Ignore Pre-Automation Process Optimization at Your Own Peril!

I just came off a Pilot implementation of my company’s Data Palette automation product at a Fortune 100 company. This Pilot started off as optimistic jubilance at being given an opportunity to implement our technology in such a large and reputable organization, but soon that exhilaration changed to moroseness and even, despair. Finally, by the time the Pilot was nearing completion, the prevailing mood changed back to a sense of positive achievement as the effort successfully wound up in spite of certain deficiencies. This roller-coaster of emotions could be attributed to the missed opportunities and changing goals evidenced during the Pilot.

When we started out, the primary goal of the Pilot was to prove that Data Palette can be made to work in the client environment. (Because the environment is very large and complex with several moving parts and heavy human intervention, automation was not considered easily doable.) I helped carry out a detailed discovery there and felt we could take on the challenge. However I did so intending to optimize part of their processes along the way; to minimize the areas where human involvement existed, but was really unnecessary. The client CIO agreed that optimizing their IT processes was a good thing prior to standardizing and automating them. However once the Pilot started and we laid out the standard operating procedures, the client team operating at the ground-level was resistant to any changes in their day-to-day processes. They felt human DBAs needed to be in the drivers’ seat and any decision making needed to be kept manual, even the mundane ones that made them get up in the middle of the night.

That’s when the demons of doubt started plaguing me. Could we still automate the processes the way they were and attain significant productivity gains? Sometimes the manual actions and logistics interspersed throughout the task take up more time than the task itself. If these time-consuming manual interchanges cannot be avoided, any automation of the task itself can seem insignificant. (I' m sure you have often heard IT personnel say "well the actual task only takes about 20 minutes, but the logistics around it cause the task to take up 2 hours, so I'm not sure this task can be automated or whether it would be valuable to have it automated!")

I really wasn’t worried about Data Palette’s ability to accommodate manual decision making and control and the end result proved this out. However the extent of benefit to the client environment was bothering me. In certain areas, I wasn’t content in letting them operate the way they were. One of the intentions (and side benefits) of standardization and automation is that it needs to be preceded by process optimization to bring the right amount of value. I was concerned due to the ground-level staff’s rigidity, value wasn’t being realized to its full potential.

Let me explain my concerns via a simple IT call center operation. When a call or alert comes in, it’s typically handled by a Help Desk or Tier 1 group. They document the problem in a trouble ticket, look at the nature of the problem and try to resolve it if possible. If they can’t, they assign it to the appropriate Tier 2 group and move on to the next call. Depending on the urgency of the problem, an Tier 2 person may be paged and assigned to the issue so it can be worked on. Now what happens if the Tier 1 person handling the issue is unsure about “when” to pass it on to the right Tier 2 group. Let’s say, this person is obsessed with solving that problem and is unwilling to pass it on quickly. She takes hours trying to figure out what is causing it and it becomes a matter of personal pride. That’s very nice of the individual, but this kind of manual decision making hurts the caller and the company. The caller has to wait a lot longer to get a resolution. If there was a business rule that stated that a Tier 1 person could spend no more than 5 minutes trying to identify the problem and after that, they had to pass it on to a different group, that would help matters. That would allow the right (more senior) person to evaluate the problem and implement the solution. And that would free up the Tier 1 person to take additional calls and the operation would run much more smoothly. The process would dictate when and how each call would be escalated rather than placing the onus on the Tier 1 individual to decide how to deal with a call.

Similarly, if the Tier 1 person had to go to a manager’s office and ask for her permission to assign the problem to a Tier 2 group, that would introduce an even higher level of inefficiency. Or during assignment of the ticket, the Tier 1 person had to call the Tier 2 person and if unable to reach him, had to walk up to a this person’s cube (say, it’s in a different part of the office) to try and get that person or wait for him to get off the phone, again the process would be grossly inefficient. These are all areas that involve unnecessary human involvement and delays and pose a barrier to automation. With the right level of process optimization and decision automation, these inept areas can be completely eliminated.

As you peruse the above examples, some of you may feel "This is a no-brainer. Why would anyone tolerate such inefficiencies in their day-to-day IT processes??" Well, pause for a minute now. Take a deep breath and look hard inside your own environment. The inefficiencies may have manifested in a different way. Many managers and ground-level personnel in companies feel “We know what’s best for our business and there’s a reason why we have developed certain processes to accommodate our unique needs. Any automation efforts need to take those into consideration.” It’s easy to be rigid about these things. And some areas really do deserve such rigidity. But many areas really don't. When you have external specialists working with your internal experts, it’s a unique opportunity to be able to re-evaluate the basis for operating in a certain way and adjust them to yield the maximum productivity and faster task accomplishment prior to automating that method of accomplishment. The results are usually in black and white. If the productivity gain is demonstrable and not just a spreadsheet exercise, then the change should be embraced.

In this particular Pilot, we were able to eventually convince the staff that it was in their best interest to accept the process improvements in certain areas. That allowed the feeling of jubilation to return all around. However it may be only until the next Pilot, since this arm wrestling over process optimization is somewhat of a recurring pattern...

Process optimization should be ignored at one’s own peril since it could very well be the best part of the automation effort. Such optimization often means the difference between a hefty 30% plus efficiency gain versus a mere 5~10% improvement.