Picture this: you’re in a taxi on your way to the Dallas airport, looking forward to being home after a long work trip. And then it hits you—where’s my phone? Suddenly panicking, you begin to search—checking every pocket in both your bags, and then your trousers, and then your coat—and finally, there it is. In your sweater pocket. As your heart rate begins to slow back down to normal again, the taxi driver quips, “You need more yoga in your life.”
I don’t know if better harmony with the universe would’ve kept me from losing my phone in my own pocket, but—when it comes to product development—the ability for every product stakeholder to connect with a single universe of data, confident that they can find what they need quickly and accurately, sounds like PLM nirvana to me.
Single- or Multi-View BOM? Traditional Challenges
So many engineering disciplines throughout the enterprise play a critical role in product development, and each one often relies on its own, domain-specific, view of the product’s Bill of Materials to author and interrogate product information. Traditionally, one way to manage these diverse needs has been with a single BOM—an overloaded bill of materials containing information from engineering, design, and manufacture—that uses filtering and calculations to serve up different views based on the user’s role.
Another way is to manage a “dual-BOM”—or, two bills of materials synchronized across engineering and manufacturing. Transforming an eBOM to an mBOM for the side-by-side management of two separate but connected bills of material can result in tenuous integrations between them. That’s because this approach requires accountability and reconciliation to ensure that manufacturing processes include every part in the eBOM. Then, when a change is introduced into one BOM, it must be communicated to the other to ensure that the two stay in sync.
Traditional methods for managing single- and multi-view BOMs can be an obstacle to both product and process improvements by requiring custom code and brittle integrations that result in a lack of flexibility for the system and its users. In most PLM systems, customizations result in an inability to upgrade to the latest features as they are released: limiting the introduction of new business processes, new technologies, and even new collaborators into the workflow. Engineering teams are stuck with legacy software, rigid processes, and multiple systems to search around in for what they need—taking up valuable time and resources while increasing chances for human error.
Aras PLM: One Authoritative BOM, Multiple Points of View
Aras believes that no single view into a product’s structure can satisfy the requirements of all users and all use cases throughout the lifecycle. After all, a product’s lifecycle includes contributions from more teams than just engineering and manufacturing. Systems architecture, requirements engineering, quality and risk management, simulation, and maintenance are just a few of the many teams that need to author and interrogate product data from concept through retirement.
Aras PLM enables users across multiple engineering disciplines to view and contribute to the product’s definition by using a representation of the product’s data that matches their unique perspectives and practices. Domain-specific industrial applications included with Aras PLM present unique data, change processes, workflows, lifecycle states, and collaboration capabilities purpose-built for authoring and interrogating product information in each supported discipline—while keeping that data connected to the parts and assemblies it relates to in one central, authoritative product bill of materials. Change is managed independently throughout each process and team, but when change impacts other teams upstream or downstream of the new information, those teams can be flagged and made aware of the new information, to ensure visibility before change is advanced.
This means Aras PLM can support either a single- or multi-view BOM process—depending on the needs of the business. But, with either approach, it maintains a single source of truth for the product’s evolving data while allowing for users across many engineering domains to create and manage product information unique to their engineering discipline. Why does this matter? Let’s consider an example: an FMEA record, authored in a quality management system to indicate risk mitigation techniques for a part or assembly, can be linked with its related product data in the eBOM. As the part in the eBOM is consumed during manufacturing process planning to create the mBOM, risk information (and all other information) associated with the part is retained, helping to ensure that key dimensions are preserved throughout manufacturing and quality inspections. Finally, as the product launches to the field and a service BOM is generated using the same information, risk information can guide service procedures to further preserve a product’s quality and safety throughout its use. Aras PLM is purpose-built to maintain critical connections, like these, among related product information as it evolves throughout the lifecycle.
When domain-specific product data is not authored in Aras PLM, it can be managed there by leveraging links to outside systems. Aras PLM is built for connectivity within and without—including links to multiple CAD, CAE, and PLM tools—to ensure that data from the many tools that product engineering teams use can be supported. And because it is built for upgradeability, these connections are maintained throughout the upgrade process, ensuring that engineers are not “stuck” on legacy software versions and that business processes and teams can be fast-moving and flexible as the OEM’s product strategy grows and evolves.
One or Many … Why Not Both?
One organization needs multiple teams—both inside and outside the company—to contribute to the development of a great product, to ensure quality and accuracy throughout its manufacture, to service and maintain it right, and to capture operational and failure data from the field to inform the best future upgrades and improvements. Powering that collaboration from one, authoritative source of accurate, up-to-date product information—accessible by anyone with a critical role in that process, in a way that provides the perspective and control they need—accelerates and improves their contribution to the product lifecycle.
It’s not just two views of the data that product development organizations need—it’s actually more. But it is, in fact, one authoritative source of product information that helps ensure that these many views, and the stakeholders accessing them, stay current with product changes, accelerate the design process while maintaining accuracy, and can author and interrogate data confidently knowing they have the most up-to-date, complete record of the product’s quickly evolving information. That sounds like PLM nirvana to me.