Ever heard of an engineer who liked (never mind enjoyed!) using a PLM solution? I didn’t think so. As they say—the relationship is “complicated.” But the consequences can be devastatingly costly to a company as exemplified by the GM ignition key debacle from several years ago. True, creating a fob eliminated this problem, but the core issue of the engineer finding it “cumbersome” to route a change request via PLM remains. BTW, “fob” is not an acronym, it’s a word dating back to 1600s, check it out!
So why is this so complicated? My theory is that it’s because each team has a different purpose. Engineers do things to meet the stakeholder requirements and that requires plenty of creative freedom—the basic focus is on design intent. PLM does things to enable manufacturing, and that needs a rigorous configuration management—the basic focus is on BOM structure. And because of that, the formality of a “change” is different between the two environments. I had this discussion at one of the OMG (Object Management Group) meetings some time age when we were discussing the nature of a revision in the context of SysML 2.0 and how that relates to PLM. Here’s a related graphic:
The graphic was used in the context of a MBSE discussion, but it applies to all engineering domains. Note that I purposely outlined identical flows for changes in engineering and PLM, but I did differentiate the formality of each by calling one a “version” and the other a “revision.” The labels are not that important. The fact that they ARE different is extremely relevant because of who owns the data and where the data resides.
Engineers (and not only Systems Engineers) use Systems Thinking, (the gray area in the above graphic) while exploring design space, by applying many different “versions” of system contexts, requirement parameters, variability of features and options, functional and logical breakdowns, simulation studies, cross-domain optimizations, etc. They own the data, and it resides in the files managed by their authoring tools. At some point design is finalized and becomes a formal “version” in PLM—the point at which PLM takes the ownership of the data and maps it to its internal data model. And then engineering moves on to the next design. See the problem? All of the knowledge gained from Systems Thinking (again, the gray background) becomes lost and many of the same explorations must be repeated over and over during the next designs. That translates into missed market opportunities and significant costs that many C-Level individuals aren’t even aware of.
Now, wouldn’t it be nice if a Digital Thread also maintained traceability to these past Systems Thinking explorations (all results—good and bad) so that they would not have to be redone for the next design—regardless of who owns the data and where it resides? And it could also be equally accessible by engineers during their design explorations as well as PLM users during their change management (impact analysis!) and related activities?
Aras already took a step in that direction as described in a recent engineering.com article. But there is a next step that will drastically simplify the whole situation. Aras’ industrial low-code platform, with its full functionality available on the cloud, is ready to connect with the engineering authoring tools that are also destined to move to the cloud. That will eliminate the need for PLM connectors as we know it because those authoring tools will no longer depend on their native files, but rather on native data structures in the cloud. This means that PLM/tool integration will be based on pervasive data federation strictly within the cloud. It also means that this integration will allow PLM to monitor what is being changed by engineering as it is being changed—dynamically—plus impose a permission model tied to the lifecycle management that defines what constitutes a “version” and what constitutes a “revision.” The engineers will never have to think about what to disclose and what not to disclose to PLM because PLM in the cloud will potentially see everything that is changing in a tool in the cloud (think collaboration on Google documents). This in turn means that the Digital Thread can have access to all “revisions,” and their history, automatically and in real time. This means that the results of engineering explorations will not be lost and will be traceable for reuse in other projects.
That is the essence of radical simplification, regardless of the complexity of the underlying data. Systems Thinking across infrastructure and during design—everybody wins—and engineers start enjoying the benefits of a PLM.
For more information on Systems Thinking, visit our website.