AssembloERP
Software gets blamed for most ERP failures. In our experience it deserves the blame perhaps one time in five. The other four are decisions made before anyone logged in.
These five patterns are composites of what we see repeatedly in Indian SMBs. If you recognise your own situation in one of them, that is the point.
1. The project with no data owner
What it looks like: the system goes live. Two weeks in, stores has created "MS Pipe 2in", "MS PIPE 2 INCH" and "Pipe MS 50". Reports become unusable. Everyone concludes the software is bad and quietly returns to the old register.
The decision that would have prevented it: one named person — usually a senior stores or accounts person, not the IT vendor — with sole authority to create item codes, and five minutes of everyone's time to agree the naming convention. Written down. On the wall.
2. The one that imported the mess
What it looks like: to save two weeks, the old data is imported as-is. Duplicate parties, obsolete items, stock quantities nobody believes. The new system inherits the old system's reputation on day one.
The prevention: clean before you import. Delete items with no movement in two years. De-duplicate parties on GSTIN. Reconcile opening stock physically — including material lying with job workers. It is boring and it is the difference.
3. The March go-live
What it looks like: the vendor wants the deal closed in the quarter, so go-live is set for mid-March. It collides with year-end, statutory pressure and the busiest dispatch fortnight. The team is asked to learn a new system while closing the books. Everyone loses.
The prevention: pick the calendar first, then the vendor. Start of a quarter, ideally 1 April, with a parallel month before it. If a salesperson pushes back on your date, you have learned something about the support you will get later.
4. The demo-scoped project
What it looks like: scope was agreed after a polished demo. Nobody walked the actual process. In month two, three genuine requirements surface — job-work reconciliation, a customer-specific packing list, batch traceability — and every one becomes a change request with a price attached. Trust erodes faster than the budget.
The prevention: before you sign, make the vendor sit with your supervisor and follow one order from enquiry to dispatch, on paper. Anything that surprises them there would have surprised your budget later.
5. The one that trained once
What it looks like: two days of training at go-live. Six months later the person who was trained has left, and their replacement is taught by a colleague who half-remembers it. Within a year the system is being used at 40% of its capability and the reports are unreliable again.
The prevention: record your own training — a phone camera is fine — for the ten tasks that matter, in your language, using your items. Add re-training to your onboarding checklist. It costs one afternoon.
The pattern
| Failure | Looks like | Real cause | Cost to prevent |
|---|---|---|---|
| Unusable reports | Software problem | No data owner | One conversation |
| Nobody trusts the stock figure | Software problem | Dirty import | One week of clean-up |
| Team resistance | People problem | Wrong go-live date | Free — pick a better date |
| Budget overrun | Vendor greed | Demo-based scoping | Half a day of process walk |
| Capability decay | Nothing, until it hurts | One-time training | One afternoon of recording |
This is why we insist on scoping a build with your process in front of us rather than quoting from a form. If that sounds like the right order of operations, tell us what you run and we will start there. Worth reading next: are you actually ready, and what it really costs.
