When automating processes, what are the biggest mistakes to avoid?
Making automation the goal, I guess.
The single biggest mistake, after automate for automation sake, IMO is to automate junk.
Don't automate what's done today.
Don't try to automate too much or everything at once. Instead, take a more agile, iterative approach to automation.
Considering automation out of context. A few examples are below.
1) Process automation can be the goal which it is explicitly stated by the business.
2) Process automation may be mandatory step for simplification, e.g. a complex human activity is replaced by a combination of automated "junk" and simple human activities.
3) Process automation is done best for “freshly” finished (done and failed today) projects because the knowledge is still in staffs’ brains.
4) Use PDCA (or agile) for process automation and limit yourself to only one “cycle” at the time - run simultaneously as many “cycles” as you can and your architecture permits.
Even with the best people, BPM implementations always confront pitfalls. Common root causes include:
We think people know what they are doing and are responsible for doing it and will stick around to complete it, but they don’t and they aren’t and they might not;
We believewe have asked all the questions and furnished all the answers, but something was missed unintentionally or hidden intentionally;
We assume that after agreement has been made on scope nothing will change, but once people learn the possibilities or fear the results change always happens.
How can we avoid (or at least minimize) these problems? Very good, detailed, proactive project management and program management.
Within project management, I recommend implementing planning and risk mitigation strategies up front that identify everything that can affect the success of the project downstream.
Planning and Risk Management practices cover:
Delivery Methodology– Discuss and agree to methodology (Waterfall vs Agile) as it drivestimelines, resources, and costs. Methodology applies to the what (functional) the solution does and how (technical) the solution will work. Methodology directly affects analysis, documentation, mock-ups, demonstrations, work in progress (WIP), minimal viable product (MVP), testing, and plan/do/check/act cycles.
Assumptions, Constraints & Dependencies– Itemize and agree to all assumptions (i.e., approach, RACI, third party participation, linear vs parallel work streams, reuse of prior work), constraints (i.e., time period, budgets, resources, geography), and dependencies (i.e., IT support for integration and deployment, testing, training, release planning).
Communications & Reporting– Itemize and agree to holding meetings (e.g., weekly reviews, stand-ups, steering committees, calendars), and determine their purpose (i.e., reviews, resolutions, awareness), audience (PM, Scrum members, Stakeholders, team members), mode (i.e., meeting, email, webex), and frequency (i.e., daily, weekly, monthly).
Risks– Itemize and agree to risks, likelihood, impact, response, and mitigation strategy.
There are a lot of good suggestions here, and I could echo some of them. But in my experience there is one problem that has caused the failure of more BPM projects than any other:
[b]failing to anticipate failures[/b].
When you design a process diagram to represent the human-relevant process, it represents how people want to see the process, and does not represent how the process must be implemented. Getting those
[i]mixed up [/i]is the source of greatest pain.
Last summer I wrote a bit about [url="https://social-biz.org/2015/08/24/podcast-about-robust-bpm/"]"robust" BPM processes[/url]. It is a style where processes work to bring components of a distibuted system "into consistency" instead of assuring consistency at all times. Most business processes are drawn in a way that assumes consistency -- which is right and good, because thinking at the business level you should not have to worry about things like disks failing, and network outages.
When you actually implement the process as automation, you absolutely must consider how the system recovers from a disk outage. As an engineer, you need to ask the questions: how does this process respond when a particular server goes down for an hour, when a disk goes out, when a network connections is lost for an hour, and a particular database is restored from a backup 4 hours old. These can NOT be hidden from the user.
One incredibly naive approach is to try and make the entire system "reliable" so that the business process can be implemented literally in the system. For a variety of reasons, this approach does not work in real life, it does not scale because of the cost increases exponentially, but it works well enough to get through testing and often into production.
Making a robust system requires a
[i][quote][b]translation [/b][/i][/quote]from the business process, into way that you have to automate to get a robust system. Failing to do this, failing to consider robustness, and instead implementing the business process literally, is the single largest reason for BPM project failure.
See section "Automated activities" in the blogpost "Shifting architecture focus from the thing to how the things change together" at http://improving-bpm-systems.blogspot.ch/2014/08/bpm-for-digital-age-shifting.html whcih is about how to make your processes "fail-prove".
Nice note on "incredible naiveté" (which probably stems in part from what Mr. Gotts flagged as "believing the salesperson). There's a hint here I think concerning the failure rates of BPM projects. And also a hint as to "why" such rates, specifically which is the issue of "reliability" versus "translation". Am I correct is seeing these insights as referring to the round trip problem? Volker Stiehl's (as referenced by Mr. Nafornita here too) proposed solution to this problem is to radically segregate SOA problems (e.g. a failured storage element) from business logic issues. A step forward maybe . . .
- John Morris
- 1 year ago
All of the above make sense.
But, what hat I always wonder in this context; what is meant with such a general term like 'process automation'
Because when it is really automated, there will be no user interface, triggers are automatic, output is automatic. Something like AI to AI.
So in the end you'll always come back many of the comments above; understand your processgoals first, then see if some toys from the automating shop can help.
Sharing my adventures in Process World via Procesje.nl
Believe the automation vendor salesman
Years ago, in the pulp and paper industry, we had "experts' who could sense the moisture content of the sheet by feeling the sheet as it went by at more than 3,000 feet per minute. The reason the experts were in place was that by the time lab test results would become available, it would be too late.
Without high automation, papermaking would not be competiive, too much automation though and you quickly get to re-work.
I don't think we have any office/services processes that can generate paper as fast as a pulp and paper machine but the point is with no gatekeepers embedded in a process you can get into a mess.
As for hard-coding all eventualities into a process so that you might possibly manage to over-automate it - the eventualities you don't think of are the ones likely to do you in, so good luck.
Personal experience - I was starting up a cement plant on my first job, carefully watching all of the dials across a 40-foot wide control panel. Someone rushed in and announced that the slurry pit had overflowed and there was slurry all over the plant floor. My back was turned so I did not see the operator.
I tapped the level indicator and replied "impossible". There was silence, Then I turned around saw the operator with slurry up to above his knees. I have been very suspicious of meter readings from that time.
Automation is a consequence of first understanding the process then digitizing which will bring basic steps to automation of data collection and presentation. Automation should then evolve to more sophisticated as users see how the outcomes could be improved and here rule capability will add to achieving this objective. So get the basic thinking in right order is important and should avoid too many mistakes?
1) Know WHY you are automating.
2) know WHAT you are automating, ("all of it" is not an option)
3) train your staff, prior to the release... do not depend on ituition
4) let every one know of the release, even if they are not directly involved
Usually "why" is the one that has the least attention, followed by training the staff.
Most importantly the impact of automation on changing work practices must not be left to sort themselves out. Your future automation exercise is dependent on how you handle these issues.
I echo the comments above, and I'd add a more philosophical consideration:
We need to automate anything that can be done better (i.e. cheaper, faster, more reliably) by a machine, at the same time considering the limitations of machines.
There is a strong temptation to judge machine activities in terms of human tolerance, which leads to disasters down the road. For example - I have seen my fair share of BPMN models parallelizing service tasks that work on the same database records (so bye-bye ACID) hehehe.
At the same time, there's the equally strange temptation to automate inherently-human activities, like complex decisions, learning, emotions. That would also lead to disasters, sooner or later.
So, the biggest thing to avoid when automating processes is
[b]an immature enterprise architect[/b]:-)
@Keith: interestingly enough, I have long debated with my team the level of transactional consistency activities that should be shown in executable BPMN diagrams - we started by showing everything, the service tasks that deal with partial front store saves, the interface errors, the validation errors etc. While this is fine for us, for most customers this is at times alienating. And especially for proofs of concept.
The solution we are working towards is an Error Bus (like a system pool that receives all system errors and system escalations and treats them according to an error taxonomy). This is based on the principles laid out by Volker Stiehl and on the research work done by prof. Wil van der Aalst et al.
Key challenge is to make it work (and scale it) independently from the implementation environment, considering that each integrated system may have already implemented a subset from the error handling taxonomy above.
Managing Founder, profluo.com
Strongly agree. A lot of self-proclaimed "enterprise architects" do not understand BPM (as a trio discipline, tools and practices).
I don't have any scientific method - in most modelling cases it is evident from the way they use the BPMN standard (or avoid using it, or fail to grasp the power of it) or they fail to think about how the architecture choreographs all solution components.
- Bogdan Nafornita
- 1 year ago
A little late to the party but I certainly agree that analysis and knowing exactly what and why you are automating something is the number one priority. I've been in situations where a company has automated something only to find they missed a crucial piece to the process, the automation project failed and instead of adding in the missing piece, they just shelved the thing altogether. That gives BPMS a black eye and sets us back in showing organizations that this is a viable and worthy solution.
I think the other thing is to break the process down into as many steps and then individually automate those steps. Keep the automation simple, that way if there are problems, it's easier to catch them (as Keith Swenson wisely pointed out) and correct them before the work being automated goes to far down the line. By breaking it down, it also makes it easier to slowly implement the automation by adding more to it as the user community gets used to it. Users are typically leery of automation because they a) feel it may be a danger to their job (although that worry should be shut down early discussions of the automation project and b) they don't think whatever it is they are doing can be automated. Again, we go back to analysis. It's SO important.
On the other side of the user coin, some users want to automate everything and that's where an automation project can become too complex and again, that's where it's important to break down each piece. So from this angle IT is the one doing to slow acceptance for the user instead of putting in everything they want.
One final thought, as I read through the comments, it was almost as if "automation" was a bad word. It shouldn't be if it's done right and done well. Things like automating the matching of new content to existing work items, setting follow-up timers and automating an escalation process. This can all be done pretty much out of the box with most BPMS platforms and still falls under the automation category.
What can be added to all the existing and outstanding answers, regarding the question "
[b]What is the Biggest Mistake to Avoid When Automating Processes?[/b]"
There is one more thing to add. And that one more thing concerns the meaning of BPM itself, i.e.
[u]what it is about BPM that makes BPM, BPM[/u]?
Because in fairness, all the excellent insights here concerning BPM can really
[u]also be applied to many technologies[/u], especially low-code, and framework-driven coding.
It's a mistake to treat BPM as "just another technology".
BPM is in fact
[u]the irreduceable technology of the work of business[/u]. BPM technology, and only BPM technology, by definition features
[u]the concepts of work as first class citizens of that technology[/u].
That means that managers and business analysts working with BPM are
[u]directly capturing and evolving business ideas concerning work operations[/u].
All other technologies require
[u]mediation [/u]of programmer and code. And mediation introduces
[u]surprisingly high costs in time and expense and rigidity[/u].
The use of BPM, along with the use of other irreduceable and related technologies, including rules, UX, algorithms etc., is an opportunity to dramatically
[u]shorten time-to-value and time-to-change[/u]for new artefacts of automation.
This is a radical message, but it is a message increasingly relevant, especially in situations where the BPM round tripping problem is minimized. Business needs flexibility and systems velocity. And BPM technology and methodology have matured beyond a tipping point. It's a nice combination.
A successful BPM project needs to be managed according to the excellent advice shared here. We will be a step further ahead though if we also try and understand "
[u]why BPM specifically[/u]" and the potentially signficant advantages that
[u]BPM brings over alternatives[/u].
[i][I'm cross-posting this note to another current question, "What is the Key Value Proposition for BPM?"][/i]
- Page :
There are no replies made for this post yet.
However, you are not allowed to reply to this post.
However, you are not allowed to reply to this post.