Skip to main content
GullySystem
A practical guide

ERP problems after go live: data, speed and user pushback

Ganesh HSStrategy and Technology, GullySystem
Practical advice · 5 min read

In this guide 6 sections
The short answer

Most ERP problems after go live fall into four groups: wrong data, wrong configuration, slow reports and people falling back to Excel. Tag every ticket with one group, fix data faults and blockers first, and assign every ticket a single accountable person with a due date. Do this inside the support window.

Start by sorting every complaint into one of four groups

Week one brings a heap of complaints. The stock count is wrong, the invoice will not print, the receivables report hangs and someone declares the system useless. Tag each one before you fix any. Resist the urge.

The four groups are data, configuration, performance and people, and each has its own owner, its own fix and its own test of whether the fault has really gone. A wrong opening balance is no bug. A missing approval step is no training gap.

Keep one shared sheet with the ticket, the user, the screen, the group and the status, otherwise the same fault gets reported five times by five different people.

  • Data: opening stock, customer and item masters
  • Configuration: taxes, approvals, document numbering
  • Performance: slow reports, custom code
  • People: Excel workarounds, skipped steps

Data problems come first because they poison everything

Opening stock that does not match the shelf makes every issue, valuation and purchase suggestion wrong, and two units of measure on one item break conversions silently. Duplicate customers split receivables across two ledgers.

Run three checks in week one. Count fast moving items against book stock. Tie the trial balance and open payables list to the old system on the cutover date, then search the masters for duplicates by name, phone and tax number.

Fix the master record once and merge the duplicate before it collects more postings, then correct the transactions that already used it. Never patch a number by editing a report. The report is only a mirror.

Configuration faults look like user mistakes

A purchase order routed to the wrong approver stalls a supplier delivery, and a tax code mapped to the wrong ledger posts to the wrong account for weeks. Nobody notices. A numbering series that resets in the wrong month produces duplicate invoice numbers, and the clash surfaces only when two customers receive the same reference.

Staff blame themselves. So they stay quiet. Ask each department head to list three steps that feel harder than before, because those lists point straight at configuration and not at people.

Route every change through one person who records what was altered and why, because otherwise two fixes collide and nobody knows which one broke the credit note.

  • Tax codes and their ledger mapping
  • Approval chain per document and amount
  • Numbering series and financial year reset
  • Print layouts for invoices and delivery notes

Slow screens and reports usually have one cause

Three years of history expose slow reports. The usual causes are a custom report with no date filter, a query that scans every transaction line, or a nightly job that overlaps the working day.

Ask the implementer for the report name, who runs it and when, then time it at different hours, because slow only at month end means a busy server. Constant slowness means a rewrite or an index.

Block heavy exports during billing hours. Schedule the stock ageing or receivables report to land in the manager’s inbox at six in the morning, so the billing desk never waits behind a heavy export.

Pushback means the old way still works better for someone

When a clerk keeps a private spreadsheet, the ERP is missing something, whether a quick lookup, a bulk upload or a layout the customer expects. Ask what that sheet does better.

Then choose one of three paths: add the missing view, train on the existing one, or retire the sheet by a stated date. A ban just hides the sheet.

Pick the three loudest workarounds this week. Close each with an owner, a fix and a date, then post the results on the notice board so staff see that complaints lead somewhere.

Post go live issue log

Seven columns hold ticket number, date, reporter, screen or report, group, owner and status, so every row names the person who raised it. A header holds the support window end date and the daily checks, and names the one person allowed to change configuration.

Open a blank worksheet to print

Questions owners ask

How long should the support window after go live last?

Agree it in the contract. Make it long enough to cover one full month end, because the first close shows data, tax and report faults that daily work hides.

Who fixes bad opening data, us or the implementer?

Settle it before signing. Usually the business owns the accuracy of its source data, such as opening stock and customer masters, while the implementer owns the load. Write the split down.

Should we go back to the old system if problems pile up?

Only if a core process such as billing or dispatch cannot run at all, because otherwise a rollback after weeks of live entries costs more than triage. Fix the blockers and keep going.

How do we handle staff who keep using Excel?

Ask what the sheet does better, fix that gap or train on it, and set a date after which the sheet is no longer accepted for reporting.

Browse all guidesBack to top ↑
Next step

Have a specific situation to work through?

This article covers the general case. Tell us what you’re actually dealing with and we’ll respond directly.

Share Your Requirements