Planning of changes in a Model Based Enterprise.
Let me first say that I do see the benefits of the Model Based Enterprise (MBE) and that modeling information is also very valuable from a CM perspective. Think of improved impact analysis capabilities to support the expert domain specific and cross expert domain impact analysis as shown in the picture below. (See also the following posts: We need a cross-platform interface for impact analysis! and CM2: the cross-platform standard for Impact Analysis for more details on the Pyramid of Impact Analysis)
However all these details need to be aggregated to a level that can be used to make business cases for decision making and make it usable for planning of deliverables.
Where does the deliverable begin and where does it end?
Let’s take an extreme scenario where all your product documentation is modelled. How can you identify easily who owns what information in a way that you can plan changes to that information?
In other words if you want to implement a change to your product, you need to do an impact analysis and use the results of the impact analysis to plan deliverables with owners and delivery dates. But how can you plan all those independent relations, objects, attributes that need to be changed. Where does the deliverable begin and where does it end?
In the ‘good old’ days
How did we do this in the ‘good old’ days? When information used to be collected in a document, it was easy to identify who is the creator, and who are its users. A document had an intended purpose and context, hence ownership is easily defined and a document can be planned easily as it is a clearly identifiable container of work. Based on the kind of change, the type of document and type of part, it was relatively easy to estimate effort for creation and updates.
Flash forward
Now flash forward again to the completely modelled enterprise. I do not want to plan each and every object, relationship or attribute, formula, characteristic, etc, as a separate task for my implementation plan. So how do I now identify the dataset, the set of information that I can plan as a task for which it is clear who the creator and its users are? See also A Glimpse into the Future of CM for more information on what a dataset is.
For a Bill of Material (BoM) or Bill of Process, it is quite clear where the boundaries are. But for instance the 3D Model is now also containing Product Manufacturing Information and what if you also add behavioral characteristics and formulas. Most likely the various types of information will have different creators and different users. Not necessarily all changes to a 3D Model will impact the other types of modelled information and vice versa.
Decoupling and context
So how do I now organize the information so that planning and execution of changes is facilitated in the most efficient way? If you cannot edit the information because someone else checked out the 3D Model, and you have to wait, it is far from efficient. Although modelling brings great advantages, it also needs to contain a level of decoupling and context to manage the creators of the information and be able to plan and efficiently execute changes.
If your data model does not take this into account you could create a situation that is far from optimal. To highlight the example: If you have multiple types of BoMs (e.g. an Engineering, Manufacturing, Planning, Service, etc) and you model it as one BoM with tags and you use revisions to control changes to the BoM, it will go wrong at some point. Typically different people own the various types of BoMs. Now updating one type of BoM require a new revision and in most systems that blocks you from executing other changes on the BoM. Or you allow multiple in work revisions, but that means you have to merge these changes at some point, risking merge issues or releasing information in the wrong order. Or you need to setup a BoM management team that does all BoM updates for all the owners of the various types of BoMs. In any case it is not going to be efficient. Decoupling the various types of BoMs to have their own revision would be a great step to improve on this situation. This might be an obvious example, but more cases will come up when going model based.
Conclusion
It is important to be able to identify datasets by clearly defining the boundaries of a dataset, so that ownership can be clearly defined in order to allow for planning of changes and efficient execution of the work. Therefor we should not only focus on the the implementation of MBx as the next new ‘shiny gadget’ but also focus on the usability and maintainability. on the long term. It is relatively easy to initially create a model, maintaining a model is harder.
Photo by Sydney Herron on Unsplash
You are so right! I just had this conversation today with other colleagues about the difference of CM today vs tomorrow and how models can be in their own environment until it is released and you should know who the owner is and who the user is to gain traction and be able to assess change impacts! I agree that CM should not be trying to control every object, relationship or attribute, formula, or characteristic. We set the foundation in which to provide consistent, relevant and accurate information.
Hi Crystal. Thanks for your comment. CM works on an aggregated level and in the current world of MBx, it seems that the link to this aggregated level is not taken into account. And for CM to keep providing consistent, relevant and accurate information, we need to have this link re-established and guarded.
Hello Martjin,
Based on my 3D MBD, For product definition: The BOM is defined in the Model and is no longer an independent dataset.
The BOM became a Report from the Model as a PDF. In order to change the BOM, you must revise a Model.
The Models are can also be broken down in terms of features that can be exposed and consumed by other Data Structure. For example, a hole feature from a CAD model can be exposed so planning can drill at next level assembly in the MBOM if they wish without requiring a new engineering PN (part without hole).
Features (dataset subset like a hole in part that can be exposed) and their relationships across the different models can tremendously help with the automation of the impact analysis to support the change impact.
Thanks Max,
I can understand that the EBOM can be derived from the model. But your ERP system still needs a BoM, a dataset, for planning and execution. I would even state that Part Numbers are things relevant for the ‘physical’ world and that the items in a model only have a reference to these part numbers but use other identifiers.
Also as a BoM is needed before other documentation is ready, how do you deal with a Model? A BoM is used for planning and therefore is the first dataset needed to be released for a change. If this is not possible the Model, the model is to engineering focused and does not take the entire value chain into account.
Hello Martijn,
The BOM you referred to is generated from the model as part of a “Resolved product Structure”. The parent in the structure released all the constituents part at one time. The parents are the Tops of the CAD tree and contains usage effectivity for consumption on the aircraft. The parent (like the BOM) must be released to support demands on the final assembly line.
Constituents parts can be released before the BOM to support the Supply chain (parts and Assembly build) along with an AMN to drive demand in the system.
There is visibility in the ERP systems of Parts that have been released out of context so Mfg can adjust their PO
Before the Top is released with the final effectivity.
Hopes this helps clarify
Hi Max,
But making parts available outside the context of the BoM does not update the planned orders. This requires a BOM update to supply the information to the MRP run so that planned orders are updated properly. Your solution requires a lot of manual updating of orders, which is not preferred. How can we make it so that a BoM can be generated without updating the entire model with positioning, geometry, etc? Which you require only when effectivity is reached.