Two people sitting at a table discussing

Ambiguity Reduction with Process Definition

By James Makela,  Certified Six Sigma Master Blackbelt, BAM, ASET

How and what data for an organization, gets collected, used and stored, seems to get ambiguous as time goes on. You find data errors, data corruption, changed definition of what data gets entered, changed utilization of the data that no longer matches what is captured and more confusion when you now have to make sense of it all.

I was in Quality Management in aerospace for over 20 years and I have lived the rushed and problematic ambiguity of data from various databases, spreadsheets, and paper forms later attempted to be normalized and used for meaningful data analysis.   My observations and solutions were influenced by FAA Software QA Training, American Society for Quality training, International Standard ISO:9000, work with ERP data migration projects, database development projects, audits I have performed on airborne avionics, aerospace supplier audits, and IT audits with Kingston Business Solutions.

I made a model of that how ambiguity was resolved and how the resolution felt compared to reality when fixes were implemented via 3 different methods.

 Ambiguity-Resolution Model

Ambiguous Event:
There is an event that is noticed to have an ambiguous outcome. (e.g. a field in a database when analyzed shows a unexplained delays of processing time.)

Confusion Is Manifested:
There are various versions of what is amiss with the data and it is not known what introduces the problem.  Many theories surface but not based in facts.

Assumptions are made:
People responsible for making the analysis or making data entry assume that they know how the process really works and know the risk and consequences of making a decision about which resolution path to follow.

A Choice is made:
Typically a choice is made to Guess and proceed now, to Pursue Help from what is available quickly, or they are willing to Seek and wait for detailed expertise and analysis.

Guess (Now) :  
This is when you choose a path to follow to achieve your desired outcome; based on your beliefs, assumptions, knowledge, and experience with the task and materials at hand.  When you choose this path you believe that the consequences for failure would be small, that you do not have time to make any other choice and you will take the consequences large or small, or that you are confident in success based on knowledge and experience. 

Pursue Help (Quick):  
When you choose this path to follow to achieve your desired outcome; you may or may not believe the consequences for failure are small; but help is believed to be somewhat immediately available and you would rather not be inconvenienced with the failure. You may feel that you have a logical understanding of the inputs and outputs of the process; but want appropriate instructions or appropriate authorization to avoid litigation or unnecessary damage or delay.  

Seek Expertise (Willing to Wait):
When you choose this path to follow to achieve your desired outcome; you typically believe the consequences for failure are large. You probably have to seek expert help through research or expertise through developmental experimentation. You may feel that you have a logical understanding of the inputs and outputs of the process; but need appropriate guidance or appropriate authorization to avoid litigation or unacceptable risk.  

When the impact of the results from taking the various paths was analyzed to the later discovered real issue the differed significantly on how often those paths produced a good outcome.

Guess (Now) :   50%  of the time the outcome was OK.

Pursue Help (Quick): 70% to 80% of the time the outcome was OK.

Seek Expertise (Willing to Wait): 95% of the time the outcome was OK.

So just how much confidence do we need to have in our ambiguity reduction?

ambiguity reduction


You fly to Las Vegas and upon leaving the aircraft; the flight attendant
tells you, “playing the number 23 on the Roulette table at Bambi’s Casino
pays off 95% of the time.”  You go by Bambi’s Casino and plunk down $20 on number 23 and feel OK with the possible outcome. Of course if the reality of your decision is success – you love it. If reality of your decision is failure – you may be disappointed; but carry on without too much impact.

Upon boarding the aircraft for your flight back, the pilot standing outside the cockpit  tells you, “this aircraft lands safely at its intended destinations 95% of the time.”  Now with the same 95% confidence –

If reality of your decision is success – you say “thank you!” If reality of your decision is failure – it could range from minor problem to a catastrophic situation.


Process Analysis:
If you want to know what is going on, perform a sequential process analysis to assess the process.

  1. Define what inputs are necessary to perform the process
  2. Define what triggers the process to execute
  3. Describe what steps are performed
  4. Record what data is actually taken, for what data system and when in the process
  5. Describe how the process is measured (Time to accomplish, quantity processed per day, etc.)
  6. Draw an existing process/data collection map (Sequential Process Analysis Data Map)

The goal of the sequential process analysis is to document the existing sequence of operations.  It attempts to answer the question of who records what data when and in what system.  

Sequential Process Analysis Data Map:

In our example ambiguity example the data for when the Main Process was done was being recorded at a date-time at the end of Sub-Process 3 by some associates, as of the end of Sub-Process 4 by other associates, and at the end of the Main Process by yet another group of associates.  Since the associates doing the data recording worked different shift days, there was ambiguity in the data,  The real fix was to produce documentation specifically controlling the End of Finishing Process data that was sent to both data systems as the desired data capture point.  This was then used for training operators.  

So, when data does not make sense, understand what is desired by the organization and compare that to the reality discovered by utilizing a Sequential Process Analysis Data Map, as well as evaluating corrupt data, missing data, errant data entries, nonsense data, out of bound data, non-standardized data, unchecked data, and other common data disruptors caused by lack of data standards.  

This map can be used for training of operators and as an aid for management and IT groups to make sense of how data is collected or a future state for how data will be collected.