Data Collection Thoughts
One thing that seems to come up a lot in terms of continuous improvement activities is the need for data. Sometimes there isn’t the right data, sometimes there isn’t enough context to the data, and sometimes there just isn’t any data recorded at all. I’ve written about data in terms of metrics and measurement systems before, but this time I’m more talking about getting your hands on information that becomes clues to solve your production mysteries. I don’t believe in substituting data for observation, just in using it narrow the observation lens.
So…what are some of my key thoughts for getting data to make sure you are working on the right stuff?
- First, make sure your data tool can tell you what you need to know. If it’s a log sheet of some sort, does it capture major sources of variation such as time, position, cycle, machine, tooling set, etc.? If it’s a measles chart (or concentration diagram or whatever name you may use), can you really tell the difference in defect locations on it?
- Next, be willing to sacrifice some clarity in some areas to get an overall picture of the process. I like to start by targeting about 75% of the data that I’d like to have and adjust it from there if need be. Most of the time I find that the extra detail I thought I needed wasn’t really necessary at this stage. I can always build additional data collection if I can’t get what I want from the reduced set.
- Also, try to make it as easy as possible. If you can extract what you are looking for from existing shift logs or quality checks or some sort of automated means, go for it. Adding a layer of work can sometimes lead to reduced data quality for everybody!
- To go along with the previous item, remember data isn’t usually free. If you don’t need the data collected indefinitely in the future, set an expiration date on the activity and free up the resources.
- Lastly, to paraphrase myself, data isn’t a substitute for going to the gemba and seeing the problem for yourself. Double check the data against what you are seeing with your own eyes to make sure that it can really help you. This data won’t solve problems for you, but it can help you know which ones are the biggest.
I’m sure there are some other key points that I’ve left out, but there are a few for starters.
Now, I’m sure some of you are asking, “Why waste time on this and why not just go observe the process at the start?” Good question. I think this is more of a helping hand to make the best use of time for some operations. If there are limited resources (and who doesn’t have limited resources?), deploying this in advance of a deep dive can help speed up the search for solutions. If a process has a long cycle time or unusual frequency, something like this could help identify repeat issues vs one-offs. I am always looking for the best way to use what I have at my disposal and sometimes it doesn’t fit the textbook methodology.