KPI: Event Management

KPI Definition	Unit of Measurement	Frequency	Remarks
Percentage of incidents logged using automated tools	Percentage	Monthly / Quarterly	This KPI measures the effectiveness of monitoring tool.
Number of events per category	Number	Weekly / Monthly / Quarterly	This KPI measures the number of events reported by monitoring tools. KPI can be reported based on category of the event (category (informational, warning, exceptional).
Number of events per CI	Number	Weekly / Monthly / Quarterly	This KPI highlight the top 10/25/50 CIs that that report the maximum number of events.
Percentage of events that resulted in incidents	Percentage	Weekly / Monthly	This KPI highlights  the number and percentage of events that resulted in an incident

Key Performance Indicators

Key performance indicator or KPI is a performance measure that is used to evaluate, manage and report the performance of a particular activity, process or organization. Typically performance is measured as efficiency and effectiveness (including cost effectiveness).

How To Define KPIs?

Any activity would be able to showcase benefit to the stakeholders only when it is mapped to the vision. Following is the approach to define KPI and eventually measure it.

The vision statement articulates what it is the service provider aims to achieve. Vision statements look at a desired state that will be achieved at some time in the future.

Mission statements articulate the basic purpose and values of the organization and its operation. Mission statements are more about how the organization will make its vision a reality.

Step 1: Define Vision

Organization’s vision defines the direction that an organization would take, the eventual future state that organization wishes to achieve.

Step 2: Define Mission

Mission defines the very basic purpose of the organization and it values. It articulates how the organization intends to realize its vision.

Step 3: Define Goals

Organization achieves the defined mission by defining the goals. Goals would be defined as short – term goal (typically for 6 months to 1 year or may be for a lesser period) and long term goals (typically 3 years or more)

Step 4: Define Objectives

Goals are further broken down into what can be termed as Objectives; the way these objectives are achieved would determine how effectively the goal is achieved.

Step 5: Define CSF (Critical Success Factors)

CSF defines the critical factor or activity that would determine the success of an objective.

Step 6: KPI (Key Performance Indicators)

KPIs are the indicators that are used to define the success of CSFs

Step 7: Metrics

The data points that are used to calculate the KPI. Metric has to be Specific, Measurable, Achievable, Realistic, Time bound.

Step 8: Measurement

Capturing the metrics

KPI Categories

KPIs can be categorised as:

• Actionable indicators: KPIs that are under organization’s control
• Directional indicators: KPIs that reflect improvement or degradation in performance
• Financial indicators: KPIs that reflects financial performance
• Input indicators: KPIs that measures amount of input resources (typically input for any process)
• Output indicators: KPI that measures output of a process
• Leading indicators:KPI that can predict the future outcome of a process
• Lagging indicators: KPI that represent the success or failure after an activity or process is executed
• Process indicators: KPIs that measures efficiency of a process
• Quantitative indicators: KPIs that can be represented as a number
• Qualitative indicators: KPIs that are qualitative in nature and cannot be presented as a number

3 Key Pitfalls To Avoid When Defining KPIs

@ Defining too many KPIs - Relevance and use of a KPI should be understood before defining the same

@ Defining too many metrics for a KPI

@ Having too many financial KPIs that highlights past-performance (a balance should be maintained by having KPIs that help in predicting future performance or provide an insight of the same)

My next series of posts would cover sample KPIs for key ITIL processes

Issues Facing ITSM Industry

Issues Facing ITSM Industry can be classified under the heads of 4 Ps of ITIL:

People: 

• Extreme internal focus of IT and lack of business understanding. IT is often not able to demonstrate value to business. 
• People need to engage more with business. 
• Communication with business needs improvement. 
• People need to constantly improve the quality of their work and deliverables.
• In many cases lack of leadership capability is having an impact on transforming and professionalizing IT so that new behavior (expected from ITSM process adoption) is embedded in the organization. Lack of management support is also resulting in poorly adopted process culture (or no process culture at all). 

Process: 

• More focus is required on customer interfacing processes and demonstrating ‘value’ from these processes. 
• More focus is required on integration of processes such that benefits are maximized by implementing various processes including ITIL. 
• Theory of adopted frameworks (ITIL, PRINCE2, COBIT, etc.) is not being translated into practice. It has been observed that in many cases the expected value from adoption is often not realized. Organizations refer to ‘implementing’ or ‘installing’ frameworks as opposed to realizing a behavior change.
• Business demands and IT technology capabilities are in constant change. IT lacks the capability to be flexible and ensure continual alignment to business demands. Continual Service Improvement (CSI) is often not in focus when adopting and deploying frameworks. There needs to be more effort and energy in embedding CSI in the culture and behavior at all levels in the organizations. 

Product:

• Need for automation of management, control and facilitation of knowledge capture and sharing.
• Tools are not being adequately used to enable people and processes which can help in greater value creation.
• Tools for strategic processes need to evolve to effectively address the demands of strategic layer of the organization 
• BYOD is becoming a norm globally. ITSM processes have to evolve to effectively address the resulting concern areas. 
• Rapid technology change 

Partner: 

• Today IT organizations have a multi supplier environment. Organizations need to evolve their ITSM to address the intricacies of such an environment. Organization’s ITSM capabilities must broker and manage multiple suppliers and ensure agreements are aligned and properly managed as well.

Future Of ITSM Industry

Today, we see that business strategy is not only driving IT strategy but in some cases are being driven by IT Strategy. In future we will see these ‘some cases’ becoming ‘many cases’. This would be a time when IT would be integrated with business. We have already seen this shift of focus from ‘alignment’ to ‘integration’ in ITIL V3. Also, this would enable IT to effectively address the continuous evolution of organizations and their policies. 

One of my earlier blog has covered how integration of IT with business can happen. 

I believe the future of IT would be driven by some of the key ITIL processes or some specific areas of the same that has not been in much focus across majority of organizations. Also, the tools that would be enabling these processes or areas and facilitate real time decision making would drive the business of Software Product Companies who have such tools in their product catalog. 

Some key areas that would drive the future of ITSM industry would be: 

• Analytics: We have data everywhere. But today the reports or data analysis is predominantly being used to measure vendor performance and in other cases initiate service improvement plans (SIPs). We rarely see the ITSM data driving business decisions. Analytics would be a key for business enabling them to make real time decisions. 
• Automation: According to Forrester, “Service Management and Automation” is one of the key things for future. Automation would drive customer-centric, service-focused, and automated IT operations. It would reinforce the fundamental that customers and services always come first. Besides, automation will allow IT organization’s support and delivery of IT services to be faster, cheaper, and of a higher quality. 
• Proactive IT organizations: Currently we see that majority of IT organizations are highly reactive. Future IT organization would be highly proactive ones. 
• Some ITIL processes would gain importance or would address some key areas which are not being effectively addressed in IT organizations today: 
• Strategy For IT Services and Demand Management processes would enable organizations to innovate and plan to outpace competitors and meet demand.
• Financial Management would ensure that value of IT services are defined and managed. It would act as a decision making process for development and delivery of IT services. It would gain even more importance in cloud environment since charging units, charge per unit and cost per charging unit has to be effectively determined besides billing the customer (and customer’s customer) based on consumption. 
• Business and Service Capacity Management would gain prominence. Currently many organizations are managing capacity only at component level, i.e. they are having only component capacity management in place. 
• Change Management and Service Asset & Configuration Management processes would have more emphasis on focusing Services as CIs and Service Changes (Practically Service is not being recorded as a CI by many IT organizations) 
• Knowledge management would drive automation of management, control and facilitation of knowledge capture and sharing. 
• Proactive problem management, not effectively followed in many IT organizations, would drive pro-activeness. 
• Continual Service Improvement would gain focus so as to continually improve service performance and quality besides process efficiency and effectiveness

Problem Ticket – Should It Be Reopened?

I have come across many queries where people ask me “Can we reopen a problem ticket?”

Before I answer or give my opinion, I have a question – Why would one need to reopen any ticket? Typically this happens when a resolution provided is not as per the user’s satisfaction, i.e., issue for which the ticket was raised is not resolved or fulfilled. This is true for Service Requests or Incidents.

In case of a problem ticket, the ticket is closed only when the root cause is identified and workaround or permanent fix is provided, i.e., the underlying issue is resolved.

Thus, under what circumstances would one need to reopen the problem ticket? I got the response that in cases when the problem resolution is not effective and similar incidents still occur.

Problem resolution has two parts – first part is Corrective Action, i.e., the resolution provided is restricted to the source ticket or CI. Second part is Preventive Action, i.e., resolution is replicated across similar CIs throughout the estate. This is known as CAPA or Corrective Action Preventive Action.

Thus, despite problem resolution, a similar incident can occur under following circumstances:

1. Preventive Action is not performed
2. Root cause identified may not be the real root cause

In the first case, Problem Manager has to ensure effective CAPA.

For occurrences of second case, the old problem ticket should not be reopened. The old ticket was worked upon, served the purpose for which it was created, though the impact of its resolution could not eliminate all possible sources of the incidents similar to the one which lead to its creation. In all such cases a new problem ticket has to be created.

Please note that Problem Manager should ensure that all instances similar to the second case is proactively identified by him/her through Proactive Problem Management techniques like trend analysis.