To produce intelligent, connected products, engineering teams must adopt a systems approach to manage information and processes throughout the entire product lifecycle. The problem is that most engineers are limited to one of two disciplines—systems engineering (SE) or product lifecycle management (PLM).
While both systems engineering and product lifecycle management can manage complex products, they also have significant differences. Combining these two long-established disciplines can create the methodologies needed to produce the next generation of complex products. However, rethinking how engineering organizations manage product development is no easy task.
Implementing system-level methods
Today's products often involve multiple nested systems, with a single design potentially encompassing electrical, mechanical, and software layers. To manage these interdependent disciplines, engineering teams must employ a systems-level approach. Systems engineering and PLM, as systems-level disciplines, offer relative advantages—like two sides of the same coin—with the goal of delivering high-quality products on time and within (or below) budget. Each discipline achieves this goal differently, but understanding these differences is crucial.
The origins of systems engineering can be traced back to the era of designing on paper with pens and typewriters. It began in the aerospace and defense industries, where companies spent months or even years developing a product that met customer needs. Whether in the past or present, these customers remain primarily government agencies, requiring precise fulfillment of their requirements. The task of systems engineers is to gather these requirements, along with the needs of other stakeholders throughout the lifecycle, and translate them into systems models to guide the development of the final product or the software or hardware included in the system.
On the other hand, PLM emerges later in its lifecycle, focusing on physical design, computer-aided design (CAD) models, and bills of materials (BOM). The basic components of PLM are parts, sub-assemblies, or assembly structures. Initially, these were primarily defined by systems engineers.
Although both approaches use the same information and complement each other, their origins and focuses differ. A leader in an engineering field confined to a systems engineering approach might not be inclined to invest in PLM; similarly, a leader of a mechanical engineering team working on PLM might not want to spend all their time managing requirements. The reason they both chose an integrated approach is that the industry is changing. And both teams need to do so to keep up with the competitive demands.
Collaboration of engineering organizations
Computer programmer Melvin Conway pointed out in 1968 that the structure of a system design inevitably replicates the communication structure of the organization that designed the system. This theory, later known as "Conway's Law," means that a product will reflect the organizational structure of the product engineering team that builds it. This can cause problems if the systems engineering and PLM groups work separately.
The challenges that arise when systems engineering and PLM teams work independently stem from cultural and technological inconsistencies. They have established their own ways of doing things and expect each other to adapt and emulate them. Beyond their independence, communication difficulties can arise from other departments, or even within the same company's engineering functions (such as software teams), due to a lack of coordination. Independent information systems further complicate the process.
The systems engineering and PLM teams are developing the same product, but sharing information is difficult because the development tools they use and the data resides in different databases. Therefore, data processing and switchover between teams and downstream partners throughout the product lifecycle are highly error-prone. Conway believes these errors will appear in the final product. The concept of a fully integrated systems approach—where every piece of product information is interconnected and consistent throughout the product lifecycle—is a myth. However, this doesn't mean that developing a holistic product is impossible.
Future-oriented engineering organizations
Building a future-oriented engineering organization may sound like a daunting task, especially today, with teams grappling with increasingly complex products, regulations, and fierce global competition. The first step in realizing this vision is creating an environment where systems engineering and PLM can collaborate. To do this, engineering leaders should consider:
Uniting the Systems Engineering and PLM teams—After outlining their shared goals and the benefits of integrated development methodologies, integrating the Systems Engineering and PLM teams will depend on interdisciplinary communication. If a similar communication forum does not yet exist within the organization, create one. If it already exists, encourage its use.
Create inclusive processes for both disciplines—moving away from self-centered belief systems and designing new processes that connect the various parts of each discipline. Meet the needs of each team by retaining some best practices that benefit other teams.
Connecting and integrating information into a single, trusted source within the engineering process—system-level design requires a system-level platform. Multi-vendor solutions offer the breadth needed to manage every stage of the development process. Moving beyond documents, PDFs, and spreadsheets is crucial.
Planning for change—maintain flexibility by choosing tools with open application programming interfaces (APIs) and flexible architectures that enable organizations to easily adapt to change. In today's digital age, best practices today may not be applicable tomorrow.
Consulting external partners—an integrated approach also requires considering the needs of customers, suppliers, and other stakeholders in the engineering process. Meetings are held with partners across the supply chain, and feedback from the field is used to improve new processes.
Combining best practices in systems engineering and PLM will lay the foundation for continuous improvement and digital transformation. Developing disruptive products and systems requires a disruptive approach, which necessitates the right change management processes and technologies.
Disclaimer: This article is a reprint. If there are any copyright issues, please contact us promptly for deletion (QQ: 2737591964). We apologize for any inconvenience.