In a panel session this week at the eBizQ virtual conference (see here and here) I was asked “What common mistake do people make that causes unnecessary delay in BPM projects?” The answer: Many projects have a goal to implement too much at once. Some projects attempt to turn a manual process into a completely automated “straight-through” processes where there is no human interaction at all.
It is true that the more you can automate a process, the lower the cost or running the process. But the cost of automation can vary greatly from activity to activity. Usually it is the case that about half the steps can be automated fairly easily, but as you automate more and more, the cost starts to rise steeply. There is usually a step or two in the process which is very difficult to fully automate.
What are those difficult steps like? Usually it is an activity where a person accesses a third party system to manipulate the information held in that system. Unfortunately, there is no well designed API to manipulate the data in the same way.
The SOA folks say: “Wrap that application in a service”. Right they are, but that wrapping can be very very expensive. I have seen upwards of a programmer-month spend on creating such wrappers. It is a simple cost/benefit relation which depends upon the number of times that you need to do this. If a person can access the system through the user interface, and accomplish the activity in 30 seconds, and if you estimate you will need to do this 1000 times a month, then you will be saving ~10 hours of work per month, maybe 120 hours/year. How many hours will it take to create the wrapper? It can be more than this.
There is an emotional side. Some people are shocked when I suggest that we simply assign a task to a user, and have that user manually update the information in the third party system. It just seems wrong to automate the process so that people can manually do a task. This group-think often pushes a project to an all-or-nothing stance in process automation. Striving to automate that last 5% causes most of the delay and cost of a process automation project.
I suggest instead that you aim initially to automate 80% of the process. Look at it this way: before you start, the process is 100% manual. You have people doing manual tasks, coordinated only by their own diligence through the use of email, and without any reliable record of what has been done. If you can reduce the manual activity to 20%, you can cut the cost of the process to somewhere around 1/5 of what it was before. That can be a huge savings and can be relatively easy.
Get the process deployed into production with only 80% automation. This leaves 20% manual, but then it is 100% manual before you start, so why should anyone complain about leaving 20% manual? You will start to get a payback immediately on the 80% automated. You get a relatively quick win.
You don’t stop there. Use an Agile approach to automate another 5% and get that into production. Then another 5%, and so on. The ultimate goal is to automate 100% of the steps that can be automated. (Some steps require human decision making and can not be eliminated completely.) The key is that you don’t need to do this all at once.
Consider that as you automate a process, the automation will change the organization, which will in turn change the process. When certain steps get easier, you will find they are leveraged to replace harder steps. The process as it is today is a result of choices people have made in evaluating cost/return on individual steps, and when the cost of a step changes, it can change a process. This change is not intuitive, so when you deploy the process with 80% automation, you should investigate whether you process is still what you thought it would be. Luckily, if you are using a process support system which includes strong human level analytics you can easily re-evaluate the bottlenecks. You can focus you ongoing efforts on the parts of the process that will yield the most benefit.
There are benefits beyond the automation of tasks. It turns out that even if you left each activity completely manual, and just used the process technology as workflow to route and track the process, you would gain a tremendous benefit: you would be able to know the precise state of each process, and what has happened to it in the past. Usually half the activities are easy to automate, so there is no reason to stop short of that.
As you automate more and more of the process, you will find there are more and more exception conditions, each one of which is increasingly rare. The benefit of automation gets smaller as the number of cases gets smaller. You always reach a point where a case falls outside of the norm, and you simply give it to a person to “fix the problem”. That is the most cost effective way to design the process, but that is precisely where a lot of projects get tripped up. They underestimate the complexity of the process (it seems so simple) but on the course of complete automation, stopping short seems like failure, so they continue to implement and implement, through multiple delays and escalating costs.
The 80% solution is master of all this: start small, get a quick win, start seeing the benefit quickly, focus on the areas that need the most attention, continue to improve. After all, isn’t the point of “Business Process Management” all about continual improvement over time? You don’t need to do it all in the first step.