Have you ever been faced with a coworker approaching you with a perception of a problem occurring somewhere in the organization, yet there is no data to actually quantify the frequency or severity of the problem? This is an everyday occurrence for many of us. Sometimes I see personnel attempting to solve a perceived problem with countermeasures before they truly understand the problem or have quantified the current state. Though I’m proud of them taking initiative to solve a problem, I have to steer them to make sure they fully understand the current state before implementing any corrective actions. Sadly, it is very typical for problem solvers to gravitate towards a potential solution because they’re “sure” they know how to correct the root cause, only to discover, “oops – the problem didn’t go away.” Worse, we install a “fix” to eliminate the symptom of a problem without addressing the root cause in the first place (the ubiquitous “band-aid”).
Collecting data is key to understanding the current state, and will thereby clearly illuminate the problems that need addressing. This data collection need not be difficult. As a young engineer having a programming background, I recall years ago prototyping a software application to query our database and present historical analysis data on our production processes. the only problem? The data lived in the *past* and was not actionable, didn’t involve the operator, and it was not visible to the production supervisor or engineer the moment the error or defect occurred so the problem could be better understood the moment it happened.
As an example, this weekend my son and his cub scout group volunteered at a local beach cleanup day. The conservation organization putting on the event asked all participants to log the trash t
hey picked up on a check-sheet. This paper log asked you to categorize each piece of trash found and is undoubtedly intended to help understand the current state so that countermeasures might be taken to eliminate the root cause. If the problem being solved is trash on the beach, picking up the trash helps eliminate the symptom (the trash), but does not address the root cause – how/why the trash got on the beach in the first place. For instance, finding many plastic spoons might suggest the ice cream parlor across the street may need to encourage patrons to enjoy their ice-cream off the beach. In order to collect data like this, a check sheet is a helpful tool to understand the current state, but thought is required to ensure the tool is most effective.
Some ideas to help understand the current state:
- Collect data visibly, in the area affected. This is best done on a mobile whiteboard or flip chart right at the station or machine.
- Have the direct-line personnel (such as an operator) collect the data themselves, asking them to record the data personally, when possible. This helps build ownership and understanding of the process.
- Consider collecting data on a sampling of the process rather than logging all data. In this case “sampling” is intended to mean that you don’t try to collect data for every defect/instance – but a randomly selected subset of all occurrences. This is helpful in that it reduces the time required to collect the data and/or inspect all defects. However if you choose to sample the data, be sure the data collected will span all times, locations, machines, or personnel proportionally, so that your data is not biased.
- Avoid using computers, or “hidden” log-sheets not visible to everyone nearby. Involving all others in the area, even those not directly involved in the area helps reinforce the need to collect data on a problem, and emphasizes your culture of lean thinking and good root cause analysis.
- Make sure everyone understands the categories of the data. If you need to categorize defects or causes of occurrences, the categories should be few and easy to understand. There is no need for elaborate lists of categories. Keep it simple! By having an elaborate system of categories, you may overly complicate the problem, and add time to the data collection process.
- Use the data! There is no point in recording current state data if there will be no action taken. Management needs to be prepared and ready to support improvement activities to solve the problems uncovered.
If you have one hundred volunteers for beach cleanup day, would it be most effective to expect every participant to log each item found? Perhaps this would be a good time to utilize a sampling plan and only have selected individuals log the trash. In the case of my son and I, itemizing the trash found was time consuming and the categories were confusing and prone to errors. It took more time to figure out what category to count the item to than it did to pick the item up. I spent all my time trying to keep up with my son picking up the trash – and regardless of my best intentions and careful consideration of the categories, at least half my recorded data felt mis-categorized because of the confusing categories.
Good root cause analysis cannot be done without a thorough understanding of the current state. We need to think of ourselves as scientists of our processes. For successful problem solving, the science of the problem must be measured and understood before implementing countermeasures.