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.
