The more thought that goes into a transformation from an ERP system, before the technology implementation starts, the more successful the transformation will be. More value will be delivered to your organization, mitigating, and minimizing the risks before implementation.
- Align your transformation to your strategy. From your Go-To-Market strategy to your overall architecture and roadmap, having a clear vision of where you want to go makes getting there much more likely.
- Strategy alignment will also generate clear objectives for your transformation program and can include principles that will drive the design of your future operating model. Objectives must be accompanied by KPIs that baseline your current performance and demonstrate the improvements that the transformation will deliver.
- It is crucial to obtain executive sponsorship at this stage. Commitment from the top, which should include resources, demonstrates how important the transformation is to your organization.
- CPQ specific preparation – product & pricing rationalization. Typically, products and pricing evolve over time; products are added and pricing models change, often without retiring the previous ones nor providing a holistic view of the desired future state model. This results in product proliferation and pricing complexity. Your transformation is an opportunity to rationalize and remove complexity, retire old products, and to simplify your pricing models. Without rationalization, products and pricing can take longer to design and build, and you may pay more for their in-life maintenance after the implementation closes.
Delivering value early and via phases has many advantages. So I am always surprised when programs go for a “big-bang” approach. On paper, a single large release may look cheaper, however:
- The delivery risk is higher. There are more things that can go wrong with less time to correct, more stakeholders to engage, more integrations, and so on.
- On paper, multiple phases may take a little longer and therefore cost more. However, in practice, big slips are far more likely with a single release.
- An initial phase starts delivering value earlier. If you look at the business case, your program may not start to self-fund right away, but it is certainly likely to offset the additional cost of multiple releases.
- An early release gives you the ability to flex as your business changes and act on feedback, by incorporating changes in subsequent releases, as well as building momentum and positivity around the program.
- Collecting valuable data from super-users during the process helps make their usage rate higher as you are incorporating their opinions and suggestions for making their jobs easier and more efficient.
- You need to choose a way to split your scope into multiple phases; typical dimensions are Business Unit / Team, Region, Country, and/or product categories.
Finally, after your first go-live, you can start to measure the KPI improvements against the baselines you previously defined. You should plan for a culture of continuous improvement, and consider how your new solution will be supported from business and technical standpoints. We hope you find these recommendations useful.
