Part 2: How to structure the various types of models and datasets?
It is no secret that product complexity keeps increasing and with that the number of dependencies increases as well. Not only product complexity also supply chain complexity increases. So how can you ensure that all information for a product/platform is captured and structured in such a way that it facilitates the change process efficiently and effectively?
It all starts with requirements, to ensure a proper and efficient flow down of requirements a product breakdown is needed that supports the different needs for different parts of the organization. E.g. mechanical engineer vs manufacturing engineer.
Typically engineering views the product more from a system/function perspective whereas manufacturing looks to the product more from the perspective how it can be build.
To manage the increasing amount of dependencies, more and more product information is documented as a model. Models consist out of one or multiple datasets as described in Part 1 of a glimpse into the future of CM and in a Glimpse into the Future of CM – Keynote ConX18. The information needs to be modelled and datasets identified to support configuration management.
The configuration of a product/platform can be depicted as a cube with a pyramid on top as shown in above figure. The pyramid represents the application requirements of the product/platform. The application requirements flow down the sides of the cube. How they flow down is organized, facilitated by the grey layer (the core platform network) which also captures the design basis (per CM2) of the End-Item. In this example we have two basis views defined for the breakdown; the engineering basis view which follows the system/function breakdown and the manufacturing basis view which is structured to how it is build. Naturally other basis views might be needed e.g. service basis view for maintenance or install basis view to support shipment and installation of a product in the field. This Core Platform Network captures not only the flow down of requirements but also all kinds of dependencies like (non-)functional or commercial dependencies. This will support defining and filtering the allowed configuration(s).
Underneath the engineering basis view, the engineering bill of material (EBOM) resides (green part of the cube) and underneath the manufacturing basis view the manufacturing bill of material (MBOM) resides (orange part of the cube). The next figure shows a more detailed example.
Note that the system breakdown layer or manufacturing node layer can exist out of multiple levels. E.g. respectively functions / sub functions or supply chain capabilities / facility layouts.
In the MBOM, assemblies 123 and 345 are combined in a manufacturing kit M123. Items ABC, EFK and 901 are buy items. In the end the MBOM must have the same components (leaf nodes/items) as the EBOM, only the structure is different. This rule is also known as the material content rule.
Each item/node in the structure has a number of datasets. Not all datasets are relevant for all basis views. E.g. in the design basis the functional specifications are listed, while in the service basis this might be less relevant and the service process plan and maintenance instructions might be more relevant.
From a CM2 methodology perspective this means that there is a Core Platform Network dataset that links to the various types of bills of materials as shown in below figure. Which forms the basis for the As Planned/As Released baseline*. This allows different roles, like mechanical engineer and manufacturing engineer, to choose which view they want to apply to the As Planned/As Released baseline in order to perform their impact analysis for changes and ensure the material content rule is satisfied.
*The As Planned/As Released baseline per CM2, not only shows the configuration as is currently released and effective but also shows which changes will be applied and become released and effective in the future.
The next article will focus on the types of models from a configuration management perspective.
If you are interested you can also read:
This article was originally posted on LinkedIn.
 a Glimpse into the Future of CM – Keynote ConX18 – IPX Congress Industry 4.0 Committee
 a Glimpse into the Future of CM – Part 1: How do model-based approaches impact Configuration Management? – IPX Congress Industry 4.0 Committee, 2019
 Industry 4.0 Impact to IPE-CM Rev C – IPX Congress Industry 4.0 Committee, 2017 (only accessible if you have a CM2-Comprehensive certification or higher)
 The True Impact of Industry 4.0 revealed, 2018 – Martijn Dullaart
The author is chair of the Industry 4.0 committee of the IPX Congress formed by cross industry leaders from AGCO – Gary DSouza, Airbus – Stephen Watts (Retired), ASML – Martijn Dullaart, Cummins – Greg Russ, FNSS – Mehmet Tunc, Gulfstream – Max Gravel, IpX – Todd Egan & Joe Anderson, and Northrop Grumman – Paul Nelson. Together they are working on a solution to help answer the following questions:
Do you also wonder why Configuration Management never gets mentioned in conjunction with Industry 4.0 or (Industrial) Internet of Things? Would you like to know the impact of Industry 4.0 on CM? What are the risks and opportunities? What will it mean to your CM processes? What requirements should IT tool vendors be made aware of and subsequently support? And what will be the impact to your organization and the people in it? How can you mitigate the risks and how can you prepare your organization to be ready for change?