Process Before Tool (right)?

Tonight at the IT Service Management Fusion 12 conference I ran into an old colleague. It was nice to see him again. We worked together at an IT good practice consultancy, and like me he later moved on to a tool vendor.

This isn’t unusual. Most work in this industry involves the configuration or customization of tools to meet the specific needs of the organization. Consultants need to earn a living and that means going where the work is, or much of it anyway.

He and I still focus on good practices, but now from a different perspective. Operational excellence, consistently executed, usually requires defining the process at some level. Sometimes this definition is informal, in the heads of the stakeholders, and sometimes the process is defined more formally, using Visio diagrams and descriptions of process details and statements of policy.

In many organizations the sum total of the process is expressed in the configuration of the tool. This is not good practice and I don’t advise it. It happens a lot.

Consultants in this space repeat “process before tool” ad nauseum. Another variation is “a fool with a tool is still a fool (or a faster fool).” At conferences and in presentations there is no shortage of this advice, and I expect to hear it repeated several times this week. Tweeting that will make me a faster fool too.

There are, however, some problems with this advice. A process defined completely in abstract, and devoid of any tool consideration, is unlikely to be useful. It will demand process steps that cannot be readily automated, or cannot be enforced through automation. Or it will demand complex configurations (or customizations) that make the tool brittle. It will ignore current state processes implemented in the tool and try to supplant it with something that is foreign.

We almost never define services devoid of any tool considerations.

The definition and improvement of the services and processes go hand-in-hand with the implementation and configuration of the automation. The industry calls it Continual Service Improvement (CSI), and it is important to get this right sooner rather than later. CSI is internal to the organization and very organic. It is not a binder delivered by credentialed IT Service Management consultants or the tool vendors.

The automation of IT service delivery and process execution is underway. It has been for several years, and new tools are appearing to make this easier and better. Publicly-traded BMC Software acquired Numara Software in February 2012. ServiceNow went public in June 2012.

Not only will the trend continue, it will accelerate. In fact, I believe the “Continuous Highly Automated Service Management” organization will require integrated automation that is several orders of magnitude more effective than today. Crossing that chasm will take a lot of work from vendors and their customers, and we have some hard problems to solve.

And yes, it will be outside-in, as well as outside-out, inside-out, and inside-in. In short, it will be awesome, but we will develop this theme in more detail later.

Key takeaways:

  • Get Continual Service Improvement right first
  • Improve services and process together with the automation
  • Automation of services and processes will accelerate non-linearly and disruptively (a chasm)
  • Steve

    It is ironic that process folks often downplay automation while one of the intrinsic values and, possibly, goals of service and process management is creating repeatable, governed processes that can be automated leaving management resources to move on to the next real challenge. Information technology without the technology piece is, after all, just information.

  • Steve

    And I certainly hope that ‘old colleague” simply means former!!!

  • Steve,

    You were allowed to remain silent and not incriminate yourself. 🙂

    You could always store information in paper forms, documents, and on post-it notes. Technology, in theory, can improve our ability to process this information. Unless we choose not to let it.