Smaller IT organizations can build efficiencies with their eyes closed. It’s the large organizations that have the most to gain … and the most to lose, in the land of “process standards”.

If you are a large IT organization, effective alignment to ITSM standards will make it possible to support your internal investment decisions with real data.  In this case I’m talking about ITIL, or COBIT or any of the relevant ISO standards.

If you define your services (no small task), and build the agreements that enable those services – based on a standards model – you’ll be miles ahead of the pack in finding new ways to gain efficiencies or achieve greater levels of effectiveness. Your IT organization can navigate the rushing-waters of day-to-day business and also make the jump to building greater value by evaluating your IT Service CPRs (costs, performance and risk metrics) or comparing the CPR between services that are competing for scarce resources in your company.

There’s plenty of fodder out there to build a slide deck with “cost per incident” data that speaks to the benefits of effectively managing an incident life cycle or establishing the governance over IT changes that will effectively mitigate change-related risk. However, unless you have already “drunk the ITIL kool-aid” remaining focused on the incident-management model is not enough to demonstrate the value of aligning with a best-practice reference model.

We call it SERVICE management for a reason. While ballooning support costs and inefficient incident life cycles are significant challenges for a large IT organization, the focus needs to be on defining services and letting those definitions drive the value-proposition behind a better alignment to standards.

There are two reasons for this:

1. If you fully understand a service, you can identify the tech assets that support it. Those assets become the Configuration Items (CIs) destined to be included in a Configuration Management database (versus just including all assets) Transition processes (i.e. Change, Release) should only be concerned with CI impact. Incidents should be related to CI’s and therefore, services. If you don’t define your services… you can’t relate an incident (change, or problem) to a specific service.
2. If you document a service… you can quickly calculate:
• The Costs required to maintain that service,
• A consolidated Performance metric, by aggregating the performance of all associated CI’s,
• And you can “Risk model” all the gates in the service.

For example, if we define “documenting a service” as producing a complete, annotated work-flow diagram, isolating all stage-gates and stakeholders, we can then establish operating level agreements (aka: MOUs) with the owners of each gate, and then we will have the information we need to build the “service capability” portion of a service level agreement.

• With this information we can produce reasonable estimates of all associated costs (Note: the biggest bit will be the associated salary proportions).
• Use a standard measure to gauge performance (i.e. time. Read: how long does a transaction take to complete the work flow?).
• Now look towards any decent risk-register model (google “risk register”… there’s a wealth of examples out there) to document the associated risks and issues.

Now armed with Cost, Performance and Risk data… you are well positioned to compare a service to itself over time, or to compare one service to another.

Imagine being able to present Cost, Performance and Risk data on all the services that IT offers the organization. This is a decision-support gold mine!