Re: Pegging planned items back up to discrete customer orders. -- BPCS-L

We are also 405 CD ... we use multiple facilities, which opens the door to more flexibility of planning process. There are several related issues here.

There are classic intentions of MRP that do not always mesh with the reality of our factory needs. MRP and other planning works when our inventory and engineering accuracy is in the high 90 percentiles, but when some aspect of our data dips below the percentiles necessary for MRP to work right, then there needs to be some alternative data accessible until that gets fixed.

We have converted between flat structures and deep structures both ways several times ... it is a nightmare and the results are never as the proponents claim.

Sometimes some customer is either past due, or has a rush on some order, and management wants rapid identification of all the implications of this. For this and other reasons, there is often need to identify what we are making for what customers.

To help that effort, our end items have in them the customer # in one of the user fields that are up to the BPCS customer to populate as desired. (I wish we had a directory of all such fields available.) This means that various inquiries and reports listing our items in production etc. such as our labor tickets and dispatch reports, also show for what customer we making this, when the data is in the system correctly.

With MRP300 you can look at something being made and peg it up to why we need that, then go to that and peg it up and get all the way ... or we can have a report or series of queries developed in which the parent item and the child item can be linked. We use this kind of approach to help production management when there is a complex sub-assembly with scores of components ... to list which components still have shortages, so they can focus production on the sub-assemblies for which all the components are ready.

We wrote software that connects all most child items to all most parent items in a grand index of how many of what components are used on which customer end parts ... the reason for this has to do with contract buying of the components ... Most of our raw materials come from TYCO ... many of our customer know this, and negotiate with TYCO on behalf of all their vendors to get better prices for TYCO parts than we can get with our volumes, so we are buying the same raw items on different customer contracts, and have to be able to account for how many for which customers.

We use planner codes to subdivide the product families: We have production control people who have specialized in different clusters of customer product types. We have raw materials from outside vendors, from internal inter-facility, some inside vendor work, and there is a scenario where a customer orders what is to us a raw material. All our raw material is item numbered 91 then a string of digits For purposes of sales analysis our customer orders use the customer part # as our item # so there might be a customer item on order that is 22-3456 whatever but that item is really identical to our 918273 whatever So planner codes can be used to keep straight all these different kinds of items that get different treatment by different personnel

Julie possibly implies that it might be wasted effort to correlate for what customers parts are needed, given that MRP job is to combine identical requirements. In our reality our customers exhibit different demand fluctuation volatility behavior with respect to altering quantities and dates of what they asked for, after we in midst of production of their parts, so there is a need to rapidly identify what production changes are needed as a result of customer calls.

SFC350 is very powerful for drill down simulation ... we have a customer on the phone asking about the doability of some lead time violation order they want to make, but then there are so many different threads to pursue with respect to the shortage items illuminated, to check out where they are in purchase order promises and so forth, so sometimes what is wanted is SFC350 data in a report format, that answers all relevant questions, and can be shared with the customer and other players.

There's lots more that we might like to do with this than we have so far actually implemented.

- Al Macintyre http://www.ryze.com/go/Al9Mac Find BPCS Documentation Suppliers http://radio.weblogs.com/0107846/stories/2002/11/08/bpcsDocSources.html BPCS/400 Computer Janitor at http://www.globalwiretechnologies.com/