|
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
As an Amazon Associate we earn from qualifying purchases.
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.
midrange.com
