Intimating PLM and ERP Systems

Author: Brion Carroll, CEO / Principal Consultant of Digital Solution Group, LLC

Digital Solution Group is the expert in intimating (intelligently integrating) a company’s Product Lifecycle Management (PLM) system with its downstream Enterprise Resource Planning (ERP) system. This is a critical transition/transformation of the release of Product/SKU information that has been approved for release to both internal and external (such as ERP, logistics, or customer (Retail)) systems.

ERP systems often have different data format requirements such as the length of a alphanumeric (or text) field, or how it defines a picklist (dropdown) value, requiring the intimation of it with PLM to require some level of data mapping or transformation.

• Text fields in the PLM system may exceed the length of what the ERP is configured to support – such as the Product Name or Description field. For that reason, the intimation facility must provide the appropriate truncation of the text field before posting it to the ERP system. Or enable a fuzzy transformation to keep the field readable in ERP.
• Picklist value mapping is another example of how an intimation facility will streamline the effort by automatically transforming the data set from PLM to meet the specific requirements of a ERP system. For example, the PLM system may contain a gender attribute that includes the values of Mens, Womens, Unisex, and Kids – where the ERP system requires it be a numeric/text field of 01, 02, 03, or 04. This would require that the intimation facility transform the PLM value as defined in (what should be) a data driven mapping configuration. Use an intelligent context memory to manage bulk transformations.
• Date field transformation is one where the PLM system has an actual data type of Date and the ERP system expects the date field to be formatted as a Text value. For that reason the intimation facility must transform the date field coming from PLM (i.e. 12/1/2024) as a text field of equal presentation.

Failed transactions require proper processing. For example:

• If the secure API login fails, then a notification is required to be sent to a 24x7 role that can immediately resolve the issue. Stacking of transactions must be performed on the PLM side so the sequence of transactions is maintained once the login issue is resolved.
• If there is an issue in a specific transaction (using the API access method), then subsequent transactions must be interrogated to determine if they will also fail. For example (as exampled above) if a Product’s create transaction fails, then any subsequent SKU create transactions of that Product should not be attempted. This would result in a notification to a role in the PLM system to resolve the issue. If the issue is data related (not gender value or a missing date field), then the reprocessing of the Product can only be performed (along with its associated SKUs) when this issue is resolved.
• Failures become much more complicated to process when a store-n-forward method is used since the PLM system is not directly notified (as per the API approach) and errors will require the posting of any failures to the transaction log that the PLM system will have to interrogate and send the appropriate notifications to the roles that would be required to resolve the issues. It is expected that any successful vs failed transactions will be posted to a transaction log, but failures require much more interrogation and proper processing as in the example of a Product create that fails would not be able to stop the SKU create transactions from being attempted by the ERP import facility – resulting in all Product and SKU transaction failures to be posted to the transaction log.

BOM transactions have a host of intimation scenarios that must be accounted for:

• Any BOM posted to ERP (using either the direct API or store-n-forward method) requires that proper “building” of the BOM be performed.
• A Subassembly (or Top-level assembly) cannot reference a Part unless the Part has already been created in the ERP system.
• In like manner a Top-level assembly cannot reference a Part or Subassembly unless they have been previously created in the ERP system.
• Bottom-up formation of a BOM in the ERP is required, suggesting that each Part should be “posted” to the ERP system upon its official release from PLM. Success (or failure) will require notification back to the appropriate role in PLM so that further action (or corrective action) can be performed.
• Any Subassembly can only be posted to ERP if (and only if) all its Parts (or Subassemblies) have been successfully created in ERP. This must be determined through data interrogation by the intimation facility. It may also be supported by a PLM function that does not allow a Subassembly to be officially released until (and only until) all its constituent Parts and/or Subassemblies have been released.
• If changes (updated version of a given Part, Subassembly, or the Top-level assembly) are made in PLM, then the appropriate updates must be transferred to ERP, considering all of the cautions noted above – especially the addition of a new Part or Subassembly to the previous posted BOM.

The last topic this writing will cover is the requirement that the PLM and ERP intimation facility support bi-directional data transactions. One example of this is where the Final Cost data is required to be passed back to the PLM system. The PLM system may have a First Cost attribute, but the role of Product Marketing/Management/Merchandising may require the Final Cost value to determine if the Product Margin % meets its target value or if the product/SKUs need to be dropped in replacement for one that is more suitable.

For this reason, the ERP system will eventually pass the Final Cost to the PLM system, whereby each of the above intimation issues of how to transact, what to do regarding success or failure, and what needs to be done per notification of specific roles is required for this bi-directional intimation to be performed successfully.

Details of how this is achieved is beyond the purpose of this writing, but can be discussed further by contacting Digital Solution Group at +1-603-566-5382 or sending an email to brion@digitalsolutiongroup.net