Error Handling Part 1: Error Detection, Management and Culture

Recently, I had a discussion about how to measure errors. First of all, a definition is needed: What kind of circumstance is exactly seen as an error (state)? I promise, this initial question turns out to be a very complex matter. It may typically include product errors, (customer) complaints, malfunctions and breakdowns. People with a process focus might also name omissions, lack of communication or ignorance as an error. From my point of view, starting with error differentiation and setting of clear borderlines is important. Which unwanted event is finally considered an error depends on the error culture of the company.

Error culture? Most companies are reluctant to report errors, if errors are discussed seriously at all. Reporting errors would allegedly indicate inability, failure or poor performance. This is how most people feel because they might have been treated in such a way – or are just frightened about that possibility. Error review is a very sensitive area. Once this topic is tackled the wrong way, it is a great effort to rebuild trust. An indication of a wrong error handling is the lack of meaning for some details. Such kinds of detail that are proven to be important because they can be crucial differentiators for decision making and eliminating root causes of an error – but when discussions about details are dismissed as unimportant, a sense for sustainable error handling might be missing as well.

"In the US, details do not interest but pragmatic problem solving. In Europe, details and data are more important." Anna K. Glahn in: Personnel development strategies of multinational companies

Finally, if an analysis of total error costs reveals that such costs are much larger than originally assumed, then the root cause might most often be a false error management which, in turn, results in a lack of error culture. To make it clear: An error culture must be implanted first before any error management can function properly.

Failure to meet industry or specified requirements

Let us come back to the question: What kind of circumstance is exactly seen as an error (state)? A specified requirement is typically an expectation that can usually be assumed. These include accepted deviations from specifications, rules, obligations or procedures that are common for the specific industry. Everything outside the accepted deviations is an error state. But what can usually be assumed and what is common in industry? For example, is the lack of a metal detector in a food production plant a failure if the customer has not requested it yet but, on the other hand, it is now commonplace in that industry?

Errors occur in every organization, every business and every department. The zero-defects state is the goal of any company – but ultimately remains utopia. At best, stage victories can be won but a residual risk always remains and errors show up. In some industries, e.g. aviation or nuclear technology, a non-occurrence of errors plays a special role and made great progress. These industries are very safe but we all know examples of their failure.

When dealing with errors, the aim should always be their elimination and future avoidance. This is the common practice and task of supervisors for their area of responsibility. A departmental manager is measured by how well the departmental goals are achieved. Since every error usually counteracts such goals, it is their very own interest to master and prevent errors. An essential part of reoccurring performance reviews is dedicated to this topic.

The main problem to be dealt with is the fact that although errors are made and measures are agreed upon, the actual root causes of the error remain. One reason might be that symptoms are “healed” (again and again) without investigating their root causes – the excuse is that there is no time for investigations. In addition, a systematic recording of all errors and problems might not be done which often hinders new findings and sustainable solutions. Operational blindness comes also in play which can only be overcome with the methods of error management. The following enumeration shows some of the factors that often preclude effective error handling in practice:

 1.      Errors are not recognized as such.

Mistakes are often accepted as unavoidable events that are dealt with in the context of "daily business".

2.      Errors are not registered.

If mistakes are not recorded, they soon fall into oblivion. In addition, the more frequent occurrence can only be judged from memory and thus elude a later evaluation.

3.      Errors are taboo.

Some errors can be traced back to problems that are generally known but are not openly addressed for a variety of reasons.

4.      Only product errors are considered.

Errors are always associated only with the product or direct customer complaints, all other errors are not considered.

5.      Errors are not evaluated.

Without objective error analysis and weighting, it is not possible to obtain an actual overview of the existing problems.

In order to gain an overview of the total errors and to react to them efficiently, the following introduced establishment of an error management system is a sensible method.

Construction of an error management system

The introduction and implementation of an error management system presupposes that the executive management totally agrees in this project to deal consistently with errors. This is by no means always the case in practice as many aspects of corporate policy are touched and there might be reasonable reasons for not dealing with certain errors (e.g. because restructuring is pending).

In preparation, all employees should be informed in detail about this project. The main reason for this is that with the detection and evaluation of errors, often unfair motives are suspected. Without staff and managers, it will be difficult to capture errors effectively. The most important message that should be conveyed is that a person who has caused a mistake will not be on focus. The aim is to find errors in business processes which need to be evaluated by systematic error detection. This can only succeed if enough information about errors is collected. It is not about who made the mistakes, but why it happened.

"It is never human error, it is always the method. Sabotage excluded." Common Kaizen axiom

Another way to reduce fears is to make it clear that no employee comes to work with the intent to commit any mistake. This is by no means an appeal to a negligent style of work but to stimulate the sense of error handling and to strengthen personal responsibility. When error discussions are held in small groups, employees become more positive about this project than they are assumed by the management. When employees start to talk about error examples that are most annoying to them, no evaluation or commenting of these errors must be made. If a production manager who may feel challenged by such a statement begins to explain or even defend the error, the employees recognize that error handling is not on focus but they feel blamed. The discussion should therefore be moderated by a neutral, trained and accepted employees, at best with the help of external support.

Error detection system

The error detection should as far as possible be integrated into existing systems. E.g., if only machine malfunctions or product errors have been noted so far, further problems or annoyances can be recorded with the same method in the future. A distinction should be made between “known” errors that occur regularly within a specific framework of a defined process and “unknown” errors that are not directly foreseeable. For known errors that appear regularly, specific key codes help to capture errors quickly and safely without much effort. Unknown errors or those that are appear rarely, a simple error list is sufficient. Error lists are also useful for all departments that do not keep regular logs.

The inhibition threshold to enter errors in an error lists is often very high, as errors are very easily associated with personal guilt. A renaming in “irregularity” instead of error can be very helpful here, since this term is more neutral. The lists could of course also be referred to as deviation lists as known from audit systems. However, this creates the danger that only production errors are considered and only deviations from the described system will be entered but not all disturbing events. The list needs to be kept chronologically and can consist of several pages. It should be collected and evaluated every one to two months.

Error detection is primarily about errors that occur within the company and allow conclusions about the ability of all internal processes. Of course, errors that are brought into the company from the outside are of great importance and need to be completely covered, e.g. in the incoming goods inspection. However, the evaluation of these errors takes place within the framework of the supplier assessment and represents a separate topic. It should be noted at this point that an analysis of internal errors often reveals that their root cause are external errors. These are errors that were not detected by the incoming goods inspection. The supplier evaluation system should then be able to account for these errors as well. But, again, this is another story.

Error detection is often the most difficult part of the whole process, especially when it comes to procedural errors in one′s own area. Many employees like to claim that there are no errors when they are addressed to the empty error collection lists. On closer examination, this claim is only true in the rarest cases. Here, further explanatory discussions are necessary to gain acceptance for the error detection. A major problem is often the accusation that denouncing is facilitated by the error detection. This idea, in turn, is based on the fear of personal guilt of the employee making the error. This fear can only be remedied by educational work.

Another method of error detection is to capture and discuss these at regular departmental meetings. Since internal discussions should already contain problem solving, hence a sort of error handling, anyway, this method seems very simple and appropriate at first. However, there is a risk that topics of the day-to-day business dominate the meeting too much and too little time is devoted to the recognition of errors. In addition, only errors that are evidently perceived as errors are discussed and recorded in these stand-up meetings.

Meetings like quality circles, hence those that only serve to record and discuss errors, are proven to be more efficient. These meetings should be moderated by a quality manager or another person who is not directly involved in the departmental process.

In principle, all errors should be recorded. In practice, however, limits of error recording are quickly reached. First of all, it is difficult to establish a generally valid definition of errors since errors are always perceived subjectively and not all events can be pressed into error codes. In addition, a good in-house error detection cannot reach 100% since the human factor plays a too large a role. But even if only 20% to 50% of all errors are recorded, there is a great benefit from this data. Of course, as with all measures, it is also necessary to weigh the costs and benefits of error detection.

As part of error management, all errors should be considered. Part of the error processing is an integral part of the processes of a quality management system, this includes the processing of customer complaints, deviations from specifications, production stops, and errors of the suppliers in the supplier evaluation.

The following overview lists some types of errors that should not be neglected and are often not sufficiently understood:

1.      Errors requiring extra work to eliminate them, e.g. repackaging

2.      Errors that endanger product safety, e.g. violation of health regulations or use of defective equipment

3.      Errors that mean a general hazard, e.g. negligent handling of hazardous cleaning chemicals

4.      Mistakes that indicate organizational weaknesses, e.g. missing materials or information

5.      Errors in connection with the customer that did not lead to an official complaint, e.g. parallel processing of a customer request or tolerance of a specification deviation

6.      Errors that cause damage, e.g. transportation damage due to wrong packaging

7.      Mistakes that appear minor but annoying in their repeated occurrence, e.g. wrong phone numbers in the address database

Instead of a conclusion, I want to share a preview on the planned contents of the next part of this series: It will be about an error evaluation system, error troubleshooting or problem solving and corrective actions. However, please share any thoughts and ideas if other topics would be of more interest.