ERP systems software had its beginnings as MRP systems, as defined by Joseph Orlicy for the discrete job shop environment. Oliver White expanded on the concept with MRP II in the 1970’s. At the time, the overwhelming manufacturing activity was in companies that manufactured in discrete batch orientated environments. As MRP concepts expanded, software companies seeking to develop applications viewed the MRP template as an opportunity to sell their product.
As conceived, MRP was a rigid template. It included only modules for Bills of Material, Product Master, Inventory, Master Production Scheduling, Material Requirements Planning, and Shop Floor. Later the template was expanded to MRP II and included Purchasing/Receiving and Accounts Payable. Job shop environments continued to occupy the large portion of manufacturing activity, and software companies attempting to capture as much of the market they could, packed more and more software functionality into the existing MRPII modules to achieve a competitive edge.
In the mid to late 1980’s through the 1990’s two major thoughts took root that changed the manufacturing software picture. First was the idea that manufacturing is only part of the picture; companies still had to deal with Order Entry and the Accounting Systems. Software companies then began to include these modules in an integrated database. This became known as ERP. Second was that as companies continued to grow with increasing order quantities, Job Shop technology was no longer the most efficient way of manufacturing. Aligning work centers into assembly lines for dedicated production facilities provided economies of scale for repetitive manufacturing. Software companies scrambled to adapt their existing discrete applications software to include Repetitive Manufacturing capabilities. Their logic – “we have 90% of the functionality already coded in our product.” This was a fatal mistake. It is the 10% difference combined with the existing functionality that over extends the software product and makes it unwieldy.
Let’s look at the 10% difference between discrete and repetitive assembly manufacturing. Differences in the accounting applications are relatively minor since all must accommodate Generally Accepted Accounting Principles. To provide focus I will relate the discussion points to the original MRP template where the differences can be easily understood.
- Product Master - This is the portion of the system which lists the raw, component and finished goods so that the other software modules in the MRP application can reference the descriptive material within its database. Referenced by part numbers, this database contains indicative information such as item description, manufacturing and purchase lead times, cost information, as well as other descriptive information. The requirements of Job Shop and Repetitive manufacturers are similar for the product master and both methodologies co-exist without creating too many issues.
- Bills of Material - This is a listing of the components arrayed in a hierarchical structure similar to the method of manufacturing, are much simpler for a Repetitive manufacturer than for a Job Shop manufacturer. While each may be required to have engineering and costed bills, there is no need for phantom bills, whose purpose is to create interim assembly reference numbers to store in process inventory. Further, a repetitive manufacturer will usually have flat bills as opposed to the highly structured bill, with many levels, often required in Job Shop Manufacturing. Some software providers have even expanded their bills to incorporate production routings but this function would just get in the way of a Repetitive manufacturer. While there are other feature differences, appropriate workarounds can be created to reduce the impact for a repetitive manufacturer.
- Inventory - While the inventory module seems on the surface to be able to serve both the job shop and repetitive manufacturers, there can be significant issues. On initial pass, both types of manufacturing require the same support in inventory accounting, storage and retrieval, historical usage, and so on. The major difference is getting raw material and components to the floor. Discrete job shop manufacturers issue material to the floor through pick tickets linked to open work orders. The quantities tend to be smaller than their repetitive counterparts and are one issue per work order.
In a repetitive environment, where volume is typically significant, material should be flowed to the shop floor and timed to the production process. In this way, repetitive manufacturers do not clog their shop floor with inventory which can remain on the floor for the entire production run. Additional features, such as JIT and floor issued inventory have been adopted and supported by Repetitive manufacturing. These features are not usually found in job shop software and workaround processes may be required.
- Master Production Scheduling - - This module establishes the projected output the factory will produce. Inputs are the forecasts and the orders for finished products. While repetitive manufacturers may have fewer items that they manufacture, the quantities produced are significantly higher than job shop manufacturers. The difference in numbers may not be significant but the repetitive manufacturer usually needs less software support, does not need to schedule work orders among a large group of work centers. Therefore, a simpler scheduling application will suffice.
- Material Requirements Planning - This module is one of the most significant in the manufacturing execution process. Job shop manufacturers need this module to “explode” their finished good requirements into work orders and then into a finite production schedule. Further, based on the “explosion” they will issue requisitions for material not in inventory. The “explosion” is dictated by the indented levels from the bills of material. Repetitive manufacturers certainly use the material requisitions from this module but since they typically have a flatter bill of materials, their requirements are not that demanding. Based on the software package, the repetitive manufacturer, to preserve the software system application flow, might have to go through this module and simulate the process to use the shop floor control module.
- Shop Floor Control - - This module is necessary to control the movement of material on the shop floor, collect manufacturing data such as costs, completions, quality, scrap, material issues, etc. It performs a vital function for a Job Shop manufacturer but gets in the way in a Repetitive manufacturing environment. A Repetitive manufacturer can just look on the floor to see how the plant is performing. He does not have to be concerned about work order movement, since there are fewer work orders. Productivity can be determined by counting the products coming off the line and by knowing when the line started and stopped. Employee labor is easy to compute since they must be on the line when production is run. The is no need for real time shop reporting for Repetitive manufacturing Thus shop floor control, while essential for a Job Shop manufacturer, is just an impediment in a Repetitive environment.
As noted earlier, all ERP software packages have accounting modules that conform to GAAP, Generally Accepted Account Principles. Variations for accounting are not usually significant when selecting a software package. Order entry can be difficult but except for certain functionality like a configurator, can normally be managed through workarounds and reformatting the data entry screens. Of more significance in order management is whether the manufacturer builds to stock or to order.
Selecting the wrong manufacturing package, i.e. one that doesn’t specifically and directly address the needs of repetitive manufacturing can be a disaster. Look for manufacturing software specifically geared to your environment, be it job shop or repetitive manufacturing. Process and software modifications to an application suite not intended for your manufacturing environment will result in increased implementation costs, higher software maintenance costs, and create worker frustration resulting in a failed implementation.