WHITEPAPER. ITIL SIMPLIFIED Avoiding common ITIL adoption mistakes

Transcription

1 ITIL SIMPLIFIED Avoiding common ITIL adoption mistakes

2 Avoiding common ITIL Adoption Mistakes IT executives are being held accountable to better manage the quality and reliability of IT under the pressures of increasingly complex customer demands, technology expansion and regulatory requirements. 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 flickering 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 organization, which became the basis for what we know today as ITIL. 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 lengthy 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. The History of ITIL In the 1980 s IT was extremely focused on the underlying technology 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 government 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 Infrastructure 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 organizations 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.

3 ITIL is Not Magic ITIL has been referred to as many things certification, instructions, 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 practices 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 incorporated into the material. Although organizations cannot achieve ITIL certification, it is possible 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. ITIL Certifications 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 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 certification, 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. 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 another 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. 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). Let s begin by defining the critica ITIL terminology, Service and Service Management.

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 perspective focuses on the underlying technological components that support the end to end service. Service Management Service Management is a set of specialized organizational capabilities for providing value to customers in the form of Services. Organizations must consider both their Resources and Capabilities 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 management, 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. However, 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 capability 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 problem, and actually has the effect of making things worse. The organization 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 standard procedures, pre-approved, and low risk. A Standard 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 Configuration 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 Problem and a Known Error. A Problem 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 workaround 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 record 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 common 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 common terminology, or any terminology at all. For example, I once worked in an organization that required a Trouble Ticket for every 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 departments for the same thing. One department uses the term Incident, 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 services they support. In Summary Although ITIL has been around for almost 30 years, many organizations struggle through the initial stages. However, once businesses standardize terminology and processes, they see significant benefits 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 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 worldwide, our award-winning Cloud based approach and unique service management codeless design environment, EasyVista Neo allows companies to transform IT services for the 21st century. Our mission is to empower organizations to streamline and simplify 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 Contact us Americas EasyVista USA (USA HQ) 3 Columbus Circle 15th Floor, Suite 1532 New York, NY Phone: +1 (888) EZV ITSM Fax: +1 (646) EasyVista San Francisco 71 Stevenson Street Suite 400 San Francisco, CA Phone: +1 (888) EZV ITSM Fax: +1 (646) EasyVista Dallas Preston Road Suite 550 Dallas, TX Phone: +1 (888) EZV ITSM Fax: +1 (646) EasyVista Canada Logiciels EasyVista Inc 2001 McGill College Avenue Montreal, QC, H3A 3P9 Phone: 888-EZV-ITSM EMEA EasyVista France (EMEA HQ) Immeuble Horizon 10, Allée Bienvenue Noisy-le-Grand Cedex Phone: Fax: EasyVista United Kingdom Berkhamsted House 121 High Street Berkhamsted HP4 2DJ Phone: Fax: EasyVista Spain Avenida de la Industria N 4 Edif. 3 2 B Alcobendas Phone: Fax: EasyVista Portugal Av. Eng. Duarte Pachero, Torre 2-6 Andar Escritorio Lisboa Phone: Fax: EasyVista Italy Via Conservatorio, Milano Phone: Fax: