|
We are make-to-order both job shop and repetitive orders. In theory any part that we make is specifically for one customer. However, two major exceptions.1. We have corporate customers with their divisions and factories geographically scattered. I had wanted corporate billing so that parts that go to several different factories of same customer name would all end up under the same customer # billed, but I got overruled ... other people in the company want to track sales by ship to, rather than by bill to. 2. For purposes of their service parts, several customers are ordering what we consider to be either commons or raw materials.
New parts start out theoretically with all components above raw materials uniquely item# whose prefix is based on the part# of the customer, then for those sub-components that are physically identical to some other part we already make, common# substituted in the product structure of the customer's part.
We are 405 CD. Every weeknite (and some weekends) We do MRP500 (several times due to master scheduled items doing double duty & nuances about that learned on BPCS_L several months ago) MRP600 CAP600 every nite ... not regen DRP because of how we have modified that. Production Planners use MRP to see what shop orders need to be launched, and we have heavily modified the shop paperwork, and labor ticket keying back in what work got done.
I am not proposing to my company that we totally quit reporting actual production, just the TIME part of it ... continue reporting the quantities made and scrapped, which I believe is needed for inventory accuracy and managing what is left to make, such as the dispatch report. It is because of the huge work load associated with tracking actual labor time, and small number of uses for that time, that I want to find other ways to get the info that is now got from time ... for example, the PAYROLL knows the total time the people worked, and what department they work in.
I did not know phantoms could be stocked. We use them in our BOM as non-parts to label history of engineering changes and revisions, so that when someone looks at the BOM they can see what the story is on when that part got redesigned, and some info on the nature of the changes.
Cutting down on the work associated with transcribing customer orders into BPCS is something else I need to work on. Management not want to invest in any add-on stuff (I have suggested Foxtrot, EDI, and scanning in customer orders to some standard machine readable format). We have customer forecasted requirements entered several months out while we only manufacture what is needed a few weeks out, since the purchasing has longer lead times.
Our end item#s are the customer part#s. The immediate children of end items# are those items with code suffixes that are like configurated because they identify something about what is going on with the wires, such as doubled or joined in some way, but as the product structure breaks down into more generic leads used in many of the parts that we make, they become what we call commons.
We do not have standard amounts of scrap by particular items, at least we not supposed to, rather scrap comes about thanks to * some machine is in need of preventative maintenance, and the rising scrap rate there is one tip off that this action needed * some operation is experiencing a lot of tiny setup orders, so the tip off there is to review product structure to see if we can add any more commons
Al, A couple of questions for you. Are you using phantoms in your B/M's to represent "common parts lists"? As you know, you can stock a phantom, and I believe you can assign a yield factor to compensate for an "average" expected scrap rate. The other question would be how are you doing order entry? Are you using a configured item based on features and options, or are you just taking orders for a "generic" configuration? It sounds like you have a good application for using features and options and releasing Final Assembly shop orders. As far as tracking scrap to a specific customer without doing actual shop order reporting will be a challenge, and that was why I suggested the co-product, by-product approach. That would breakout the cost of good and expected bad product by item number and then you could track which customers ordered those parts. The Sales Analysis module would help you summarize those costs, quickly. Good luck. Al Mac <macwheel99@xxxxxxxxxxx> Sent by: bpcs-l-bounces+amkavoulakis=sealinfo.com@xxxxxxxxxxxx 09/15/2005 08:10 PM Please respond to "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx> To "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx> cc Subject Re: [BPCS-L] Scrap in Cost of Sales 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 -- This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/bpcs-l or email: BPCS-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l. Delivered-To: amkavoulakis@xxxxxxxxxxxx -- This is the SSA's BPCS ERP System (BPCS-L) mailing list To post a message email: BPCS-L@xxxxxxxxxxxx To subscribe, unsubscribe, or change list options, visit: http://lists.midrange.com/mailman/listinfo/bpcs-l or email: BPCS-L-request@xxxxxxxxxxxx Before posting, please take a moment to review the archives at http://archive.midrange.com/bpcs-l. Delivered-To: macwheel99@xxxxxxxxxxx
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
