ERP and Computer Integrated Manufacturing (CIM)
Individual standalone IT applications for structured tasks have been reasonably easy to justify and implement in a specific functional area. Some examples are a computer aided design (CAD) system in design engineering, a statistical process control (SPC) application in quality management, and an automated material handling system in distribution. Efforts to link these stand-alone applications to ERP are termed computer integrated manufacturing (CIM).
This
is Part Three of a three-part article reprinted from Maximizing Your ERP System
by Dr. Scott Hamilton. Bridging the theory and realities of current
ERP systems, Maximizing Your ERP System provides practical guidance for managing
manufacturing in various environments. Drawing on case studies from Dr.
Scott Hamilton's first-hand experience in consulting with more than
a thousand firms, it covers common problems and working solutions for how to
effectively implement and use ERP systems. This excerpt on "Trends Affecting
Manufacturing and ERP" is drawn from one of the book's twenty-five chapters.
The book can be ordered on amazon.com. The trends discussed in this part are:
-
ERP and Computer Integrated Manufacturing (CIM)
-
ERP and Advanced Planning and Scheduling (APS)
-
Evolution of ERP Software Packages
-
ERP and Generally Accepted Manufacturing Practices
For
the first six trends discussed go to Part
One and Part Two.
Reprinted with permission from McGraw-Hill.
Examples of CIM Applications
An ERP system provides the basic planning and control system to manage a manufacturing operation. It provides integration across functional areas, coordination of functional activities to meet strategic plans, and integration of activities between the firm and its customers and suppliers. The relationship between CIM applications and an ERP system can be demonstrated by examples of data exchanges that loosely couple the parts of the system.
-
Computer-aided design applications require item data from an ERP system and
provide item and bill of material data to an ERP system.
- Shop floor
data collection applications require information about manufacturing orders
and routings from an ERP system. They provide material movement and labor
time transactions to an ERP system. Labor transactions may also feed a time
and attendance system or a payroll application.
- Quality management
applications, such as an SPC and laboratory information management system
(LIMS), can provide detailed tracking of manufacturing processes. For example,
quality data may be collected about defects and reason codes, or about product
attributes. This quality data can supplement standard ERP functionality, such
as lot- and serial-tracking and inspection requirements.
- Automated material
handling systems require information about picking and shipping schedules
from an ERP system and provide material movement data to ERP.
- Automated assembly
systems and flexible manufacturing systems require ERP information about the
manufacturing schedule and product/process design, such as routing details,
tools, component parts and identification of numerically controlled machine
programs. They provide information about manufacturing events, such as units
completed and scrap.
- A sales forecasting
system may be as simple as a standard micro-based software package, or a customized
decision support application. An ERP system maintains historical sales data
about bookings, shipments, invoices and returns that provide key inputs to
generating a statistical forecast, and the resulting forecast provides the
primary inputs to ERP for a sales plan and inventory plan.
Approaches for Integrating CIM Applications
Several approaches can be taken to link CIM applications with an ERP system. Tools provided by the ERP software vendor and the software's database management system facilitate (or constrain) the approaches for integrating CIM applications. Ideally, the tools should enable you to extend and supplement ERP functionality without affecting source code, so that you can easily upgrade to new releases from the ERP software vendor. The tools include:
-
Open Database Connectivity (ODBC) Design. An ODBC design within an ERP system
makes it easy to access the data with off-the-shelf industry standard decision
support tools, such as spreadsheets and report-writers. A data export capability
provides the additional benefit of extracting ERP data for use in an external
application.
- Data Import.
Data import capabilities can be used to initially load the ERP database with
data from existing systems. The same tool also enables other applications
to update the ERP database, such as data collection systems and rules-based
configurator packages.
- Event Manager.
Events within an ERP system can be monitored so that additional applications
get launched, or personnel get notified as a result of the event. Events occurring
outside the ERP system may also be monitored to trigger actions.
Before undertaking significant capital outlays for CIM integration, it is critical that business processes be reengineered and simplified. The cost and difficulty of integrating a CIM application increase as the level of integration becomes more extensive.
ERP and Advanced Planning and Scheduling (APS)
Many ERP systems employ MRP logic as the primary engine for coordinating supply chain activities. Advanced planning and scheduling (APS) logic represents a major change from traditional MRP logic for scheduling purposes. To explain the differences, it helps to understand the starting points of MRP logic and APS logic.
MRP logic uses backward infinite scheduling to explode demands for make items through the bills and generate production schedules. It assumes infinite resource capacity and no material constraints, requiring manual adjustments to loads or available capacity during overloaded periods. With manufacturing orders, some ERP systems calculate a variable lead-time and operation due dates that reflect simplistic models of available capacity and scheduling rules. Using MRP logic provides a simple yet sufficient synchronization of supply chain activities for many environments.
APS logic uses finite scheduling based on capacity and material constraints to synchronize activities in the supply chain. In the context of production activities, APS automatically schedules manufacturing orders (and operation due dates) based on comprehensive models of available resource capacity, detailed routing information, and finite scheduling rules. The APS logic underlying a specific schedule can be very complex. This means the scheduling person requires easy drill-down to the scheduling exceptions and rationale. Schedules automatically generated by APS may need manual overrides. APS logic can generate schedules that do not meet due dates, which means demands must be adjusted to align with the schedule (such as revising sales order delivery promises).
APS applications have been maturing so that they are becoming easier to implement and use, as well as less expensive. The comprehensive modeling and finite scheduling logic have a degree of complexity making APS difficult to implement. In addition, APS logic can have difficulties with component date effectivities, phantoms, by-products/co-products, subcontract purchase orders, inventory buffers by resource, and other issues. The focus of APS logic—manufacturing orders—seems to run counter to JIT philosophies involving order-less manufacturing. APS logic has been incorporated into some ERP systems as the primary engine for coordinating supply chain activities. Many ERP systems provide APS logic as a supplement to MRP logic, such as a finite scheduling module. The following case study highlights some of the issues in integrating APS logic with MRP logic.
Case Study: Integrating MRP Logic and an APS Application
One ERP software vendor integrated a stand-alone APS application with its ERP system, where the level of integration evolved through several design iterations. The ERP system acted as the master database for resources, bills/routings, manufacturing orders (generated by MRP logic), and inventory/purchases. This data was replicated in the APS application, where the APS application supported comprehensive models of resource availability.
The ERP application supported infinite capacity planning to identify overloaded periods for key resources, and resource availability was then modified in the APS application. The APS application performed finite scheduling using resource and material constraints, and generated detailed production schedules for each resource. It uploaded the resulting schedule to the ERP system for coordinating procurement activities and making delivery promises. Actual production activities reported in the ERP system provided the basis for calculating remaining work in the APS application.
Integration between the APS application and the ERP system covered most of the manufacturing issues. For example, the integration handled phantoms, planned manufacturing orders, bill of material dependencies, parallel and alternate operations, operation attributes (such as setup matrices), split operations (across multiple machines), and updates to the order-dependent bill in the ERP system. Difficulties were encountered in handling component date effectivities (since they were not recognized in the APS application) and capable-to-promise calculations across a multi-level bill (since MRP logic was required to calculate multiple manufacturing orders prior to downloading them to APS).
APS Logic and the Theory of Constraints
The theory of constraints (abbreviated as TOC) is a management philosophy that focuses attention on the constraining resource within a production process. As a simplified explanation, TOC starts with the production rate of the pacemaker resource, and a time buffer or inventory buffer to protect the constraining resource from disruptions. The production rate and buffer reflect the family of items produced by the resource. Operations at prior (and subsequent) resources are synchronized to the pacemaker resource, resulting in the timely release of materials to support scheduling at the pacemaker. The production schedules for resources involved in prior operations ensure that releases match the production rate (or capacity) of the pacemaker resource. Improvement activities focus on the constraint. This approach has been coined "drum-buffer-rope," since it focuses on the pacemaker's schedule (the drum), its buffer, and the pull-through effect (the rope) on other activities.
APS logic and the TOC approach both employ detailed routing data to schedule orders through the pacemaker or bottleneck resource. Differences between APS logic and the TOC approach include the need for routing data for other non-constrained resources, reporting requirements, and the use of inventory buffers.
-
APS logic uses routing data for other non-constrained resources to synchronize
prior and subsequent operations (via backward and forward finite scheduling),
whereas the TOC approach employs simplistic rules such as lead-time offsets.
It could be argued that simple routing data for APS logic accomplishes the
same purpose as lead-time offsets, and provides additional benefits in costing
and capacity planning.
- APS logic requires
reporting of actual work performed (such as unit completions by operation)
to calculate remaining work at non-constraining resources, whereas the TOC
approach does not.
- APS logic generates
detailed schedules for every resource and focuses on schedule adherence, whereas
the TOC approach focuses on the schedule and inventory buffers at the constraining
resource. In addition, APS logic often has difficulties with the concept of
inventory buffers.
Some environments require more advanced scheduling capabilities. These environments can be characterized by multiple potential constraining resources (dependent on the product mix), multiple parallel legs (rather than a single linear flow), products with widely varying time requirements for the pacemaker resources, and/or resources with varying capabilities. APS logic provides these scheduling capabilities, whereas a TOC approach becomes more difficult.
Evolution of ERP Software Packages
ERP software packages have evolved over time to support a wide variety of manufacturing environments and business practices. They have also evolved in terms of ease-of-use and ease-of-implementation. The starting points for ERP can be traced to early accounting systems that handled sales order processing, basic purchasing functions and inventory, and also to early bill of material processing logic.
Variations in ERP software packages can frequently be traced to their origins. This includes an accounting versus manufacturing orientation, a standard versus custom product orientation, a discrete versus process orientation, a mainframe versus microcomputer origin, and a standard package versus toolkit orientation.
Variations in ERP software packages can also be traced to their maturity and the use of third-party applications. An ERP software package matures over time with additions of new modules and functionality by the software vendor. These enhancements are typically driven by user group requests and target market requirements. Increased functionality frequently reflects increased complexity, especially when new functionality runs counter to the package's fundamental design. This sometimes results in multiple mutually-exclusive versions of software modules. Increased complexity makes it very difficult to re-engineer the software package to a simpler fundamental design. New initiatives in an ERP package are often constrained by concerns about upgrading the installed base, upgrading the technology foundation, and/or the expense of re-writing the entire system. New initiatives are also constrained by the sheer complexity of an existing ERP system. Hence, new initiatives often take the form of third-party packages that are unencumbered by concerns about an installed base or technology platform.
Additional modules within an ERP package frequently reflect third-party packages, with various degrees of integration and replicated data. The arguments for a best-of-breed approach to third-party packages make sense for peripheral ERP applications, such as human resources, quality management, sales forecasting, and CRM. The third-party approach does not work as well with core ERP applications, such as order entry or purchasing, since these require more integration points and extensive common data. Limitations in connectivity tools and in the package's fundamental logic typically constrain approaches to third party packages.
ERP and Generally Accepted Manufacturing Practices
Generally accepted accounting practices have been widely accepted and consistently implemented in most ERP systems. Generally accepted manufacturing practices, in contrast, have not been widely agreed-upon and consistently implemented. This has been complicated by the different ways in which a given ERP system simulates or models a manufacturing business. The conceptual framework underlying an ERP system's design may provide an overly complex approach to needed functionality, or even ignore needed functionality. Extensions to the framework to support new business practices—such as order-less environments—may be cumbersome and overly complex, rather than natural extensions that reflect simple symmetric solutions. Explanations in this book are based on conceptual frameworks that reflect generally accepted approaches taken in most ERP systems, and the body of knowledge represented by APICS (American Production and Inventory Control Society).
The relevant chapters in this book provide further explanations of generally accepted approaches (and natural extensions) for each concept. This includes comparisons to alternative approaches taken in some ERP systems. The key point is that each ERP system can provide different solution approaches to handling various manufacturing practices.
This
concludes Part Three of a three-part article reprinted from Maximizing Your
ERP System by Dr. Scott Hamilton. Bridging the theory and realities
of current ERP systems, Maximizing Your ERP System provides practical guidance
for managing manufacturing in various environments. Drawing on case studies
from Dr. Scott Hamilton's first-hand experience in consulting
with more than a thousand firms, it covers common problems and working solutions
for how to effectively implement and use ERP systems. This excerpt on "Trends
Affecting Manufacturing and ERP" is drawn from one of the book's twenty-five
chapters. The book can be ordered on amazon.com.
For
the first six trends discussed go to Part
One and Part Two.
About
the Author
In
addition to consulting, Dr. Hamilton has conducted hundreds
of executive seminars, taught MBA classes at four universities, and helped design
several influential ERP packages. He can be reached at ScottHamiltonPhD@aol.com
or (612) 963-1163.