Integrating PDM and ERP Systems with IBM Manufacturing Release Management

IBM Redbooks Solution Guide

Published 16 April 2014

More options

Rate and comment

Authors: Amaresh Rajasekharan, David Reese

Abstract

IBM® Manufacturing Release Management is a new solution for improved manufacturing and resource planning. Companies have long known that effective management of new design and engineering releases is essential, not only to the manufacturing process but for reducing overall supply chain risks. As supply chains become more software-driven, the integrated flow of design and release information has emerged as a critical factor.

As described in this IBM Redbooks® Solution Guide, Manufacturing Release Management acts as a bridge to carry product design and related data from an enterprise's Product Data Management (PDM) systems with its Enterprise Resource Planning (ERP) systems. Along the way, it can validate the data from the PDM systems, transform the data from Engineering Bills of Material (EBOM) to Manufacturing Bills of Material (MBOM) format, and move the transformed data to one or more ERP systems that can use it. This broad functionality makes Manufacturing Release Management the linchpin companies need to efficiently and effectively connect the development of new products to their production, application, and successful entry into the marketplace.

Contents

IBM® Manufacturing Release Management is a new solution that applies to the Product Lifecycle Management process and acts as a bridge to carry product design and related data from the Design and Engineering domain to the Enterprise Resource Planning (ERP) domain, where it can help support improved manufacturing and resource planning. Here are some of the solution’s core capabilities:

  • Retrieval, validation, and interpretation of data from Product Data Management (PDM) systems
  • Transformation of the data from Engineering Bills of Material (EBOM) to Manufacturing Bills of Material (MBOM) format, including any needed deviations, such when multiple manufacturing locations are involved
  • Transfer of the product data to one or more ERP systems or other systems that can use it

The solution (see Figure 1) is, essentially, a service-oriented architecture (SOA) that uses a set of IBM middleware products and service assets that work together within a prescribed architecture. The involved products include IBM Integration Bus (IIB) as the common integration backbone, providing connectivity to various data sources such as file systems, IBM Operational Decision Management, which serves as a platform for business rules management, and IBM WebSphere® MQ as a messaging conduit to and from back-end applications. In some specific cases, an IBM DB2® UDB-based database server might be necessary to store intermediate artifacts and runtime data. For advanced requirements involving long-running processes and human-centric workflow requirements, IBM Business Process Manager (IBM BPM) can be used instead of (or with) IIB.

IBM Manufacturing Release Management solution - conceptual information flow
Figure 1. IBM Manufacturing Release Management solution - conceptual information flow


Did you know?

IBM brings two key capabilities to help ensure successful implementation of a bridge solution such as Manufacturing Release Management. First is a product portfolio with both software and hardware, which is ideal for end-to-end solutions. Second is the proven consulting experience of IBM in manufacturing and in configuring PDM processes to maximize clients’ IT investments.


Business value

Effective management of new design and engineering releases is essential to the smooth manufacture of products and a key part of reducing supply chain risks. As supply chains become more software driven, the integrated flow of information emerges as a critical factor.

The Manufacturing Release Management solution can be the linchpin that efficiently and effectively connects the development of new products to their production, application, and successful entry into the marketplace. More specifically, the solution addresses these important business objectives:
  • Reduction in errors because of manual BOM processing

    When processed manually, product data and configuration details can be highly prone to error. The presence of such errors can result in redundant redesign work and lead to delays in the finished product timeline.

    The solution is to use a combination of robust integration flow and change management processes with proper approvals and rules-based BOM processing. The Manufacturing Release Management solution incorporates all of the essential building blocks to minimize errors in BOM processing.

  • Fewer engineering changes and redesigns

    BOM and configuration errors can happen for many reasons. In addition to the problems that are related to manual processing, configuration errors can be introduced into the PDM system, and propagating these errors to the enterprise’s ERP system creates even bigger problems. It is important to trap these errors before additional revisions are done to the involved engineering artifacts because those revisions can trigger redundant changes involving multiple systems, additional revision cycles, and corresponding wastes of time and money.

    The Manufacturing Release Management solution architecture prescribes rules-based validations of product data before that data is committed in the target ERP system. If the product data is found to be prone to error, the infrastructure exists to notify the operator, and when needed, halt future artifact releases until the errors are resolved.

  • Reduction in compliance failures and rejections

    Regulated industries such as aircraft manufacturing require extensive documentation. At a minimum, every product configuration and revision must be documented and approved by authorized personnel using special, legally privileged forms and paperwork. Errors that are introduced in this documentation process can result in BOM and configuration inconsistencies that can lead to audit failures and expensive rework.

    The Manufacturing Release Management solution architecture includes components to perform BOM verification by using a process that is controlled by Engineering Change Orders (ECOs), which enable a proper BOM reconciliation between the PDM and ERP systems.

  • Shorter time from design to market

    All of the business challenges that are listed so far contribute to delays in the time that it takes a product to go from design to market. Manually introduced errors and compliance rejections cause rework that might have been avoided. So, by meeting the individual business objectives that were outlined, an even higher business goal can be achieved by getting products to market faster than otherwise possible.

    A solution such as Manufacturing Release Management helps reduce delay-inducing errors and push products to market faster.

  • Lower total cost of ownership (TCO)

    Any bridge solution, such as Manufacturing Release Management, must be cost-effective to create and maintain. In discrete scenarios, new product lines are introduced, suppliers enter and leave the business, and manufacturing locations change. Some products are made to order, and others are made to stock. Also, the rules governing BOM transformations and routing can change. However, modifying an enterprise’s solution implementation each time is a costly effort.

    The Manufacturing Release Management solution uses the notion of operational decision management to abstract BOM transformation and routing rules. You can use this capability to compose the rules in a natural language, such as plain English, and then create versions of and deploy rule components without stopping production. This approach uses standards-based models that promote the use of business vocabulary in a manner that is friendly to domain users and business analysts, thus reducing the gap between business and IT.



Solution overview

The Manufacturing Release Management solution enables the release of engineering artifacts to ERP systems and other systems that involve BOM processing as one of their transactions. These engineering artifacts can include parts, assemblies, documents, CAD drawings, model files, and so on.

The solution flow typically begins with a release action in the system of record, in this case a PDM system. The action can be as simple as an event notification about a small payload or a more complex file export involving a full ECO. The solution’s PDM adaptation subsystem reads and processes the information and, in the more complicated case, the solution’s complex event processing component takes effect to coordinate retrieval of the full product structure that is affected by the ECO.

A large payload might need pre-processing, such as splitting up the data and storing the fragments for incremental processing. The data is then validated for completeness and prepared for next-level processing that is specific to each implementation and uses customer-specific business logic, including which ERP system should receive the updated product structures. This processing is performed in the solution’s integration workflow subsystem that runs on top of an ESB.

After the target ERP system is determined, the new product structure is converted from EBOM to MBOM format by using a combination of mediations in the ESB and rules-based data transformations in the business rules management system (BRMS). The integration workflow subsystem enforces rules regarding process and data integrity, including what data can be created, deleted, or updated in the ERP system, and when that should occur. The integration workflow subsystem also reconciles the BOM versions between the PDM and ERP systems to ensure consistency.

The transformed BOM is sent to the appropriate ERP system adapter for invocation of suitable APIs on the ERP system to, for example, create, modify, or delete the affected engineering artifacts. This adapter may be a standard one for popular ERP systems such as SAP, or it could be a technology adapter such as a flat-file adapter or a database adapter.

Some implementations of the solution require service lifecycle governance, such as selecting service endpoints based on criteria such as date, product line, production strategy, test or production environments, and so on. Service lifecycle governance also covers any needed changes to BOM transformation rules and rule applications.

Ideally, the events that are generated during these processes should be stored in a solution-level database. For example, when large product structures are involved, the solution uses a persistence subsystem to store subsets of the product data for incremental processing.

The design-time and build-time artifacts for the solution subsystems can be built by using development tools that are available within each component. For example, IBM Integration Toolkit provides the tools to build artifacts for IIB, and IBM WebSphere Integration Developer provides a similar capability for IBM BPM.


Solution architecture

The solution involves many logical components and associated IBM products or assets. These components are shown in Figure 2 and explained in the paragraphs that follow the figure.

High-level architecture of the IBM Manufacturing Release Management solution
Figure 2. High-level architecture of the IBM Manufacturing Release Management solution

PDM system adaptation

Obtaining the data from the source PDM system is accomplished by using one or more of these products and service assets:
  • Adapters to the file system: These adapters are available with both IIB and IBM BPM.
  • Support for JMS queues: This support is available with both IIB and IBM BPM.
  • Adapter for DBMS: A JDBC adapter is available as a separate component, but database connectivity is also available with both IIB and IBM BPM.
  • Custom adapters: These adapters can be built for systems such as Siemens Teamcenter, PTC Windchill, and Enovia, either by using a wrapper class involving PDM system APIs or by using an IBM adapter toolkit.

For PDM systems that are either "homegrown" or have no service APIs, the usage of technology adapters such as the file and database adapters that are described above is recommended. For systems with a robust set of APIs, service invocation can be considered.

ERP system adaptation

Adapting and transforming data for use by the target ERP system is accomplished by using one of these components:
  • Adapters to the file system
  • Adapter for DBMS
  • Dedicated adapter (for example, the SAP adapter that comes with either IIB or IBM BPM)

For ERP systems that are either "homegrown" or nonstandard, the file system or database-oriented approaches are the preferred choice.

Complex event processing

Events in the involved systems are exchanged as messages between components, and the solution processes these events in two primary ways. For implementations requiring only basic asynchronous messaging capability, IBM WebSphere MQ can be used with either IBM BPM or IIB. For advanced event processing capabilities, IBM Operational Decision Management (ODM) is recommended. ODM provides a rules-based approach to handling events.

Integration workflow

IIB is the default Integration Bus for the Manufacturing Release Management solution and provides a wide range of connectivity options and supports many protocols. However, for integrations requiring long-running transactions and human-centric steps, IBM BPM is recommended.

Mediations (data transformation)

Several different IBM products can be used to transform product structures from EBOM format to MBOM format:
  • IIB can support both data transformations and schema mapping. The WebSphere Message Broker toolkit provides tool support, such as XML Mapper.
  • IBM BPM provides a built-in business rules manager that can be used for data transformations. The related schema mapping can be accomplished with either the BO Mapper or XML Mapper tools, both of which are part of IBM Integration Designer, the design time tool for building components for IBM BPM.
  • ODM provides a rich, rules-based platform to implement BOM conversions by using business rules. This rules application can be deployed on Rule Execution Server, and the rules can be collaboratively authored by using Rule Team Server, both of which are components of ODM.

Service lifecycle governance

For service lifecycle governance, IBM WebSphere Service Registry and Repository can be used with either IIB or IBM BPM. In everyday practice, this might involve the selection of a particular service endpoint, from among many possible endpoints, for BOM conversion, based on business-specific criteria. In such a situation, a WebSphere Service Registry and Repository -based lookup can be used to select the most suitable endpoint.

Solution-level persistence

For solutions that require an intermediate persistence store, IBM DB2 10.7 provides all of the required capabilities, such as splitting a large payload into smaller chunks and then processing the smaller units individually. The solution creates its own, internal data to help manage these intermediate processes, and using a solution-level database to store this information is considered a leading practice.

Build-time tools

Build-time tools, also known as design-time tools, depend on the runtime components that are being used. IIB includes the IBM Integration Toolkit for build-time tools. If IBM BPM is used, then IBM WebSphere Integration Developer is needed for build-time tools. For rules development, ODM provides Eclipse-based tools for events and rules design.


Usage scenarios

The high-level usage scenarios that are supported by this solution are part of an ECO-controlled, BOM verification-enabled release process. This section describes a selection of the key scenarios.

Processing engineering change orders and other events

When a change to a product must be made, a design engineer typically releases an ECO. The engineer can release the ECO by using the user interface in the PDM system, or, alternatively, the PDM system can be set up to automatically release the ECO after all the appropriate approvals are recorded. The ECO usually contains some status text or a release description, a time stamp, and an identifier that uniquely identifies the ECO document. The released ECO also typically contains a list of the parts and assemblies that are being modified along with applicability criteria, such as the date the changes are to take effect. Effectivity can be specified either at the ECO level, in which case it applies to all of the affected components, or at the level of the individual parts and assemblies. The ECO can either be exported as a file to the file system or as a message to a JMS destination.

Transforming Bills of Material

At some point, Bills of Material (BOM) must be transformed from an engineering perspective to a manufacturing one. This transformation involves enriching the engineering data with additional manufacturing-related attributes, such as plant code, classification, sourcing, and supplier. As part of this enrichment, some of the data can also be transformed to suit the requirements of specific ERP systems. The data can be converted both in structure and semantics based on customer-specific business rules.

ECO-controlled BOM processing and updating

Payloads containing ECOs, parts, assemblies, and other data often must be processed to create corresponding records in the target ERP system. This processing can involve a complex series of adds, cuts, and mods. Adds are new parts or subassemblies that are added to the parent assembly. Cuts refer to the deletion of parts or subassemblies, and mods are modifications to one or more components. This ECO-controlled BOM updating scenario is shown in Figure 3.

ECO-controlled BOM processing
Figure 3. ECO-controlled BOM processing

BOM verification

It is sometimes necessary to compare a BOM record in the ERP system with its source record in the PDM system, such as when the solution run time is not appropriately notified that an ECO was released. Several factors can cause this situation to occur, ranging from simple human error, such as the failure of a user to properly exit the PDM system, to unexpected data corruption, which can cause premature failures and the momentary unavailability of the endpoint to which the release notification was to be sent. When this situation happens, one or more releases might be skipped because of a lack of notification, resulting in a possible data integrity issue at the ERP level.

To avoid this problem, a preferred practice is to verify the BOM at each individual transaction. Whenever an assembly that is affected by an ECO is processed, the solution can check the ERP system to compare the last known good revision of the assembly there with what is recorded in the PDM system. If problems are found, then the solution can initiate a series of service invocations into the PDM system to get all of the released revisions of the assembly and process all of them into ERP records before creating the latest assembly. In this way, the PDM system and ERP system can be synchronized.

Creation, modification, and deletion of ERP records

To accomplish its work, the solution must create, update, or delete various objects in the ERP system. The exact set of objects is system-dependent, but some are more common than others:
  • Material Master
  • Documents (and their association with Material Masters)
  • ECOs
  • Bills of Material
  • Bills of Material Components

If the ERP system is SAP, these objects are created by using various BAPI invocations. With other ERP systems, the process could involve the appropriate method or service invocations, or modification of the underlying database that supports the ERP system.


Integration

Figure 4 shows the context of the Manufacturing Release Management solution and the interaction between the involved systems and user roles. Broadly stated, the solution takes the data from one or more PDM systems and creates equivalent records in one or more ERP systems after the appropriate transformations occur.

Interaction of systems and users in IBM Manufacturing Release Management solution
Figure 4. Interaction of systems and users in IBM Manufacturing Release Management solution


Supported platforms

Manufacturing Release Management is supported on any hardware that supports the various base products that make up the solution. For the URLs to the appropriate IBM product pages that provide up-to-date lists of the supported hardware, see "Ordering information".


Ordering information

Table 1 shows the Manufacturing Release Management ordering information, which is based on industry segment.

Table 1. Ordering information - Manufacturing Release Management solution
ProductURL (for additional details, part numbers, and so on)
Aerospace and defensehttp://www-935.ibm.com/industries/aerospacedefense/
Automotivehttp://www-935.ibm.com/industries/automotive/
Electronicshttp://www-935.ibm.com/industries/electronics/
Consumer productshttp://www-935.ibm.com/industries/consumerproducts/
Additional industrieshttp://www-935.ibm.com/industries/


Related information

For more information, see these documents and websites:

Others who read this publication also read



Special Notices

This material has not been submitted to any formal IBM test and is published AS IS. It has not been the subject of rigorous review. IBM assumes no responsibility for its accuracy or completeness. The use of this information or the implementation of any of these techniques is a client responsibility and depends upon the client's ability to evaluate and integrate them into the client's operational environment.

Follow IBM Redbooks

Follow IBM Redbooks