Re: Purchasing order policy

[Al Mac <macwheel99@xxxxxxxxxxx>]

I also agree with Daniel.

However, companies can get into this kind of situation when the personnel 
or management forgets that for MRP to work right, you need a certain degree 
of accuracy a lot of places:
* Education for the users
** This is probably the most critical, because people who understand the 
system are able to identify problems, fix problems, work around problems, 
but inadequate education for the users means too many people are clueless
* Inventory
** production reporting, purchase order receiving, inter facility transfers
* Engineering data
** lead times
** production rates
** compensate for what you not track (in our case move and setup time)
* some kind of auditing what the users have been keying in ... 
reasonableness checks to catch human error, and fix it

If you do not have the accuracy in your data base, with the appropriate 
continuing user education, to support ERP working right, then you may as 
well junk ERP and do everything the old fashioned way from 50 years ago, 
when people did not have computers in factories.  The computer can only 
help you if your people cooperate with the computer system, to supply it 
with good data.

We are in a competitive industry in which
(a) potential customers ask for samples from both us and the competition, 
then buy from a place that both delivers on quality, and offers a low 
price, so even if our samples measure up, our prices might not, thus we 
cannot be stocking up on material in anticipation of orders we do not get, 
but when we do get the orders, the customer wants their stuff like 
yesterday, but our raw material lead times are like months away
(b) existing customers expect delivery when we promised delivery, at the 
price we promised, and with 100% perfect quality.  If we slip in any of 
these areas, there is grave risk the customer's future orders, that we had 
ordered raw materials for, will slip off to a competitor

Because of our long lead times for raw materials, and customers with 
varying forecasting (e.g. actual total ordered in a year is wildly 
different from their estimated annual usage which was the basis of our 
price quoting), we use forecast data as planned (not firm) orders, for more 
than one month out.  This means purchase orders are made for what is needed 
5 or more weeks out, while shop orders not made of what is more than 1 
month out needed.  Due to some customers orders on short lead times, we 
need a better system to link what we need to buy/make, tied to the customer 
it is for, because of different customers having different behavior 
practices.

This is related to the company's decision to invest in BPCS in the first 
place, at a time when we already knew we had this kind of situation for our 
industry.  I identified to management another ERP that was better for our 
industry, and better for many of these challenges, and asked if that had 
been considered.  My boss said the other package would cost $ 3 million 
more than BPCS, which was $ 2 million more than they could ask the CEO for.

Given the high $ cost to get and keep an ERP, the idea of saving money on 
education for users mystifies me, since there is high cost from people 
using the system ineffectively.

There has also been past BPCS threads of relevance (check the archives)
* Suppose orders are past due when they are entered to the system.  Does 
BPCS calculate them correctly?  (clue ... if you have a huge spike in what 
is past due, the odds are you not managing that well)

Daniel wrote:
> Hi Joe
>
>
> I dont think the order policy code will resolve this problem. From what you
> are saying, this is an order management issue.
>
> BPCS creates planned orders for a reason, usually because there is a
> forecast or a customer order in the system, and there is not enough
> available stock.  If you dont want to execute some planned orders, this is
> symptomatic  of a planning problem right at the source of your MRP demand,
> like having forecasts no one believes in,  or invalid (false) customer
> orders. Either situation will not be corrected by order policy codes, but by
> the appropriate management of the MRP demand input.
>
> It sounds as if  someone is trying to double guess the whole MRP calculation
> and logic process, which is terribly a bad practice. Might as well turn off
> MRP completely, and do the shop order and purchase order planning outside of
> BPCS.
>
> Daniel Warthold P. eng CPIM
>
>
>
> ----- Original Message -----
> From: "Joe McCormick" <joemccormick@xxxxxxxxxxxxxx>
> To: "SSA's BPCS ERP System" <bpcs-l@xxxxxxxxxxxx>
> Sent: Tuesday, February 14, 2006 10:09 AM
> Subject: [BPCS-L] Purchasing order policy
>
>
> Hi,
> What would be the most suitable order policy to use in order to only
> purchase for firm (not planned ) shop orders. We currently by for both but
> are finding this is contributing to excess inventory as many planned orders
> are not made.
>
> Thanks
>
> Joe
>
>
> ----------------------------------------------------------------------------
> ----
>
>
> No virus found in this outgoing message.
> Checked by AVG Free Edition.
> Version: 7.1.375 / Virus Database: 267.15.7/259 - Release Date: 13/02/2006
>
>
>
> ----------------------------------------------------------------------------
> ----
>
>
> > --
> > 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: daniel.warthold@xxxxxxxxxxxx
> >
>
> --
> 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: macwheel99@xxxxxxxxxxx