Free Downloads

ISO 20000: 2011
ITIL 2011 MMap

Request for Change (RFC) Template

Major Incident Report Template

ISO 20000/ITIL Timeline poster


Sponsored Links



Dec 21, 2014

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:

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).

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 :)

Dec 13, 2014

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:


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.

Dec 5, 2014

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.

Nov 26, 2014

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( 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.

Jul 15, 2014

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.

Graph: Service Management Document System
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.

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?

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.

Nov 23, 2013

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.

Jul 3, 2013

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, first strategy hints and some nice market research figures there.

May 2, 2013

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...

Mar 10, 2013

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%.

Customer Survey Grades

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?