Home
 > Research and Reports > TEC Blog > Trends Affecting Manufacturers and ERP Part Three: Four M...

Trends Affecting Manufacturers and ERP Part Three: Four More Trends

Written By: Dr. Scott Hamilton
Published On: October 8 2003

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.

 
comments powered by Disqus
Popular Searches

Recent Searches
A B C D E F G H I J K L M N O P Q R S T U V W X Y Z Others

©2014 Technology Evaluation Centers Inc. All rights reserved.