You are currently browsing the tag archive for the ‘model-based’ tag.

In my previous post, “My PLM Bookshelf,” on LinkedIn, I shared some of the books that influenced my thinking related to PLM. As you can see in the LinkedIn comments, other people added their recommendations for PLM-related books to get inspired or more knowledgeable.

 

Where reading a book is a personal activity, now I want to share with you how to get educated in a more interactive manner related to PLM. In this post, I talk with Peter Bilello, President & CEO of CIMdata. If you haven’t heard about CIMdata and you are active in PLM, more to learn on their website HERE. Now let us focus on Education.

CIMdata

Peter, knowing CIMdata from its research valid for the whole PLM community, I am curious to learn what is the typical kind of training CIMdata is providing to their customers.

Jos, throughout much of CIMdata’s existence, we have delivered educational content to the global PLM industry. With a core business tenant of knowledge transfer, we began offering a rich set of PLM-related tutorials at our North American and pan-European conferences starting in the earlier 1990s.

Since then, we have expanded our offering to include a comprehensive set of assessment-based certificate programs in a broader PLM sense. For example, systems engineering and digital transformation-related topics. In total, we offer more than 30 half-day classes. All of which can be delivered in-person as a custom configuration for a specific client and through public virtual-live or in-person classes. We have certificated more than 1,000 PLM professionals since the introduction in 2009 of this PLM Leadership offering.

Based on our experience, we recommend that an organization’s professional education strategy and plans address the organization’s specific processes and enabling technologies. This will help ensure that it drives the appropriate and consistent operations of its processes and technologies.

For that purpose, we expanded our consulting offering to include a comprehensive and strategic digital skills transformation framework. This framework provides an organization with a roadmap that can define the skills an organization’s employees need to possess to ensure a successful digital transformation.

In turn, this framework can be used as an efficient tool for the organization’s HR department to define its training and job progression programs that align with its overall transformation.

 

The success of training

We are both promoting the importance of education to our customers. Can you share with us an example where Education really made a difference? Can we talk about ROI in the context of training?

Jos, I fully agree. Over the years, we have learned that education and training are often minimized (i.e., sub-optimized). This is unfortunate and has usually led to failed or partially successful implementations.

In our view, both education and training are needed, along with strong organizational change management (OCM) and a quality assurance program during and after the implementation.

In our terms, education deals with the “WHY” and training with the “HOW”. Why do we need to change? Why do we need to do things differently? And then “HOW” to use new tools within the new processes.

We have seen far too many failed implementations where sub-optimized decisions were made due to a lack of understanding (i.e., a clear lack of education). We have also witnessed training and education being done too early or too late.

This leads to a reduced Return on Investment (ROI).

Therefore a well-defined skills transformation framework is critical for any company that wants to grow and thrive in the digital world. Finally, a skills transformation framework needs to be tied directly to an organization’s digital implementation roadmap and structure, state of the process, and technology maturity to maximize success.

 

Training for every size of the company?

When CIMdata conducts PLM training, is there a difference, for example, when working with a big global enterprise or a small and medium enterprise?

You might think the complexity might be similar; however, the amount of internal knowledge might differ. So how are you dealing with that?

We basically find that the amount of training/education required mostly depends on the implementation scope. Meaning the scope of the proposed digital transformation and the current maturity level of the impacted user community.

It is important to measure the current maturity and establish appropriate metrics to measure the success of the training (e.g., are people, once trained, using the tools correctly).

CIMdata has created a three-part PLM maturity model that allows an organization to understand its current PLM-related organizational, process, and technology maturity.

The three-part PLM maturity model

The PLM maturity model provides an important baseline for identifying and/or developing the appropriate courses for execution.

This also allows us, when we are supporting the definition of a digital skills transformation framework, to understand how the level of internal knowledge might differ within and between departments, sites, and disciplines. All of which help define an organization-specific action plan, no matter its size.

 

Where is CIMdata training different?

Most of the time, PLM implementers offer training too for their prospects or customers. So, where is CIMdata training different?

 

For this, it is important to differentiate between education and training. So, CIMdata provides education (the why) and training and education strategy development and planning.

We don’t provide training on how to use a specific software tool. We believe that is best left to the systems integrator or software provider.

While some implementation partners can develop training plans and educational strategies, they often fall short in helping an organization to effectively transform its user community. Here we believe training specialists are better suited.

 

Digital Transformation and PLM

One of my favorite topics is the impact of digitization in the area of product development. CIMdata introduced the Product Innovation Platform concept to differentiate from traditional PDM/PLM. Who needs to get educated to understand such a transformation, and what does CIMdata contribute to this understanding.

We often start with describing the difference between digitalization and digitization. This is crucial to be understood by an organization’s management team. In addition, management must understand that digitalization is an enterprise initiative.

It isn’t just about product development, sales, or enabling a new service experience. It is about maximizing a company’s ROI in applying and leveraging digital as needed throughout the organization. The only way an organization can do this successfully is by taking an end-to-end approach.

The Product Innovation Platform is focused on end-to-end product lifecycle management. Therefore, it must work within the context of other enterprise processes that are focused on the business’s resources (i.e., people, facilities, and finances) and on its transactions (e.g., purchasing, paying, and hiring).

As a result, an organization must understand the interdependencies among these domains. If they don’t, they will ultimately sub-optimize their investment. It is these and other important topics that CIMdata describes and communicates in its education offering.

The Product Innovation Platform in a digital enterprise

More than Education?

As a former teacher, I know that a one-time education, a good book or slide deck, is not enough to get educated. How does CIMdata provide a learning path or coaching path to their customers?

Jos, I fully agree. Sustainability of a change and/or improved way of working (i.e., long-term sustainability) is key to true and maximized ROI. Here I am referring to the sustainability of the transformation, which can take years.

With this, organizational change management (OCM) is required. OCM must be an integral part of a digital transformation program and be embedded into a program’s strategy, execution, and long-term usage. That means training, education, communication, and reward systems all have to be managed and executed on an ongoing basis.

For example, OCM must be executed alongside an organization’s digital skills transformation program. Our OCM services focus on strategic planning and execution support. We have found that most companies understand the importance of OCM, often don’t fully follow through on it.

 

A model-based future?

During the CIMdata Roadmap & PDT conferences, we have often discussed the importance of Model-Based Systems Engineering methodology as a foundation of a model-based enterprise. What do you see? Is it only the big Aerospace and Defense companies that can afford this learning journey, or should other industries also invest? And if yes, how to start.

Jos, here I need to step back for a minute. All companies have to deal with increasing complexity for their organization, supply chain, products, and more.

So, to optimize its business, an organization must understand and employ systems thinking and system optimization concepts. Unfortunately, most people think of MBSE as an engineering discipline. This is unfortunate because engineering is only one of the systems of systems that an organization needs to optimize across its end-to-end value streams.

The reality is all companies can benefit from MBSE. As long as they consider optimization across their specific disciplines, in the context of their products and services and where they exist within their value chain.

The MBSE is not just for Aerospace and Defense companies. Still, a lot can be learned from what has already been done. Also, leading automotive companies are implementing and using MBSE to design and optimize semi- and high-automated vehicles (i.e., systems of systems).

The starting point is understanding your systems of systems environment and where bottlenecks exist.

There should be no doubt, education is needed on MBSE and how MBSE supports the organization’s Model-Based Enterprise requirements.

Published work from the CIMdata administrated A&D PLM Action Group can be helpful. Also, various MBE and systems engineering maturity models, such as one that CIMdata utilizes in its consulting work.

Want to learn more?

Thanks, Peter, for sharing your insights. Are there any specific links you want to provide to get educated on the topics discussed? Perhaps some books to read or conferences to visit?

x
Jos, as you already mentioned:

x

  • the CIMdata Roadmap & PDT conferences have provided a wealth of insight into this market for more than 25 years.
    [Jos: Search for my blog posts starting with the text: “The weekend after ….”]
  • In addition, there are several blogs, like yours, that are worth following, and websites, like CIMdata’s pages for education or other resources which are filled with downloadable reading material.
  • Additionally, there are many user conferences from PLM solution providers and third-party conferences, such as those hosted by the MarketKey organization in the UK.

These conferences have taken place in Europe and North America for several years. Information exchange and formal training and education are offered in many events. Additionally, they provide an excellent opportunity for networking and professional collaboration.

What I learned

Talking with Peter made me again aware of a few things. First, it is important to differentiate between education and training. Where education is a continuous process, training is an activity that must take place at the right time. Unfortunately, we often mix those two terms and believe that people are educated after having followed a training.

Secondly, investing in education is as crucial as investing in hard- or software. As Peter mentioned:

We often start with describing the difference between digitalization and digitization. This is crucial to be understood by an organization’s management team. In addition, management must understand that digitalization is an enterprise initiative.

System Thinking is not just an engineering term; it will be a mandate for managing a company, a product and even a planet into the future

Conclusion

This time a quote from Albert Einstein, supporting my PLM coaching intentions:

“Education is not the learning of facts
but the training of the mind to think.”

 

In my previous post, I discovered that my header for this series is confusing. Although a future implementation of system lifecycle management (SLM/PLM) will rely on models, the most foundational change needed is a technical one to create a data-driven infrastructure for connected ways of working.

My previous article discussed the concept of the dataset, which led to interesting discussions on LinkedIn and in my personal interactions. Also, this time Matthias Ahrens (HELLA) shared again a relevant but very academic article in this context – how to harmonize company information.

For those who want to dive deeper into the concept of connected datasets, read this article: The euBusinessGraph ontology: A lightweight ontology for harmonizing basic company information.

The article illustrates that the topic is relevant for all larger enterprises (and it is not an easy topic).

This time I want to share my thoughts about the two statements from my introductory post, i.e.:

A model-based approach with connected datasets seems to be the way forward. Managing data in documents will become inefficient as they cannot contribute to any digital accelerator, like applying algorithms. Artificial Intelligence relies on direct access to qualified data.

A model-based approach with connected datasets

We discussed connected datasets in the previous post; now, let’s explore why models and datasets are related. In the traditional CAD-centric PLM domain, most people will associate the word model with a CAD model, to be more precise, the 3D CAD Model. However, there are many other types of models used related to product development, delivery and operations.

A model can be a:

Physical Model

  • A smaller-scale object for the first analysis, e.g., a city or building model, an airplane model

Conceptual Model

  • A conceptual model describes the entities and their relations, e.g., a Process Flow Diagram (PFD)
  • A mathematical model describes a system concept using a mathematical language, e.g., weather or climate models. Modelica and MATLAB would fall in this category
  • A CGI (Computer Generated Imagery) or 3D CAD model is probably the most associated model in the mind of traditional PLM practitioners
  • Functional and Logical Models describing the services and components of a system are crucial in an MBSE

Operational Model

  • A model providing performance analysis based on (real-time) data coming from selected data sources. It could be an operational business model, an asset performance model; even my Garmin’s training performance model is such an operating model.

The list of all models above is not extensive nor academically defined. Moreover, some model term definitions might overlap, e.g., where would we classify software models or manufacturing models?

All models are a best-so-far approach to describing reality. Based on more accurate data from observations or measurements, the model comes closer to what happens in reality.

A model and its data

Never blame the model when there is a difference between what the model predicts and the observed reality. It is still a model.  That’s why we need feedback loops from the actual physical world to the virtual world to fine-tune the model.

Part of what we call Artificial Intelligence is nothing more than applying algorithms to a model. The more accurate data available, the more “intelligent” the artificial intelligence solution will be.

By using data analysis complementary to the model, the model may get better and better through self-learning. Like our human brain, it starts with understanding the world (our model) and collecting experiences (improving our model).

There are two points I would like to highlight for this paragraph:

  • A model is never 100 % the same as reality – so don’t worry about deviations. There will always be a difference between virtual predicted and physical measured – most of the time because reality has much more influencing parameters.
  • The more qualified data we use in the model, the closer to reality – so focus on accurate (and the right) data for your model. Although, as most of the time, it is impossible to fully model a system, focus on the most significant data sources.

The ultimate goal: THE DIGITAL TWIN

The discussion related to data-driven and the usage of models might feel abstract and complex (and that’s the case). However the term “digital twin” is well known and even used in board rooms.

The great benefits of a digital twin for business operations and for sustainability are promoted by many software vendors and consultancy firms.

My statement and reason for this series of blog posts: Digital Twins do not run on documents, you need to have a data-driven, model-based infrastructure to efficiently benefit from digital twin concepts.

Unfortunate a reliable and sustainable implementation of a digital twin requires more than software – it is a learning journey to connect the right data to the right model.
A puzzle every company has to solve as there is no 100 percent blueprint at this time.

Are Low Code platforms the answer?

I mentioned the importance of accurate data. Companies have different systems or even platforms managing enterprise data. The digital dream is that by combining datasets from different systems and platforms, we can provide to any user the needed information in real-time. My statement from my introductory post was:

I don’t believe in Low-Code platforms that provide ad-hoc solutions on demand. The ultimate result after several years might be again a new type of spaghetti. On the other hand, standardized interfaces and protocols will probably deliver higher, long-term benefits. Remember: Low code: A promising trend or a Pandora’s Box?

Let’s look into some of the low-code platform messages mentioned by Low-Code advocates:

You will have an increasingly hard time finding developers to keep up with global app development demands (reason #1 for PEGA)

This statement reminded me of the early days of SmarTeam implementations. With a Data model Wizard, a Form Designer, and a Visual Basic COM API, you could create any kind of data management application with SmarTeam. By using its built-in behaviors for document lifecycle management, item lifecycle management, and CAD integrations combined with easy customizations.

The sky was the limit to satisfy end users.  No need for an experienced partner or to be a skilled programmer (this was 2003+). SmarTeam was a low-code platform the marketing department would say now.

A lot of my activities between 2003 and 2010 were related fixing the problems related to flexibility,  making sense (again) of customizations.  I wrote about this in a 2015 post: The importance of a (PLM) data model sharing the experiences of “fixing” issues created to flexibility.

Think first

The challenge is that an enthusiastic team creates a (low code) solution rapidly. Immediate success is celebrated by the people involved. However, the future impact of this solution is often forgotten – we did the job,  right?

Documentation and a broader visibility are often lacking when implementing such a solution.

For example, suppose your product data is going to be consumed by another app. In that case, you need to make sure that the information you consume is accurate. On the other hand, perhaps the information was valid when you created the app.

However, if your friendly co-worker has moved on to another job and someone with different data standards becomes responsible for the data you consume, the reliability might fail. So how do you guarantee its quality?

Easy tools have often led to spaghetti, starting from Clipper (the old days), Visual Basic (the less old days) to highly customizable systems (like Aras is promoting) and future low-code platforms (and Aras is there again).

However, the strength of being highly flexible is also the weaknesses if not managed and understood correctly. In particular, in a digital enterprise architecture, you need skilled people who guarantee a reliable anchorage of the solution.

The HBR article When Low-Code/No-Code Development Works — and When It Doesn’t mentions the same point:

There are great benefits from LC/NC software development, but management challenges as well. Broad use of these tools institutionalizes the “shadow IT phenomenon, which has bedeviled IT organizations for decades — and could make the problem much worse if not appropriately governed. Citizen developers tend to create applications that don’t work or scale well, and then they try to turn them over to IT. Or the person may leave the company, and no one knows how to change or support the system they developed.

The fundamental difference: from coordinated to connected

For the moment, I remain skeptical about the low-code hype, because I have seen this kind of hype before. The most crucial point companies need to understand is that the coordinated world and the connected world are incompatible.

Using new tools based on old processes and existing data is not a digital transformation. Instead, a focus on value streams and their needed (connected) data should lead to the design of a modern digital enterprise, not the optimization and connectivity between organizational siloes.
Before buying a tool (a medicine) to reduce the current pains, imagine your future ways of working, discover what is possible with your existing infrastructure and identify the gaps.

Next, you need to analyze if these gaps are so significant that it requires a technology change. Probably it does, as historically, systems were not designed to share data horizontally in an organization.

In this context, have a look at Lionel Grealou’s s article for Engineering.com:
Data Readiness in the new age of digital collaboration.

Conclusion

We discussed the crucial relation between models and data. Models have only value if they acquire the right and accurate data (exercise 1).

Next, even the simplest development platforms, like low-code platforms, require brains and a long-term strategy (exercise 2) – nothing is simple at this moment in transformational times.  

The next and final post in this series will focus on configuration management – a new approach is needed. I don’t have the answers, but I will share some thoughts

A recommended event and an exciting agenda and a good place to validate and share your thoughts.

I will be there and look forward to meeting you at this conference (unfortunate still virtually)

In my last post, I zoomed in on a preferred technical architecture for the future digital enterprise. Drawing the conclusion that it is a mission impossible to aim for a single connected environment. Instead, information will be stored in different platforms, both domain-oriented (PLM, ERP, CRM, MES, IoT) and value chain oriented (OEM, Supplier, Marketplace, Supply Chain hub).

In part 3, I posted seven statements that I will be discussing in this series. In this post, I will zoom in on point 2:

Data-driven does not mean we do not need any documents anymore. Read electronic files for documents. Likely, document sets will still be the interface to non-connected entities, suppliers, and regulatory bodies. These document sets can be considered a configuration baseline.

 

System of Record and System of Engagement

In the image below, a slide from 2016,  I show a simplified view when discussing the difference between the current, coordinated approach and the future, connected approach.  This picture might create the wrong impression that there are two different worlds – either you are document-driven, or you are data-driven.

In the follow-up of this presentation, I explained that companies need both environments in the future. The most efficient way of working for operations will be infrastructure on the right side, the platform-based approach using connected information.

For traceability and disconnected information exchanges, the left side will be there for many years to come. Systems of Record are needed for data exchange with disconnected suppliers, disconnected regulatory bodies and probably crucial for configuration management.

The System of Record will probably remain as a capability in every platform or cross-section of platform information. The Systems of Engagement will be the configured real-time environment for anyone involved in active company processes, not only ERP or MES, all execution.

Introducing SysML and SML

This summer, I received a copy of Martin Eigner’s System Lifecycle Management book, which I am reading at his moment in my spare moments. I always enjoyed Martin’s presentations. In many ways, we share similar ideas. Martin from his profession spent more time on the academic aspects of product and system lifecycle than I. But, on the other hand, I have always been in the field observing and trying to make sense of what I see and learn in a coherent approach. I am halfway through the book now, and for sure, I will come back on the book when I have finished.

A first impression: A great and interesting book for all. Martin and I share the same history of data management. Read all about this in his second chapter: Forty Years of Product Data Management

From PDM via PLM to SysLM, is a chapter that everyone should read when you haven’t lived it yourself. It helps you to understand the past (Learning for the past to understand the future). When I finish this series about the model-based and connected approach for products and systems, Martin’s book will be highly complementary given the content he describes.

There is one point for which I am looking forward to is feedback from the readers of this blog.

Should we, in our everyday language, better differentiate between Product Lifecycle Management (PLM) and System Lifecycle Management(SysLM)?

In some customer situations, I talk on purpose about System Lifecycle Management to create the awareness that the company’s offering is more than an electro/mechanical product. Or ultimately, in a more circular economy, would we use the term Solution Lifecycle Management as not only hardware and software might be part of the value proposition?

Martin uses consistently the abbreviation SysLM, where I would prefer the TLA SLM. The problem we both have is that both abbreviations are not unique or explicit enough. SysLM creates confusion with SysML (for dyslectic people or fast readers). SLM already has so many less valuable meanings: Simulation Lifecycle Management, Service Lifecycle Management or Software Lifecycle Management.

For the moment, I will use the abbreviation SLM, leaving it in the middle if it is System Lifecycle Management or Solution Lifecycle Management.

 

How to implement both approaches?

In the long term, I predict that more than 80 percent of the activities related to SLM will take place in a data-driven, model-based environment due to the changing content of the solutions offered by companies.

A solution will be based on hardware, the solid part of the solution, for which we could apply a BOM-centric approach. We can see the BOM-centric approach in most current PLM implementations. It is the logical result of optimizing the product lifecycle management processes in a coordinated manner.

However, the most dynamic part of the solution will be covered by software and services. Changing software or services related to a solution has completely different dynamics than a hardware product.

Software and services implementations are associated with a data-driven, model-based approach.

The management of solutions, therefore, needs to be done in a connected manner. Using the BOM-centric approach to manage software and services would create a Kafkaesque overhead.

Depending on your company’s value proposition to the market, the challenge will be to find the right balance. For example, when you keep on selling disconnectedhardware, there is probably no need to change your internal PLM processes that much.

However, when you are moving to a connected business model providing solutions (connected systems / Outcome-based services), you need to introduce new ways of working with a different go-to-market mindset. No longer linear, but iterative.

A McKinsey concept, I have been promoting several times, illustrates a potential path – note the article was not written with a PLM mindset but in a business mindset.

What about Configuration Management?

The different datasets defining a solution also challenge traditional configuration management processes. Configuration Management (CM) is well established in the aerospace & defense industry. In theory, proper configuration management should be the target of every industry to guarantee an appropriate performance, reduced risk and cost of fixing issues.

The challenge, however, is that configuration management processes are not designed to manage systems or solutions, where dynamic updates can be applied whether or not done by the customer.

This is a topic to solve for the modern Connected Car (system) or Connected Car Sharing (solution)

For that reason, I am inquisitive to learn more from Martijn Dullaart’s presentation at the upcoming PLM Roadmap/PDT conference. The title of his session: The next disruption please …

In his abstract for this session, Martijn writes:

From Paper to Digital Files brought many benefits but did not fundamentally impact how Configuration Management was and still is done. The process to go digital was accelerated because of the Covid-19 Pandemic. Forced to work remotely was the disruption that was needed to push everyone to go digital. But a bigger disruption to CM has already arrived. Going model-based will require us to reexamine why we need CM and how to apply it in a model-based environment. Where, from a Configuration Management perspective, a digital file still in many ways behaves like a paper document, a model is something different. What is the deliverable? How do you manage change in models? How do you manage ownership? How should CM adopt MBx, and what requirements to support CM should be considered in the successful implementation of MBx? It’s time to start unraveling these questions in search of answers.

One of the ideas I am currently exploring is that we need a new layer on top of the current configuration management processes extending the validation to software and services. For example, instead of describing every validated configuration, a company might implement the regular configuration management processes for its hardware.

Next, the systems or solutions in the field will report (or validate) their configuration against validation rules. A topic that requires a long discussion and more than this blog post, potentially a full conference.

Therefore I am looking forward to participating in the CIMdata/PDT FALL conference and pick-up the discussions towards a data-driven, model-based future with the attendees.  Besides CM, there are several other topics of great interest for the future. Have a look at the agenda here

 

Conclusion

A data-driven and model-based infrastructure still need to be combined with a coordinated, document-driven infrastructure.  Where the focus will be, depends on your company’s value proposition.

If we discuss hardware products, we should think PLM. When you deliver systems, you should perhaps talk SysML (or SLM). And maybe it is time to define Solution Lifecycle Management as the term for the future.

Please, share your thoughts in the comments.

 

So far, I have been discussing PLM experiences and best practices that have changed due to introducing electronic drawings and affordable 3D CAD systems for the mainstream. From vellum to PDM to item-centric PLM to manage product designs and manufacturing specifications.

Although the technology has improved, the overall processes haven’t changed so much. As a result, disciplines could continue to work in their own comfort zone, most of the time hidden and disconnected from the outside world.

Now, thanks to digitalization, we can connect and format information in real-time. Now we can provide every stakeholder in the company’s business to have almost real-time visibility on what is happening (if allowed). We have seen the benefits of platformization, where the benefits come from real-time connectivity within an ecosystem.

Apple, Amazon, Uber, Airbnb are the non-manufacturing related examples. Companies are trying to replicate these models for other businesses, connecting the concept owner (OEM ?), with design and manufacturing (services), with suppliers and customers. All connected through information, managed in data elements instead of documents – I call it connected PLM

Vendors have already shared their PowerPoints, movies, and demos from how the future would be in the ideal world using their software. The reality, however, is that implementing such solutions requires new business models, a new type of organization and probably new skills.

The last point is vital, as in schools and organizations, we tend to teach what we know from the past as this gives some (fake) feeling of security.

The reality is that most of us will have to go through a learning path, where skills from the past might become obsolete; however, knowledge of the past might be fundamental.

In the upcoming posts, I will share with you what I see, what I deduct from that and what I think would be the next step to learn.

I firmly believe connected PLM requires the usage of various models. Not only the 3D CAD model, as there are so many other models needed to describe and analyze the behavior of a product.

I hope that some of my readers can help us all further on the path of connected PLM (with a model-based approach). This series of posts will be based on the max size per post (avg 1500 words) and the ideas and contributes coming from you and me.

What is platformization?

In our day-to-day life, we are more and more used to direct interaction between resellers and services providers on one side and consumers on the other side. We have a question, and within 24 hours, there is an answer. We want to purchase something, and potentially the next day the goods are delivered. These are examples of a society where all stakeholders are connected in a data-driven manner.

We don’t have to create documents or specialized forms. An app or a digital interface allows us to connect. To enable this type of connectivity, there is a need for an underlying platform that connects all stakeholders. Amazon and Salesforce are examples for commercial activities, Facebook for social activities and, in theory, LinkedIn for professional job activities.

The platform is responsible for direct communication between all stakeholders.

The same applies to businesses. Depending on the products or services they deliver, they could benefit from one or more platforms. The image below shows five potential platforms that I identified in my customer engagements. Of course, they have a PLM focus (in the middle), and the grouping can be made differently.

Five potential business platforms

The 5 potential platforms

The ERP platform
is mainly dedicated to the company’s execution processes – Human Resources, Purchasing, Finance, Production scheduling, and potentially many more services. As platforms try to connect as much as possible all stakeholders. The ERP platform might contain CRM capabilities, which might be sufficient for several companies. However, when the CRM activities become more advanced, it would be better to connect the ERP platform to a CRM platform. The same logic is valid for a Product Innovation Platform and an ERP platform.  Examples of ERP platforms are SAP and Oracle (and they will claim they are more than ERP)

Note: Historically, most companies started with an ERP system, which is not the same as an ERP platform.  A platform is scalable; you can add more apps without having to install a new system. In a platform, all stored data is connected and has a shared data model.

The CRM platform

a platform that is mainly focusing on customer-related activities, and as you can see from the diagram, there is an overlap with capabilities from the other platforms. So again, depending on your core business and products, you might use these capabilities or connect to other platforms. Examples of CRM platforms are Salesforce and Pega, providing a platform to further extend capabilities related to core CRM.

The MES platform
In the past, we had PDM and ERP and what happened in detail on the shop floor was a black box for these systems. MES platforms have become more and more important as companies need to trace and guide individual production orders in a data-driven manner. Manufacturing Execution Systems (and platforms) have their own data model. However, they require input from other platforms and will provide specific information to other platforms.

For example, if we want to know the serial number of a product and the exact production details of this product (used parts, quality status), we would use an MES platform. Examples of MES platforms (none PLM/ERP related vendors) are Parsec and Critical Manufacturing

The IoT platform

these platforms are new and are used to monitor and manage connected products. For example, if you want to trace the individual behavior of a product of a process, you need an IoT platform. The IoT platform provides the product user with performance insights and alerts.

However, it also provides the product manufacturer with the same insights for all their products. This allows the manufacturer to offer predictive maintenance or optimization services based on the experience of a large number of similar products.  Examples of IoT platforms (none PLM/ERP-related vendors) are Hitachi and Microsoft.

The Product Innovation Platform (PIP)

All the above platforms would not have a reason to exist if there was not an environment where products were invented, developed, and managed. The Product Innovation Platform PIP – as described by CIMdata  -is the place where Intellectual Property (IP) is created, where companies decide on their portfolio and more.

The PIP contains the traditional PLM domain. It is also a logical place to manage product quality and technical portfolio decisions, like what kind of product platforms and modules a company will develop. Like all previous platforms, the PIP cannot exist without other platforms and requires connectivity with the other platforms is applicable.

Look below at the CIMdata definition of a Product Innovation Platform.

You will see that most of the historical PLM vendors aiming to be a PIP (with their different flavors): Aras, Dassault Systèmes, PTC and Siemens.

Of course, several vendors sell more than one platform or even create the impression that everything is connected as a single platform. Usually, this is not the case, as each platform has its specific data model and combining them in a single platform would hurt the overall performance.

Therefore, the interaction between these platforms will be based on standardized interfaces or ad-hoc connections.

Standard interfaces or ad-hoc connections?

Suppose your role and information needs can be satisfied within a single platform. In that case, most likely, the platform will provide you with the right environment to see and manipulate the information.

However, it might be different if your role requires access to information from other platforms. For example, it could be as simple as an engineer analyzing a product change who needs to know the actual stock of materials to decide how and when to implement a change.

This would be a PIP/ERP platform collaboration scenario.

Or even more complex, it might be a product manager wanting to know how individual products behave in the field to decide on enhancements and new features. This could be a PIP, CRM, IoT and MES collaboration scenario if traceability of serial numbers is needed.

The company might decide to build a custom app or dashboard for this role to support such a role. Combining in real-time data from the relevant platforms, using standard interfaces (preferred) or using API’s, web services, REST services, microservices (for specialists) and currently in fashion Low-Code development platforms, which allow users to combine data services from different platforms without being an expert in coding.

Without going too much in technology, the topics in this paragraph require an enterprise architecture and vision. It is opportunistic to think that your existing environment will evolve smoothly into a digital highway for the future by “fixing” demands per user. Your infrastructure is much more likely to end up congested as spaghetti.

In that context, I read last week an interesting post Low code: A promising trend or Pandora’s box. Have a look and decide for yourself

I am less focused on technology, more on methodology. Therefore, I want to come back to the theme of my series: The road to model-based and connected PLM. For sure, in the ideal world, the platforms I mentioned, or other platforms that run across these five platforms, are cloud-based and open to connect to other data sources. So, this is the infrastructure discussion.

In my upcoming blog post, I will explain why platforms require a model-based approach and, therefore, cause a challenge, particularly in the PLM domain.

It took us more than fifty years to get rid of vellum drawings. It took us more than twenty years to introduce 3D CAD for design and engineering. Still primarily relying on drawings. It will take us for sure one generation to switch from document-based engineering to model-based engineering.

Conclusion

In this post, I tried to paint a picture of the ideal future based on connected platforms. Such an environment is needed if we want to be highly efficient in designing, delivering, and maintaining future complex products based on hardware and software. Concepts like Digital Twin and Industry 4.0 require a model-based foundation.

In addition, we will need Digital Twins to reach our future sustainability goals efficiently. So, there is work to do.

Your opinion, Your contribution?

 

 

 

 

 

 

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.

 

One of my favorite conferences is the PLM Road Map & PDT conference. Probably because in the pre-COVID days, it was the best PLM conference to network with peers focusing on PLM practices, standards, and sustainability topics. Now the conference is virtual, and hopefully, after the pandemic, we will meet again in the conference space to elaborate on our experiences further.

Last year’s fall conference was special because we had three days filled with a generic PLM update and several A&D (Aerospace & Defense) working groups updates, reporting their progress and findings. Sessions related to the Multiview BOM researchGlobal Collaboration, and several aspects of Model-Based practices: Model-Based Definition, Model-Based Engineering & Model-Based Systems engineering.

All topics that I will elaborate on soon. You can refresh your memory through these two links:

This year, it was a two-day conference with approximately 200 attendees discussing how emerging technologies can disrupt the current PLM landscape and reshape the PLM Value Equation. During the first day of the conference, we focused on technology.

On the second day, we looked in addition to the impact new technology has on people and organizations.

Today’s Emerging Trends & Disrupters

Peter Bilello, CIMdata’s President & CEO, kicked off the conference by providing CIMdata observations of the market. An increasing number of technology capabilities, like cloud, additive manufacturing, platforms, digital thread, and digital twin, all with the potential of realizing a connected vision. Meanwhile, companies evolve at their own pace, illustrating that the gap between the leaders and followers becomes bigger and bigger.

Where is your company? Can you afford to be a follower? Is your PLM ready for the future? Probably not, Peter states.

Next, Peter walked us through some technology trends and their applicability for a future PLM, like topological data analytics (TDA), the Graph Database, Low-Code/No-Code platforms, Additive Manufacturing, DevOps, and Agile ways of working during product development. All capabilities should be related to new ways of working and updated individual skills.

I fully agreed with Peter’s final slide – we have to actively rethink and reshape PLM – not by calling it different but by learning, experimenting, and discussing in the field.

Digital Transformation Supporting Army Modernization

An interesting viewpoint related to modern PLM came from Dr. Raj Iyer, Chief Information Officer for IT Reform from the US Army. Rai walked us through some of the US Army’s challenges, and he gave us some fantastic statements to think about. Although an Army cannot be compared with a commercial business, its target remains to be always ahead of the competition and be aware of the competition.

Where we would say “data is the new oil”, Rai Iyer said: “Data is the ammunition of the future fight – as fights will more and more take place in cyberspace.”

The US Army is using a lot of modern technology – as the image below shows. The big difference here with regular businesses is that it is not about ROI but about winning fights.

Also, for the US Army, the cloud becomes the platform of the future. Due to the wide range of assets, the US Army has to manage, the importance of product data standards is evident.  – Rai mentioned their contribution and adherence to the ISO 10303 STEP standard crucial for interoperability. It was an exciting insight into the US Army’s current and future challenges. Their primary mission remains to stay ahead of the competition.

Joining up Engineering Data without losing the M in PLM

Nigel Shaw’s (Eurostep) presentation was somehow philosophical but precisely to the point what is the current dilemma in the PLM domain.  Through an analogy of the internet, explaining that we live in a world of HTTP(s) linking, we create new ways of connecting information. The link becomes an essential artifact in our information model.

Where it is apparent links are crucial for managing engineering data, Nigel pointed out some of the significant challenges of this approach, as you can see from his (compiled) image below.

I will not discuss this topic further here as I am planning to come back to this topic when explaining the challenges of the future of PLM.

As Nigel said, they have a debate with one of their customers to replace the existing PLM tools or enhance the existing PLM tools. The challenge of moving from coordinated information towards connected data is a topic that we as a community should study.

Integration is about more than Model Format.

This was the presentation I have been waiting for. Mark Williams from Boeing had built the story together with Adrian Burton from Airbus. Nigel Shaw, in the previous session, already pointed to the challenge of managing linked information. Mark elaborated further about the model-based approach for system definition.

All content was related to the understanding that we need a  model-based information infrastructure for the future because storing information in documents (the coordinated approach) is no longer viable for complex systems. Mark ‘slide below says it all.

Mark stressed the importance of managing model information in context, and it has become a challenge.

Mark mentioned that 20 years ago, the IDC (International Data Corporation) measured Boeing’s performance and estimated that each employee spent 2 ½ hours per day. In 2018, the IDC estimated that this number has grown to 30 % of the employee’s time and could go up to 50 % when adding the effort of reusing and duplicating data.

The consequence of this would be that a full-service enterprise, having engineering, manufacturing and services connected, probably loses 70 % of its information because they cannot find it—an impressive number asking for “clever” ways to find the correct information in context.

It is not about just a full indexed search of the data, as some technology geeks might think. It is also about describing and standardizing metadata that describes the models. In that context, Mark walked through a list of existing standards, all with their pros and cons, ending up with the recommendation to use the ISO 10303-243 – MoSSEC standard.

MoSSEC standing for Modelling and Simulation information in a collaborative Systems Engineering Context to manage and connect the relationships between models.

MoSSEC and its implication for future digital enterprises are interesting, considering the importance of a model-based future. I am curious how PLM Vendors and tools will support and enable the standard for future interoperability and collaboration.

Additive Manufacturing
– not as simple as paper printing – yet

Andreas Graichen from Siemens Energy closed the day, coming back to the new technologies’ topic: Additive Manufacturing or in common language 3D Printing. Andreas shared their Additive Manufacturing experiences, matching the famous Gartner Hype Cycle. His image shows that real work needs to be done to understand the technology and its use cases after the first excitement of the hype is over.

Material knowledge was one of the important topics to study when applying additive manufacturing. It is probably a new area for most companies to understand the material behaviors and properties in an Additive Manufacturing process.

The ultimate goal for Siemens Energy is to reach an “autonomous” workshop anywhere in the world where gas turbines could order their spare parts by themselves through digital warehouses. It is a grand vision, and Andreas confirmed that the scalability of Additive Manufacturing is still a challenge.

For rapid prototyping or small series of spare parts, Additive Manufacturing might be the right solution. The success of your Additive Manufacturing process depends a lot on how your company’s management has realistic expectations and the budget available to explore this direction.

Conclusion

Day 1 was enjoyable and educational, starting and ending with a focus on disruptive technologies. The middle part related to data the data management concepts needed for a digital enterprise were the most exciting topics to follow up in my opinion.

Next week I will follow up with reviewing day 2 and share my conclusions. The PLM Road Map & PDT Spring 2021 conference confirmed that there is work to do to understand the future (of PLM).

 

Last summer, I wrote a series of blog posts grouped by the theme “Learning from the past to understand the future”. These posts took you through the early days of drawings and numbering practices towards what we currently consider the best practice: PLM BOM-centric backbone for product lifecycle information.

You can find an overview and links to these posts on the page Learning from the past.

If you have read these posts, or if you have gone yourself through this journey, you will realize that all steps were more or less done evolutionarily. There were no disruptions. Affordable 3D CAD systems, new internet paradigms (interactive internet),  global connectivity and mobile devices all introduced new capabilities for the mainstream. As described in these posts, the new capabilities sometimes created friction with old practices. Probably the most popular topics are the whole Form-Fit-Function interpretation and the discussion related to meaningful part numbers.

What is changing?

In the last five to ten years, a lot of new technology has come into our lives. The majority of these technologies are related to dealing with data. Digital transformation in the PLM domain means moving from a file-based/document-centric approach to a data-driven approach.

A Bill of Material on the drawing has become an Excel-like table in a PLM system. However, an Excel file is still used to represent a Bill of Material in companies that have not implemented PLM.

Another example, the specification document has become a collection of individual requirements in a system. Each requirement is a data object with its own status and content. The specification becomes a report combining all valid requirement objects.

Related to CAD, the 2D drawing is no longer the deliverable as a document; the 3D CAD model with its annotated views becomes the information carrier for engineering and manufacturing.

And most important of all, traditional PLM methodologies have been based on a mechanical design and release process. Meanwhile, modern products are systems where the majority of capabilities are defined by software. Software has an entirely different configuration and lifecycle approach conflicting with a mechanical approach, which is too rigid for software.

The last two aspects, from 2D drawings to 3D Models and Mechanical products towards Systems (hardware and software), require new data management methods.  In this environment, we need to learn to manage simulation models, behavior models, physics models and 3D models as connected as possible.

I wrote about these changes three years ago:  Model-Based – an introduction, which led to a lot of misunderstanding (too advanced – too hypothetical).

I plan to revisit these topics in the upcoming months again to see what has changed over the past three years.

What will I discuss in the upcoming weeks?

My first focus is on participating and contributing to the upcoming PLM Roadmap  & PDS spring 2021 conference. Here speakers will discuss the need for reshaping the PLM Value Equation due to new emerging technologies. A topic that contributes perfectly to the future of PLM series.

My contribution will focus on the fact that technology alone cannot disrupt the PLM domain. We also have to deal with legacy data and legacy ways of working.

Next, I will discuss with Jennifer Herron from Action Engineering the progress made in Model-Based Definition, which fits best practices for today – a better connection between engineering and manufacturing. We will also discuss why Model-Based Definition is a significant building block required for realizing the concepts of a digital enterprise, Industry 4.0 and digital twins.

Another post will focus on the difference between the digital thread and the digital thread. Yes, it looks like I am writing twice the same words. However, you will see based on its interpretation, one definition is hanging on the past, the other is targeting the future. Again here, the differentiation is crucial if the need for a maintainable Digital Twin is required.

Model-Based Systems Engineering (MBSE) in all its aspects needs to be discussed too. MBSE is crucial for defining complex products. Model-Based Systems Engineering is seen as a discipline to design products. Understanding data management related to MBSE will be the foundation for understanding data management in a Model-Based Enterprise. For example, how to deal with configuration management in the future?

 

Writing Learning from the past was an easy job as explaining with hindsight is so much easier if you have lived it through. I am curious and excited about the outcome of “The Future of PLM”. Writing about the future means you have digested the information coming to you, knowing that nobody has a clear blueprint for the future of PLM.

There are people and organizations are working on this topic more academically, for example read this post from Lionel Grealou related to the Place of PLM in the Digital Future. The challenge is that an academic future might be disrupted by unpredictable events, like COVID, or disruptive technologies combined with an opportunity to succeed. Therefore I believe, it will be a learning journey for all of us where we need to learn to give technology a business purpose. Business first – then technology.

 

No Conclusion

Normally I close my post with a conclusion. At this moment. there is no conclusion as the journey has just started. I look forward to debating and learning with practitioners in the field. Work together on methodology and concepts that work in a digital enterprise. Join me on this journey. I will start sharing my thoughts in the upcoming months

 

 

 

After the first episode of “The PLM Doctor is IN“, this time a question from Helena Gutierrez. Helena is one of the founders of SharePLM, a young and dynamic company focusing on providing education services based on your company’s needs, instead of leaving it to function-feature training.

I might come back on this topic later this year in the context of PLM and complementary domains/services.

Now sit back and enjoy.

Note: Due to a technical mistake Helena’s mimic might give you a “CNN-like” impression as the recording of her doctor visit was too short to cover the full response.

PLM and Startups – is this a good match?

 

Relevant links discussed in this video

Marc Halpern (Gartner): The PLM maturity table

VirtualDutchman: Digital PLM requires a Model-Based Enterprise

 

Conclusion

I hope you enjoyed the answer and look forward to your questions and comments. Let me know if you want to be an actor in one of the episodes.
The main rule: A single open question that is puzzling you related to PLM.

It Is 2021, and after two weeks’ time-out and reflection, it is time to look forward. Many people have said that 2020 was a “lost year,” and they are looking forward to a fresh restart, back to the new normal. For me, 2020 was the contrary of a lost year. It was a year where I had to change my ways of working. Communication has changed, digitization has progressed, and new trends have become apparent.

If you are interested in some of the details, watch the conversation I had with Rob Ferrone from QuickRelease, just before Christmas: Two Santas looking back to 2020.

It was an experiment with video, and you can see there is a lot to learn for me. I agree with Ilan Madjar’s comment that it is hard to watch two people talking for 20 minutes. I prefer written text that I can read at my own pace, short videos (max 5 min), or long podcasts that I can listen to, when cycling or walking around.

So let me share with you some of the plans I have for 2021, and I am eager to learn from you where we can align.

PLM understanding

I plan a series of blog posts where I want to share PLM-related topics that are not necessarily directly implemented in a PLM-system or considered in PLM-implementations as they require inputs from multiple sources.  Topics in this context are: Configuration Management, Product Configuration Management, Product Information Management, Supplier Collaboration Management, Digital Twin Management, and probably more.

For these posts, I will discuss the topic with a subject matter expert, potentially a vendor or a consultant in that specific domain, and discuss the complementary role to traditional PLM. Besides a blog post, this topic might also be more explained in-depth in a podcast.

The PLM Doctor is in

Most of you might have seen Lucy from the Charley Brown cartoon as the doctor giving advice for 5¢. As an experiment, I want to set up a similar approach, however, for free.

These are my conditions:

  • Only one question at a time.
  • The question and answer will be published in a 2- 3 minute video.
  • The question is about solving a pain.

If you have such a question related to PLM, please contact me through a personal message on LinkedIn, and I will follow-up.

PLM and Sustainability

A year ago, I started with Rich McFall, the PLM Green Global Alliance.  Our purpose to bring people together, who want to learn and share PLM-related practices, solutions,  ideas contributing to a greener and more sustainable planet.

We do not want to compete or overlap with more significant global or local organizations, like the Ellen McArthur Foundation or the European Green Deal.

We want to bring people together to dive into the niche of PLM and its related practices.  We announced the group on LinkedIn; however, to ensure a persistent referential for all information and interactions, we have launched the website plmgreenaliance.com.

Here I will moderate and focus on PLM and Sustainability topics. I am looking forward to interacting with many of you.

PLM and digitization

For the last two years, I have been speaking and writing about the gap between current PLM-practices, based on shareable documents and files and the potential future based on shareable data, the Model-Based Enterprise.

Last year I wrote a series of posts giving insights on how we reached the current PLM-practices. Discovering sometimes inconsistencies and issues due to old habits or technology changes. I grouped these posts on a single blog page with the title:  Learning from the past.

This year I will create a collection of posts focusing on the transition towards a Model-Based Enterprise. Probably the summary page will be called: Working towards the future currently in private mode.

Your feedback

I am always curious about your feedback – to understand in which kind of environment your PLM activities take place. Which topics are unclear? What am I missing in my experience?

Therefore, I created a small anonymous survey for those who want to be interacting with me. On purpose, the link is at the bottom of the post, so when you answer the survey, you get my double appreciation, first for reaching the end of this post and second for answering the survey.

Take the survey here.

Conclusion

Most of us will have a challenging year ahead of us. Sharing and discussing challenges and experiences will help us all to be better in what we are doing. I look forward to our 2021 journey.

Translate

Email subscription to this blog

Categories

%d bloggers like this: