One of the fallouts of ITIL V2 was the seeming rush to establish new positions in the organization to align with the ITIL processes. Naming an Incident, Change or Service Level Manager was a clear-cut directive. But do we really need, and can an ordinary organization really support, a full-time Configuration Manager or Availability Manager?
ITIL V3 very clearly delineates how the ITIL processes work within the boundaries and responsibilities of the organizational structure by defining the Functions that perform the activity, the Process that may extend across several Functions to accomplish the objective of the activity, and the Role that an individual within a Function plays when performing a Process.
Many people, when first exposed to ITIL and its concepts, start thinking about how they might reorganize the IT department around the ITIL processes. Let’s explore the relationship between functions, processes and roles.
The term function refers to a group of people often aligned by a particular technical skill or technology, such as system administrators, or Java programmers. These functions or technical functional areas carry out various processes or activities.
A process, on the other hand, is a set of structured activities that achieve some specific goal or objective, such as restore a service or find a problem. A process may involve the participation of many functional areas to accomplish its objective. The staff members of the functional areas perform the process by carrying out the responsibilities of various roles assigned to them.
Processes, in fact, often cut across many functions, involving many different staff members, each carrying out their roles. So, in order to implement the ITIL processes, it is really not necessary, or desirable for that matter, to try to organize the processes as functions.
For example, let’s look at an imaginary scenario involving a broken printer, and classify the mix of Functions, Processes and Roles that contribute to moving an Incident through diagnosis as a Problem, development of a Workaround, and implementation of a Change.
Step |
Function | Process | Role |
User A calls the Service Desk to report that a printer is not working. |
Service Desk | Incident Management | Incident Recording |
The Service Desk begins following the Incident Management process to restore the user to service. |
Service Desk | Incident Management | Incident Classification |
Shortly after User A calls, Users B, C, D and so forth, call to report the same Incident. |
Service Desk | Incident Management | Incident Classification |
The Service Desk escalates the Incident to the Technical Support group for resolution. |
Service Desk | Incident Management | Incident Escalation |
The Technical Support group determines that there is an unknown underlying error causing the printer failure and opens a Problem record. |
Technical Support | Problem Management | Problem Control |
The Technical Support group knows that it will not be able to restore the printer to full service within the time frames specified in the Service Level Agreement and notifies the Service Desk that it will redirect all print jobs to a different departmental printer. |
Technical Support | Incident Management | Incident Investigation & Diagnosis |
The Technical Support group troubleshoots and diagnoses the Problem and determines that it must update the patch level on the server. The patch upgrade requires a server reboot. |
Technical Support | Problem Management | Error Control |
The Technical Support group closes the Problem record and opens a Known Error record to document the error. |
Technical Support | Problem Management | Error Control |
The Technical Support group issues a Request for Change to make the patch change. |
Technical Support | Problem Management | Error Control |
The Change Advisory Board reviews the RFC and determines that the server will have to be rebooted during normal working hours. |
Change Advisory Board | Change Management | Assessment |
The Service Level Manager, who sits on the Change Advisory Board, contacts the User representative and clears a specified time for the patch upgrade and reboot. |
Service Level Management | Change Management | Planning & Coordination |
The Change Advisory Board adds the patch upgrade and reboot schedule to the Forward Schedule of Changes and Projected Service Availability report and forwards them to the Service Desk. |
Change Advisory Board | Change Management | Planning & Coordination |
The Service Desk communicates the forthcoming change and period of unavailability to the appropriate Users. |
Service Desk | Incident Control | Communications |
At the specified time, the Technical Support group installs the patch, reboots the server, and verifies that the printer is working. |
Technical Support | Change Management | Change Building |
The Technical Support group returns the completed RFC to the Change Manager |
Technical Support | Change Management | Post-Release Technical Review |
The Change Manager closes the change and informs the Service Desk. |
Change Management | Change Management | Closure |
The Service Desk verifies the printer is working with the User and closes the Incident ticket. |
Service Desk | Incident Management | Closure |