Learn effective cloud ERP implementation methodology
Each cloud ERP implementation methodology has its pros and cons. Learn more about each strategy and decide which is best suited for your organization.
An ERP system implementation is daunting. The system change will likely affect many employees across your organization as well as vendors and customers.
Taking on such a large project can in fact bring significant risk. Project leaders must choose the best implementation methodology after consulting with key stakeholders, the software vendor and implementation partners.
Here's more about different methodologies as well as their pros and cons.
Big bang approach
With the big bang methodology, you implement the whole system in one big project, with one go-live for the whole organization. This approach is a good fit if dividing the project into sub-projects would negatively impact the end-user experience.
- The big bang approach is typically the fastest way to deliver all the ERP functionality to your users.
- The software is complete at go-live and doesn't rely on old systems to fill in the gaps.
- Training is developed and delivered for the whole system.
- Overall costs are likely low because the implementation is shorter, so HR costs are lower.
- You are less likely to lose key resources partway through the project because it will take less time.
- A problem in one area can impact the go-live schedule for the whole project.
- Trying to deliver all the functionality in one release can be more complex than other strategies.
- You have to implement additional functionality before using and understanding the intricacies of the foundational ERP system.
- You must convert data from multiple systems at once, so data migration is likely more complex.
With a phased approach, you subdivide the project into multiple smaller projects. For example, Phase 1 may deliver core functionality, while Phase 2 brings additional, less-critical functionality. Phase 2 may include additional modules, integration with a third-party application or seamless integration development with your organization's other systems.
- Delivering functionality in multiple smaller projects is less risky.
- You can learn how the ERP system works during Phase 1 before starting the next phase.
- Your implementation team will likely be smaller, so communication is easier.
- Fewer features must be configured and delivered at go-live, reducing complexity.
- Training is more focused because only some of the functionality is available.
- You can revisit who is on the implementation team after each phase without major disruption to the program.
- Overall program cost may be more expensive since implementation will likely take longer.
- Employees, contractors or implementation partner employees may depart after each phase because it's a natural time to leave the project.
- Employees may have to temporarily continue using older systems and processes because the systems and processes won't be streamlined until the next phase.
- Training will need to occur multiple times because the project has more than one phase.
- Employees could be frustrated that required functionality is delayed until a later phase, potentially impacting change management.
With this approach, your ERP implementation occurs in multiple phases based on the needs of your organization's predefined lines of business. For example, you may carry out the ERP implementation for the company's American division, then the Canadian division, then the European division.
You could also divide your phases by product line. This approach combines aspects of the big bang and phased approaches. You can split the project into multiple smaller projects, as with the phased approach, then one line of business receives the full functionality for them, as with the big bang approach.
It's important to note that the project team may require contributions from employees who haven't experienced the ERP implementation. For example, the core functionality, security and reporting may be consistent across lines of business, but integrating with third-party vendors may be regional and only require the current line of business's support.
Here are some pros and cons of this approach.
- Overall program risk is lower because you're delivering functionality in multiple smaller projects for specific lines of business.
- You may be able to defer more complex requirements, such as the need to support multiple currencies, until a future phase.
- You can deliver one line of business's required functionality in one phase.
- You can prioritize releases based on the needs of lines of business.
- You will have experience from previous implementation projects when working on the next ones.
- You may have to redo earlier work to accommodate requirements for other lines of business.
- Many of the most important project decisions are likely decided during the first phase and could be difficult to change as other lines of business come on board.
- Prioritizing one line of business without causing organizational political issues could be challenging.
Convincing resources to participate in releases that don't directly affect them could be difficult.