Lean Documentation 2

System Analysis (1) – Document Creation

A well-run documentation system will support your business processes and improvements, not hold them back.  How do you ensure that this is the case?

Let’s look first at what is required of a good documentation control system:

1.       Documents must be version-controlled, with traceability on all changes.  You have to be able to demonstrate which version you were using on a particular date, and, essentially, ensure that everyone is using the correct version.

2.       Review and approval cycles need to be well-managed.  This is a hard-copy problem, almost always solved to some extent by using electronic workflow systems.  It’s remarkably easy to ‘lose’ a document during an approval cycle, creating delays and increasing the risk of version control problems.

3.       Information must be easy to retrieve.  There’s no point recording everything you do if the information is not readily available at a later date.  For example, one site found that it was reversing changes made a few years previously because there was no easy way of querying earlier change controls.

4.       There should be few opportunities for human error.  This is a more subtle requirement.  You will never eliminate human error entirely, but you can reduce the chance of it happening, and increase the probability that errors are caught at an early stage.

5.       Interactions with other systems must be well-managed.  Systems rarely operate in isolation and points of interaction are prime points for error and inefficiencies.

And, of course, everything you do must comply with the current applicable regulations.

Before you can start applying these principles, you need to know what you have already, and where there are opportunities for improvement.  One approach is to map and analyse each documentation system – and how they interact.  Let’s look at a simple SOP system.

Step 1: Map your system -- overview

Use standard flowcharting techniques to map, firstly, the creation/update and review/approval process and, secondly, hard-copy distribution (if applicable).  It’s useful to start with an overview (Fig 1) then map in more detail.

Fig. 1 Overview of SOP creation and update

Step 2: Map your system -- detail

Now look at each part of the system in more detail.  To keep it simple, we’ll look at an approval cycle (Fig. 2).

Fig. 2 Document approval

To add detail to this, we need to ask ‘what if?’ at each point.

·                What if Approver 1 decides that another change is needed and he can’t approve it?

·                What if Approver 2 loses the hard copy?

Assuming the author starts off by physically handing the hard copy to his first approver (because he has an interest in keeping things moving), and that the ‘what ifs’ can occur with any approver, the flowchart now looks like this (Fig. 3):

Fig. 3 Document approval in more detail

It’s relatively uncommon for documents to be passed from hand to hand: they are more often sent via internal mail or left in someone’s in-tray, where they can easily be mislaid.  So the author, chasing his document after 2 weeks, is told by Approver 1 that it was passed to Approver 2 a week ago, but Approver 2 denies all knowledge of it.  The author has to spend more time - an unnecessary waste - communicating with Approvers 1 and 2 until the document finally comes to light.  It may not reappear at all, in which case the author has to recreate the final draft and start the approval cycle again, with the risk of the original reappearing at some point.

This system doesn’t look quite so ‘in control’ now, does it?  And there are other, less common, ‘what ifs’.  What if the approver leaves the company or goes off sick before s/he can approve?  What if an external influence means that the author has to pull the document out of approval to make another change?  What if two or more of these ‘what ifs’ occur concurrently?

Step 3 – Identify your risks

The ‘what ifs’ form the basis of your risk analysis.  In this case we are analysing primarily for inefficiencies and opportunities for error.

This process is blatantly inefficient as it is linear: because there is necessarily a single copy for approval, it is sent to each approver in turn.  This would work reasonably well if each approver (having, of course, already participated in the review cycle) signs promptly and passes the document on.  In practice, this very rarely happens.  Using the example above, Approvers 1 and 3 might sign within a week of receipt, but Approver 2 might take 3 weeks, perhaps because he’s been away, is extremely busy with other things, or is just the type of person who takes a long time to process documents.  So the whole approval cycle takes 5 weeks - a long time by anyone’s standards.

What about opportunities for error?  We’ve already mentioned loss of the hard copy.  Occasionally, there may be an urgent need for a change to the document while it’s still being approved (one of the less common ‘what ifs’).  Now the author has to locate it, make the change and restart approval.  But, if the original has been mislaid, there is a huge compliance risk.  Because the document hadn’t had its final approval before the new change, the version number remains the same for the newly-changed document, so there are now two different documents, bearing the same version number, both in the approval cycle.  The risk of the wrong version being distributed is great, particularly if the author is not managing approval himself, but is relying on an administrator to do so for him.

How robust is your system?  Does it stand up to non-standard and unforeseen events?

In the next report we’ll use the same type of analysis in looking at how a system interacts with others, and start closing some of the gaps.

To see a full list of features by Joanna Hills follow this link to her introductory feature and scroll to the end of the article:
GLP, GCP, GMP, SOP, too many documents?