Working In Uncertainty
Diagrams for controls work
First published 31 October 2003.
Why diagrams matter
It's possible to evaluate or design internal controls without properly understanding how the underlying process and systems work, but it is not a reliable approach. You can use Internal Control Questions (ICQs) or just go with the issues interviewees raise with you, but the danger is that you will misjudge risk levels because the process and systems don't work the way you imagine or the ICQs assume. For example, it may be that getting data from a billing system to the nominal ledger is not the single step you imagine, but instead the data passes through two other databases and a spreadsheet before it hits the nominal ledger. Unless you know you can miss potential problems on that pathway.
Assuming you decide that a description of systems and processes is needed, there are ways to do it without diagrams, some of them excellent though they usually need skill to create and to read. However, most people prefer diagrams, so diagrams it is.
Unfortunately, many diagrams turn out to be less useful than they should be. If you're running a project that involves several people or teams producing diagrams to support an evaluation of internal controls you may recognise some of these common issues:
The following sections suggest methods of minimising all these problems. (Incidentally, if you want to master the skill of drawing diagrams like this you should consider engaging me for some individual technical tutoring or teletutoring sessions. This is the quick and easy way to do it thoroughly.)
Whatever style of diagram you choose there are certain simple guidelines that help improve clarity. Here are some common faults that make diagrams unclear, and recommendations for avoiding them.
Solution: Encourage people to base their diagrams on reality and do not accept conceptual fudges. For example, if doing a data flow diagram it may be helpful to identify process boxes with computer applications.
Solution: Insist that every box and every line has an explanation on it written in just a few words with the minimum of jargon. For a process the explanation should say what is happening in the process. For a data flow the explanation should say what data is flowing. For example, a computer system called GLADYS that creates purchase orders could have the text ‘GLADYS (create purchase orders)’. Now, anyone reviewing the diagram knows to expect to see purchase orders coming out of it, and probably requisitions and various types of reference data going in.
Solution: Don't make up notation without a very good reason and provide a key.
Solution: Move from start to finish in the same general direction, such as left to right, or top to bottom. One approach is to put transaction data going in one direction with reference data coming in at roughly 90 degrees to it.
Solution: There are two good alternatives. The first is ‘levelling’ i.e. putting the diagram onto more than one level of detail. Each box at the top level can, potentially be exploded into a diagram at a lower level. In some drawing tools you can set up hot links so that this is done with a click on the icon. The second technique is to separate the information you want to show on the basis of the events that trigger the processes you are showing. For example, you could do a picture to show what happens for new sales, and another for sales returns. Usually it is possible to keep the basic layout but change the arrows and explanations.
To show the effect of improving clarity, here's a makeover. Click on ‘Before’ and spend a few seconds trying to work out what is going on, then close it and click on ‘After’. It should be much easier to see what is happening, so spend a few more moments thinking about what might be missing from this diagram. Creating diagrams that are clear enough to be reviewed for gaps and anomalies is vital.
The last thing you want is for people to spend weeks on diagrams and have nothing useful from them until all the work is finished. Fortunately, it is easy to break the work into incremental deliveries, allowing you to learn from what has been done and to stop the work once you decide there's not much to be gained from going further.
The first goal should be to produce pictures of the underlying task, free of the details of any controls that may be involved. For example, if the data on a paper document has to be input to a computer system that is what you show, ignoring details of how it gets sent around departments gathering authorising signatures before the input takes place.
Besides being much quicker to do there are two other reasons for doing this:
Next, make a list of the events that the process responds to (e.g. a new sale, receipt of cash, receipt of credit note) and start with the ones that diagramming will be most useful for. These will usually be the high volume events, but remember that there are also low volume reference data updates such as changes to sales tax rates that can be extremely important.
Another way to divide diagramming into incremental deliveries is to add layers of detail in stages. For most review work this is not necessary as detailed diagramming is not needed at all. However, for some design work you might want to do more detail and that can be done as a separate delivery once higher level pictures have been done and shared with others who can use them.
Diagrams should directly support later stages in your work. That may involve some careful thinking about the task and what you need from diagrams.
In ‘The easiest and best matrices for documenting internal controls’ I explain one method of risk identification that is useful when your main interest is ensuring that information is processed reliably. In this technique the processing is sliced into steps, each one being (a) across a process, or (b) across a dataflow (including data capture and data output flows). For each step you then look for controls covering completeness, accuracy, validity, and any other control objective of interest. Obviously, a diagram in terms of processes and dataflows makes this easy.
It helps to ensure accuracy and usefulness if you try to base your diagrams in physical reality. Look for computer applications, databases, computers, paper forms, and reports. Find where data resides and where it moves and show those stages.
Let's imagine you've laid down rules for clarity, rules for icon styles, the diagramming style, and what software to use. You've agreed with everyone that the first stage is to document the underlying task. What can go wrong? Usually it's interpretation and level of detail. Ask people for a ‘process description’ and be amazed at how many interpretations of ‘process’ there are.
Here are three ideas for consistency:
Looking back at the many diagrams I've seen over the last decade only a handful have been clear and useful. The vast majority have been seriously flawed in one way or another and that means effort was wasted. This is not necessary and the rules of clarity suggested above should help.
Many companies do not have diagrams on the grounds that it would be too much work, but using the ideas described above to control the level of detail should make it much more cost effective.
Hundreds of people receive notification of new publications every month. They include company directors, heads of finance, of internal audit, of risk management, and of internal control, professors, and other influential authors and researchers.
Please share: Tweet
Words © 2003 Matthew Leitch. First published 31 October 2003.