PLM transformation is the latest Industry buzzword that’s relevant and meaningful to companies trying to streamline product design, launch, distribution, and service. Regardless of what you read in magazines and blogs, it’s a major commitment of time and resources, no matter how small or large. By definition, Transformation is a drastic change from your current practice – both from business process and software practices.

Context and Scope
The terminology of digital thread is often associated with Transformation since the focus is on handoff between various organizational roles and computer systems during the entire product development. In this context, PLM Transformation is bounded by work processes from Concept through Release to manufacturing. It’s beyond our current scope to talk about financial justification to approach the subject of transformation or PLM package selection.

Is PLM transformation a Business or IT initiative? Every organization should recognize the importance of both. In current day practices, the work processes are so tightly integrated with IT systems and tools. Have there been discussions about a Supplier bid package without discussing what software is used, what neutral formats are acceptable, how to hide IP, the location of the master list of qualified suppliers, etc?

Common Triggers
There are multiple reasons why this subject is initiated within your organization, the common reasons being: Moving to a new PLM platform, swapping an existing PLM platform, Software maintenance and licensing cost, business drivers due to compliance or productivity, and last but not the least – Our competition has embarked on such a journey.

Tips and Techniques
In my experience, I have applied some key principles to keep the organization moving in the right direction and get value from a Transformation effort.

• Spend enough time to harmonize the business process. There must be consistency across product lines or business units for a given work process.
• If there’s a PLM platform in the mix, introduce the software early and discuss the business process with a “Solution Demonstration” approach. Avoid endless displays of graphs, workflow diagrams, and charts.
• Select a group of external partners you want to work with. Recognize that there are many areas of specialization, and one size does not fit all.
• Recognize the delineation between core capabilities that have reached a certain level of maturity in PLM tools and others that are evolving:

Matured: Documents, Change, BOM, CAD, Supplier data exchange, Integrations to enterprise systems
Advanced: NPI/NPD portfolio, ECAD/Software integration, Materials, Regulatory submission, PDH/PIM product hub, IoT integration, Advanced analytics, Risk & Requirements integration

• A decade of legacy PLM in place will take 20% effort to transform (2 years).
• Legacy data has a huge impact. Decide what’s important to move forward and define an archival strategy for the rest.
• Training and Documentation are not administrative efforts. These require subject matter expertise and takes time to develop and execute.

Summary
It’s a daunting effort with so much uncertainty and careers at stake. However, “do-nothing’ is not an option to stay competitive and improve efficiency.