Suppose you are in charge of a cliff edge. Your task is to maintain the views from the cliff, but keep visitors safe. You can construct a fences along the top of the cliff, to stop people falling over, or you can place ambulances at the foot of the cliff, to clear up once someone falls over.
Fences seem most appealing (even if only for humanitarian reasons), but they are expensive to construct and maintain. Furthermore, constructing a high fence will block the beautiful views across the sea and people will stop visiting the site (which is bad). So your fences can be only so high before they become an impediment and stop people using the facilities. Unfortunately, keeping the fences too low means people can still climb over them and (you guessed is) fall to their doom.
Maintaining ambulances at the foot of the cliff is also expensive. There is the possibility that people falling over the cliff will be so harmed that they do not survive the fall and even those that do survive may be out of commission for some time. Ambulances seem like a last resort, a safety net. Too few ambulances means more injured fallers die when they could have been saved, too many ambulances means increased cost without any benefit.
There is a balance to be struck. Fences to guard against the unwary and ambulances to recover the unfortunate (or plain stupid).
This balance between ambulances and fences is the line that process engineers walk. We try to design fences that are cheap to install, efficient to maintain, stop the majority of people falling over the cliff, and allow people to enjoy the facilities along the cliff edge safely. At the same time we know that there will always be those who venture beyond the fences (they cannot be secured without blocking the view and driving people away — possibly to another cliff), so we prepare a small fleet of ambulances to minimise the impact (forgive the pun) of those who fall.
Creating a process that allows facilities to be used efficiently but also provide a means of identifying and safely recovering when things go wrong is the skill of a good process engineer.
A good example of this is the combination of change and incident management. Change management is a fence, a process designed to avoid problems. Incident management is an ambulance, a process designed to minimise problems once they occur. When change management fails because either someone circumvents the process (climbs the fence) or because the process is incorrectly applied (the fence is damaged or too low) then incident management identifies the resulting problem and hopefully resolves it as quickly as possible (ambulances recovering the injured faller and saving their life).
If change management processes are too draconian they will be expensive (delaying change and making your organisation unresponsive) or simply circumvented when users perceive them to be an unacceptable impediment. If incident management is under resourced they will be incapable of recovering from problems when they occur. As change management becomes less effective the cost of incident management rises, as change management becomes more effective the need for incident management declines.
Striking the right balance is a matter of judgement and will vary from organisation to organisation, and from service to service. The more sensitive your service is to problems, the more change control is called for, the less sensitive your service is to problems, the less change control is required.
A problem in, for example, an order processing system for a mail-order company has serious consequences and suggests more change control should be applied. The cost of failure is so high that incident management costs would be unacceptable. Within the same organisation the system that produces the print catalogue is less sensitive, so change management costs would normally be lower and more incident management might be called for.
The key to good process design and implementation is balance between constructing fences and maintaining ambulances.
