If a picture is worth a thousand words, imagine what a visual diagrams of your ITSM processes can do for your business. Visualizing processes offers significant value, particularly around communicating the what, who, who, how, when, where of activities, people, and systems involved. In ITSM, that value cannot be underestimated, especially when it comes to dealing with incidents.
In this article, we’ll take a look at mapping your incident management processes, including the benefits and four steps to success.
Benefits of incident management mapping
Incident management involves restoring normal service operation as quickly as possible in order to minimize the negative effects of outages or degradation. When you have an incident, your response is how you’re managing it—and processes make these easier to manage.
Mapping, or diagraming, processes makes your incident management successful. Mapping an incident must be done in a way that ensures the whole team is aligned, so your process results in enhanced repeatability and a consistent approach towards incidents. If mapping feels superfluous or unnecessary, consider some benefits of mapping your incident management processes:
- Easily determine responsibility and supporting roles
- Smoothly transition and train new employees
- Reduces confusion
- Build consensus across teams and departments
When you diagram these processes, you’ll get the biggest benefit: reducing the time and money spent on addressing incidents.
As much as mapping an incident can—and should—be a process, we must remember that not every incident will fit the “standard”, predefined model. For instance, where a new service or new environment is involved, or a security breach that hasn’t been encountered before. In this situation, mapping must consider provisions for dealing with deviations from the norm in a manner that is still controlled. This can include pointing to supporting processes or handing over to specialized teams who can swarm over the incident.
Mapping incident management processes in 4 steps
There are four main steps to consider in mapping incident management processes:
1. Gather information on the current environment
Before doing any mapping, it is important to identify the context in which the process is operating. Each organization has its own culture, systems, and structures, so it’s vital to start with by collecting information on the main aspects of incident management. These components would include:
- Current steps involved in identification, logging, categorization, prioritization, handling and, communication of identified incidents types
- Sequential information about those same steps, including dependencies and available options for deviation
- Roles and responsibilities involved with the process including individual and cross-functional units’ involvement
- Any predefined timelines for incident handling based on business objectives or contractual SLAs as well as information on thresholds that trigger necessary actions
- Any agreed framework for escalation in case of deviation from timelines, thresholds, or impacts that require action from higher technical or managerial levels
2. Identify and engage stakeholders
Alongside the information gathering activities, mapping is greatly enhanced when input from all involved and affected stakeholders is considered. Of course, it’s much easier to simply gather the information and draw the map—but then you’d have a significant gap in understanding cultural and systematic issues that prevail within the organization that impact how incident management is carried out.
For example, consider email alerts for critical incidents. Customers might not be keen on these, cluttering already full inboxes. But the service desk might be of the opinion that it’s the best way to track communication. Getting perspectives from all teams will help map a process that meets the needs of everyone.
In addition, internal or external customers provide the best view of the process from an outside-in standpoint. Customer needs and successes are heavily linked to their perception of how incidents are handled, particularly when it comes to touchpoints and moments of truth encountered during their interactions with service provider personnel and products. Getting their input is vital in ensuring that the mapped process is relevant to their needs and generates outcomes that meet their requirements and perceptions.
The same angle can be applied to third-party suppliers, particularly those who are heavily invested in the service provider’s operations. While their involvement may be ringfenced by the signed contractual obligations which are inextricably linked to financial and capacity limitations, their perspectives can be useful in understanding the most effective way of handling incidents escalated by the service provider that meets business outcomes and customer satisfaction targets.
3. Draw using standard notation
With the information in place and stakeholder perspectives gathered, the next step is to draw the process so that it’s understood by all persons involved. Adopting a standardized framework for mapping, such as ISO/IEC 19510 or BPMN v2.0, is best, especially when dealing with stakeholders who are unaware of mapping notation.
Start with an informal workshop, where all participants use flip charts, markers, and sticky notes to iterate to a final version. Then, formally document the final result using specialized mapping software, such as Microsoft Visio or online tools like Draw.io or Lucidchart.
This is where standard notation becomes useful in outlining where processes start and end, activities and tasks, decision or deviation points, and roles involved as shown in the example below. A cross functional flow chart is typically best for this work, but stick to basics and avoid complexity (e.g. crisscrossing lines, huge variety of object types, etc.) until all stakeholders understand mapping notations.
Basic incident management process map
The level of detail will vary depending on your target audience. If your diagrams are extremely detailed, it’s unlikely anyone will reference them. Instead, focus on simplicity. This simplicity will keep you focused on your real goal: ensuring all stakeholders agree and are clear on how incident management is carried out within your organization.
4. Optimize and customize accordingly
Once you’ve mapped the incident management process, use the map as your basis for continual improvement. Your improvement journey might include:
- Adopting best practices and international standards on incident management
- Deploying systems to support the process, such as:
- Knowledge bases
- Automated detection, escalation, and resolution
- Improving response and resolution timelines among others
- Reviewing regularly with stakeholders the mapped processes in order to:
- Identify bottlenecks and pain points
- Prioritize improvements aligned with the customer and business needs
Remember that the benefits of mapping are maximized when stakeholders reach consensus, on roles, activities, and metrics. This consensus contributes to alignment with stakeholder expectations.
