Rolling out an ERP system is not installing a program. It is a project in five phases where we first agree what the system has to solve, and only then install anything. The process described below follows the methodology of the QI vendor and our own practice. It has one purpose: so that at any moment you know what is happening, what it will cost and when it will end. That is why the first two phases produce more writing than programming.
1. Sales meeting: what you actually need
We start with a conversation about your company, not about software. We want to know what you do, how many employees you have and how many people will work in the system at the same time, whether you have branches and how data travels between them. Then the range of processes the system should cover — sales and purchasing, finance, accounting, warehouses, assets, manufacturing — and the technical context: which operating system and database server you use and by when you need to be live.
Next comes a demonstration at your premises on a demo version of QI. We prefer to run it for a small group of the people who decide about the system, because in a small group we can react to specific questions instead of giving a generic show. We present the technology, the user interface and above all the agendas that matter to you.
One thing that is often underestimated: right at the start we jointly identify the key people. Who signs, who decides about money, who about technology, who about functionality, who has the deciding and who the advisory voice. Projects do not fail on software, they fail because nobody is able to decide. The phase ends with a detailed quote and a risk assessment.
2. Feasibility study: checking whether it makes sense
The second phase answers whether your idea is feasible, at what cost and in what time. The study describes the goal and scope of the rollout, basic information about the organisation, the requirements, an analysis of the current state and a design of how the company will work once the system is live. It adds a proposed implementation team, expected costs, the time needed and a list of risks and benefits.
It includes a trial installation and a consultation with the system vendor. Where your requirements go beyond standard functionality, we ask the vendor for a feasibility guarantee, so that it does not turn out later that a promised change cannot be made. The phase ends with a decision on whether to continue. "No" is a legitimate outcome and it is far cheaper here than six months later.
3. Implementation plan: the document that says what will happen
The implementation plan is the most important document of the whole project. It extends the analysis with the things the study covered only in outline: where your processes deviate from what QI supports as standard, which deviations can be solved by configuration and which require development.
The solution description in the plan covers required standards, document numbering, data migration from the previous systems, access rights, data transfers between branches and a list of custom changes. To that it adds what holds the project together:
- Acceptance criteria — how we know a stage is finished.
- Stages and a schedule drawn up as a Gantt chart.
- The scope and attendance of training — who, on what and when.
- The budget and a refined licence scope.
- Risks, countermeasures and the impact of the rollout on daily work.
4. Implementation: from installation to go-live
Only now does anything get installed. This phase follows the plan and one rule is worth remembering: changes, comments and approvals are exchanged in writing. When money is involved, verbal agreements cannot be defended.
At the start the implementation lead and the team are introduced and their authority is stated. Tasks are assigned in writing with a start and end date, on both sides — to our consultants and to your people through the responsible person. The implementation lead tracks progress, calls team meetings at least once a month and keeps your key people informed about the status and about any deviation from the plan.
The technical work covers installing and configuring servers, workstations and the network, installing the database server and QI, load tests compared against reference results, configuring the system and the individual modules, document series and users, migrating data, filling in the code lists and setting access rights by group.
Data migration is always tested on the trial licence first. Only once the imported records are correct are they transferred to the live licence.
Trial run
On the trial licence we go through every process and document you will actually use. If a deviation appears, it is recorded and we carry on, so that everything gets covered. Part of this is the so-called trial round through all main processes, which the methodology places no later than one month before go-live. The run produces a report signed by the project manager and by your responsible person.
Stages, changes and custom work
Every stage closes with an acceptance protocol listing reservations and corrective actions, and is invoiced according to the plan. Changes to the plan go through change management: the request is registered, split into essential and other, a solution, price and deadline are proposed, and it is approved in writing. Custom changes are tested first by us and then by you, and handed over with a protocol.
Training and go-live
Training runs on the trial licence, which is a copy of the live one, so people work with their own data. Basic training on operating the system is for all future users; specialist training covers the individual agendas. Every training session ends with a written knowledge check — not to fail anyone, but to find out where more help is needed.
Alongside this we write the procedures for finance, accounting, warehouses or payroll, which are then reflected in your internal directives. And go-live always happens with consultants physically present. How long they stay depends on the size of the rollout.
5. Customer care: the project does not end at go-live
After the rollout we move to a service contract listing the services, deadlines and responsible people. It includes regular visits where we check how the system is working for you and deal with whatever has changed in the meantime. Once operations settle, we look at extending functionality, adding agendas and training new or seasonal staff.
What you get on paper
So that you have something to rely on, every phase leaves a document behind. The feasibility study tells you what can be done and at what cost. The implementation plan gives you the schedule, the stages, the acceptance criteria and the budget. During the rollout you collect acceptance protocols for each stage with reservations and corrective actions, handover protocols for custom changes, the trial run report and work reports. At the end you receive written procedures for each agenda — a manual for how a particular job is done in QI at your company.
The length of the project is driven mainly by scope. A company rolling out finance, warehouse and sales is live sooner than a manufacturer with planning and costing. Two things always hold: the trial round happens no later than a month before go-live, and go-live is planned for the start of an accounting period so that data transfers as simply as possible. You get the actual schedule right after the analysis and we stick to it — deviations go through change management, not through a quiet agreement.
What it means for you
Two things carry the project and we cannot do them for you. The first is the time of your key people: without them the system is configured to match assumptions rather than reality. The second is decision-making authority for one responsible person on your side who can say yes or no.
If you would like to know what this process would look like at your company and how long it would take, get in touch. The first consultation is free and without obligation.