It is critical to clearly define the business case and why your organization is planning the cloud ERP implementation or upgrade. The project sponsor and executive leadership must share a common vision for the project as lack of alignment may result in a failed implementation with potential cost overruns.

Merely going live does not constitute success. Unless the project achieves the benefits outlined in the business case, it will not be seen as successful.

This risk can be remediated by conducting leadership interviews prior to the launch of the project highlights any serious gaps among the leadership team and provides an opportunity to address potential issues.

Implementing a new business technology system such as an ERP means changing how work gets done. To ensure your organization is ready for change and deliver the expected ROI, you must plan for organizational readiness prior to launching the project.

This includes defining the potential scope of the project at a high level and assessing internal bandwidth. Both process owners and the IT organization should be ready to allocate sufficient time and internal resources to the project because employees carry the native knowledge of the organization. Sometimes, that knowledge is irreplaceable.

To ensure you have the necessary internal expertise on board for the project, conduct a formal organization assessment prior to launch. Identifying gaps after project launch could be very expensive and lead to project delays.

Selecting the right system integrator is the key for implementation success. This requires prior experience working with system integrators and subject matter expertise in the relevant ERP systems.

• Perform due diligence and conduct reference checks.
• Assess the onshore/offshore capabilities as well bench strength.
• Consider the cultural fit.

Drafting the SOW is a special skill and needs prior experience. Sometimes, it requires relatively deep subject matter expertise to ensure that critical items are not ignored in the SOW. It is advisable to engage an independent firm to help with the RFP process and SOW creation. This helps ensure the least ambiguity in the scope of the SI’s work and deliverables

Adoption is key to the overall success of the project beyond go-live. Often, change management is pushed to the later part of the project, leading to go-live issues and poor adoption. The best practice is to plan adequate change management and spread it across all phases of the project including pre-planning. For example, the RGP Return on Change™ Framework starts by aligning leadership and creating a shared vision for the change journey.

Training is another critical component of the implementation that needs adequate planning. It’s best to engage a training planner and work closely with the system integrator to establish proper checks and balances on the adequacy and effectiveness of the training.

The leadership team and key process owners need to understand that cloud ERPs are not customizable, and set clear expectations across the organization.

Although it’s possible to do some personalization, such as capturing additional information the organization needs, system users are expected to adopt and adapt the ERP vendor’s standard functionality. Also, users will not be able to directly connect to the database and download data to produce ad hoc reports as they can with on-premise systems and will need to adopt the standard reporting tools.

• Work with subject matter experts and the ERP vendor to understand the overall functionality of the cloud ERP.
• Review the mission-critical business processes up front to ensure alignment across the organization.
• Discuss the reporting strategy with internal IT department in conjunction with the ERP vendor and system integrator.

Implementation strategy plays a big role in the success of the overall project. In a worst-case scenario, companies can spend millions of dollars and then end up scrapping the entire implementation because they thought they could execute it all at once—but couldn’t.

Some organizations choose to start by implementing in a single business unit that is least risky to their company’s operations, while others choose to tackle the big ones first. Either way, it’s best to gather the requirements globally—involving all the key process owners across all locations—even if you’re not implementing all the processes in the first phase. In other words, gather requirements globally, execute locally. This minimizes the risk of designing the system without the complete list of requirements on a global basis.

Projects often get delayed when you attempt to implement too much functionality in too little time. For example, trying to retire too many legacy systems at once is cumbersome and takes away bandwidth from the users. It’s important to assess the impact of the ERP implementation on legacy systems and minimize the need to develop integrations to legacy systems as much as possible.

Also, changing core business processes and operations dramatically increases project risk. Implementing core finance functions such as general ledger, accounts payable, fixed assets, etc., is somewhat less risky from a business point of view, compared with moving the material master and bills of material to the new ERP system.

Assess the internal resources and budget availability before finalizing the scope of the implementation. Implementing the new functionality in a phased manner not only minimizes project risk, but also operational risk.

Unlike traditional ERP implementations that follow a waterfall methodology, cloud ERP implementations use a hybrid waterfall/Agile methodology. This allows for iterative development and enables users to see real data and processes at each stage of the project.

Planning for a cloud ERP implementation should include a project risk assessment to understand and proactively mitigate the risks across the following categories:

Process: Every organization believes their critical processes are unique. But cloud ERP systems are not. Key leaders must set the expectation that you will not be able to customize the new system to fit your old legacy processes—and users will need to adapt to the standard out-of-the-box functionality. And the more highly customized your legacy processes are, the greater the risk.

Data: Depending on how long the legacy system has been in place and how well it was maintained, bad data could pose a high risk to the implementation timelines. Even if the data is good, you will need to map the data to the new ERP system and validate it up front. You’ll also need to be ready to validate and provide clean data to the system integrator for an on-time go-live. To avoid potential delays caused by data issues, define the data validation strategy upfront, as well as assessing the data quality, taking advantage of external help as needed to clean it up. Be sure to engage internal and external data migration and governance experts and establish a separate project track that focuses on the data.

Integrations: Having to develop too many integrations could pose a high risk to the project timelines and budget. Most of the time there is a dependency on a third parties such as banks, vendors, customers, and so on. Adequate planning is required to ensure enough time is allocated for development and testing. Having a dedicated instance for integration testing helps mitigate the risk as well.

Reporting: Often, reporting is pushed to the later part of the implementation phase. The best practice is to review the reporting requirements alongside other requirements during the design phase. There’s an interdependency between the system architecture and reporting. For example, the chart of account structure determines the financial reporting capabilities, so it’s essential to gather the reporting needs and the key performance indicators (KPIs) that you intend to use prior to signing off on the overall design.

Security: Depending on the size and complexity of your organization, security requirements should be consolidated and considered upfront during the planning phase. This includes your organization’s security policy, data privacy and security needs:

• Launch a separate track for security and monitor it closely.
• Have the financial controller or other finance leaders confirm and approve user security and SOX requirements.
• Consider the post-go-live support structure and corresponding security.

There’s often a misconception that cloud ERP implementation does not need “as-is” process documentation since the system cannot be customized. However, unless you document the current processes, it will be difficult to understand what is changing and adequately plan for the change. Clear documentation of both as-is and “to-be” processes is vital.

The best practice is to create the high-level to-be process documents and have key process owners sign off on them before launch. This reduces cost and poses less risk to the overall implementation by getting agreement across the functional owners.

Before going live, you have to verify that all the systems, processes and data are working the way they should to meet both the business and technical requirements. The system must be tested multiple times during the life of the implementation, from testing scripts to integration testing to user acceptance testing. We advise engaging the QA team early on. A poorly tested system leads to adoption issues.