Chapter 4: Implementing an ERP software

When bringing about change, the process often looks a bit like this:

Assess for change- > Prepare for change -> Plan for change -> Implement the change -> Sustain the change So far, we’ve been dealing with theoretical knowledge. We’ve assessed why we need the change, we’ve prepared and planned for it. The next step is implementing the change—in this case, the ERP. And it begins with understanding what will make the change successful and positively impact the business.

Going forward, we’re putting the knowledge we’ve gained so far down to actionable uses. This is the part of the process where all the research and prep come together to create and configure your desired ERP system.

In favor of Agile implementation

There are various Project Management methodologies. Two that are easily recognized are the Agile Methodology and Waterfall Methodology. There is a significant difference in how these two methodologies approach things.

The Waterfall Methodology is a linear, sequential model. The project work is broken down into phases, and each one starts after the previous one ends. All the requirements are gathered first, the strategy is shared, approvals received, development initiates and goes into multiple user acceptance testing rounds, master data is collected, then the implementation (finally) begins. A significant amount of time is also spent in documenting the business requirements, understanding them, gap analysis, etc.

On the other hand, in Agile, the implementation happens continuously using standard features of a software. As and when you (the business implementing the ERP) make the data available, it’s mapped into the respective module. Agile implementation follows an iterative model, which focuses on continuous improvement at every single stage.

Figure 4. Waterfall vs. Agile implementations

Most ERP projects are undertaken using the Waterfall approach, but there is a significant issue with that. ERP systems cover a vast and integrated scope and thus have many complexities that need to be considered. Often, not everything comes up at the beginning. Even before the implementation commences, requirements cannot be accurately predicted. It’s a very real possibility that the current system did not include certain required features. Requirements always evolve over time. When the Waterfall model is used, the implementation must often come to a halt to allow for these changes to be addressed, and decisions to take place. This causes implementations to drag on for many months, since it involves long phases of design, specifications, blueprinting, etc. Obviously, not ideal.

This is why we think an Agile implementation is the better way to go for any ERP implementation.

First, some Agile myth-busting

The myth that the Agile ideology cannot be applied to an ERP due to its sheer scope is based on several damaging misconceptions: an ERP implementation is too big to be managed by small Agile teams; the highly integrated ERP requirements cannot be broken down into vertical user-stories; development and testing cannot be done in the short “sprints” that are characteristic of the Agile model; the Agile method, which is used for constantly shifting, unknown requirements, cannot be used for a standardized software such as an ERP; the only way to perceive the value of an ERP is through using a fully built and integrated product, not incremental changes—you get the idea. Truth be told, Agile practices are a great way to mitigate the risks and challenges that plague ERP implementations.

Firstly, unlike the Waterfall model, Agile relies heavily on the constant presence and input of the business. It requires the implementers and business representatives to work together as a single, end-to-end team that’s focusing on using the same set of key performance indicators (KPIs). Successful implementation relies heavily on communication, which is made possible through this. It fosters a collaborative relationship.

It also works at a much faster pace. Agile replaces long, drawn-out planning phases with short sprints. This does not translate to a lack of planning. Rather, it aids the Project Champion to track outcomes, progress, and any challenges or bottlenecks that the implementation is facing. Agile helps break down the immense scope of an ERP into smaller feature-and-module based sprints, making it much more achievable for small teams to deliver. This also allows for an iterative process and highlights the value the ERP will bring to the business. To summarize, these are some of Agile’s key features that can be invaluable tools for implementing an ERP:

  1. Cross-functional teams.
  2. Sprint-based, incremental implementation cycles.
  3. Communication and transparency facilitated by scrum ceremonies and KPIs (more on that later!).