While the vision for product lifecycle management (PLM) -- and PLM integration with other software systems -- is to establish an enterprise-wide repository
Manufacturers get caught in this trap when they take a parochial view of PLM as an initiative that only benefits the engineering group, not the organization as a whole. Moreover, PLM implementations can be stymied when one group-- for example, engineering -- requires other departments to use the platform without first securing C-level sponsorship or showing the other groups how an integrated PLM system can benefit their own product-development functions.
“The problem is we still don’t have the right visibility in the executive suite, and that is where it has to come from in order to take a product-centric view of a company,” said Michael Grieves, professor of information systems at the University of Iowa, a consultant to NASA and author of the book Product Lifecycle Management: Driving the Next Generation of Lean Thinking. “You need to be thinking about this across functional areas -- not just engineering or manufacturing. We don’t do a good enough job forcing the discipline about thinking about products in a product-centric fashion throughout the rest of the lifecycle.”
Additionally, PLM can become pigeonholed when companies lose sight of the greater reason they’ve embarked on the discipline in the first place. Typically, manufacturers make a decision to implement PLM to achieve a specific goal or resolve a particular problem -- for example, strategic initiatives to boost innovation or facilitate quality improvements, or compliance and sustainability concerns.
“People often take their eyes off the prize and that they’ve implemented PLM for a particular reason,” said Monica Schnitger, president of Schnitger Corp., a consulting company specializing in product-development issues and PLM. “The problem that led them to PLM didn’t only involve the engineering team, [it was also] bigger than any one group of people.”
When people forget why they implemented PLM, Schnitger said, they risk having an implementation that doesn’t support all of the product-development processes in the company while not delivering the information that people need.
Spreading the word about PLM integration
The first step in avoiding siloed PLM is to promote PLM’s “value proposition” in language and deliverables that resonate with both the C-level suite and the various functional areas of the business.
Too often, champions of product lifecycle management systems focus too heavily on selling the features of various platforms instead of talking up the intrinsic value of a PLM-driven, product-centric organization, according to Grieves. Keeping a focus on customer value will go a long way in getting departments beyond engineering and R&D on board. Cross-functional teams are also crucial to pulling PLM out of silo mode and helping the different business groups rally around the discipline to achieve common goals.
“Engineering, manufacturing and support people think differently without understanding the others’ issues,” Grieves said. “You’ve got to get people to break out of the silo and interact with others that don’t think like them.”
While the culture around engineering and product development has typically been insular, that’s starting to change dramatically as people get more comfortable with sharing data and collaborating on projects on a wider scale.
“People realize today that it’s not the information itself, but the conclusions that are drawn and connecting the dots that brings someone’s expertise to the fore,” Schnitger said.
Pick the right PLM tools
Beyond the cultural and change-management issues, choosing the right PLM technology is also instrumental in gaining adoption outside engineering. While many PLM platforms evolved out of traditional engineering-oriented tools like computer-aided design (CAD) and product data management (PDM) systems, numerous technology advancements have made PLM systems more palatable and accessible to non-engineers.
“Just about all of the tools have process and data-visualization capabilities that let them be more useful outside of the engineering and design group,” Schnitger said.
For example, new browser-based PLM tools allow people in marketing or maintenance to tap into and contribute product-related data without having to own and operate often complex and expensive 3-D programs. In addition, Web collaboration and visualization capabilities in PLM suites allow non-CAD users to edit, view, rotate and annotate 3-D product designs, enabling them to provide input earlier in the design process, which is key to PLM’s promise of reducing time to market and lowering development costs. Dashboards and analytics tools, increasingly offered in PLM suites, promise to give executives in finance and procurement much-needed visibility into product components and sourcing so they can address compliance concerns and monitor trends in quality. Again, that tends to be an advantage early in development as opposed to late in the cycle, when it can be more costly.
Training users not just in the specific PLM tools but also in the process change that accompanies the discipline is perhaps one of the most crucial factors in promoting widespread adoption of the technology. If users across the business feel that the changes brought on by PLM can improve how they do their jobs, they will buy in.
“At the end of the day, PLM is about product-development processes in an organization, and if you want people to implement the tool, you have to match the software to the organization’s processes,” said Oleg Shilovitsky, a consultant and former PLM executive who writes the Beyond PLM blog. “If it gets over-complicated, they will resist. If it’s a natural fit, it will make the deployment more successful.”