|
Thanks for the suggestions. For many other reasons we have problems with conflicting needs* the need to produce parts based on unique characteristics of the physical part, not because it is a particular numbered wire of a final customer assembly ** we might have a bunch of 100 wire harnesses for a bunch of customers in which 15 of the wires are physically identical on any given harness with scores of other parts some for same customer some for others, so we have a unique item # assigned to some wire that is some length, guage, color, copper compound, has what connectors on the ends ... that might end up hundreds of different end items for many different customers ... from perspective of factory efficiency, we need to have this as one part #, not hundreds of different part #s for parts that are physically identical to each other * the desire to be able to access end customer relevant to sub-components being produced, because sometimes production planners get the word that the parts for some customer need to be expedited before this info has been updated in BPCS and MRP regenerated, also as the common parts flow into items that are uniquely identified by end customer identification, we do have our factory organized into areas by end customer needs. * I have already been trying to do end customer identification, and we having a lot of inaccuracies due to our system not really setup to track that way, which is why I was considering pro-rating based on which end items actually got shipped, or were on order, that share the components that got scrapped
Frederick is correct that our scrap is like a cost of doing business.Our scrap has no financial value that we can get $ back for it that is more than the cost of hauling it away. It is like getting rid of used computer paper, the $ from recycling it, is like a subsidy to reduce the cost of hauling it away.
A portion of our scrap is from inspection finding that some parts did not measure up to standards and nature of the work is such that either it cannot be repaired, or is uneconomical to repair ... makes more sense to make replacement parts.
A portion of our scrap is related to setup costs ... some equipment has some wastage until it gets up to speed doing the product perfectly, so that in essence it not matter if we make 10 parts or 10,000 parts, there will be 1 or 2 scrap from each run.
Through the process of labor reporting, we experience scrap rates of 2% plus or minus 2% scrap across the board. In other words, some work has no reported scrap, while other work has up to 4 % reported, with overall average being around 2%. I run various reports against this, such as by work center, parent part, components impacted and so forth.
The 8% was added for certain types of raw materials consumed in the operations where the highest scrap already being reported, because we were having a problem with inventory shortages that management suspected might be due to under-reporting of scrap. There may be problems with the 8% not applied uniformly to new engineering changes. We are still having shortages. I do not have a sense of how the scale has changed.
Thus we are consuming our raw materials on the average 10% of our parts being scrapped, which is a big chunk of $ relative to our profit margins.
The 2% average that is being reported, in the range of 0-4%.The 8% that is being assumed across the board for the component parts that are correctly coded to do so (a lot are not) Actually the 2 are combined ... we telling BPCS to assume 8% extra scrap, so then the 4% (or whatever) actually reported also has within it an extra 8% of that 2% eaten.
However, I have my doubts about the veracity of this. If our physical inventory, or cycle counting, finds that we have an excess of inventory that the 8% consumed, it will get added back into our system. Plus our error rate in other areas such that what needs to be adjusted is often the sub-components made out of the supposedly 8% scrapped stuff.
Several years ago we captured what equipment was making parts that got scrapped, which went into bins by machine, then each time a bin was emptied, it was weighed to find the total scrap weight by machine. The parts had a sample weight in the engineering so that the labor reporting data could be sorted by what machine the scrap was reported on then compute the reported scrap into scrap weight by machine based on BOM of what was allegedly scrapped, then effort to reconcile reported with the actual weighing. The result was pretty much same results, too close to see any discernable discrepancies. We can't do that again today because other economy measures are not recording as much engineering details as we have in the past.
I checked out the BOM documentation on by-products ... looks like we would need to install API to use that, while most of API not applicable to our kind of business.
Thanks again for the ideas ... I hope I get similarly good feedback on my overhead question.
- Al Macintyre http://www.ryze.com/go/Al9Mac BPCS/400 Computer Janitor ... see http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.
midrange.com
