ITIL - Implementation - ITSM and Metrics

Using the IT Service Management for Service-Oriented Architecture Template to implement ITIL

Order ITSM Template  Download ITSM TOC

IT Service Management SOAITIL - Implementation - ITSM and Metrics - The IT Service Management for SOA architecture is compliant with the latest defined ITIL and ISO 20000 standards.

Information Technology Infrastructure Library (ITIL) is a consistent and comprehensive documentation of best practice for IT Service Management. Used by hundreds of organizations internationally, a whole ITIL philosophy has grown up around the guidance contained within the ITIL books and the supporting professional qualification scheme.

ITIL Implementation

ITIL Version 3 was released in the spring of 2007 and ITIL 3.0 is structured around a core of Service.

  • Service Strategy
  • Service Design
  • Service Transition
  • Service Operation
  • Continual Service Improvement

The processes that are addressed in that standard are:

  • Access Management
  • Availability Management
  • Capacity Management
  • Evaluation
  • Event Management
  • Financial Management (aka Service Economics)
  • Information Security Management
  • Knowledge Management
  • Problem Management
  • Release and Deployment Management
  • Request Fulfillment
  • Service Asset and Configuration Management
  • Service Catalog Management
  • Service Continuity Management
  • Service Level Management
  • Service Portfolio Management
  • Service Validation and Testing
  • Supplier Management
  • Transition Planning and Support

These process in turn are supported by six (6) functional areas. Each of these areas have policies and procedures that are contained in the IT Service Management Template.

Order ITSM Template  Download ITSM TOC

ITIL Standards

Service Desk - (Help Desk Policy, Help Desk Standards, Help Desk Procedures, and Help Desk Service Level Agreement)

An effective "service desk" (Help Desk) can be a great asset to any enterprise. Getting accurate feedback on issues your users are having can only benefit your development efforts and ultimately, the users themselves. The key here is to make sure that the help desk is well-prepared to accept responsibility for support calls on your applications.

Janco recommends that you start working with the help desk at least six weeks before your first application release. If the help desk is mature, they will have aids for capturing application support requests. These will provide the initial information needed for the knowledge base. The help desk personnel will augment that knowledge base over time with solutions and user work-around(s) as they come up with. Be sure to weed out the "false solutions. "

There should be a complete distribution list for ticket reports from the help desk to all of the key managers and users in the enterprise. These will disclose what issues users are encountering. Commonly recurring or high-impact issues should become the focus of everyone involved. This then feeds the priority setting process in the Problem Management process.

Incident Management (Help Desk Procedures, Service Request Policy and Service Request Standard)

ITIL defines an "incident" as any disruption to the normal operation of a system or application. This includes bugs, outages, and even user interface problems. The Incident Management process begins with notification of an incident. This can be logged by the help desk in response to a user call. It can even be automatically created by a monitoring system. It marked as completed when normal functioning of the system is restored.

Note that this does not include root cause analysis or correction! Incident Management is all about restoring service.

Ideally, the help desk handles the entire Incident Management process. In less ideal cases, development may be called on to help resolve "novel" incidents--ones that do not have a solution in the help desk's knowledge base.

When incidents come into the development room, you have some negatives that need to be dealt with. The incident needs to be resolved expeditiously, making it both interrupt driven and urgent. Therefore, every incident will automatically take somebody off their current assignment. This is damaging to flow.

In worse cases, the entire team may get derailed and start huddling around the incident. Fire-fighting is exciting and many help desk professionals like to work them. If the entire team is chasing the incident, nobody is making forward progress on scheduled tasks. If you have a large user community or a lot of incidents, you can lose an entire day or weeks before you realize it.

This can be exacerbated if your help desk never resolves application support incidents. In such cases, Janco recommends the "Center-Post" position. Assign one member of the team to be the primary point of contact for incident resolution.

Problem Management (Help Desk Procedures, Service Request Policy and Service Request Standard)

Recurring incidents can be identified as Problems that require correction. This is the job of the Problem Management process.

Identifying a problem is often done by the help desk, but it can also come from others. The decision about which problems require correction and which ones have top priority often becomes very slow and bureaucratic. Janco has seen teams get chewed out for fixing problems that weren't scheduled to be addressed for a couple of iterations!

Problem managers should be encouraged to communicate via status reports. There also is a need to communicate back to the user community when the status of a problem changes. Good Problem Management classifies problem states such as "known problem", "known workaround", and "known solution". A help desk team will typically move through these states pretty quickly.

Bear in mind that the ITIL definition of Problem Management is all about oversight, not the actual changes needed to fix the problem. The actual changes are deployed as part of Release Management.

Change Management (Change Control Standard, Change Control Quality Assurance Standard, Change Control Management Workbook, Version Control Policy, and Version Control Policy)

Change Management is the most complex part of the ITIL standard. This is the process that so easily slips into heavyweight bureaucracy or, worse, meaningless meetings.

Change Management as defined simply means tracking changes, their impact to configuration items, and ensuring that changes are applied in an orderly way. It doesn't have to hurt.

In reality, however, help desk will spend a lot of time preparing for change management committee (CMC) meetings.

Janco recommends standardizing your change and deployment process (per the standards defined in the template). Get into a regular rhythm of releases and deployments so the CMC comes to expect that every third Tuesday (or whenever), your team will have a new release. Standardize the release mechanics and system impact statement so you can standardize and re-use your change requests. Familiarity will create confidence with the CMC.

Configuration Management (Documentation Standard, Version Control Policy, and Version Control Policy)

Configuration Management (CM) is not the act of changing configuration items. It's the process for tracking planned, executed, and retired configurations. As you plan each release, you should identify the places that will be affected by the release.

In a well-executed ITIL rollout, CM is vital for change management, incident management, the help desk, and release management. In a poorly-executed ITIL rollout, configuration management does not exist, or it only addresses servers or network devices.

CM should cover servers, network topology, applications, business processes, documentation, and the dependencies among all of them. That way, proposed changes to one area (e.g. , upgrade to front-end firewalls) can be analyzed for its impact.

Release Management (Documentation Standard, Version Control Policy, and Version Control Policy)

Release Management dove tails with Information Technology's release planning cycle. Engage early.

Order ITSM Template  Download ITSM TOC