When tracing the roots of cloud ERP project failure, the trail often leads back to what we call “Phase Zero,” the pre-kick-off strategy and planning that can make or break project success. This is where important organizational aspects of the transformation get hammered out, such as staffing, planning, timelines, and how the program will run alongside the business. Get the guide here to start preparing for a smooth move to the cloud.

One of the first critical activities is to set up your PMO, the nerve center for managing the transformation effectively. And executive sponsorship is key, as successful change is driven from the top. The PMO team should be composed of multiple people who are responsible for supporting different aspects of program management. In addition to the program lead, who is responsible for the day-to-day program management, you need someone who is responsible for overseeing the budget, resources and other business details. You also need a communications specialist who drives internal program communications and company-wide communications such as branding, an internal webpage, etc. (We’ll go into more detail about the specific functions of these roles below.)

See how we helped Solidigm go live with a full-stack SAP S/4HANA system on time and deliver results nearly a year faster than plan, rescuing $70M+ in revenue.

Do not assume that the SI will handle resource planning for you. They may describe various methods for how you can staff the project, such as a hybrid workforce or a fully dedicated team, but the decision will be up to you. There are a lot of organizational considerations affecting staffing decisions that the SI won’t get involved in managing. For example:

• How many people do you need on your team
• Where should they come from?
• How will their day jobs be covered?
• How are you going to backfill those roles?
• If you take people out of the business and put them on the cloud ERP project full time, are you going to give them their jobs back afterwards?

This may seem like a simple line item, but there are big implications before, during and after the actual implementation.

The SI may say they’ll do a project plan, but it will be entirely from their point of view and will only contain client project milestones. Without project management support, you won’t have the roadmap of smaller tasks necessary to accomplish the milestones. Additionally, the SI will be focused only on implementation tasks and not those that are associated with other business activities that might be necessary. So you may go into the implementation without realizing that the SI has overlooked important milestones.

SIs will not do your “as-is” to “to-be” mapping for you. They’ll provide the “to-be” processes for the new system but will not show what processes need to change. All of those process-associated decisions are really in your hands, not the SI’s. That means you need to conduct a gap analysis between the way you work today and the way you will have to work using the new system. This gap analysis should start early during the design phase — otherwise, you’re not capturing the information you need for testing and training purposes (see Communication and Training below).

The SI will give you templates for moving data from one ERP system to the other, but they aren’t going to fill out the template for you. Data objects have to be captured in the existing system and mapped to the new system. You then have to extract your data from the existing system and cleanse it before moving it over to the new system. There’s also potential for data governance issues with the migration, so if you haven’t already done so, this is your opportunity to put proper data governance in place.

Your data includes both transactional and master data. The SI will focus on the master data, and transactions may not get enough attention. For example, you need to ask:

• How much transactional data are we bringing in?
• When are we going to stop putting transactions into the existing system?
• How does that impact the business?
• What transactions do we need to pause or might we need to put in both places?
• What methodology will we use to handle those transactions?

As the client, you are 100% responsible for test scenarios and test scripts and for preparing for user acceptance testing (UAT), including determining who the testers should be, which roles should have access to the system, etc. Test scenarios go hand-in-hand with documentation. Remember that “as-is” to “to-be” process mapping you did during the Design phase? That is very useful for building and preparing your test scenarios and your test scripts.

If you don’t have someone who is accustomed to serving as a testing lead, this responsibility can be very overwhelming, as can the role of cutover lead.

Before giving the green light to continue with implementation, the cutover lead will be responsible for talking to all the functional business stakeholders and making sure that the transaction end dates are maintained, that the transactions actually do stop, that the loads occur successfully and that the data is validated. This is all done from the client’s perspective — the SI does not give you the thumbs up for when you’re ready to go. So you really need professional guidance to guide through all the data aspects.

The SI will not provide training about your new processes. They will give you hands-on keyboard training on how to use the new system. It will be your responsibility to train your people about process changes.

The initial review of the SI-provided training documents often comes as a surprise because they don’t contain any desktop procedures. As a result, clients are often left scrambling, when they suddenly realize that they are responsible for pulling the training team and training together. This creates a knowledge deficit in the training team when they are brought on.

The team also has to create an immense amount of content in a limited amount of time. User adoption of a new system is tied to confidence after training, so it’s imperative that your users don’t leave the training feeling like they don’t know what they are going to do on Day 1.

Ongoing communication during the project also increases user acceptance. If the program is operating in a black box, users will begin to grow apprehensive about what is happening — and may even fear organizational changes. The SI does not provide this type of change management support as a standard part of the implementation but will generally support it for an enhanced fee.

Frequently, when you get to user acceptance testing, you’ve had to determine what minimum viable product would be required to go live — and you’ve likely had to leave some things out, which will need to be implemented later as enhancements. Or, you may have things that are laggers and still going through testing, which are going to be implemented after the initial go-live.

To close the “bells and whistles” gap that often occurs, you will need to prioritize which enhancements to address and determine the right resources and timing for working on them.

You need to project manage potential support issues and ongoing testing during the hand-off from the SI to your team. And, unfortunately, it’s sometimes easy to lose track of monitoring the SI for commitment to finish things. You may have to rigorously monitor the SI and continue to manage and remind them, “No, we went live with the minimum viable product, but you have to help us implement the rest of it.”

This ongoing enhancement and final completion of implementation has to be project managed more intensely from the client-side post-go-live and on an ongoing basis.

After go-live, your SI may be “done” even though there’s more to be implemented. If you’ve omitted things that will need to be added, you’ll have to project manage that. Also, your SI will not help you establish what your go-live support structure is going to look like. They will expect you to decide how to staff the post-go-live activities and address questions that come up. For example:

• Who are questions going to go to?
• How are you going to triage issues?
• Are you going to have a ticketing system?
• Are you going to have an email address?
• Who’s going to be staffing it?
• Who is going to create the report for executives about how the project is going and whether it is falling apart or working?

There’s a lot of reporting that comes out on a daily basis from hypercare, and you need to have the processes in place to be able to do it.

Expert Guidance to Bridge SI Gaps

As you can probably see, there are many aspects of a cloud ERP implementation that are not part of your SI’s statement of work — critical workstreams that can make the difference in how successful your organization’s migration to the cloud will be. Put simply: the devil is in the details, and RGP and Veracity are here to help drive project success across every stage of the transformation, from strategy and planning to project execution to change management.

Our expert consultants have supported our clients with hundreds of successful system implementation and optimization projects. We work as an extension of your team to bridge gaps and advocate for your interests to ensure all the details are accounted for in the project plan and that the SI completes the work to your specifications.

Learn more about how RGP works as a force multiplier to drive successful execution of your cloud ERP migration or visit our Cloud ERP Resource Hub for more practical insights and guidance.