How to publish your QMS on your Intranet
	naming documents

chapter contents list

• introduction
• names and titles
• keep it simple
• some variations on the simple approach
• use the document name for the filename
• avoid overloading the name with information

introduction

This page is about naming documents and ways of referencing them.

There are as many ways of naming and referencing documents as there are companies. Everyone has his own scheme and preferences. This page gives some rules for doing this and the reasons for the rules. This is not necessarily the right way; it is simply one way of doing it.

names and titles

First, let's have some definitions.

document name

The document name is the short identifier by which (together with the version number) the document may be uniquely identified.

document title

The document title is the short textual description of the document which indicates the purpose or contents of the document.

So, for example, we may have a document whose title is "Report on the possible use of the intranet for the QMS". It might have a name of Rep1234.

The name is sometimes called the identifier or id.

keep it simple

We work on the principle that it is best to keep things simple.

We don't put any limitation on the document title, and we don't use it in our referencing system.

We prefer to keep the name as simple as possible. Avoid overloading the name with information; use it only as an index.

• So, don't include the version number in the name.
  A document is best thought of as a series of versions of the one basic document. The basic document is what has the name, so there is no place for a version number in the name. The full identity of the document would be, for example, Rep1234 version 2.
• Give the name a prefix so that it's clear what sort of reference it is.
  You could use "Rep" (being short for "report"); we prefer "Doc" (being short for "document").
  You might separate your QMS documents into Docs and Forms but this is not actually necessary (or even desirable).
• Make the rest of the name a serial number of defined length.
  It is usually sufficient to allow for up to 999 documents.
  Following from this, you would have names like Doc001, Doc034, and Doc123.
• It is best to include the leading zeros in the name as the names will then sort into the right order.
  If you were to use Doc1 instead of Doc001, when you sorted them (using any normal sorting rules) you would end up with Doc1, Doc10, Doc11, ... Doc19, Doc2, etc. This is, almost certainly, not what you want. Including the leading zero avoids this problem.
• Don't give meaning to blocks of numbers.
  You could allocate document numbers so that similar documents are grouped together, but don't make this a rigid part of your naming system. This is because, however hard you try, after a time, something will arise to cause you problems.
• Have a master list ordered in several ways.
  It's a good idea to have a master list of your documents, so that users can readily see what exists. Having a list in numeric order is generally a good idea. You would normally want to have the list hyperlinked so that users can go straight to the document they want.
  Here is an example of such a master list. [Note: its links won't work from here.]
  In addition, you can have additional lists (probably without the version number detail, so as to avoid the updating problem) which are ordered in different ways. For example: you might have a list which was ordered by job type, so that the documents relevant to a particular job type were grouped together. You could have duplication in that list where appropriate.

some variations on the simple approach

We've explained how to keep it simple, but there will be times when users or needs lead to a slightly more complex approach.

Some users like to distinguish between what they think of as different types of document. Apart from procedure documents (prefix Doc), there are forms (prefix Form), policy documents (prefix Pol), work instructions (prefix WI or prefix Work), training guides (prefix Guide), and so on. There can be no objection to that, if that is what the users want, but you should avoid it if you can, as often there will be no rigid distinction between such documents, and this could lead to rather sterile discussions about whether a document is actually policy or procedure. Using one prefix avoids the problem.

If you do adopt more than one prefix, you have two choices for allocating numbers.

1. You can use one series of numbers which is shared by all the prefixes.
2. You can have a separate set of numbers for each prefix.

In the first case, you might then have, for example, Doc001, Pol002, Doc003, Form004, Doc005, and so on. The benefit here is that there is not likely to be any confusion between Pol002 and Doc002 as Doc002 would not exist. A slight disadvantage is that if you sort the names, the order would be something like Doc001, Doc003, Doc005, Form004, Pol002, and so on. It would be hard to get them to sort into numerical order.

Overall, we prefer the first case, as it is best to reduce the possibility of confusion. Also, if you subsequently want to rename a document (for example, from Doc017 to Pol017), you only need to change the prefix; all else is the same.

use the document name for the filename

As the name is unique to a document, it would seem to be a good idea to use it for the file name. All you need do is add an appropriate file extension. So, Doc001, which is an html file, becomes Doc001.htm (or Doc001.html, most operating systems will accept either extension).

There may be files associated with Doc001.htm (for example, it may contain a .gif file as a diagram). Avoid the temptation to name this .gif file as Doc001.gif. At least call it Doc001a.gif.

Case can cause problems in file names. "Case" here refers to upper case and lower case. Operating systems differ in their treatment of case in file names.

• The Windows operating systems ignore case in file names.
  So, Doc001.htm is the same name as doc001.htm.
• The Unix operating system, its derivatives, and Linux do not ignore case in file names.
  So, Doc001.htm and doc001.htm are not the same name.
• On the Mac, on OS9, case is ignored. So, Doc001.htm is the same name as doc001.htm.
  OSX is like Unix (see above).

If you are working on Windows and are certain that you always will (is anything in the future certain?), then you have no cares (in respect of file names). Otherwise, you do. Some of the tools available for transferring files between machines (for example using the File Transfer Protocol, FTP) will make a mess of the case of file names. Some take the file name they get from Windows as being all lower case, so they transfer the file name as lower case. If your hyperlinks rely on mixed case names, then they won't work on the new system. The safest approach is to use lower case exclusively; alternatively, ensure that all the tools you use handle case as you want it.

avoid overloading the name with information

The simplest name is an index number; in this case, we name our documents 001, 002, 003 and so on, and we name their files 001.htm, 002.htm, etc. That is minimal.

There is the possibility that someone else has developed a series of files and that he too is a minimalist. He too might have 001.htm, 002.htm, etc. To avoid a clash, we name our documents doc001.htm and so on, hoping that he has used a different prefix. If he has used "doc" we can use qms001.htm and so on. The use of a prefix is not absolutely minimal, but it seems like a reasonable addition.

There is a temptation to load the name with more information.

The first temptation is to include the version number. So, we see file names like doc001v1.htm. The problem with this is that when you upgrade Doc001, and you give it a new file name (doc001v2.htm), none of your hyperlinks will work any more. You will have to check through all pages which refer to Doc001 and change them. Strictly, their version numbers will need upgrading, and so on. The minutest change will cascade through the whole QMS causing most of your procedure documents to be upgraded. So, don't put the version number in the file name. There are ways to get round this.

The second temptation is to include the department name or owner in the name. This makes the name longer. It is better to put this information in the master list rather than the file name in case the information changes. Suppose there is a re-organisation and the departments change. Do you have to change the file names? If you do, then again you have to go through all the QMS pages to check that there are no hyperlinks that need to be changed.

Any information that you put into the file name is subject to change. Any such change will cause you grief as you will have to check the hyperlinks. Avoid unnecessary information in the name. All you really need is the serial number.