× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



I'm sorry but I can not let this thread go any further without interjecting
some thoughts about planning versus execution.

Al Mac makes two points in his commentary:

1. What we doing with less clerical than you guys is that by releasing shop
orders, purchase orders, resupply orders ... this has the same effect as if
the MRP  planned orders get firmed.  So that eliminates an enormous volume
of the manual work you doing interacting with BPCS.  However, then we have
to manage orders released perhaps too early, whose requirements tend to
fluctuate due to changes in customer orders.  This can lead to us having
excess inventory, because we made something for a customer order that ain't
there any more, so we need to do a better job of tracking the effects of
deleted customer orders.

2. The alternative is the extra clerical work in BPCS,
or risk critical stuff get overlooked,
or risk that the business rules get changed, and the programmer unaware of
the rules changes, or what programs affected

These 2 points are perfect examples of the problems one faces when trying to
use a planning systems to handle execution issues.
Remember planned orders are just that - for planning purposes.  Their
appearance is the last step in the planning process.
The act of firming planned orders is the first step in the execution
process.
But Al points out the drawback to automatically firming planned orders - the
clerical effort gets transferred from the planners to production control.
The other drawback is the inventory challenge AL points out - it tends to go
up.

Part of the clerical effort, regardless of whether the effort is focused on
planned or firm planned orders,
is trying to figure out which work orders are required for customer orders
(and which customer orders)
versus which of the work orders are simply for inventory replenishment.

So if this is the challenge what is the solution?  One solution is Rapid
Priority Management (RPM) concepts.

RPM systems use a derivative database built off the ERP database to support
the execution side of the manufacturing system equation.
One of the features found in RPM systems is a planner's work bench which
tells them specifically
which work orders need to be firmed and which work orders need to be
released.
There is also a buyer's work bench which tells the buyers which requisitions
need to be released and which POs in what quantities are critical to
production.
The driver for all levels of the BOM is customer sales orders -  the
appearance of a work order for a part 4 levels deep on the work bench means
it is required for a sales order.

If you have access to Carol Ptak's ERP Tools, Techniques and Applications
for Integrating the Supply Chain - Second Edition, St. Lucie Press, check
out her overview of RPM starting on page 188.



Roy Luce

Main:   847-540-9635
Cell:   847-910-0884
Fax:    847-620-2799 *new*
Email:  lwl@xxxxxxxxxxxxx

-----Original Message-----
From: bpcs-l-bounces+lwl=ix.netcom.com@xxxxxxxxxxxx
[mailto:bpcs-l-bounces+lwl=ix.netcom.com@xxxxxxxxxxxx]On Behalf Of Al Mac
Sent: Friday, October 07, 2005 3:49 PM
To: SSA's BPCS ERP System
Subject: Re: [BPCS-L] Firming Planned Orders

I snipped out some excess lines before replying.

You guys may be doing some extra clerical work.
I certainly believe we are also.

What we doing with less clerical than you guys is that by releasing shop
orders, purchase orders, resupply orders ... this has the same effect as if
the MRP  planned orders get firmed.  So that eliminates an enormous volume
of the manual work you doing interacting with BPCS.  However, then we have
to manage orders released perhaps too early, whose requirements tend to
fluctuate due to changes in customer orders.  This can lead to us having
excess inventory, because we made something for a customer order that aint
there any more, so we need to do a better job of tracking the effects of
deleted customer orders.

Where I think we have excess manual work in need of some future
modifications.  The CIC file (item facility planning and cost summary)
record for any given item gets automatically created by BPCS, if it not
already exists, if there is any activity for the item in the facility that
could impact MRP, such as customer order input, engineering work.  However,
at time of creation the records have all kinds of defaults we do not like,
such as nothing is master planned ... I would like it if the CIC record is
auto created because of a customer order, that it should default to being
master planned.  There's a whole bunch other fields where I think the
defaults poorly thought out by SSA, and some that are related to our own
standards such as lead times.

This leads to a need for people to be supposed to check CIC in association
with those first entries, which sometimes overlooked, until question comes
up ... how come MRP is ignoring these customer orders?

One way to fix this would be to have the Company Business Rules for BPCS
Data Base Defaults stored in some kind of ISO document that identifies what
programs need to be updated in association with each rule if that rule gets
changed, then have some programs that run regularly to fix CIC defaults to
agree with current company rules.

The alternative is the extra clerical work in BPCS,
or risk critical stuff get overlooked,
or risk that the business rules get changed, and the programmer unaware of
the rules changes, or what programs affected

>Arghhh!  Never mind.  You are correct and that's the way that I was
>thinking that it should be.  It looks like it was set up incorrectly with
>facility planning data for another facility.  It turns out that the guy
>does manually convert his planned orders to firm planned orders.  It's just
>that the one for this item wasn't showing up in the list when he does
>release planned orders.  Sorry for the confusion.
>
>Dave Parnin
>--
>Nishikawa Standard Company
>Topeka, IN  46571
>daparnin@xxxxxxxxxxxxxx
>
>
>
>                       "Daniel
> Warthold"
>
>
>Planned orders can only be firmed up manually, one by one, at the planner`s
>will, for which he should have a good reason for firming them up. Thara are
>advantages, but there are also risks involved in firming orders.
>
>Daniel Warthold
>
>
>----- Original Message -----
>From: <daparnin@xxxxxxxxxxxxxx>
>Subject: [BPCS-L] Firming Planned Orders
>
> > Is there a flag somewhere to have MRP/MPS skip the planned order and go
> > directly to a firm planned order?  It's been awhile since I've worked
> > MRP/MPS in depth but I seem to recall that the firming up process was a
> > manual one.  Today I got a call from a guy about a planned order asking
>why
> > it wasn't a firm planned order.  This is a new part that was set up by a
> > fairly new person.  The call came from someone who has been in his
>position
> > for awhile and I tend to believe him when he says that they are always
>firm
> > orders.  Any thoughts would be appreciated.
> >
> > Dave Parnin
> > --
> > Nishikawa Standard Company
> > Topeka, IN  46571
> > daparnin@xxxxxxxxxxxxxx
--
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: lwl@xxxxxxxxxxxxx



As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.