PLM Platform Upgrade: The Elephant in the Room

Enterprise digital platform upgrades are rarely pure “technical endeavors”; they combine various opportunities for improvements, across process, operating standards, data quality, business capabilities, integration, performance, infrastructure, APIs, etc. Regular upgrades can contribute to both continuous business improvement and stabilization, without breaking the bank or having to wait for the next “major transformation” to introduce changes.

PLM implementations and major upgrades introduce both opportunities and threats to organizations, mitigating possible disruption and business change challenges. There is often an expectation or perhaps perception that “the more business changes are deployed; the more value will be realized”—a high-risk-high-reward strategy which does not guaranty success depending on organizational maturity and change readiness. When carefully planned, regular minor upgrades can cumulatively add significant value and minimize business disruption—avoiding the last PLM implementation or previous major upgrade to become the new elephant in the room… i.e., “a very large issue that everyone is acutely aware of, but nobody wants to talk about”.

In this post, I elaborate on how regular minor PLM upgrades can contribute to ongoing operational efficiency and business capability adoption, powered by DevOps processes and tools.

Digital transformation comes from business transformation; it does not typically guaranty when and how rapidly an organization will realize benefits from the change. DevOps is the continuous delivery and integration framework to provide such agility and the ability to move quickly to execution, experiment, validate assumptions, and manage investment risks while ensuring the best return on investment.

Minimizing business disruption

Disruption brings its share of challenges as organizations are not able to focus on their operations and deliver their core products and services. Nevertheless, it is important to continuously balance operations, firefighting with continuous improvement and planning for change. It is important to evaluate expected value and potential impacts from upgrades, balancing this with the implications and cost of “doing nothing”.

Minimizing disruption includes many factors:

• Being clear about strengths and weaknesses of the current enterprise digital platform(s).
• Understanding the current pain points and business priorities.
• Maintaining an accurate vision and value-driven roadmap, including for minor and major upgrades.
• Communicating upgrade justification, business case with budgeting planning, including ROI and potential “disbenefits” from production downtime and learning curve.
• Planning deployment steps with data, technical, people and business dependencies.
• Understanding in-house expertise and existing vendor governance.
• Streamlining business process education and simplification; making work more engaging content, focusing on adherence to standards.
• Embedding platform upgrades to wider application management services (AMS)—often described as a “standard offering” with SaaS packaged solutions, but which can also be implemented as part of any AMS and IMS models.
• Leveraging OOTB and integration optimization through “maintenance factorization” enabled by DevOps, automated testing and agile delivery methodologies.

DevOps practices goes beyond continuous improvement, they translate PLM strategy into execution, seamlessly. They contribute to both minor upgrade and major transformation delivery, bridging silos between technical and operations worlds. Validating deployment processes as part of regular minor improvements and upgrades can translate into a robust test-bench, ahead of the next business transformation initiative or major upgrade.

Expected key benefits from minor upgrades

Minor upgrades can share similar value with major upgrades, though on a possible smaller scale. Business benefits from minor upgrades can include:

• Process efficiency improvements and other business benefits across functions with regular upgrades, compared to seldom upgrades.
• Ongoing end-user education, increased satisfaction and work performance, reduced frustration, errors and work duplication
• Reduced business risks by embedding continuous learning and improvement roadmap.
• Increased adoption of OOTB capabilities, and reduced customization complexity—as enhancements are released, or simply as process adoption of the same platform expands into other business areas.
• Improved process usage and better usability, leveraging data and process mining to inform upgrade requirements and business case.
• Better maintenance cost and business disruption control.

So, what’s in it for me?

Multiple stakeholders in the organization will have different perspectives and expectations, here are some examples:

• From the COO and CFO perspective: will we be getting value for money from upgrades and are business risks mitigated?
• From the Engineering Director, Product Development Operations Director and Product Owner perspective: with the next upgrade, will we be able to scale and operate in a smarter way across internal teams and the global supply chain?
• From the CIO, IT Director and IT / PLM Manager perspective: will the upgrade deliver on-cost and on-time, how will business expectations be managed throughout, how will technical issues be dealt with, how will data and integration risks be mitigated, etc.?
• From the Business Transformation Director perspective: how to prioritize an upgrade versus another one, how and when will the business realize value, how will end-users be educated, is the organization designed to maximize value from the change?
• From the end-user perspective: what enhancements will the upgrade provide, will it make my life easier with better processes, automation and capabilities? Are the issues that I previously reported addressed with the upgrade? How much effort will I have to spent to get up to speed with the changes, and will I be supported as a user when I have a technical question?
• From the support / helpdesk engineer perspective: will the upgrade provide better or maintain the existing support tools that I use on a daily basis? Will it provide a more robust and stable solution for the end-users and reduce the level of support required?

What are your thoughts?