Will An Incident Become A Problem?

I have often come across discussions and queries regarding when an incident would become a problem. Interestingly, I have found that some of my co-consultants and many practitioners of ITIL, despite being ITIL certified at various levels themselves, provide various reasons for the same. Some of the ‘so called’ conditions when an incident would become a problem are:-

• When there is a major incident
• When the incident approaches SLA breach time
• Business impact of incident is very high
• Etc.

The fact is an incident never becomes a problem.

In generic terminology or layman’s language, incidents are referred to as problems. But such explanations are not expected from an ITIL certified individual.

Let us see how ITIL defines incident and problem:

• ITIL defines incident as an unplanned interruption to an IT service or a reduction in the quality of an IT service.
• ITIL defines problem as unknown cause of one or more incidents.

Let us take an example to understand difference between the two – Your PC hanged and that happened quite frequently. Every time you rebooted your PC, it started working fine. Eventually, you called the support team. They checked your PC and installed a patch. Thereafter, your PC never hanged.

The condition when your PC hanged was an incident. You resolved that incident by rebooting it. It was a workaround. Finally, when the support team checked your PC, they did a root cause analysis. It was a problem. They provided resolution to this problem by installing the patch.

Asset Vs Configuration Item

Another area that people find it difficult to differentiate is a configuration item and an asset. Some of us feel that both are same. I will focus this post on key differences between the two.

Asset has a financial value along with a depreciation rate attached to it. IT assets are just a sub-set of it. Anything and everything that has a cost and the organization uses it for its asset value calculation and related benefits in tax calculation falls under Asset Management, and such item is called an asset. Asset's life is for duration till its financial value becomes 'Zero', which depends on the associated depreciation rate. There is no relationship between assets.

Configuration Item or CI on the other hand may or may not have financial values assigned to it. It will not have any depreciation linked to it. Thus, its life would not be dependent on its financial value but will depend on the time till that item becomes obsolete for the organization. CI has a relationship. So from a CI all information on subsequent parent and child CIs can easily be obtained. Also, CI is restricted to items specific for use in live IT environment.

Let’s take an example that can easily signify the similarity and differences:

1) Similarity:

Server - It is both an asset as well as a CI.

2) Difference:

Building - It is an asset but not a CI.

Document - It is a CI but not an asset.  

Good Practice Vs Best Practice

I have observed that most of us confuse between Good Practice and Best Practice. Whenever it is recommended that a practice should be followed, it is said to be a best practice. When this practice becomes a part of life, it becomes a good practice. So a good practice is always automatically followed by everyone concerned. We can say that a best practice when followed over a period of time becomes a good practice.

Let us take couple of examples from our day to day life. Initially when the seat belts were introduced in cars, it was said to be a best practice to wear the seat belt. Eventually, wearing seat belt became a habit and thus a good practice.

Another example is wearing helmets. Initially people were not used to wearing helmets and thus it was said to be best practice to wear a helmet. But over a period of time, in most countries, wearing helmet became a habit and it became a good practice.

Let’s take an example from ITSM space. For an organization where service desk has been recently introduced, it is a best practice to call the service desk in case of any issue, help or information required. But eventually when the process matures, it becomes a practice to call the service desk for any support issues and hence a good practice.

ITIL V2 Vs V3

Like any other process framework evolution, ITIL is also evolving and ITIL V3 is the latest generation of this evolution. This evolution has really caused a lot of anxiety in ITIL followers in terms of “What it is?”, “How will it impact our ITIL V2 implementation?”, “Should we go for ITIL V2 or V3” and so on.

I would like to mathematically term V3 as:

ITIL V3 = ITIL V2 Refined + ‘X’

Where, ‘X’ is a set of new processes, most of which probably your organization would already be following.

Also, there has been a level of ambiguity in the ITIL V2 jargons and the terms the industry was actually using. A best example of it can be the CMDB. The ITIL V3 has not only taken care of these ambiguities but also provided a simplified framework in terms of what industry was “actually” using. In other words we can say that it has refined ITIL V2 to be aligned with the industry. Not only that it has broadened its scope covering the processes that industry is already using but were not included in ITIL V2.

Besides, while ITIL V2 talked about “Aligning IT with business”, the ITIL V3 is talking about “integrating IT with business”; i.e., making IT a part of the strategic layer of an organization and thus covering strategic, tactical and operational layers.

ITIL V3 has introduced us to Service Life Cycle approach. This raises a question – “Why was it required?” ITIL V3 is having a major focus on IT Strategy (Business – IT integration) and Continual Service Improvement. The entire approach from identifying a service for creating value to business, to its design, transition, operation and improving on its performance and cost parameters needed a continuous cycle, and thus what we have is a Service Life Cycle. Accordingly a process realignment (of all ITIL V2 processes) was required.

In the corresponding tables we would try to map all the existing processes of ITIL V2 to ITIL V3 and understand the key processes that are new to ITIL V3. The description under the column “In V3 under” has the names of core ITIL V3 books. These five books help an organization in understanding:

• How can they develop business driven ITSM strategy?

• How can they design a system to support the selected ITSM strategy?

• How would they transition the designed system to production, in terms of people, processes and technology?

• How would they support the operation of the implemented system on an ongoing basis?

• How would they continuously improve the processes and operations?

Mapping ITIL V2 processes to ITIL V3

1. Process: Financial Management For IT Services

Process Name in V3: Financial Management

In V2 under: Service Delivery

In V3 under: Service Strategy

Additional Details: Concept of Return on Investment (RoI) introduced.

2. Process: Service Level Management

Process Name in V3: Service Level Management

In V2 under: Service Delivery

In V3 under: Service Design

Additional Details: No changes. It is also covered briefly in Continual Service Improvement.

3. Process: Capacity Management

Process Name in V3: Capacity Management

In V2 under: Service Delivery

In V3 under: Service Design

Additional Details: Resource Capacity Management is renamed as Component Capacity Management (consisting of Resource Management & Performance Management). Capacity Management Information System (CMIS contains info. on capacity & performance reports and data, Forecast and Capacity plan) introduced.

4. Process: Availability Management

Process Name in V3: Availability Management

In V2 under: Service Delivery

In V3 under: Service Design

Additional Details: Availability Management Information System (AMIS contains info. on Availability Mgmt. reports, Availability plan, Availability design criteria and Availability testing schedule) introduced.

5. Process: IT Service Continuity Management

Process Name in V3: IT Service Continuity Management

In V2 under: Service Delivery

In V3 under: Service Design

Additional Details: No changes.

6. Process: Change Management

Process Name in V3: Change Management

In V2 under: Service Support

In V3 under: Service Transition

Additional Details: No changes.

7. Process: Configuration Management

Process Name in V3: Service Asset & Configuration Management

In V2 under: Service Support

In V3 under: Service Transition

Additional Details: Configuration Management and Asset Management exist as two sub-processes. Configuration Management System (CMS) and Service Knowledge Management System (SKMS) introduced. CMS contains a set of tools and databases (Eg. CMDB, Asset database, etc) used to manage configuration data and includes information about Incidents, Problems, Known Errors, Changes, and Releases.

DHS & DSL replaced by Definitive Media Library (DML). DML is one or more locations in which the definitive and approved versions of all software Configuration Items are securely stored).

8. Process: Release Management

Process Name in V3: Release & Deployment Management

In V2 under: Service Support

In V3 under: Service Transition

Additional Details: Release and deployment activities separated as two separate sub-processes – Release and Deployment.

9. Process: Incident Management

Process Name in V3: Incident Management

In V2 under: Service Support

In V3 under: Service Operation

Additional Details: No changes.

10. Process: Problem Management

Process Name in V3: Problem Management

In V2 under: Service Support

In V3 under: Service Operation

Additional Details: No more bifurcation of process into problem control and error control activities. Known error can be created during any stage of problem management.

New processes in ITIL V3

1. Demand Management (Service Strategy): It is a critical aspect of service management. It consists of activities that understand and influence customer demand for services and the provision of capacity to meet these demands. At a strategic level Demand Management involves analysis of patterns of business activity & user profiles and the strategy to influence the demand. At a tactical level (as part of Business Capacity Management it involves implementation of strategies to influence the demand. In ITIL V2 the concepts of Demand Management was discussed under Business Capacity Management).

Key Terminologies:

• Pattern Of Business Activity (PBA): It defines dynamics of a business & includes interactions with customers, suppliers, partners, and other stakeholders.

2. Service Portfolio Management (SPM) (Service Strategy): SPM is the process responsible for managing the Service Portfolio. It considers Services in terms of the business value that they provide.

Key Terminologies:

• Service Portfolio: It is the complete set of services that are managed by a service provider. It is used to manage the entire lifecycle of all services (Service Pipeline, Service Catalog and Retired Services). It is not normally published to customers.

• Service Pipeline: It is a database or structured document listing all IT services that are under consideration or development, but are not yet available to customers. It provides a business view of possible future IT services.

• Service Catalog: It is a database or structured document with information about all live IT Services, including those available for deployment. It is the only part of the Service Portfolio published to customers, and is used to support the sale and delivery of IT Services. It includes information about deliverables, prices, contact points, ordering, and request processes. It contains accurate information on all services that are currently operational and all services that are about to transition into operation.

3. Service Catalog Management (Service Design): Service Catalog Management is the process responsible to provide a single source of consistent information on all of the agreed services and ensure that it is widely available to all who are approved to access it. They are responsible for the maintenance of Service Catalog. In ITIL V2 Service Catalog was discussed under Service Level Management.

4. Supplier Management (Service Design): Supplier Management is the process responsible for ensuring that all contracts with suppliers support the needs of the business, and that all suppliers meet their contractual commitments. In other words they are responsible to manage suppliers and the services they supply, thus ensuring that value for money is obtained by provision of high quality of IT Services to the business.

Key Terminologies:

• Supplier and Contract Database (SCD): It is a database or structured document used to manage Supplier Contracts throughout their lifecycle. The SCD contains key attributes of all contracts with suppliers, and should be part of the Service Knowledge Management System.

5. Information Security Management (Service Design): It is the process that ensures the confidentiality, integrity, and availability of an organization’s assets, information, data, and IT Services. It is a comprehensive process designed to address the strategic direction for security activities of the organization and to ensure that its business objectives are achieved. They are responsible for aligning IT Security with business security and thus ensuring that information is effectively managed in all services and Service Management activities. In ITIL V2 it was a part of Availability Management.

6. Transition Planning & Support (Service Transition): Its purpose is to plan for the capacity & resources required for any transition and provide support to the transition teams. Besides planning & co-ordination they are responsible for identifying, managing & controlling the risks of failure & disruption across transition activities. When needed they also co-ordinate activities across projects, suppliers and service teams.

7. Service Validation & Testing (Service Transition): It is responsible for ensuring the quality assurance, i.e., to ensure that a service being transitioned is fit for purpose and fit for use. Its responsibility also includes planning and implementation of validation and test activities. It also identifies, assesses and addresses issues, errors and risks through out the Service Transition activity.

8. Evaluation (Service Transition): It is a generic process. It considers whether the performance of something is acceptable, value for money, etc. – and whether it will be continued with, accepted into use, paid for, etc. They are responsible for correctly setting the stakeholder expectations and providing effective and accurate information to Change Management to make sure changes that adversely affect service capability and introduce risk are not transitioned unchecked.

9. Knowledge Management (Service Transition): It is responsible to ensure that the right information is delivered to the right person at the right time to enable him/her to make an informed decision, thereby improving the quality of the management decision.

10. Event Management (Service Operation): It is a stand-alone process for detecting and managing events and alarms, which ITIL calls “exceptions”. In ITIL v2, Event Management was covered under Incident Management. It is responsible for monitoring all events that occur anywhere in the IT infrastructure, to detect and escalate exception conditions and determine the appropriate control action.

11. Request Fulfillment (Service Operation): It is a new process for managing the lifecycle of all customer and user generated service requests. These types of requests include facilities, moves and supplies as well as those specific to IT services. In ITIL V2, it was covered under Incident Management.

12. Access Management (Service Operation): It provides rights and identity management related to granting authorized users the right to use a service, while restricting access to non-authorized users. Its goal is to provide right to users to be able to use a service or group of services.

13. Continual Service Improvement: It is responsible for continuously aligning and re-aligning IT services to the changing business needs by identifying the improvement opportunities and implementing the improvement plans/activities to IT services that supports the business processes.

ITIL Functions

ITIL V2 had Service Desk as the lone function. While ITIL V3 has 3 more functions other than the Service Desk. These functions are:

1. Technology Management: Provides the detailed technical skills and resources needed to support IT services and management, along with the ongoing operation of the IT Infrastructure.

2. IT Operations Management: It is responsible for the daily operational activities needed to manage IT services and the IT Infrastructure. It includes IT Operations Control and Facilities Management.

3. Application Management: It manages applications throughout their lifecycle.

Impact Of ITIL V3 On ITIL V2 Implementation

What if your organization is already implementing (or has already implemented) ITIL V2? In fact a very minimal impact is there. You can carry forward your ITIL V2 implementation plans and once you have already implemented ITIL V2, you can identify the areas which would need some modifications or tweaking of your processes. The changes to the old processes are in terms of refinements and thus are minimal. So taking your organization from ITIL V2 to ITIL V3 is not going to be an ‘uphill’ task. And in terms of the new processes of ITIL V3, a lot of them would be what your organization would already be following. So you have to only work around these processes to follow the ITIL V3 framework.

And for the organizations that are thinking of implementing ITIL, well you can take up your implementation plan with ITIL V3 straight away.