PLM Platform Upgrade: Leveraging OOTB Capabilities, Flushing Old Customizations, Refreshing Interfaces

By definition, business change and improvements are an ongoing and iterative process. Regular enterprise platform upgrades contribute to enabling competitive advantage. Upgrading means getting the latest platform improvements and capabilities, leveraging the latest ‘best practice’, bringing further stability and scalability improvements—rather than simply about extending enterprise software support and warranty shelf-life.

Upgrading for the sake of upgrading is not a valid goal; it must be value driven. Expected business benefits are often not easily qualified and quantified; there are different schools of thought about how to estimate value. This is not a reason for not defining the rationale for value realization, or for not planning digital platform upgrades. Again, this is part of ongoing business risk mitigation and operations planning; upgrades can bring both value-added enhancements and unexpected changes which might imply significant technical and integration challenges. It is clearly a about balancing pains and gains.

In this post, I elaborate on business value assessment, opportunities and challenges, risk mitigations and required trade-offs when embarking on a PLM platform upgrade.

When only focusing on functionality, business and IT leaders can be surprised to realize that enterprise solution upgrade come at a price to the business. However, with the rise of new business models, number of cost elements are being re-shuffled from CAPEX to OPEX, and vice et versa. SaaS models address this perception in bundling levels of ongoing maintenance as part of the software rental.

On one hand, upgrades can be perceived as an unnecessary expense, something that should be part of a holistic operating model. For organizations with multi-million-dollar PLM and ERP systems, there are better reasons for upgrading than “vendor support of an old software version is about to expire” or “let’s upgrade because there is a new software version available now”. This is a little bit more subtle than that.

On the other hand, nothing comes for free; successful upgrade strategies focus on ongoing budgeting and future capability planning—with a clear line of sight of the holistic operating models (modus operandi across both business and IT combined perspectives). This is also why many organizations actually redefine the role of IT as a business strategic function in itself, rather than simply an enabling function.

Leveraging OOTB capabilities, flushing old customization

Upgrading to a more recent platform must give the business access to new capabilities, functional enhancements and bug fixes, potential performance improvements, new APIs and configuration requirements. In turn, this provides opportunities for improving existing processes and current working practices:

• What business functions would benefit from the change?

Levels of change come from upgrades. It is essential to understand what change and its implications to all relevant business functions: both existing and potential new users, and what will it means from an operational stability perspective.

• What would they have to learn, or change compared to their current working practices, and how differently would they have to operate afterwards?

Minor changes can have significant implications to operating procedures, if not from a user point of view, possibly from the perspective of existing support teams. Both aspects need to be understood.

• Does the organization understand the risks and mitigations related to “doing nothing” versus prioritizing an upgrade?

Risk comes from change; risk also comes from the lack of change (i.e., “doing noting” and maintaining the status quo). There are multiple types of risk: operations, scalability, supportability, integration, data quality, business disruption, education, etc.

• Would there be any organizational design change implications?

Upgrades can trigger opportunities for further organizational re-alignment and maximize value and operating efficiency. This could be materialized by improvements associated with the upgrade itself or by actualizing previous opportunities to catch-up with known adaptation requirements which are overdue.

• Would the upgrade bring to the business opportunities to use more effectively or efficiently processes and tools available within the current platform?

Upgrades, even the simple ones, can contribute to unlocking new ways of working by using better or more the existing solutions, refreshing learning programs, etc. Many organizations do not maximize all platform capabilities that they purchase or rent, just because it was too much of a change in the past, or because the enterprise software came as a bundle with many unused capabilities.

• What new functionalities and enhancements would be expected going forward, and what value would they bring (time saving, automation, extension of existing process, etc.)?

Understanding (sometimes re-assessing) what is “in the box” can be a valuable exercise to plan improvements and re-shuffle operational efficiency expectations. Upgrades can contribute to improving data governance and reduce the need for new IT tools and systems to be introduced to fill perceived gaps.

• Would there be opportunities to reduce current complexity, remove past customizations and adopt new out-of-the-box (OOTB) capabilities?

Integration, customization and configuration are normal enterprise platform implementation paradigms: continuously looking at ways to simplify the technical landscape includes looking at ways to remove or improve custom code solution elements.

Reducing TCO, comparing with the “cost of doing nothing”, refreshing the integration landscape

As one enterprise solutions get upgraded, integration solutions can also be impacted. Hence the need to look beyond the boundaries of one IT system or another. It is important to look at the business as one wider “system” within which the IT software and processes reside. Minor upgrades can have significant cost implications on skills, suppliers, customers, support functions, and obviously on cost.

Hence the need to look at the total cost of ownership (TCO) across the platform and its boundaries, considering opportunities to:

• De-customize / re-customize with smarter and lighter configurations and customizations while upgrading.
• Capitalize on industry / PLM process, data and platform knowledge from implementation partners (lessons learned from other upgrades).
• Leverage offshore build capabilities to deliver technical activities in a cost-effective way.
• Implement DevOps practices to foster continuous delivery and integration, leveraging agile deployment practices when delivering platform upgrades— both from the technical and business change perspectives; consider testing automation solutions to “industrialize” upgrades and changes going forward.
• Offset upgrade investments with new value realization directly benefiting the business; mitigate the cost of doing nothing by reducing / removing non value-added activities (reducing recurring maintenance, sub-optimum workarounds, temporary patching, removing manual or semi-automated interfaces with automations, etc.).
• Adopt cloud and SaaS solutions whose regular upgrades can be fully managed by the solution provider; understand the implications of using multi-tenant installation bases, data security and export control requirements based on the industry, etc.
• Balance the use of on-premises / hosted / managed infrastructure as a service for enterprise platforms and related hybrid integration.

What are your thoughts?