Incident Management Process

This process is defined as finding a workaround or quick fix whenever there are faults or issue in the system. Imagine that you are running daily jobs to populate your database and produce reports. It may happen that reports are not getting published as the database did not update; or due to an erroneous file, daily jobs are failing. These situations are called incidents, and the incident management process helps to find quick fixes or workarounds to fix these incidents in a minimum amount of time.

Incidents are classified as per priorities. Normally, a Priority 1 (P1) incident has 8 hours for resolution time, Priority 2 (P2) has 16 hours for resolution time, Priority 3 (P3) has 24 hours for resolution time, and Priority 4 (P4) has 48 hours for resolution time. As shown in Figure 5-1, there is an impact urgency matrix and based on that, the priority is calculated. There are serious service-level agreements between vendors and service providers for penalties whenever there is a violation of the time required to take care of incidents.

Solution Database – An Introduction

As seen in Figure 5-2, there are teams: Team 1 to Team 5, and they have used the same solution; however, each of them has taken a different amount of time to implement a solution. For example, Team 3 has used the maximum time to implement a solution whereas Team 2 has taken the minimum 1 hour to implement a solution. There are various reasons for variations in time differences for Team 2 and Team 3. In the case of Team 3, a solution did not exist, and the team was required to create such a solution and test it before deployment. In the case of Team 2, there was a system where reusable solutions were getting maintained, and therefore Team 2 was able to reuse a solution that had already been implemented; so that is why their resolution time was the quickest.

The secret of Team 2 in the implementation of a solution follows KM Practice. They were maintaining a database called a solution database where new solutions were getting stored, and existing solutions were getting reused when needed. Therefore, their resolution time went down.

In the upcoming section, we will design a Solution Database (SDB) and replicate this design in SharePoint Online for smooth functioning. To design, we assume that we are creating solution data for an incident management process so that there is a faster resolution time for incident closures, which will increase customer satisfaction.

Solution Database Definition

Knowledge Needs to Have a Solution Database

SDB Architecture

So far, we have seen the definition, objectives, and different knowledge needs of a solution database. For convenience, we will assume an existing solution database for incident management purposes, which will help us to understand more clearly, and readers are welcome to generalize for other purposes for their different knowledge needs. In this section, we intend to define solution database architecture more clearly to understand how we can create a new solution and reuse existing ones from SDB. Figure 5-3 is an overview of SDB architecture.

In Figure 5-3, we see a Solution Contributor or Solution Seeker access SDB to resolve incidents. In the case where a solution seeker discovers a list of solutions with the help of search, he or she is able to pick and choose a relevant solution from the list of solutions in the database. In the case where a solution does not exist, the seeker is encouraged to a create a new solution that gets reviewed from a SME before it is available for all users. Architecture of SDB is based on two principles of KM, that is, reuse knowledge and create knowledge.

Designing such architecture on SharePoint, then with Workflows, and now with Flows has become an act of simplicity with a default set of features available in SharePoint technology that facilitates the design SDB architecture.

Building an SDB

Now we have come to the crux of this chapter where we will learn to create and reuse solutions in a solution database for the incident management process. Again, for convenience, we will assume an SDB is for the incident management process, and solutions will be created to fix incidents in a timely manner. Let’s begin with creating a solution using SharePoint Online Forms that can be linked with Flows to trigger events and notifications.

It is very important that we a create structure that is easy to understand and convenient for adding solution details. Therefore, as mentioned in the above paragraph, we use forms to capture a solution and metadata about the solution. Figure 5-4 is an example of a form that can be used to capture solutions for the incident management process and is suitable for an IT service organization that specializes in application maintenance support for business. Let’s look at the form to capture incidents and fields used in the form. Solutions are stored in an actual SharePoint Online object called a list and are retrieved based on a standard or advanced search.

The search engine looks only for appropriate keywords in the field of Solution (Keywords) as seen in Figure 5-5. Fill in this field very accurately. Solution (Keywords) must contain all keywords listed in Figure 5-5 known by the user.

Figure 5-6 is an example of a solution created containing information updated in all fields. OSD stands for operation service desk, which is a ticketing tool where incidents or faults are maintained.

Searching an SDB

Now we know how to create solutions in a SharePoint-based solution database system. Let’s try to discover how we can search for solution in an SDB. The solution database allows the user to search for existing reusable solutions of incidents and problems. Figure 5-7 is example of s standard search.

The user can search for information by typing their keyword (e.g., SAPPORO) in the boxes present in Figure 5-7. The user will then view the list of solutions in the SDB with the provided keyword (Figure 5-8). The user can search for solution(s) by typing a reference ticket number from a ticketing tool or a description of the problem as the keyword.

Figure 5-9 is an example of an advanced search in an SDB where the user can search using parameters such as customer or factory or GPC.

If no solution is found (Figure 5-10), then solve the problem yourself and then contribute the solution in the SDB.

Reusing the Solution

Until now we have seen how to create a solution and search for a solution in an SDB. Let’s see how we can reuse an existing solution from the SDB. If a relevant solution is found, then reuse it (Figure 5-11).

Figure 5-12 shows this.

Ask the Expert

A solution database may not be the ideal to discover all solutions in an SDB. Therefore, Ask the Expert can help users to get to closer to a solution. Ask the Expert enables any user to ask and post any question or any official query in regard to the content of functional and technical issues. If the user has a query regarding a specific problem and can’t find an answer within a solution database, the user should use “Ask the Expert.”

If the query is new, then the user should select the New status (Figure 5-13). If it is an existing query that needs a more detailed response, the user should select Reopen as the status.

Experts view in the admin portal (only viewable by an expert) where all the questions/queries posted by portal users that are active and will be visible in this module for the expert users (Figure 5-14). A delete option will be provided as well. Expert users can edit any of the queries and provide answers for the same. The field names and their description will be the same for all the experts.

When a new query is raised, an email notification is sent automatically to the expert list of the respective factory. If there is any change in the status of the query, an email notification is sent to the experts and the requestor. If the problem is solved by the expert, the requester receives a notification that their query is answered and that they can look up the solution. Therefore, the requester has to go again to Ask the Expert and open the item. If the response is acceptable, the query is solved, and the status should be changed to Closed. If not, the requester should specify the problem and send the query again. The experts will receive another notification that they have to work on this again.

Besides that, it is always possible to reopen a closed query. In the field History, the query-response interaction will be generated automatically, including details about who edited the query and when. This responded to query should now be uploaded by the requester to the solution database.

Advantages of an SDB

Introduction to Communities of Practice

A Community of Practice (CoP) is a group of people who share a craft and/or a profession. The group can evolve naturally because of the members’ common interest in a particular domain or area, or it can be created specifically with the goal of gaining knowledge related to their field. It is through the process of sharing information and experiences with the group that the members learn from each other, and have an opportunity to develop themselves personally and professionally – Wikipedia.

CoP is an initiative that helps create and cultivate knowledge, thereby creating a knowledge-sharing culture in the organization.

Value of CoPs for Delivery Teams

A successful CoP initiative revolves around business value, community participation, increased knowledge, and improved capabilities as seen in Figure 5-15. Beyond this platform, content, people, and process are other important aspects for a CoP’s success.

Community Roles and Responsibilities

For a successful CoP initiative, there are designated roles that help community facilitation and attends its objectives. Below are the roles described in detail.

• CoP Sponsor is able to envision the purpose and vision of the community and also foresee the goals of the CoP over time, and should have a sense of how the CoP can interact across Capgemini.

• CoP Facilitator helps with building, connecting, guiding and facilitating the overall community.

• CoP Leader helps communicate the CoP goals and vision and provides continuous support for the community.

• CoP Core Group is a working group that helps with the CoP start-up activities and continues to provide ongoing support.

• CoP Experts are the SMEs within the CoP.

• CoP Members are the essence of the community as without them the CoP would not exist.

Communities Are Powerful Tools, As Long As You Put Members’ Needs First – Forrester Research. Below are some of the important things to keep in mind before creating a CoP.

• Clear purpose – What is the vision for the CoP?

• Creating a trusted and effective environment for knowledge sharing and collaboration

• Committed core group of active participants

• CoP members motivated to contribute to initiatives

• Knowing the needs of participants

• Having a clear action plan with activities to meet needs

• Blending face-to-face and online activities

Tools will be introduced at various phases to the CoP members (Figure 5-16).

Summary

With this, we have come to the end of the chapter. In this chapter, we have taken a deep into a SharePoint-based system such as Solution Database; Ask the Expert; and a cursory overview for Communities of Practices, which will help to execute KM initiatives in a collaborative way using SharePoint Online technology. In the next chapter, we will focus on the use of Artificial Intelligence in strengthening CX.