Event, incident, and problem management

Peter Strempel

My experience has included the design and implementation of ITIL-aligned processes to apply to a service desk, a configuration management database (CMDB), and related processes for event, incident, problem, and change management.  They are necessary basic components without which ITSM becomes difficult.

At this point it is worth noting –

  • A service desk need not be an actual call centre. It is just the point at which support requests come into a management system.  The detail to be recorded has to allow for later reporting on incidents by systems affected, by user groups affected, by frequency of problems experienced, and by the magnitude of the problems experienced.
  • The CMDB is an information repository that holds details on all configurable IT assets and items.  This includes hardware and software, but also contracts, service catalogues, SLAs, licenses and other documents governing IT services and support.  The service desk and CMDB might the same piece of software, but what’s important is the capability of creating reports across and between all types of information.
  • Event management is in fact just a component of incident management.  The rôle and purpose of event management is likely to have greater relevance to larger organisations, or IT-focused enterprises.  It concerns principally automated monitoring of all configuration items and services, a triage of any alerts to focus on raising alarms for human intervention, and the recording of event management and closure.  This is a bit like setting up logging services in software to flag selected events for alerts sent, for example, to email and phone alerts, and the system used for incident management.

Incident and problem management are more directly user-focused, with incidents most likely being reported to, and resolved by, a service desk.  Analysis of incidents revealing patterns of related incidents usually signal one or more specific problems for resolutions by higher-level technical support or system development resources.

Figure 1 below shows a hypothetical incident management process.

Incident management
FIGURE 1: capturing information about incidents is as important as resolving them.
  • Incidents can include events, such as server/cloud downtime or heavy loads and waiting times for accessing certain systems.
  • Incidents also include all support calls to a help desk.
  • The incident management function must include capturing enough detail to identify precisely what configuration items (IT components, contracts, licenses, etc) and user groups are affected (training, localised infrastructure).
  • Incident management includes on-the-spot troubleshooting with the aim of resolving a service disruption, and, if it cannot be immediately resolved, escalation according to an applicable service level agreement, or according to some other known method.
  • In many cases escalation can also be via technical hierarchy to second or third level support teams.
  • Important to the ITIL framework is that incident management includes enough logged information to permit reports to be generated that can list incidents by frequency, by affected systems, and by affected users. That is the basis for problem management, and leads onto change management.

Problem management is the systematic analysis of the most frequent incidents, or emerging patterns of events and incidents, to eliminate the underlying causes for service disruption.  Figure 2 below shows a model problem management process.

FIGURE 2: a simplified problem management process map.

Where an organisation is large enough, a dedicated problem manager with excellent analytical ability and wide technical skills should spearhead problem management.  The rôle requires access to all incident and problem management information already gathered, but also to details of change and project management information that might relate to causes for underlying problems.

In larger organisations, immediate resolution of problems might lead the problem manager to form ‘Matrix’ or ‘Tiger Teams’.  Such teams come together temporarily, with membership drawn from across the organisation, and perhaps also from vendors, to bring together the expertise needed for rapid analysis and resolution of a particular problem.

A problem manager may also determine that a formal development or change project is needed to resolve underlying problems.  This would trigger entirely separate processes for project and change management.

Often the root cause of problems is a previous change with inadequate testing or evaluation processes.  It is therefore important to conduct problem management in conjunction with analysis of information about project releases and formal changes listed in the change register.

I examine change and project management in their own set of pages, as disciplines quite separate from ITIL.

If any of the methods and techniques I have mentioned here strike you as useful to your organisation, I’d welcome an opportunity to discuss your specific requirements.

What you can expect from me as your ITIL consultant is the experience to make sound judgements about matching your business objectives with ITIL principles to help minimise costs while adding value to your operations.  My judgements in this area are grounded in hands-on experience with ITIL transformation projects, and my full range of skills in designing and implementing architectural, business process management, and IT projects.

Use my email form here to get the ball rolling by summarising your details and your needs.