Essential ITIL: what you need to succeed.
People consistently ask me similar questions about ITIL, and most of these revolve around practical approaches for implementing various process improvements in their organization.
Of course, some of these discussions require some basic level-setting around ITIL itself, which may in turn require a bit of "demyth-tification.'' Since its introduction back in the 1980s about it than is contained in the ITIL books themselves--some of it factual, some hype, and some pure myth.
So let's start there: what is ITIL really all about?
First, ITIL is about people. In fact, ITIL starts with a commitment to the people of IT, because it consists of a series of individual IT practitioner certifications. These certifications help improve the skills required to deliver high quality, repeatable, and well-controlled IT services. There is no ''company-wide ITIL certification"--these would, in fact, be handled by the international standards organization ISO via ISO 9001/8 and 20000 corporate certifications.
Second, ITIL is about process. There are different approaches to process implementation based on which "version" of ITIL you are inclined to adopt. But without debating the merits of ITIL "versions," let us presume that any ITIL implementation discussion ultimately has roots in the principle of Process Improvement. Besides, ITIL v2 and v3 are more alike than different at a fundamental level. Both embody essential ITSM processes that every IT organization must perform to the best of its ability - you're doing them as a matter of course whether you have efficient processes in place, or not. Thus almost any question you might ask about ITIL comes down to this: how do you best make use of whatever essential ITIL v2 and/or v3 elements make sense for you to adopt given your specific needs.
Third, ITIL has starting points. This is one of the most widely discussed topics as of late, especially as ITIL isn't considered to be highly prescriptive. Rather, it's a set of "good practice"guidance for IT practitioners to follow. They may adhere to these strictly, as outlined in each of the books. Or, more likely, practitioners may adapt the ITIL guidance as they see fit based on the unique skill sets, goals, and functions of their unique IT organization.
But rest assured, there are a handful of ITIL processes which are essential to today's IT organizations and the services they deliver--whatever the specifics of the organization happen to be. This last point is worth expanding upon further, which I'll do by way of an analogy.
ITSM Meets Perfumery
When I first looked at the large number of processes and functions in ITIL v3 my initial reaction was perplexity: Where do I start and how should I decide an approach? When I have this dilemma I often find it valuable to look to other industries for a long-established precedent, and see if I can learn from their experiences. Right about this time my wife had decided to change her perfume, and there was the inspiration I needed--in the ancient art of perfumery.
Imagine being given the task of creating a new and exciting perfume. Just think of all the potential ingredients and the sheer complexity of the task. Selecting and synthesizing a few components from among many is a challenge perfumers have grappled with for thousands of years as they've sought to blend exquisite scents from a myriad of available ingredients. This is similar to the problem we face in talking about what processes are essential in ITSM, and hence in ITIL.
To achieve success, perfumers have structured a logical approach that, through analogy, can be applied with good effect to determining what's essential to implement in ITIL v2 and/or v3.
Of course, the ingredients you ultimately choose will be driven by the specific problem you're trying to solve. Are you being asked to create the ITSM equivalent of a chewing gum flavor, versus a captivating cologne? The collection of ITIL processes you choose to implement will reflect that, as I'll explain shortly.
Types of Scents
Perfumes basically consist of four classes of ingredients: primary scents, modifiers, blenders, and fixatives.
PRIMARY scents can consist of one or a few main ingredients that create a classic, natural theme or concept, such as "rose" or "jasmine." Alternatively, multiple ingredients used together can create an "abstract" primary scent that doesn't directly resemble a natural ingredient, such as "cola." These become the essential elements around which the perfume will be based, and are key to a successful perfume. Of course, before selecting the primary scents you would need to have some guidance; for example, is the scent for a man or a woman, young or old, rich or poor, trendy or staid? From this basic data the process can begin.
MODIFIERS alter the primary scent to give the perfume a distinct, desired character. For example, fruit esters can be included with a floral primary scent to create a "fruity floral" scent, whereas citrus scents specifically create a "fresher floral." The cherry scent in cherry cola is this kind of modifier. If we only used the primary scents then we would have much less choice, but the skill of the master perfumer is in the subtle addition of modifiers that create a new and exciting combination.
BLENDERS are a diverse group of ingredients that smooth out or "round off" the transitional notes of a perfume by blending, balancing and harmonizing its different "layers" or "bases;" i.e., the primary scents and modifiers. Common blending ingredients include hydroxycitronellal, which imparts a floral odor to numerous consumer products, and linalool, a naturally occurring terpene alcohol found in many flowers and spice plants.
FIXATIVES are used to support the primary scent by bolstering and stabilizing it. Resins and wood scents, and amber bases, are among the scents typically used for fixative purposes. Without these components smells can break apart and just not work, like immiscible liquids.
Granted that's all vastly oversimplified but you get the picture: in a perfume some scents are primary and others play secondary or supporting roles. It's the same with the ITIL processes as I'll now explain.
The ITIL Essentials
Talking about individual ITIL processes in isolation from one another is inherently limiting, especially in the ITIL v3 context, since the processes are designed to be used together. But which ones are essential and which are optional? The component approach and associated terminology used in perfumery is an ideal way to illustrate the relationships among the essential elements and how they work together with supporting processes.
ITIL PRIMARIES are those essentials that every IT organization must have, and inherently does have, whether it embraces the ITIL guidance or not. Every IT shop has some way of managing incidents, for example, even if it's just assigning someone to fix what breaks in response to complaints from users.
ITIL MODIFIERS such as Service Level Management and Service Catalog, are those processes that "flavor" the character of the primary processes. In relation to the essential process of Incident Management, for instance, these "modifiers" determine whose incidents are more important than someone else's. Part of setting up a service catalog would be to decide that when System X fails it's a Priority 1 call whereas when System Y fails it's a Priority 3 call. Most organizations will need to implement some version of these Modifiers as they will the Primaries. You don't want people making up their own priorities and escalations--you want rules, and those rules modify the behavior that is required on a primary level.
ITIL BLENDERS are those processes that ensure everything will work together. For example, Capacity Management ensures you have enough staff, servers, etc. to execute the other processes.
ITIL FIXATIVES in this case are Financial Management activities; things like headcount and budget that bond the whole IT infrastructure and organization together in the end. That is, with whatever your budget and governance are, you make sure you've got the best possible facilities to meet business needs.
Just for fun, try this exercise: Create a simple spreadsheet with four columns, one for each of the four constituents just described, and then start putting the names of each v3 process or function in Figure A into whichever one of the columns you think it belongs under. It's a very interesting exercise because everyone looks at the various processes and their interrelationships with a different set of eyes. If you do this as a group you may get into a lively discussion.
SERVICE SERVICE SERVICE SERVICE CONTINUAL STRATEGY DESIGN OPERATION TRANSITION SERVICE IMPROVEMENT Financial Service Event Transition The 7-Step Management Catalog Management Planning and Improvement Management Support Process Service Service Incident Change Service Portfolio Level Management Management Reporting Management Management Demand Capacity Request Service Service Management Management Fulfilment Assets & Measurement Configuration Management Availability Problem Release and Return on Management Management Deployment Investment Management for CSI IT Service Access Service Business Continulty Management Validation Questions Management and Testing for CSI Information Operational Evaluation Security Activities in other Lifecycle Management Phases Supplier Service Desk Knowledge Management Management Requirements Technical Engineering Management Data & IT Operations Information Management Management (Control & Facilities) Applications Management FIGURE A Functions and Processes from the Service Lifecycle as listed in the five core publications describing the IT Service Management practices that make up ITIL v3.
The Eight Essential Elements
As stated above, some ITIL processes are essential to every IT organization--because you're doing them regardless of whether you have an efficient process in place to help you or not.
Let's take stock now of the essential ITIL processes and why they're essential to IT Service Management success. If you compare the bullet list that follows to the list of ITIL v3 functions and processes in Figure A you'll quickly see that, while it's obvious that some of these processes are clearly essential to ITSM, it is difficult to decide exactly which processes and functions to include because there are many sub-processes in v3. Figure A illustrates the large range of elements that need to be addressed from the v3 perspective.
Leveraging the collective ITIL guidance with an eye toward "first steps" and foundational aspects, here are the eight essential ITSM processes that are required by all IT departments:
1. Service Desk
2. Event Management
3. Problem Management
4. Service Asset & Configuration Management
5. Change Management
6. Incident Management
7. Request Fulfillment
8. Release & Deployment Management
Recent research supports calling these processes out as essential. For example, the IT Process Institute, in its research on Identifying Key Performance Drivers (1), found seven sets of control practices that predict top levels of performance. From highest to lowest impact, they are:
* Release scheduling and rollback (Release & Deployment Management)
* Process culture
* Pre-release testing (Change Management)
* Process exception management (Incident Management and Problem Management)
* Standardized configuration strategy (Service Asset & Configuration Management)
* Change linkage (Change Management)
* Controlled production access
Looking at these control practices you can see that most of them map closely to five of the ITIL essentials. Process culture is a management initiative and not an ITIL element per se, and therefore is not covered by the essential elements. This leaves Controlled Production Access, which the essential ITIL processes will contribute by highlighting and supporting resolution of various security issues, as well as ensuring that new services are secure.
Similarly, the eight ITIL essentials encompass much of what is in the ITIL Service Transition and Service Operation phases, which have been well-quantified in terms of their impact to IT performance.
What Makes the "Essentials" Essential?
Now let's briefly discuss each of the eight essential ITIL processes individually, with an eye toward why each is so important.
SERVICE DESK Everybody using computers everywhere at some point needs something fixed.
Even if a business doesn't have a Service Desk per se the activity is still happening--people inevitably call or e-mail someone or knock on someone's door and say "this doesn't work, fix it." Service Desk is thus a basic IT activity irrespective of whether you formalize it with technology and skilled people or not; calling the Geek Squad or another third party amounts to the same thing.
EVENT MANAGEMENT An Event is a set of circumstances that may or may not affect the customer, but you know it has happened or you can predict that it shortly will happen; e.g., you see that a particular server is getting near its capacity limit. So hopefully you spot that as an Event, you tell Capacity Management, and they create more capacity. The customer doesn't even know the server they use nearly froze. Event Management is being done all the time, any time threshold/alerts are established or IT is monitoring the infrastructure.
INCIDENT MANAGEMENT AND PROBLEM MANAGEMENT Incident Management is all about getting the customer's service back to agreed service levels as fast as possible. Again, this is an essential ingredient because keeping the business performing to its maximum performance level is why ITSM exists. And Problem Management is about root cause analysis relative to Incidents. Problem Management asks "Why did that incident or group of incidents occur? And what can we do to stop that happening again?" Again, that's an essential part of how you do your job in IT.
CHANGE MANAGEMENT IT changes constantly. There isn't any shop that isn't changing on a daily basis, be it major or minor in magnitude. You have to perform changes all the time to fix Events, respond to Problem Management insights, roll out new equipment, and so on. Change Management is not only essential to IT operations, but it's also your Achilles' heel. The recent three-hour e-mail outage that BlackBerry users experienced, which resulted from an upgrade to increase capacity, is but one example among many of the high-magnitude risks associated with failed changes.
REQUEST FULFILLMENT Employees, customers and other stakeholders inevitably have requests relating to services in whatever form; and, of course, you have to address those requests to the best of your ability or what are you there for? You must do that; it's a basic part of your job.
RELEASE & DEPLOYMENT MANAGEMENT Some might view this process as subsumed under Change Management but either way the activities associated with it are essential. Say you've got a brand new payroll system going live. This includes everything associated with getting that business-critical service in place; conducting the related training; moving, converting, and backing up files; and so forth. Another example might be rolling out two hundred new workstations over the weekend. Again, Release & Deployment Management is the kind of service IT is providing all the time with varying levels of efficiency and effectiveness.
SERVICE ASSET & CONFIGURATION MANAGEMENT This essential process is squarely where IT governance comes to the forefront. Every IT department needs to know what assets it has, where they are located and what is being done with them. If you don't know this asset information than you are probably violating Sarbanes-Oxley since they want to know why you don't know. So inarguably this process, too, is essential.
Getting the Basics Right
These essential elements figure prominently in both ITIL v2 and v3, but in v3 the guidance around them has been upgraded. For this reason I recommend that organizations that have embraced v2 (as well as those that have yet to do so) at least consider upgrading their essential elements to incorporate v3 enhancements.
That said, it remains absolutely imperative for every IT shop to get the basics right at whatever level is currently possible. Implement these essential elements first, in whatever order makes sense for your IT organization, leveraging ITIL advice wherever possible. If you're working with the service lifecycle approach in v3 then you'll be modifying and blending the essentials with some of the supporting processes at the same time. Even from a v2 perspective, in fact, you'll be doing some blending, shading, and customization of the essentials to fit your needs. It is important to remember also that, wherever you start out from, you will still need to "continuously improve" by adding the other layers - especially the Modifying layer, which includes elements such as Service Level Management and Service Catalog.
Real World Application of "The Essentials"
Let's now apply all this emphasis on the flexible application of essential ITIL processes to answering the kinds of questions I hear every day from IT managers and leaders alike.
My boss told me to forget about strategy and to concentrate on improving service management--how do I do this with ITIL v3?
One approach would be to implement the essential elements to a given maturity level; and, once those are in place then go back to the boss and say, "OK, we've got control of our basic processes, now let's do ITIL v3 the proper way using the service lifecycle approach." That is, look at the essentials versus your current practices and determine how far from the v3 guidelines you are for each one. Then ask: What do we need to do to close the gap? Having implemented the essentials you've lost nothing towards moving ahead with the serviceoriented methodology that v3 advocates.
To prove the business value of ITIL v3 to my boss and peers I need some quick wins--how do I do this with v3?
It's often the case that senior IT managers don't have direct, hands-on experience with ITIL; hence they might legitimately question whether it's just another way for consultants to make money. If this is your situation my advice would be similar to the above: look at your basic processes today, pick the ones you're worst at right now, and improve them using v3 guidance to a basic level of maturity that provides business value. Then you'll have some leverage to justify your case to move forward with the lifecycle approach.
I am not interested in the service lifecycle approach, so can I still use ITIL v3?
Some organizations just don't "do" long-term planning, but that doesn't mean you can't make good use of ITIL v3. First get the essential elements in place, then look at the rest of the components and start integrating supporting processes with those basic eight, keeping in mind the perfume analogy above. First modify the basics, then add blenders and fixatives as I've discussed.
How can I build a good set of essential elements from ITIL v3?
Select the processes that address your greatest pain points, perform a process gap analysis and then close the gaps. But keep in mind that the number of "essential" processes you ultimately put in place might be more than the eight discussed here. When you take a closer look at v3 guidance you'll see that there aren't just a few processes and functions involved, there are more than thirty of them. Once you've got the basics in place you'll want to continue on and build in others - even if you don't plan to adopt v3's service lifecycle approach. It's reasonable to take the v2 approach to process implementation since v2 is process-oriented. But adopt the v3 guidance about what constitutes a process, its inputs and outputs, etc., and then prioritize your rollouts of specific processes based on what you need to improve most.
ITIL isn't about the debate over Versions or Processes or Lifecycles. As my colleague Rob Stroud notes in his blog titled: ITIL v3--You're doing it whether you know it or not, if you want to work for successful organizations, they have probably already put several aspects of ITIL v3 into practice, whether they realize it or not. As the head of the ITSM team at a large manufacturer commented, "any ITIL implementation that is service aligned is doing much of v3 already."
The keys to success then, are the eight essential elements that every IT organization should adopt and perform to the best of its ability.
When practical considerations preclude adopting all aspects of the v3 methodology, this should be seen as a valid starting point, not a stumbling block, for leveraging the essential elements. Once basic processes are in place organizations can begin to fine-tune and expand on those processes by adding "modifiers," "blenders" and "fixatives"--supporting processes that "flavor" the IT environment in line with unique, local requirements.
RELATED ARTICLE: Abstinence, When it Comes to Business Intelligence Projects, is Not a Good Idea
The acquisition of Business Objects by SAP and Cognos by IBM has caused a great deal of turbulence in the Business Intelligence (BI) world, and this in turn is having an effect on the BI applications market. However, there is also another reason for the slowdown in this particular market: abstinence.
In a move to differentiate its wares and to extend the reach and range of its BI platforms, vendors in this space have spawned an adjacent market comprised of applications designed to help organisations run their businesses better. One of these application areas - 'performance management' - has gained significant momentum over the last four years, with BI (and non-BI) vendors investing heavily in order to secure their share of the market.
Performance management solutions are presented in many different guises: Enterprise Performance Management, Business Performance Management, and Business Performance Software, with Corporate Performance Management (CPM) being Butler Group's preferred term.
In the current climate, one would have thought that the market for CPM solutions would be booming, as business leaders seek to control their companies and institutions better; but my impression at the moment is that organisations are being ultra cautious in all areas of IT spending, even though CPM should be viewed as a mission-critical business investment project. Holding-off CPM projects for another year is not really an option in my opinion, as although many factors influence the performance of an organisation, none is more critical than the decisions business users make every day. CPM solutions help individuals make these decisions and enable organisations to answer three key business questions: "how are we doing?", "why are we doing this?", and "what should we be doing next?" In terms of CPM offerings, this equates to: score-carding, dashboards, and financial consolidation; reporting and analysis; and planning, budgeting, and forecasting. Most organisations do of course have systems in place to measure and monitor aspects of business performance, but all too often these systems stop at the finance department. CPM extends this practice to other areas of the business, and provides operational managers and employees with actionable BI, i.e. information that is both relevant and timely.
The current trend towards IT abstinence, i.e. the conserving of expenditure relating to IT projects in order to build up capital or savings, may be damaging to an organisation's prospects when the global economic slow-down reverses. Cancelling or postponing BI projects in particular can only weaken an organisation's position with respect to the competition. Organisations must of course be prudent in the current economic climate, but CPM provides a way for organisations to illuminate the business as they search for the light at the end of the tunnel.
Richard Edwards, Senior Research Analyst, Butler Group
EXECUTIVE CONSULTANT TO CA
About the Author
Malcolm Fry began his IT career in 1967, and in the following years took on development, operational and management roles for retail, manufacturing, oil, and pharmaceutical organizations. He has received worldwide recognition as one of the foremost authorities in the areas of help desk and IT service management. He is the author of numerous best-selling books on IT service and support, the newest being Building an ITIL Service Management Department which is due to be published in May. In addition he has had many articles and papers published in multiple languages, and is currently writing a white paper for CA extolling the importance of the Essential ITIL v3 Processes and Functions. Malcolm was also a member of the ITIL Advisory Group (AIG) steering ITIL v3 and a mentor, along with Rob Stroud, to the authors of the ITIL v3 Service Transition book.
|Printer friendly Cite/link Email Feedback|
|Article Type:||Organization overview|
|Date:||Mar 1, 2009|
|Previous Article:||Everyone a computer specialist: a case for the development of user orientated autocode languages using the notation and terminology of the type of...|
|Next Article:||Software as a Service: it's about the business model, stupid. This white paper stresses an alternative view to the prevailing technology platform...|
|iTRACS integrated solutions simplify IT Infrastructure Library standards adoption in enterprise networks.|
|iTRACS integrated solutions simplify IT Infrastructure Library standards adoption in enterprise networks.|