Re: MRP Dates Education

Thanks Harmon

The effectivity date scenario is very plausible ... we do not enter customer 
order until after the engineering is done & on some new customer requirements 
with short lead times there is a mad scramble to get the engineering done so 
that the order processing can start ... the engineers are sending out 
messages all day ... such & such a part is ready in a certain facility & 
immediately co-workers are keying in orders on that end-part so that the 
system can do its thing.

Your explanation might also apply to engineering changes ... we have some 
customer scenarios in which when they have a change, they want us to stop 
immediately production on the old version, but is MRP going to plan the 
sub-components correctly on the new version when we are in the middle of it & 
some of the requirements are now going to be past due, relative to the 
effectivity date of the engineering change?

We have this recurring problem of troubles shipping customer parts, that have 
short lead times, because some department did not get the word to make some 
neccessary sub-assembly & why not ... well I have been tackling it from the 
perspective of the mass of data is just too overwhelming, we need to make the 
big picture of the work to be done to navigate, while upper management has 
been tackling it by increasing staff.  We figure out why in some cases then 
assume that the same story might be true in others, when in fact there may be 
other problems we are not seeing.

I waded thru the MRP documentation last nite & it plainly states several 
things of direct relevance to us that we should have known a year ago, but 
when plain statements are buried in an Encyclopaedia that lacks good 
indexing, the documentation is not going to be read in a timely manner.

Scenario - sales keys in a customer order in which MRP500 calculated 
production dates would stick due date as PAST DUE at time of creation, 
relative to our PLANNING DATE, then MRP does not create the planned order - 
the MRP500 documentation says so, except that does not explain why this only 
happens on the first run of a new part --- Harmon's explanation does.  Now we 
do not have Human Planners per se, rather people who use the MRP generated 
orders to launch reccommended production & purchase orders, so there needs to 
be a methodology of communicating to them when this scenario occurs, that is 
not going to result in dropped information.

Our scenario is that occasionally a customer order is entered in which the 
cumulative lead time means that some lower level items would be past due at 
time of order launch, so MRP does not plan them, so some human has to plan 
them.  This is not a violation of company policy, because provided we know 
this is going on, we can authorize over-time etc. to get the job done, but 
there has to be visibility of the reality, which is somewhat lacking today.

New person in that human role ... How am I supposed to know this? 
Answer ... Sales is supposed to tell you.
Which begs the question - how is Sales supposed to know when they have this 
scenario?  I mean different customer parts have different cumulative lead 
times & the promise date IS in the future, it is not like they are entering a 
past due customer order.
Bottom Line Answer - I think ultimately Sales is going to need another of Al 
Mac's "brilliant programs."

I can just predict Sharon saying "Al, couldn't you have a pop-up screen at 
time of order entry asking ARE YOU SURE? when we try to enter an order on an 
item whose cumulative lead time drives requirements into a time machine?"  
But I have already determined that sort of scenario is not doable for a host 
of reasons.

1. We need better visibility end item vs. cumulative lead time, because this 
is not a fixed value - it wanders all over the place, depending on the 
complexity of the part & other factors.
2. Via SFC350 or BOM300 you can call up a customer end item on screen & it 
tells you cumulative lead time ... except to start the thing the filters are 
not intuitively obvious & you have to scroll to find the largest cumulative 
lead time ... I think I need to clone the code that calculates that stuff (is 
there a report that does it?), placing that into a report in which user keys 
range of item #s & you get one line per item telling you
2-a standard info on that item
2-b what the longest cumulative lead time is on that item
2-c add number days involved to current week's MRP planning time frame 
(MRP120 start date) = the EARLIEST you can promise delivery of this item in a 
customer order entered this week on this item without causing MRP indigestion 
... this assumes we have no safety stock ... you can always go into SFC350 
for the precise math
3. Place this general logic inside a larger software, in which the user would 
select a particular customer number (or range of customer #s like where we 
have one customer # for each division of a customer & the numbers are 
contiguous).  The customer number would go to the file of recent shipments & 
current orders & come up with a list of end item numbers that we make for 
that customer & then that would drive the selection of items for the report 
described in step 2.
4. All the people, involved in discussing with the customer the consequences 
of the time it takes to resolve THEIR engineering design problem, would have 
a copy of this report on that customer, which they could fax to the customer 
to show how the failure to resolve this more timely vs. what the lead time 
situation is.

One good thing about me reading this documentation is that I now see how we 
might be able to use Planning Bills to help with another situation.

We have this scenario of a particular customer in which our contractual 
arrangement is that we build to their drawings, but they often have an error 
in their engineering drawing in which IT IS IMPOSSIBLE to make the part as 
described - we identify this to the customer & give them some alternatives, 
and resolution of this problem is slow to work its way through that company, 
and the deadline is rapidly approaching regarding when they are going to need 
the parts, such that there is NO WAY we can make it on time if we do not 
enter the customer order requirements until the engineering problem is 
resolved, guaranteeing a scramble to get the materials, with various costs 
moving parts on the company plane.

But thanks to my readings of MRP documentation to try to figure out the 
latest question, I see how we might be able to reduce the cost chaos of this 
other problem..
1. Let's assume that WE WILL be making this part, once the customer 
straightens out their design documentation.
2. Ask someone who knows more about this subject than I do whether or not 
this scheme is gonna work, so we do not get into the same mess we got into 
when we mucked around with Shop Order Number System and History retention 
days.
3. Create a PLANNING BILL OF MATERIAL for this part, that excludes the 
sub-assembly that has the engineering problem in it, but includes everything 
else.
4. Throw the switch in SYSTEM PARAMETERS that says that we DO WANT MRP to 
generate orders to fulfill Planning Bill Requirements.
5. This will result in us manufacturing 100% of the problem part EXCLUDING 
the problem sub-part of the problem end-part.
6. When the customer gets their engineering problem resolved, we can then 
enter a REGULAR CUSTOMER ORDER on the corrected part.
7. Throw the switch in SYSTEM PARAMETERS back the way it is now saying that 
WE DO NOT WANT MRP TO GENERATE ORDERS ON PLANNING BILLS.
8. The REGULAR CUSTOMER ORDER will consume the portion of the problem part 
that was not a problem & we only need to scramble to get the work done on the 
sub-part that was the problem.

Al Macintyre
BPCS 405 CD
+---
| This is the BPCS Users Mailing List!
| To submit a new message, send your mail to BPCS-L@midrange.com.
| To subscribe to this list send email to BPCS-L-SUB@midrange.com.
| To unsubscribe from this list send email to BPCS-L-UNSUB@midrange.com.
| Questions should be directed to the list owner: dasmussen@aol.com
+---