This week I have been taking the Operational Support and Analysis support ITIL capability module class from taruu.com. This class essentially covers Service Operation. Specifically, the main areas include event management, incident management, request fulfillment, problem management, access management, and the Service Operations functions such as the Service Desk.

One of the neat things about the second-level classes is that they can focus more on how to apply ideas. The class is primarily exercise-focused rather than lecture-focused: for example, we roleplay how you would talk with a CEO about Service Management. The classes are almost as much about leadership and presentation as they are about the material.

Information technology service management is the practice of managing an IT infrastructure by employing a service-oriented perspective. A best practice framework known as ITIL offers guidelines on how to manage an IT portfolio by viewing it as a collection of services that provide value to customers. ITIL orients its guidance around the lifecycle of a service beginning with conceiving a strategy, followed by designing the service, and subsequently transitioning the service into an operational mode.

People talking about "Lean" principles can mislead their audience, because often "Lean" to the speaker means something very different (e.g. that "Lean" means holding kaizen improvement sessions, and that's it). So, take what I'm going to say with a bit of salt, because I have no Lean credentials.

In reading about Lean manufacturing (through "Lean Thinking," "Getting the Right Things Done," and now "Learning to See"), I have been working through how Lean concepts might apply to an Information Technology environment. One of Lean manufacturing's focuses is to create pull-based processes that minimize inventory on-hand, for example. By minimizing inventory you free up cash for new things and can respond more quickly to changing demand.

So--how does this relate to IT? Inventory, in a value-stream mapping, is the stuff waiting between groups. The two ITIL processes that seem to relate the best to the inventory concept are incident management and request fulfillment. Here's my thoughts:

Below are notes from today's itSMF USA Higher Education SIG round table conversation.

Please see Kathy Reid's blog entry, "The benefits of describing ITIL incidents in object-deviation format."

Many tools and methods can support incident management and problem management. The "Ishikawa Fishbone Diagram" comes up often in problem management, as a way to graph and define root causes. Kathy Reid's post discusses the "Kepner Tregoe" method (which I'm not familiar with myself).

Essentially, the technique she mentions is to describe an incident as what is different than the expected results. This reminds me of one definition of quality, as "conformance to requirements." When there's a deviation, that means there is a reduction in quality. Defining the incident principally by the deviation seems like a quick way to isolate the issue as well as to provide data for problem management later.

Before I learned about ITIL, I was a system administrator trying to figure out how we could "do things differently." It seemed like we were doing the same work that a bunch of IT shops were doing, and maybe there was something already written that we could learn from.

One of the books I found was The Practice of System and Network Administration, by Tom Limoncelli and Christine Hogan. (Since then, a second version of this book has come out.) It's an extremely thorough introduction to the "soft topics" of systems administration (and it gets points for being written in LaTeX).

If you're going to itSMF USA Fusion 2008, they're holding the "3rd annual itSMF-USA Academic Forum" on the Saturday and Sunday before the conference begins.

Predecessors/Before You Begin

ITIL makes a big distinction in vocabulary between an incident and a problem. Please keep in mind these two are different: a problem is the unknown, underlying cause of one or more incidents.

Incident Management

Grisha Alpernas from the city of Portland, Oregon gave a great presentation called "How did it happen that we did something right (without even knowing it)?"

Portland centralized IT in 2001. Their old IT system (structure etc) was bad and they had to throw it out. They re-organized into three areas: the service desk (inter-active), technical services (pro-active), and technical support (re-active). In one year they reduced their staff by 17% and their managerial staff by 25%.