‘This stuff makes the most sense of all this stuff.’ – ITIL Foundations student
This comment was made by a student in one of my ITIL Foundations classes, and it was a reasonable statement because he made it while we were covering Service Operation.
Service Operation is the ITIL Lifecycle phase that is most immediately familiar to the majority of the front-line IT staffers who find themselves in an ITIL Foundations class.
The core processes included in the Service Operation volume have roots in earlier versions of ITIL. One of the things we emphasize at Service-Catalyst is the development of a management system that relies on well defined process integration.
To describe the integration of the Service Operation processes, the old ITIL v2 Service Support book did a very clear job of making the interconnections between the core Service Operation processes clear.
The triad of the Service Desk function and the Incident and Problem Management processes formed a section of the ITIL (v2) Service Support volume. Collectively they were referred to as ‘Support and Restore.’ You used to be able to take a Practitioner exam on these three processes and become a Certified ITIL Support and Restore Practitioner.
Now, aside from the interesting history lesson, I think it can still be helpful to begin with this triad in understanding and applying the Service Operation concepts from the ITIL v3 lifecycle.
In the classic model Problem Management was the ‘parent’ or ‘controlling’ process of the Support and Restore triad. We used to visually demonstrate this oversight role of Problem Management like so:
What this meant was that Problem Management had oversight of the Incident Management process. According to the pure model every workaround or solution applied by Incident Management to resolve an Incident was vetted, tested and approved by Problem Management. In a flow-chart it would look something like this:
‘Wow, something like that could really help us.’ – (a different) ITIL Foundations student when I drew this up on the board.
Now, you, who have read the v3 materials, might object at this point and state that this is properly the function of the Knowledge Management process. This objection would be correct. But if we go back to the ITIL v2 Service Support outline, as indicated in the graphic above, Knowledge Management was originally a sub-process of Problem Management.
One of the things that the v3 refresh did was to break sub-processes, such as Knowledge Management, out more clearly. Knowledge Management thus became a much more comprehensive and useful process.
One cost of this, however, is that we have lost track of the immediate oversight role that historically was provided by having Problem Management, using what was the sub-process of (a simpler) Knowledge Management, play the role of controlling process for the Support and Restore triad.
In my unscientific experience most organizations who are ‘doing ITSM’ never really get to Problem Management. The immediate focus is on fixing the ticketing system and getting the Service Desk squared away and getting everyone on the same system for tracking Incidents. The immediacy of the break-fix backlog takes up all the project mind-share.
However, it’s not necessarily such a big step to get started with Problem Management and using it a systematic way to review the workarounds and solutions that are applied in the support environment is an excellent way to get started.
Our next article will offer some further thoughts about getting started with Problem Management.