Model-based problems and emperor’s new clothes

Model-based problems and emperor’s new clothes

I thought it was only confused by Model-Based approach and terminology. I published Model-based confusion in 3D CAD and PLM article earlier this year and I’ve got some kind of mixed feedback. Model is a very powerful word. But it got overused and confused people looking for technology to help in everyday tasks like design, bill of materials, production planning, purchasing parts.

I think, I’m not alone with my confusion about model-based approach. My attention was caught by engineering.com article It’s Time to Clean Up Our Model-Based Problem, President of CIMdata Inc. brings few interesting points and… challenges about the future of model-based terminology.

My favorite part is MBD x2 and MBE x2 and MBSE… You can ask me what is that? Yeah… this is how model-based terminology looks like today – Model-Based Definition, Model-Based Design, Model-Based Engineering and Model-Based Enterprise. Look at the picture – it is better than thousand words.

CIMdata calls for a challenge – to agree on common sense definition without much overlap. Here is a passage from the conclusion.

For the good of innovative product development and the beefing up of enterprise competitiveness, CIMdata believes it is time that everyone responsible for MBx takes an unbiased look at the gains to be won from PLM enablement.  In turn, PLM is a key part of digitalization and the sweeping transformations accompanying digitalization, all of which are inevitable.

Unless and until agreement is reached on the need for change in MBx methodologies and associated terminology, they will continue to be a stumbling block.   Knowledgeable academics, government standards committees, experts from industries using MBx, and people marketing MBx need to cross some boundaries and put their heads together.  If in fact MBx is getting in the way of platformization—and CIMdata is convinced this is so—the innovation of manufactured products in the defense, aerospace, and other industries may slowly come to a halt.

Confucius pointed out 2,500 years ago that wisdom begins with calling things by their right names.  PLM enablement of MBx begins with names and labels everyone understands and can agree on.

The discussion made me think about problems and solutions dilemma. Einstein is quoted as having said that if he had one hour to save the world he would spend fifty-five minutes defining the problem and only five minutes finding the solution.

I found that very often in our work we tend to come with solution (and names) before defining the problem we are going to solve. Coming with solution brings us to the point we are already doing something rewarding and it makes us feel that we already figured out what to do. Especially if we come with such smart and powerful word as “model”. How possible things can go wrong if they are based on a model?

But problems are much harder to articulate. What is the problem of the engineers trying to pass information to manufacturing planners and stuck in the middle with a wrong Excel file? We might not know what is the problem, but if we tell them to bring “single model of truth”, it feels like we are solving the problem already. Very often we prefer to stick with our solution that taking a risk and learn more about the problem.

So, here is my take on CIMdata challenge. Manufacturing companies don’t have model-based problem. Manufacturing companies have many other problems to solve – how to get design right, to to prove that product will perform according to expectations, how to prove that product actually can be manufactured with predicted cost and time, how to simulate future product in real time environment and to insure product is sustainable…

We need to go deeper to understand what problem you want to solve. Spent time on this and then come with the solution. I’m sure model is needed to solve many problems I mentioned above.  But when we come to the definition of a problem, we can be more specific about a model. And if “database model” is a replacement of “file models”, it is fine. If replacing files with central database is the solution, then we can call it in a such way. If instant data sharing is a solution to a problem of synchronizing data every 24 hours, then we call it in a such way as well.

Solution first mindset feels more comfortable. But, I’ve seen how focusing on solutions and even worst on how to call it, can be damaging and doesn’t give us the best odds for success. MBD, MBE, MBSE… what problems these solutions are supposed to solve? Are those problems real or it is just a marketing name to sell what vendors have? What value is behind these names. Maybe model-based is PLM version of  The emperor’s New Clothes fairy tale? In such a way model-based problem is a situation where no one believes in model-based, but everyone believes the everyone else believes in model-based.  Or alternatively, everyone is ignorant to whether model-based has a value or not, but believes that everyone else is not ignorant.

What is my conclusion?  PLM industry should take a deep breath and look into problems to be solved in manufacturing companies. Then adjust the solutions and terminology based on problems and values. I’d like to see PLM industry focus on how to provide definition explaining value of products and not hiding behind confusing buzzwords. It seems to me in most cases “model-based” is used to explain that information is stored in 3D CAD systems and databases and is used in product development processes. But hey,  that was an idea of PLM from the beginning. So, maybe “model-based” approach is a vaporware? Who knows… Just my thoughts…

Best, Oleg

Want to learn more about PLM? Check out my new PLM Book website.

Disclaimer: I’m co-founder and CEO of OpenBOM developing cloud based bill of materials and inventory management tool for manufacturing companies, hardware startups and supply chain. My opinion can be unintentionally biased.

Share

Share This Post

  • Pingback: GHZ Partners | IT Services, Software()

  • Lika2know

    Oleg & Readers –
    I would encourage you to pull back a bit from the focus on manufacturing as the main motivator for model-based-whatever. For example, linking systems engineering models (requirements, architectures) to design engineering work is significant for its potential to produce valid designs sooner and with fewer problems not discovered until integration time. And, it also lends itself to the ability to support more adaptable manufacturing as tracing from manufacturing models back to design models and then back to analyses and systems representations can provide the illusive “intent” insight. Having an understanding of the drivers and analysis results will make it easier to substitute materials and processes to support manufacturing, and to support greater customization.

    We are suffering from a surfeit of overlapping acronyms, that is true. But, what we don’t need is to move to manufacturing something that can’t do the job, is bad for the people doing the manufacturing, or bad for the environment. PLM is a big enough tent to hold abstract (product or system) models as well as models that are intended from their creation to be turned into something concrete.

  • beyondplm

    Lika2know, thanks for your comment and insight! I agree, we are suffering from acronyms. While I agree, “models” are important and connect system engineering, requirements, etc. is absolutely important. But, I thought that was promised by some PLM vendors a decade ago. PLM concepts are beautiful and important, but unfortunately hard and sometimes oversold. Do you think “model-driven whatever” will solve the problem of complexity? I don’t think so. We must find a better way :)>