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.

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

Predecessors/Before You Begin

ITIL defines the word "problem" very specifically. Learning about problem management should go hand in hand with learning about incident management.

Problem Management

Problem Management is the process of investigating the underlying causes of incidents. Problem management relies on three key terms:

My last workshop of the day was called "Improving the 'Best' of Problem Management," by Christopher Jones from MeadWestvaco. This was the second year he gave this talk--it was apparently very popular last year.

The two goals of problem management are to prevent incidents and to minimize unpreventable incidents. For them problem management means

* find the "true" root cause--for them, when you can no longer ask "why?"
* publish known errors
* select and implement solutions to problems (in conjunction with change management)