My background in MPS goes back to the mid and late 1970's when Arista
Manufacturing Systems out of Winston-Salem, NC developed and marketed the
first MPS module.

The primary usage of MPS is not to "... create smaller subsets of capacity
or order critical items."  Rather MPS's focus is to manage the production

The production plan consists of a fixed quantity to be produced within a
given timeframe - typically weekly - over a company's planning horizon.
Rather than drive sales demand directly into MRP it is this fixed weekly
production quantity that drives MRP and its planning of purchased and
manufactured sub-components.  Driving MRP off a planned production quantity,
rather than directly from sales orders stabilizes the production floor.
Rarely is it necessary to interrupt production to rush a priority order.  

MPS logic is simple, allowing the production plan to be managed with very
little data analysis.  The first step is to set a weekly production
quantity.  This is done by evaluating sales forecasts and using rough cut
capacity planning to determine the feasibility of the production plan.  

In day to day operations booked sales orders consume the uncommitted portion
of the production plan (known as the Available to Promise quantity or ATP)
reducing the ATP quantity.  When the ATP goes negative the sales orders'
promise dates are moved to the nearest period with available ATP (nearest
ATP may be in an earlier or later period).  Only when the ATP goes negative
and there are no other alternatives, is the production plan number

The primary benefit realized from using MPS is a very high on time shipment
performance.  In the 1980's and early 90's on time shipment performance
climbed into the high 90 percentile range.

Use of MPS diminished as customers began to demand shorter lead times and
specific date shipments.  Specific date shipment requirements in particular
render the MPS ineffective.  The effort to set and manage a daily production
plan takes away from the effort required to meet customer demands.  The cure
has been to remove MPS from the picture and drive MRP directly from sales
orders.  However there has been a price to pay.

As customer demands change (add this line item, change this ship date,
cancel this order, etc.) so must the daily production plan and since the
daily production plan is driven directly from sales orders it changes daily.
Managing daily priorities is now the focus and as a result on time shipment
performance has suffered.  Today firms count themselves doing well if they
ship above 90% on time.  I know of several firms whose objective is to ship
90% on time and expend tremendous efforts to make that happen.

Roy Luce

Systems Plus - Midwest

Direct: 847-540-9635
Cell:   847-910-0884
Fax:    847-620-2799
Email:  rluce@xxxxxxxxxxxxxxxxxxx

-----Original Message-----
[] On Behalf Of Daniel
Sent: Friday, October 20, 2006 8:29 AM
To: SSA's BPCS ERP System
Subject: Re: [BPCS-L] Resell Purchased / Master Schedule ?

If you regenerate MRP as often as you regenerate MPS, there should not be 
any problems. The requirements of the MRP items will be cought, and al the 
necessary orders will be planned to cover these requirements.

As a matter of fact., I dont see as much of a need today to spit items 
between MPS and MRP, given the speed computers can regenerate MRP. My 
understanding is, 20-30-40  years ago, because MRP took hours to run, there 
was a need to cut the MRP generation process into a smaller subset of 
capacity critical  or order critical items, the MPS items , and the other 
non-critical items:  the MRP items. Any toughts on this?

Daniel Warthold

----- Original Message ----- 
From: "Al Mac" <macwheel99@xxxxxxxxxxx>
To: "BPCS_L discussion" <bpcs-l@xxxxxxxxxxxx>
Sent: Friday, October 20, 2006 1:24 AM
Subject: [BPCS-L] Resell Purchased / Master Schedule ?

  * One rule of thumb says MRP140 needs to "M" Master Schedule End Items
  that we manufacture and sell for customers, so that MRP will calculate
  what's needed of all components to be manufactured or purchased.
  * Another rule of thumb says raw material that we purchase to be used as
  components of the manufactured parts, nor any sub-components, should not
  be "M" coded, just the end items that we sell the customers.
  * A dispute has come up with respect to what is the correct Master
  Schedule coding for items that are coded purchased, but can also be sent
  customers as THEIR service or repair parts?

  It has been several years since we had MRP education, so different 
  memories stray into disagreements needing clarification.

  I had thought that when the raw materials show up as components of 
  scheduled items, currently on customer orders, that MRP will correctly
  calculate how many we need thanks to both dependent and independent
  requirements, but if a customer orders a supply of our raw materials, 
  are not currently needed due to being in the BOM of master scheduled
  active items, then by not having these raw materials master scheduled, 
  have effectively told MRP to ignore these requirements, and that having
  extra items coded as master scheduled did no harm to MRP.

  We are on BPCS 405 CD mixed mode.
  We run MRP500 then MRP600 by facility, with a few extra runs of MRP500
  thanks to a prior thread on BPCS-L regarding parts complexity.
  Our BOM has several levels.  We used to be heavy into DRP resupply 
  but that part of our business is now about dad.

  Al Macintyre
  BPCS/400 Computer Janitor ... see
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,
or email: BPCS-L-request@xxxxxxxxxxxx
Before posting, please take a moment to review the archives

Delivered-To: daniel.warthold@xxxxxxxxxxxx

As an Amazon Associate we earn from qualifying purchases.

This thread ...


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

This mailing list archive is Copyright 1997-2022 by 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.