Thoughts on Process Improvement

In my earlier post, I mentioned the possibility that automation, inadvertently, leads to  / works as an entry barrier to process improvement. In this post I am expanding on that thought and thus, there is quite a bit of similar content in both posts.

As is evident from the title, I am posing a question. My answer is a “conditional” Yes and this article will clarify why I think that way. Automation is a magic word. On the outset, I am a major proponent of automation & the benefits it brings in the overall improvement in operational efficiency. The distinction is that the long term results of good automation will bear fruit only when it is “done right”.

Over the last 10 years, I have seen many automation projects that showed great short term potential but did not live up to the promise. Moreover, I have seen random automation actually delay much needed process changes. This is how it played out. (This may be seemingly anecdotal but some of you may find similarities with situations in your experience.)

It basically starts with some “manual” process. As organizations grow, what was a seemingly small activity in scale, over the years, turns into an arduous task. I will illustrate this with an example.

Problem
There is a certain sales situation where an order cannot be identified or credited systematically and salespeople have to claim the order as using a certain process. These claims are in a scenario where two sales people from different lines of business work together to get the business. One of them gets credited directly (systematically) and the other has to claim. Moreover this is supposed to be approved by two managers from both lines of business. Even if one manager rejects the claim, it would have to be resubmitted.

What went wrong
So what was a process problem is now a process problem & an automation aka tool problem.

And because a significant investment was made for creating the tool, there is a general tendency to keep trying to make the automation work. So we keep adding band-aids and try working around a wrong process to start with.

This example is simplistic at best and there are a lot of other moving parts. The net result was that the wrong process was automated and it took a year or more of payment delays & operational pain (in terms of support cases & further manual effort) to figure out that the business rule has to be modified.

To be fair to the business analysts, the automation was done when this business model was in initial stages and thus, the business teams possibly did not have a way or foreseeing what can come up in the future. Also the scale was small when the tool was launched. But as business grew and the # of claims started hitting 5 or 6 figures, the problem was felt far more acutely.

Done Right
Thus I come back to my initial point. Automation is useful when “done right” and I define done right as follows:

1. The right processes are automated
2. The processes are optimized and non-value added processes are minimized / eliminated
3. The automation is designed & flexible enough to handle events in the foreseeable future
4. The automation has a positive impact on some meaningful organizational metric – It’s got to move something relevant
5. It needs to have a clear ROI

It takes a significant amount of rigor to ensure that the processes are analyzed and optimized before they are automated. Assuming that automation will miraculously solve process problems is at best a fallacy & an expensive one at that.