Skip to main content

Posts

ISO 20K Can Be a Starting Point, Not a Destination

Since it's adoption, there has been a slow, but steady growth in the number of organizations that are seeking, or have achieved, ISO/IEC 20000 (ISO 20K) certification. For the most part, interest in the standard is being driven by RFP requirements or perceived competitive advantage. The certificate is seen as an "award" that an organization receives for achieving best practice ITSM. While ITIL is being actively adopted, many organizations are overlooking ISO 20K because they do not perceive any value in the certification. I recently realized that we are looking at ISO/IEC 20000 in the wrong way. The standard has so much more to offer than just a certificate. It actually provides a starting place for an ITSM journey, not only the destination. ISO/IEC 20000 defines the "minimum critical activities" required to deliver high quality, aligned services. Once these activities are understood, an organization can assess which activities they already execute well and w

Defining Categories

I often hear from organizations that they are not reaping the expected benefits from their Incident Management Systems or integrated Service Management suites. One of the biggest reasons is that they are struggling to determine how to categorize incidents, problems, service requests, changes, and so forth. Coming up with the right categories for your organization is easier said than done. If you’ve had to do it multiple times, you’re not alone. Having said that, it is important to persist. Categories drive many process activities such as: Incident matching Second- and third-level escalations Workflow management Self-service decision tree logic Priority definition Knowledge base searches Trend and root cause analysis Metrics production SLA reporting Miscategorized records cause inefficiencies, ineffective reporting and can even damage the relationships between lines of support. For example, are your second-line support teams regularly asking “why was this record assigned to me?” If so,

Service Requests and Change Management

I was having a discussion with a learner this morning about the difference between Service Requests and Standard Changes. This learner's organization publishes a list of standard services that users can request via a self-help tool. The Service Request will be routed to the Service Desk. The Service Desk will review the request. If appropriate, the Service Request may be fulfilled by applying a Standard Change that has been approved by Change Management. By definition, a Standard Change is a pre -approved, low risk change (such as a new hire) that can be fulfilled almost immediately. Standard Changes must be recorded, possibly as a Service Request. They do not require operational oversight by the CAB. It is important to note that not all Service Requests are Standard Changes. Service Requests can include questions, queries, complaints and compliments. Similarly, not all Standard Changes are Service Requests. Standard Changes can include batch jobs, patches and other low risk chang

Undervalued Evaluation

I have been reading Service Transition and am struck again that one of the most undervalued processes is Evaluation. The purpose of Evaluation is to provide a consistent and standardized method for determining the performance of a service change. The actual performance of a change is assessed against its predicted performance. Any detected can therefore be understood and managed. One of the goals of Evaluation is to provide effective and accurate information to Change Management. The objective is to: Evaluate the intended effects of a service change as well as the unintended effects of the change. For example, does the change meet the requirements agreed to in Service Design? Does this change have any negative effects on availability, capacity, etc…? Provide good quality outputs from the evaluation process so that Change Management can asses whether a service change is to be approved or not. Triggers for the Evaluation Process: Request for Evaluation from the Service Tr

ITIL V3 and MOF 4.0

Since 1999, Microsoft has offered its own framework for IT Service Management. The analogy with ITIL has always been clear, which is quite obvious as both frameworks offer documented 'best practice' guidance for IT Service Management. There are plenty of interesting differences though. In a cross-reference document, Microsoft illustrates how MOF and ITIL play leap-frog. The document offers a detailed analysis of the similarities and differences of both frameworks. More information: go to MOF or download the paper here: Cross-reference MOF-ITIL .

ITIL's Service Design 5

What does the Service Design stage actually design? Many readers of ITIL V3 assume that Service Design is primarily responsible for IT services. In fact, this stage is responsible for five different aspects: Service solutions Service management systems and tools Technology architectures and management systems IT and service management processes Measurement methods and metrics ITIL’s holistic approach to design ensures consistency and integration across the full portfolio of IT services. Consideration of each design begins with an assessment of the “as-is” situation, with a view to identifying relationships, dependencies, compatibility, and, especially, opportunities to leverage existing capabilities and resources (service assets). Both opportunities and gaps are identified. This may validate the design of the new service, or may indicate the need to modify or adapt the design of the new service or other existing services. Service Design is charged with designing ser

What IS a Process?

Ross Wise here again…While I was working on some process improvements the other day it occurred to me that it could be very easy for people to get confused over the different elements that make up a process. So I thought I would jot a few down for everyone to help clear things up… First we have the process itself. This is a collection of specific high level steps that can happen in either a linear or parallel fashion to achieve specific objectives or outputs. It consists of a number of elements: Procedures : detailed instructions for the completion of a given process step Flowchart : a diagram showing the order and connection of process steps and decisions Inputs : the raw materials you use to create the process output Outputs : the end product or service resulting from doing the process steps and procedures Triggers : events that initiate the process Roles : the assigned responsibilities given to individuals using or executing the process Resourc