You are currently browsing the tag archive for the ‘MBD’ tag.
Imagine you are a supplier working for several customers, such as big OEMs or smaller companies. In Dec 2020, I wrote about PLM and the Supply Chain because it was an underexposed topic in many companies. Suppliers need their own PLM and IP protection and work as efficiently as possible with their customers, often the OEMs.
Most PLM implementations always start by creating the ideal internal collaboration between functions in the enterprise. Historically starting with R&D and Engineering, next expanding to Manufacturing, Services and Marketing. Most of the time in this logical order.
In these implementations, people are not paying much attention to the total value chain, customers and suppliers. And that was one of the interesting findings at that time, supported by surveys from Gartner and McKinsey:
- Gartner: Companies reported improvements in the accuracy of product data and product development as the main benefit of their PLM implementation. They did not see so much of a reduced time to market or reduced product development costs. After analysis, Gartner believes the real issue is related to collaboration processes and supply chain practices. Here the lead times did not change, nor did the number of changes.
- McKinsey: In their article, The Case for Digital Reinvention, digital supply chains were mentioned as the area with the potential highest ROI; however, as the image shows below, it was the area with the lowest investment at that time.
In 2020 we were in the middle of broken supply chains and wishful thinking related to digital transformation, all due to COVID-19.
Meanwhile, the further digitization in PLM (systems of engagement) and the new topic, Sustainability of the supply chain, became visible.
Therefore it is time to make a status again, also driven by discussions in the past few weeks.
The old “connected” approach (loose-loose).
A preferred way for OEMs in the past was to have the Supplier or partner directly work in their PLM environment. The OEM could keep control of the product development process and the incremental maturity of the BOM, where the Supplier could connect their part data and designs to the OEM environment. T
The advantage for the OEM is clear – direct visibility of the supplier data when available. The benefit for the Supplier could also be immediate visibility of the broader context of the part they are responsible for.
However, the disadvantages for a supplier are more significant. Working in the OEM environment exposes all your IP and hinders knowledge capitalization from the Supplier. Not a big thing for perhaps a tier 3 supplier; however, the more advanced the products from the Supplier are, the higher the need to have its own PLM environment.
Therefore the old connected approach is a loose-loose relationship in particular for the Supplier and even for the OEM (having less knowledgeable suppliers)
The modern “connected” approach (wins t.b.d.)
In this situation, the target infrastructure is a digital infrastructure, where datasets are connected in real-time, providing the various stakeholders in engagement access to a filtered set of data relevant to their roles.
In my terminology, I refer to them as Systems of Engagement, as the target is that all stakeholders work in this environment.
The counterpart of Systems of Engagement is the Systems of Record, which provides a product baseline, manufacturing baseline, and configuration baseline of information consumed by other disciplines.
These baselines are often called Bills of Information, and the traditional PLM system has been designed as a System of Record. Major Bills of Information are the eBOM, the mBOM and sometimes people talk about the sBOM(service BOM).
Typical examples of Systems of Engagement I have seen in alphabetical order are:
- Arena Solutions has a long-term experience in BOM collaboration between engineering teams, suppliers and contract manufacturers.
- CATENA-X might be a strange player in this list, as CATENA-X is more a German Automotive consortium targeting digital collaboration between stakeholders, ensuring security and IP protection.
- Colab is a provider of cloud-based collaboration software allowing design teams and suppliers to work in real time together.
- OnShape – a cloud-based collaborative product design environment for dispersed engineering teams and partners.
- OpenBOM – a SaaS solution focusing on BOM collaboration connected to various CAD systems along with design teams and their connected suppliers
These are some of the Systems of Engagement I am aware of. They focus on specific value streams that can improve the targeted time to market and product introduction efficiency. In companies with no extensive additional PLM infrastructure, they can become crucial systems of engagement.
The main challenge for these systems of engagement is how they will connect to traditional Systems or Records – the classical PLM systems that we know in the market (Aras, Dassault, PTC, Siemens).
Image on the left from a presentation done by Eric Herzog from SAAB at last year’s CIMdata/PDT conference.
You can read more about this here.
When establishing a mix of Systems of Engagement and Systems of Record in your organization digitally connected, we will see overall benefits. My earlier thoughts, in general, are here: Time to split PLM?
The almost Connected approach
As I mentioned, in most companies, it is already challenging to manage their internal System of Record, which is needed for current operations and the traceability of information. In addition, most of the data stored in these systems is document-driven, not designed for real-time collaboration. So how would these companies collaborate with their suppliers?
The Model-Based Enterprise
In the bigger image below, I am referring to an image published by Jennifer Herron from her book Re-use Your CAD, where she describes the various stages of interaction between engineering, manufacturing and the extended enterprise.
Her mission is to promote and educate organizations in moving to a Model-Based Definition and, in the long term, to a Model-Base Enterprise.
The ultimate target of information exchange in this diagram is that the OEM and the Supplier are separate entities. However, they can exchange Digital Product Definition Packages and TDPs over the web (electronically). In this exchange, we have a mix of systems of engagement and systems of record on the OEM and Supplier sides.
Depending on the type of industry, in my ecosystem of companies, many suppliers are still at level 2, dreaming or pushed to become level 3, illustrating there is a difficult job to do – learning new practices. And why would you move to the next level?
Every step can have significant benefits, as reported by companies that did this.
So what’s stopping your company from moving ahead? People, Processes, Skills, Work Pressure? It is one of the most common excuses: “We are too busy, no time to improve”.
A supply chain collaboration hub
On March 21, I discussed with Magnus Färneland from Eurostep their cloud-based PLM collaboration hub, ShareAspace. You can read the interview here: PLM and Supply Chain Collaboration
I believe this concept can be compelling for a connected enterprise. The OEM and the Supplier share (or connect) only the data they want to share, preferably based on the PLCS data schema (ISO 10303-239).
In a primitive approach, this can be BOM structures with related files; however, it could become a real model-based connection hub in the advanced mode. “
Now you ask yourself why this solution is not booming.
In my opinion, there are several points to consider:
- Who designs, operates and maintains the collaboration hub?
It is likely not the suppliers, and when the OEM takes ownership, they might believe there is no need for the extra hub; just use the existing PLM infrastructure. - Could a third party find a niche market for this? Eurostep has already been working on this for many years, but adopting the concept seems higher in de BIM or Asset Management domains. Here the owner/operator sees the importance of a collaboration hub.
A final remark, we are still far from a connected enterprise; concepts like Catena-X and others need to become mature to serve as a foundation – there is a lot of technology out there -now we need the skilled people and tested practices to use the right technology and tune solutions concepts.
Sustainability demands a connected enterprise.
I focused on the Supplier dilemma this time because it is one of the crucial aspects of a circular economy and sustainable product development.
Only by using virtual models of the To-Be products/systems can we seriously optimize them. Virtual models and Digital Twins do not run on documents; they require accurate data from anywhere connected.
You can read more details in my post earlier this year: MBSE and Sustainability or look at the PLM and Sustainability recording on our PLM Global Green Alliance YouTube channel.
Conclusion
Due to various discussions I recently had in the field, it became clear that the topic of supplier integration in a best-connected manner is one of the most important topics to address in the near future. We cannot focus longer on our company as an isolated entity – value streams implemented in a connected manner become a must.
And now I am going to enjoy Liveworx in Boston, learning, discussing and understanding more about what PTC is doing and planning in the context of digital transformation and sustainability. More about that in my next post: The week(end) after Liveworx 2023 (to come)
This year started for me with a discussion related to federated PLM. A topic that I highlighted as one of the imminent trends of 2022. A topic relevant for PLM consultants and implementers. If you are working in a company struggling with PLM, this topic might be hard to introduce in your company.
Before going into the discussion’s topics and arguments, let’s first describe the historical context.
The traditional PLM frame.
Historically PLM has been framed first as a system for engineering to manage their product data. So you could call it PDM first. After that, PLM systems were introduced and used to provide access to product data, upstream and downstream. The most common usage was the relation with manufacturing, leading to EBOM and MBOM discussions.
The traditional ENOVIA PLM backbone
IT landscape simplification often led to an infrastructure of siloed solutions – PLM, ERP, CRM and later, MES. IT was driving the standardization of systems and defining interfaces between systems. System capabilities were leading, not the flow of information.
As many companies are still in this stage, I would call it PLM 1.0
PLM 1.0 systems serve mainly as a System of Record for the organization, where disciplines consolidate their data in a given context, the Bills of Information. The Bill of Information then is again the place to connect specification documents, i.e., CAD models, drawings and other documents, providing a Digital Thread.
Aras – Bills of Information creating the Digital Thread
The actual engineering work is done with specialized tools, MCAD/ECAD, CAE, Simulation, Planning tools and more. Therefore, each person could work in their discipline-specific environment and synchronize their data to the PLM system in a coordinated manner.
However, this interaction is not easy for some of the end-users. For example, the usability of CAD integrations with the PLM system is constantly debated.
Many of my implementation discussions with customers were in this context. For example, suppose your products are relatively simple, or your company is relatively small. In that case, the opinion is that the System or Record approach is overkill.
That’s why many small and medium enterprises do not see the value of a PLM backbone.
This could be true till recently. However, the threats to this approach are digitization and regulations.
Customers, partners, and regulators all expect more accurate and fast responses on specific issues, preferably instantly. In addition, sustainability regulations might push your company to implement a System of Record.
PLM as a business strategy
For the past fifteen years, we have discussed PLM more as a business strategy implemented with business systems and an infrastructure designed for sharing. Therefore, I choose these words carefully to avoid overhanging the expression: PLM as a business strategy.
The reason for this prudence is that, in reality, I have seen many PLM implementations fail due to the ambiguity of PLM as a system or strategy. Many enterprises have previously selected a preferred PLM Vendor solution as a starting point for their “PLM strategy”.
One of the most neglected best practices.
In reality, this means there was no strategy but a hope that with this impressive set of product demos, the company would find a way to support its business needs. Instead of people, process and then tools to implement the strategy, most of the time, it was starting with the tools trying to implement the processes and transform the people. That is not really the definition of business transformation.
In my opinion, this is happening because, at the management level, decisions are made based on financials.
Developing a PLM-related business strategy requires management understanding and involvement at all levels of the organization.
This is often not the case; the middle management has to solve the connection between the strategy and the execution. By design, however, the middle management will not restructure the organization. By design, they will collect the inputs van the end users.
And it is clear what end users want – no disruption in their comfortable way of working.
Halfway conclusion:
Rebranding PLM as a business strategy has not really changed the way companies work. PLM systems remain a System of Record mainly for governance and traceability.
To understand the situation in your company, look at who is responsible for PLM.
- If IT is responsible, then most likely, PLM is not considered a business strategy but more an infrastructure.
- If engineering is responsible for PLM, then you are still in the early days of PLM, the engineering tools to be consulted by others upstream or downstream.
Only when PLM accountability is at the upper management level, it might be a business strategy (assume the upper management understands the details)
Connected is the game changer
Connecting all stakeholders in an engagement has been a game changer in the world. With the introduction of platforms and the smartphone as a connected device, consumers could suddenly benefit from direct responses to desired service requests (Spotify, iTunes, Uber, Amazon, Airbnb, Booking, Netflix, …).
The business change: connecting real-time all stakeholders to deliver highly rapid results.
What would be the game changer in PLM was the question? The image below describes the 2014 Accenture description of digital PLM and its potential benefits.
Is connected PLM a utopia?
Marc Halpern from Gartner shared in 2015 the slide below that you might have seen many times before. Digital Transformation is really moving from a coordinated to a connected technology, it seems.
The image below gives an impression of an evolution.
I have been following this concept till I was triggered by a 2017 McKinsey publication: “our insights/toward an integrated technology operating model“.
This was the first notion for me that the future should be hybrid, a combination of traditional PLM (system of record) complemented with teams that work digitally connected; McKinsey called them pods that become product-centric (multidisciplinary team focusing on a product) instead of discipline-centric (marketing/engineering/manufacturing/service)
In 2019 I wrote the post: The PLM migration dilemma supporting the “shocking” conclusion “Don’t think about migration when moving to data-driven, connected ways of working. You need both environments.”
One of the main arguments behind this conclusion was that legacy product data and processes were not designed to ensure data accuracy and quality on such a level that it could become connected data. As a result, converting documents into reliable datasets would be a costly, impossible exercise with no real ROI.
The second argument was that the outside world, customers, regulatory bodies and other non-connected stakeholders still need documents as standardized deliverables.
The conclusion led to the image below.
Systems of Record (left) and Systems of Engagement (right)
Splitting PLM?
In 2021 these thoughts became more mature through various publications and players in the PLM domain.
We saw the upcoming of Systems of Engagement – I discussed OpenBOM, Colab and potentially Configit in the post: A new PLM paradigm. These systems can be characterized as connected solutions across the enterprise and value chain, focusing on a platform experience for the stakeholders.
These are all environments addressing the needs of a specific group of users as efficiently and as friendly as possible.
A System of Engagement will not fit naturally in a traditional PLM backbone; the System of Record.
Erik Herzog with SAAB Aerospace and Yousef Houshmand at that time with Daimler published that year papers related to “Federated PLM” or “The end of monolithic PLM.”. They acknowledged a company needs to focus on more than a single PLM solution. The presentation from Erik Herzog at the PLM Roadmap/PDT conference was interesting because Erik talked about the Systems of Engagement and the Systems of Record. He proposed using OSLC as the standard to connect these two types of PLM.
It was a clear example of an attempt to combine the two kinds of PLM.
And here comes my question: Do we need to split PLM?
When I look at PLM implementations in the field, almost all are implemented as a System of Record, an information backbone proved by a single vendor PLM. The various disciplines deliver their content through interfaces to the backbone (Coordinated approach).
However, there is low usability or support for multidisciplinary collaboration; the PLM backbone is not designed for that.
Due to concepts of Model-Based Systems Engineering (MBSE) and Model-Based Definition (MBD), there are now solutions on the market that allow different disciplines to work jointly related to connected datasets that can be manipulated using modeling software (1D, 2D, 3D, 4D,…).
These environments, often a mix of software and hardware tools, are the Systems of Engagement and provide speedy results with high quality in the virtual world. Digital Twins are running on Systems of Engagements, not on Systems of Records.
Systems of Engagement do not need to come from the same vendor, as they serve different purposes. But how to explain this to your management, who wants simplicity. I can imagine the IT organization has a better understanding of this concept as, at the end of 2015, Gartner introduced the concept of the bimodal approach.
Their definition:
Mode 1 is optimized for areas that are more well-understood. It focuses on exploiting what is known. This includes renovating the legacy environment so it is fit for a digital world. Mode 2 is exploratory, potentially experimenting to solve new problems. Mode 2 is optimized for areas of uncertainty. Mode 2 often works on initiatives that begin with a hypothesis that is tested and adapted during a process involving short iterations.
No Conclusion – but a question this time:
At the management level, unfortunately, there is most of the time still the “Single PLM”-mindset due to a lack of understanding of the business. Clearly splitting your PLM seems the way forward. IT could be ready for this, but will the business realize this opportunity?
What are your thoughts?
While preparing my presentation for the Dutch Model-Based Definition solutions event, I had some reflections and experiences discussing Model-Based Definition. Particularly in traditional industries. In the Aerospace & Defense, and Automotive industry, Model-Based Definition has become the standard. However, other industries have big challenges in adopting this approach. In this post, I want to share my observations and bring clarifications about the importance.
What is a Model-Based Definition?
The Wiki-definition for Model-Based Definition is not bad:
Model-based definition (MBD), sometimes called digital product definition (DPD), is the practice of using 3D models (such as solid models, 3D PMI and associated metadata) within 3D CAD software to define (provide specifications for) individual components and product assemblies. The types of information included are geometric dimensioning and tolerancing (GD&T), component level materials, assembly level bills of materials, engineering configurations, design intent, etc.
By contrast, other methodologies have historically required the accompanying use of 2D engineering drawings to provide such details.
When I started to write about Model-Based definition in 2016, the concept of a connected enterprise was not discussed. MBD mainly enhanced data sharing between engineering, manufacturing, and suppliers at that time. The 3D PMI is a data package for information exchange between these stakeholders.
The main difference is that the 3D Model is the main information carrier, connected to 2D manufacturing views and other relevant data, all connected in this package.
MBD – the benefits
There is no need to write a blog post related to the benefits of MBD. With some research, you find enough reasons. The most important benefits of MBD are:
- the information is and human-readable and machine-readable. Allowing the implementation of Smart Manufacturing / Industry 4.0 concepts
- the information relies on processes and data and is no longer dependent on human interpretation. This leads to better quality and error-fixing late in the process.
- MBD information is a building block for the digital enterprise. If you cannot master this concept, forget the benefits of MBSE and Virtual Twins. These concepts don’t run on documents.
To help you discover the benefits of MBD described by others – have a look here:
- What is MBD, and what are its benefits?
- MBD Efficiencies for Small Manufacturers
- 5 reasons to use MBD
- 10 reasons why everyone is moving away from traditional 2D drawings
MBD as a stepping stone to the future
When you are able to implement model-based definition practices in your organization and connect with your eco-system, you are learning what it means to work in a connected matter. Where the scope is limited, you already discover that working in a connected manner is not the same as mandating everyone to work with the same systems or tools. Instead, it is about new ways of working (skills & people), combined with exchange standards (which to follow).
Where MBD is part of the bigger model-based enterprise, the same principles apply for connecting upstream information (Model-Based Systems Engineering) and downstream information(IoT-based operation and service models).
Oleg Shilovitsky addresses the same need from a data point of view in his recent blog: PLM Strategy For Post COVID Time. He makes an important point about the Digital Thread:
Digital Thread is one of my favorite topics because it is leading directly to the topic of connected data and services in global manufacturing networks.
I agree with that statement as the digital thread is like MBD, another steppingstone to organize information in a connected manner, even beyond the scope of engineering-manufacturing interaction. However, Digital Thread is an intermediate step toward a full data-driven and model-based enterprise.
To master all these new ways is working, it is crucial for the management of manufacturing companies, both OEM and their suppliers, to initiate learning programs. Not as a Proof of Concept but as a real-life, growing activity.
Why MBD is not yet a common practice?
If you look at the success of MBD in Aerospace & Defense and Automotive, one of the main reasons was the push from the OEMs to align their suppliers. They even dictated CAD systems and versions to enable smooth and efficient collaboration.
In other industries, there we not so many giant OEMs that could dictate their supply chain. Often also, the OEM was not even ready for MBD. Therefore, the excuse was often we cannot push our suppliers to work different, let’s remain working as best as possible (the old way and some automation)
Besides the technical changes, MBD also had a business impact. Where the traditional 2D-Drawing was the contractual and leading information carrier, now the annotated 3D Model has to become the contractual agreement. This is much more complex than browsing through (paper) documents; now, you need an application to open up the content and select the right view(s) or datasets.
In the interaction between engineering and manufacturing, you could hear statements like:
you can use the 3D Model for your NC programming, but be aware the 2D drawing is leading. We cannot guarantee consistency between them.
In particular, this is a business change affecting the relationship between an OEM and its suppliers. And we know business changes do not happen overnight.
Smaller suppliers might even refuse to work on a Model-Based definition, as it is considered an extra overhead they do not benefit from.
In particular, when working with various OEMs that might have their own preferred MBD package content based on their preferred usage. There are standards; however, OEMs often push for their preferred proprietary format.
It is about an orchestrated change.
Implementing MBD in your company, like PLM, is challenging because people need to be aligned and trained on new ways of working. In particular, this creates resistance at the end-user level.
Similar to the introduction of mainstream CAD (AutoCAD in the eighties) and mainstream 3D CAD (Solidworks in the late nineties), it requires new processes, trained people, and matching tools.
I am aware of learning materials coming from the US, not so much about European or Asian thought leaders. Feel free to add other relevant resources for the readers in this post’s comments. Have a look and talk with:
Action Engineering with their OSCAR initiative: Bringing MBD Within Reach. I spoke with Jennifer Herron, founder of Action Engineering, a year ago about MBD and OSCAR in my blog post: PLM and Model-Based Definition.
Another interesting company to follow is Capvidia. Read their blog post to start with is MBD model-based definition in the 21st century.
The future
What you will discover from these two companies is that they focus on the connected flow of information between companies while anticipating that each stakeholder might have their preferred (traditional) PLM environment. It is about data federation.
The future of a connected enterprise is even more complex. So I was excited to see and download Yousef Hooshmand’s paper: ”From a Monolithic PLM Landscape to a Federated Domain and Data Mesh”.
Yousef and some of his colleagues report about their PLM modernization project @Mercedes-Benz AG, aiming at transforming a monolithic PLM landscape into a federated Domain and Data Mesh.
This paper provides a lot of structured thinking related to the concepts I try to explain to my audience in everyday language. See my The road to model-based and connected PLM thoughts.
This paper has much more depth and is a must-read and must-discuss writing for those interested – perhaps an opportunity for new startups and a threat to traditional PLM vendors.
Conclusion
Vellum drawings are almost gone now – we have electronic 2D Drawings. The model-based definition has confirmed the benefits of improving the interaction between engineering, manufacturing & suppliers. Still, many industries are struggling with this approach due to process & people changes needed. If you are not able or willing to implement a model-based definition approach, be worried about the future. The eco-systems will only run efficiently (and survive) when their information exchange is based on data and models. Start learning now.
p.s. just out of curiosity:
If you are model-based advocate support this post with a 
After the first article discussing “The Future of PLM,” now again a post in the category of PLM and complementary practices/domains a topic that is already for a long time on the radar: Model-Based Definition, I am glad to catch up with Jennifer Herron, founder of Action Engineering, who is one of the thought leaders related to Model-Based Definition (MBD) and Model-Based Enterprise (MBE).
In 2016 I spoke with Jennifer after reading her book: “Re-Use Your CAD – The Model-Based CAD Handbook”. At that time, the discussion was initiated through two articles on Engineering.com. Action Engineering introduced OSCAR seven years later as the next step towards learning and understanding the benefits of Model-Based Definition.
Therefore, it is a perfect moment to catch up with Jennifer. Let’s start.
Model-Based Definition
Jennifer, first of all, can you bring some clarity in terminology. When I discussed the various model-based approaches, the first response I got was that model-based is all about 3D Models and that a lot of the TLA’s are just marketing terminology.
Can you clarify which parts of the model-based enterprise you focus on and with the proper TLA’s?
Model-Based means many things to many different viewpoints and systems of interest. All these perspectives lead us down many rabbit holes, and we are often left confused when first exposed to the big concepts of model-based.
At Action Engineering, we focus on Model-Based Definition (MBD), which uses and re-uses 3D data (CAD models) in design, fabrication, and inspection.
There are other model-based approaches, and the use of the word “model” is always a challenge to define within the proper context.
For MBD, a model is 3D CAD data that comes in both native and neutral formats
Another model-based approach is Model-Based Systems Engineering (MBSE). The term “model” in this context is a formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases.
<Jos> I will come back on Model-Based Systems Engineering in future posts
Sometimes MBSE is about designing widgets, and often it is about representing the entire system and the business operations. For MBD, we often focus our education on the ASME Y14.47 definition that MBD is an annotated model and associated data elements that define the product without a drawing.
Model-Based Definition for Everybody?
I believe it took many years till 3D CAD design became a commodity; however, I still see the disconnected 2D drawing used to specify a product or part for manufacturing or suppliers. What are the benefits of model-based definition?
Are there companies that will not benefit from the model-based definition?
There’s no question that the manufacturing industry is addicted to their drawings. There are many reasons why, and yet mostly the problem is lack of awareness of how 3D CAD data can make design, fabrication, and inspection work easier.
For most, the person doing an inspection in the shipping and receiving department doesn’t have exposure to 3D data, and the only thing they have is a tabulated ERP database and maybe a drawing to read. If you plop down a 3D viewable that they can spin and zoom, they may not know how that relates to their job or what you want them to do differently.
Today’s approach of engineering championing MBD alone doesn’t work. To evolve information from the 2D drawing onto the 3D CAD model without engaging the stakeholders (machinists, assembly technicians, and inspectors) never yields a return on investment.
Organizations that succeed in transitioning to MBD are considering and incorporating all departments that touch the drawing today.
Incorporating all departments requires a vision from the management. Can you give some examples of companies that have transitioned to MBD, and what were the benefits they noticed?
I’ll give you an example of a small company with no First Article Inspection (FAI) regulatory requirements and a huge company with very rigorous FAI requirements.
Note: click on the images below to enjoy the details.
The small company instituted a system of CAD modeling discipline that allowed them to push 3D viewable information directly to the factory floor. The assembly technicians instantly understood engineering’s requirements faster and better.
The positive MBD messages for these use cases are 3D navigation, CAD Re-Use, and better control of their revisions on the factory floor.
The large company has added inspection requirements directly onto their engineering and created a Bill of Characteristics (BOC) for the suppliers and internal manufacturers. They are removing engineering ambiguity, resulting in direct digital information exchange between engineering, manufacturing, and quality siloes.
These practices have reduced error and reduced time to market.
The positive MBD messages for these use cases are unambiguous requirements capture by Engineering, Quality Traceability, and Model-Based PMI (Product and Manufacturing Information).
Model-Based Definition and PLM?
How do you see the relation between Model-Based Definition and PLM? Is a PLM system a complication or aid to implement a Model-Based Definition? And do you see a difference between the old and new PLM Vendors?
Model-Based Definition data is complex and rich in connected information, and we want it to be. With that amount of connected data, a data management system (beyond upload/download of documents) must keep all that data straight.
Depending on the size and function of an organization, a PLM may not be needed. However, a way to manage changes and collaboration amongst those using 3D data is necessary. Sometimes that results in a less sophisticated Product Data Management (PDM) system. Large organizations often require PLM.
There is significant resistance to doing MBD and PLM implementations simultaneously because PLM is always over budget and behind schedule. However, doing just MBD or just PLM without the other doesn’t work either. I think you should be brave and do both at once.
I think we can debate why PLM is always over budget and behind schedule. I hear the same about ERP implementations. Perhaps it has to deal with the fact that enterprise applications have to satisfy many users?
I believe that working with model versions and file versions can get mixed in larger organizations, so there is a need for PDM or PLM. Have you seen successful implementations of both interacting together?
Yes, the only successful MBD implementations are those that already have a matured PDM/PLM (scaled best to the individual business).
Model-Based Definition and Digital Transformation
In the previous question, we already touched on the challenge of old and modern PLM. How do you see the introduction of Model-Based Definition addressing the dreams of Industry 4.0, the Digital Twin and other digital concepts?
I just gave a presentation at the ASME Digital Twin Summit discussing the importance of MBD for the Digital Twin. MBD is a foundational element that allows engineering to compare their design requirements to the quality inspection results of digital twin data.
The feedback loop between Engineering and Quality is fraught with labor-intensive efforts in most businesses today.
Leveraging the combination of MBD and Digital Twin allows automation possibilities to speed up and increase the accuracy of the engineering to inspection feedback loop. That capability helps organizations realize the vision of Industry 4.0.
And then there is OSCAR.
I noticed you announced OSCAR. First, I thought OSCAR was a virtual aid for model-based definition, and I liked the launching page HERE. Can you tell us more about what makes OSCAR unique?
One thing that is hard with MBD implementation is there is so much to know. Our MBDers at Action Engineering have been involved with MBD for many years and with many companies. We are embedded in real-life transitions from using drawings to using models.
Suppose you start down the model-based path for digital manufacturing. In that case, there are significant investments in time to learn how to get to the right set of capabilities and the right implementation plan guided by a strategic focus. OSCAR reduces that ramp-up time with educational resources and provides vetted and repeatable methods for an MBD implementation.
OSCAR combines decades of Action Engineering expertise and lessons learned into a multi-media textbook of sorts. To kickstart an individual or an organization’s MBD journey, it includes asynchronous learning, downloadable resources, and CAD examples available in Creo, NX, and SOLIDWORKS formats.
CAD users can access how-to training and downloadable resources such as the latest edition of Re-Use Your CAD (RUYC). OSCAR enables process improvement champions to make their case to start the MBD journey. We add content regularly and post what’s new. Free trials are available to check out the online platform.
Learn more about what OSCAR is here:
Want to learn more?
In this post, I believe we only touched the tip of the iceberg. There is so much to learn and understand. What would you recommend to a reader of this blog who got interested?
RUYC (Re-Use Your CAD) is an excellent place to start, but if you need more audio-visual, and want to see real-life examples of MBD in action, get a Training subscription of OSCAR to get rooted in the vocabulary and benefits of MBD with a Model-Based Enterprise. Watch the videos multiple times! That’s what they are for. We love to work with European companies and would love to support you with a kickstart coaching package to get started.
What I learned
First of all, I learned that Jennifer is a very pragmatic person. Her company (Action Engineering) and her experience are a perfect pivot point for those who want to learn and understand more about Model-Based Definition. In particular, in the US, given her strong involvement in the American Society of Mechanical Engineers (ASME).
I am still curious if European or Asian counterparts exist to introduce and explain the benefits and usage of Model-Based Definition to their customers. Feel free to comment.
Next, and an important observation too, is the fact that Jennifer also describes the tension between Model-Based Definition and PLM. Current PLM systems might be too rigid to support end-to-end scenarios, taking benefit of the Model-Based definition.
I have to agree here. PLM Vendors mainly support their own MBD (model-based definition), where the ultimate purpose is to share all product-related information using various models as the main information carriers efficiently.
We have to study and solve a topic in the PLM domain, as I described in my technical highlights from the PLM Road Map & PDT Spring 2021 conference.
There is work to do!
Conclusion
Model-Based Definition is, for me, one of the must-do steps of a company to understand the model-based future. A model-based future sometimes incorporates Model-Based Systems Engineering, a real Digital Thread and one or more Digital Twins (depending on your company’s products).
It is a must-do activity because companies must transform themselves to depend on digital processes and digital continuity of data to remain competitive. Document-driven processes relying on the interpretation of a person are not sustainable.
After the first article discussing “The Future of PLM,” now again a post in the category of PLM and complementary practices/domains a topic that is already for a long time on the radar: Model-Based Definition, I am glad to catch up with Jennifer Herron, founder of Action Engineering, who is one of the thought leaders related to Model-Based Definition (MBD) and Model-Based Enterprise (MBE).
In 2016 I spoke with Jennifer after reading her book: “Re-Use Your CAD – The Model-Based CAD Handbook”. At that time, the discussion was initiated through two articles on Engineering.com. Action Engineering introduced OSCAR seven years later as the next step towards learning and understanding the benefits of Model-Based Definition.
Therefore, it is a perfect moment to catch up with Jennifer. Let’s start.
Model-Based Definition
Jennifer, first of all, can you bring some clarity in terminology. When I discussed the various model-based approaches, the first response I got was that model-based is all about 3D Models and that a lot of the TLA’s are just marketing terminology.
Can you clarify which parts of the model-based enterprise you focus on and with the proper TLA’s?
Model-Based means many things to many different viewpoints and systems of interest. All these perspectives lead us down many rabbit holes, and we are often left confused when first exposed to the big concepts of model-based.
At Action Engineering, we focus on Model-Based Definition (MBD), which uses and re-uses 3D data (CAD models) in design, fabrication, and inspection.
There are other model-based approaches, and the use of the word “model” is always a challenge to define within the proper context.
For MBD, a model is 3D CAD data that comes in both native and neutral formats
Another model-based approach is Model-Based Systems Engineering (MBSE). The term “model” in this context is a formalized application of modeling to support system requirements, design, analysis, verification and validation activities beginning in the conceptual design phase and continuing throughout development and later lifecycle phases.
<Jos> I will come back on Model-Based Systems Engineering in future posts
Sometimes MBSE is about designing widgets, and often it is about representing the entire system and the business operations. For MBD, we often focus our education on the ASME Y14.47 definition that MBD is an annotated model and associated data elements that define the product without a drawing.
Model-Based Definition for Everybody?
I believe it took many years till 3D CAD design became a commodity; however, I still see the disconnected 2D drawing used to specify a product or part for manufacturing or suppliers. What are the benefits of model-based definition?
Are there companies that will not benefit from the model-based definition?
There’s no question that the manufacturing industry is addicted to their drawings. There are many reasons why, and yet mostly the problem is lack of awareness of how 3D CAD data can make design, fabrication, and inspection work easier.
For most, the person doing an inspection in the shipping and receiving department doesn’t have exposure to 3D data, and the only thing they have is a tabulated ERP database and maybe a drawing to read. If you plop down a 3D viewable that they can spin and zoom, they may not know how that relates to their job or what you want them to do differently.
Today’s approach of engineering championing MBD alone doesn’t work. To evolve information from the 2D drawing onto the 3D CAD model without engaging the stakeholders (machinists, assembly technicians, and inspectors) never yields a return on investment.
Organizations that succeed in transitioning to MBD are considering and incorporating all departments that touch the drawing today.
Incorporating all departments requires a vision from the management. Can you give some examples of companies that have transitioned to MBD, and what were the benefits they noticed?
I’ll give you an example of a small company with no First Article Inspection (FAI) regulatory requirements and a huge company with very rigorous FAI requirements.
Note: click on the images below to enjoy the details.
The small company instituted a system of CAD modeling discipline that allowed them to push 3D viewable information directly to the factory floor. The assembly technicians instantly understood engineering’s requirements faster and better.
The positive MBD messages for these use cases are 3D navigation, CAD Re-Use, and better control of their revisions on the factory floor.
The large company has added inspection requirements directly onto their engineering and created a Bill of Characteristics (BOC) for the suppliers and internal manufacturers. They are removing engineering ambiguity, resulting in direct digital information exchange between engineering, manufacturing, and quality siloes.
These practices have reduced error and reduced time to market.
The positive MBD messages for these use cases are unambiguous requirements capture by Engineering, Quality Traceability, and Model-Based PMI (Product and Manufacturing Information).
Model-Based Definition and PLM?
How do you see the relation between Model-Based Definition and PLM? Is a PLM system a complication or aid to implement a Model-Based Definition? And do you see a difference between the old and new PLM Vendors?
Model-Based Definition data is complex and rich in connected information, and we want it to be. With that amount of connected data, a data management system (beyond upload/download of documents) must keep all that data straight.
Depending on the size and function of an organization, a PLM may not be needed. However, a way to manage changes and collaboration amongst those using 3D data is necessary. Sometimes that results in a less sophisticated Product Data Management (PDM) system. Large organizations often require PLM.
There is significant resistance to doing MBD and PLM implementations simultaneously because PLM is always over budget and behind schedule. However, doing just MBD or just PLM without the other doesn’t work either. I think you should be brave and do both at once.
I think we can debate why PLM is always over budget and behind schedule. I hear the same about ERP implementations. Perhaps it has to deal with the fact that enterprise applications have to satisfy many users?
I believe that working with model versions and file versions can get mixed in larger organizations, so there is a need for PDM or PLM. Have you seen successful implementations of both interacting together?
Yes, the only successful MBD implementations are those that already have a matured PDM/PLM (scaled best to the individual business).
Model-Based Definition and Digital Transformation
In the previous question, we already touched on the challenge of old and modern PLM. How do you see the introduction of Model-Based Definition addressing the dreams of Industry 4.0, the Digital Twin and other digital concepts?
I just gave a presentation at the ASME Digital Twin Summit discussing the importance of MBD for the Digital Twin. MBD is a foundational element that allows engineering to compare their design requirements to the quality inspection results of digital twin data.
The feedback loop between Engineering and Quality is fraught with labor-intensive efforts in most businesses today.
Leveraging the combination of MBD and Digital Twin allows automation possibilities to speed up and increase the accuracy of the engineering to inspection feedback loop. That capability helps organizations realize the vision of Industry 4.0.
And then there is OSCAR.
I noticed you announced OSCAR. First, I thought OSCAR was a virtual aid for model-based definition, and I liked the launching page HERE. Can you tell us more about what makes OSCAR unique?
One thing that is hard with MBD implementation is there is so much to know. Our MBDers at Action Engineering have been involved with MBD for many years and with many companies. We are embedded in real-life transitions from using drawings to using models.
Suppose you start down the model-based path for digital manufacturing. In that case, there are significant investments in time to learn how to get to the right set of capabilities and the right implementation plan guided by a strategic focus. OSCAR reduces that ramp-up time with educational resources and provides vetted and repeatable methods for an MBD implementation.
OSCAR combines decades of Action Engineering expertise and lessons learned into a multi-media textbook of sorts. To kickstart an individual or an organization’s MBD journey, it includes asynchronous learning, downloadable resources, and CAD examples available in Creo, NX, and SOLIDWORKS formats.
CAD users can access how-to training and downloadable resources such as the latest edition of Re-Use Your CAD (RUYC). OSCAR enables process improvement champions to make their case to start the MBD journey. We add content regularly and post what’s new. Free trials are available to check out the online platform.
Learn more about what OSCAR is here:
Want to learn more?
In this post, I believe we only touched the tip of the iceberg. There is so much to learn and understand. What would you recommend to a reader of this blog who got interested?
RUYC (Re-Use Your CAD) is an excellent place to start, but if you need more audio-visual, and want to see real-life examples of MBD in action, get a Training subscription of OSCAR to get rooted in the vocabulary and benefits of MBD with a Model-Based Enterprise. Watch the videos multiple times! That’s what they are for. We love to work with European companies and would love to support you with a kickstart coaching package to get started.
What I learned
First of all, I learned that Jennifer is a very pragmatic person. Her company (Action Engineering) and her experience are a perfect pivot point for those who want to learn and understand more about Model-Based Definition. In particular, in the US, given her strong involvement in the American Society of Mechanical Engineers (ASME).
I am still curious if European or Asian counterparts exist to introduce and explain the benefits and usage of Model-Based Definition to their customers. Feel free to comment.
Next, and an important observation too, is the fact that Jennifer also describes the tension between Model-Based Definition and PLM. Current PLM systems might be too rigid to support end-to-end scenarios, taking benefit of the Model-Based definition.
I have to agree here. PLM Vendors mainly support their own MBD (model-based definition), where the ultimate purpose is to share all product-related information using various models as the main information carriers efficiently.
We have to study and solve a topic in the PLM domain, as I described in my technical highlights from the PLM Road Map & PDT Spring 2021 conference.
There is work to do!
Conclusion
Model-Based Definition is, for me, one of the must-do steps of a company to understand the model-based future. A model-based future sometimes incorporates Model-Based Systems Engineering, a real Digital Thread and one or more Digital Twins (depending on your company’s products).
It is a must-do activity because companies must transform themselves to depend on digital processes and digital continuity of data to remain competitive. Document-driven processes relying on the interpretation of a person are not sustainable.
Last week I shared my first review of the PLM Roadmap / PDT Fall 2020 conference, organized by CIMdata and Eurostep. Having digested now most of the content in detail, I can state this was the best conference of 2020. In my first post, the topics I shared were mainly the consultant’s view of digital thread and digital twin concepts.
This time, I want to focus on the content presented by the various Aerospace & Defense working groups who shared their findings, lessons-learned (so far) on topics like the Multi-view BOM, Supply Chain Collaboration, MBSE Data interoperability.
These sessions were nicely wrapped with presentations from Alberto Ferrari (Raytheon), discussing the digital thread between PLM and Simulation Lifecycle Management and Jeff Plant (Boeing) sharing their Model-Based Engineering strategy.
I believe these insights are crucial, although there might be people in the field that will question if this research is essential. Is not there an easier way to achieve to have the same results?
Nicely formulated by Ilan Madjar as a comment to my first post:
Ilan makes a good point about simplifying the ideas to the masses to make it work. The majority of companies probably do not have the bandwidth to invest and understand the future benefits of a digital thread or digital twins.
This does not mean that these topics should not be studied. If your business is in a small, simple eco-system and wants to work in a connected mode, you can choose a vendor and a few custom interfaces.
However, suppose you work in a global industry with an extensive network of partners, suppliers, and customers.
In that case, you cannot rely on ad-hoc interfaces or a single vendor. You need to invest in standards; you need to study common best practices to drive methodology, standards, and vendors to align.
This process of standardization is so crucial if you want to have a sustainable, connected enterprise. In the end, the push from these companies will lead to standards, allowing the smaller companies to ad-here or connect to.
The future is about Connected through Standards, as discussed in part 1 and further in this post. Let’s go!
Global Collaboration – Defining a baseline for data exchange processes and standards
Katheryn Bell (Pratt & Whitney Canada) presented the progress of the A&D Global Collaboration workgroup. As you can see from the project timeline, they have reached the phase to look towards the future.
Katheryn mentioned the need to standardize terminology as the first point of attention. I am fully aligned with that point; without a standardized terminology framework, people will have a misunderstanding in communication.
This happens even more in the smaller businesses that just pick sometimes (buzz) terms without a full understanding.
Several years ago, I talked with a PLM-implementer telling me that their implementation focus was on systems engineering. After some more explanations, it appeared they were making an attempt for configuration management in reality. Here the confusion was massive. Still, a standard, common terminology is crucial in our domain, even if it seems academic.
The group has been analyzing interoperability standards, standards for long-time archival and retrieval (LOTAR), but also has been studying the ISO 44001 standard related to Collaborative business relationship management systems
In the Q&A session, Katheryn explained that the biggest problem to solve with collaboration was the risk of working with the wrong version of data between disciplines and suppliers.
Of course, such errors can lead to huge costs if they are discovered late (or too late). As some of the big OEMs work with thousands of suppliers, you can imagine it is not an issue easily discovered in a more ad-hoc environment.
The move to a standardized Technical Data Package based on a Model-Based Definition is one of these initiatives in this domain to reduce these types of errors.
You can find the proceedings from the Global Collaboration working group here.
Connect, Trace, and Manage Lifecycle of Models, Simulation and Linked Data: Is That Easy?
I loved Alberto Ferrari‘s (Raytheon) presentation how he described the value of a model-based digital thread, positioning it in a targeted enterprise.
Click on the image and discover how business objectives, processes and models go together supported by a federated infrastructure.
Alberto’s presentation was a kind of mind map from how I imagine the future, and it is a pity if you have not had the chance to see his session.
Alberto also focused on the importance of various simulation capabilities combined with simulation lifecycle management. For Alberto, they are essential to implement digital twins. Besides focusing on standards, Alberto pleas for a semantic integration, open service architecture with the importance of DevSecOps.
Enough food for thought; as Alberto mentioned, he presented the corporate vision, not the current state.
More A&D Action Groups
There were two more interesting specialized sessions where teams from the A&D action groups provided a status update.
Brandon Sapp (Boeing) and Ian Parent (Pratt & Whitney) shared the activities and progress on Minimum Model-Based Definition (MBD) for Type Design Certification.
As Brandon mentioned, MBD is already a widely used capability; however, MBD is still maturing and evolving. I believe that is also one of the reasons why MBD is not yet accepted in mainstream PLM. Smaller organizations will wait; however, can your company afford to wait?
More information about their progress can be found here.
Mark Williams (Boeing) reported from the A&D Model-Based Systems Engineering action group their first findings related to MBSE Data Interoperability, focusing on an Architecture Model Exchange Solution. A topic interesting to follow as the promise of MBSE is that it is about connected information shared in models. As Mark explained, data exchange standards for requirements and behavior models are mature, readily available in the tools, and easily adopted. Exchanging architecture models has proven to be very difficult. I will not dive into more details, respecting the audience of this blog.
For those interested in their progress, more information can be found here
Model-Based Engineering @ Boeing
In this conference, the participation of Boeing was significant through the various action groups. As the cherry on the cake, there was Jeff Plant‘s session, giving an overview of what is happening at Boeing. Jeff is Boeing’s director of engineering practices, processes, and tools.
In his introduction, Jeff mentioned that Boeing has more than 160.000 employees in over 65 countries. They are working with more than 12.000 suppliers globally. These suppliers can be manufacturing, service or technology partnerships. Therefore you can imagine, and as discussed by others during the conference, streamlined collaboration and traceability are crucial.
The now-famous MBE Diamond symbol illustrates the model-based information flows in the virtual world and the physical world based on the systems engineering approach. Like Katheryn Bell did in her session related to Global Collaboration, Jeff started explaining the importance of a common language and taxonomy needed if you want to standardize processes.
Zoom in on the Boeing MBE Taxonomy, you will discover the clarity it brings for the company.
I was not aware of the ISO 23247 standard concerning the Digital Twin framework for manufacturing, aiming to apply industry standards to the model-based definition of products and process planning. A standard certainly to follow as it brings standardization on top of existing standards.
As Jeff noted: A practical standard for implementation in a company of any size. In my opinion, mandatory for a sustainable, connected infrastructure.
Jeff presented the slide below, showing their standardization internally around federated platforms.
This slide resembles a lot the future platform vision I have been sharing since 2017 when discussing PLM’s future at PLM conferences, when explaining the differences between Coordinated and Connected – see also my presentation here on Slideshare.
You can zoom in on the picture to see the similarities. For me, the differences were interesting to observe. In Jeff’s diagram, the product lifecycle at the top indicates the platform of (central) interest during each lifecycle stage, suggesting a linear process again.
In reality, the flow of information through feedback loops will be there too.
The second exciting detail is that these federated architectures should be based on strong interoperability standards. Jeff is urging other companies, academics and vendors to invest and come to industry standards for Model-Based System Engineering practices. The time is now to act on this domain.
It reminded me again of Marc Halpern’s message mentioned in my previous post (part 1) that we should be worried about vendor alliances offering an integrated end-to-end data flow based on their solutions. This would lead to an immense vendor-lock in if these interfaces are not based on strong industry standards.
Therefore, don’t watch from the sideline; it is the voice (and effort) of the companies that can drive standards.
Finally, during the Q&A part, Jeff made an interesting point explaining Boeing is making a serious investment, as you can see from their participation in all the action groups. They have made the long-term business case.
The team is confident that the business case for such an investment is firm and stable, however in such long-term investment without direct results, these projects might come under pressure when the business is under pressure.
The virtual fireside chat
The conference ended with a virtual fireside chat from which I picked up an interesting point that Marc Halpern was bringing in. Marc mentioned a survey Gartner has done with companies in fast-moving industries related to the benefits of PLM. Companies reported improvements in accuracy and product development. They did not see so much a reduced time to market or cost reduction. After analysis, Gartner believes the real issue is related to collaboration processes and supply chain practices. Here lead times did not change, nor the number of changes.
Marc believes that this topic will be really showing benefits in the future with cloud and connected suppliers. This reminded me of an article published by McKinsey called The case for digital reinvention. In this article, the authors indicated that only 2 % of the companies interview were investing in a digital supply chain. At the same time, the expected benefits in this area would have the most significant ROI.
The good news, there is consistency, and we know where to focus for early results.
Conclusion
It was a great conference as here we could see digital transformation in action (groups). Where vendor solutions often provide a sneaky preview of the future, we saw people working on creating the right foundations based on standards. My appreciation goes to all the active members in the CIMdata A&D action groups as they provide the groundwork for all of us – sooner or later.
A month ago I announced to write a series of posts related to the various facets of Model-Based. As I do not want to write a book for a limited audience, I still believe blog posts are an excellent way to share knowledge and experience to a wider audience. Remember PLM is about sharing!
There are three downsides to this approach:
- you have to chunk the information into pieces; my aim is not to exceed 1000 words per post
- Isolated posts can be taken out of context (in a positive or negative way)
- you do not become rich and famous for selling your book
Model-Based ways of working are a hot topic and crucial for a modern digital enterprise. The modern digital enterprise does not exist yet to my knowledge, but the vision is there. Strategic consultancy firms are all active exploring and explaining the potential benefits – I have mentioned McKinsey / Accenture / Capgemini before.
In the domain of PLM, there is a bigger challenge as here we are suffering from the fact that the word “Model” immediately gets associated with a 3D Model. In addition to the 3D CAD Model, there is still a lot of useful legacy data that does not match with the concepts of a digital enterprise. I wrote and spoke about this topic a year ago. Among others at PI 2017 Berlin and you can check this presentation on SlideShare: How digital transformation affects PLM
Back to the various aspects of Model-Based
My first post: Model-Based – an introduction described my intentions what I wanted to explain. I got some interesting feedback and insights from my readers . Some of the people who responded understood that the crucial characteristic of the model-based enterprise is to use models to master a complex environment. Business Models, Mathematical Models, System Models are all part of a model-based enterprise, and none of them have a necessary relation to the 3D CAD model.
Why Model-Based?
Because this is an approach to master complex environments ! If you are studying the concepts for a digital enterprise model, it is complex. Artificial intelligence, predictive actions all need a model to deliver. The interaction and response related to my first blog post did not show any problems – only a positive mindset to further explore. For example, if you read this blog post from Contact, you will see the message came across very well: Model-Based in Model-Based Systems Engineering – what’s up ?
Where the confusion started
My second post: Why Model-Based? The 3D CAD Model was related to model-based, focusing on the various aspects related to the 3D CAD model, without going into all the details. In particular, in the PLM world, there is a lot of discussion around Model-Based Design or Model-Based Definition, where new concepts are discussed to connect engineering and manufacturing in an efficient and modern data-driven way. Lifecycle Insights, Action Engineering, Engineering.com, PTC, Tech-Clarity and many more companies are publishing information related to the model-based engineering phase.
Here is was surprised by Oleg’s blog with his post Model-Based Confusion in 3D CAD and PLM.
If you read his post, you get the impression that the model-based approach is just a marketing issue instead of a significant change towards a digital enterprise. I quote:
Here is the thing… I don’t see much difference between saying PLM-CAD integration sharing data and information for downstream processes and “model-driven” data sharing. It might be a terminology thing, but data is managed by CAD-PLM tools today and accessed by people and other services. This is how things are working today. If model-driven is an approach to replace 2D drawings, I can see it. However, 2D replacement is something that I’ve heard 20 years ago. However, 2D drawings are still massively used by manufacturing companies despite some promises made by CAD vendors long time ago.
I was surprised by the simplicity of this quote. As if CAD vendors are responsible for new ways of working. In particular, automotive and aerospace companies are pushing for a model-based connection between engineering and manufacturing to increase quality, time to market and reduced handling costs. The model-based definition is not just a marketing issue as you can read from benefits reported by Jennifer Herron (Re-use your CAD – the model-based CAD handbook – describing practices and benefits already in 2013) or Tech-Clarity (The How-To Guide for adopting model-based definition – describing practices and benefits – sponsored by SolidWorks)
Oleg’s post unleashed several reactions of people who shared his opinion (read the comments here). They are all confused, t is all about marketing / let’s not change / too complex. Responses you usually hear from a generation that does not feel and understand the new approaches of a digital enterprise. If you are in the field working with multiple customers trying to understand the benefits of model-based definition, you would not worry about terminology – you would try to understand it and make it work.
Model-Based – just marketing?
In his post, Oleg refers to CIMdata’ s explanation of the various aspects of model-based in the context of PLM. Instead of referring to the meaning of the various acronyms, Peter Bilello (CIMdata) presented at the latest PDT conference (Oct 2017 – Gothenburg) an excellent story related to the various aspects of the model-based aspects, actually the whole conference was dedicated to the various aspects of a Model-Based Enterprise illustrates that it is not a vendor marketing issue. You can read my comments from the vendor-neutral conference here: The weekend after PDT Europe 2017 Part 1 and Part 2.
There were some dialogues on LinkedIn this weekend, and I promised to publish this post first before continuing on the other aspects of a model-based enterprise. Just today Oleg published a secondary post related to this topic: Model-Based marketing in CAD and PLM, where again the tone and blame is to the PLM/CAD vendors, as you can see from his conclusion:
I can see “mode-based” as a new and very interesting wave of marketing in 3D CAD and PLM. However, it is not pure marketing and it has some rational. The rational part of model-based approach is to have information model combined from 3D design and all connected data element. Such model can be used as a foundation for design, engineering, manufacturing, support, maintenance. Pretty much everything we do. It is hard to create such model and it is hard to combine a functional solution from existing packages and products. You should think how to combine multiple CAD systems, PLM platforms and many other things together. It requires standards. It requires from people to change. And it requires changing of status quo. New approaches in data management can change siloed world of 3D CAD and PLM. It is hard, but nothing to do with slides that will bring shiny words “model-base”. Without changing of technology and people, it will remain as a history of marketing
Again it shows the narrow mindset on the future of a model-based enterprise. When it comes to standards I recommend you to register and watch CIMdata’s educational webinar called: Model-Based Enterprise and Standards – you need to register. John MacKrell CIMdata’s chairman gives an excellent overview and status of model-based enterprise initiative. After having studied and digested all the links in this post, I challenge you to make your mind up. The picture below comes from John’s presentation, an illustration where we are with model-based definition currently
Conclusion
The challenge of modern businesses is that too often we conclude too fast on complex issues or we frame new developments because they do not fit our purpose. You know it from politics. Be aware it is also valid in the world of PLM. Innovation and a path to a modern digital enterprise do not come easy – you need to invest and learn all the aspects. To be continued (and I do not have all the answers either)
Jos Voskuil's Weblog 
If it was easy, anyone could do it. It's hard. It's supposed to be hard. Quote inspired by Tom Hanks…
Jos, what a ride you have had! And looking at some of the spaghetti system architectures of even today's businesses,…
Congratulations, Jos! I'm very happy that you'll stay active in the PLM world and continue with your blogs - during…
Jos, welcome to the world of (part-time) retirement. Enjoy your AOW. Thanks Dick, you have the experience now - enjoy…
Thanks for all the valuable thoughts you have shared with us Jos, hope your 'new career' will bring you lots…