Branimir Valentic Many people identify ISO standards with a bunch of documents. Well, I have to admit that I understand that concern. If you just started reading the ISO 20000 standard’s requirements, it may seems that you will be busy with producing documents for some time. Maybe you will, but that’s also an opportunity to do more than just “produce documents.”
First of all, when starting the ISO 20000 implementation, you have to define your own approach toward documents, which needs to be created in the scope of your Service Management System (SMS) – what is needed (i.e., must have vs. nice to have), in which scope, in which order to write the documentation, etc. By doing that, you will make your life easier. So, let’s see how to decide which documents are needed and how to structure the SMS documentation set.
What do I need?
ISO 20000 doesn’t allow you to write the documents you’d like to and omit the ones you don’t. So, the logical question is – which documents do I need? To find the answer, ISO 20000 can be of great help. Why? Simply put, the standard requires that policies, plans, procedures, and records are documented. Further on, you will quite often find in the standard the word “documented” – meaning, you have to have recorded information for that requirement (either as a document or in the tool).
ISO 20000 implementation, and the number of documents and records you need to create, depends on whether you use a tool or not. What’s the trick? To be honest – there is no trick. If you have a tool, you will satisfy the need for recorded information (or documented information) for many ISO 20000 requirements. And, if you don’t use a tool – OK, but you will need many more documents to fulfill all the requirements. For example, if you have a tool, that’s where you will record your incidents and service requests. But, if you don’t use a tool, then you have to find another way to record them (because it’s required, as mandatory, by the standard). A spreadsheet will, at least for a smaller number of incidents and service requests, do.
The documentation set
When I first started implementing ISO standards, one of the main concerns was – the documentation. I considered ISO standards to be generators of (unnecessary) tons of documents. After a while, I realized that documentation does the following:
- Clarifies – Documentation is used to set clear rules as to who, what, how, when, etc.
- Supports decisions – Whenever you are not sure of the right approach (e.g., in the scope of the Change Management process) – check the documentation.
- Provides basis for improvement – Although it sounds like a buzzword, once you start documenting, e.g., procedures, you will start thinking about the activities, responsibilities, inputs, outputs, etc. And, very often, you will see that something can be done more efficiently.
Figure: Important elements when structuring SMS documentation
ISO 20000 does not require some particular approach for how to structure your SMS documentation. That’s the good news. The bad news is that it requires documents and records for all processes in the scope of ISO 20000. Here are a few elements that are important, i.e., can be useful when you try to structure your SMS documentation:
- Documentation structure – Make your policies, procedures, and process description from the same template. In this way, it will be easier to navigate throughout the documentation set.
- Sequence – ISO 20000 consists of two major parts: SMS requirements and processes. That’s also a good sequence when writing the documentation; i.e., make SMS setup-related documents first (e.g., SMS policy, SMS scope, etc.), then the process documents and lastly, the documents needed for internal audit and management review.
- Content – ISO 20000 defines some mandatory requirements for policies, i.e., procedures. This means that your, e.g., Change Management procedure needs to define how to handle emergency changes. That’s the easier part because the standard explicitly sets requirements. But, you will also have to include some non-mandatory elements to make your procedures applicable to your organization. For example, the standard does not define how to trigger the Incident and Service Request Management process. So, depending on your own situation, document it. That will make that process clear and unambiguous.
The number of documents and amount of details inside them will vary depending on the company size:
- Smaller companies will try to make the fewest documents possible to avoid overkill. They will also combine policies and procedures as one single document.
- Larger companies are more complex in structure and the processes in place, so they will require more detailed documents. In some situations, policies will be stand-alone documents apart from the procedure description.
Document for the sake of – documents?
If you create documents just to have them on your list, i.e., because the standard requires that you have them, I have to tell you – you wasted a lot of effort. Even more than that, you missed the opportunity to set your processes in a managed, i.e., transparent and controlled way. What I prefer is the other way around – if I have to implement a certain process, it’s in my best interest to make it as usable as possible.
Such an approach is beneficial because, in such way, I have put in writing what we are living inside the SMS. In this way, I always get a better overview of how things are set, what is good, what could be improved, etc. My colleagues know exactly how we work and my users feel the effect of an organized and managed SMS. If that makes them happy and satisfied, I assume feedback from my management will make me even happier. Who wouldn’t want that?
Use this free List of mandatory documents to see which documents are mandatory if you want to be ISO 20000 compliant.
