Re: MRP Dates Education

Short Update

Thanks for all your suggestions - we are checking stuff out & discussing 
recent postings.

Even if these solutions work to solve current problems, they also causes 
other problems.

Due to team effort training some new planners, it has surfaced that some 
people knew about apparent problems in what MRP does & does not plan on new 
customer requirements, that other people were not aware of, and this has gone 
up the ladder to suggest some policy changes to top management, but do we 
really understand all the ramifications?

We have a recurring problem with ship date promises not being met, in which 
the immediate suspects are that the customer lead times were too short, or 
changes in other customer requirements that shared the common components 
resulted in consuming materials that were ordered in sufficient time, and 
there is some finger pointing which may be misinformed ... we find an 
explanation in one circumstance & it might not be valid in the others.

Customer-DW gave us new business a week ago in which at time of acceptance it 
was known that the whole process would need to be a rush job, and various 
authorizations were issued for Saturday overtime, and expediting raw 
materials in here, but we had hoped MRP would be a partner in the venture of 
figuring out what all was needed.  

This is not an unusual scenario.  We typically get prints of something a 
customer wants, we build samples & propose best way to make, but it has to 
match the customer blue print, sometimes we propose to the customer an 
improvement, but they have to approve any change to the engineering design, 
which can take time, and meanwhile they need their part real soon in 
quantity.  Once customer technicians & our engineers are in agreement, the 
bill & routing is entered & checked, and customer service is notified that 
everything is in place.  Only then is the first customer order entered on the 
new part.  

Sometimes we have a hold up because we are dealing with customer 
conglomerates that have large staffing --- they have not yet got around to 
checking our samples, even though they got them weeks ago, and the part is 
due in a few weeks - we ask them to approve our building to the design we 
sent them the samples on, even though they have not yet finished their end of 
the verification, so that we can get them in quantity by their deadlines, but 
every change has to go through a beaurocracy of multiple people to approve.  
Then when the part is in midst of production, we get what amounts to a design 
change for us, just a design correction from their perspective.  Some 
customers do this to us a whole lot more than others.

Customer-AM gave us a revision change in August in which our engineers found 
an error in their engineering drawing, which we fully communicated with them 
at the beginning of September ... you cannot use the AMP part called for in 
the specifications to produce those results - now if you want those results, 
we checked with AMP & several of AMP's competitors & none of them have 
anything to do something like that - do you want to authorize one of them to 
engineer to order something - alternatively, here is a proposal how to make 
this so that electrically it has the same results as what you are calling for 
in the drawing, except that you need to authorize the change.

Well Customer-AM must have a sample they built that works, which they cannot 
share with us & it takes them a while to accept the notion that there is an 
error in their drawing, and resolve the question 

(we are still waiting for a corrected customer design, which according to our 
contract we would need to produce samples on, but we also have a request to 
them to approve bypass sample approval so we can start production just as 
soon as they provide a valid design) 

& meanwhile their production is setup to receive the part in volume in the 
middle of October & it aint going to happen, and some of their personnel will 
be blaming the supplier (us), so I came up with an idea how to put into MRP 
the portion of the part in which there is no design problem yet to solve, 
which would also require customer approval, because we would want them to pay 
for our work if they subsequently decide to abandon their design, a scenario 
which has been known to happen, when this kind of problem has occurred in the 
past.

Customer Part CUST-DW was entered to BOM & routings the beginning of this 
week & engineering swears up & down that they back dated all the 
effectivities.

Order CUST-DW was entered in the middle of this week - MRP planned levels 1 & 
2 A-Ok but started dropping some of the sub-components & raw material needs 
planning at levels 3 & 4 because those requirements would have been needed at 
dates earlier than the "M" planning date.

We run MRP500 & MRP600 by facility every nite using the default "M" time 
frame date & any nites that there are other updates like CST900, we do them 
before MRP.

We normally change "M" time frame in MRP120 every Friday to the following 
Monday, so that this last Friday we would have changed it from Oct 11 to Oct 
18, except we changed it to Sep 15 (back 1 month) to see if that solves the 
problem.

I had been passing the buck to co-workers checking on this, so I do not know 
what part #s to check ... had something not been planned Fri nite & had I 
known what to check, I could have pushed MRP planning date back even further 
& done another regen ... in fact that is now my proposal for them to do Mon 
morning if this has not solved the problem.

A lot of BPCS programs give users the option of using "M" time frame or some 
other time frame at time of execution, and a lot use "M" without offering any 
alternatives.  We have some report programs we added to the collection, in 
which I copied the sections of BPCS code how to get at time frame, using "M" 
because we have had this policy of planning based on current week for eons, 
but now a whole bunch of programs will have the inconvenience of using Sep-13 
instead of Oct-18 as the current week.  We cannot use the system date in 
these reports because they are looking at the work to be done in week 
buckets, based on the current work week, not calendar 7 days from middle of 
week onwards.

So I copied one of those programs to a test library, changed the code to 
access new "C" time frame CURRENT CENTRAL SCHEDULE based on what "M" would 
have contained normally, compiled & tested - well 2 problems - 1 it acted 
like the program had not changed - 2 it took an hour to execute when normally 
it takes 5 minutes.  There is only 1 line of code change here - which time 
frame code to use, but I spent several hours trying to figure out this 
mystery.

Assuming pushing MRP Planning date into the past solves our problem with 
these rush customer orders like DW, my new tentative plan until I figure out 
where software is defaulting to "M" when I want it to use "C" or something 
else ... each evening, make sure "M" is Sep-13, run all the MRP500 600 then 
make "M" Oct 18 for the convenience of users during the next work day.

Al Macintyre
RPG/400 Programmer Analyst
BPCS 405 CD REL-1 & working on the Y2K bug fixes
+---
| 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
+---