測量和管理

在強調使用數據在管理方面的重要性時後,有一句話經常會被引用,如果你無法測量,你將無法有效的管理。

有些人拿著這個念頭就聯想,只要有足夠的數據就可以解決問題。當收集與積累大量的數據以後,希望就可以找到關鍵的洞察力,而我們也能明確的知道在下一步該做什麼。

不過也許我們首先該作的是問一個這個問題,我們最終最希望看到什麼結果?以及我們需要在什麼樣的環境/現實中使用?

在確定所要的管理結果之後,我們再問需要的是什麼數據,以及收集數據的投資是否會超過了收益。

在測量之前,先問問適合的問題。所收集的數據將會更有意義。

Metrics and Analytics

ITIL has a DIKW (Data, Information, Knowledge, Wisdom) model.

I like the model with an enhancement from “The Cognitive Enterprise” by Bob Lewis and Scott Lee. I think judgment is situational but necessary. [https://www.amazon.com/Cognitive-Enteprise-Bob-Lewis-ebook/dp/B018MS4WKK]

By applying structure to collecting metrics, we gain information.

By applying analytics to the information, we gain knowledge.

By applying expertise to the knowledge with the right situational context, we get closer to sound judgment.

Many organizations mistaken metrics for analytics and for thinking metrics or analytics alone will be all they needed to reach a sound judgment in decision-making.

Metrics of analytics can certainly help, but they are only the foundational pieces of a prudent and capable decision-making process.

Change Management Process Design – Part 2

http://www.dreamstime.com/-image25302740

This post is part two of a series where we discuss the ITIL-based Change Management process and how to put one together. In the previous post, I presented some design considerations such as goal/purpose; the intended scope; and roles and responsibilities. In this follow-up post, I will discuss additional process governance and planning elements.

Categorization and Prioritization

Why do we categorize? Proper categorization can facilitate or drive certain governance decisions. Categorization can drive the lead time required for review and approval. Categorization can also determine what process workflow or approval authorities may be required to facilitate the change. ITIL recommends three types of change request: Standard, Emergency, and Normal. If ITIL’s definitions work for your organization, go ahead and adopt them. However, that categorization alone is probably not sufficient to describe the changes and how they affect the business operation. Finding a way to describe the risk and impact associated with a change is also important. Risk can be used to measure the level of the potential disruption of business operation associated with a change request. Impact can be used to measure how far-reaching a change can be. The key idea here is to find a way of properly assessing changes and managing risks.

When designing a categorization scheme for changes, I recommend examining your existing incident and problem categorization scheme and make an attempt to have a consistent categorization across the ITSM processes. I believe that a uniform categorization will make risk assessment more reliable than not having it. A consistent categorization could also make the design and analysis of the reports more meaningful. Some organizations choose to use separate categorization schemes for incidents, problems, and changes – a decision sometimes influenced by the organizational boundaries or the tools on-hand. Just keep in mind that a change management exercise is also a very much a risk management exercise.

Workflow and Documentation

Once you have the change requests categorized, you will need a workflow to process the change requests for review and approval with a well-defined lead time. These lead-times are necessary to provide the adequate time required to review and to approve the change request by the change manager and the stakeholders. Many organizations I was with have had either weekly or semi-weekly CAB review cycles. That means the approval and scheduling timing need to be well defined so CAB and change manager can review, discuss, approve, or even escalate the change with sufficient time. Also, different types of change or change risks/impacts will likely require different lead-times or maybe different work-flows to process them. Some organizations may be required to impose change freeze windows in order to support critical business systems or processes.

Just like other ITSM artifacts, change requests should be documented and, ideally, captured in a tool. The levels of detail needed to be capture will vary from one organization to another, but most organizations should capture the baseline of required data such as:

  • Change requester, owner, and implementer
  • Type, category, risk, impact, priority as defined in the process document
  • Configuration items (systems, applications, devices, etc.) affected by the change
  • Summarized and detailed description of the change
  • Business justification
  • Proposed schedule or implementation timing
  • Dependencies and required resources identified
  • Key approvers needed
  • Final report on the closure of the change

Once the changes are captured and processed, the process guide also needs to define the necessary communication and coordination mechanisms to support the change management activities.

Metrics and Measurements

Tracking and measurement are the key elements to the continual process improvement. Depending on the goal and purpose defined for the change management process, we can further define the critical success factors and the key performance indicators we will need to track in order to measure the effectiveness, efficiency, and the quality of the process. The process design should spell out the metrics requirements and make sure the tools can support the required metrics.

Process Integration

It will also be useful to define some potential connecting ITSM processes to CHM. Incidents, problem, change, configuration, and release management process all have activities that are closely tied to one another. Which processes will trigger the CHM process from an upstream workflow or will receive the CHM output downstream? If you have an incident identified and it requires changes implemented to restore the service, how will those changes be handled? If you practice problem management in your environment, how will CHM process be injected into the root-cause remediation or deficiency remediation activities? Will the incident tickets, problem records, configuration items, and requests for change be linked in some fashion? These are just some governance related questions that should be considered upfront as they will affect how you plan and design the CHM process.

In the last two posts, we just went over a number of governance and planning elements for the change management process. We talked about the scope and purpose of the process, how we categorize and prioritize changes, the essential roles for executing the process, the necessary categorization, workflow, metrics, and integration with other ITSM processes. On the next post, we will go over and example process flow and spell out more details for the change management activities.

Problem Management Process Design – Part 3

This post is the third and the final installment of the series for designing a problem management (PM) process for your organization. Previously we discussed the elements and considerations that should go into designing a problem management process. We elaborated those considerations further with a sample list of process requirements, a sample process flow, and a sample RCA form. We will assemble all the information together into one process design document that can be used to implement the process.

Problem Management Process Design Example

In addition to the process requirements and the process flow, I believe a process design document should call out the following information pertinent to the implementation of the process. For example…

  • The Policy section outlines what policy statements (IT or corporate) governs the process and what expectations the organization wants to set for the process.
  • The Scope section specifies which incidents or events will generate a problem record. Your organization may have a pre-defined set of criteria on how problems are triggered, and those criteria can go into this section. Some organizations may also choose to group a series of closely related incidents and trigger a problem record for those incidents.
  • The Roles and Responsibilities section outlines the roles that will be involved in the process and their corresponding activities and responsibilities.
  • The Artifacts and Communication section describes what documentation methods will be utilized by the PM process. It provides the procedural information necessary to carry out the PM process. The communication protocols section describes the recommended communication methods and their frequencies.
  • The SLA and Metrics section describes the metrics that will be used to measure the process performance. The tutorial document has outlined some examples. Develop and measure the metrics that you can capture reliably and that your organization also cares about.

To reiterate, the primary goal of the Problem Management process is to identify the problems in the IT environment, so we can eliminate them by performing root cause analysis on the problems. As a capable IT organization, we should be able to correctly diagnose the root causes of just about everything that goes wrong within our IT environment and to implement solutions so similar problems or incidents will not reoccur. With proper documentation, the Problem Management database is a great learning tool. Also, another benefit of having a well-run problem management process is having the ability to review organizational decisions made about addressing a particular problem. Known errors do not need to be purely technical. They could also be the documented decisions about how we plan to address certain problems. The root causes, solutions (proposed or implemented) and the workarounds documented as part of the Problem Management process will benefit the Incident Management process immensely when similar incidents surface due to the recurrence of a problem.

I hope the information presented so far has been helpful. Please feel free to suggest options or other approaches that have worked for your organization.

COBIT 5 and What You Can Leverage for ITSM Work

ISACA recently released COBIT 5, a governance and management framework that can help organizations create optimal value from IT. If you are familiar with COBIT, hopefully you have already downloaded the framework documents. If you are not familiar with COBIT or ISACA, follow this link to get more information on the framework. In this post, I will outline some of the useful information you can leverage from COBIT to help you in your ITSM journey, based on my early perusal of the framework.

Good Practices

For a number of processes we use in ITSM, there is a corresponding one in COBIT. For example, DSS02 in COBIT “Manage Service Requests and Incident” maps approximately to the Incident Management and Service Request Management processes in ITIL. Within the process DSS02, COBIT breaks the processes down further into seven management practices. Within each management practice, there are a number of activities associated with each management practice. If you want to implement or improve an ITIL Incident Management process for your organization and wonder what are considered as good practices, these management practice activities can provide some valuable insights for your effort. Tailor those activities further into exactly what you would do in your organization and you have a list of good practices for your shop.

Metrics

For each process, COBIT 5 has outlined various IT-related and process goals that a process contributed directly towards. Next to each goal, COBIT outlines a list of recommended metrics to measure for those goals. Of course, depending on your organization and the availability of certain service management data, you will have to find tune those metrics for your environment. It offers an excellent starting point for defining the list of metrics you plan to capture.

RACI Chart

For each process, COBIT 5 has a RACI chat that talks about who is responsible and/or accountable for certain key management practices within the process. Granted, the RACI chart can be high-level and somewhat generic. It nevertheless offers a good starting point for those who are working on a process design exercise or just want to better define the roles and responsibilities within your environment.

In summary, I must say I like what I have seen from COBIT 5 so far because the framework offers a great deal of good information to use for your ITSM work. I definitely recommend downloading and checking out the new framework further. On Tuesday, April 17, 2012, Debbie Lew of Ernst & Young and Robert Stroud of CA hosted an education session on COBIT 5 during ISACA Los Angeles Chapter’s annual spring conference. Normally the presentation deck is available only to the attendee of the conference. Ms. Lew has graciously given me the permission to make the presentation deck available via this blog. Check out their deck for more information on COBIT 5 and feel free to post questions and comments.