<img height="1" width="1" style="display:none" src="https://www.facebook.com/tr?id=157406051691882&amp;ev=PageView&amp;noscript=1">

Systems Thinking and How to Engineer to Possible

Manufacturing Systems Thinking February 16, 2023

VIEWPOINT: How manufacturers use systems thinking and digital transformation to manage their complex designs, minimize failures, and bring new products to market faster.

Image source: metamorworks/stock.adobe.com.

Manufacturing organizations recognize that systems thinking and engineering digital transformation (DT) are critical to managing exploding product complexities to minimize the risks of functional failures. They also recognize that leveraging complexities is critical to maintaining a competitive advantage and discovering and embracing new products and market opportunities.

Systems thinking is crucial for exploring, documenting, verifying, and validating how a product interacts with its surroundings, for example how self-driving vehicles and smart cities work with their environments. DT, on the other hand, is critical to enabling collaboration and traceability during the design phase and throughout the manufactured asset lifecycle, for example bringing closer alignment with external partners and suppliers or intelligent use of IoT (Internet of Things) data in the maintenance of the existing assets and development of new products and services. Due to the fact that both initiatives take a long time to implement and require dedicated resources, it’s essential to make sure that your teams understand the objectives of these initiatives. The key question is how to achieve and measure both, plus minimize the risks and leverage the opportunities.


Known Variants of a Known BOM

Some organizations take an interesting approach to answering that question by focusing their systems thinking and DT efforts on the future rather than the present. Traditionally, a product platform allows organizations to optimize their manufacturing operations by maximizing the reuse of existing elements of the platform in various pre-approved product variants. The platform is engineered to contain all elements of all approved variants, often referred to as a 150% BOM (bill of materials). In contrast, a variant contains only a subset of the platform elements, is called 100% BOM. Via a variant management process called CTO (Configure to Order), a design manufacturer can configure a variant using a predefined set of configuration rules. At the same time, the manufacturing operation remains optimized to manufacture any of these variants. This is how buyers configure cars using auto manufacturers’ web sites. Often that process is geared towards more custom products where most of the parts come from a predefined 150% BOM platform.

At the same time, some are unique to the order and therefore need to be engineered before manufacturing the product. This variant management process is called ETO (Engineer to Order). This is typical of the heavy equipment market, where the basic machinery needs to meet a one-of-a-kind set of requirements typical of mining, construction, or infrastructure building applications. In both CTO and ETO cases, manufacturers rely on well-established software solutions called CPQ (Configure, Price, Order), which allow for maintaining a high level of efficiency of the ERP (Enterprise Resource Planning) and MRP (Manufacturing Resource Planning) processes for handling these variants in manufacturing. That works well only for known variants that can be represented via a known manufacturing BOM.


Known Variants of an Unknown BOM

But what if the variants are unknown and include representations that are not easily represented via a manufacturing BOM?

A good example of that challenge are self-driving electric vehicles. The physical structure is unlike the familiar combustion engine-powered platforms and the electrification of it offers new functional possibilities that need to be clarified (e.g., acting as a power supply for external tools). The platform’s functional differentiation must also be realized via software that challenges the concept of manufacturing BOM-driven variant definitions. In addition, it must reduce complexity: physical with the generative manufacturing, communication with system-of-systems interaction with standards yet-to-be-defined, maintenance with worldwide dynamic IoT interpretations, upgrades with over-the-air reconfigurations, and so on. In other words, it must be “engineered to possible,” so those future variants can be generated using a modified approach to CPQ that still handles BOMs but is also equally proficient with handling software configurations.

That’s why I found TME’s (Toyota Motor Europe’s) approach to systems thinking and engineering digital transformation so fascinating. You can listen to the recording of a Rev-Sim (Revolution in simulation) sponsored webinar titled “Development of a flexible digital thread for managing system performance simulation at Toyota Motor Europe” to learn more. Let me outline the approach.

TME decided to focus on the DT of the company’s basic future EV sub-model elements in a way that allows engineers to modify them via an extensive set of parameters quickly. While these are very much sub-system models, they are a bit more specific regarding physical details (e.g., elements of suspension) than a purely MBSE model would be if defined in a language like SysML. This allows TME to democratize the simulation of these sub-modes individually or as combinations to explore what is possible and in what combination. In addition, all that digitalized engineering data is modeled to be fully traceable via a digital thread that connects design intent with the module models, simulation models’ generation, parameter modifications, and simulation results. Once fully implemented, it allows engineering teams to execute quite sophisticated variant and simulation scenarios with a push of a button. That includes an ability to qualify the results against parameters in requirements in a way that future users of the platform can reference as accepted or rejected.

To understand what needs to be modeled, TME relies on the principles of systems thinking. To capture the design intent and various implementation studies, the company relies on digital transformation. To expose the rest of the organization to all that information in context (revisions, studies, approvals, rejects, etc.), TME relies on a tool-agnostic and extendable digital thread implemented on a modern low-code PLM platform capable of adapting to new design tools and the emerging manufacturing technologies (such as generative design).



The TME example shows how a company can “engineer to possible” by enabling future variants of future products by documenting the key elements of a solution very early in the design process. I believe that this methodology will drive more efficient definitions of the product platforms that support future manufacturing details of future-specific product variants and will lead to manufacturing success. As you build work within your design teams, find ways to use systems thinking and DT to further your design and manufacturing goals.


Viewpoint articles are tech-focused editorial written by experts from the CAD industry. This article was written by Paweł Chądzyński from Aras Software.



Searching for more information about Product Design & Manufacturing? 
Click here!

Paweł Chądzyński

Paweł Chądzyński is Senior Director of Product Marketing at Aras Software, https://www.aras.com.

View All Articles


Materials + 3D Printing + MCAD = Innovation Explosion

One of the seminal movies of the 1960s was The Graduate, in which a new college graduate tries to navigate the challenges of love, social norms, and...

PTC Creo 11 Supports the Changing Needs of Manufacturing

From its origins as the first parametric modeling software for mechanical engineering until today, PTC Creo is synonymous with mechanical and product...

Computer Hardware Drives Engineering Performance

Computer hardware optimized for design and simulations is becoming essential. As engineering software advances, the underlying hardware requirements...