Many businesses and business people care assiduously about processes. They have whole departments qualified as six sigma specialists or some other quality system to map and continuously improve processes. Many other businesses care little about processes. When they try to map their processes they get confused between activities, KPIs, processes, policies and parameters.
Most of the time the effort is not worth the reward as the process documentation is built once, forgotten by the organisation because it is too hard to update and ignored by the staff as it is too difficult to comprehend.
A process defined by a dictionary would sound something like this: A series of actions, changes, or functions bringing about a result: the process of digestion; the process of obtaining a driver’s licence. A process from a business point of view is best described by its outcome.
A good habit to get into is to use the “verb noun” nomenclature for processes. For example, create tests, plan timetable, sit exam, mark exams, report results. The rationale behind this is that it will always act as a constant reminder of what is most important about defining the process; the outcome (noun) and the action (verb).
Processes can be defined at different levels with level zero processes being the highest level and level one being the next level down and so on.
Following our previous examples, the level zero process may be to execute examinations. Each of the previous examples would be a level one process. The levels of processes need go no deeper than that of a work instruction; how to do a task.
Thus, processes are simply a series of tasks which take one or more inputs and create one business outcome. If, at the level that a process is described (level zero, level 1 etc), there is more than one business outcome, then split the process into two or more processes so that each has only one outcome.
Processes can be described by words, words and pictures, words and graphics or words and flow charts, or further combinations with words being the common denominator.
Processes are not policies, although they may refer to them. Processes should not define the value of a parameter. For example, “Reject all bottles of finished product less than 1.07 kg in weight”, is better written as, “Reject all bottles of finished product less than the set weight” and to have a table with today’s set weights.
The rationale behind this is that the process documentation does not have to change as bottle sizes or tolerances for overfilling change. The document is easier to keep up to date. The process does not change, just the value of the parameter used within the process.
Process should have defined inputs and outputs and a performance indicator, measured by the process, which will tell you whether the process is functioning properly or not. The performance indicator is not part of the process although measuring it and reporting it may well be.
Processes should be analysed in order to be certain that they indicate who is responsible (R), accountable (A), who needs to be consulted (C) during the process and who needs to be informed (I) about the outcome of the process. RACI mapping, as it is called, is often forgotten.
When it is not done, a process can have multiple accountability assigned or no accountability assigned. In either case, the impact is the same, no-one is accountable for ensuring that the process works as intended and is improved over time.
Further, if those to be consulted or informed are not specifically identified, over-communication or under-communication results.
So, why would you care about formally identifying and mapping processes?
You should care if your team seems to be forever playing catch up with no time to do their tasks, let alone think properly about them. Completing level zero and level one process mapping alone will reveal under- and over-communication, inadequate accountability and some individuals being accountable for too many processes.
If your team is large and dispersed and you want their customers to experience a consistent approach, mapping your processes will reveal the diverse range of approaches that your team uses with undoubted poor consequences for productivity and customer service.
Controlling your processes and analysing the performance indicators will enable you to reduce variation, improve productivity and increase customer satisfaction.
Process mapping and analysis is not hard and can be very useful if a few simple guidelines are followed. Take care not to over-engineer, make the processes easily understood and easily available (the top shelf in the quality engineer’s cupboard is not a good place) and you will find definite benefits.
However, if your processes change every time you use them, then mapping and controlling processes is not for you.
Or, if you have difficulty in communicating standards for your staff to a level where they actually comply, then mapping process is also not for you. Not until you become good at setting, communicating and enforcing standards, that is.
