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:
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:
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: failing to anticipate failures.
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 mixed up is the source of greatest pain.
Last summer I wrote a bit about "robust" BPM processes. 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 translation 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.
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.
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.
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 "What is the Biggest Mistake to Avoid When Automating Processes?"
There is one more thing to add. And that one more thing concerns the meaning of BPM itself, i.e. what it is about BPM that makes BPM, BPM?
Because in fairness, all the excellent insights here concerning BPM can really also be applied to many technologies, especially low-code, and framework-driven coding.
It's a mistake to treat BPM as "just another technology".
BPM is in fact the irreduceable technology of the work of business. BPM technology, and only BPM technology, by definition features the concepts of work as first class citizens of that technology.
That means that managers and business analysts working with BPM are directly capturing and evolving business ideas concerning work operations.
All other technologies require mediation of programmer and code. And mediation introduces surprisingly high costs in time and expense and rigidity.
The use of BPM, along with the use of other irreduceable and related technologies, including rules, UX, algorithms etc., is an opportunity to dramatically shorten time-to-value and time-to-change 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 "why BPM specifically" and the potentially signficant advantages that BPM brings over alternatives.
[I'm cross-posting this note to another current question, "What is the Key Value Proposition for BPM?"]