jump to navigation

Is automation the miracle cure for all process problems? November 8, 2008

Posted by Prasad Varahabhatla in Automation, BPI, BPM, Process Definition.
3 comments

In my experience, I have come across many instances where Process Improvement and Automation are talked about in the same breath and many times, interchangeably. In fact, I too did (and sometimes still do) the same. Some recent articles brought about a change in perspective.

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.

Who’s that coming out of the woodwork? November 3, 2008

Posted by Prasad Varahabhatla in BPM, Customer Requirement, Stakeholder Management.
Tags:
add a comment
All of us are very conversant to with words like sponsor, stakeholder, team member, customer and so on. For instance, program and project managers spend a considerable amount of time trying to clearly articulate the R&R’s among their team members. I have seen in my experience that the same level of rigor is sometimes not applied to define the exact role stakeholders and customers play in the success of our initiative.
 
This becomes more challenging when dealing with
1. Long term projects (> 1 year)
2. Large organizations with numerous “affected” departments
3. The program impact spans countries and timezones
 
So, it is imperative that we map the stakeholders and clearly document the role they play in the program. The RACI matrix (http://en.wikipedia.org/wiki/RACI_diagram) may be a useful tool here. Be carfeul to map everyone, however small their role may be. If there are stakeholders with different needs, it is wise to re-look at the scope, determine whether the current activity we are undertaking meets all the varied needs and in case, it does not, spell it out to the relevant stakeholders. Publish the scope and stakeholder map so that everyone know where you stand and where they stand. Use Wiki.
 
A few ground rules I gained from experience and training.
  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.

Till now I have not yet reached to any content that directly says Process Excellence. We are still in the early parts of the journey. We will get closer to Process Excellence as we reach the destination.