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.

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.

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.

ISO/IEC 20000 - A Brief History

From DISC PD 005 over BSI 15000 to ISO/IEC 20000. Specifications, requirements, Code of practice.

History is a myth that men agree to believe.
Napoleon

ISO/IEC 20000 Timeline

I have been looking around for some brief document with ISO/IEC 20000 history, and I could not find anything useful.

Here are a few major points I have collected from various sources in ISO/IEC 20000 history.

1995: British Standard Institution (BSI) published the first version of DISC PD 0005:1995 - Code of Practice for IT Service Management. It described only four basic ITSM processes.

1998: BSI publishes a revised version of DISC PD 0005:1998 and it already described all five process areas and 13 processes as we know it today.

2000: Published BS 15000:2000 - Specification for IT Service Management which was used together with the code of practice DISC PD 0005.
Also in 2000, the third supplementary document entitled DISC PD 0015:2000 IT Service Management Self-Assessment Workbook was published.  It was a questionnaire that enabled anyone to make an assessment of its compliance degree with BS 15000.
Some serious revisions and rewriting followed, resulting in standard documents very similar to today's norm:

2002: BS 15000-1:2002 IT service management - Specification for Service Management;
PD 0015:2002 - Self-Assessment Workbook

2003: BS 15000-2:2003 IT service management - Code of Practice for Service Management
The same year a new PD 0005:2003 Guide to Management of IT Service Management was published with explanations of the purpose of BS 15000, and also the framework guidance on how to use the standard processes and implement them.
BSI 15000 was adopted by many service companies in UK, and countries worldwide accepted it.

2005: BS-15000 was placed on the “fast track” by the ISO. By the end of the year, with some moderate changes, it was published as ISO/IEC 20000 standard:

• ISO/IEC 20000-1:2005 Specification  is very formal, it defines processes and provides assessment/ audit criteria.
• ISO/IEC 20000-2:2005 Code of Practice that gives HOW-TOs and describes best practices for implementation of Part 1.

Standard was unchanged for four years. Adoption was a bit slower due to somewhat lower ISO maturity level of the standard. The norm requirements were very demanding, and supplemental documentation was scarce and sometimes ambiguous. There was a need for some additional documentation:

2009: ISO/IEC TR 20000-3:2009 Guidance on scope definition and applicability  was published. It provided guidance on scope , applicability and of conformance for service providers

2010:

• ISO/IEC TR 20000-4:2010 Process reference model - describes  the service management system processes implied by ISO/IEC 20000-1 at an abstract level.
• ISO/IEC TR 20000-5:2010 Exemplar implementation plan for ISO/IEC 20000 -1 - provided guidance  to implementation of ISO/IEC 20000 by example and advice.

2011. April:  ISO/IEC 20000-1:2011 - new version of specification is out.

2012. February: ISO/IEC 20000-2:2012 - new Guidance on the application of service management systems published.

If someone has an update or a correction to this, I will be very glad to update the post. Thank you.

Related posts:

ISO/IEC 20000 Essentials
A few more words on ISO/IEC 20000

ISO/IEC 20000 Rediscovered
Describing differencies and similarities of ITIL and ISO/IEC 20000

ITIL and ISO/IEC 20000 Compared
ITIL V2 - ITIL V3 - ISO20000 comparisson table

Hope this helps. Have a nice day!

ISO 20000 Rediscovered

"It is easier to do a job right than to explain why you didn't. "
- Martin Van Buren -

If we browse thru brief ITIL history, we can see that ITIL (or its basic concepts) was present in IT since the wheel invention. There lies the key to its popularity in IT service business. What can an IT business do to improve it's functioning, but turn to ITIL, or some of its derivatives, like MOF or ISO/IEC 20000? You educate and certify people, define your functions and processes and introduce tools for their automation. And then you are ITIL compliant. Or not?

ITIL is best practice guidance. In the V3 it becomes a bit more prescriptive, but still it stays a framework that basically tells us WHAT we SHOULD DO. In ITIL V3 there are some more ideas on HOW, but that's not its forte. You can define everything by ITIL recommendations, and it can help you a lot in your Service Management work, but you are still not ITIL compliant. Because there is no such thing as ITIL compliancy. You can measure your processes and report on them all you want, but no one guarantees that you made it there.

An international standard for IT Service Management, ISO/IEC 20000, is heavily based on ITIL. It deals with most important ITIL processes, but also adds some new. It defines requirements and code of practice for ITSM, and also provides the tools for assessment and audit of the system.

By ISO 20000, use of ITIL is not mandatory, but since 20000 is by its nature above ITIL in the pyramid, implementation and certification is much easier (read: “only possible”) if it is ITIL supported. ISO 20000 requirements are very short, not much juice there. HOWs and SHOULDs are in ITIL, SHALLs are in ISO 20000. So know your ITIL.

Also, it doesn't hurt if a company is ISO 90000 certified. You know, mindset and experience...

So, a possible path of implementing ITSM is combination of ITIL and ISO 20k: You define the phases of implementation with processes according the pain you feel in your processes. Also you implement ISO 20000 Plan-Do-Check-Act methodology and metrics for every considered process. Educate people, define the scope, processes and roles. Implement automation tools. Check. Act…

A tiny catch: ISO 20000 requires full frontal coverage, all processes have to be implemented. Scope can be limited only to a specific customer or part of organization. But you can keep your ITIL phased implementation, process by process, or in groups of processes. Apply what ITIL tells you, and implement what ISO20000 requires in each phase. In the end, you have a Service Management organization functioning on best practice principles and ready for ISO20000 certification.

ITSM pyramid

Certification
ITIL Qualification Scheme is for the people. Companies are not certified. Example: my company certified a bunch of people in ITIL Foundations 5 years ago. 95% of them left the company since then. In the meantime, we recognized the cost of repetitious certification of new employees. So we developed internal informal ITIL training, to support our business needs and processes. Only higher positioned people get formal ITIL certificates. We created internal support policies, procedures and work instructions, some of them included in our ISO9000 QMS, some external.

Now, ISO/IEC 20000 provides certification on a company level. External auditor (Registered Certification Body) conducts the review, and if the company meets the certification criteria, it can be certified and display the logo.

So if a company wants to be competitive, and introduce order and best practices in their service business, it should definitely think about ISO/IEC 20000 certification.

ISO20k doesn’t introduce much overhead, it just tells you in advance what things shall be done eventually, and keeps you from wandering in the dark. If implemented right, certificate should be a bonus, not the target.

Related posts: ITIL ISO/IEC 20000 Compared : ISO/IEC 20000 Essentials : Implementing ITIL and Staying Alive

ITIL - ISO/IEC 20000 Compared

General Comparisson
ITIL V2	ITIL V3	ISO 20000
Best Practice	Best Practice	Standard & Code of Practice
Individual Certification	Individual Certification	Certification of a Service Provider Organization and individuals (lately)
Best practice guidance, detailed description and implementation guidance	Best practice guidance, detailed description and implementation guidance slightly more prescriptive then V2	High-level requirements
Defines process and function roles and responsibilities	Defines process and function roles and responsibilities	Org. structure independant, defines few mandatory roles
Process based, 10 processes & 1 function	Service Lifecycle Based, 26 processes, 4 functions	Continual improvement based, 16 processes, no functions
Processes & Functions
ITIL V2	ITIL V3	ISO 20000
Planning to Implement Service Management	Continual Svc. Improvement	Planning and Implementing Service Management
Service Delivery	Svc. Strategy, Svc. Design, Continual Svc. Improvement	Service Delivery
Service Level Management	Service Level Management	Service Level Management
Service Reporting	- Reporting from SLM -	Service Reporting
Financial Management	Financial Management	Budgeting and Accounting for IT Services
IT Service Continuity Management	IT Service Continuity Management	Service Continuity and Availability Management
Availability Management	Availability Management
Capacity Management	Capacity Management	Capacity Management
- demand management from Capacity Management) -	Demand Management	-
Security Management	Information Security Management	Information Security Management
Service Support	Svc. Operation	Resolution Processes
Incident Management	Event Management, Request Fulfilment, Incident Management	Incident Management
Service Desk	Service Desk	- No functions in ISO 20k -
	Svc. Transition, Svc. Operation	Controll Processes
Configuration Management	Service Asset and Configuration Management	Configuration Management
Change Management	Change Management	Change Management
	Service Transition	Release Processes
Release Management	Release and Deployment Management	Release Management
	Svc. Design	Relationship Processes
-	Supplier Management	Supplier Management
	Svc. Strategy, Svc.Design, Svc. Improvement
	Parts of Service Portfolio Management, Service Level Management and Continual Service Improvement	Business Relationship Management

ISO/IEC 20000 Essentials

In a previous post I announced a few more words on ISO/IEC 20000. So here they are.

ISO/IEC 20000 is an international functionally based standard for IT Service Management. This functionally based means that it is not a broad general standard like ISO 90000. It was published by ISO (International Standards Organization) in mid December 2005., evolved from BS15000 with only a few minor changes.

HISTORY
During the ‘80s British Standard Institute’s Service Management Group worked on a code of service management practices, which covered 13 basic processes, aligned with the first version of ITIL. Final version of this code was promoted to a standard and published in 2000 as BS15000. It was the first world’s standard for Service Management. After initial testing on early adopters, additional polishing and changes for realignment with ITIL V2, it was republished in 2002. It was adopted by many service companies in UK, but also companies worldwide accepted it.

In 2005, BS-15000 was placed on the “fast track” by the ISO. By the end of the year it was published as ISO-20000 standard.

ISO/IEC 20000 and BS15000 are practically the same, only a few less significant changes were made in the process.


UNDER THE HOOD
ISO/IEC 20000 consists of two specifications: ISO/IEC 20000-1:2005 and ISO/IEC 20000-2:2005.

• ISO/IEC 20000-1:2005 is Specification and it defines Requirements for ITSM. Part 1 is very formal, it defines processes and provides assessment/ audit criteria.
  
• ISO/IEC 20000-2:2005 is a Code of Practice that gives HOW-TOs and describes best practices for implementation of Part 1.

The standard introduces elements of Quality Management (Plan-Do-Check-Act) in Service Management. Some parts of ISO17999 (ISO standard for internet security) are added. Also it is very much aligned with ITIL and speaks the same language. Basic ITIL processes are described and grouped in a following way:

1. Service Delivery:

• Service Level Management
• Availability Management
• Capacity Management
• Continuity Management
• Budgeting and Accounting for IT Services (Financial Management)
• Information Security Management
• Service Reporting

2. Relationship:

• Business Relationship Management
• Supplier Management

3. Resolution:

• Incident Management
• Problem Management

4. Control:

• Configuration Management
• Change Management

5. Release:

• Release Management

ISO/IEC 20000 Process Groups Model

WHO IS IT FOR?

All service oriented companies, and in particular for business organizations that provide IT services.

The way I see it, if you provide IT services, you need a fine balance of ITIL and ISO20000. ITIL gives you competence, and ISO20000 tells you how competent you are, protects company’s investment and knowledge, and gives you competitive advantage on the market.


CERTIFICATION
Certification Scheme for ISO/IEC 20000 is created and managed by itSMF. To formally confirm compliance with the norm, independent assessment can be performed by an itSMF Registered Certification Body.


ISO/IEC 20000 and ITIL
ISO20000 and ITIL are complementary, in a sense that:

• ITIL is a best practices framework which enables business organizations to establish a common language and understand + establish essential ITSM processes. ITIL says how things SHOULD BE.
  
  
• ISO20000 is a standard that enables business to implement and measure best practices. The main point is that the norm helps to objectively test if those practices have really been adopted. It says how things HAVE TO BE. And who is responsible if they aren’t.

Did ITIL V3 Ruin Everything?
In May 2007 ITIL V3 was published. Did this create a lack of balance between the two?
ISO20000 was aligned with ITIL V2. To be a true quality standard it had to adopt some ISO90000 and develop/evolve some processes. Primarily, it implemented Deming’s P-D-C-A lifecycle for continual improvement.




ITIL V3 caught up with ISO 20000, it is also lifecycle oriented, it adopted some of ISO20000 methods (PDCA) and processes (Security, Supplier Management and Service Reporting). In some aspects, we can say that ITIL and ISO20000 are more aligned now then before.

On the other hand, ITIL V3 significantly evolved in some higher level aspects. ISO will have to revise 20000 in the following years to anticipate this. But that doesn’t mean much to companies that are making first steps in standard adoption, since the early implementation path is focused on the basics, anyway.

ITIL gained a lot of popularity with IT professionals due to its earlier appearance, individual approach and market value for consulting/training companies. Last year's ITIL V3 hype also contributed to it.
Adoption of ISO20000 on the other hand, is a bit slower since it's primary value is to the company, and mixed individual interests of the stakeholders probably slow it down. Also it is more formal and strict, so that can scare away some businesses. With time, it will probably change, at least in companies that are really interested in return of their investment.

Related posts:
ITILV3: What's New?; ITIL V3 Qualification Scheme; Implementing ITIL and Staying Alive

And remember, last week I have put a few mindmaps for you to download:

• ISO/IEC20000 Specification Mind Map
  A set of requirements.
  
  
• ISO/IEC20000 Code of Practice Mind Map
  Guidance and recommendations on quality standards for ITSM.

Implementing ITIL and Staying Alive

At first sight, ITIL implementation path depends on who you are and what you do. And of course, with what do you do it. So: People, Processes, Technology.

At the beginning, let's move one starting dilemma out of the way: full frontal or phased approach? Phased, period. Strategically, you will have in mind full set of processes. But when you start, you want to dig deep and narrow, not broad and shallow. Hit the major pain points, ensure quick wins, and fly on the wings of starting success. This will enable you to move forward easier.

Critical factor number one? Management support. A lot of it.

From What Angle?

• You can try to imagine a well-organized company whose major pain is to know what it has, where it is and how it works. They have a stabile infrastructure with a low incident rate, and their Service Desk copes with it fine. But they implement a lot of changes and they want to gain more control over the Change and Configuration management. Of course, this is a fairy tale company, since a lot of hanges automatically means a lot of incidents, but just for the sake of the argument, this imaginary company would start it's ITIL journey in Change and Configuration Management.
  
• Or, maybe you are in a bank. Security is probably one of your biggest concerns. Maybe you want to start with Information Security and Access management. Depending on your country regulations, maybe you will even start ISO27000 certification. In some parts of the world it is a very likely case.
  
• Some service organizations with a high-end infrastructure (ASPs?) will be focused on geting their services definition right: Catalog, Portfolio, Demand, Suppliers, SLM...
  
• But, in nine out of every 9.1 cases, you are firefighting. In incidents up to your ears. Your left doesn't remember what your right has just done. Your customers are pissed. And because of the chaos you're in, you turned to ITIL. So you start from Incident Management. What a cliché.

So you decided to implement ITIL. How?

Simple: first you get a few ITIL Foundations certificates. Then you realize that you need a magic wand. What? Something to do the job for you. So, you realize that it is the tool that will take you on a journey. Of course, the TOOL.

You read some Gartner reports, evaluate some tools, and choose the best salesmen of evaluated tools. His implementing team is ITIL certified, his Tool is all Pink and shiny. Sadly, but this is usually the most critical point on your way.

You probably chose a good application, since most of the tools on the market are adequate for first steps in ITIL. At the end of the day, and at the beginning of your project, it all depends how good is your vendor. Because at most cases, he will be your ITIL consultant, too. So look closely. References, team certification, staff fluctuations.

To add some odds to your side, at least at the first phase of your project, hire an independent consultant. If you can afford one. This will probably save you a lot of effort, and eventually your job.

P.S.: If your company has ISO9000 certificate, it will be relatively painless for you to start preparing for ISO/IEC20000. You can implement the tool and ITIL processes, you can certify your people, but ISO 20000 offers you the mechanism for process definitions and audits. More on ISO/IEC20000 later, for now I've put a few mindmaps for you to download:

• ISO/IEC20000 Specification Mind Map
  A set of requirements.
  
  
• ISO/IEC20000 Code of Practice Mind Map
  Guidance and recommendations on quality standards for ITSM.