The ERP Development Process: From Scoping to Go-Live

Businesses evaluating ERP development usually ask about technology and price first. The better predictor of outcome is neither — it is the process the developer runs, because ERP projects rarely fail in the code. They fail in the gap between what the system models and what the business actually does, and that gap is opened or closed by how the work proceeds. This is the process as we run it — refined across ERP builds for factories, schools and trading businesses since 1998 — including the steps that exist specifically because we once learned their absence the hard way.

Stage 1: Scoping — on the floor, not in the meeting room

Every ERP that torments its owners began as a scope document describing an imagined business. The corrective is physical: scoping happens where the work happens. We walk the operation with the people who run it — the order register, the store’s issue book, the gate’s challan file, the accounts office — and map three things:

1. The workflows as actually performed, including the unofficial steps (“then I call Akbar to confirm”) that no org chart admits but every system must accommodate or replace.
2. The documents — every register, challan, ledger and report the operation runs on. These are the system’s real requirements; a system that does not produce the documents people depend on will be abandoned in favour of whatever does.
3. The people — who records what, at which point, with what incentive to keep it current. An entry with no natural owner will not be made; the design must place each entry where the work already is.

The output is a scope your own managers can read and correct — a description of your business, not a feature list. Getting this stage wrong is the most expensive mistake available in the entire project; whether you should be scoping a custom build at all is the subject of custom ERP vs off-the-shelf.

Stage 2: Design — the data model is the product

Before screens, the spine: what are the system’s core records, and how do they relate? In a manufacturing ERP the spine might run buyer order → production stages → inventory movements → deliveries → accounts, with every stage’s work recorded against the order — the architecture our textile system is built on. Get the spine right and reports become views of one truth; get it wrong and no amount of screen polish saves the reconciliation burden later.

Design also fixes the vocabulary. The system speaks the business’s language — your stage names, your document titles, your order numbering — because every translation a screen forces is a small daily tax on adoption.

Stage 3: Build — working modules, reviewed early, in order of pain

We build module by module, and the client reviews working software at each step — not mockups, not progress decks. Two disciplines govern the sequence:

Start where the pain is. The module that removes the loudest daily problem goes first. It earns the project its credibility with the people whose habits must change — the store keeper who sees stock answers arrive in seconds becomes the system’s advocate, not its obstacle.

Feedback lands while it is cheap. A manager looking at a real screen with real fields says things no scope review surfaces: “wastage is entered by the next shift,” “the challan needs the buyer’s article code, not ours.” Caught mid-build, these are small edits; caught after go-live, they are the workarounds that kill systems.

Stage 4: Migration and the parallel run

Data migration — opening balances, party accounts, item masters, open orders — is careful clerical work that must be verified line by line, because staff will test the new system’s trustworthiness against the balances they already know. One wrong opening balance costs more confidence than ten missing features.

Then the stage we refuse to skip: parallel running. For a defined period the system and the old registers run together, and results are compared daily. This does two jobs at once — it catches any modelling error while the old process still provides the safety net, and it converts staff trust from a promise into an observation. The registers retire when the comparisons have made the case, not when a schedule says so. (How this plays out on a factory floor is described in our production-tracking piece.)

Stage 5: Go-live and training on real work

Training happens on your data, your orders, your parties — never demo content. A supervisor who enters a real dye batch under guidance has learned more than a week of manuals teaches. Go-live itself is staged, not big-bang: the proven modules carry live work while later modules finish, which is precisely what module-by-module building makes possible.

And the definition of “done” is behavioural, not technical: the system is live when the documents people depend on — the packing list, the party ledger, the status answer — come from the system, because that is the point at which keeping it current stops being extra work and becomes the work itself.

The long tail: where the real relationship lives

An ERP is not finished at go-live; the business will change — new product lines, new buyers, new compliance obligations — and the system must move with it. Regulatory change is the sharpest recent example: sales-tax-registered businesses needed FBR’s electronic invoicing integrated into their sales flow, and businesses on maintained systems absorbed it as an update rather than a crisis. Ask any ERP developer how their longest-running system has evolved; our answer spans decades, at clients you can name.

Questions that reveal a developer’s process

Put these to anyone quoting you ERP development — including us:

1. Where does scoping happen — our floor or your office?
2. When do we first see working software, and which module comes first?
3. What is your parallel-run practice, and who decides when registers retire?
4. What does training run on — our data or yours?
5. Which of your systems has run longest in production, and how has it changed?

The answers separate developers who build systems that stick from those who deliver software and leave. Scoping is where every good project starts, and ours are free — the process above begins with a walk through your operation, via our ERP development service.