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.



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.