Document

Considered by many to be necessary but not very exciting, documentation is often thought of as the housekeeper who cleans up after the party is over. It doesn't have to be like that. Good documentation can simplify complex detail and minimise operational errors.

For example, it can be used to:

Capture a baseline of your current processes, if you are about to go through an organisational change, where multiple departments and/or organisations are involved. In a case like this, you may need both an overview and some detail to inform different audiences. A useful method to use is a combination of linkage of process map, process definition and SIPOC. This can be done to multiple levels of detail if required.

Or to capture the detail of a complex process in a single map, usually A3 size or greater. This can be great for team discussions or workshops, where the "big picture" is needed along with sufficient detail to be useful. Also good when a process has a cast of thousands and a cross functional format is not feasible. Each process step can have its own set of identifiers and rating.

Or to provide multiple levels of process diagrams, from a top level "home", through to standard operational procedures with screen shots of software applications. If you have a complex process structure, there is an industry standard Process Classification Framework (PCF) which was created by the American Productivity and Quality Centre (APQC). It was primarily designed so that processes could be benchmarked between different organisations worldwide. Even if it is not fully adhered to in your particular application, it can provide useful insight into what should be included at a particular process level.

For creating process diagrams, there is another standard called the Business Process Model and Notation (BPMN), which along with the basics, has additional features which can display complex process steps in a small physical space, allowing more detail to be shown on a page. If you don't already use a specific format, it is a good one to adopt.

Create and Manage

The good thing about having comprehensive documentation is that you'll better understand how your organisation functions and you'll have a baseline from which to work. The bad thing is that you'll need to have somewhere to keep it all and a method of maintaining and displaying it to users.

There are a number of options available for document creation and management, ranging from a simple process diagramming application and a separate network file share, which could be suitable for smaller organisations, through to a comprehensive diagramming application with collaboration facilities, included data analytics and a document repository with version control, which could be suitable for enterprise level organisations.

There are also applications that can import data logs from transactional systems and automatically create process diagrams and analytics in order to model real time performance against theory. The possibilities are endless if you have the need and the budget.

Some considerations, for selecting applications for the most common usage of diagram creation and document management, are:

Create

• All diagramming applications include a range of templates and some allow extra ones to be imported. Make sure that it has the ones that you need. For example, for process related work, this might include both open and cross function (swim-lane) layouts, a general selection of drawing and flowchart objects, BPMN objects, Entity Relation, UML objects, etc.

• If you want to have multilevel processes then you will need a diagramming application that can link from an object in one process diagram to another process diagram or detailed procedure, which might be in a text and image format, in a separate location.

• Some diagramming applications are cloud based only and may not function without a network connection. Cloud based offers the possibility of greater collaboration between users and easier access, without the need for a desktop installation, whereas a dedicated desktop installation can be more flexible and cost effective in the long term. If on line collaboration during design is important, then check as to what extent this is supported.

• File import and output types can vary. If you would you like to import files from other applications then this might be important. Similarly, if you would like to output files in a specific format, like .pdf for example, then this option would need to be available. Some free diagramming applications limit file types to web biased formats such as .svg or .xml but free viewers are available for these.

• Licencing costs may depend on concurrent users, with each having the ability to create and modify diagrams. For cloud based applications, viewing only may not be limited but you would need to check in each case. For desktop installations, free viewers are often available or the diagram can be saved in a format such as .pdf, for viewing by those without the installed application.

• Detailed text and image procedures can be created in something like MS Word or similar, saved as a .pdf file. You would usually be referencing them via a link in a diagram.

Manage

• At a minimum, completed documents need to be stored in a secure, backed up location that has a capability for multilevel access control. This can be on a network file share, a specialised document repository or a cloud based application, where it may be included with the diagramming application, as part of the licence.

• Version control should also be implemented, either manually or automatically, the former being via a central register such as a spreadsheet (see note1, below) and the latter via a function within the document repository application. In either case previous versions should be stored and provisions made for only the current, approved document to be visible to general users. This is important, not only for it being good practice, but also being a requirement for some quality certifications such as ISO 9001.

• Although documentation is rapidly moving on-line, you may still need an option for printing hard copy. If this is the case check if this is possible from the stored or displayed file format. This should not be a problem with common formats such as .docx or .pdf but may present problems with viewers for less common, specialised formats.

• In addition to defining the usual create, modify, delete and view rights, all documents should have an assigned owner and approver. Again, this is good practice but it also prevents accidental changes to published documents.

Note1: This is a useful tip from personal experience. Any manual version control should ideally keep two identifiers for each document, being the document name and the file name. The reason for this is that changing the file name of a current document, to indicate a new version of that document, will break any links to the document and you'll waste a lot of time endlessly fixing links. It's better to keep the file name of a current document constant and use a separate document name, which should be included in the document itself and in the register, to indicate different versions. Previous versions can have their file names changed for each version, so that they can be easily identified and stored in an archive folder.