8:29 AM
Material Requirements Planning (MRP1) is based on the principle:
There are 3 major groups of MRP1 systems (and we have seen a few oddballs). We will not go into detail on the first two below in this article, except to say that they are valid methods with advantages and disadvantages over the third, and more information is available on request.
- "Gross Requirements" (ignoring stock) (Not popularly implemented in modern ERP software, and much simpler than the other methods, whilst having some obvious drawbacks, significantly reduces the "Forrester effect" caused by "nervousness", see below).
Two types of "Net Requirement" systems exist:
- "Bucketed" systems will be covered by a future article. Again not popularly implemented in ERP systems (and in most circumstances not needing an ERP system), this type is significantly better suited to Just in Time (See JIT) environments, in conjunction with "Period Batch Control",
- "Unbucketed" systems, which are popularly implemented in many ERP systems are described below.
Within these 3 groups there are two modes of processing making 6 types of system to choose from:
- "Conversational Planning" which we recommend and which we will discuss in a future article.
- Non-conversational, which we do not recommend, but which is incorporated into many ERP systems, and is described below.
The Bill of Material (BOM) or parts list is exploded into its constituent parts and multiplied by the requirements for these parts from the Master Production Schedule (MPS) (order book or forecast).
Stock is deducted (net requirements) and the lead-times allowed for, to give start dates for the works and purchase orders / schedules. Further provisions can be made for scrap allowances and batching rules (See Participative Sales and Operations Planning). This acts as the demand for the next level (in the BOM) constituent parts. Requirements are aggregated at each level from all sources to create a total requirement at that level. This calculation is then performed and the result passed down to the next level (in the BOM) where it is added to other requirements for that item and the process repeated until the bottom level of the BOM is reached. All of these calculations are conducted as one hit, in a process which is described as "regenerative processing", and because it may take a little time to recalculate everything using this method, a second method of processing is incorporated into many ERP systems called "Net Change", which simply recalculates items which are affected by a change at any level.
Notes:
1. Nervousness:
"Nervousness" is the tendency of the net requirements to fluctuate alarmingly in response to some higher level changes. E.g. the scrapping of one component can result in a requirement to produce another batch of parts immediately. "Forrester" first investigated this amplification of minor changes in his book "Industrial Dynamics". (Also see "Lean Supply Chains".) There are ways of reducing this effect!
Shims are the best example of selective assembly. The demand for a particular shim is dependent on the size of the gap to be filled, rather than dependent on the number of products produced (although it has some non-linear relationship to this). Therefore this type of usage together with some other types, which we discuss in our course, are not suitable for MRP1 planning. To overcome this problem some people advocate the use of "Planning Bills of Materials", which are "average Bills of Material", (e.g. on average 1.5 shims are used per product.). Our experience of trying to use this technique is unfavourable and we believe that there are better methods. We will discuss this in a future article.
3. Compliance:
MRP systems can be measured by "compliance" which simply counts the number of occurrences where the output from MRP cannot be followed and must be changed. We will discuss this in a future article.
Advantages and disadvantages
It is largely assumed by the software industry that this technique is universally applicable. It is not! Indeed there are many situations where it is overkill and other situations where it is positively counterproductive and damaging. Frequently the data structures and recording mechanisms and control processes are not set up correctly, resulting in a degenerate, sub-optimal or faulty operation of the system. We will not go into all our reasoning here but a detailed critique is available on request.
Measures of Performance (MOPS) (See Focused Improvement Systems)
In order for you to perform the above calculations "what you need, minus what you have got = what you need to get" the system requires a high degree of data accuracy. So data must be captured in such a way that accuracy can be relied upon. (See Previous Best Practice of the Week B044: TRAP (Rules for data collection)). Data accuracy is also a key performance criterion therefore. We will discuss how to measure this in a future article, but one of the Key Performance Indicators (KPI's) for an MRP system is on-time delivery.
The variables inherent in the system are:
- Master Schedule
- Bills of Material (BOMs)
- Stocks & Work in Progress (WIP)
- Lead-times
- Work orders / schedules
- Purchase orders / schedules
- Yields
- Working days / times
Probably the biggest single cause of MRP problems, an unstable and "un-doable" Master Production Schedule, will kill your MRP system stone dead. The master schedule is controlled by the Sales and Operations Planning process. What you will make and when are probably the most important decisions in a manufacturing business. It is therefore surprising that these decision are often left to chance, or that the order is simply accepted with no view of its "do-ability".
Bills of Material (BOM)
Bills of Materials must be created as a part of the New Product Introduction process and then controlled via a Specification Change Management process. If picking is performed the pick list acts a form of control. I.e. if it is not on the pick list it does not get picked. This can often be a useful source of feedback for BOM errors.
Bills of Material Design is covered by our M03 Bill of Material & Routing Design & Management training course and paraphrased in Previous Best practice of the Week B014: Effective Bill of Material Design. Product Change is covered by our D02 Specification Change Management training and paraphrased by Previous Best Practice of the Week B022: Change control.
Stocks and WIP
Stock and WIP accuracy is a major cause of problems in MRP systems. However the concept of stock accuracy sometimes gets lost in the daily life of the operation. Like the sales director who stormed into the stores and demanded an urgent part for a customer. When asked for a requisition he blew his top and removed the part. Stock accuracy at that company died on that day. Procedures must be followed. Leadership is essential. If the prescribed procedures are not a natural way of operating the discipline will quickly break down. This is covered by Previous Best Practice of the Week B029: Bin Discipline.
Lead-times
Lead times are often assumed to be fixed in MRP systems. In fact this is most definitely not true. They need to be monitored. (See Previous Best Practice of the Week B010 Lead time reduction and Participative Sales and Operations Planning)
Work Orders / Purchase Orders
The other major problem in the day-to-day operation is the problem of ghost work or purchase orders. Orders which have already been complete but because the bookings are not complete there is a residual (sometimes small) quantity still outstanding on the order.
Yields
Unless yields are significant they should be ignored in MRP systems, because they lead to mysterious movements of work orders and not being able to understand the MRP output. If they are significant the planned yields need to be reviewed regularly and abnormal scrap reported routinely by exception. Rework must be quickly reprocessed!
Calendar
Finally do not forget to maintain the calendar(s) with your working times / days. Set a date for doing it.
Output
The output of an MRP system consists of action messages highlighting exception conditions caused by changes and data errors. Firstly these messages need to be handled in a sequence which we discuss on our course, and secondly these need to be managed and particularly at implementation, need to be controlled.
No comments
Post a Comment