Paweł Z. Chądzyński さんのアクティビティ

The Future of Product Innovation and PLM – Abstraction, Digital Threads, and Artificial Intelligence

Paweł Z. Chądzyński — Thu, 21 Mar 2024 10:35:00 GMT

PLM solutions traditionally manage what a product is (aka design data) without much understanding of what the product does (aka design intent). Design data configuration management is critical for keeping track of product variants, releases, changes, and the transformation of the engineering Bill of Materials (eBOM) to the manufacturing Bill of Materials (mBOM). However, BOM management does not have a significant role in determining the product's purpose. That lack of design intent context, of course, becomes a significant issue when designing ever-complex products characterized by:

A tsunami of requirements and regulations well beyond the product’s core functionality and stakeholder specifications, such as country-specific regulatory compliance or green initiatives
The increasing necessity to design the product as part of a more extensive system – i.e., systems with increasingly complex system-to-system behaviors
An accelerating drive towards software-defined products because of pervasive connectivity, SaaS models for delivering product functionality via online services, and over-the-air update capabilities
Ubiquitousness and intelligence of physical and virtual sensors everywhere within and around the product
And more…

Abstraction as a way of expressing design intent

The ability to abstract product complexity to a higher representation level is why Model Based Systems Engineering (MBSE) data is so important. MBSE also defines design intent critical to understanding the purpose of design data. That MBSE abstraction is precisely what "reduces" the complexity by focusing on the functional breakdown of a product (I’m simplifying here a bit). This allows the product’s functions to be defined and optimized before being allocated for implementation across mechanical, software, electronic, and electrical domains. I’m convinced this is how MBSE is also slowly transforming product design methodologies and tools within the individual domains, which eventually leads to a BOM managed by PLM. That is precisely what happened in software and semiconductor design when their design complexities became unmanageable.

Consider how software engineers today use high-level programming languages to design on a functional level with little need to understand how that gets compiled into an assembly language or a CPU-specific instruction set (an implementation domain!). It is the same with chip designers using hardware description languages (HDL) such as Verilog or VHDL to design on a functional/logical level without being concerned about how the code gets synthesized to a register-transfer logic (RTL) or how integrated circuit (IC) foundries generate photoimaging masks from it (also an implementation domain!). Software and semiconductor designers can achieve today’s design efficiency by elevating design complexity to a functional level.

Obviously, in the case of PLM this focus on functional representation does not diminish the importance of the implementation domains collaborating to optimize the overall result using PLM, nor does it diminish the value of managing a BOM in PLM. But I do see MBSE slowly changing the focus point for design engineers towards systems thinking with every design engineer using tools capable of creating a functional abstraction in every domain. It’s similar to the role of electronic schematics as a functional definition before laying out a printed circuit board (PCB). I predict that the same will happen to all product domains managed by PLM, allowing PLM to understand why a product is designed the way it is. In the immortal words of the Borg in Star Trek: “Resistance is futile.”

Digital Thread to support the future of product innovation

Making MBSE part of a PLM-managed Digital Thread, and therefore providing the design intent of a product within PLM, is already a reality and one of the results of Digital Transformation. This is either developed organically as part of an internal strategy or is enforced as part of industry-wide initiatives like The US Department of Defense INSTRUCTION 5000.97. Digital Thread, which spans both sides of the engineering V model, is the second requirement for the future of product innovation and PLM. To learn more, check out my previous blog, Let's Talk About the Model-Based Enterprise, Digital Threads, and Relationships.

One more note. A PLM-managed Digital Thread does not need to contain everything because the sheer amount of data would be overwhelming. It simply must know how to find it. The recent trend for implementing PLM services in the cloud addresses this since now many data sources can be accessed via cloud-based Data as a Service (DaaS).

Artificial Intelligence (AI) as a partner to engineering

Can PLM assist engineers in designing future complex products instead of “just” tracking what was designed? I’m convinced that it can, but only if engineering design methodologies and tools evolve in a way that makes PLM an interactive engineering “advisor”, or a “co-pilot”. The elevation of functional abstraction and Digital Thread with evolving relationships discussed above are vital to enabling AI to do just that.

Exposing design intent in PLM has many Digital Thread benefits throughout a product’s lifecycle, and many involve the ability to generate a Digital Twin in context instead of having to physically go to the asset in the field. For example, it can be used to analyze the impact of a proposed product update, or leverage IoT data in preventive maintenance, or wirelessly enable/disable services in specific product variants, and others. AI can certainly help by enabling more intelligent searches or generating task-specific reports from very complex data or translating requirements and regulations between languages without losing the context. However, none of that is genuinely transformational in terms of assisting engineers in creating the next design.

Imagine instead a Digital Thread that maintains traceability to ALL previous design solutions that worked or did not work, ALL previous product platforms and their variants, the history of ALL simulations, and ALL IoT data interpretations via Digital Twins of the physical assets. Imagine that the same Digital Thread maintains traceability to functional abstractions of all these solutions, products, and variants. Imagine also that these functional abstractions are modeled using the same system engineering methodology, ontology, and the structured model of data and relationships that can evolve over time. By being the “same” I mean that they can be compared without a loss of context.

Now imagine how the co-pilot would work:

A systems engineer asks PLM for feedback on how a specific set of requirements and functions can be implemented based on the tracked history
The PLM AI service returns a list of past solutions that succeeded or failed with an ability to drill down into the details of engineering or market success and failures
Using AI reasoning, the engineer would compare a set of solutions that succeeded to see what the differences there were between them
The engineer seeds the new design using the selected solution as a template
Finally, the engineer uses the AI inference to see how likely the new design is to succeed or fail due to technology or market issues
... or something like that, use your imagination!

Thinking about PLM-managed Digital Thread strategies without considering the never-ending rise in future product complexities spells big trouble. This is because one risks a Digital Thread implementation that overfocusses on traceability for sole traceability's sake but does not improve the understanding of its meaning. This may not be a problem in mechanically dominated products where the view of a physical part is sufficient to understand its purpose but is likely a dead-end when products become software and silicon-driven (and where a physical view of the underlying 3D transistor technology is quite useless). I’m exaggerating, of course, to make a point.

That’s where the reimagining of future product innovation comes in. The same PLM platform used today to connect the dots between everything that represents a product can, in the future, assist engineers in generating new innovative designs with AI. After all, it’s your data. This is part of Engineering 5.0 (related to Industry 5.0) discussed by Rob McAveney, Aras CTO, during his recent ACE 2024 keynote address.

Why Digital Transformation in PLM Depends on a Robust Digital Thread

Paweł Z. Chądzyński — Tue, 19 Dec 2023 11:35:00 GMT

Most manufacturing organizations have some form of active digital transformation project to stay relevant in the current economy. Challenges stemming from legacy systems and processes often constrain these efforts.

One challenge is enabling an effective collaboration that allows one to find, access, and have confidence in the accuracy of digital information. This is important because collaboration based on information served up in context, across the enterprise, and throughout the lifecycle leads to more timely product launches, improved quality, increased innovation, and lower operating costs. Effective collaboration requires an effective Digital Thread, an essential foundation for boosting organizational efficiency across teams, groups, and the enterprise.

PLM's historical challenges

Early product lifecycle management (PLM) processes were primarily focused on mechanical designs. Their lifecycle management of mechanically oriented BOM structures formed an early implementation of a Digital Thread, but only for a limited data type. The legacy PLM systems did not span the many other engineering disciplines—systems, simulation, electronics, electrical, and software.

Furthermore, in many companies, individual departments and disciplines within each department operate in their specific tool silos, even if the company is standardized on a particular PLM platform. Departmental focus is on their design responsibility rather than working with others to optimize across disciplines because of legacy processes and because of the limits of the legacy PLM systems. A lack of cohesion between all engineering disciplines in this early form of Digital Thread inhibited the development of highly complex products.

To better understand the problem, consider how modern electric vehicle manufacturers optimize driving range using regenerative braking. In older vehicles, the braking system was largely independent of other vehicle subsystems and designed in a silo. That is no longer the case; every modern automobile subsystem depends significantly on other functions.

In contrast, new electric-vehicle startups have had success in cross-discipline collaboration. Why? Because they had no legacy products and therefore they were not constrained by legacy disconnected silos of knowledge, data, and process. For example, their strategic embrace of systems modeling and MBSE allowed them to identify and understand interdependencies that otherwise would be missed. Today, traditional automakers adopt similar approaches to become more competitive by recognizing the value of cross-discipline collaboration and systems-engineering concepts.

The creation of a Digital Thread

To improve efficiency and build better products, companies need to expose and share information between silos by embracing traceability between them so that information can be shared securely between internal departments, partners, and suppliers across the entire product lifecycle. That can only be accomplished by creating a modern Digital Thread that enables connected flow across the silos of the product's design intent (the Why), design data (the What), and design processes (the How) - in context. This requires mechanisms to connect existing systems and fill the gaps between them. This can be a challenge, especially when legacy systems, tools and data repositories need modernizing.

A truly effective Digital Thread must provide proper data and process context specific to the particular stage of a lifecycle. The continuous flow of information in context can provide vital insights to guide decisions at every stage of the product lifecycle, enhancing collaboration and communication and speeding up the development of better products.

Best practices

There are a few best practices to remember while building your modern Digital Thread. To start, generating, managing, and connecting related information across a product's lifecycle depends on a company's existing IT landscape. There is no one-size-fits-all software solution for it. It is wise to avoid beginning your journey by identifying a list of specific goals before evaluating software solutions. Consider the process first, including how external partners and suppliers interact with your data. In addition, consider the fact that the relationships that connect artifacts in a Digital Thread are much more than "just" links. To facilitate traceability in context, they must reflect the level of maturity that includes their own semantics, directionality, history, revisions, lifecycle states, and other indicators.

Remember – you cannot build a Digital Thread in one step. An incremental and iterative approach is warranted—start small and deliver incremental value over time. Don't wait for the next budget cycle to get started. Instead, make a series of small, targeted investments that deliver value to the organization.

Prioritizing openness and interoperability is essential in building your Digital Thread. You can't predict which tools you will need to include in your Digital Thread in the future. Mergers, acquisitions, and evolving supplier networks can affect your IT ecosystem unpredictably. Committing to one software vendor's ecosystem could severely hamper your ability to adapt and adjust to business changes. Last, remember that the Digital Thread is a moving target. Accept that a digital-thread journey is never complete in an evolving world of technology. That should not prevent you from getting started, as even a partial Digital Thread provides significant business value.

For more information on Aras Digital Thread solutions, visit aras.com.

Aras Variant Management is Getting Better and Better

Paweł Z. Chądzyński — Wed, 16 Aug 2023 21:15:00 GMT

A while ago, I wrote a blog on why Variant Management needs to be considered way before 150% BOM (Bill of Materials) is reached for an already-designed product that becomes available. The key to that is the reuse of the variant logic on distinctive design representations, including validation and comparison. That is exactly the architecture of the Aras Variant Management application. The separation between the variability logic and breakdown structure data models enables the use of both in any combination and at any phase of a product’s lifecycle.

Aras has just released a new set of Variant Management application capabilities that are worth commenting on. These features result from collaboration with the application users and their various underlying use cases. Let us have a quick look at each of the new capabilities.

Reusable Selection Sets

The new Selection Set capability allows users to save selected features and options under a unique name and reuse them later to support different use cases. This reduces the underlying 150% breakdown structures to a specific 100% variant of it in which the breakdown structure can be a physical BOM, a functional breakdown, document content, or a complex set of requirements:

A modified variability logic and/or breakdown structure
A new variability logic and/or breakdown structure, or
Any combination of the above

A Selection Set is automatically validated against the variability logic and breakdown structure it applies whenever it is reused. Any conflicts are automatically identified, and the user is provided with interactive guidance on how to resolve them. With an appropriate configuration of the Aras platform, Selection Sets use and change history can be traceable via the product’s digital thread throughout the product lifecycle.

Fig. 1: Validating a named Selection Set in a new context

The ability to reuse a specific configuration of the variability logic offers significant value to the product teams. It reduces errors, improves productivity, and encourages collaboration. This is because once variability logic is defined and validated, multiple users can leverage it in different contexts by selecting any combination of the related features and options when exploring a family of variants.

Reusable Usage Conditions

The new Usage Conditions capability allows us to save each condition under a unique name in order to use and reuse them later on any applicable assets within any breakdown structure. This allows the individual conditions to be defined and validated once, and then used repeatedly in configurations with other Usage Conditions.

Since Usage Conditions identify valid conditions when an asset (such as a part) can be used, the ability to identify them by name enables management and differentiation of global vs. local circumstances. This offers significant benefits when managing supply chain issues or market differentiation. The global condition can now be managed on an enterprise-wide basis, while the local conditions may be specific to a manufacturing plant or geographically narrow market opportunity.

Fig. 2: Identifying structures affected by a named Usage Condition

Named Usage Conditions make change management easier because they are versionable and traceable via the product’s Digital Thread. A good example of that is the where-used analysis service in the Aras platform that allows you to identify every configuration affected by a specific version of a condition or every configuration affected by a change in an existing condition.

Variant Matrix

Maintaining and debugging variability features, options, and rules for a product family is not easy. This is especially true when the separation of the variability logic and breakdown structures affects multiple representations of the product.

Fig. 3: Dynamically generated Variant Matrix

The Variant Matrix capability allows a user to review, validate, and compare multiple variants of multiple breakdown structures in bulk via a single UI (user interface). Since the number of valid combinations can be high, the user can control the scope of their analysis by selecting specific features and options that relate to the analysis. This improves productivity and significantly reduces the time needed to analyze multiple combinations of resolved or proposed variants.

Conclusion

The latest release of the Variant Management application improves users’ productivity and ease of use of the application. This helps manage the increasing complexity of today’s products by maintaining its focus on the various representations throughout the lifecycle of the product’s platform and its variants instead of limiting it to BOM only. To see a demonstration of the application and new capabilities click here. This release is a part of Aras’ ongoing product development process based on a four-month Agile release cycle, with details of each published here. Aras guarantees that all releases are compatible with the local configurations implemented by subscribers.

As with all Aras solutions, upgrading to the latest releases is without risk because Aras guarantees upwards compatibility via no-cost upgrade services for all subscribers. This is true for on-premise and cloud (Aras Enterprise SaaS) deployments.

Let's Talk About the Model-Based Enterprise, Digital Threads, and Relationships

Paweł Z. Chądzyński — Thu, 20 Jul 2023 12:10:00 GMT

Relationships and maturity – we all have something to say about that since we cannot function without them. It is how we live our private lives, raise our children, and succeed in our careers. It is important because, according to the thesaurus, the antonyms are incompetence and decline. But how do these concepts apply to Model-Based Enterprise and Digital Thread? It’s all about traceability.

The Digital Thread was recently the focus of CIMdata’s PLM Road Map & PDT North America 2023 event, the related Aerospace & Defense PLM Action Group report, and the AIAA position paper Digital Thread: Definition, Value and Reference Model. So, it is very much the center of attention for major industry players. This is unsurprising as it is a key element of the increasingly important Model-Based Enterprise strategy that extends beyond engineering. But there is an aspect of Digital Thread traceability that is rarely part of the discussion, yet that is critical to understanding if success is possible: the maturity of relationships.

This isn’t just another post about the Digital Thread; you will learn that something might be holding you back, and it is critically important to move your Digital Thread forward with the Model-Based Enterprise initiative.

Traceability drives the Model-Based Enterprise

Traceability in context (coupled with ease of navigation and visualization) is how the Digital Thread creates value, which is necessary for achieving the Model-Based Enterprise. This is because traceability in context is a much bigger concept than a library of URL-like links that connect elements between different models of a design. Traceability applies to the engineering and non-engineering parts of the Model-Based Enterprise and requires context. Its evolution looks like this:

Model-Based Definition (MBD) – It typically starts with MBD of 3D designs where documents are replaced with 3D models that hold all the data that defines a mechanical product.
Product Manufacturing Information (PMI) – 3D MBD models are then expanded with PMI, all the data needed to manufacture a mechanical product from the 3D model.
Model-Based Engineering (MBE acronym use #1!) – Meanwhile, product engineering embraces MBE (“E” for engineering) by creating connected RFLP (Requirements, Functional, Logical, Physical) representations for all product representations. This includes Model-Based Systems Engineering (MBSE), simulations, mechanical and electronic CAD, software Application Lifecycle Management (ALM), Validation & Verification, documentation, and others.
Industry 4.0 – At the same time, the entire manufacturing ecosystem starts transforming into Industry 4.0 by leveraging all engineering models from the previous steps and integrating such technologies as Digital Twins, Internet of Things (IoT), cloud computing and analytics, Artificial Intelligence (AI) with machine learning, and others.
Model-Based Enterprise (MBE acronym use #2!) – Finally, all of this allows organizations to slowly transform themselves into MBE (enterprise) where not only engineering and manufacturing ever-evolving but all people, processes, tools, and data (including partners and suppliers) become model-driven and everything becoming traceable via the Digital Thread.

The Model-Based Enterprise cannot be achieved unless Digital Thread traceability can be expressed in the context of the task at hand. A context that reflects the task, who is performing it, for what purpose, and under what conditions that may or may not be engineering specific. In other words, nobody wants to see, is able to benefit from, or can understand the entire Digital Thread all at once, especially when, sometime in the not-so-distant future, its traceability will include – well – everything. And that task-specific “context” is a key enabling characteristic of a successful Model-Based Enterprise.

The genesis of Digital Thread traceability in product design

Figure 1 shows how individual relationships within Digital Thread keep maturing in context. It starts at conception (top left) and continues through all abstractions (left), all physical designs (bottom), V&V and integration (right), manufacturing (top right), and the field (extended right).

Figure 1 – Engineering V Model

For example, in “engineering speak,” a relationship between a requirement and a part begins as “allocated” (V-left), matures to “satisfied by” (V-bottom), matures to “verified” against a specific part rev (V-right), and keeps maturing with the physical asset to reflect maintenance and upgrades (V-extended right).

Figure 2 shows why individual views of the Digital Thread must be generated in the context of the relationship maturity of the task at hand. That means that most of the relationships depicted here are irrelevant to that contextual view even though they are critical to full Digital Thread traceability. For example:

If I need to understand requirements (REQUIRED) then I need a view that shows their structure, decomposition, flow down, and perhaps change history and how it relates to the product (AS DESIGNED) – I do not need to see how they were allocated or satisfied at later lifecycle stages.
If I need to interpret a specific IoT data stream from a physical asset, I need a view that shows how the related requirement (REQUIRED) was verified with a simulation study (AS DESIGNED) performed against a specific product variant (AS BUILT) and its operational performance (AS OPERATED) and maintenance/upgrade history (AS SERVICED).

Figure 2 – The Digital Thread and Product Lifecycle

The genesis of Digital Thread Relationship Maturity Indicators

Based on my own experience, the concepts of traceability I just presented have not found their way into discussions of Digital Thread and a Model-Based Enterprise although hints of it can be found in the AIAA’s paper referenced above. Assuming that you probably haven’t thought this out either, consider this since this is how your Digital Thread will succeed in enabling a Model-Based Enterprise.

Figure 3 – Digital Thread and Relationship Maturity

Figure 3 depicts the maturity evolution of a single relationship that sets up traceability between two specific digital artifacts A and B. It shows how the maturity of that relationship evolves to reflect different states of the product lifecycle. The table below explains what is meant by this “maturity” and how maturity indicators allow that relationship to evolve.

Figure 3 Details	Comments
	The web of traceability between all digital assets including bills of material, parts, software, electronics, CAD models, documents, requirements, simulation and analysis data, verification and validation data, supplier specifications, technical data pack (TDP) contents, manufacturing process plans, inspection & test plans, quality records, service manuals, maintenance records, and many others.
	The initial maturity of a relationship is typically URL-like and sets up basic traceability between elements A and B. All we know at this point is that A is “somehow” related to B (not the other way around) and nothing else. Without other maturity indicators it has no context.
	Types of relationship maturity indicators depend on the business needs, examples: Bidirectionality, e.g., valid in both directions. Semantics, e.g., A is a “requirement,” and B is a “part.” Behavior, e.g., does not “float” to the latest generation of A or B but specifies a particular revision of each. History, e.g., how the current maturity evolved for each indicator. Notifications, e.g., release status for dashboards. Triggers, e.g., pushes revision of the A & B parts to the ERP system.
	Indicates the same relationship but now includes more maturity indicators.
	Indicates maturity of the same relationship needed for specific use cases, such as release to manufacturing.
	Indicates that specific relationship maturity applies to how individual views of the Digital Thread are dynamically generated without having to persist them.
	Indicates that the maturity of the relationship keeps evolving together with the operation, maintenance, and upgrades of the physical asset and forms the basis for generating Digital Twins in context as a navigable view of Digital Thread.

Bottom line: Relationship maturity is ever-evolving, possibly beyond the useful life of the asset itself because of reuse and sustainability. It also shows that the relationship evolves to be tool agnostic since the original design authoring tool may no longer be available.

And there we have it. While creating a massive library of URL-like links to set up some kind of traceability between digital elements of various models is useful (the “globe” in Figure 3), it is insufficient to drive toward a successful Model-Based Enterprise. For a Model-Based Enterprise to benefit from the traceability of everything-to-everything, all relationships within and between the various product, process, and organizational models must be capable of evolving relationship maturity indicators.

Conclusions

If you are intrigued by this blog and envision transforming your organization into a Model-Based Enterprise, then Aras Innovator® PLM platform should be on your list. The platform is the only PLM solution architected to model the Digital Thread relationship maturity indicators with a low-code modeling engine according to your current and emerging business needs. Aras customers start with the out-of-the-box (OOTB) functionality and use the modeling engine to evolve the platform in step with the internal transformation of people, processes, and tools towards the goal of a Model-Based Enterprise as outlined in the five steps above. There is no risk of getting stuck with incompatible implementations because Aras guarantees upwards compatibility via its no-cost upgrade services for all subscribers. This is true for on-premises and cloud (Aras Enterprise SaaS) deployments.

I encourage you to use the links cited above to learn more about the industry focus on the Digital Thread and judge how the concepts outlined above relate to it.

As to the maturity of relationships, I’ve been working on my specific relationship and its maturity for the last 45 years (!), and I’m told that there is so much left to do… Same challenge.

Does Variant Management Manage Just BOM? Think Again!

Paweł Z. Chądzyński — Thu, 01 Jun 2023 16:07:00 GMT

More products, fewer parts—this is the shortest characterization of the variant management business value. From a marketing and manufacturing perspective, that is very much true, and that is what CPQ (Configure, Price, Order) tools do: generate a 100% BOM (all parts of a variant) using a 150% BOM of a modularized product platform (all parts of all variants). But that only works if the variability logic and the resolved variants are already verified, something that CPQ tools cannot do because they only understand BOM structures. That verification involves (depending on the market, there may be other areas):

Functionality (that it does what is intended),
Compliance (that the right set of requirements is met),
Configuration (that the parts can work together),
Implementation (that all engineering domains are accounted for, ex: software),
Manufacturability (that it can be manufactured),
Documentation (that the content is configured correctly),
AND that all teams involved have the same understanding of what that variability is, including supply chain partners.

That multi-domain scope of variability logic is an increasing challenge for the industry faced with a need to deliver increasingly complex products. The inability to effectively manage it at all levels of product representation and at every stage of a product lifecycle directly impacts time to market, cost, CoQ (Cost of Quality), and team productivity.

At the core of the problem is the modularized product platform strategy where the individual elements (modules or subsystems) of the platform are designed, built, and manufactured by a multiplicity of internal and external teams which often do not communicate well, and which often have a limited understanding of the overall product.

For example, does:

… the software team responsible for the embedded code within an automotive control unit have any understanding of the mechanical interaction of the parts?
… a requirements team understand the impact of a specific requirement across the platform architecture and functionality?
… one team know how the other team is impacted by what they do?

Since the variability of a product platform has everything to do with how that platform is modularized, it is also directly connected to an efficient strategy of product variability. The two are, in fact, inseparable.

The Risks of a Modular Design

Recently I had the pleasure of talking with Prof. Patrick Hillberg at the CIMdata PLM Roadmap event focused on digital thread. Hillberg invested a lot of time in thinking through the process of platform modularization and how it can lead to unforeseen emergent properties with catastrophic consequences, see Better Products Need Better Cultures: The GM Ignition Switch Recall. While the paper does not focus on product variability, its focus on the platform modularization strategies is an eye-opener when thinking about validating product variability, quote: “Decomposition leads to dysfunctional cultures.” It is a long read but worth it. He concludes that in the GM case, life was lost because the airbags control disabled them based on the engine status instead of the vehicle velocity. The mechanical misbehavior of the ignition key acted as a trigger (the engine went off while the car was moving) and not the cause (airbags turned off because the engine turned off–but the car was still moving). The core issue was that the two functional modules were implemented in silos. This is not an argument against product platform strategy; it is an argument that module “silos” can and do lead to tragic consequences.

My point is that similarly to a team approach to a platform design where everybody (including suppliers) has the same understanding of the product’s design intent – variant strategy also needs to be a part of every step of the process and at every level of the engineering V model. It is the people and the process. This, in turn, means that the only effective variability strategy is the one that allows to explore, define, and verify the same variability logic against any product structure: requirements, functionality, architecture, module breakdown, manufacturing, documentation, and others. While the individual product representations have different breakdown structures, the same variability logic should be reusable against any of them.

Aras Variant Management

Recently released Aras Variant Management focuses squarely on this challenge: reusing the same variability logic in different product representation contexts and at any step of a product’s lifecycle. The application separates the definition of the logic from the structure that it resolves, allows saving the logic under a specific name, and reuses it as needed. Its dedicated data model is an integral part of the Aras’ PLM platform digital thread. It connects variability to all other digital assets the platform manages, including requirements, system functionality, architecture, implementations in different engineering domains, manufacturing processes, documentation, and others. Platform services can be configured to manage variability configuration, revision, change management process, team collaboration, and others.

Conclusions

Variant management is not limited to marketing and engineering. It is a fundamental part of the modular product strategy that involves internal and external (supply chain) teams—an essential element of Systems Thinking. As such, it impacts people, processes, and tools, and its impact should be considered in that sequence. Since variant management and modular platform design are critical to your products, you need to ask yourself if your product variability strategy takes that into account at every stage of the product’s lifecycle, by every team, and by all partners and suppliers. Not doing so may allow you to create more products with fewer parts, but it may also create the hidden problem of unforeseen emergent properties and behaviors. That can cost you billions, affect your product brand, and risk the well-being of your customers. Does Variant Management manage just BOM? Think again.

Learn more about Aras Enterprise SaaS and the benefits of Systems Thinking and Variant Management.

Failing to Keep Up With Technology Will Undermine Your Digital Transformation Strategy

Paweł Z. Chądzyński — Thu, 09 Feb 2023 16:00:00 GMT

Think Southwest Airlines and the Ford Mustang Mach-E

Every now and then, the market hands us amazing examples of what happens when companies fail to keep up with the technologies that are strategic to their competitiveness simply because C-level management does not see it as a strategic business issue. This is something that should be of particular interest to manufacturers of increasingly complex products where there is a reliance on PLM systems. Now, I understand that getting C-level attention is easier said than done but here are few examples that could help you to get there in a way that may be transformational to your organization’s competitiveness.

Putting off what you should be doing today

One example is the recent Southwest Airlines meltdown which apparently was 100% due to a purposeful delaying of technology upgrades, as explained here in great detail. According to this report, the bottom line is that the executives knew all along that the manual part of the pilot and crew assignment process was stretched to the limit. However, the company was quite profitable, so the management adopted a strategy best expressed by Vivian Leigh in Gone With The Wind here (sorry, I couldn’t resist). The latest reports indicate that this will cost them over $1 billion while their competitors weathered the storm quite well.

While Southwest does not use a PLM system, what happened to them has interesting parallels for PLM users, where upgrades tend to be avoided because of the cost, disruption, time, resources, and the inability to move customizations to newer versions of the system. In addition, PLM solutions are managed by IT departments and are often viewed as a less strategic cost. There are two consequences of that for PLM: the company keeps increasing its technical debt (customizations implemented on the old rev) and is unable to embrace new technologies and methodologies (ex: MBSE or pervasive simulation) in a common and in-context digital thread across the entire engineering V model. In other words, while the company thinks it is saving money by skimping on the PLM upgrades, its ability to compete decreases in a way that may be quite difficult to correct. If left unaddressed, it will negatively impact the best-laid plans for Digital Transformation, which should be of great concern to C-level management.

The unknown-unknowns and arrogance of over-confidence

Another example is Ford’s flagship product: the Mustang Mach-E. Until a few days ago, I perceived it as a technological marvel. And yet! Here is an article that reports what Ford CEO Jim Farley recently disclosed during a shareholder’s meeting: among other things, they didn’t know that the wiring harness is 1.6 kilometers longer than it needed to be, that they underinvested in braking technology to save on the battery size, and that the car is 70 pounds heavier than it had to be due to a misguided battery selection. As a result of this they left about $2 billion of profit on the table. Ouch! According to the article Farley said that “As with any transformation of this magnitude, certain parts are moving faster than I expected and other parts are taking longer.” Contrast that with this Munro Live YouTube teardown of Tesla S (the relevant segment is between 13:00 and 14:02). Munro says that: “The integration on these cars is just to die for. To do this, you’d have to have the suspension guys, the pneumatics and hydraulics guys, the electronics guys, the structural guys – everybody would have to be involved in every decision.” Aside from this male-dominated view of engineering (so wrong!), he is correct in highlighting the strategic role of cross-domain collaboration in the context of top-down Systems Thinking. My uneducated guess? That’s apparently what Ford teams are still learning how to do. That’s not surprising because traditional cars were designed with much outsourcing based on hand-me-down requirements and integration of pre-designed and pre-packaged sub-systems. This process does not lend itself to optimizing the entire system via the collaboration of the various engineering teams.

To be able to have a Systems Thinking driven cross-domain collaboration methodology in place you need two things: a digital thread and a collaboration platform capable of generating views in-context from that digital thread. In-context means that the views show what the specific participants of the collaboration can relate to as opposed to the underlying raw data which may be incomprehensible to them (ex: SysML model as expressed in a specific MBSE tool). That’s where PLM-managed tool-agnostic digital thread comes in at least as far as the system of record (i.e., the digital thread) is concerned. But because this digital thread now must provide traceability to the newest data structures, including system models and simulation studies, the PLM platform used to manage it must be able to express it. That’s where the importance of keeping up with the latest technologies in PLM platforms comes in. If your PLM version is five years old, you don’t stand a chance because that version was never architected to manage a digital thread that goes beyond a mechanical BOM. Same with the collaborative capabilities – they may simply not be there.

Conclusions

The emerging PLM technologies makes them essential to enablement of competitive strategies for the ever-increasing complex products and the related increasingly complex services built around these products. Think of the digital thread, digital transformation, and hyper-optimization of processes and design methodologies across domains, companies, and supply chain. That connection between the strategy and the enabling technology is what Southwest disregarded when underinvesting in their resource management system and Ford under-appreciated when pivoting to the EV market. This is now a C-level issue. The challenge is in finding ways to get C-level attention regarding that new role of PLM since in most organizations the term PLM is pigeonholed to its old role as an IT managed system-of-record primarily for mechanical engineers. That’s why I used the examples of Southwest and Ford because they speak in $s lost, opportunities delayed, and competitors racing ahead because that’s what C-level management wants to understand. Now figure out how to connect that with the criticality of embracing MBSE, pervasive simulation, AI, generative design, cross-domain collaboration, cross-domain optimization, meaning investment in core technologies, and you just may get your funding for the next generation of a PLM platform. The 2023 slowdown provides an excellent opportunity to reevaluate where you are vs. where you should be in a way that will result in that C-level attention.

Learn more about Aras Enterprise SaaS and the benefits of Systems Thinking.

Failing to Keep Up With Technology Will Undermine Your Digital Transformation Strategy

Paweł Z. Chądzyński — Thu, 09 Feb 2023 16:00:00 GMT

Think Southwest Airlines and the Ford Mustang Mach-E

Putting off what you should be doing today

The unknown-unknowns and arrogance of over-confidence

Conclusions

Learn more about Aras Enterprise SaaS and the benefits of Systems Thinking.

How the Digital Thread Improves Engineering Performance – A Real Life Example

Paweł Z. Chądzyński — Tue, 25 Oct 2022 13:38:00 GMT

Systems Thinking and Product Lifecycle Management (PLM) platforms – do the two converge on measurable benefits for your engineering teams? We have the answer, and it is a resounding yes! Here is the story....

First, let’s discuss ‘talking the talk.’ Back in the year 2018, I attended daily sessions of a Systems Thinking Roundtable at the INCOSE IS (International Council on Systems Engineering) conference in Washington D.C. The sessions were chaired by Dr. Cecilia Haskins of the Norwegian University of Science and Technology. One of the participants prepared a single Systems Thinking related question or idea for participants to evaluate, and each participant had a set length of time to discuss it. This was clearly about talking the talk, but it did require a firm commitment on the part of the participants to show up at 7:00 AM (sharp!), to express themselves within the allocated time (clocked!), and be willing to lead the next day’s session. These seemingly minor commitments were a key part of the exercise because they underscored the fact that ideas need people, processes, and discipline to become useful. These were open subjects and relaxed conversations, just a food for thought without a consequence. But was it?

Recently, I was listening to a webinar titled How Electrification is Transforming PLM Strategies. It was hosted by John MacKrell, Chairman, CIMdata. What I found interesting was that John presented a very coherent message touching on many Systems Thinking themes discussed randomly at the INCOSE roundtable but since organized into a coherent perspective. The core message was that rising product complexities (like vehicle electrification) create significant product opportunities, but that governing the underlying design process effectively requires Systems Thinking with a PLM platform-managed digital thread across the product lifecycle. And that the fundamental shift in thinking requires leading with system views as opposed to BOM (Bill of Materials) views. Note that I focused on the system views as opposed to system models because those views in context are what the rest of the organization benefits from. This means extending the digital thread to incorporate design intent that allows users to understand why things are designed in a specific way. Still talking the talk but now in the context of complexity and digital transformation. So, where’s the walk?

Not long ago there was a Rev-Sim (Revolution in simulation) sponsored webinar titled Development of a flexible digital thread for managing system performance simulation at Toyota Motor Europe. The Toyota Motor Europe (TME) portion was hosted by Ernesto Mottola, PhD., TME’s Vehicle Performance Engineering. The overarching message was that a digital thread is essential for enabling collaboration and optimization and that it is all about “connecting data=connecting processes=connecting people” in a Systems Thinking environment. What is unique about TME’s story is that it chose to start with the digital transformation of the design exploration space for a future electric car as opposed the actual design process of a specific product. It did that by creating a tool-agnostic digital thread to trace and manage individual sub-elements and sub-systems of a future electric car. This involved a system-centric approach to capturing 150% of the architectural structures of mechanical car platforms, including related variants, without the use of formal MBSE (model-based systems engineering) modeling tools like SysML language. This allows them to trace any parameter driven changes to these models as an input to the simulation with significantly reduced engineering effort. You can find out more about it here.

Fig. 1 TME’s reported benefits from the digital transformation of the engineering models

The webinar explains how this first phase is enabling TME to focus on democratizing and automating simulation by automatically generating simulation models. This means that the tool-agnostic digital thread will incorporate Simulation Process Data Management (SPDM) just the way it incorporated the sub-system models. One of the follow-up questions from the webinar’s audience was why TME is focused on organizing the fundamental engineering data instead of a specific product design process. According to Ernesto it is because you must first understand the fundamental underlying problem before addressing the higher-level design issue. TME is clearly walking the walk and I can’t wait for the next webinar that features the latest results!

Conclusions? Enabling free flowing but structured discussion of the basic Systems Thinking tenants like the Cecilia Haskins INCOSE roundtable allows individuals and teams to explore fundamental issues that should be addressed by every engineering organization. With that understanding, one can subsequently develop a unified vision of what a Systems Thinking driven digital transformation should be, given the emerging product complexities and new market opportunities as John MacKrell did. And then using that vision to enable visionaries within your organization to take risks with Systems Thinking and digital transformation. This approach is bound to produce huge benefits like those demonstrated by Ernesto Mottola.

So, there you have it. Systems Thinking and PLM platforms do converge … but it is a long journey that starts by connecting data=connecting processes=connecting people who first talk the talk and then walk the walk.

Learn more about Aras Enterprise SaaS and the benefits of Systems Thinking.

How the Digital Thread Improves Engineering Performance – A Real Life Example

Paweł Z. Chądzyński — Tue, 25 Oct 2022 13:38:00 GMT

Fig. 1 TME’s reported benefits from the digital transformation of the engineering models

Learn more about Aras Enterprise SaaS and the benefits of Systems Thinking.

How the Digital Thread Improves Engineering Performance – A Real Life Example

Paweł Z. Chądzyński — Tue, 25 Oct 2022 12:38:00 GMT

Fig. 1 TME’s reported benefits from the digital transformation of the engineering models

Learn more about Aras Enterprise SaaS and the benefits of Systems Thinking.

How the Digital Thread Improves Engineering Performance – A Real Life Example

Paweł Z. Chądzyński — Tue, 25 Oct 2022 12:38:00 GMT

Fig. 1 TME’s reported benefits from the digital transformation of the engineering models

Learn more about Aras Enterprise SaaS and the benefits of Systems Thinking.

Is Variant Management Your Achilles Heel? It’s All About Systems Thinking

Paweł Z. Chądzyński — Thu, 22 Sep 2022 14:00:00 GMT

Product variability is one of the key strategies used by Original Equipment Manufacturers (OEMs) and companies that offer configure-to-order products. This helps to decrease costs, minimize Cost of Quality (CoQ), accelerate time-to-market, and quickly respond to new opportunities with custom solutions. So, it’s important.

Product variants are unique combinations of selected product characteristics that span functional and physical features. Traditionally variability was configured on the level of physical parts using a Bill of Materials (BOM). Today however, most products, like the Apple iPhone for example, are no longer purely mechanical and include electronics and software with variants that are increasingly configured without changes to the mechanical BOM. Here are few examples of products with variants impossible to manage via a strictly BOM-centric approach:

BMW recently announced the pay-as-you-go availability of heated seats (link) indicating configuration via software only while maintaining the same hardware for all.
Apple just released iPhone 14 with the ability to route messages via satellite (link) – free for now but pay-as-you-go later indicating configuration via software only while maintaining the same hardware for all.
Automotive industry is forced to reduce functionality in cars due to a chip shortage (link) indicating configuration via software and hardware.

On one hand the above BMW and Apple examples represent product variants entirely implemented via software configuration – that have nothing to do with the physical BOM which remains the same for all variants. On the other hand, the automotive industry example represents product variants which are a combination of software and physical BOM configurations. In both cases, the software configuration is accomplished in one of two ways: via unique builds specific to the product variant, or via a single build regardless of the product variant that is controlled at run-time via a separately configured feature on/off table (a parameter table).

Today’s typical variant management process involves applying a configuration logic to an already designed 150% physical BOM (one that satisfies all standard features) to generate a variant specific 100% physical BOM (one that is a specific subset of the standard features). This is a well-established methodology based on the standardized product platforms and on libraries of pre-defended modules with standardized interfaces. It is addressed by a Configure-Price-Quote (CPQ) class of tools and is the basic methodology of variant management today:

Fig 1: Deriving a 100% BOM-centric physical variant

So, what’s not to like? The Achilles heel of the CPQ approach is that the configuration logic is very much BOM-centric and therefore focuses primarily on physical parts.

There you have it – BOM-centric variant management is insufficient to manage variability in complex products whenever software is involved, and this is where systems thinking, a holistic approach to analyzing and managing product behaviors, comes in. In these cases, variant management must become part of the system modeling methodology that embraces the Requirements, Functional, Logical, and Physical (RFLP) representations of a design as shown in Fig 2:

Requirements at various levels of their breakdown
Functional at various levels of their structure
Architecture that is specific to implementation domains
Engineering BOM that is specific to implementation domains
Manufacturing BOM that is specific to manufacturing sites

Fig 2: A system-centric RFLP representations with traceability to BOM-centric equivalents

But wait, there’s more!

The fact that variability must often simultaneously resolve product structures in multiple implementation domains highlights a unique role of a functional breakdown. This is because a system-level function is not domain-specific, and this neutrality allows it to be allocated for implementation to any domain. In other words, to have a variant resolved across all product representations, it should be resolved using a functional breakdown first. Only then should further variant configuration be resolved in other domains, all the way to the manufacturing BOM.

This is true systems thinking and that’s why systems engineers pay increasing attention to the issue of product variability when using the various Model-Based Systems Engineering (MBSE) tools. This is not easy since the concept of product variability has never been a particular strength of these tools and it is only recently beginning to be seriously addressed with modeling languages like SysML 2.0.

The point is that managing variability solely with physical BOM-centric structures is insufficient for today’s system-centric variants that span multiple product representations. System-centric variants require solutions that are driven by tool-agnostic RFLP product definitions traceable via a tool-agnostic digital thread and managed by modern PLM (Product Lifecycle Management) platforms. PLM is important because in addition to these various product representations, that digital thread must also accommodate countless revisions of the product representations and of the variant management logic as highlighted in Fig 1.

Solution vendors are recognizing the need to expand variant management solutions beyond the traditional BOM-centric CPQ approach. The new Aras Variant Management application helps designers of next-generation products manage complex product configurations across all product representations, engineering domains, and organizational boundaries through formally defined product features, options, configuration rules, and variability of breakdown structures across all product lifecycle stages. This helps you establish a consistent approach to managing variability as an essential element of your product family strategy, giving you an unprecedented flexibility to define product platforms and maximize module reuse, while increasing quality, lowering cost, and shortening time-to-market.

In conclusion, systems thinking is very much part of variant management of complex products. It allows to start defining variability in the earliest phases of design space exploration of the “RFL” of the RFLP and connecting it later to the “P” of the RFLP (a final BOM) via a tool-agnostic digital thread. This methodology does not replace the traditional role of CPQ tools. But it does alleviate CPQ’s Achilles’ heel by expanding beyond the BOM-centric representation to address the needs of all engineering teams.

Agree? Disagree? We’d love to hear your thoughts on this subject.

Learn more about the Aras Variant Management and the benefits of systems thinking.

The Benefits of Systems Thinking Make PLM on the Cloud a No-Brainer

Paweł Z. Chądzyński — Tue, 09 Aug 2022 13:48:00 GMT

One of the goals of digital transformation is to enable traceability in context between the many expert silos and the final design results—a digital thread that connects people, processes, and data. That does not mean eliminating domain experts or their tools but rather providing the ability for non-experts to leverage their work via a traceable and repeatable process.

Simulation is a perfect example with its need for model extraction, repeated execution in context, verification of results against requirements, and the need to compare results across design revisions—across separate OEM business units, partners, and suppliers. Other silos include requirements management, systems engineering, product platform variability, and others.

There is a key aspect of these silos that directly affects (or should affect!) the scope of digital transformation, because it involves different sets of data and processes, and therefore impacts OEMs’ digital thread scope:

Are they targeting a system-centric view before design details become available?
Or are they targeting design details in a specific implementation domain, a BOM-centric view?

The engineering V model provides very good visualization of that. It shows system-centric views of a product starting on the upper left of the V model and progressing down to the bottom. These views represent design intent in a tool-agnostic way. BOM-centric views of a product become established at the bottom of the V model and progress to the upper right. These views represent design data. Enabling traceability between system-centric views and BOM-centric across the entire engineering V model and across expertise silos is where systems thinking and digital transformation become inseparable.

There is a natural tendency to assume that the system-centric views are established with MBSE (Model-Based Systems Engineering) tools used by systems engineers and communicated to the rest of the enterprise in a form of diagrams. That isn’t always the case, however, since not every OEM needs that level of sophistication or can absorb the cost of embracing it. Many OEMs rely on system-centric views explicitly authored as requirement structures, or functional breakdowns, or product platform/family definitions, or structured organization of the engineering in form of reusable modules, or similar. Maybe in time every OEM will use sophisticated MBSE tools to generate whatever system-centric views they need but that is not the case today.

The key point to the digital transformation strategy is to recognize which system-centric views are key, where they come from, and which expertise silos are involved to defining them during the design space exploration phase. This is where things can go wrong without a systems thinking approach because lack of traceability to design intent prevents individual implementation domains from understanding why things need to be implemented in a specific way.

Once system-centric views are defined and communicated to the rest of the engineering organization, their intent must be allocated to the individual engineering domains for implementation. Sometimes it is a straightforward assignment of a function per domain (ex: software or mechanical) but many times it requires a process of optimization across individual domains. Signal latency is a good example:

While a system-centric view may communicate a maximum overall latency budget of some sort of a control scenario, the design implementation may have to distribute that between electronic devices (sensor reaction, pin I/O buffer delays), electronics (clock rates, signal integrity), software (data and signal processing algorithms), and mechanics (movement of a physical actuator). That distribution is never straightforward and always involves interactive optimization between the different domains to avoid overdesign or unnecessary implementation costs. The key point to a digital transformation strategy driven by systems thinking is to recognize which expertise silos are involved during the design optimization phase and how to reuse this expertise during the BOM-centric verification of the designs.

And that’s a lot of data that needs to be connected via a digital thread. Fortunately, modern PLM platforms are architected to span the entire engineering V model, to correlate the system-centric and BOM-centric views in the context of specific revisions and configurations, and to reuse democratized and “packaged” tasks traditionally dedicated to expertise silos in a form of specific workflows, configurations, and result interpretation methodologies by non-experts.

This need is not lost on the industry. Here is a quote from the July 2022 IDC report titled “Global PLM Priorities by Company Size”* where more than 800 PLM decision makers shares their thoughts on current business concerns, future priorities, and PLM implementation goals:

“Improving collaboration is becoming essential to product development, especially when there are development partners and an extended supply chain. Continuously evaluating product and life-cycle analytics is critical to improving product designs and optimizing performance. Therefore, cloud/SaaS PLM tools that can access data silos and leverage high-performance computing will be a growing part of the product development infrastructure.”

Aras Enterprise SaaS, the Generation 2 SaaS PLM leader, enables systems thinking by extending its core PLM services to the left side of the engineering V model. This includes flexibility to define and manage and generate various system-centric views from the underlying system models, integrating them with the tool-agnostic digital thread that already includes BOMs, and managing their lifecycle using the same proven PLM services traditionally used for managing BOMs. While cloud-based PLM platforms offer many benefits, from the systems thinking perspective, Aras Enterprise SaaS provides the ultimate collaboration environment for cross-domain optimization. This is because cloud-based functionality can be accessed under permission controls by anybody from anywhere across the OEM, partners, and suppliers. This gives the globally dispersed teams ubiquitous access to the system-centric views of design intent in context and when needed, which can improve data quality and process speed.

In conclusion, systems thinking as part of digital transformation enables OEMs to create lasting competitive advantages in the marketplace by managing and leveraging exploding product complexities to their advantage. OEMs can benefit from systems thinking as part of their digital transformation journey by taking advantage of Aras Innovator or Aras Enterprise SaaS.

Learn more about Aras Enterprise SaaS and the benefits of systems thinking.

*Source: doc # US49122322 , July 2022

Variant Management: The Key to Managing Exploding Product Complexity

Paweł Z. Chądzyński — Thu, 16 Jun 2022 14:53:00 GMT

It used to be that product variant management was done using CPQ tools (Configure, Price, Quote) which allowed users to resolve a product configuration according to a set of rules applied to the product platform’s existing features, options, and usage conditions. The idea was to eliminate any custom engineering work while providing manufacturing with the right BOM (Bill of Materials) for a customized product. A good example of this is the use of a car manufacturer’s website to let customers configure their cars. The series of choices are dynamically arranged based on what the customer already selected. If you chose a basic model of a car, you may no longer have the option of choosing features like heated seats. In a different scenario, a CPQ tool may identify what parts of the desired configuration do require custom engineering. For example, a central air conditioning system where the air handler, the condenser, the vents, and the thermostat are off-the-shelf, but the air ducts must be designed to fit the house’s specific layout and architecture. The goal of CPQ tools is to minimize the time between ordering a custom product and manufacturing shipping it.

Today product complexities driven by pervasive connectivity, increasing software content, and a high degree of customization force OEMs to consider the basic tenants of variability management much earlier in the product lifecycle. These are cases where managing the variability built into a product platform requires a degree of technology sophistication on the part of the user beyond what typical CPQ tools require. For example, the concept of variability is often used during numerous design phases and within various design representations to explore what is possible from a technology perspective. Since CPQ tools were not designed for this purpose, engineering teams default to using complex spreadsheets. That is a source of much pain due to the lack of data model enforcement, traceability, revision control, change process, and not knowing which spreadsheet is the one that matters in a specific case. Even if the spreadsheet process works, it is open to human error and does not provide a path for connecting the results with the CPQ tool users.

Aras has invested considerable time and resources researching these issues with customers over an extended period. This led to several conclusions that were incorporated into our latest application, Aras Variant Management, and they are all worth pointing out.

Variability resolution logic should never be implemented as part of the product breakdown structure that needs to be resolved. The breakdown structure is any product representation that includes definition of all variant points and related components. A breakdown structure could be a representation of a product at the level of requirements, functional breakdown, architectural breakdown, or a physical implementation including mechanical, electronics, and software. Variability resolution logic and the product breakdown structure are two different data models, and by managing them separately one can develop a configuration logic methodology—rules, features, and options—that can be applied to multiple sets of design representations with variant components. This means that the rules themselves become a reusable OEM asset. It also means that rules and breakdown structure development processes can have their own lifecycles, revision controls, change management, and approval workflows.

An independent variability logic applies the same set of rules to each of the RFLP (Requirements, Functional, Logical, and Physical) design representations, individually or together. For example, by building a breakdown structure that reflects a system functional breakdown one can define the structure and the related variant components in a way that allows targeting of these functions to a multiplicity of implementation domains. This means that the same set of variability configuration rules can be applied to a system-level functional breakdown to distribute its allocation between the mechanical, electronic, and software implementations. That is a powerful concept for MBSE (Model-based Systems Engineering) initiatives because it extends product variability methodology all the way back to the design exploration stage of the product lifecycle.

Information that results from the resolved breakdown structure—a variant— is also key to making variant management methodology relevant to every stage of the product design lifecycle. In a typical CPQ scenario the output of the configurator is meant to feed CRM or MRP systems. But when variability management is applied earlier in a design cycle the desired output is often to inform, evaluate, and resolve technology issues that drive definition of the individual variant components, groups of these components that define sub-systems, and the variability configuration rules. That may involve no data generated at all other than a temporary view of the target configuration, a set of system model elements, a set of the related requirements, a filtered content of documents, and others. The flexibility of determining the type of the resulting data is key to extending variability methodology throughout the organization.

Finally, flexibility to set the context of the variability resolution without changing the rules or the breakdown structure is important as well. For example, over time, details of the rules or of the breakdown structure will evolve and therefore variability resolution executed a month ago may yield different results than one executed today. While the default of this type of context is typically set to the latest version of rules and structures, it may be critical to select an earlier date to be able to compare how changes of the rules and structures affect the variant resolution. That type of context setting is critical, and it is only possible if the underlying data is subject to the lifecycle and traceability services.

There are some of the aspects of variant management that make the methodology applicable beyond the traditional focus of the CPQ tools. What is important is that all of them require services of the underlying PLM platform including traceability, revision control, change management, access control to the data, and others. Therefore, the latest Aras Variant Management capability built on the Aras low-code PLM platform is an important step towards helping OEMs manage ever increasing product complexity.

Visit www.aras.com to learn how Aras Variant Management application helps you efficiently manage product variants.

Change Management in Context – A Foundation of System Lifecycle Management

Paweł Z. Chądzyński — Fri, 22 Apr 2022 03:30:00 GMT

If you haven’t noticed, the nature of change management in PLM is, well, changing due to exploding product complexities. It used to be that PLM was focused on changes to physical parts or physical assemblies (BOM). That was because PLM solutions and configuration management were originally designed to manage the mechanical domain. However, with the increasing importance of systems engineering and Model-based Systems Engineering (MBSE) tools, the context of a single change is drastically expanding. That expanded context is what must be considered to evaluate the impact of this change.

Some may remember the fatal and costly 2014 debacle that General Motors (GM) got into with a faulty ignition switch design (see here for a root cause discussion). Notwithstanding the fact that the GM design engineer failed to follow the company’s change management procedures (by changing the design of a part without changing the part number), there is another interesting element to the story. GM did not have the ability for engineers to quickly and automatically use the parameters derived from the modified part to rerun system-level analyses and simulations to evaluate the impact of the change. Nor did they run an analysis that would automatically compare the results generated by the previous design and related requirements. That highlights the challenge of PLM change management which I discussed in a previous blog. Had such an automatic connection existed the whole situation might have been avoided because the analysis would have been done easily and automatically (e.g., without an additional time investment by the engineer), taking into account the entire system context of that change.

It turns out that I’m not the only one who thinks this way. Consider the following quote from the new INCOSE Vision 2035 report: "By 2035, a family of unified, integrated MBSE-Systems Modeling and Simulation (SMS) frameworks exist. They leverage digital twins and are fully integrated into the enterprise digital thread foundation." I would add that these frameworks would be completely integrated with the PLM platforms (for the “big” SE), as well as with domain-specific design tools (for the “small” SE) – see the explanation of the “big” vs “small” SE in the graphics below. Similar points are made by Dr. Martin Eigner in his new book, System Lifecycle Management.

System models enable design intent driven traceability of relationships &
dependencies between design data and across domains.

Solution providers are not waiting. Domain-specific tool vendors are actively pursuing integration of MBSE for small SE, the wiring harness design tool E3 and GENESIS system modeling tool being good examples. Aras' low-code platform has already released foundational elements of this framework allowing big SE and small SE to be managed as part of a single digital thread.

There is another aspect of the change management process that needs attention because of the expanding impact of change. It has to do with the need for that process to dynamically adapt to a design’s maturity level. Initial changes are driven by design space exploration and have a minor impact. As design maturity increases, changes become more impactful because of prior decisions on reuse, requirements flow down, and information already shared internally or with partners. I call that Dynamic Change Management. It automatically streamlines change requests, assessments, and orders in accordance with the design’s maturity. This ensures that users throughout the extended supply chain have easy and early visibility into engineering status changes throughout the product lifecycle where change histories are automatically captured and recorded. Again, the Aras Innovator platform is already providing that functionality.

Dynamic change management is also critical because specific design domains execute at different timelines and cadences while still relating to the same overall system design. Application Lifecycle Management (ALM, e.g., software development) vs. electronic CAD vs. PLM are good examples of that. In fact, ALM is a true stand-out because many OEMs agree that their goal is a complete decoupling of software design from hardware design, while maintaining the same overall system design context.

While the ideas discussed here can be forward-looking for your organization, there is one aspect of the change management process that should never be left unattended. That is compliance with CM2 by IpX - the Institute for Process Excellence. Whatever solution you use or intend to use to manage product changes, “Is it compliant with CM2 by IpX - the Institute for Process Excellence?” is the first question to ask. If the answer is no, it’s time to look for a different solution provider.

To find out more about Aras Innovator’s low-code platform and Aras Enterprise SaaS visit www.aras.com.