Documentation Library

[Aesh]

I have been asked to work through the existing procedures in our Documentation Library and work with the various teams who are responsible to rewrite the ISO2000 documents to meet ITIL requirements and enter them into the respective sets.

While many of them now cross over ITIL area's, I'm at a loss how to manage the internal process documents, eg: Admin work instructions, correspondence log entries etc

[blamblam]

What to do with the non-ITIL work processes... and there can be a few. Most of the time you should be able to marry up many of the work instructions to an ITIL process but there are some which escape... such as Procurement, Meetings, Documentation Management (if the organisation is big enough).

An approach I have taken in the past is to group these functions together as "Other Service Management Activities" sought best-practice processes and given them the same look and structure as the ITIL processes.

When in the UK, I stumbled across someone who had created a concept of a DDL (Definitive Document Library) for Documentation Management. This was quite seperate from the CMDB (although some key documents were listed in the CMDB as they related to other CIs) as it's prime purpose was version control of all documentation and was controlled by a Documentation Management process. I know this is not strictly ITIL but I liked the idea and have since refined it.

In structuring the documentation I tend to group it into three main areas - Policies, Processes/Procedures and Work Instructions. Each is progressively more detailed, documented separately but reference each other.

Policies are the business rules that the organisation must adhere to, e.g. an IT Policy which says that no remote access is allowed. Processes/procedures (ITIL Processes) are the the framework while the Work Instructions are the detailed "how to do" specific things in working to the process. For example, instructions on how the business raises a RFC or how the support staff go about escalating Incidents.

The reasons for keeping these three groupings separate is twofold:
1. Ownership. They will invariably be documented by different people/parts of the organisation. Policies are often set by Senior Management or Corporate/Policy parts of the organisation. Processes/Procedures are directly in the IT area, while the work instructions will be reviewed by IT, in the case of third-parties or external service providers, the ownership and relevance of these documents will lie with these parties.
2. Version Control. As the documentation gets more detailed, the likelihood of change to the documentation becomes greater. Work instructions can change regularly and if these are rolled up into the same document as the Processes and Procedures, you could be looking at perpetual change. Try communicating that regularly to the rest of the business and you'll begin p**sing them off.

This entire process is managed through the Documentation Management process which captures the realtionship between documents, who owns them and is authorised to change them. I also feed changes to documentation through the Change Management process. The DDL is the register that tracks these documents and they are only entered into it when they go "live", i.e. are no longer draft. A spreadsheet will suffice for this.

Also remember that it is a many to many relationship with many of these documents. A policy may affect many process/procedure documents and, equally, a work instruction may also be relevant to many process/procedures documents.

This reply turned out a lot longer than I intended but I hope this has helped.