The four pillars of IT Service Management

What does ITSM require?

I propose these four pillars:

1. A service-focused view of IT. This means that the end service as the customer experiences it is paramount. Not the server, not the network, not the database, not the software - no more finger-pointing. This is not a hard concept; technologists can understand it as anologous to contract-specified interfaces on a component. The implementation (or the sourcing) can vary as long as the contract is fulfilled.

2. Process orientation. What are the measurable and repeatable activities? How well do we understand them? Are we continuously re-evaluating them for efficiency and effectiveness? What capabilities and functions must support them? What activities do we have that are not easily measurable, yet still apparently critical?

The above two concepts are broadly accepted as essential to ITSM. I propose two more:

3. Master data management. Just as my business customer understands their systems of record for Products, Customers, Locations, and Accounts, I need to clarify my systems of record for Servers, Databases, Applications, Services, Projects, Programs, Service Requests, Incidents, Problems, and Changes. Do I have multiple systems trying to house essentially the same data, perhaps under differing names? Am I allowing the same data to be updated in multiple locations? Do reports across my IT Service Organization agree?

4. Well-architected internal IT. Do I have outdated or poorly maintained ITSM systems (change, incident, project, portfolio, configuration management, monitoring, service request management)? Spreadsheet-driven processes? Redundant systems? Manual or non-existent integrations across systems that really should be sharing data or services?

There's much to be done in any ITSM initiative but considering it from all four of these dimensions may be useful.

Cheers,

Charlie 

Comments

[Damon Edwards]

Really interesting post. It got me thinking and turned it a post of my own:
http://dev2ops.blogspot.com/2007/10/knowing-where-you-are-going-identifying.html

When I read through your pillars the idea of a maturity model came to mind. I admit its bit loose, but I see it progressing something like this:

First you wake up and realize that you operate software as a service. This often results in a bit of an upper management hand-wave, but none the less, it's a critical step because it means you recognize that you have to change how your organization runs. (Pillar #1)

Then you realize that the service lifecycle actually cuts across many different disciplines and you need coherent processes that span them all. Once you have those processes defined you also need to know how to measure their effectiveness. (Pillar #2 and #3)

Finally you need to bake those processes and methods of measurement into your IT systems (Pillars #3 and #4)

Note: Pillar #3 is the linch pin between #2 and #4.