• No results found

WHITEPAPER. ITIL SIMPLIFIED Avoiding common ITIL adoption mistakes

N/A
N/A
Protected

Academic year: 2021

Share "WHITEPAPER. ITIL SIMPLIFIED Avoiding common ITIL adoption mistakes"

Copied!
7
0
0

Loading.... (view fulltext now)

Full text

(1)

ITIL SIMPLIFIED

Avoiding common ITIL

adoption mistakes

(2)

ITIL Simplified

Avoiding common ITIL Adoption Mistakes

IT executives are being held accountable to better manage the qua-lity and reliabiqua-lity of IT under the pressures of increasingly complex customer demands, technology expansion and regulatory require-ments. Standards, such as ITIL, play a very important role. Imagine managing service delivery without a software solution, process automation or any process guidance for that matter. In the early 1980’s, process frameworks, such as ITIL, were just a thought flicke-ring in someone’s mind. These thoughts were the result of a lack of quality in the IT services delivered to organizations. There had to be a better way to deliver high quality services while maintaining low costs. This led to the development of best practices for an IT orga-nization, which became the basis for what we know today as ITIL.

The History of ITIL

In the 1980’s IT was extremely focused on the ‘underlying techno-logy’ of IT rather than the delivery of IT services. Therefore, service delivery was an afterthought that would soon gain prominence when the British government made it a top priority.

The Beginning

ITIL can be traced back to around 1986, when the British govern-ment recognized that the quality of IT service was extremely insufficient. The Central Computer and Telecommunications Agency (CCTA) were tasked with developing an Operational Guidance framework for more efficient and fiscally responsible use and management of IT resources.

In 1988, the CCTA created the Government Information Technology Infrastructure Management (GITIM) framework which focused on Service Support and Service Delivery.

In 1989, GITIM was renamed the Information Technology Infrastruc-ture Library (ITIL).

The Adoption

In the early 1990’s, government agencies and large companies in Europe started to utilize the ITIL framework. ITIL quickly became the de facto standard for IT Service Management.

In 2000, the CCTA merged with the Office of Government Commerce (OGC). In 2001, ITIL v2 was released with volumes dedicated to Service Support and Service Delivery. In 2007, ITIL v3 is released, adopting a Service Lifecycle approach to Service Management and a focus on business integration.

Today

Today, ITIL is widely recognized as the global standard for IT Service Management. The advent of cloud computing will only increase the demand for high quality IT Service delivery and support. Research has shown that ITIL is used (in one form or another) by almost 75% of enterprise organizations. This demonstrates that large IT orga-nizations continue to seek out effectiveness and efficiency in the delivery of their IT Services, and continue to adopt the principles of ITIL to achieve these goals.

ITIL continues to be a popular framework providing guidelines to IT organizations. However, the ITIL framework is something that causes confusion and often intimidation when an organization considers or begins adoption. Organizations become weary of len-gthy ITIL implementation projects and the potentially difficult to quantify benefits. The question of what processes to implement, how to measure ROI and how to avoid common pitfalls often go unanswered. This paper goes beyond defining ITIL, it digs deeper into the most common questions that arise and provides advice on how to avoid the most common mistakes made when following the framework.

(3)

Certification programs were started in the early 1990’s with ITIL v2. Official exams were created and offered to individuals by 2 accrediting organizations: EXIN and ISEB. Three levels of certification were achievable for individuals including Foundation, Practitioner, and Manager (known unofficially as Master).

In 2007, ITIL v3 was released, and with it came a new accrediting organization (APM Group) with a new modular approach to certification, utilizing a credit based system. Candidates complete a module and earn a certification as well as a defined number of credits. The process still includes a Foundation level certification, worth 2 credits. What was formerly the Practitioner level is now known as the Intermediate level, and is comprised of multiple modules worth 3 or 4 credits each, for a possible total of 16 – 17 credits. These modules fall under the Lifecycle stream (3 credits/course) or Capability stream (4 credits/ course). In order to achieve the new ITIL Expert certifica-tion, a candidate needs to have amassed 17 credits (2 from Foundations and 15 from any combination of Intermediate courses), as well as attend and pass the Managing Across the Lifecycle exam for an additional 5 credits. This gives the candidate 22 total credits and the designation of ITIL Expert.

ITIL Certifications

ITIL is Not Magic

ITIL has been referred to as many things – certification, instruc-tions, standards, the golden ticket to end IT chaos. ITIL is a set of books that provides guidelines for delivering quality IT services to customers. ITIL provides a complete methodology for best prac-tices in the discipline of IT Service Management.

ITIL puts great emphasis on a Service Lifecycle which consists of 5 stages:

• Service Strategy • Service Design • Service Transition • Service Operation

• Continual Service Improvement

ITIL is currently published by the Office of Government Commerce (in Great Britain), but it is not just a collection of idealistic OGC theories. ITIL is continually improved through contributions from the global private sector; therefore ‘real world’ practices are incor-porated into the material.

Although organizations cannot achieve ITIL certification, it is pos-sible for individuals to achieve various levels of ITIL Certification. This is an important step for any organization interested in the ITIL framework as a reference. An internal champion who understands the ITIL terminology is a priceless commodity.

Clarifying ITIL Terminology

The English language is complex. The same word can mean very different things depending on the context. Add ITIL to this mix and the confusion increases. ITIL terminology goes against how the common man uses many terms in the English language. In short, ITIL has its own definitions and it’s important to understand these terms across the organization in order to avoid process inefficiency. For example, one department uses the term “Incident,” while ano-ther department refers to the same thing as a “Request,” and yet another department calls it a “Trouble Ticket.” This only causes confusion, resulting in ineffective IT processes.

Let’s begin by defining the critica ITIL terminology, Service and Ser-vice Management.

What is a Service?

A Service is a means of delivering value to customers, by facilitating outcomes that customers want to achieve, without the ownership of specific costs and risks.

There is not a single ‘one’ thing you can point to and say, “that is a service.”

Services consist of the 4 P’s: People, Process, Product (Technology), and Partners (Vendors).

(4)

Services provide value to our customers as long as they have Utility (the Service does what it’s supposed to do), and Warranty (the Service performs well).

There are also different perspectives of a Service. The business perspective is what the user sees and interacts with. The IT pers-pective focuses on the underlying technological components that support the end to end service.

Service Management

Service Management is a set of specialized organizational capa-bilities for providing value to customers in the form of Services. Organizations must consider both their Resources and Capabili-ties when managing their Services.

Resources are the things an organization has, such as money,

infrastructure, people, information and applications.

Capabilities are the things an organization can do, such as

mana-gement, organization, process, knowledge and people (people have certain capabilities).

Resources and Capabilities come together to create value for the

customer, but only when balanced in the right proportions. For instance, if you are staffing a Service Desk, the determination can be made that 10 Service Desk agents is an adequate number of resources based on the number of customers being supported. Howe-ver, if only 3 of the 10 agents have the capability to handle an Incident from initiation through to closure, then we do not have enough capa-bility as an organization. Therefore the organization is not providing value to the customer. An ineffective and inefficient Service Desk will lead to unsatisfied customers, and the organization will suffer because it will not win repeat business.

Quite often, an organization will take an overly reactive approach to remedy this situation. This can lead to the mistake of “throwing more resources” at the problem. In our example, this would be the hiring of 10 more Service Desk agents. This will not resolve the pro-blem, and actually has the effect of making things worse. The orga-nization goes from 7 incapable Service Desk agents, to 17 incapable Service Desk agents and we still only have 3 capable agents.

The organization can properly mitigate this risk by providing training that will arm all Service Desk agents with the capability of resolving Incidents, rather than acquiring more resources.

We can now dig a bit deeper and clarify the ITIL terms that cause the most confusion.

Incident vs. Service Request

ITIL defines an Incident as any event that causes (or may cause) a disruption to, or degradation of a service. A Service Request is defined as a request for a change to a service that is usually well understood, common, has standard procedures, pre-approved, low risk and is user initiated.

The common confusion surrounds the difference between an Incident and a Service Request, and whether Service Requests are managed as Incidents or not.

An Incident is something that disrupts service, while a Service Request is something the user wants or needs. Therefore, Incidents should be handled through the Incident Management Process and Service Requests should be handled through the Request Fulfillment Process.

Events vs. Incidents

ITIL defines an Event as any detectable or discernible occurrence that has significance for the management of the IT infrastructure or the delivery of IT service. There are 3 types of Events:

• Events that signify Normal Operation (Informational) • Events that signify Unusual Operation (Warnings) • Events that signify Exceptional Operations (Incidents)

An Incident is any event that causes (or may cause) a disruption to, or degradation of a service.

The common confusion is the belief that every Event is an Incident. Most Events are not Incidents, they are informational. However, all Incidents are Events, but these Events actually disrupt service.

(5)

Service Request vs. Standard Change

ITIL defines a Service Request as a request for a change to be made to a service that is usually well understood, common, has stan-dard procedures, pre-approved, and low risk. A Stanstan-dard Change is also defined as a request for a change to be made to a service that is usually well understood, common, has standard procedures, pre-approved, and low risk.

The common confusion is in understanding the difference between a Service Request and a Standard Change and which processes we use to manage them.

Service Requests are usually initiated by the user and handled through the Request Fulfillment Process. Standard Changes are usually operational in nature, and are managed through the Change Management Process.

Problem vs. Known Error

ITIL defines a Problem as the unknown, underlying root cause of one or more Incidents. A Known Error is defined as a fault in a Confi-guration Item identified by the successful diagnosis of a Problem, and for which a temporary work-around or a permanent solution has been identified.

The common confusion surrounds the difference between a Pro-blem and a Known Error. A ProPro-blem becomes a Known Error once we understand its Root Cause and we have a work-around for it. An organization has a choice: Permanently fix the Known Error through a Request for Change, or record the Known Error in the Known Error Database (Knowledgebase) and utilize the work-around whenever necessary.

What exactly is a CI?

ITIL defines a Configuration Item (CI) as any component that needs to be managed in order to deliver an IT Service.

The common confusion surrounding CIs is identifying what should be recorded in the CMDB as a CI verses what should be managed in the Asset Inventory (not managed in the CMDB as a CI).

The CMDB should hold records for CIs that are important to the business and impacts a business service. Just because you can re-cord it in the CMDB doesn’t mean you should. The remaining items should be managed in the Asset Inventory.

Common Pitfalls

In successful, ITIL focused organizations, everyone is utilizing com-mon terminology. Using the correct terminology helps to ensure that the correct process is being followed. Unfortunately, this is not the case in many organizations.

One common pitfall is when an organization does not apply com-mon terminology, or any terminology at all. For example, I once worked in an organization that required a “Trouble Ticket” for eve-ry process, whether it was trouble or not!!! The Service Desk was processing “Trouble Tickets” that were not necessarily trouble. There was no distinction between the Service Requests, Problems, Incidents, and Changes because all processes required Trouble Tickets to be created. This made proper reporting very difficult and caused unnecessary stress and confusion amongst the IT staff. All processes suffered and as a result, service delivery was poor and the reputation of IT was terrible.

Other organizations utilize varying terms across different depart-ments for the same thing. One department uses the term “Inci-dent,” another department “Problem,” another “Request,” another department uses the phrase “Trouble Ticket,” another department “Issue,” and all departments are referring to the same thing!

(6)

If all departments utilized the term “Incident,” confusion would be minimal. It’s more than just terminology confusion, it’s process confusion. Once you confuse language, you confuse process. ITIL standards can help an organization avoid this pitfall.

Another common pitfall to avoid is poor categorization. Properly defined categories allow for efficient process automation. The real key for effective categorization is proper training (human element). When Incidents, Problems, Changes, and Service Requests are properly categorized all processes will operate more effectively. In addition, reporting will be more meaningful and you can be more proactive in making improvements to your processes and the ser-vices they support.

In Summary

Although ITIL has been around for almost 30 years, many organiza-tions struggle through the initial stages. However, once businesses standardize terminology and processes, they see significant bene-fits across the organization. Service delivery becomes easier, cost reductions are noticeable and IT staff are much more satisfied.

About the author:

Russell Stopek is a certified ITIL Expert with a superior level of knowledge of the ITIL scheme in its entirety. Russell is ISO IEC 20000 Manager certified and has extensive experience implementing ITIL verified IT service management.

About EasyVista:

EasyVista™ Inc. is a leading provider of Cloud-based IT Service, IT Asset and Organizational & Customer Service Management solutions. The Company serves customers in every vertical sector and has direct operations around the world with offices in the United States, Canada, France, UK, Germany, Italy, Spain and Portugal.

With tier 1, multi-lingual support and Network Operation Centers wor-ldwide, our award-winning Cloud based approach and unique service

management codeless design environment, EasyVista Neo al-lows companies to transform IT services for the 21st century. Our mission is to empower organizations to streamline and sim-plify the management and control of in-house, out-sourced and Cloud-based service management. We are the broker of Service and Support for New IT, we are Service Management by Design.

(7)

EasyVista France (EMEA HQ)

Immeuble Horizon 10, Allée Bienvenue 93885 Noisy-le-Grand Cedex

Phone: +33 1 55 85 91 00 Fax: +33 1 55 85 91 11

EasyVista USA (USA HQ)

3 Columbus Circle 15th Floor, Suite 1532

New York, NY 10019 Phone: +1 (888) EZV ITSM

Fax: +1 (646) 736-6967

EasyVista Portugal

Av. Eng. Duarte Pachero, Torre 2 - 6° Andar – Escritorio 7

1070-102 Lisboa Phone: +351 21 805 13 20

Fax: +351 21 800 71 66

EasyVista United Kingdom

Berkhamsted House 121 High Street

Berkhamsted HP4 2DJ Phone: +44 1442 200 120

Fax: +44 1442 200 121

EasyVista Dallas

14785 Preston Road Suite 550 Dallas, TX 75254 Phone: +1 (888) EZV ITSM

Fax: +1 (646) 736-6967

EasyVista Italy

Via Conservatorio, 22 20122 Milano Phone: 02 77297552

Fax: 02 779240

EasyVista Canada

Logiciels EasyVista Inc 2001 McGill College Avenue

Montreal, QC, H3A 3P9 Phone: 888-EZV-ITSM

EasyVista Spain

Avenida de la Industria N°4 Edif. 3 – 2°B 28108 Alcobendas Phone: +34 902 430 412

Fax: +34 902 430 527

EasyVista San Francisco

71 Stevenson Street Suite 400 San Francisco, CA 94105 Phone: +1 (888) EZV ITSM

Fax: +1 (646) 736-6967

Americas

References

Related documents

– Some events will represent a situation where the appropriate response will need to be handled through the incident, problem or change management process.  Open an incident record

management and also for proactive ITIL processes such as availability , change, service catalog, or capacity management. ‘ITIL combined with Automation results in a single system

Any Service Request Management solution would be based on an ITIL best practice process framework such that a Service Request Management process would provide the structure

Design service solution (Design) Develop service solution (Design) Build service solution (Transition) Test service solution (Transition) Strategy Design

ITIL v3 defines an event as a change of state that has significance for the management of a configuration item or IT service.. This definition is intentionally quite broad since it is

Availability Management Service Continuity Management Performance Management Service Monitoring Business System Management Event Management Service Request Service Execution

This service is the focal point of ITIL service management functions, including Request Management, Change Management, Problem Management and Service Asset and

Improvement of Service Delivery Systems QM Capability to other Management approaches Service Operation Service Strategy Service portfolio mgmt Service Design Service catalog mgmt