In Episode 54 of Razorleaf’s Stay Sharp podcast, Navigating PLM Complexity: Multi-System Strategies for Success, co-hosts Jen Ferello and Jonathan Scott take the next step in their exploration of all things PLM, by examining the idea of multiple PLM systems or tools in the same company. They discuss how organizations might have gotten to that state, how the systems might be set up, how they might interact, and why reducing their number might not be the best idea.
Multi-System Set Ups
To level-set, Jonathan explains that the right terminology to describe different installations is an “instance,” saying, “That instance can have its own software, version, configuration, content, whatever, however you want to characterize it.”
The most straightforward example of multiple PLM systems is two different platforms from two different vendors in two different departments or divisions—two entirely unrelated instances. Another common situation is a single PLM system in two different instances in the company, possibly differentiated by business line. They might each be running a different version, if any group has integrations or customizations they couldn’t move. Or the different instances could be configured based on function, Jonathan says, “One’s record keeping and maybe information distribution, but the other is development cycles—or maybe somebody’s got a PLM that they use for another functional case, like using it for simulation lifecycle management.”
Common Patterns in Multi-System Instances
Whatever the underlying reason for a single organization having and supporting multiple PLM instances under one roof, there are three patterns that Jonathan and Jen discuss that can help you make sense of what might feel like chaos: federated, hub-and-spoke, and peer-to-peer.
A federated pattern consists of separate PLM instances—from whatever origin or configuration discussed above—for different functions, plus an umbrella system across all of them as the “one ring to rule them all,” says Jonathan. The umbrella system could do the organization’s record-keeping, regulatory compliance, quality, “or some other corporate function, some overarching function where you’re looking at that element of your product family’s collective lifecycle.” This pattern might be the easiest for making sense of acquired companies, where each uses their own PLM systems, but all are able to roll up the information to the enterprise. It also might be most appropriate for situations where, Jonathan says, “localized efficiency is better, but some things have to be connected.”
As Jonathan describes, in a hub-and-spoke pattern, a central hub exists that receives information, but also moves information around and/or translates data from one system to another. A company with different divisions is a good use case. One division makes a product—any kind of widget—and another division produces an integrated system that contains the widget. Since the first division is a product builder, and the second is a system integrator, they’ll likely need different PLMs. There could even be a third division that does something different with the widget and needs a different PLM instance. “What they need is some ability to move subsets of data around very efficiently,” Jonathan says. “They’re not trying to standardize everybody to make them all behave the same way.” All of that is possible with a PLM in the middle of the enterprise architecture as the hub.
The peer-to-peer pattern is a more straightforward architecture, where two PLM systems talk to each other. It’s relevant where two entities—whether multiple companies, partners, suppliers, or simply two divisions—need to share data back and forth, “and they need to translate or correlate so that when the data moves across, it doesn’t lose context and doesn’t lose something important as it’s shared,” Jonathan explains.
He and Jen differentiate peer-to-peer patterns from integrations in that peer-to-peer patterns, as well as federated and hub-and-spoke, can be done manually or automated, whereas integrations are all automated. But Jonathan does amend his views aired in a previous podcast on integration that assumed one PLM instance. He says, “The reality is … my digital thread could run across three PLM instances from two vendors with three different versions of the software, plus four ERPs, two MESs, and a partridge in a pear tree. That’s the reality. That’s what people have.”
Learn More About the Pros and Cons of a Multi-System Environment
The full podcast contains more discussion and details on a variety of topics, including the business advantages of having a multi-system PLM setup, why flexibility is both a pro and a con for multiple systems, why there’s no single right answer to the question of singular or multiple PLM systems, and more.
Check out the full conversation in Stay Sharp Episode 54: Navigating PLM Complexity: Multi-System Strategies for Success, and join us each week for a new podcast.
Follow the Razorleaf Podcast, Stay Sharp in Digital Engineering on:
