Segmentation of Workflow for Secure Human Check

The weakest link regarding process safety is inspection conducted by human operators, since reliability of human behavior is not so high. Humans are not so reliable, so checkers often forget to check. Also, they may misconceive and miscount during inspections. This paper presents solutions for this problem.

A check is a crucial procedure for industrial process safety. We can detect abnormalities mostly through checks. If we forget or fail to check, risks hidden in the process will run loose.

The important part of checks is still left to human operators, even though there are many automatic control apparatuses to detect deviations of plants, to issue alerts, and even to fix them automatically. Human operators are required for general vigilance and complex decision, which cannot be handled by control apparatuses.

In order to reduce errors on checking, we should use segmentation of workflow. This paper explains theoretical advantages of the segmentation by showing practical examples in the industries.

2. Common Problematic Methods of Checking

There are many examples of ineffectual checks. Here are common examples.

1) Check on Actions not on Results

We often see a kind of check question that asks about execution of the last action. It goes like "Do A. Check whether you have done A or not." Such question is mediocrity and tautological, so human operators will not pay particular attention for it and might overlook the check.

The check must be questioning on results not executions of actions.

2) Check triggered by completion of the previous operation

We commonly see a kind of checks that is designed to follow operations. It is a instructing like "Do A. After that, check B."

Although this instruction of check looks commonplace, it does not have enough resistance to oblivion. When we forget to do the preceding action, we will forget the following action too, because it can be triggered only by the end of the preceding action.

3) `Double Check' as an Identical Repeat of Inspections

People regard so-called `double check' as identical repeat of checks by two people. But this method is very unreliable because of two reasons.

The first reason is that a checker tends to expect the other checker will detect abnormality. Both of them relay on each other, so the check will be indulgent.

The other reason is that people tend to commit errors at the same confusing points. (This risk has been recognized in software industry [1].)

So duplication of human checks is not effective, and its reliability does not increase in proportion to the number of checkers.

To make checks secure enough, we must conduct them by verifying from several different points of view.

4) Yes/no Questioning (Closed Question)

In general, a `closed question', whose answer should be either `yes' or `no' , is very clear and easy to understand.

But, for industry scenes, closed questions are not safe, because very large portion of answers tends to be `yes'. In actual workplace, closed questions are frequently used for verification. Most of states in workplaces are normal, so checker usually answer as "yes, it is right". People strongly expect yes answer beforehand, and they will not be strict for the checking.

To avoid this risk, we should make a checker report about variable things. We should switch a question like "Have you done action A?" to "When you did action A?" The checker will watch the situation more carefully when she/he is asked to answer something that is not constant.

3. Segmentation of Workflow and Interruption with Check Procedure

In order to solve the problems of (1) and (2) discussed above, check procedure must be designed to meet the following two criteria:

A) A workflow must have a `stage gate', periods only for check by humans.

This gate should be trans-sectional and simultaneous, i.e. all operational actions must be stopped together at the stage gate. The workplace will get silence and standstill. This stillness improves accuracy of human check. The checkers can concentrate on states and results of jobs rather than their previous actions.

B) The stage gate must be triggered independently from preceding operations in order to avoid the risk of forgetting stage gates.

We can realize triggering of stage gates depending on time.

Case 1: A company has a rule that stops all employees' operation at 4PM to make them concentrate on checking situation of their tasks. If they find mistakes at 4PM, they can correct them before the end of working hours.

Another implementation of a stage gate is to design it as a 'dam' inserted in the workflow. A workflow may ramify into several parallel paths. Progress speeds of job parts are not the same, so supervision of the job becomes difficult.

We should insert workflow dams to make all parts rendezvous.

Case 2: In a food factory, many of human errors had occurred at composition of materials. Most of novice operators put each material into the machine at different timing as soon as the material is ready. In contrast, skillful operators place a tray in front of the intake of the machine, put each material on it, and wait until all materials are prepared.
Then they check the composition of the materials in stillness, so their reliability is high.

Case 3: When a tour conductor guides the group of his customers, he usually appoints some meeting place before the final goal. Appointing the final goal is weak against disturbances, since it is rather difficult to remember long way to the goal and to reach there without trouble. Appointing near place as a rendezvous point is much easier and robust.

We can consider about trade off of efficiency and robustness of the stage gate system. Even if some parts of the job arrive at a stage gate earlier than rest of the job, they must wait at stage gates until other parts arrive. This rule is also called `convoy system', in which faster ships must go slow to keep formation of the convoy with slower ships. It looks inefficient regarding speed, and we reduce degree of freedom of each job. However, it allows check easier and more secure as we saw in the examples above.

Von Neumann once estimated required mean-time-to-failure (MTTF) for vacuum tubes for computers [2]. Long run without intermissions is fragile to keep correctness of the computer' s state, since some parts may fail during the run.

We empirically know MTTF of human operators, so we can estimate probability of failure of workflows with a certain amount of durations. We should insert intermissions to shrink durations, if many human errors are taking place.

Reference

• [1] Knight, J. C. and Leveson, N. G. "An experimental evaluation of the assumption of independence in multiversion programming", IEEE Transactions Software Engineering 12(1), 96-109, 1986.
• [2] John Von Neumann, "The role of high and of extremely high complication", Theory of Self-Reproducing Automata, University of Illinois Press, 1966.