It’s Tuesday, and your manager has just called you into the office. “We are appointing you to a new role within the IT support team. I would like to you to be the incident process owner.” After a moment of shock, surprise, and excitement all at once, you listen to the details and how your manager views the importance of the position and the major goals and objectives of putting you in charge. “Do you have any questions?” You pause…“No, thank you so much for your confidence in me. I won’t let you down.”
Now what?
Moving into a new role is challenging enough. As the incident management process owner, you will be responsible for getting a cross-functional team to believe in the importance of managing customer expectations, work together to drive a reduction in incidents, and improve response times—not to mention driving consensus and adoption of managing from a service perspective. No big deal, right?
One technique to drive change is to map out the incident process. The goal is to identify what steps are essential and get consensus for a new closed-loop process that is measured and managed to deliver better results. But a process mapping exercise has very little to do with actually mapping the process steps. Process mapping is a tool to drive sustainable organizational change. If you want your manager to be impressed, follow these steps for mapping out the incident management process and take the first steps to drive real organizational change that sticks.
Let’s begin by asking a series of important questions that should be your first initial point of action.
What Role Will You Take in Driving Change?
A successful process mapping project requires participation at many different levels within the service delivery organization. To determine who needs to be involved, identify the way that incident tickets or requests flow today. The key roles include the process owner, the IT functional unit managers (such as networking, data center, desktop), and management.
Management Commitment
When your manager asked if you had any questions, you should have responded with “What role will you take in driving change?” A manager who recognizes the importance of having a role dedicated to the success of managing incidents should also be ready to act and support the organizational transformation that needs to occur. A manager’s support is vital to the participation of the cross-functional team and eliminating barriers to the adoption of a consistent incident management approach. The first step to being successful is to identify what you need from your manager.
Establish a Transformation Team
Successful change in the iterative process of managing incidents requires that a broad cross-functional team identify what is not working, what does work, and ways to innovate to drive higher levels of success for the business. Don’t make the mistake of going into your office and mapping out a “perfect” process and bringing it back to the team and telling them that this is the new and improved incident management process that the organization must adopt.
For real change to stick, everyone who works with incidents today must buy in to doing a new process. The cross-functional team must air out all the dirty laundry to change behaviors. Where is the dysfunction today? Which contributors lack trust in the process? In the background, it is the organization’s dysfunction that attributes to failures in the process. When you successfully uncover the pain points, you are going to open the door to overcoming the dysfunction and move closer to developing work methods that serve the business and not processes meant to control the dysfunction.
Own the Process
IT service management defines the process owner’s role outlining all your new accountabilities and responsibilities. But when it comes to mapping a process, the most critical skill is negotiating. The current process is probably broken, over-engineered, or driven by your service management tool. But it is an established process, and people are following it in an ad-hoc fashion. Your job is to streamline the activities of nearly every functional unit in IT in a way that everyone is happy. You will need to compromise, add steps to solve the conflict between teams, and at just the right time, remind everyone that you are trying to provide a better service to the business.
How Do I Map a Process?
Once you have established a cross-functional group and secured buy-in at all levels for improving incident management, the next thing you must decide is what method and tools will you use to map the process.
Choose Your Method
While there are many different techniques for mapping a process depending on what you are trying to achieve, the incident management process typically uses two methods to map the process: Top Down Flow and Cross-Functional Flow.
Figure 1: Top-Down Flow
The top-down flow (Figure 1) is a fundamental mapping technique that is used to map the sequential steps from the top of the page to the bottom. The method allows for simple branching and looping, and it is easy to understand.
Figure 2: Cross-Functional Flow
Notice however that the functional flow can also show the sequence of events and identify roles and responsibilities for each step in the process. If your organization is struggling with accountability and lack of trust, the cross-functional flow (Figure 2) will not only help you achieve a better process design, the method will also help to eliminate conflict and define clear responsibilities.
Choose Your Tool
Two tools that are widely available are PowerPoint and Visio. There are many other mapping tools available. Remember that the tool is for depicting the agreement of the decisions of the cross-functional team. You don’t want to get caught up in finding the right tool because mapping the process is more about the people and the cultural change and less to do with the process diagram that is created. Visio does without a doubt make it easier to create and manage changes to cross-functional flows.
Identify Functions
Incident management is a process that flows across functional lines in an organization. The cross-functional team that should be responsible for engineering a new process must have representation from all functional groups within IT. Figure 3 represents a typical structure. In this case, representatives with authority to make decisions should be selected from the infrastructure, application development, operations, support, security, and client/server units.
Figure 3: Functional Units in IT
Map the Functional Flow
A functional flow maps the high-level flow of information across the key stakeholders and provides a starting point for understanding the customer’s relationship with the IT functions. Additionally, the functional flow defines the relationships internally within IT. If we can collectively agree on the overall flow, then mapping the sequence of events within the flow will be much easier. Figure 4 shows a sample functional flow.
Figure 4: Sample Functional Flow
Map the Incident Management Process
Once the team has decided on the high-level flow, the work can begin by mapping the specific steps in the process. The icons used in the process flow all have a particular meaning in addition to what is accomplished within the step. Using the right symbol is important. Figure 5 and Figure 6 show the most common symbols used in the incident management process.
Figure 5: Common Symbols
Figure 6: Using Arrows
Begin mapping the process by creating a lane for each functional group. The process begins with and ends with a terminator. As roles and responsibilities change, the process symbols will move to the responsible functional group as shown in Figure 7.
Figure 7: Swim Lane Assignment
Figure 8 shows the first page of a typical incident management process. Notice in the example, a tool lane shows how the technologies are used to support the process. The figure shows the customer experiencing an outage and contacting the support organization through the telephony systems and connecting with the first available technician.
Figure 8: Incident Management Process Sample
Don’t forget to create a key and track all the symbols, abbreviations, and custom icons. Be sure to provide a description, agreed to by the process team, for each of the icons used. Figure 9 shows a sample process key.
Figure 9: Sample Process Key
Wrapping Up
Finalize the flows that are developed by getting consensus from the cross-functional team on the new way to work together to serve the customers. Work with the system administrator of the incident tracking system to make the changes as needed to support the new process. Conduct awareness training within each of the functional areas and make the process documentation available to the broader IT organization.
Remember the goal of mapping out the incident management process is not about pretty pictures and process flows. Mapping the process is about creating accountability, clearly identifying roles and responsibilities, and getting the organization to work together to provide the best service possible to the customer. Once the organization agrees to work together in a more effective and streamlined way, the IT organization can better establish and manage customer expectations.
As the process owner, it is also critical to identify a clear measurement strategy that provides feedback to the functional teams on how well the process is working. The reports will not only help to ensure process adherence, but measurements can drive continuous improvement and demonstrate the value delivered to the customer. Being a process owner is a great role to begin moving up in the IT organization. Your success depends upon your ability to negotiate across a diverse team of managers who have other goals and objectives. Use mapping as a tool, not as a control over organizational dysfunction and you will be successful in your new role.