CSI and the 7 Step Improvement Process

I would like to revisit the 7 step improvement process from the perspective of CSI, since there has been a slight (logical) modification to it.  The concept of measurement, what we measure, gathering the data , processing it into understandable formats and then being able to analyze it, is fundamental in our ability to perform (CSI)  Continual Service  Improvement as an overall vision and in support of the business need and the underpinning of tactical and operational goals.

1. Identify the strategy for improvement: (Plan) Talk to the business, to your customers and to IT management.  Utilize your service catalog and the associated service level requirements to define a starting point.  The question “What is important to the business?” must be answered.  Look to the corporate vision, mission, goals and objectives.  Identify the IT vision, mission, goals and objectives.  Are these properly aligned? Tie in the Critical Success Factors.  Are these being met?  Is value creation happening? (Wisdom)

2. Define what you will measure: (Plan) This directly relates to the organizations strategic, tactical and operational goals.  It is in this step where we actually define what can be measured.  If a gap exists between what can be measured and what we need to measure, then a gap analysis must be completed and then finalize an actual measurement plan.  CSI can identify opportunities for improvement. (Data)

3. Gather the data: (Do) Data can be gathered from multiple sources.   Quality is the key objective of gathering the data for CSI.   The emphasis is not on assuring real time performance (that is an operational perspective) but on identifying where improvements can be made to existing levels of service, or IT performance. (Data)

4. Process the data: (Act) Data is processed in alignment with Critical Success Factors (CSF) and Key Performance Indicators (KPI).  If necessary we can align this data all the way up to the vision.  The goal here is to process the raw data into an understandable format that can be rationalized and made consistent.  We begin to create information.  After this we can begin to analyze the information and begin to make the essential comparisons. (Information)

5. Analyze the data: (Check) In this step the information begins to be transformed into meaningful knowledge of the events that are impacting the organization.  We can begin to define any trends that may be happening within our environment.  We can also determine if these trends are positive or negative.  It is important that we ensure that proper analysis takes place, to support our future recommendations before we present this data to the business. (Knowledge)

6. Present and use the information: (Check) At this point we present and use the information in whatever way is necessary for the target audience.  It is imperative that you understand your audience and the purpose for which the report is being given.  The purpose and the value being created must be properly articulated.  This will prevent the gap that often happens between what IT reports and what is of interest to the business.  This will underpin our recommendations and assist the business in defining the next steps. (Knowledge)

7. Implement improvements: (Act) Here the knowledge gained is used.  We can optimize, improve and corrects services and processes.  The issues have been identified and solutions can now be applied.  Since each stage of the lifecycle has limited resources it is also here where we prioritize which improvements can actually be implemented.  Once done, new baselines can be established and the process can begin again.

The Value of Business Relationship Management

One of the key processes in the ISO/IEC 20000 standard is Business Relationship Management. This process “establishes and maintains a good relationship between the service provider and the customer based on understanding the customer and their business drivers.”


Business Relationship Management (BRM) within ISO/IEC 20000 is one of the Relationship Processes (along with Supplier Management). These processes help to establish the links in what Harvard Professor Michael Porter described as the “value chain”. BRM creates the link between the service provider (including IT, but full delivery may involve other organizational functions) and the customers and users, both internal (“the business”) or external (“the end customer”).

Business Relationship Management is now a formalized process in newest (2011) edition of ITIL. With the newest edition, the authors recognized the importance of having BRM as an extent process, rather than as guidance embedded in other ITIL processes (such as Service Portfolio, Strategy Management and Service Level Management). The formalization of BRM now paints a complete picture of the service lifecycle, one that has slowly emerged since the earliest days of best practice guidance in the form of ITIL.

I sometimes encounter people who had begun their journey with V2 guidance, yet had only been exposed through formal training to the two core books of Service Delivery and Service Support. This narrow exposure gave them a limited perspective of the service lifecycle that had always existed (albeit in a disjointed and disconnected way). Unfortunately, many people did not know about or read the other books in the V2 library. However, best practice guidance had been put forth in V2 as to the importance of engaging the customer and understanding their needs. The last of the V2 books to be published, titled The Business Perspective, focused on this vital idea. In ITIL V3 (2007 edition), the authors brought this idea into the mainstream service lifecycle, yet had not made it a formal process. BRM has now taken its rightful place in the canon of processes in ITIL 2011.

I am very glad to see the full vision of the service lifecycle emerge. BRM is a fundamental process that helps a service begin its own journey to delivering value to customers and users. Although one could (and many have) begun their service delivery journey from IT outward, BRM provides an often misunderstood or forgotten view or perspective from the customer towards the service provider. Following the standards laid forth in ISO/IEC 20000, an organization can begin to build an even stronger linkage to those stakeholders who benefit most from efficient, effective and economical services delivered by service providers. 

Drivers for the Various CSI Orders or Levels

In a previous blog we discussed the revised 7 step improvement process.  Step 6 of that process is to present and use the information.  There are various levels of management in an organization. When presenting this information and implementing improvements it is important to understand which level to focus on and have a good understanding of the perspectives of each level and what their drivers are. This will enable us to derive the maximum value and benefit out of the information delivered.

First order drivers:  At the highest level of the organization are the strategic thinkers.  The reports delivered at this level need to be short, quick to read and deliver precise data about risk avoidance, protecting the image or brand of the organization, profitability and cost savings.  These are the drivers that will support your reasons for improvement efforts.

Second order drivers: The second level of management is occupied by vice presidents and directors.  Here, reports can be more detailed and must summarize findings over time.  Defined is how the processes delivered support and underpin the business objectives and enable the organization to react early and quickly to issues that put the business at risk.  They will also illustrate how these processes are aligned to our existing measurement frameworks which enable us to define the health of the business from the perspective of the IT organization.

Third order drivers: This third level of management is made up of managers and high level supervisors. At this level reports and measurements need to demonstrate compliance to stated objectives and overall team and process performance. They should provide insight into resource constraints and continual improvement initiatives.

Fourth order drivers: At this level are the team leaders and staff members.  Reports must emphasize personal benefits.  Metrics must define individual performances, provide recognition of skills and identify training and career growth opportunities.

Knowledge Management - the "why"

When I teach, I like to talk about knowledge and wisdom and the value that they bring to the organizational table.  A lot of the time people give me a quizzical look, Knowledge? Wisdom?  Where is this conversation going?  I ask people how they capture the knowledge or do they even capture the knowledge that is gained when they develop a new service, application or when some new technology is introduced into their live environment.

Although what we deliver can sometimes be intangible (availability, capacity, security) it is very complex and can take years to build up the know-how on how to deliver these elements and continually meet the changing needs of our customers.   However you need knowledge, born from experience, to solve problems, to always improve, to use your wisdom to answer the question of why should we make one choice over another?

Like any other organization we must brand the product we deliver.  This brand will then garner a reputation; the reputation will be built on the knowledge that is gathered from the designers, engineers and support staff.  Knowledge must be stored, protected and shared to create a culture of quality among the staff of your organization.

Many people think you can deliver this quality by compartmentalizing the different components in the delivery chain, siloing the different processes and technologies.  Continual service improvement isn’t about putting a bunch of smart people in a room and designing some new infrastructure or service.  It requires skills that are difficult to attain.  It’s about people being immersed in the day to day activities of the entire organization and utilizing and sharing the knowledge that is developed by these processes and functions. In some future discussions we will talk about the methods and best practices on how to we can capture and share our knowledge to continually meet our customers changing needs.

Knowledge Management - the "what"

George Santayana, the Spanish American philosopher, wrote the famous saying, “Those who cannot remember the past are condemned to repeat it.”

 

This really is the underlying basis for the process of knowledge management.  It plays a key role in CSI but data must be captured in each of the service lifecycle stages.  This Data capture must then be processed into Information, synthesize the information into Knowledge and applied to the context of the environment we are supporting to create Wisdom.  This is known as the Data-to-information-to-Knowledge-to-Wisdom structure. DIKW.  Wisdom (not repeating the past) will allow us to make more informed & better decisions around improvements in our processes, functions and services. The purpose of knowledge management process is to quantify all of this D-I-K-W and then to share perspectives, ideas, experiences and information at the right time in the right place with the right people to enable informed decisions efficiently by not having to rediscover this valuable knowledge.

Let's review the four elements of DIKW:

Data: Is a set of discrete facts about the CIs that we have within our environments.  This data is captured in highly structured databases such as “Service asset and Configuration management systems.  These advanced systems allow us to create relationships between these CIs and the discrete facts are captured as attributes of these CIs.  This allows us to identify the relevant data and accurately capture it.  We can then analyze and synthesize this data into information.

Information:  We create information by putting the data into some context as it relates to our environment.  This information is typically stored in things like emails, records, documents and multimedia.  We do this so that it can be easy to capture, query, find, re-use and learn from.  I like to think of the information as somewhat static.  It’s the state of a CI at a particular moment in time.  We can then trend these different moments in time to garner knowledge about the lifecycle of a CI or group of CIs.

Knowledge:  Knowledge is gained from the analysis of information.  This is then combined with peoples own experiences, insights and expertise to create new knowledge.  Knowledge is dynamic and context based.

Wisdom:  Wisdom is the ability to make use of our combined knowledge to create value through correct and well informed decisions. (Back to that not repeating the past thing).

In our next blog, we will explore "why" Knowledge Management is critical to successful service management.

Should Service Requests be Included in First Call Resolution metrics?

I recently had a question regarding the inclusion of Service Requests into metrics for First Call Resolution. As always, the answer is “it depends”!

ITIL now treats Service Requests and Incidents as two different processes – Service Request Fulfillment and Incident Management. Both are generally logged into the same tool and owned by the Service Desk. They are also measured by their own key performance indicators and metrics. ITIL does not consider first call resolution as a process metric - it is more of a service desk performance measurement.

First call resolution historically helps measure the handling of incidents by the Service Desk. The definition of an incident is usually pretty clear. However, since the definition of a service request can vary greatly from organization to organization, the value of including requests in incident metrics may also vary.

If your definition of a service request includes pre-authorization and funding, then the Service Desk’s ability to fulfill the request during the first call likely falls into the same percentage as incidents. However, if service requests may require an additional layer of management approval or the service desk does not have the skills and authority to fulfill the requests, then it is unfair to hold them to a first call resolution metric that is unachievable. What do you consider to be the “first call”?

I would also consider your assignment of urgency, impact and priority when deciding whether to include service requests in your statistics. Are you using the same standard for determining the priority of service requests and incidents? Should an analyst spend more call time fulfilling a service request in order to meet the target while a user with a potentially higher priority incident is in queue?

HDI’s recently published results of its Support Center Practice survey, including some statistics about first call resolution. While most respondents targeted over 70% first call resolution, only about 40% actually achieved that goal. Given that, I would recommend reviewing all of the criteria used for this important measurement.

Financial Management and SACM KPIs

A learner who is working towards developing a Cost Management department recently asked about key performance indicators (KPIs) for the Financial Management and Service Asset and Configuration Management (SACM) processes.    

ITIL 2011 actually maps Critical Success Factors (CSFs) to KPIs for each process.  Key performance indicators for Financial Management can be found in section 4.3.8 of the Service Strategy book while those for SACM can be found in section 4.3.8 of the Service Transition book.

While I cannot list all of the KPIs for both processes, here is a good sample:

Financial Management

• The financial management for IT services framework specifies how services will be accounted for, and regular reports are submitted and used as a basis for measuring the service provider’s performance.
• All strategies have a comprehensive analysis of investment and returns, conducted with information from financial management for IT services.
• Internal service providers receive the funding required to provide the agreed services – showing a break-even at the end of the financial planning period.
• Customer and service assets are recorded in the configuration management system, and all required financial information is complete.
• Regular reports are produced on the costs and utilization of customer and service assets and action plans are targeted for any deviations from required performance or utilization.
• The cost of each service is reported on a monthly, quarterly and/or annual basis, and compared with the return achieved by that service
• The service provider uses an accounting system, and this is configured to report on its costs by service.
• Regular reports are provided on the costs of services in design, transition and operation.
• Improved accuracy in budgets and charges for the assets utilized by each customer or business unit
• Increase in re-use and redistribution of under-utilized resources and assets
• Reduction in the use of unauthorized hardware and software
• Reduction in the average time and cost of diagnosing and resolving incidents and problems
• Improved ratio of used licences against paid-for licences
• Improvement in time to identify poor-performing and poor-quality assets
• Reduction in risks due to early identification of unauthorized change
• Increased quality and accuracy of configuration information

Service Asset and Configuration Management

• Improved accuracy in budgets and charges for the assets utilized by each customer or business unit
• Increase in re-use and redistribution of under-utilized resources and assets
• Reduction in the use of unauthorized hardware and software
• Reduction in the average time and cost of diagnosing and resolving incidents and problems
• Improved ratio of used licences against paid-for licences
• Improvement in time to identify poor-performing and poor-quality assets
• Reduction in risks due to early identification of unauthorized change
• Increased quality and accuracy of configuration information