Which Came First? Process or Automation?

There's a lot of activity in the marketplace around IT automation, the automation of a wide variety of IT activities.  Unfortunately not all of it is helpful.  Many vendors and not a few IT organizations are assuming that, if automation in general is a good thing, then any automation is better than no automation and automation in any form is good.  So they end up automating IT processes and activities in a relatively undisciplined way, and without any clear or objective sense of what they hope to achieve other than to "lower cost" and "reduce the amount of manual effort involved." 

While these are clearly good objectives, I'm hearing from the more mature IT organizations a much better and more discplined way to think about this.

First, it all starts with process.  IT organizations who are thinking seriously about automation must first think seriously about process.  Identify those key IT processes, document them, train people on how to follow them, and then put measurement mechanisms in place to capture a number of key performance indicators to track how well people are following these processes and how well these processes are working.  Also identify process owners, because this is what they do.  This is Process 101, and any decent process engineer can help you set this up.  This initial set of processes should be good processes (or "good practice") but don't try to make them perfect; we'll get to that in a moment.

As an aside here, you can even use some process tools (either generic process tools or IT-specific process tools) built for this purpose.  There are some good ones available, they have the ability to collect the essential key metrics already built-in, and many come with good IT processes out-of-the-box.  Some also have the ability to support the automation of elements of these processes, and that's a clear bonus; more on this in a moment.

Second, start using the metrics collected to do two essential things:

1. Determine where the processes are not working and fix the process.

2. Determine where people are not following the process and fix the people.

Let the organization run a bit, and then do the second step again, and again, and again, and don't ever stop.  This second step is called "Continuous Process Improvement," and it's at the heart of what Dr. Deming tried to teach us so many years ago.  You may also find you're not collecting the right metrics, so you can fix that along the way as well.

Now, several things should be clear from this description.  The first is that Deming was right: good practice is what you can get from others (in books, in software, in tools, etc); best practice is what a process-mature IT organization gets after plugging good practice into the above CPI algorithm.

The second is why you shouldn't spend too much time trying to fine-tune the processes in their initial implementation.  Let your CPI program do that for you.  Overwhelming experience teaches us that.

The third is that automating good practice (i.e. automation purchased out-of-the-box) isn't nearly as effective in the long run as automating best practice.  So we get the real payoff when we add a third step to the CPI activity above:

3. Using these same all-important key metrics, identify those processes or process steps that can be automated and that are expensive (time, money, people), error-prone (lots of human error), or both, and automate them.  With this approach, it's now possible to approach the automation of most IT activity in a disciplined, thoughful, and goal-oriented way.

So, what we learn is that buying automation out-of-the-box may have short-term benefits, but is ultimately short-sighted, since you've traded off best practice for good practice where automation is concerned.  Second, automation isn't something you buy but something you do when paired with the right approach, the right metrics, and plugged into a larger process improvement paradigm.  Third, the IT industry is still in its infancy at learning how to do this correctly, but we have the benefit of seeing how others industries did this, and there are many of them.  More on this in a future post.