Free Downloads

MindMaps:
ISO 20000: 2011
and
ITIL 2011 MMap
 

Templates:
Request for Change (RFC) Template

Major Incident Report Template

Posters:
ISO 20000/ITIL Timeline poster

    

Sponsored Links

 

Google

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


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.

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.
 

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


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?

Aug 17, 2012

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

Jul 10, 2012

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

Apr 18, 2012

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:

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:
Overlapping ISO 9001, 27001 and 20000
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
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.