Using Agile Methodology for ERP System Implementation

Agile methodology for software development has been around since the early 2000’s.  It began as a way to move past the previous “Waterfall” Development methodology to solve shortcomings in the Waterfall Development process.  Until the advent of Agile methodology, software development was a long and linear process.

You can also listen to this article:

It required a large volume of documentation up front.  It then followed with lengthy technical specifications before coding could begin.  The process was highly technical, consumed a great deal of time, was expensive, and often found itself over budget by wide margins.

But the expense and length of time for implementation proved excessive and Agile Development arose as a way to address those problems.  Agile Development relied upon collaboration, self-organization, and managing change to deliver working segments of the software in short periods of a few weeks or months.  It relied less on documentation and rigid project management and instead relied upon releasing iterative segments of the finished whole.  Relying on teams, short sprints, and testing, this approach outpaced the Waterfall method and delivered superior software in a shorter time with less cost.

Borrowing from the Best

Despite its origin as a software development methodology, in the end, it is simply a “best practices” methodology designed to improve and streamline a process.  And as the philosophy of Agile Development matured, it found its way into other implementations as well.  Agile Manufacturing uses many of the same principals to respond quickly to customer demands.  It has become a critical step in the lean process for many companies and is one which allows faster response to customer trends and market shifts.  And now, companies are finding that it is well suited for the implementation of other complex software systems as well.

As more companies discover the benefits of adding an ERP system to their organization, they are often faced with the daunting expense and time-intensive nature of the ERP implementation.  Intuitively, many of these companies proceed with a linear adoption process like the old Waterfall methodology mentioned above, or, they contract to a third-party consultant who often proceeds in the same fashion.  But just as Agile methodology was superior in software development and as an improvement in manufacturing strategy, it has also gained footing as a methodology useful to the implementation of an ERP system.  And while this is helpful for larger companies, it is extremely welcome to small to medium-sized businesses for whom an ERP implementation is often difficult if not impossible due to the expense, time, and technical skills required by traditional implementation strategies.

Steps in Agile ERP System Implementation

With Agile Development methodology, there are steps that can be adapted to ERP system implementation:

1. Telling the Story Rather than over-document the workflows and technical requirements, every desired feature has its own story, often referred to as Product Backlog Creation. Here, managers define how they want the system to work to optimize their process and automate functions as much as possible.  Today’s ERP platforms are extremely customizable and this ability to “tell the story” means using natural language to describe the inputs and functions a segment design should incorporate.
2. COTS Once the story is defined for key processes, users must define what is and isn’t available using the “Commercial Off The Shelf” (COTS) functionality of the chosen ERP platform. While ERP platforms will have a lot of native functionality “Out of the Box”, none are plug and play and there are programming considerations or Independent Software Vendors (ISV) that will need to be used to customize the system for each company’s business use.  If the company is using a third-party consultant for the implementation, the consultant may explain what the functionality can and can’t do and the company will decide whether this is a fit for them or if additional programming or ISVs are needed.
3. Sprints Once functionality and ISV requirements are determined, Agile methodology uses “Sprints” to deliver finished segments of the ERP implementation. Teams are small and made up of key players and stakeholders within the company who will work together to solve roadblocks, develop data entry strategies and begin to define how the module will be customized further within the segment’s functional area for their business needs.  There are short, specific time goals for the delivery of the segment and regular and monitored accountability for each team member to make sure everyone is pulling their weight.  Sprints are a little different in an ERP implementation in that the segment being designed may need to be larger than would normally be used in Agile.  For example, a finance segment or an inventory segment may not be able to be developed in smaller pieces as the whole is required for the segment to work at all.  But with these exceptions in mind, teams can be built with the right members and skillsets to produce a larger segment and still do so with the adaptability of Agile.
4. Scrum Meetings One of the key failings of the Waterfall method was that it often locked teams into rigid, unalterable courses that were not easily changed when the need for change was clearly required. With sprints, changes are a given and “scrum” teams working together collaboratively to sift through problems that arise, discuss them, and develop alternatives to build the change into the delivered segment of the implementation.  These meetings often produce “To Do” type lists assigned to relevant team members with the delivery date used as the goal.
5. Testing and Demo Another key difference in Agile Vs Waterfall is that in Agile, testing is done along the way or near the end of the segment. As testing yields results, the team will settle on a version that covers all the “story” elements and works to meet the story needs with the flexibility and adaptability to make the changes to the programming or documentation as they go.  Once testing is complete, a demo of the module is conducted so everyone on the sprint team can see how the segment works for their stakeholder needs.
6. Conclusion As the segment “Goes Live”, teams can use lessons learned through the sprint process to improve on team performance in upcoming sprints for other functional areas to achieve a continuous improvement process along the way.

Unlike the Waterfall method, Agile not only relies on change, it counts on it to hone and customize programming of the ERP segments along the way.  While there is ebb and flow in time-frames, it is often less costly to change sprint elements as you go than to go back and change after the entire system is fully live across all functional areas.  The collaborative process, regular meetings, and testing of the segment improve the final implementation and ensure that fewer, and less costly, changes are required once the entire system is functional.

Benefits of Using Agile Methodology in ERP System Implementation

Using agile methodology for an ERP implementation is superior to the Waterfall method.  It is especially effective for small to medium businesses that may have limited resources, little to no in-house IT, and a limited amount of time to tie their processes into an ERP.  Using the Agile method provides several key benefits:

Flexibility

Teams can develop segments that work not only for the business needs of the enterprise but also one that works well for its culture and available resources.  This flexibility extends to the build process itself as the new system may require changes to traditional, and often core, operating procedures.  With the collaborative team in charge of the segment build, the collaboration allows changes to be made quickly to adapt to the new software.

Confidence Building

ERP implementations are by nature uncomfortable and even scary.  They require entire companies to learn new skills and journey through a long learning curve.  Often, beginning with segments or modules that can be designed and implemented quickly can boost organizational confidence.  This “quick win” strategy will allow staff to become more comfortable and to buy into the change as they see a quick and effective benefit over an older process.

Team Building and Collaboration

With traditional Waterfall Development, adoption is pre-ordained, and documentation and specification is done within a smaller skillset, often with little or no input from staff outside of IT.  In the traditional method too, changes were often ironed out over a long period of time and at greater cost.  Functionality was potentially limited during the “debugging”, and depending on cost and resources, some changes were not able to be made at all.  The collaborative nature of Agile methodology and its emphasis on teams and accountability ensure that a larger sampling of staff is included in the build.  This helps the resulting ERP rollout to be more customized and fitted to the needs of the users within the company from the beginning.

Customized Functionality

Users often rely on specific reports and metrics to accomplish the required tasks of their jobs within the organization.  Using Agile methodology to implement a new ERP allows metrics and reports to be determined and designed specifically for users who need them.  With the Waterfall method, those reports and metrics may not be included by IT staff who don’t know they are required, or they may not provide the level of data within those metrics and reports required for staff to complete their tasks.

Companies that use Agile Methodology for ERP system implementation will see an increase in collaboration, organizational participation, and buy-in.  It is built into the agile process.  All companies will see potentially lower cost and a more flexible, adaptable, and customized programming of the ERP that requires less of a learning curve and less “debugging” at the end.  This will result in lower cost and higher user satisfaction, an important consideration considering the level of investment a company makes in its ERP system and how long it will be in use.  Small to medium companies, often facing fewer and tighter resources as well as having much less in-house IT expertise would particularly benefit.