Today while visiting a grocery (super-)store I witnessed a strange event in the parking lot where a couple of guys were “pushing” carts. This is something I did in high school so it is a task I understand very well. They had a 60’ plus train of carts along with a motorized device at the end that helped to push which is what grabbed my attention. My assumption is that since they had the motorized device (technology innovation) they could take on more work (process efficiency). What I witnessed was something completely different. I watched them for well over five minutes. In that time the train grew and grew and became very difficult to manage. You can also imagine that a 60’ train of carts in a busy parking lot blocks quite a few cars, including my own. From my time of pushing carts I knew what a manageable load was and that it was often more efficient to manage smaller subset of work. In the time I watched them in this farce, the two individuals without the aid of any motorized cart should have been able to collect and return twice what they ended up collecting without unconvincing any of the customers by blocking them in.
This story is a great example of what happens when you overuse technology in an attempt to increase business efficiency. It is important to look for the sweet spot, adding just enough value without overbuilding or you will see diminished returns.
I’m sure everyone that has worked with workflow or Business Process Management (BPM) for any period of time will have lived through projects that went passed the sweet spot. It is not always as clear as the shopping cart story above. In my experience it typically comes from either trying to automate too much in a previously manual process or from trying to handle too many process exceptions. One of my favorite things about process improvement is that it is not a one cycle process. You go through iterations of improvement and continue to tighten up the process. With this iterative approach it affords the team some time to automate the manual processes and helps the process mature a bit before you try and handle all of the potential exceptions.
In one project where clearly things had been taken too far, the team had spent a pretty substantial amount of time working through all of the different types of process exceptions. I think there were eight possible paths at one point. After the process went live we ended up finding that a few of the paths were never followed, and a few others were followed fewer than 3% of the time. Clearly mistakes had been made and the process was overbuilt. Working in a few steps that were a bit more generic and only partially automated would have been a better alternative. By planning smaller, more focused iterations you will show value quicker and make it a lot easier to plan the next improvement cycle.