Where the bottleneck lived
What shaped the decisions
Part 1 produced a real, measured improvement using paper, labels and discipline. That kind of improvement has a shelf life. It lasts exactly as long as the people who were trained on it, and it decays the first busy week nobody has time to update anything.
Putting it in a system was not a technology decision. It was the only way to make the improvement outlive the attention that created it.
The documented client scope is gap analysis, requirements definition and system selection, and those are mine without qualification. The delivery detail on this page — migration control, test gates, cutover sequencing — is the implementation method those requirements were written to satisfy. Where a figure is a measurement it is labelled as one; where it is method it is described as method.
What they needed, and why it mattered
Because Part 1 had already documented the inbound and outbound process, requirements started as a module-by-module review of how the company actually works rather than a walk through the vendor’s feature menu.
- 01Location-level stock visibilityQuantity queryable by product code and storage position, not just as a company-wide total.This is the requirement Part 1 exists to make possible, and the only one that removes the walk to the shelf.Owner: Operations · new capability
- 02Receive against a PO and assign stock to a locationThe goods receipt cannot be committed until a valid registered location is chosen.A control, not a convenience. Without it the location master silently empties out as people skip the field on a busy morning.Owner: Operations and Accounts · partially existing
- 03Pick from the indicated location, and consolidate deliveryPicking confirmed against the location barcode, with the order progressing through picking, packing, shipping and delivered.Stock has to decrement at the right position, not just in aggregate — otherwise the totals stay right while every location slowly goes wrong.Owner: Sales and Operations · existing but manual downstream
- 04Carry proven accounting practice forward untouchedGeneral ledger and bank handling stay as they are. No redesign of anything that was already working.Every unnecessary change spends adoption goodwill that the warehouse changes actually need. Scope discipline is an adoption strategy.Owner: Accounts · deliberately out of scope
- 05Every requirement carries a named departmental ownerOwnership assigned at the moment the requirement is written, not negotiated later when testing starts.A requirement with no owner cannot be signed off, which makes acceptance testing unaccountable and turns go/no-go into an opinion.PM control · applies to all requirements
Seven phases, and each one feeds the next
An ERP implementation is not one workstream. It is several dependencies converging on a single cutover date, which is why the sequence matters more than the effort in any one phase.
Six questions, answered in order
Each analysis answers one question, and each answer is what made the next question worth asking.
Part 1 worked. That is precisely what made Part 2 urgent rather than optional. An improvement held in place by labels, a spreadsheet and recent training has a decay curve, and everyone involved could name the week it would start.
Framing it as two halves of one transformation rather than two projects is what got the second one funded. The argument was not here is more to buy; it was here is what protects what you already paid for.
“Inventory visibility” is not a requirement, it is a wish. It decomposes into a location master, a mandatory location on receipt, barcode confirmation on movement, and a stock enquiry that returns quantity by position — four buildable statements, each testable.
The chain runs in both directions on purpose. Backward it answers why are we building this, which is what kills scope creep. Forward it answers how will we know it works, which is what makes sign-off mean something.
The old application was not bad software. It was accounting software being asked to be warehouse software. It could invoice correctly and could not represent a bin, and no amount of configuration was going to change the second thing.
The last row is the one that mattered most for adoption: accounting continuity was scored as minimise unnecessary change. Finance was working. Replacing it would have spent goodwill the warehouse changes needed.
Not configuration. Data. A system that opens with balances nobody believes gets worked around within a fortnight, and then the shadow spreadsheets come back and the whole programme has achieved nothing.
The decision that defines a migration is what to do when the ledger and the physical count disagree. Importing the ledger figure is fast and wrong. Every variance was investigated to a cause — pending movement, wrong location, damage, duplicate code, old entry error — and only an approved balance became an opening quantity.
Every screen can pass its own test while the transaction still breaks between two of them. The chain from purchase order to dispatch is the unit that matters, because that is the unit the business actually runs.
The scenario worth pointing at is the short shipment. Happy paths pass everywhere; exception branches are where systems fail in production. Those branches came out of the Part 1 SOP — short receipts, QC failures, self-collection, split deliveries — rather than being invented from the software.
The project team does not choose the go-live date; the operating calendar does. Everything before T0 exists to make T0 boring, and the parallel run exists so that a bad day is a bad day rather than an outage.
Training was scoped by role rather than delivered as one session, because a warehouse operator and an accounts clerk need different things and a combined session teaches neither well. Part 1 had already documented resistance from long-tenured staff, which made repetition a deliverable rather than a nicety.
| Failure layer | The question that identifies it | What it costs to get wrong |
|---|---|---|
| Data | Is the source, master or opening balance wrong? | Fixing config that was never broken |
| Configuration | Does the configured rule differ from the FRD? | Retraining users on correct behaviour |
| Process | Is the SOP unclear, or operationally unrealistic? | A defect log full of things that are not defects |
| Integration | Does the transaction break between modules? | The one that reaches production most often |
| Adoption | Is the function correct but being bypassed? | Everything works and nothing improves |
Severity is set by go-live impact, not by how loudly it was reported. P1 blocks receiving, inventory integrity or customer dispatch. P2 has a workaround. P3 is real but can wait behind critical-path work. Every defect carries expected behaviour, evidence, an owner, a target fix and a re-test date — otherwise the log becomes a list of complaints.
What it looks like to the people using it
The Part 1 addressing scheme, living inside the ERP. These are the screens the requirements above were written to produce.
They are the proof that the addressing scheme survived the transition. A location structure that exists only on physical labels is a Part 1 artefact; the same structure holding as a queryable master, enforced on receipt and confirmed on pick, is what makes it permanent.
Two halves, one result
Part 1 gave the warehouse structure. Part 2 gave the operation a memory. Neither one alone would have held.
Software does not create order. It preserves order that already exists. If a process is not defined well enough for a system to hold it, the process work has to happen first — which is why the sequencing was not negotiable, and why the location master was the only data source that needed no cleansing.
The 95% figure was measured in Part 1 and belongs to the programme, not to this half. The migration reconciliation and the requirements traceability are Part 2’s own. Everything else on this page — the phase model, the gate structure, the defect layers — is described as implementation method, because that is what it is.
What produced each result
Three deliverables, and each one maps to a number at the top of this page.
The migration reconciliation
Four sources profiled and ranked by how far they could be trusted, a physical count as the authority on quantity, and a documented investigation behind every variance before it was allowed to become an opening balance.
The traceability matrix
Business problem, business requirement, functional behaviour, acceptance scenario and named owner held on one line. It is what turns “configured” into “accepted” and gives the go/no-go decision something to stand on.
The location master and stock enquiry
Part 1’s addressing scheme as a queryable system record, enforced at goods receipt and confirmed on pick. Duplicate ordering stops when anyone can see what is already held and precisely where it sits.
I would put the exception branches into UAT earlier. Short receipts, QC holds and split deliveries were tested, but they were tested after the happy paths, and the happy paths are never where an implementation gets hurt. Front-loading them would have surfaced the awkward workflow questions while there was still configuration time to answer them properly rather than with a documented workaround.