Deployment activities are integral to enterprise platform implementations, following user acceptance, as all workstreams converge together.
All PLM-ERP-MES (product lifecycle management-enterprise resource planning-manufacturing execution system) platform vendors, system integrators and other management consultancies have developed bespoke methodologies and templates to accelerate implementations—often tailored to the industrial context and relevant enterprise platform. They typically focus on requirement assessment, vision definition, roadmap development, business case justification, process and data discovery, blueprinting, business change, testing iterations and so on. Such frameworks often lack clarity in defining deployment strategies and transition planning, including the associated risk mitigations.
Project management methodologies such as PMBOK (Project Management Body Of Knowledge) or PRINCE2 (Projects IN Controlled Environments) are fairly light when it comes to deployment strategy development, execution methodologies and templates. Enterprise platform deployment covers transition dry runs, cutover, data migration, user training and critical business communications, combined with possible fallback scenario planning and execution. Time is often critical when running deployment activities, hence the need for speed and accuracy is essential to minimize business disruption when deploying enterprise platform solutions.
In this article, I elaborate on what it takes to effectively deploy enterprise platforms, from solution readiness to deployment readiness, cutover planning and rehearsals, risk mitigations and rollback scenario planning, and the need for speed when executing cutover.
Deployments are about readiness, preparedness, rehearsal, cutover and fallback mitigation, combined with timeliness, accuracy and speed. Deployment plans, independent of the platform, are detailed task driven. They include detailed checklists, coupled with step-by-step checkpoints that require go-forward decisions before proceeding to the next list of activities. Contrary to many other implementation planning activities that can be managed at a high-level, deployment activities must typically be micromanaged and automated where possible to ensure a quality and timely completion.
Deployment success relies on many factors that cover solution and transition readiness:
- A mature and stable solution (process, tools, platforms, interfaces, data, training, etc.)
- A tested and approved solution—key user sign-off of the above, in addition to nonfunctional and data migration validation
- A robust and effective cutover plan, with associated execution scenarios
- A rigorous rehearsal plan (aka “dry runs”) to ensure that the cutover plan and all prerequisites have been completed
- An exhaustive mitigation plan with the relevant rollback scenarios, including business implications
- An iterative process for continuous deployment to foster change adoption readiness
From Solution Readiness to Deployment Readiness
Adopting new PLM or ERP solutions typically come with new capabilities, processes, modi operandi, business changes and many technical aspects. Transition to the new solution includes:
- Change readiness: Have key users been properly involved in learning and testing the solution? Have they been positively embracing the change and promoting its value? Do they understand what it will take for the project team to deploy the solution and how they are expected to support it?
- Data model and business rules configuration and customization to tailor processes: Are there new processes, features and functionalities that cover the initial requirements? What requirements were not met, and what might be the work-arounds? What additional requirements have been met?
- Data migration from legacy systems to the new platform. Alternatively, this can be from one app to another within the same platform, if new or improved processes require data augmentation, or possibly importing files into platform and apps.
- Product structure and modular BOM information (and other domains) adaptation to the required integration and data requirements: Is the master data governance coherent across the enterprise, beyond the scope of the solution that is being deployed? In other words, is the solution future-proof and does it align with the wider operations?
- User training: Is the program ready to deliver user training prior to deploying the new solution? How long will it take for the users to be productive with the new processes and tools? How will they adapt and learn, and how will this impact their productivity over the short and medium term?
As Schmitt and Anderson (2010) pointed out in a product marketing information (PMI) paper: “the focus of project management is on the delivery of a product or service. Often, little thought is given to the care and feeding of the product or service after it has been delivered.”
From Cutover Planning to Execution
Furthermore, in that same paper, Schmitt and Anderson (2010) highlighted the need for formal deployment (aka cutover) planning to ensure that the solution is not “thrown over the wall” to avoid eroding (sometimes negating) the business value and the good work done prior to deployment (including platforms and apps, but also people, process and data alignment elements).
“There is value in giving this deployment process a formal name and defining a set of disciplines to ensure that it is completed, along with the other project management processes” (Schmitt and Anderson, 2010).
When deployments go wrong, the de facto standpoint is to blame the solution, the vendor, the implementation team, the IT function, or a combination of all these factors.
On the one hand, it is rarely acknowledged that an organization was not ready for a deployment, or that it had unrealistic expectations about the speed of a deployment and what level of disruption it might create.
On the other hand, as Schmitt and Anderson (2010) pointed out, it is also possible that “the project was technically successful because it met all the requirements and was accepted by the customer, but still was a business failure.” Hence, they highlighted the importance of “the timing of the release, training, and accountability.”
Cutover planning includes many aspects, from business communication, requirement traceability, storyboards and methods, go-live approvals and iterative notifications to ensure data and business readiness, both prior to and during cutover. For instance:
- Will the data cleansing activities be performed prior to cutover or during the deployment?
- Are clear accountabilities established and will the onus of deploying the solution be shared across the relevant functions (e.g., implementation partner, internal IT, HR, key users and floorwalkers, transition and support teams, suppliers, procurement and so on)?
Rehearsals to Ensure Deployment Success, Including Rollback Scenarios
Planning is essential, but it does not beat practice. Practice and “dry runs” contribute to making the plan real and improving or validating deployment assumptions. Even if technical changes are minimal, it is important to test how the solution will be deployed on a step-by-step basis. This will contribute to identifying issues and finding solutions. It will help to minimize production disruption by doing this in full-scale pre-production environments.
Deployment rehearsals focus on scripted testing, following all required steps to transition from pre-production to production by:
- Testing for both manual and automated deployment activities, from a full-scale production “clone environment” in a simulated, albeit realistic context
- Completing data migration activities, validating the final reconciliation assessment, and anticipating data errors and exception management
- Confirming deployment activity timings and sequencing
- Bringing support teams up to speed with transition and knowledge transfer activities, as well as anticipating data exceptions, business Q&A and support requirements
- Validating the solution prerelease process and adapting communication plans toward production transition readiness
- Testing rollback activities and other mitigations
There are different transition strategies when it comes to deploying new PLM or ERP platforms (with their associated processes, interfaces and user trainings).
Toward Continuous Deployment
Transition strategies are often selected based on legacy landscape and data complexity, as well as potential business implications. Phased deployment and a coexistence approach (parallel or “overlay” running) are typically preferred, compared to a “big bang” deployment, as they reduce business risks, albeit they also increase complexity and total cost of ownership with dual maintenance requirements
Interestingly, Roberts (2020) noted in the Digitalist Magazine that “deploying even small changes to ERP systems can take a huge amount of time due to long, outdated release cycles and concerns about risk and stability,” and promoted the use of a DevOps framework for deploying enterprise solutions to foster agile developments and a culture of collaboration. The goal of leveraging such tools and processes is to coordinate and automate deployment activities across multiple platforms, apps and interfaces, from, as Roberts puts it, “requirements through to continuous integration, deployment, and improvement.”
As part of their SAFe framework, Scale Agile defines continuous deployment as “the process that takes validated features in a staging environment and deploys them into the production environment, where they are readied for release.” The framework is clear, and processes and tools exist that can be adopted by every organization—as soon as they can overcome their operating and cultural challenges in becoming more agile, rather than just “doing agile.”
What are your thoughts?
