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.

I am currently working on a process related to compensating sales people on a particular business model. For a host of reasons that I cannot go into in this note the process is completely manual. Right from the classification of an order, the “claiming” of the order (by a sales person), the sales crediting and finally the upload into the commissions systems, everything is done manually.

To compound the issue, the process is different in each theater (geo area), there are different tools used each created with a different logic / business rules for classifying orders and the process is managed by different organizations in different theaters.

In most of my conversations with stakeholders especially the operations people, the word automation was used multiple number of times. The pain that people were facing was with the present “manual” effort to do the above activities. It was the most visible parameter and thus the focus was on correcting it. So the hypothesis is that by eliminating “manual touches” and automating the process, we bring about significant productivity improvement.

I know that automation is likely to bring about productivity improvement. But that is when it is done on the right process. One thing that was apparent in my scenario was that the process was not optimized and there were a significant number of steps in the process, that were not adding value. Effectively, over the last some years, we have built tools that support processes that were in themselves questionable. And I am positive there was a business justification to do that.

But in retrospect, it is obvious just by automating a process by building a tool has really not solved anything. In fact, from a process problem, we now have moved to a process problem and a tool problem. By spending thousands of dollars on “tooling” a processwe may inadvertantly have built entry barriers to change (or process improvement).

The following pointers could be useful when considering process improvement activities.

1. Keep in mind that the objective is not to remove manual activity. The objective is to improve the process.

2. Once improved, the process has to positively impact some aspect of the organization.  If possible, define some metrics to isolate the impact. The impact could be measured in terms of time, cost or quality or any other variable.

3. Never jump into “automation as a solution” thinking without first cleaning up the process by removing any kind of wastage. Please note that there may be some activities that do not add value but may have to be retained for legal or compliance requirements.

4. Look actively for opportunities to eliminate activities that add no value.

5. Look for opportunities to combine activities. Once the wastage has been reduced, then consider simplification (or call it automation).

Automation in itself is not bad. It is extremely useful when done with a plan and when done right.

NOTES

The following articles have some of the ideas that have been presented in this post.

1. An article by Flournoy Henry from BP-3. This is the article that triggered the thought.

http://www.bp-3.com/blogs/2008/10/program-or-process-how-do-you-decide/

2. An article by Bob Lentz in 2005. This article is very detailed and has a lot of detail and explanation of the ideas in this article.

http://www10.mcadcafe.com/nbc/articles/view_article.php?section=UserArticles&articleid=252637

3. To automate or not to automate? The authors talk about automation from a IT viewpoint

http://www.usenix.org/events/hotos05/prelim_papers/brown/brown.pdf

4. An article on the good and bad of automation.

http://port25.technet.com/archive/2006/05/22/Automation_3A00_-Not-at-the-cost-of-core-expertise.aspx

and a few more…

Appreciate your comments.

1. Stakeholder mapping is not a one time exercise. Stakeholders may change, their needs could change as their understanding of what you offer increases, and so on.
2. Set expectations on communication protocol and adhere to it.
3. Have agreements with stakeholders (formal or informal). The basic components of the agreement are the outcomes (for them, for you and us), the outputs (deliverable(s) and timing) and the consequences of not delivering on the agreement.
4. Goes without saying that delivering on the agreement builds trust.
5. Agreements also need constant monitoring.
6. Be Accountable. Accountability simply defined is an obligation to accept responsibility for one actions and if managed well, creates alignment and empowerment, drives people to cooperate and finally delivers results. Also note that for stakeholder agreements to work, there is a need for accountability and trust.
7. Build credibility. Make allies. Some stakeholders will be people you know and some will be known by people you know.

Remember that this could be a different way of operating and may require change management. People in general may suffer from “commitment phobia” but at the same time, everyone appreciates structure. At the end of the day, you will be appreciated.

Sounds like a lot of big words and motherhood statements. But convert the text above in simple English, make a commitment, keep it and religiously expect the same in return.

I received some feedback that this topic merits more discussion than a honorable mention. My assumption brings forth a very pertinent question. Why does process exist? Lets just look at a few definitions for process.

A process is a set of activities that produce products and services for customers. (Source: GAO’s BPR Glossary of Terms)
A process is an organized group of related activities that together create a result of value to customers. (Source: Michael Hammer)

There are a multitude of other definitions that possibly do not have the word I have highlighted in bold above — customers. But regardless of which definition you chose to follow and whether it explicitly states or not, a process exists to serve a customer need.

So when you walk into a process improvement scenario, it may be a great idea to see if there is a “well defined” customer for the output of the process and whether it is possible to articulate their needs simply and clearly. Call it Objective, call it outcome, call it anything, but to quote Habit 2 (of the famous seven from Covey), begin with the end in mind.

In my experience (and most likely yours), I have seen initiatives that were abandoned midway (without realizing their full potential) when there was a general disagreement among the many stakeholders in terms of the outcome and worse still, not too much clarity on the end customer. I am not sure how many of you faced this but many times when I start off on a project one of the challenges I encounter is mapping stakeholders and determining with surity who the end customer is. Its easy to get a list of names but the complexity arises when you have to ascertain the role each of these names play on the project.

I will illustrate the above statement with an example. Assume that you are working on processes that ultimately help pay commissions to the sales agents in your company in an accurate and timely manner. To do this, you obviously need to work closely with people from HR, Finance and operations who are the actors in your process. They are the people who actually follow the process (or use the associated tools). In the entire process, the sales people are involved only when they have to approve or accept their compensation plans and as a process manager, you do not interact with sales people (or do not need to) even once.

So who is the customer in the above scenario?

By the way, this is no trick question. All of you immediately know where I am leading. The problem is that its awfully easy to get lost in operational details and forget focusing on our customer and their needs.

We will talk more about customer and stakeholder management in the next post .

Moving on, the next question is how much do we break-down a process? A seeming simple question and there could be seemingly simple answers. A good rule of thumb I follow is as follows:
1. If the process is broke down to a level (call it step) where you cannot isolate / measure the impact of a particular input on the step, you have gone too deep.
2. If the process is at a level where the measure / impact does not allow for generating a meaningful conclusion, you are looking at it far too high a level.

Regardless of the confusing rules of thumb up there, the simple statement of fact is it should be at a level where:
1. It can be defined
2. It can be measured
3. It should lend itself to some improvement or even better removal from the process
4. It should have a clear link to the next step in the process

Believe it or not, while I did not really plan it that way, when I re-read the above statements, I saw D M I of DMAIC. Call it coincidence if you will. (I won’t push myself to add the A or C right here)

For someone who does not know DMAIC, http://en.wikipedia.org/wiki/DMAIC#DMAIC will provide all the dope you need. It is simply Define, Measure, Analyze, Improve & Control.

The above link talks about six sigma and also DMAIC. There are some good words and some criticism. I would not spend too much time on the criticism and stuff. When I look at these frameworks, all I see is just that—a framework.

For me, DMAIC is five cool English verbs that can help provide structure to a problem.

More in the next post…

“A business process or business method is a collection of interrelated tasks, which accomplish a particular goal.” (http://en.wikipedia.org/wiki/Business_process)

There was one interesting example they gave here of how Adam Smith defined the pin-making process in 1776.
”One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head: to make the head requires two or three distinct operations: to put it on is a particular business, to whiten the pins is another … and the important business of making a pin is, in this manner, divided into about eighteen distinct operations, which in some manufactories are all performed by distinct hands, though in others the same man will sometime perform two or three of them.”

There is another reference to this in an article from a site called Living Gloucester. “Pin making by hand was an industry that required the skills of a number of different craftsmen. Adam Smith, the pioneering economist, considered pin making a classic example of the “division of labour”. Just how many different craftsmen were involved in the chain of production is controversial. Some manufacturers seem to have managed with six workers, whilst others required up to twenty-five. There may have been a tendency to sub-divide the processes as the eighteenth century went on.”

Lets come back to the simplicity of the process. For a manufacturer who was using 25 people for the job, this must have been a fairly complex process and possibly, a little less so for the person using six people. That is when you look at the process as a whole. But the focus of my claim of the simplicity of a process is the process description by Adam Smith. In his statement, you see a “break-down” of the process into tasks and there lies the beginning of process improvement.Right in 1824, 60 years after Adam Smith’s famous example, an American called Lemuel Wright patented his machine for making solid head pins. And you and I know more about pin making today than we did yesterday.