PLM System Integrator – part 1: selecting the right implementation partner
Implementing PLM solutions and other digital platforms is no trivial task, especially for organizations with complex product portfolio and manufacturing processes, workforce and supply chain on a global footprint, significant legacy processes, data and systems. Such initiatives are typically multi-year programs as new capabilities and continuous improvements get added, new integration points implemented, new apps developed, new data created, etc. The next consideration after planning and selecting a new PLM platform is to define how it will be implemented, when, and by whom (as “the devil is in the detail”). Different delivery approaches can be considered based on the type of implementation, from simple process improvement, capability introduction, integration development, regular system maintenance and upgrades to more fundamental business transformations covering all of the above.
In this post, we discuss characteristics of PLM implementations, types of services required, roles of service providers, considerations for appointing a System Integrator, delivery and engagement models, and related commercial implications. We also highlight how upgrade services might become part of SaaS offerings, and to what extent.
The scope of PLM is vast; so is the scope of work related to implementing PLM solutions (including but not limited to the IT tool itself): from process to automation requirements, efficiency optimization, IT integration, data migration, education and training, business change, etc. Implementing PLM solutions involves series of activities, as varied as: stakeholder alignment, planning, budgeting, procurement, technology selection, supplier selection, data discoveries, process re-engineering, contextual and cultural factor adaptation, solution design, stakeholder management, business change communication… and on the IT side, infrastructure architecture design, installing software, coding, testing, documenting, etc. These also apply to any digital platform projects, from ERP to CRM, IOT…
There are typically 5 core functions to consider when implementing enterprise platforms and business change solutions:
Business change governance, strategy and scoping: covering from problem statement and initial requirement analysis to change roadmap, budgeting, internal governance, deployment and data cleansing strategies, vendor and implementation partner selection, benefit realization tracking, etc.
Platform / tool vendor: bringing expertise and design support to defining the infrastructure, fixing issues, tuning performance.
System Integrator: supplier driving the change, taking responsibility for the overall solution delivery and operational coordination of all related stakeholders, building and deploying the PLM solution “as built” and until post-go-live stabilization.
Infrastructure supplier: designing and delivering the IT connectivity for each phases of the implementation, in collaboration with the system integrator and the vendor.
Maintenance and support supplier: supporting the operational or run phase of the solution, incl. post go-live transition to Business-As-Usual (BAU) service level.
The above mix might differ based on how much an organization prefers to outsource, based on internal knowledge, efficiency and risk mitigations.
Expectations from a System Integrator
There is possibly a different definition of a “System Integrator” per platform vendor... At a macro level, a System Integrator can be simply defined as follows:
“A System Integrator brings together all elements (sub-systems) to ensure success of the selected solution—managing scope, coordinating all stakeholders involved, ultimately solving the problem as initially stated.”
The System Integrator is expected to:
Bring the required expertise, technically and managerially, to deliver the solution.
Build trusted relationships with the relevant stakeholders.
Plan, design, build and deploy the solution to the business.
Interface with vendor(s), and other parties, internally and externally of the organization: e.g. IT and infrastructure suppliers, maintenance and support suppliers, etc.
Have “skin in the game” when delivering the solution—i.e. having incentives to make the initiative a success.
This last point is important as a significant incentive is typically commercial and reputational. Commercial incentive(s) typically reflect on delivery and engagement models implemented with or by the System Integrator.
Commercial incentives and implications
Based on context, the System Integrator might be the single “throat to choke”, often with full authority to manage and contract other parties under a “prime contract”. This approach is likely to have expensive price tag as it would include the relevant contingencies; however, it can contribute to significantly reduce risks with fixed-price commercial terms, sequential milestone payment on delivery, shared contingencies and other control mechanism. Such contracts can be complex and rely on procurement and commercial experience on both sides (buyer and service provider).
Different challenges might occur depending on which party is the prime implementation partner. For example, when the platform / tool vendor is also given the System Integrator role, there can be a premium charged to the organization on all services. In such cases, the delivery approach is likely to align closely with technology / platform roadmap—a positive for future alignment, gap or issue resolution—however, not always a pragmatic option, often a time-consuming approach.
With SaaS options, there are obviously new considerations about the above, especially when the Vendor / System Integrator is also to be the de-facto maintenance and support supplier if the solution is hosted on their (or their partner’s) infrastructure.
Other hybrid commercial models might include different lines of ownership by solution components or role in the implementation, such as multiple build suppliers based on given solution elements (e.g. integration solutions between specific technologies or platforms).
Delivery and engagement models
Depending on the commercial model, delivery and engagement models will have specific:
The delivery framework defines how the solution will be orchestrated: e.g. Waterfall vs agile, proof of concept followed by production pilot vs multi-phase deployment with gradual integration and data migration, etc.
The engagement framework defines the interaction, communication, risk mitigation and issue resolution approach, e.g. governance model, escalation and change management, roles and responsibilities, scope boundaries and other delivery parameters which relate to the commercial model.
In part 2 of this two-part post series, we will elaborate on the selection criteria to appoint a System Integrator when running PLM implementation RFQs, things to watch-out for, critical success factors, commercial and delivery risk mitigations.