There are quite a few IT Service Management (ITSM) models out there -- those based on ITIL frameworks, for example -- that are intended to ensure stable computing environments that adjust to new conditions,
To read some information, one would assume that implementation of a formal ITSM model would be like killing a werewolf with a silver bullet; all it takes is saying ITIL, and magic happens. This is the vendor hype part of the IT Infrastructure Library -- and ITSM in general -- that can actually do more damage than good when it comes to outcomes. At some point, it becomes impossible to live up to the hype. I see a lot of opportunity to spend a whole lot of money on software and consultants, though.
Personally, I'm not sure that there is enough -- if any -- hard ROI for formal ITSM frameworks, particularly in smaller organizations. This is not to say that I'm necessarily against ITSM in some places, but it seems counterproductive to ram it down the throats of well-functioning IT departments that may not be fully operating under formal ITSM guidance. Frankly, a lot of what is included in formal ITSM is based around common sense, such as reasonable IT governance, reasonable change management processes, reasonable problem/incident/request management, and a desire to create an even better IT department that is responsive to the needs of the business and of the users.
ITSM seems to revolve around an attempt to resolve complaints about IT and business alignment taken to an extreme level, or to fix an IT department that is not responding to the needs of its users. I'm certainly in no way opposed to continuous improvement and being measured on results, but is implementing what can be a complex framework, that may or may not have a clear ROI, the right answer?
Let's take a look at just a few aspects of ITSM ITIL frameworks. I will be the first to admit that I'm looking at all of this in a very basic way:
- Incident management. Incident management's goals are to restore operations as quickly as
possible in the event of an incident and to minimize the business impact.
- Problem management. When an incident takes place, identifying the root cause of the
problem will help to prevent it from recurring. Most often, correlation of multiple related
incidents is used to assist in problem resolution.
- Single point of contact. The service desk, or what we used to call the help desk. This
is the point at which problems are reported to IT.
management. IT is all about change. Change management is focused on making sure that
changes to the environment don't have an impact on the normal operating environment.
- Configuration management. As items change in an environment, the new steady-state needs
to be recorded so that it can be measured and monitored.
- Capacity management. Ensuring that the IT environment continues to meet the needs of the
business and of users is essential.
- Financial management. This is the part of ITIL that dictates that the IT infrastructure be obtained at the most effective price. It should be noted that this doesn't necessarily mean that it's obtained at the cheapest price. From there, metrics are developed that help the organization understand infrastructure costs, and eventually distribute those costs to organizations that use the infrastructure.
All of these items are important to define in any organization that makes serious use of IT, but many of the ITSM models are frighteningly complex and get even more complex as they are refined and new editions released. For a great example of this increased complexity, look no further than ITIL v2 and ITIL v3. Of course, organizations can choose to adopt and adapt; that is, a company can adopt just portions of a complex IT Service Management strategy, and adapt it to specific needs.
Or, you can do what many organizations have chosen to do, and eschew rigidity in favor of custom internal policies designed to address what is important for your business. For example, rather than working through a brain-bending exercise in an attempt to determine the difference between a problem and an incident and associated service levels, you can choose to simply say that "IT will respond to new help desk tickets within an hour." For many small organizations, institution of a formal, committed service-level agreement (SLA) around help desk ticket resolution simply isn't possible. A formal commitment would create a need for additional resources to support that formal commitment, so some organizations are satisfied to forgo rigidity (a formal SLA) in favor of flexibility (i.e., workload shuffling to allow help desk staff address highest needs).
Most organizations by now have already established some kind of help desk, which can be equated to the service desk that is required in so many ITSM models.
Change and configuration management can be handled through simple processes that are already in place, without putting into place significant barriers to change. Configuration management should already be handled via documentation of changes that are made to the infrastructure.
What I'm getting at is this: In what way do your existing processes and services -- help desk, changes, documentation, assessment -- fail the organization? What will a new, and often complex and expensive, service management implementation bring to the table?
Before you jump in with both feet, make sure that you're not going to go through a lot of effort for little return.
This was first published in December 2010