There’s a lot of confusion and, dare I say it, waffle about processes and process mapping. Confusion because there are various definitions of what a process is and in its relationship with a system; waffle because everyone has their own idea – and I’ll admit to being no different. I have my own ideas and that’s what I’m going to write here. ISO9000 defines a process as a “set of interrelated or interacting activities which transforms inputs into outputs”. I’m not really convinced that helps clarify much – in fact, it introduces more confusion in overlapping a process with a system.
Another commonly used approach is to define a process as that which converts inputs to outputs. Less confusing but, again, I don’t think it helps much. It’s a bit like the TV weather forecaster saying we’ll get weather tomorrow – he or she is quite right (unless tonight is booked for Armageddon) but the forecast doesn’t help us plan for our picnic. Another problem with this simple approach is that, when we come to use it, inputs can include parts that don’t get converted into the outputs. However, by refining our inputs we can begin to make sense – enter IDEF0 and ICOM.
IDEF0 is one of a series of process mapping schemes that has a very specific set of rules covering its structure, syntax and use. IDEF0 can be used to produce a function model of a process or even a whole system; IDEF1 and IDEF2 cover information and dynamics models, respectively. I don’t plan to write a guide to the method, for there is plenty of that already available (just look on the web); it’s a good tool for producing detailed maps that actually help improvement projects, and I’d recommend spending some time trying it out, but for now I just want to pull out one aspect that can be used to explain a process. This is the ICOM format for the boxes:
- Inputs: what goes into the process to be converted to one or more outputs.
- Controls: what controls the process, ensuring the right work is done.
- Outputs: what we want to come out of the process.
- Machinery: the tools, equipment, people, etc., needed to actually run the process.
In this, we still have inputs and outputs but we also specify controls and machinery. One of the IDEF0 rules is that every process box must have:
- At least one output – else it adds no value, and
- At least one control – else it is, by definition, uncontrolled (and we don’t want that, either).
Some people will claim that it must have an input, because a process needs one to convert to an output, but it’s not hard to find examples that don’t. Take the response to an alarm signal – the alarm is a control that initiates an action. An argument that the alarm is an input can be countered by considering whether it is transformed into the output, and by the fact that it also controls when the process action takes place.
Using the method like this is very strict within IDEF0 but it is also a useful rule with less regulated mapping.