Disaster management

Citation

Loughlin, C. (2003), "Disaster management", Assembly Automation, Vol. 23 No. 3. https://doi.org/10.1108/aa.2003.03323caa.001

Disaster management

What should you do when things do not go according to plan? I do not mean "small" problems such as a JIT supplier informing you that they will be a week late. No, I mean really really big problems such as when you find out that the new manufacturing system or plant layout that you have just implemented, simply does not work at anything like the levels of productivity you had planned.

Of course no one ever plans for such a situation to arise. But what if it has happened despite years of advance planning, endless computer simulations and small scale trials?

Many would argue that such a situation should never arise, and advocate (with hindsight) that the principles of continuous improvement, as opposed to radical change, should have been applied. However, it is not always possible to go from A to B in small movements. If A and B are separated by a bottomless trench then only a leap (of faith) will get you to B.

One possible option is to go back to the previous system. But in the vast majority of cases that previous system would have been ripped out, cannibalised and otherwise put beyond use as the new system went in. So you cannot go back.

If you cannot go back then the only solution is to go forward.

Good system design depends both on a clear vision of the overall process and on meticulous attention to the fine details. So if things have gone wrong the first thing to decide is whether the fault is in the grand plan itself or in an accumulation of minor details or some combination of the two.

The grand plan will not work if the details do not function, and by the same token the details are pretty irrelevant if the grand plan fails to bring them all together into a working whole. The first obvious step therefore is to assess the grand plan.

If you decide that the grand plan is OK then you can yield a big sigh of relief and set about correcting the minor faults in a systematic manner. The trouble is on deciding that the grand plan is OK is probably not best done by the people who came up with it in the first place. They have too much personal equity at stake to be reasonably expected to come up with a rational unbiased objective verdict. The grand plan may well be valid, but it needs an independent third party to assess the situation.

This probably sounds very obvious, but again and again I have seen projects fail or falter because those in charge simply became involved. I know, I have been guilty of this myself. It is all too easy to get sucked in by the excitement of the new project and the grand plan overview can soon get pushed to one side by finer details and impending deadlines.

Perhaps what is needed therefore is someone to maintain an impartial overview of the whole project. But to be of any use that person needs to have intimate knowledge of the plan, and by implication this will mean that they are no longer impartial.

Clearly, this is a difficult problem to solve. The best advice I can come up with is that if you do find yourself with a project that has gone badly wrong, then you should get someone independent in to assess the problem. This is what to do after the event.

To prevent it happening in the first place I advocate a "layered" approach to simulation. Simple simulations of the basics can often show up fundamental flaws in a system design. Once a basic design has been proven, then detailed simulation of each sub-process is required. The big danger with simulations is that you try to make them too detailed initially and get bogged down. The top level simple simulation can often be accomplished just with pieces of paper on a desk. Diving straight into a computer program can insulate you from the real world, and it is after all in the real world that your problems will arise.

Clive Loughlin