Do you really need all those cumbersome processes?

When we think about IT service management (ITSM) processes, we usually think about how we can standardise everything we do, to ensure that we use our resources efficiently and that everyone does everything that is needed. A typical process is designed so that everything will be handled the same way, every time, regardless of who is doing the handling. For example every incident should go through the same steps between being detected and being closed.

We sometimes modify the process flow a bit to allow simple things to be handled more quickly, for example a standard change may be approved without going through all the steps that would be needed for a radical innovation, but we basically keep the overall structure and workflow consistent.

The trouble with this approach is that it can lead to an excess of bureaucracy and actually end up making you less efficient. For example a change management process that was designed to protect legacy financial systems may be far too cumbersome for managing changes to a web site, which relies on different technology, has a different risk profile, and needs a much nimbler rate of change.

I have been involved in a number of discussions about how we could categorise IT services to help us respond to these different needs more appropriately. For example Gartner describes a Pace Layered Application Strategy which distinguishes between:

• Systems of Record. These support an  organization’s critical data and transactions. They typically have a low rate of change and may be subject to regulatory requirements.
• Systems of Differentiation. These support unique company or industry capabilities. They need fairly frequent reconfigurations to meet evolving business or customer needs.
• Systems of Innovation. These are often built or modified on an ad-hoc basis to meet new requirements or opportunities.

Another approach is to categorise systems according to a fairly simple system that accounts for the required confidentiality, integrity, availability, and rate of change.

• Level 1 – Needs high confidentiality, integrity and availability with a low rate of change
• Level 2 – Needs medium confidentiality, integrity and availability with a medium rate of change
• Level 3 - Needs low confidentiality, integrity and availability with a high rate of change

Clearly the terms high/medium/low need to be defined and understood in this context, but the idea is to recognize that there is a trade-off between rate of change and ability to protect the environment. This can help to facilitate a discussion between IT and their customers where the trade-offs are made clear and customers can take responsibility for the choice. (I did not include a service that needs very high levels of confidentiality, integrity and availability with a high rate of change as this would typically require a very specialized approach with commensurate high cost).

Some IT organizations have started to use classifications like this within their development departments, but I have seen very few IT organizations making use of these ideas to help them manage their operational processes – and I think this could be an opportunity for us to significantly improve.

People design a change management process (for example) for a “Level 3” service in exactly the same way as they would design a change management process for a “Level 1” service, despite the fact that they require different activities and workflows.  But a change management process that works well for “Level 3” won’t do a good job for “Level 1”. So why not design them differently and use two distinct processes, each of which is fit-for-purpose for the target environment? The same applies to almost every other aspect of ITSM. What sort of capacity plan do you need for a service that never changes and never grows? How does that compare to one that has frequent changes? Similarly you may decide that you need a well-crafted availability plan for your systems of record, but much less effort would be appropriate for your systems of innovation.

One area of ITSM where I have used this idea very effectively is in service level management. Reading the ITIL book could lead you to believe that you must spend months negotiating detailed service level targets for each IT service. In practice it is much more efficient to define 3 or 4 generic SLAs to be used as starting points. You can design your infrastructure and operations so that they can meet the requirements of these SLAs, and offer them to customers as standard. If a customer wants to negotiate something different then they can offer to fund what it would take to customise the environment to meet their specific needs.

If your customers –or indeed your staff –complain that your processes are bureaucratic and cumbersome, and you can see that they have a point, then why not start by identifying some services that would be better served by lightweight processes. You can then design some appropriate processes and pilot these with one or two services. You should find that you achieve a significant reduction in effort while any increased risk is focussed where it belongs, on those services where the customer wants innovation and high rates of change, and understands that increased risk is the downside of this decision. You should also find another benefit; reduced pressure on valuable resources, such as your Change Advisory Board (CAB) so that they can focus on the changes that really matter to the business.

 Picture credit: IvanWalsh.com