The key mistake is taking time and effort automating processes and work procedures that don't need automation, or that shouldn't exist at all in the organization.
"The first rule of any technology used in a business is that automation applied to an efficient operation will magnify the efficiency. The second is that automation applied to an inefficient operation will magnify the inefficiency. " - Bill Gates
Forgetting the passwords.
No, agree with Filipe. Improving/Automating useless processes can keep a lot of people busy.
'We do the same useless things as our competitors, but we do them faster!'
Efficiency is a means, not a goal. Without knowing your usefull outcomes, efficiency is just a consultancy word.
And I think calling it automating 'a process' is a little overrated some times. Most of the time automation-things can be used to support several aspects of process execution and management, but is that the same as 'automating a process'?
It is most important that you avoid "Process Confabulation." In order to imlement any process, you first need to discover and document the process, and this is usually done by interviewing the people who are currently doing the process. Process Confabulation is what people do when you ask them what the process is, and they don't really know what the process is, and they can't admit that they don't know it.
There are many things that people do, and they are not really able to explain exactly why they do them in a particular way. It is like riding a bicycle: I can ride a bike, but I can't really tell you exactly what I do to keep my balance, I just do it. In the office, a worker may have learned that Betty is the best person to get XXX done, or that Albert is most effective at YYY, but that worker may not be able to explain why they go to Betty and Albert in certain situations and not others.
Many office workers have learned how to get things done, but they are not good at explaining what they do. Describing a business process is a very different skill from actually doing it. At the same time, if someone is being paid a high salary, it would would be socially embarassing to admit that they can not say what they do on the job. In fact, most worker think they can explain their job, so what they do is process confabulation: they make up the process that they think they do.
For a BPM consultant, process confabulation leads to implementing the wrong process. If this actually gets deployed, people find it does not work, and they perceive this as being a buggy process: not the process they asked for. If the BPM designer create a proceess for doing A, then B, then C, the process enging almost always "works" by making A then B then C. The process fails only when that is not what the workers want or need.
Process confabulation is the biggest cause of implementing the wrong process, and ultimately the biggest cause of BPM project failure.
Looking forward to seeing some of you at BPMNext, next week.
The biggest problem is inexperience and unfamiliarity with the basic principles of design; e.g., the constructs of sequence, iteration, and choice; transaction processing, and more. I will be publishing a paper on this, "Process Templates," on Monday, April 6th. Stay tuned.
What is surprising with all this "discover first then automate" talk from BPM vendors, is that so few have a decent discovery tool to front-end their automation technology. In the 15 years I ran Nimbus - a great discovery tool - we failed to ver partner with a BPM vendor. Thier product management thought it was a great idea, but the sales guys rejected us because "discovery delayed their sale". In fact on guy said "The best way to discover a process is to automate it, and then see what is not working well". Hmmm. Perhaps 10 years on, this is now different. I am looking forward to BPMNext to see how the BPM industry has moved on.
After reading the discussion so far, I will start from a different place. I want to assume we figured out the current process, there is good reason to improve it and then automate. So then the mistakes I see are about user adoption and change management. (1) not involving users sufficiently in testing the prototypes and incorporating their feedback and (2) not talking with stakeholders about what changes in skills and behaviors this automation will entail for them and making sure they really see What's In IT for Them.
First, measure the process as it is and evaluate if his automation can bring benefits to the business.
Second, consider the implementation cost of automation and balance it with the expectable business benefits, including process improvements analysis. If positive with a good ROI do it, if not, maybe it's a waste of time and money.
A key mistake when automating a process is to ignore the economics of information.
"Data is cheap and analysis is expensive" is a casual expression of the economics of information.
We see examples where this plays out as systems and process anti-patterns.
One example is alarm fatigue, where healthcare is the poster child and which reflects a failure to invest in the business analysis necessary to manage event notifications. You could say "it's all about exception handling" rather than the STP for which the process was first justified (i.e. "straight-through processing") except that doesn't go far enough.
Despite the lip service and despite the risks, in over 10 years alarm fatigue in health care has only gotten worse. And the same phenomenon shows up in manufacturing, chemicals, oil and gas exploration, piloting etc. etc.
And now that the IoT ("Internet of Things") is a vortex sucking everything into it's maw, expect the "data is cheap" problem to be multiplied over and over. Without proper business analysis and artifact construction, inexpensivie sensors everywhere will ensure a volume of data and events sufficient to overwhelm any human operators.
The problem of alarm overload starts at the device-level, but is mostly a "problem-in-the-middle" especially concerning business process, business rules, analytics and CEP.
The solution is to budget for the requisite amount of domain-specific business analysis as part of a project. In this way, volumes of "cheap data" can be turned into information, events and processes that add business value but which also occur at a volume appropriate for human interaction.
A clear understanding that
a) you are going to touch only one process among all processes which constitute the whole enterprise,
b) dependencies between this process and other processes are not known for you – “surprises” are expected
c) dependencies between this process and other components of the whole enterprise are not known for you – more “surprises” are expected
d) you don’t know for sure the result of you “intervention” – maybe the whole iceberg of processes will turn-over (and better to stay away from it)
e) there are pitfalls of automation – for example, http://improving-bpm-systems.blogspot.ch/2011/01/automation-and-intelligent-systems.html
f) a BPM-suite is mandatory but not sufficient
g) and many other architectural aspects.
The biggest mistake we make is designing for the industrial age, not the 21st century. Take one example - the minimum lifetime most process automation projects are designed for is five years.
Think back 5 years.
People used their mobile phones for talking. Companies had big, impersonal magazine-style websites. Shopping was something you did in person, in a store. And within a company, email ruled the roost as the means of communication.
We now live in a world where product lifecycles are measured in months and the whole business model changes every few years.
So why should our processes be laid down as unchanging?
Our biggest mistake in business, never mind process is "We know best" syndrome.
That patriarchal idea that there is a "right" way of doing things and only management can find it.
Once found (or fudged) it becomes a universal truth, never to be challenged or changed again.
(Until new managers come in of course - everyone wants their own universal truth)
That is ego talking, not sound management principles.
Any business is an experiment. Finding a way to make something people want enough to pay for.
Then optimising that so that less resource is used, it is scaled to more and more people and the value optimised.
A good business is constantly experimenting.
Trying to find new ways to appeal to customers, to reach more people, to minimise cost and maximise efficiency.
Process needs to be part of that. Darwinism needs to be built in.
Not to be the strongest or the fastest, but to be the most adaptable to change.