ISO/IEC 20000 documentation eco-system

Here is a full picture of the required documents and records in the ISO/IEC 20000 service management system. We thought it would be nice to have everything in one place. Depending on the number of your requests, we will be posting it as a printable PDF poster. Would you like that?

ISO/IEC 20000 documents and records



Documents belonging to process groups are described in previous posts:

Service management document system

Control process group documents

Resolution process group documents

Relationship process group documents

Service delivery process group documents

Design and transition of new or changed services documents

General requirements documents

ISO/IEC 20000 SMS general requirements documents

Which documents are required in SMS general requirements of ISO/IEC 20000? This chapter is about management involvment and adding quality control flavour to service management

Management responsibility

It is absolutely impossible to establish an elaborate service management system (SMS) without the active and unconditional support from the top management. The plan and the policy are just dead letters on paper (or screen) if they are not supported with the visible and constant vision-based commitment from the CEO and CIO. Therefore you have to ensure that the service management policy and plan are at least reviewed, approved and backed up by the top management.

Other parties

Most of service providers need to include other parties in order to complete some of the service management processes. It is very important that the provider can demonstrate the accountability and authority to manage these processes with an end-to-end visibility.



SMS General requirements documents

Documentation management

Two simple procedures have to be established here:

• Control of documents
• Control of records

It is a fact that service providers implementing ISO20k usually have a quality management system (QMS) based on ISO9001, and this makes it easier. If the QMS and the SMS are of the similar scope, then just delegate control of these procedures to the QMS. If it is not the case, just write and implement these two simple procedures. Not a rocket science.

Resource management
Parts of resource management requirements can also be delegated to other quality systems. It is very difficult to run a service management system without some essential Human resources practices, so if you already have some, integrate them into your SMS.

Establish and improve the SMS
This part of the norm is aligned with Deming's wheel: Plan-Do-Check-Act. Therefore the documents covering this part are:

• Service management plan
• Continual improvement policy and procedure
• Internal audit procedure and plans
• Audit records
• Nonconformities
• Corrective/preventive actions
• Management review
• Improvement proposals

 

ISO/IEC 20000 Design and transition of new or changed services documents

Change is hard. Service management people love the Status quo. Introducing new services in your system takes a lot of time, resources, knowledge. Even the slightest changes on an existing service can have adverse impact on the business process.

Large changes are often done by the technology specialists from architecture or infrastructure departments. They usually don't care much about your service management methodologies and best practices, since they operate by their project management methodologies and frameworks. Some of the common infrastructure project management methodologies are "Nexting" (clicking the Next button until the server is installed), Run'n'gun and Quick'n'dirty. And voila - new service is ready for support.

This mentality can create barriers between departments and impact the business in a very bad way.
In order to overcome this, all stakeholders have to agree on set of rules for introducing new/changed service.

So this is what chapter 5 is all about. Policy, procedural documents and records that cover activities during the service design and transition.



Design and transition documents

Policy will describe the general rules of the game. I personally like to add a New/Changed service procedure which will describe the workflow and responsibilities. This ensures that everyone knows what to expect, minimizing the blame management playground.

ISO/IEC 20000 Service delivery processes documents

Service delivery process group means business. Back in the old days, it was half of ITIL V2 Service Management. This is a large and complex process group oriented towards the customer. Service delivery processes create a lot of documents and records. Where will you keep them?

For additional info, please have a look at our previous posts:

• Service management document system
• Control process group documents
• Resolution process group documents
• Relationship process group documents

For all of these processes and their documents my general remarks are the same as before. Try to have a separate procedure document for each process, even if it is not required. Also, each process should have a policy, at least as a part of the procedure. These should give a quick general knowledge about the process to new employees and provide some structure to the SMS (Service Management System).

Service delivery process group documents

6.1 Service level management
SLM is a key process in Service delivery, most of the other processes depend on it. There is a lot of communication with the customer during the process, and records should be retrievable either from the file system, specialized applications or document management system. All the changes on key documents should be done through the Change management process.

6.2 Service reporting
Reports are an important way of communication with the customer. Service provider has to keep records of all agreements about reporting with the customer. Optimal place to put report definitions would be the SLA, or a separate contract. For newly developed reports it would be enough to archive a customer's reply to your mail with the new report proposal.
All the reports have to be defined according to the requirements, so they can be delivered even if the main assignees are unavailable. Thing vacations, flu seasons… Keep the report definitions in a neat report catalog, and insist on standardized reports as much as possible. If the customer requires something specific, evaluate the requirement, and if it is found valuable, include it in your standard report.

6.3 Service continuity and availability management
This process requires a lot of activity and resulting records. The auditor will probably like to see most of them. C&A management is a difficult and tedious process since it doesn't provide immediate business results, but it provides proof that you are serious about your business.

6.4 Budgeting and accounting
Here is one process that most of the IT people tend to neglect. If it's true your case too, turn to your finance department and go through the requirements with them. They will most probably be able to help you pull it off.

6.5 Capacity management
Capacity management has some very simple requirements and it is rather straightforward. If you are a managed services provider, or if you provide IT services to external customers, try to document and archive your communication with the customer about the capacity, since you have to take into account their resources too. The auditor might want you to prove that you take care of things over the fence.

6.6 Information security
If you are implementing ISO/IEC 20000, there is a chance you alredy certified for ISO/IEC 27001. Good for you, since you can redirect most or all of this process requirement to your ISMS (Information security management system). If not, follow the requirements and take care of the produced documents and records similar to the other recommendations from this series of posts.

So, a bunch of complex processes. Don't be intimidated by them. Plan your implementation, one process at a time. In the beginning, it looks like a Mission impossible. After some time, you'll get used to it :)

ISO/IEC 20000 Relationship processes documentation

Relationship processes add a human flavor to IT service management. There is a bit more freedom in defining documentation for Business relationship and Supplier management then in ITIL-descended Service Support and Delivery processes.

In the next few posts I will focus on process specifics. For a more general info  about the SMS document system you can have a look at my previous posts:

• Service Management Document System
• ISO 20000 Control processes documentation and
• ISO 20000 Resolution processes documentation.

 



Relationship processes documentation in ISO/IEC 20000

Business relationship management
Business relationship management refocuses IT to the customer and his needs. Documents and records can be created in a variety of ways and saved according to your organization document management preference.

A policy would be nice to have.

 

Records serve as the proof that you are performing this process as required. We keep both the documents and records in our document management system, alternatively they can be placed on a shared folder system.


Supplier management
Supplier management forces the provider to consider the supplier's ability to stay within agreed SLA parameters.

Same as the above, documents and records can be in the document management system or in shared folders.

ISO 20000 Resolution processes documentation

Incident and Problem management, being the most matured processes in service management should be easy to define in ISO20k. But where do we put documents and records? What do we have to pay attention to?

And here comes the infamous resolution process group. How to deal with these documents and records?

Incident and service request management
Procedure: As we know, in Incident management there are three separate procedures. If you are a small service support organization, all three of them can be in one document, as separate chapters.

Policy is not required, but, as I said, we like to keep the standard form for all processes. Policy, again, can be a separate document or a part of above mentioned procedure document, preferably in the beginning. Your documents will sit in a Resolution process group folder on your file share, document management system or a service management wiki.

Records: You probably have some kind of a ticketing app, or a full Service Desk application. Your Incident and Service request records will reside there.
Same as before, you have to agree with the customers about some details, AND don't forget to keep these agreements in electronic or paper form. Your auditor will probably want to see them.



Resolution process group in ISO/IEC 20000

Problem management
Procedure: As we know, the Problem management process can be fairly simple until you start to write it down. Please, try to have fun with this one as we did :)
Policy: same as above.

Records: Problem records, known errors, fixes and even reviews can be kept in your Service Desk application, or at least they can be linked to a document repository where they are saved in MS Word, PDF or other form.
Reports about process effectiveness will be kept in your document repository or maybe somewhere where you maintain your meeting minutes documents.

ISO 20000 Control processes documentation

Where should we keep our ISO 20k documents? Do we need a sophisticated document system, database or a printed library? Is a shared folders system enough? We asked ourself these and many more questions before we started implementing our service management system.

Living with our ISO/IEC 20000 Service Management System for years, we gathered some experience and knowledge about it that I will be happy to share here. I would like to spend a few posts on the key parts of the system, with document and record management in focus.

I have touched the theme in my previous post Service Management Document System, now let's elaborate it through specific process groups.

Mind you, I am not aiming to describe specific ISO20k requirements, for this you have the standard(http://www.iso.org/iso/catalogue_detail?csnumber=51986). I am discussing the specific required and nice to have documents and their whereabouts.

I will go through each process group and share my experience and opinions.

Let's start with Control processes. It's in the heart of the ISO 20000 schematic and I really feel these processes deal with the vital documents and records for the service management. So it's a good place to start.


Configuration management
Policy: this document will define the main game rules focusing on general non-sequential process rules. After the initial creation, it will not change frequently. Policy can sometimes be a part of the

Procedure document, but I prefer to put it in a separate document since I find it easier to maintain it.

Procedure: a document which describes how Cis are tracked. It will also be rarely changed . Policy and procedure can be stored in shared folders or in a document management system. Configuration Item Type Definitions: we have to have these, and it helps if we have the ITSM tool to keep it in.

CMDB records: if you have CMDB automated in a separate CMDB application or a piece of a ITSM tool, then you are all set, it's a way to go. Otherwise, you have to keep and maintain the knowledge about the customer's infrastructure in one ore (usually) more databases/document repositories. Basic CI info will probably be kept and maintained in your ticketing application. Less structured data can be kept in a separate database and documents. It is very important to keep these data up to date. This can be done by appointing ServiceDesk and/or account managers to be responsible for CI info accuracy. Bad CMDB data are the source of all evil in ITSM. Things to take special care of:

Catalogue of services - services are Cis, and are usually composed of technical services, dependent of many Cis. Think carefully how will you maintain this data, and especially how deep will you go in granular description of Cis.

Access data - passwords and accounts for accessing customer infrastructure are very sensitive and it has to conform to 6.6. Information security management.



Control processes group in ISO/IEC 20000

Change management
Policy: again, a separate document or a part of a procedure document. A good practice would be to keep all important non-sequential data in a policy, like definitions, acronyms, interfaces. There are processes which don't specifically require a policy, but we like to create one for every process anyway. See if it works for you.

Procedure: Only emergency procedure is required, but again it would be nice to have a separate document here defining all types of changes that we perform.

Emergency change definition: it would be very useful if you can get this definition in a contract with the customer. In case of external customer, most of them insist on their own templates created by their legal, so this Emergency change definition agreement has to be done in a separate contract. Most of the auditors will accept a simple confirmation reply from a customer to your e-mail.

Records: change schedules, RFCs, plans, analysis, reports are results of CAB meetings and other CM activities, and they can be kept either in your Service Desk tool or on any other tool you use for document management, in accordance with 4.3.2 Control of documents.

Release and deployment management
Release policy: same as the other policies. You have to keep a record about your agreement with the customer regarding this policy. It would be best if it is in your SLA but it can also be separate mail exchange or a document signed by the customer.

Emergency release definition also has to be agreed with the customer.

Records: plans, control documents, reports/analysis can be kept either in your Service Desk tool or on any other tool you use for document management, in accordance with 4.3.2 Control of documents.

Service Management Document System

A few words about the service management document system. Whether you implement ITIL processes or a complete ISO/IEC 20000 service management system, your documents and records have to live somewhere. What is the best practice here?


Let's keep the main thing the main thing. What document system is already at place in your organization? Use it. If your organization has reached the level of maturity to implement the Service Management System, odds are that you already have some kind of a sensible document management software.

Introducing a new feature, no matter how seductive it may seem, will just prolong the learning curve and increase the resistance to the change. You don't want that. Try to stick with what you have. Implement the system with what you've got and let it live for some time. At the end of the first year, you will know what's missing, and you can take it from there.



Service Management Document System

So, the only thing you have is a file share system? No sweat. It can work very well for you. You have implemented a Wiki in your company? Even better. Even with the hype of wiki fading away and reducing it below its measure, it can be utilized ideally for specific purposes. You have a real document management system, open source or from a renowned vendor? Cool, we will put it to work.

Documents
Internal documents - when we talk about basic service management documents like policies, processes and procedures, these are the documents which won't change frequently. The ideal place for them is where you already keep this kind of documents. File share, document management system, collaboration applications, even paper versions might work. Of course, I'm not very serious about this last one :)

What you have to have in mind with these documents is that:

• they must be easily accessed by the authorized personnel,
• they have to be found and identified quickly
• approved by authorized people
• only the last approved version should be accessible to the audience
• versioning might come in handy.

If you are kind of halfhearted here, my recommendation for document management here is the Wiki. Any kind of a decent open source or Wiki as a part of some document management system you have deployed. Documents open quickly in any browser, everything is indexable and searchable, and versioning is easily traceable. A bunch of advantages compensate well for the minor difficulties in text formatting.

External documents - unstructured documents like customer and vendor agreements and contracts, legal documents, laws, norms, company and employee certificates etc. can be in paper or electronic form. For some of them the organization has to conform to legal requirements of keeping and archiving.
For efficient service provider operation most of the paper documents shall be converted to electronic form and accessible to employees according to their user rights. This is where it gets a bit tricky. Not everyone should be able to see every bit of information.
Financial parts of contracts should be accessible on a need to know basis. But other operational parts like contact lists, SLA parameters and operation rules should be availyble to everyone involved. How to deal with that?

Records
In the course of your service manageemnt thrench-line battle, you tend to produce a lot of records. These can be records in your application database or nonstructured records like periodic or on-demand reports. Records, as well as documents, should be legible, readily identifiable and retrievable. Also, they have to conform to requirements for retention and disposal.

Application records- various service management applications will create records, probably in some kind of relational database.  By their nature, they are not too demanding for space, so they should be retained in operational state as long as needed, sometimes even longer.

If your Service desk application has trouble indenxing and operating a large number of records, you will move all your older data into an archive (warehouse) database in order to improve the application speed. This way you can easily access your history data for reporting purposes, and keep a swift application operation. Incidents, problems and changes historycal data can come in very handy when you get a request for a report of all the incidents on Apache server since 2007, and their relation to problem records.

Other, more practical use of long record retention would be very practical: disregarding the implemented Knowledge Management system, Service Desk analysts tend to search for existing incidents and problems in order to find a previous solution to an existing issue. 

Non-structured records are created every day, these are mostly electronic form documents acompanying the operative or reactive actions in service management. E-mail messages, written documents, spreadsheets and screenshots tend to take a bit more space. Nevertheless, they should be kept according to regulatory and statutory requirements, or longer.

The best location for them would be an indexed, full text searchable document management system, or at least a shared folder with an indexing option.

In the end, a piece of advice: anything you can do to avoid the overhead is a good effort. Auditors are reasonable people most of the time. If you have any kind of basic document management system with versioning and approval workflows, you should defend the existing functionality without additional work.

No use of keeping additional records, versioning tables, approval sheets and stuff if minimal requirements can be satisfied with what you got. Even if something is missing, the auditor will respect your willing not to fake the unnecessary records in order to keep your processes more efficient. Yeah, you'll get a nonconformity or two, a few improvement recommendations, but it will help you to move in the right direction. Have faith.

 

ISO/IEC 20000 and ITIL Timeline/History

“History is a set of lies agreed upon.” - Napoleon Bonaparte
“History will be kind to me for I intend to write it.” - Winston Churchill
"We learn from experience that men never learn anything from experience.” - George Bernard Shaw

After ITIL history and ISO/IEC 20000 history posts, this blog has received quite a few requests to create a parallel timeline for the two. We have finally made some time for it and the result is this fancy poster. It is nice to notice the interest of younger IT people for the historical evolution of ITIL and ISO 20k.


ISO 20000 and ITIL History

We did our best to collect and consolidate the timeline details from various relevant sources. I will be glad to correct it if someone from the audience notices any inconsistencies or new important events.

Since this one looks OK, I made it available as a PDF poster.

AXELOS - new name of the joint venture managing ITIL and PRINCE2 certifications

As we mentioned in a previous post, Capita plc and Government Office created a new joint venture to promote and manage ITIL® and PRINCE2® certifications.

On 1st July 2013 the joint venture has been launched under the new name - AXELOS.

 

CEO of AXELOS is Peter Hepworth who came from Activision Blizzard (Call of Duty, anyone?).

 

AXELOS will be the owner of the intellectual property of the Best Management Practice portfolio. It will manage licensing schemes, accreditation and support of examination institutes, training organisations, and consulting organisations.

 

Have a look at the official press release.

 

A few less known curiosities:

• On average one ITIL exam is taken every 1.5 minutes.
• ITIL exams are available in 21 languages in over 150 countries worldwide.

Let us all hope these latest development will turn out for the best of international IT Service Management community.

UPDATE: Axelos shows first signs of life. Have a look at http://axelos.gtml2.com/axeloslz/lz.aspx?p1=054481S1&CC=&p=1&cID=0&cValue=1, first strategy hints and some nice market research figures there.

Cabinet Office let the 51% of ITIL/PRINCE2 to Capita plc

Her Majesty decided to let the 51% of ITIL/PRINCE2 ownership to Capita plc, a company selected after an extensive procurement process to create a new Joint Venture organization. 

Cabinet Office will get 10 million pounds advance and three additional annual payments of 9,4 million pounds. In return, Capita will own 51% of a new Joint Venture (JV) organization. Government Office keeps 49%.

That's a lot of money. And this transaction opens a lot of questions, for all involved subjects. What will change for ATOs, authors of central and complementary publications, certified companies and individuals? Who will write new versions?

How is the new JV going to triple the revenue in next ten years? Who is going to receive the short end of the stick? Furthermore, why is Cabinet Office selling a piece of a golden goose?

We on ITIL side of the fence recognized the V3 and 2011 pumped up the pyramid of revenue-generation. Owner of ITIL will earn much more in this new frame. Is the government really that bad in managing money generators as ITIL and PRINCE2 after thirty-something years of experience?

Time will probably tell. But I have a huge problem with patience...

Customer Satisfaction Survey Grading

What grades do you use in customer satisfaction surveys? How are grades influenced by the culture of the country? What to do if you perform surveys in different countries with different background?

I have been discussing customer satisfaction here a few times. Related to that, let me share a brief anecdote with you:

We implemented a new Service Desk SW on a customer's site. They are a managed services company providing support all over the world, 24x7. After the resolution of every ticket, contact person on a ticket receives a mail notification with a link to a short web-based survey.

There were just a few questions regarding speed of resolution, communication, competence of support people and overall satisfaction with the ticket resolution.

Grades were 1-5, with the above explanation that 1=poor and 5=excellent.

We received quite a bunch of survey results at the beginning, which was the intention. Here and there, a low score was received, but we were not alarmed, you can't please everyone. Service Manager was in charge to treat all grades below 3 as a customer complaint and to follow up with customers to raise their satisfaction.

Then one day we received two very bad results, averaging below 2. Both from the same market. Alert! We are doing something wrong.

So Service Manager sent apologetic mail with a inquiry what went wrong and how can we improve, blah...
The answer came quickly, from both customers, saying they are sorry, but they thought 1 is better and 5 is poor.

Was something wrong with the survey code? Customers sent us their screenshots, everything is fine, the explanation at the form header clearly stated "1=poor and 5=excellent". Both customers were from Germany. On a request to explain how they misunderstood this clear instruction, they said: "German school grading system is 1 to 5, a one being the best grade (Sehr gut), and five the worst - insufficient (Nicht genügend)". So they didn't bother looking at explanations, they automatically presumed that this survey from another country complies to their long-term grading experience in German scholar system. Can't blame them.

Therefore we looked arround, what are grading standards in school systems around the world?

USA and influenced states use ABCDEF grades. Europe differs very much depending on history, somewhere 1 is bad, under the German skirt it is excellent (Chezh republic and Slovakia also).
Eastern European countries, Asia and Oceania use either Russian 1-5 system or percentage system 0-100%.

Interesting details:

• Venezuela uses rather exotic 0-20 grading system
• Ecuador and Serbia (opposite hemispheres) use similar 5-10 grading systems where 5=fail and 10=excellent.
• A lot of countries use different grading systems for primary, high school and university grades.

So what approach to take in grading customer satisfaction in order to make it intuitive regardless of their local education background?

 

We had only two solutions:

• Go to using 1, 2, 3, 4 grades, where customers won't be able to relate to their finer graded school system. 1-4 is also good because it eliminates the indifferent middle grade, and it forces a customer to decide for better or worse 2 or 3.
• Take the -2, -1, 0, 1, 2 grading approach. Good: it is self-explanatory, negative numbers can't be good. Bad: it leads the customer to a mediocre "0" grade, suggesting that it is OK.

For now, we are using the second proposed grading system, accepting the downside that some customers see nothing bad in selecting a "0", which is a neutral grade.

An additional tweak would be to change grades to -1, 0, 1, 2, which would "push" a customer towards positive grades some more.

What metod do you think is most apropriate for you?


Related articles:

Customer Satisfaction 
How bad do we need it in IT Service Management? Where is it mentioned and where is it dealt with in ITIL V3? How do we manage it in real life?

Customer Satisfaction Survey: What Methods To Use?
How to gather customer satisfaction data? What methods are there? What ITIL says? What methods will work for you?

ITIL 2011: Free Mind Map

Surprisingly lot of you people asked for my refreshed ITIL 2011 edition mind map.
Since you have seen pictures of it in my previous posts, you know I have it ;)   I've put it here for free download.


ITIL 2011 Mind Map

Mind you, this is still my working version, so please let me know if you find any typos or errors.




Of course, if you decide to dig deeper, I recommend buying a full set of books from TSO or Amazon.

Download my ITIL 2011 Mind Map here.

If you don't have a MindJet MindManager, you can have a look in flash here (it will ask you for a viewer installation). Hope you enjoy it!

ISO/IEC 20000:2011 Free Mind Map

For the last few months I have been working on an implementation of ISO/IEC 20000 with one of my customers. Quite a challenge, and it was a success! Before we started, I have created a simple MindMap with notes about requirements. So I decided to share it with you for free.

These are just short notes about structure and requirements, just to give you a quick picture on what to expect.

Of course, if you decide to hop on certification train, I recommend buying a full set of ISO/IEC20000 documentation, at least the requirements and guidance on the application of SMS which are published in 2011/12 edition.

You can download my MindMap for free here.

If you don't have a MindJet MindManager, you can have a look in flash here (it will ask you for a viewer installation). Hope you enjoy it!

Have a nice day.

ISO/IEC 20000-1:2011 Mind Map

ISO 9000 - ISO/IEC 27001 - ISO/IEC 20000: How do They Fit Together?

 -
With newly refreshed ISO/IEC 20000 alignment to ISO 9001 and ISO/IEC 27001, I thought it would be nice to have a set of more detailed information about relations between these three, all in one place.

Think, there is a great chance that a Service Provider aiming for 27001 or 20000 already implemented ISO 9001. And once we have two standards out of these three, how much more work is it to get the third one?

For new people here:

• ISO 9001 is a Quality Management standard
• ISO/IEC 27001 is an Information Security norm
• ISO/IEC 20000 is dealing with Service Management. It was developed on ITIL V2 basis and is now in a second edition. Have a look at posts:
• ISO/IEC 20000 Rediscovered
• ISO/IEC 20000 Brief History
• ISO/IEC 20000 Refreshed

If a company already adopted a Quality Management mindset from 9001, then going either for 27001 (Information Security Management) or 20000 (Service Management) is a natural thing. Usually the order of implementation is determined by local market demand and governmental regulation of the core business (Financial organizations, Service providers, military...).

Implementation of ISO/IEC 27001 brings a significant market advantage to a Service Provider, since it is often a requirement in tenders, especially in European countries. It will make you care about security, both yours and of your customer. In the beginning it will feel a bit restraining, but for a good reason. It will significantly reduce risks of losing contracts due to information security reasons.

ISO/IEC 20000 requires a broad specter of implemented processes, but if you are a service providing organization with some experience and knowledge of ITIL (could it be otherwise?), then it shouldn't be a problem. It will only make you define neglected or less cared for aspects and Service Management processes.

Here is a simple diagram I use in presentations to communicate a quick win-win feeling to the audience:

How ISO 9001, 27001 and 20000 overlap

And here is a table of more detailed relations.

ISO 9001 - ISO/IEC 27001 - ISO/IEC 20000 Mapping

This is still a working version of the table, but still pretty usable. Hope you enjoy it. If it displays too small for you when clicked on, you can copy it with rightclick and paste it to your favorite text or picture editor. Or, click here on my Google pages.

ISO/IEC 20000 Refreshed

As we all probably know, in February this year a new edition of ISO/IEC 20000-2 (Guidance on the application of service management systems) was published, following the last year's (April 15.) new edition of ISO/IEC 20000-1. Now that we have Requirements and Code of practice, we can talk more on what's new and how it fits in what we already have.

I would like to shortly outline main new moments that happened to ISO20k during last year.

First, as expected, standard is more mature and seasoned. After 5-6 years in production, bottlenecks and most of logic-defying points are corrected.

There are more requests (256 "SHALLs" vs. previous 170) but they are more reasonable, understandable and even somewhat less demanding then before.

Language is "internationalized", in a way that you don't have to be born in UK to understand most of it.

Also, terminology and content is made more compatible with ISO 9001 and ISO/IEC 27001 since these standards are likely to coexist in Service Support organizations.

ISO/IEC 20000 Process Schema

Some changes reflect a shy alignment to ITIL 3, although the overall concept indicates major divorce from ITIL altogether. Prior to pre-release info, this was a subject of guesswork: is the new edition going to be aligned to ITIL V3? So we got our answer-a firm NO.  It would be difficult to align to ITIL's new 'I want to be all and encompass everything' philosophy. So ITIL is now more aligned to ISO20k then vice versa.

Additionally, ITIL is now lifecycle-oriented framework of best practices (or wannabe best :) and ISO20k is a process-oriented standard, so the intentions behind each one are basically different.

Clause 3 Terms and definitions now has 37 terms instead of 15 from previous edition. Two items are removed: service desk, and change record. Service Desk since it refers to a function, and ISO20K is process oriented with no other organizational references.  Change record probably to remove potential ambiguity with ISO9000 records.

• Some additions to clause 3 are for additional compliance with ISO 9001: continual improvement, corrective and preventive action, customer, nonconformity etc.
• Some other additions refer to ISO/IEC 27000 family: information security and information security.
• Also a few are here to refer flirting with ITIL 3: service, service request, transition...

Previous clauses 3 Requirements for a management system and 4 Planning and implementing service management are now merged to 4 Service management system (SMS) general requirements. Introduction of SMS is the main indicator of alignment with ISO9000 (Quality Management System - QMS) and ISO/IEC27000 (Information Security Management System - ISMS).

ISO/IEC 20000 with number of SHALLs for every clause

Former Incident management now became Incident and service request management, one of small concessions to ITIL 3.

A significant tribute to ITIL 3 is clause 5 Design and Transition of new or changed services. Which represents a serious chunk of 20k, but that's about it, if we are looking for an expansion of ITIL ISO20K love story.

There is no release module any more, and Release management is now in 9 Control processes, logically  together with it's sisters Change and Configuration management, now called Release and Deployment management, just to be sure everyone understands what is it all about.

Catalogue of services is not just a recommendation in part 2, it is required in clauses 4, 5 and 6.

Clause 4.2 Governance of processes operated by other parties is added in order to make SP demonstrate management of his external suppliers and internal business organizations which participate in service delivery.

These are the basic changes I've noticed. My opinion: ISO/IEC20000 goes in the right direction. Requirements are more mature and aligned with the real world. ISO20k is a very useful formal framework for service improvement, aligned with industry best practices. Especially when used in synergy with ISO 9000 and ISO/IEC 27000. If you are a serious service provider (as my company is), then 20000 is the way to go. It is good for you and your company too.

ITIL Continual Service Improvement

CSI is not strictly a lifecycle stage, since it spans through all four other stages. It is mainly a set of Quality Management skills put together to make better Strategy, Design, Transition and Operation. Therefore the main tool is Deming's circle (Plan-Do-Check-Act) together with Seven-step Improvement process.

Continual Service Improvement relies also on change management and capability improvement methodologies. Everything is oriented to align processes from Strategy to Operation, and thus comply to changing business requirements.

Purpose

Purpose of ITIL Continual Service Improvement is to ensure IT Services alignment with business needs. This is  done via improvements to IT services through Strategy, Design, Transition and Operation stages. We want to improve effectiveness of service, process and cost.

Objectives

I will quote these in a best effort to provide quality info under 'fair use' terms

• Review, analyze, prioritize and make recommendations on improvement opportunities in each lifecycle stage
• Review and analyze service level achievement
• Identify and implement specific activities to improve IT service quality and improve the efficiency and effectiveness of the enabling processes
• Improve cost effectiveness of delivering IT services without sacrificing customer satisfaction
• Ensure applicable quality management methods are used to support continual improvement activities
• Ensure that processes have clearly defined objectives and measurements that lead to actionable improvements
• Understand what to measure, why it is being measured and what the successful outcome should be

Scope

• Overall ITSM health
• Alignment of Service Portfolio with changing business needs
• Organization maturity and capability
• Continual improvement of all aspects IT services and supporting assets

Value

• Continual service quality improvement
• IT Services alignment to business needs
• Cost effectiveness
• Identification of improvement opportunities in all processes via monitoring and reporting
• Identification of improvement opportunities org. Structures, resources, partners, technology, training and communications

Principles

Here are some Key principles:

CSI approach
It is a somewhat changed improvement approach from V2. here are steps and deliverables:

• What is the vision? - Align with business vision, mission, goals and objectives
• Where are we now? - Baseline assessments
• Where do we want to be? - Measurable targets
• How do we get there? - Service and process improvement
• Did we get there? - Measurement and metrics
• Feedback branch to beginning is How do we keep the momentum going? - Manage the implementation of improvement changes

ITIL Continual Service Improvement Mind Map

Service Measurement

Why do we Measure?

• To validate
• To direct
• To justify
• To intervene

Baseline - current state of CI used as reference value for future comparisons

Vision to measurements:

1. Vision
2. Mission
3. Goals
4. Objectives
5. CSF
6. KPI
7. Metrics
8. Measurements

The seven-step improvement process

This is the only process in CSI, as title says it consists of seven steps, nicely mapped to a Deming's PDCA cycle and Knowledge management DIKW cycle. Picture is worth 1000 words. Enjoy:

 CSI Seven-Step Improvement Process diagram

ITIL Service Operation

Finally! Service Operation is a real man's book. This is where it happens. Here we make money. All we do in Strategy, Design and Transition makes sense here. Service Provider does day-to-day activities of keeping the service available and customer happy.
If you are going to read any of the five books, my bet is that this will be the one. Since in the beginning we are all interested in consequences more than causes. 

Purpose
To do everything necessary for service delivery at agreed levels.

Objectives

• Minimizing the adverse impact of service outages on business activities
• Delivering and supporting the agreed services effectively and efficiently
• Maintaining access to services for authorized customers (and no one else)

Scope

• People
• Processes (Service Management)
• Technology
• Services

Value

• Reduced outage duration and frequency
• Operational results and data provided
• Enforcement of security policy

ITIL Service Operation Mind Map

Service Operation Processes:

Incident Management
Key process, one of the oldest Service Support processes. If you know anything about ITIL, odds are that you know Incident Management. It is in charge of restoring disrupted service as soon as possible.

Event Management
This process was added in V3 to address emerging use of monitoring tools in IT and describe the relation to Incident Management from V2.

Request Fulfilment
This is another offspring of the holly Incident Management, cause of many an internet forum discussion 'What is Request Fulfilment?" or likes.  Definition is simple: Request Fulfilment manages customer requests. Which by definition can be: requests for info or advice; for a Standard Change or for access to an IT Service. Simple. Have a look at article about password reset.

Problem Management
As opposed to Incident Management, Problem Management seeks underlying causes of one or more incidents and through lifecycle of known error-workaround-permanent fix,  strives to minimize the adverse impact of problems to the business process. Problem Management can be reactive and proactive.

Access Management
Another new one in V3. This is actually a process which spends a lot of Operations time - handling customer access rights . New users, approvals, identity statuses, logging and tracking, removal of rights.


Service Operation Functions:

Service Desk
The only function in V2, Service Desk is the single point of contact (SPOC) and an interface to a user for all communication with service support, all Operation and most of Transition processes. With accent to Incident Management, Request Fulfilment and Event Management.

Technical Management
Technical Management takes care of technology competencies. It identifies, develops and refines the knowledge needed to design, test, manage and improve the service. It also manages trainings and deployment of resources.

IT Operations Management
Operations Management does daily operational activities needed for IT Infrastructure management. It consists of Operations Control which performs routine operational tasks, and Facilities Management which manages physical environment.

Application Management
Application Management was a separate book in V2. It is responsible for managing Applications across their lifecycle (Requirements-Design-Build-Deploy-Operate-Optimize).

ITIL Service Transition

Service Transition is a stage which gives most pain to the IT Service Provider. Transition (add new, change existing, retire old service) is a source of many service disruptions. So we want our transition of service to be planned, built, tested, evaluated and deployed in an organized and controlled manner.

  

Purpose

To ensure that new or modified services are in conformance with business requirements, as defined in previous Strategy and Design stages, and that services which are no longer needed are properly retired.

Objectives

• Efficiently and effectively plan and manage service changes
• Manage change risks
• Release planned changes
• Manage expectations on new or changed services
• Manage accurate knowledge and info on changed services and assets

Value

• Better estimation of cost, timing, resource requirement and risks
• Higher volumes of successful change
• Reduce delays from unexpected clashes and dependencies
• Reduced effort spent on managing test and pilot environments
• Improved expectation setting for all stakeholders
• Increased confidence that new or changed services can be delivered to specification without unexpectedly affecting other services or stakeholders
• Ensure that new or changed services will be maintainable and cost- effective
• Improved control of service assets and configurations.

Scope

Creating new and changing existing services, implementing new and changed services, service retirement. Plan-build-test-evaluate-deploy.

Key principles

• Align service transition plans with the business needs
• Implement all changes through transition
• Adopt a common framework and standards
• Maximize re-use of established processes and systems
• Manage relationships with stakeholders
• Manage systems for transfer of knowledge and decision support
• Plan release packages
• Proactively manage resources across transitions

ITIL V2011 Service Transition Mind Map

Service Transition Processes:

  

Transition Planning and Support

Since Transition is so important, ITIL  defines the separate Transition Planning and Support process in order to manage and control changes and releases, from overall planning to specific transition resources management. The accent here is on standardization and best practices, managing of overall resources and helping with major changes and releases but not detailed planning of individual changes.

  

Change Management

Change Management is the key Transition process, and one of the key ITIL processes altogether. Since changes are the main cause of service disruptions, we want as much control of change as possible. In Change Management we ensure that all changes are recorded and evaluated. Authorized changes are prioritized, planned, tested, implemented, documented and reviewed. This way number of failed and unauthorized changes is significantly reduced, as well as number of resulting incidents and problems.

  

Service Asset & Configuration Management

This process was previously named Configuration Management and dealt with Configuration Management Database (CMDB). It looked and sounded too technical which scared off some new business-minded people in ITIL. In fact, Conf. Management was in charge of our knowledge of infrastructure: what do we have, where it is and how it works. To be more in spirit of the business aspect of this process, Asset management flavor was added, so now we follow lifecycle of IT assets from cradle to grave and actual info on this assets is available from all processes, any time.

  

Release and Deployment Management

Previous Release Management was the most difficult to explain in an "Elevator presentation", so deployment was added in order to enable Americans to get it quicker. It would be less confusing if it was called only Deployment management from the beginning. In a nutshell (or elevator :)) RDM deals with consequences of Change Management process: build, test and deployment of releases.

  

Service Validation and Testing

This one is a separate process since it is a discipline used throughout the lifecycle, mainly from Change and Release management. Service Validation and Testing will ensure that the service will deliver expected outcomes, and that it is 'fit for purpose' and 'fit for use' (Utility and Warranty, remember them from Strategy?).

  

Change Evaluation

This was 'Evaluation' in V3, and probably since no one knew what it relates to, they added 'Change' in 2011. So now we know it is a process which deals with evaluation of change. It is implemented to identify all predicted and unpredicted change effects. Smaller changes can be evaluated within Change Management, and for more significant changes (up to company to decide).  It is triggered before every approval point.

  

Knowledge Management

Knowledge Management was such a hype in 90's! Here in ITIL Service Transition, it is added as a nice to have process which is even in the foundations syllabus. General idea is to capture and manage knowledge as Service Provider's intellectual property. Methods are classic KM, I even recommend the reading since it is digest version of all I once knew about Knowledge Management.

ITIL Service Design

Service Design connects the Strategy with Transition and Operation, providing tools to create and redesign services aligned with strategic objectives. It takes care that service management is fully aligned with business needs and uses its capabilities in an efficient and resilient manner.

Purpose
To design IT Services in a cost-effective, secure manner and in accordance to Service Strategy, and to take care of designed service delivery having in mind customer satisfaction.
A set of design governance documents is defined: methods, best practices, procedures and policies.

Objective
Effective IT Service design using continual improvement methods, ensuring service alignment with existing and new business requirements.

Five Aspects of Service Design
deal with designing:
 • service solutions for new or changed services
 • management information systems and tools
 • technology architectures and management architectures
 • processes
 • measurement methods and metrics

Four Ps:
(we remember them as People, Processes, Technology from last version)
 • People
 • Processes
 • Products (services, technologies, tools)
 • Partners (manufacturers, supplier,  vendors)

Service Design Package (SDP)
Definition: "Service Design Documents defining all aspects of an IT Service and its Requirements through each stage of its Lifecycle. A Service Design Package is produced for each new IT Service, major Change, or IT Service Retirement"

ITIL V2011 Service Design Mind Map

Service Design processes:

Service Catalogue Management
Deals with management of information about all live services. Info has to be accurate and current.

Availability Management
One of the oldest ITIL processes, connected to SLM. Ensures that delivered services availability is in accordance with the agreed levels. Of course, in a timely and cost-effective manner.

Capacity Management
Another V2 veteran: Capacity Management wants to ensure that IT capacity (infrastructure and services) meets the agreed requirements in a cost effective (and timely, of course) manner. Capacity management spans through all ITIL lifecycles, since cost-effectiveness and efficiency are among the basic reasons for ITIL existence.

IT Service Continuity Management
IT Service Continuity Management (ITSCM) process is responsible for the alignment of IT services to Business Continuity Management.

Service Level Management
This is a matured key process, SLM ensures that all services are delivered as agreed. It is tightly coupled with other processes emerged from Service Delivery group. Main purpose of SLM is to improve communication and understanding of Business and Service Provider.

Design Coordination
New in ITIL 2011, this process became the central point of communication and control for all processes in Service Design stage.
Design Coordination process is in charge of all design activities, whether they are done through projects or Change Management. It ensures consistent design of services which are aligned with Service Strategy and will be properly prepared for Transition.

Information Security Management
ISM is a governance process which ensures that information security policy  is aligned with business security. ISM maintains and enforces the security policy.

Supplier Management
A fresh process which was probably introduced for better compliance with ISO/IEC 20000, same as Business Relationship Management in Service Strategy. Supplier Management ensures getting value for money from suppliers. All activities are included: negotiation, agreements, supplier performance management, seamless integration of underpinning contracts and delivered services.