ITIL Implementation - Process Interfaces
| diese Seite auf Deutsch |
|---|
Step 6: Definition of Process Interfaces
As the next step in the design of an ITIL-compliant IT organization it is determined which inputs each process receives from other processes, and which outputs it must produce so that subsequent processes are able to function.
These inputs and outputs are also called ITIL information objects: Structured sets of data, like e.g. an Incident Record, which serves to describe a Service Request or Service Interruption.
Just how great the importance of process interfaces is for the design of optimal work procedures frequently becomes apparent during the analysis of as-is Processes:
Weaknesses in processes often occur at those points where one process ends and another one begins. In many cases one will find interrupted information flows or media breaks – so that the required information is not exchanged as intended.
For this reason, the definition of the process interfaces is taken care of as a separate project step, before dealing with the innards of the processes in detail. Obviously, before being able to define the detailed activities, it must be clear what inputs a process can expect from preceding ones, and which outputs it must produce.
Objective of this Project Step
- Definition of the interfaces for the Service Management processes which are to be introduced
Prerequisites
- Structure of the Service Management processes to be introduced
- Process overviews (process breakdowns)
- Structure of processes of the entire IT organization
- ITIL information objects (ITIL glossary terms) as in-/ outputs
Results/ Deliverables
- Interfaces of the ITIL processes to be introduced:
- with each other
- with other IT Service Management processes
- with the other processes within the IT organization and beyond it
Description
The previously developed process structure is used as a basis for modeling the process interfaces. Information objects serve to define the in-/outputs in a precise way. The Process Owner can thus easily and at a single glance recognize which inputs he can expect from other processes, and which results his own process must deliver.
The information objects being used to specify the interfaces may be selected from an ITIL Glossary.
A challenge during the definition of the interfaces lies in the fact that, as a rule, not all ITIL processes are introduced simultaneously; it is also often necessary to integrate inputs from processes that are outside of IT Service Management.
For example, an IT Security Management process could not yet be explicitly defined – nevertheless the Service Desk still requires inputs from Security Management, like Security Alerts, to be delivered via a clearly defined interface.
In order to circumvent this problem, which inevitably springs up during a phased introduction of IT Service Management, a generic process directory for the IT organization as a whole can be used. An example derived from ITIL, COBIT and ISO 20000 which will be applicable to the majority of IT organizations is available here for download. Uniform Process Structure for the Entire IT organization).
The generic directory offers a framework for the definition of interfaces, even if process details are not yet known.
In our example, the IT Security Management process from the Uniform Process Structure can be used as a placeholder when defining the interface between Security Management and the Service Desk, even if the underlying process details will only be defined some time in the future.
This approach has the advantage of pro-actively ensuring a long-term consistency in the entire process model of the IT organization, and be aware of missing links between processes.
Even so, the missing link between the Service Desk and Security Management is still real, and a workaround must be found. One possible way to fix the problem could be a preliminary agreement with an existing Security Administrator, who will agree to provide the Service Desk with all relevant security information.
If no such solution can be achieved, the interface in the process documentation is left open – and must be highlighted as non-functional in the interface model.
Success Factors
- It must be avoided that the newly introduced processes represent an isolated solution; the interfaces to the other processes within the IT organization and beyond it must therefore be considered.
- The documentation of the interfaces should be clearly laid out, in that it is hierarchically structured and details are only shown when required. Thus it will be possible to grasp the great interrelationships between the major processes at a glance, while being able to zoom in on detailed data structures at the interfaces if necessary.
Following Process Activity
Step 7: Establish Process Controlling
