The PLMInsider PLM blog

Many companies that operate a collaborative PDM (cPDM) application, exchange BOMs with ERP. Many utilize an interface to achieve this. Still many face challenges regarding the correctness of these bills and also having to do additional work for the bill to do what it needs to do. In this article I’d like to touch on some of the business principles behind the coexistence of both the PLM and ERP worlds and also introduce some thoughts toward greater effectiveness.

Engineering bills are different from Planning or Manufacturing bills. In my post on “The Product Definition Challenge”, I asserted the interdependencies of various BOM’s and also the common types you find in an enterprise. I also wrote about “product decomposition” and “bom-lets”, i.e. the assemblies that are aggregated in ’super structures’. Super structures are different product representations and provide product context for the various integrated product teams (see my post on this topic in Collaboration). Super structures ’should’ be the ’system engineering’ oriented view of the product.

Having worked with several companies I came across different patterns preparing the cPDM implementation for it to exchange bills with ERP. It is not the technological trick… rather understanding the business rational. Key in ‘understanding’ what it is that is exchanged we first need to review the commercial ‘product positioning strategies’ that companies operate and the ‘product definitions’ in support of these models.

The illustration below is an overview of these models.

1.    An Engineer(ed)-to-Order (ETO) product, in its core the product is a technical ‘template’. The product has proven itself in some form and such there is demand for this product. In the ‘old’ days there would be a set of master blue prints of the product concept. Let’s take a nuclear submarine or power plant example. The product concept exists, ‘template’ designs are available. Safety certification takes place while in production, at final assembly and at delivery. The configured end-product requires substantial engineering effort. Much effort goes into interfaces between systems, models, assemblies and components. Re-use of ‘components’ is of major benefit given that historical analysis says that only 20% of the components of a product are really new. Engineering one or a small series makes a substantial difference as the ‘template’ may server different customer orders. Design in WIP and its ‘improvements’ ripple through all the products that are in production WIP and this is a major configuration challenge.

Clients enter into a contract with an ‘OEM’. Public and large (semi) private institutions are typical customers. The processes are ‘contract’ and usually project driven. The focus is on full lifecycle support, product conformance, production efficiency and WIP management.

2.    In a Make-to-Order (MTO) (also Build-to-Order) situation, the ‘design’ of the product and production processes is ‘ready’ (and maintained) for ’serial’ production. Typically the product may have obtained some form of ‘type’ approval regarding safety. As a business policy a company may define a base (stable) product with several categories of stable, reusable and maintained modular options. Yet some level of engineering may be needed and to accommodate for specific client requirements some portion of the product can be Engineered-to-Order.

Improvements are ‘blocked’ and changes are ‘batched’ and ripple through in a very controlled manner. Some category of changes are scheduled for new orders while other must be incorporated in production WIP and products in the field. Improvements may include categories of technical and cost optimizations. Interchangeability is model and configuration specific. Aircraft are examples of this strategy model and product type.

Subject to the go-to-market concept the enterprise would have for example a 50-60% standard base product, 20-30% standard options, and maybe 10-20% custom options. This kind of division is the base for sales, engineering and material management efficiency. Most processes are contract and/or order driven. All possible configurations are technically fully certified at product launch, including production and supply chain processes. There is a degree of similarity with ETO and ATO. The focus is on full lifecycle support, product reliability and production efficiency.

3.    An Assembled-to-Order (ATO) product is in fact a variant of MTO with the exception that as a principle no custom engineering effort is required, the product is ‘ready’ to produce to client order. Some modules are forecast and may already be in stock, while others may be ordered ‘just-in-time’. Improvements are ‘batched’ and may be introduced in the next product model. Improvements are typically market driven and may include categories of technical and cost optimizations while assuring full interchangeability. Autos, rolling stock or computers may be in this category. All possible configurations are technically fully ‘proofed’ before product launch, including the production and supply chain processes. The focus is aftermarket support, consistent quality, reliability and production efficiency.

4.    The last product positioning strategy is Pick-to-Order (PTO). Here a completely assembled end product of a limited number of configurations is ordered. PTO is a variant to ATO in as much that the final configuration is forecast as a Make-to-Stock. Change and Improvement management follows a similar process to ATO. Interchangeability may be less of a topic as, like-for-like (commodities) will be replaced in the field and in some cases the product may not be serviced rather disposed of completely at the end of its useful life. Consumer products (and also computers) are examples of PTO. The engineering process is (cost) improvement and (flow line) production processes are market demand driven. All end products are technically fully ‘proofed’ before product launch, including the production and supply chain processes. The focus is on consistent quality and production efficiency.

Note: Literature may call different names for these product positioning strategies.

Considering these four scenarios you appreciate that the resulting forms of ERP coexistence differ.

So let’s put the above in the context of PLM and ERP. In ERP there are two types of bills, the ‘generic/master’ planning and the ‘derived’ order specific. In PLM you basically have the same, the ‘generic product structure’ (GPS), an approach that comprises modules and incorporates all targeted design variants, and a derived ‘end item’ specific configuration. It may not be a product ‘platform’ or ‘family’ definition as a transition to a ‘variant’ master structure may be required. Product Engineering assures that different combinations of module options technically fit together as defined by ‘rules’. The same goes for the manufacturing engineers, this discipline assures that the ‘master’ planning follows this modular approach and from the master planning a specific order bill can be configured.  The following illustration explains some of the principles. I listened to many expert opinions and this is basically what can be considered the common denominator.

In this illustration I also included the end ‘ state’ of the product i.e. the As-Built and the As-Delivered as well as the As-Serviced/As-Maintained. The observant reader will realize that this As-Serviced definition is not based on the produced product as this does not define item positions and their maintainability aspects, critical in ETO and MTO. Also appreciate where product configurators may be utilized. You appreciate that engineers working on a ‘total’ product structure (all variations) cannot do without such ‘configurator’ function. How would you suppress undesirable components from being loaded into the 3D-model or mock-up when you are just interested in a specific configuration you are working on. This is probably worth another post… (see also my post on Digital Mock-up).

Notionally the ERP ‘master’ production planning bill is the super structure of the production build sequence. From this master build sequence, order specific final assembly bills can be defined. The build sequence will have a related bill of routing (BOR). Although this name is not consistent throughout the industry, e.g according to APICS it is bill of operations (BOO). There will further be a component manufacture, (sub)assembly and a final assembly BOR’s. Different from the Engineering/Manufacturing super structure, the BOR definition is the decomposition of the production build sequence with detailed operations and manufacturing steps.

The above illustration is notional, I do not pretend it to be complete.

‘Operations and steps’ define work instructions and ‘resources’ needed at each step. At these steps assembly/sub-assembly bom-lets are ‘consumed’ from the bottom up during the (final) assembly process of the end product. The BOR ‘consumes’  the Engineering defined (sub) Assemblies. I referred to these in other posts as ‘bom-lets’. Considering these constructs, the BOR is not a BOM… rather a ‘process’ structure and has a association with the Manufacturing BOM. There have been several publications concerned with ‘fusion’ of MBOM and BOR (BOMO). Purposely I have been vague how these are fused as there would be several solutions. I would like to assert that when done right you would not need an MBOM as the BOR describes the MBOM build sequence. Unfortunately, today’s PLM and ERP technology still requires both a MBOM and BOR, and are maintained separated. A joint definition would bring significant benefits. For example the BOR constructs can be defined within the MBOM and a BOR filter would suppress these constructs for those who would not need to work with them. This approach would then also support routing variability and overall, it would make maintenance, synchronisation and reconciliation with the EBOM more auditable, secure and easy.

Defining the BOR involves several Production Engineering specialists: Those responsible for the:

• The build sequence work breakdown structure
• The ‘line’ equipment and other resources
• Required tooling, but also the numerical control programs and information for machining centers and robots
• The production method consuming assembly, sub-assembly, component and (raw)material level
• The Assembly work instructions
• The Component production work instructions
• Standards and Norms (documents) that control quality at the process and its steps
• The quality assurance in all its aspects, including discrepancy and corrective action register(s).

The BOR can be defined in either the PLM or ERP domain. The trend is for PLM, the reason being that engineers today need to have access to a lot of critical design information. The authoring capability in PLM is usually referred to as a digital manufacturing solution (computer aided process planning (CAPP)). The strength of CAPP is that it essentially keeps all of the above elements ‘together’ as a single source of manufacturing information in the context of the (configured) product including the Production and Manufacturing Information (PMI) source that may be stored in for example JT. This lightweight 3D experience is dependent on the 3D-model and the trend is that it obsoletes 2D drawings. PMI typically stores dimensions, dimensional tolerances, position tolerances and surface finish. This is also a strong case in favor of CAPP in PLM.

Returning to our main topic: ERP, among other things, depends on a master bill from which order bills are derived to determine ‘material’ requirements. I came across some ETO and MTO product positioning model companies that prepare and simulate this ‘master’ WBS (Planning bill) in Microsoft Project prior to entering in ERP.

In ETO this Planning Bill and BOR typically is a one-off effort as each ‘end product’ order may be unique. If there is some form of a series, the end product can be considered a master definition and some companies use classical unit number effectivity to define an As-Built. The Planning bill follows the Systems Engineering decompositions defined by Product Engineering. Early alignment between these two disciplines reduces later synchronization effort.

MTO is a variant of ETO and ATO, with the key difference that a client configuration assembly bill for a specific order is configured by engineers. All of the configurable modules are pre-loaded in ERP from which an order specific final assembly bill can be configured with their corresponding ’standard’ routings.

The Manufacturing bill including the super structures and modules I talked about earlier are converted to suit manufacturing, and populated with the required bom-lets i.e. assemblies, sub-assemblies, components, (raw) materials. As you interface with ERP all of these bom-lets revisions are brought across and kept synced against the ‘master’ definition. Once brought across you then need to set revision (date) effectivities. That is the crux of interfacing PLM with ERP. Product Engineers negotiate with Manufacturing and Production Planning Engineers what bom-lets are transferred. If products are in production WIP you then need to determine in the Change Introduction Board (CIB) how these ‘mods’ are introduced into the order specific MBOM/BORs derived from the engineering master definition. This CIB together with a Change Review Board (CRB) are organizational entities in classic closed loop Change Management. The dispositioning of these mods is also the reason that it is absolutely critical for the PLM application to also exchange Change Notices to ERP and not just the changed BOMs themselves as I came across frequently while also leaving a paper change trail. Ignoring this (whatever the reason) makes reconciliation and the verification and validation very difficult, see earlier post in which I talk about the V-model.

A brief note again on As-Maintained BOM… (see illustration regarding the source). In Aerospace the manufacturing method and the work instructions are key sources regarding maintenance, repair and overhaul (MRO). This effectively applies to all ETO and MTO cases (Engineer-to-Maintain/Sustain) in which product sustainment and life cycle support scenarios are an important topic (see earlier posts on Enterprise Asset Management). Example; aircraft cannot be certified without this principle while it assures safe operation and reliability backed by periodical maintenance requirements and principles. All of the production methods and experience are key input to maintenance work cards. Considering that today, the assembly process can be digitally simulated, the same benefit goes for maintenance which is in effect the reverse order. The Build Sequence becomes the Disassembly order and this is also the background why there is Service BOM (see posts on Product Definitions).

In summary, Engineering owned System Engineering oriented super structures are the base for manufacturing bill and the bill of routing. This super structure is pushed from PLM into ERP. The MBOM/BOR is concerned how these super structures are assembled into end products. The MBOM/BOR is a ’standard’ or order specific routing depending on the product positioning model. The BOR consumes (sub)-assemblies as defined by product engineering against the super structures. Updates of (sub)-assemblies, components and (raw) materials are pushed into ERP subject to status. The CRB and CIB process determine what changes are introduced in the product and production WIP. Effectivity (date) is a critical function to schedule changes in and out.

PLM would be concerned with knowledge processes for design and manufacturing engineering, ERP would be concerned with production execution driving final assembly. Work instructions support the production process and are also the foundation for  MRO.

Considering the volume of information that is stored against the MBOM/BOR and also the critical collaboration required between ‘product’ engineering and ‘production process’ engineering, that in itself is a sound case to support these processes in PLM. A large ERP vendor also appreciates this as it recently acquired Visiprise well know for it digital manufacturing and execution suite.

Tags: ATO, BOR, CAPP, CRB, ERP, ETO, MBOM, MTO, PTO

This entry was posted on Thursday, November 12th, 2009 at 22:53 and is filed under Business Activity Managememt, Product Definition. You can follow any responses to this entry through the RSS 2.0 feed. You can leave a response, or trackback from your own site.