Showing posts with label data. Show all posts
Showing posts with label data. Show all posts

Sunday, July 1, 2012

The Most Important ITIL Process

What if I told you that not only is there a most important ITIL process, it's widely misunderstood and rarely treated as a process? It's true! Lost in the discussions about incidents, portfolios, catalogs and CSI is the fact that they are all dependent on another process. It is called out many times in all of the ITIL books. But this Rodney Dangerfield of processes "gets no respect". 

This red-headed stepchild of ITIL is Knowledge Management. Most practitioners can recite DIKW (Data->Information->Knowledge->Wisdom) in their sleep. That's the output of Knowledge Management. Few could tell you the inputs to KM, and fewer still how to go about improving their ability to perform KM.

So what are the key inputs to Knowledge Management? EXPERIENCES and INSIGHTS. Quite simply, if your organization cannot capture the experiences and insights of its members and reuse them, ITSM is hopeless. For instance, if your incident management process does not capture what was done and what was learned while service was being restored, problem management becomes nearly impossible.

While KM is a process, it is not an algorithm. It uses heuristics and is a prime candidate for Adaptive Case Management techniques to ensure its outputs achieve their intended purpose. Effective knowledge management is built on standards that include the following items:


  • Standards for recording data around key experiences and insights - incidents, problems, requests, etc
  • Standards for processing data into information - classification, categorization, etc
  • Standards for analyzing information into knowledge - comparisons to targets/expectations, trends, etc
  • Standards for presenting knowledge to support effective decision making (wisdom) - identifying decision criteria, how to represent performance in graphs/tables/charts, etc
To support these standards, you can use models such as the Knowledge Spiral and Knowledge-Centered Support to increase your organization's capabilities. The benefits are that you are better able to discern patterns and address them effectively. And instead of a red-headed stepchild, knowledge management can be the Golden Child that improves your organization's efficiency and effectiveness.

Saturday, June 2, 2012

All Measures are Proxies

I've been a stat-head my whole life. Whether it's sports stats, how much milk our cows were making, box office data, or incident data, I'm interested. So I'd like to focus this post on what data can tell us and what is cannot.

Most people are familiar with the notion of proxies - a measure that is used when you can't measure something directly. In theory, anything can be used as a proxy for anything else. For instance, the number of mirrors I have broken or black cats that have crossed my path could be a proxy for how unlucky I will be in the future.

In practice, we tend to only use a proxy when we perceive a cause and effect relationship. For instance, we use a customer survey score as a proxy for customer satisfaction. A good proxy meets the following conditions:


  • Credibility - stakeholders believe that the proxy is a reasonable stand-in
  • Correlation - movement of the proxy appears to mirror the movement of the item to which it is linked
In a sense, even things that we can easily measure serve as proxies for something else we can't measure. For instance, batting average in baseball is a proxy for whether a player is a good hitter. The amount of money in our bank account is a proxy for how wealthy (or poor!) we are. And so on.

Where this becomes important in ITSM is when no one agrees on how to measure something. For instance, think about the warranty measures - availability, capacity, continuity and security. There is no one agreed definition for any of these terms that would allow you to take a set of data and calculate its measure. This causes a lot of headaches as people debate what the "right" formula is to calculate availability, for instance.

The most useful way to think about these terms is to understand why we want to measure these things. Most groups want to measure these things so they can understand how well a service is performing. It also helps them communicate with the customers of their service. 

Do we need the "correct" calculation in order to do these things? No! We just need to calculate it in a way that is credible to stakeholders and that correlates with delivery of good service. As long as everyone views the calculation as reasonably approximating reality (as they see it), and helps them focus on what areas to improve, the measure is as good as it needs to be!

So the next time you're struggling with metrics, ask yourself why you're trying to measure something. As Lean principles state, overproduction is waste. Don't try to produce a perfect measure when a decent one will let you do what is needed to deliver value!