Managing complexity is something almost everyone dealing with PLM is talking about and there is a good reason for it. Managing complexity is one of the great challenges in product development and product manufacturing. Not only products become more and more complex, the processes to handle them are becoming more complex as well.
Now, maybe processes haven’t become more complex lately, they may have been that way for a while already. Why, then, is ‘managing complexity’ gaining so much attention now ?
PLM backbone to support end-to-end product creation processes
Without an integrated product creation landscape in place that provides pervasive access to information by managing data from a range of diverse systems (aka ‘PLM’), processes have been essentially unmanaged or managed only partially. Processes rely on verbal communication and individual experience/knowledge to function, and that way complexity can be dealt with ad hoc – but the results can vary from excellent to very poor, depending on the effectiveness of the communication and the ability of the people involved to make the right decisions.
When end-to-end support of product creation processes is introduced via a PLM backbone, all the little things that were dealt with on an ad hoc basis in the past now need to be formalized. These “special situations” aren’t usually documented anywhere, and a lot of time and energy needs to be spent on digging up what they are, how they affect results, and who is doing what if such a situation arises. If an analysis finds that there are exceptions, a decision must be made if those should be allowed in the future. If so, it must be determined how such situations can be handled within the formalized system of rules, as they are being defined in the PLM system.
So, to be able to take advantage of integrated information from a PLM backbone, a thorough analysis of the as-is and to-be state needs to happen, and tough decisions must be made. A PLM backbone will ensure that processes are handled in a controlled manner, eliminating errors and making sure that everybody has access to the information they need. This will however work only if the data model and business processes are defined properly, a PLM system cannot provide these benefits out of the box.
Workflows don’t stop at system boundaries: Integrating PLM and ERP
Extending the integrated information landscape to also include ERP, by integrating PLM with ERP, means that business processes and mindsets must be taken into account that may be quite different from what is available or planned on just the PLM side. This obviously adds to the complexity, and that is at least one of the primary reasons why PLM-ERP integration is usually regarded as being “difficult”. Just like the introduction of a PLM system, integrating that system with ERP requires a lot of thought. One of the considerations to be kept in mind is the extent to which the ERP side requirements may have an influence on how data models or business processes need to be designed on the PLM side. The impact can be minimal, or it can be extensive – either way it needs to be looked at closely.
So that brings us to the conclusion that introducing PLM, and even more introducing a PLM system integrated with ERP, exposes complexity and the need to manage it. Fortunately, these systems also provide the tools to handle complexity, of products as well as processes, properly. It just takes a well planned and designed implementation of both PLM and PLM-ERP to achieve the benefits.
There is a choice to be made: Tackle the challenge of managing complexity head on, or continue to live in blissful ignorance about the underlying complexity, hoping that nothing bad will happen…
Managing BOM complexity between PLM and ERP: The engineering to order process (use case)
The following is an example of a well-designed business process to manage such a complex scenario. It has been designed and implemented using the PLM-ERP standard integration Teamcenter Gateway for SAP (T4S).
Companies providing configurable standard products and solutions, also allowing customer specific changes, are most likely facing the situation that the engineering BOM (eBOM) has to be modified due to some customer requests during the order process. Sales configurators, allowing to configure customer specific standard products, are often part of or integrated to an ERP solution. Typically, the outcome of a customer configuration process results in an order BOM.
To have the possibility to add new engineering parts to the order BOM, it has to be transferred back to the PLM system. In the best case, the PLM-ERP integration already creates new items for the new engineering parts, while transferring the 100% order BOM to the PLM system. To be able to configure a 100% order BOM in the ERP system, the generic 150% product eBOM has be transferred from PLM to ERP system including all options and variants defined in the PLM system.
Besides transferring the customer orders as bill of materials, another possible solution is to exchange the customer specific configuration as variant condition information between the ERP and the PLM system and vice versa. The PLM-ERP integration solution synchronizes the options and values between the two systems. The customer product configuration of the sales configurator results in a stored option set in the ERP system; this is transferred to the PLM system as a variant rule. This customer specific variant rule is applied to the generic 150% BOM and results in a 100% customer order BOM which is then transferred back to the ERP system. The advantage of transferring variant rules back to the PLM system instead of 100% BOMs is that the same rule can be applied to the 150% BOP (bill of process). The configured 100% BOP is then also transferred back to the ERP system as a customer specific routing.
Workflows still don’t stop at system boundaries: Extending the PLM-ERP landscape by MES
To close the loop, customers are thinking about bringing the information from the MES system back to the MRO module of the PLM system as an “as built” structure. This loop can be closed using the Teamcenter Gateway Plus extensions (available for Teamcenter Gateway for SAP (T4S) and Teamcenter Gateway for Oracle EBS (T4O). These extensions enhance the Teamcenter Gateway solutions to a PLM integration platform, providing generic adapters to integrate other enterprise application. Visit us at Siemens PLM Connection Americas booth #18 for detailed information on T4S+ and T4O+.
This contribution is an adapted version of two posts by Mathias Mond (Managing Director TESIS PLMware) and Dirk Kremer (Product Manager Teamcenter Gateway Solutions), taken from www.plmerp.com - the new blog on PLM-ERP integration by TESIS PLMware.
Learn more about PLM-ERP Integration
Subscribe to the www.plmerp.com RSS feed and stay tuned with more information and insights.
Visit us at Siemens PLM Connection Americas booth #18 for detailed information on T4S+ and T4O+, as well as for the highlights of the upcoming releases T4S / T4O 9.1 including:
- SAP Project System-Teamcenter Scheduler integration (execution planning)
- SAP iPPE integration(variant management)
- Oracle EBS routing support
- Oracle EBS GUI display
- and many more