Re: Planned vs. Allocated Inventory & Scheduling Customer Orders

Jenny - We're on 405 CD & have had running battles with similar issues ...
some of the stuff we do might not be applicable to your situation or your
version.  Sounds like your bills have more levels than ours, but our
situation also complicated by us using common manufactured sub-components ...
common to multiple different customers parts.

Does 3.7 have MRP300, BOM300?

We are fortunate in that we are under capacity.  We can add to a second
shift.  We have factory floor space available for growth.  Our constraints
are material and setup time.

The nature of the product we make is such that we have some ways to measure
complexity, such as number of wires in the harness & this is a tip off approx
how much time it should take to make parts ... we have populated that
complexity figure into a field of IIM we not using for anything else, and we
print that various places for end user convenience.

Our end item #s are based on customer part #s.
We have populated a field of IIM we not using for anything else, which has
the customer # that we make that part for.
We selected a field that was already showing up on INV300 BOM300 & other
screens & reports, so that we did not have to modify anything other than
tweaking literals.  Thus someone can be looking at requirements for raw
materials & with a few keystrokes identify what customer(s) orders triggered
them.

Check recent archives ... I think Ed DeHarde had a great explanation of MRP
Horizon days ... a lot better than I can explain it.  This also ties into
cumulative lead times.  Some of our customers expect very short lead times,
when they order stuff, some of them would like to get it yesterday if that
was possible, while we have raw materials with lead times of like 2 months.
This means that we give customers prices based on their estimated annual
usage so we can budget how much safety stock.

I created a file which has by item the cumulative lead time for end items,
for query user reference.  You see, if we accept a customer order in which at
the time of input, some of the components would have to be scheduled into the
past, MRP won't plan that portion that is in the past.  However, by using
horizon days, as explained by Ed, you can create a buffer such that MRP does
plan the whole order, then you can adjust to fit what's doable.

I believe that the horizon needs to be larger than cumulative lead time for
in-house production, depending on how much lead time customers are promised &
assuming adequate safety stock.  I have been told by co-workers that our lead
times in system are not as accurate as should be, but I not think it matters.
 What matters is what BPCS is being told.  Horizon needs to be big enough to
plan all components of parts needed for customer orders accepted with short
lead times in reality when system is told the lead times are long.

We try to get each day's inventory & labor transactions caught up input
before end of the day ... this is doable due to an offset between the working
hours of factory workers & office crew.  I have also been running a daily
report on negatives in the system which I think might distort MRP & I been
fixing that before running MRP.  On nites that I run CST900, I do it before
MRP & CAP regens.

We run full generation all facilities MRP every nite, but sometimes we run a
net change at lunch time, on days that a lot of customer order activity has
occurred.  We prefer lunch time because volume of interactive users
diminished then.
However, on occasion, there is a message to all users that we have had a
dramatic change in some customer model line requirements & we running an
MRP500 MRP600 to recompute the consequences & could people try to stay off
the system until that gets done, so as to reduce the load & expedite it
getting completed.

Our version of MRP has a Simulation menu.  You can copy your MRP data into
the Simulation & experiment with the data to try to come up with a plan & if
happy, copy the simulation back to reality.

We have customers who give us orders, then change them ... they want
different date, different quantity.  If, since we got the original customer
orders, we have released shop orders, this firms up the MRP & the revised
recommended dates not automatically get to shop floor.  We have a query/400
listing shop orders whose current planned dates are no longer in sync with
MRP, so that production control can make adjustments.

SFC350 is very useful but also dangerous.
You can key in quantity you interested in making & see where there are
shortages & also do command key to see capacity impact.
But let's suppose there are a bunch of customer orders being keyed in since
last MRP regen that share the same common components ... SFC350 is only
projecting the story based on last MRP plus current single order you
considering.

In theory it should not be neccessary for people working with orders to know
for what customer something is needed, just use BPCS reports to tell you what
to get.  In our reality, the price of our raw materials depends on what
customer we getting it for because of contracts customers negotiate with our
suppliers.

We have recently begun using safety stock on work-in-progress associated with
where our greatest production bottlenecks are.

> From: jgcarr@durhamcompany.com (Jenny Carr)

>  We repeatedly have problems with the scheduling of customer orders (i.e.
don'
> t have purchase parts when we need them).  Unfortunately, you have to
> schedule items and wait for MRP to run (in our case, nightly) before you
know
> whether you can meet the scheduled date.  Although we use reports that
notify
> our buyers that they need to expedite purchase parts, we have not found an
> effective way to easily identify those customer orders.  I "think" this is
> because of the volume of orders, common purchase parts, and the difficulty
> associated with pegging through 4-8 levels of the bill.  I got excited when
I
> saw the SFC350 program; until I recently discovered that it only includes
> allocations of orders already released (not the ones that are still
planned).
>  For us, that is where most of our inventory is.  Does anybody have any
good
> ideas?
>
>  I saw on a flowchart that SFC350 is typically used before releasing
orders.
> Now I know why.  Assuming that there isn't an easy way to pull in the
planned
> quantities into SFC350, what is a good procedure for to reschedule the
orders
> at that point without affecting capacity issues, etc.?
>
>  Even if we solve this problem, the other problem still exists.  We still
> need to figure a way out to figure out a realistic schedule date based on
1)
> allocations (released to shop), 2) planned, 3) on order and what is
required
> on the customer's order request.  We at one time looked at some APS systems
> to accomplish this, but it doesn't seem like it should be that difficult.
I'
> ve considered building a database that pulls the necessary data from BPCS.
>
>  I'm open for suggestions, but please remember, we are only on 3.7 with
> Nexgen Y2K mods.
>
>  TIA,
>
>  Jenny Carr
>


MacWheel99@aol.com (Alister Wm Macintyre) (Al Mac)
BPCS 405 CD Manager / Programmer @ Global Wire Technologies Incorporated
http://www.globalwiretechnologies.com = new name same quality wire
engineering company: fax # 812-424-6838

Sep 11 Favorite Links:
http://www.nzherald.co.nz/pdf/middle_east.pdf
http://www.semitrue.com/thankyou/
http://groups.yahoo.com/group/TYR
http://www.skirsch.com/politics/plane/disable.htm
http://www.geocities.com/wasabidoh/Pictures.html - select Attack on America

Newspapers World Wide
http://www.wheretodoresearch.com/news/foreign_newspapers.htm
http://www.wheretodoresearch.com/news/US_Newspapers.htm

Intelligence Briefings by country
http://www.nsdmg.org - click on REAL WORLD RESOURCES
http://www.c-span.org/international/links.asp
http://www.cnn.com/2001/WORLD/asiapcf/central/09/17/asia.support/
http://www.odci.gov/cia/publications/factbook/geos/af.html
http://www.economist.com/countries
http://www.washingtonpost.com/wp-dyn/world/search/list/index.html
http://www.debka.com/
http://www.stratfor.com