top of page

Error proofing - How referencing a Tom Hanks movie has taught me about error proofing in MRO


It all started in college when a close friend heard me say, “What is in your mailbox,” when attempting to reference a movie starring Tom Hanks. Not surprisingly, Tom Hanks was not in a film called “What is in your mailbox,” but it was just enough information for my friend to know precisely what I was talking about. The laughs followed as she gesticulated my accuracy by barely touching her thumb to her index finger. You were this close! It's You've got mail.

[in an email to Joe Fox] The odd thing about this form of communication is that you're more likely to talk about nothing than something. But I just want to say that all this nothing has meant more to me than so many somethings. Kathleen Kelly in You've Got Mail

For almost 30 years now, she has documented all of the “so close” that I have said. This unintentional input into a conversation did not deter her from knowing what film I was referencing. Even with the historical documentation for tracking purposes, each conversation (or my mistake) continued because she transitioned the error into what was correct.


You were this close


Even with the movie I failed to reference accurately, I was close to the answer. It was not an answer miles apart, requiring multiple levels of inquiry to understand what movie I was referencing. It was just the right amount of information to understand the input into the conversation. She heard my answer, made a minor adjustment of interpretation, and knew what movie I was referencing. She was error-proofing my dialogue.


In any set of data, coding errors can exist. This is especially common when you have manual inputs impacting the data. Manually typing in an SKU number or transcribing a phone number, being off by a single digit becomes a completely different number or string. But how should we look at data influenced by “fat-fingers” and errors to lessen our ability to analyze?

Dammit. If a machine can find out that there is an error, why can't it locate where it is and change the setting of the relay from one to zero or zero to one? Richard W Hamming

Error proofing is required in manufacturing to ensure that processes remain fluid, information is transacted correctly, and errors are minimized. This is especially important in manually inputted systems such as inventory control, transacting shipments, or documenting safety contacts by typing in a badge identification within a safety tracking system. If we have humans involved in a process, errors will exist. Thus, we need to incorporate error-proofing strategies.


Error proofing example within MRO inventory


Consider an example where you want to add a ½” 2-way, 2-position, normally closed ASCO valve to your MRO inventory. To get the manufacturer’s description number into your inventory management system, you obtain it from your preferred vendor’s website. You jotted down on your notepad, 821G001AC120. One step closer to getting it into MRO, but first, you want to confirm it does not already exist in your MRO inventory. 


As an employee conscious of cash and its impact on excess MRO inventory, you searched for 831G001AC120, and nothing came up. You proceed to create your unique identification number and add all of the additional required information. You purchased the parts, and now you have inventory. The problem is that you searched for 831G001... and not 821G001. These are completely different strings!


The example below from Rapidtables using ASCII/UTF-8 or American Standard Code for Information Interchange and the abbreviation for 8-bit UCS transformation format. Notice the differences.

Input

ASCII/UTF-8

821G001AC120

00111000 00110010 00110001 00110000 01000111 00110000 00110000 00110001 01000001 01000011 00110001 00110010 00110000

831G001AC120

00111000 00110011 00110001 00110000 01000111 00110000 00110000 00110001 01000001 01000011 00110001 00110010 00110000

Example 1 - UsingASCII/UTF-8 to denote the errors of a common MRO spare


Origins of data proofing

The origins of finding errors in data dates back to a Bell Labs employee named Richard W. Hamming and what has become known as Hamming Codes. In his strategy, a string is converted to binary with the addition of parity bits within the data. With data transmitted or stored, data could be corrupted with fat fingers or errors that result in a binary 1 becoming a 0 or vice versa. The Hamming approach uses a block parity mechanism approach, whereas the binary data is evaluated within blocks and with parity added to the blocks.


Hamming


Since the 1950s, the Hamming approach has proven to correct single-bit errors and find two-bit errors in data blocks. It has also led to dozens of error-proofing iterations such as grammar auto-correcting in our emails to refining our misspellings in Google searches. Error proofing is becoming common, which should encourage us to think about where it fits within our manufacturing responsibilities.


With every error we find manually, we should be encouraged to apply error-proofing code to our manufacturing applications. So seek out tools that can help support the probability of detecting errors to eliminate your redundancy. Especially in MRO.



19 views

Comments


bottom of page