How many of us see a defect in manufacturing...and wonder if it is a big problem. Is it a little problem? Chances are, if you don't have it setup in your manufacturing management system, you don't know anything about your rejects. Today I'm going to talk about the utility of even a simple mechanism of recording your defects, scrap, returns, etc.
Starting somewhere
The easiest way to get going here is just start. Now, this means a few things. We need to know a few things before we start. Deciding to start is very important, so certainly do so.
A few things you need to start.
- What is recorded now? If nothing, then still define what you intend to record.
- How is data recorded already? Is there a shop order or traveler form with information? Do reject numbers live in the production packet somewhere?
- What are you looking for? If you aren't sure, let's consider what will give you a better understanding of your systems with this data collection, then we can refine it. We aren't playing the short game here, so don't be sad if you aren't getting exactly what you want right away.
Take these answers and consider your mechanism. As this is a case study/success story, I will fill in the rest with how I was able to take this simple collection mechanism and move it into a tool for proactive assessment of trends.
Answers for the case study:
- All rejected parts and assemblies are recorded.
- Paper records of rejects and scrap. Paper records for all scrap lives with records. The manufacturing system notes extra pulls and this is used as scrap for % calculations.
- Looking to have better understanding of what reject reasons are for what reason. Need to be able to identify trends and input corrections to the manufacturing system.
Solution and its evolution.
The start somewhere solution here was just and excel spreadsheet. Noted the work order, the part, how many, the reject reasons. Version one was built and recorded for one quarter, then for the next calendar year it was revised and recording continued. Each quarter results were pulled for management review uses.
First level results
Immediately, data recording was identified as an area of concern. Paper records are nice, but without guidelines for how to say part -x- is defective or assembly -y- is damaged, you see issues right away, particularly if you are writing them into a sheet. Despite data clarity issues, it was possible in a single month to look at Pareto charts and see what reject reasons might be of concern. After a full year, the system was revised again.
Second level results
The second revision included "canned" responses from a source table, simple to do in excel with some data validation and table work. This cleaned up how data was entered and made the sorting for trends easier. Another addition here was the inclusion of some broad categories. "Unspecified damage" and "unspecified defect" were added to account for form entries not applicable to other answers. Along with the quarterly use in Management Review, the unspecified categories would be assessed and sorted to ensure they were not capturing anything significant.
Third level results
After the next year of records, a new mechanism was employed. Microsoft forms was implemented for data collection. This removed the copying of forms and allowed the work order processor to enter the defect data right into the sheet via web form. Additional refinement of the responses provided even better granularity. One large step was to refine what was recorded. Simple plastic bags, bulk boxes, and some other trivial cost parts are no longer recorded into the collection system. Their total reject rates are still accounted for, as the mechanisms used for over-allocation is still in use. The only time these are looked at in practice is if there is a huge reject spike, say, 1,000 bags are bad. In 2+ years of monitoring a stable production system, these rejects mostly created noise.
The "so what"
Starting simply with dedicated reject metrics enabled this organization to address several emergent production quality problems. The visibility of the information saved parts, money, and time for the company. It didn't matter that the first version wasn't great (the current one isn't perfect by any means either). When you begin to understand your systems better, you can improve them more effectively. With the current implementation of this system, emerging trends of problems aren't just a hunch any more. The team can go pull the data up and look at what is actually happening.
If you don't this kind of insight into your process I encourage you to start somewhere. Even a simple tool is still useful. Mind the questions in the front. Make sure you have some understanding of what you are looking for before you begin. You can do it!
