The Stages of an ERP Implementation
The problem facing most small to medium enterprises when they first dip their toe into the world of ERP, is: where to begin?
There is no single perfect “right” way of implementing ERP. Each software manufacturer, reseller, consultancy, and individual contractor, will have their own preferred methodology – perhaps claimed as a “secret sauce” – designed to arrive at the same outcome via a myriad of similar pathways. Some are good, some are poor, some are cloaked in impenetrable nomenclature that I struggle to make sense of, even as an ERP veteran of two and a half decades.
As an alternative to industry-standard complexity, here is a simplified model, written in plain English, built from good old hands-on experience, which I think of as an average of all the different methodologies I have taken an active role in or read about. It’s by no means the only way, but it is what I call “good practice”.
The Immutable Sequence
A natural law governs the order in which the stages of an ERP implementation are performed. If the order is ignored, the implementer is forced to return to an earlier stage while prematurely attempting to complete a later one.
I call this list of stages “The Immutable Sequence”, immutable meaning unchanging over time. The Immutable Sequence is:
- Analyse
- Define
- Select
- Design, Build, Test, Adjust
- Accept
- Train, Prepare
- Migrate
- Operate
Stages on the same line can be performed simultaneously.
The sequence is generic, unaffected by the technology you choose to deploy or the flavour of project management used. It lends itself naturally to two consecutive projects – Project 1 taking in Analyse, Define, and Select, produces the inputs for Project 2, which starts at Design and ends in Operate.
Project 1 sets the foundations for the success of Project 2, which is where most of the cost will be, and where there is greatest potential for the implementation to go off the rails.
The boundary between the two projects is an opportunity for a mid-course correction once the organisation has developed collective insight and wisdom they will not have had at the start.
It is important to note that while the Projects make linear progress through these stages, the Data team will be working to a different set of steps, loosely coupled to this “main sequence” by various contraints and requirements, which will be discussed in a future article.
Here is a brief description of each stage:
Project 1
Stage 1: Analyse
Before you launch into defining your future business and technical requirements, you must understand exactly how your business operates today by mapping and analysing your major business processes. Ideally including likely abnormal events and exception handling, and digging out the constraints, bottlenecks, inefficiencies, duplications, etc, that show you how your business really operates.
Incorporate your process maps with additional organisational information to build a current operating model, which will answer questions arising in Stage 2, and during the design discovery in Project 2.
Stage output: Current Operating Model – often referred to as “as is”
Stage 2: Define
Define your business and technical requirements for the new system; a comprehensive wish list prioritised as must-haves, ideal-haves, nice-to-haves, and possible future enhancements.
One frequently asked question will be: “how do we do it now?”. To answer that you must have already completed Stage 1 and have a set of “as is” process maps to hand.
Stage output: Requirements Document
Stage 3: Select
Assuming you have gathered enough information from Stages 1 and 2, you will be in a position to make selections, not just of software, but everything needed for Project 2 – ie the “meat” of the implementation.
These selections form the stage outputs:
- People – key team members such as workstream leads, decision makers, a project manager, new hires, and locums (or “backfill” as old school FDs always seem to say).
- Project methodology – largely a choice between “waterfall” and “agile”, but beyond that, what logs, registers, regular meetings, and complexity to use.
- Requirements – what is essential in the initial design, and the order in which the remainder of requirements are prioritised if you choose a phased project methodology.
- Data – what data are you carrying forward, what data are you archiving, and what data are you discarding?
- Technology – hardware and software. This will be a natural focus, but do not concentrate on it to the exclusion of everything else. I have an article about technology selection in the pipeline.
- Third parties – implementation partners, consultancies, contractors, and whoever else you have determined necessary to complete the job.
- Key dates – target dates for design freeze, acceptance, training, legacy cut-off, data migration, and most importantly go-live. It is not plausible to set these before this stage, until you have some idea of the requirements and objectives you are going to ask of the team and technology you have just selected.
The exact methods applicable to, and suitable for, Stages 1,2,and 3, are beyond the scope of this article, but we’ll tackle them in the future.
Project 2
Stages 4-7: Design, Build, Test, Adjust
These four stages form an iterative sequence: a design is produced; a prototype software model is configured (sometimes more than one simultaneously, depending on software and methodology); the software is tested – so called: “unit testing”; complete processes are tested – so called: “integration testing”; and any adjustments shown to be necessary are fed back into the design. A new prototype follows, then more testing, adjusting, and so on.
In an ideal world, the cycle will continue until all the business requirements specified in Stage 2 are fully satisfied. In reality, implementations run into trouble here with late decision making, uncontrolled addition of previously undocumented requirements, the discovery that the standard software cannot deliver one or more requirements, lack of specific expertise within the team, and so on. All of these can be largely avoided by observing and maintaining good governance and methodology from the beginning of Stage 1.
During the Design stage there will be two frequently asked questions: “How do you do this now?”, and “What do you want this to do?”. If you have not previously completed the Analysis and Definition stages, you will be forced backwards to do so, at far greater cost than would have originally been incurred, because now you have software contract obligations, expensive retained third-parties, and a bigger project team on the meter.
Stage outputs: a completed Decision Log, a working System Design, a set of software configuration data, a new Operating Model – often referred to as “to be”, an Acceptance Test Schedule, and a full set of test data.
Accept
The completed Operating Model and software build moves on to acceptance, ideally by the people who are going to use it for real. This will involve localised training for testers if they haven’t already been involved. Users will work to the Acceptance Test Schedule produced in the previous stages, under the guidance of one or more full time team members to keep the acceptance on track.
Acceptance is official recognition that the system works as intended and the contents of the Requirements Document have been satisfied. Acceptance also entails picking up the many small errors and omissions from the Design, and correcting them before the final production system is built (eg spelling mistakes in addresses, missing posting references, logo positioning and aspect ratios, etc). If there are any showstoppers at this stage, the project team has seriously messed up.
Stage output: A fully signed-off Acceptance Test Schedule.
Train, Prepare
Once acceptance is complete, you can begin end-user training on a training copy of the production application. Simultaneously, the production application is built and readied for data migration, legacy data extraction and transformation begins for the production load, support operations are readied, and a final “Go, No-go” meeting is held.
Project team members sometimes lose their nerve at this point and vote for a “No-go” out of fear of the unknown. Their concerns should be investigated, but a discount applied if they have never been in this position before.
If the output of the meeting is a “Go”, normal internal activity ceases on the legacy system, old ledgers are closed and locked (after relevant finance period-end actions), and end-user logins are blocked.
Stage ouputs: a trained workforce, a virgin production system, a “Go” decision.
Migrate
If you have got everything right up to this point, your data lead will direct the load of a perfect set of data into your new application, with each category of data checked and signed for by a designated expert.
Stage outputs: fully signed-off data loads, a loaded production system.
Operate
Operations begin in the new system, accompanied by a period of intensive and highly responsive support, sometimes referred to as “hypercare”, designed to clear bottlenecks and blockers that have the potential to bring everything grinding to a halt for the want of a tiny piece of information, or a simple correction to data or configuration. This phase may last for many months but should continue at least as far as the first month-end.
Of course, it isn’t the end of the story, but the point at which all post-go live problems are solved marks the effective end of the implementation, accompanied by a passing of the torch from the project team to the maintenance team.
This leads into a new phase of your ERP programme concerned with maintenance and continuous improvement, which is beyond the scope of this article.
The ideas and opinions in this article are my own; other opinions and methodologies are available.