ERP Rescue Consultant, India

Signs an Indian ERP project needs rescue, not more patience

Every implementation has difficult weeks. A rescue is different: the project has lost its shape, and continuing on the current path will not bring it back. Signals worth taking seriously include:

• go-live keeps slipping, and nobody can explain what the next date depends on
• Tally or the old package is still the real book of accounts, with the new ERP updated afterward or not at all
• the partner's consultants change frequently, and each new person asks the same questions again
• change requests are being raised for things your team believed were in the original scope
• after go-live, accounts staff prepare GST data outside the system because ERP figures do not tie to the returns
• stock in the system and stock in the godown drift further apart every month
• invoices are delayed because IRN generation or e-way bill creation fails and nobody owns the fix

None of these on its own proves the project has failed. Together, they usually mean that the plan, the scope and the relationship need to be reset rather than pushed harder. Outside the Indian context, my ERP recovery page explains the underlying approach.

Keeping GST returns, invoicing and month-end safe during recovery

In India, a troubled ERP is not only an internal problem. Customers need valid tax invoices, transporters need e-way bills, and returns must be filed on time whatever state the system is in. So the first part of any rescue is protecting those obligations.

I sit down with your accounts team and chartered accountant to agree what can be trusted from the system today and what needs a temporary control. That may mean reconciling sales registers against IRN records before each return, checking a sample of tax calculations on new invoice types, or agreeing that one branch keeps billing from the old system until a specific fix is tested. The tax treatment is always your CA's call; my role is to make sure the system side of each decision is clear and that temporary measures are written down, owned and removed once the fix is proven.

Month-end gets the same discipline. I help finance build a short close checklist for the recovery period: stock reconciliation, bank reconciliation, open GRNs, interbranch balances and payroll journals. A first clean close after a bad go-live often does more for confidence than any status report, because it shows the numbers can be relied on again.

Working with your partner, or replacing one, without a blame game

A rescue can often succeed with the existing implementation partner. The partner knows the configuration, has the code and usually wants the project to succeed as much as you do. What is missing is a shared, honest view of the work and a plan both sides can commit to.

I prepare for a reset by listing every open item with its origin: in the original scope, added later, disputed or no longer needed. In the reset meeting we go through that list together, agree priorities and acceptance criteria, and settle staffing questions such as a named lead consultant and continuity on your account. I keep the discussion on the facts rather than on fault, because a partner that feels accused tends to defend rather than fix.

Sometimes the relationship cannot continue. If that is the decision, the priority is a clean handover: source code and customizations, configuration documentation, data migration scripts, admin credentials and the issue log. I help you list what you need to receive, and a new partner can then be brought in on a clearer brief. My implementation oversight work in India can continue alongside whoever delivers the next phase.

Data repair after a rushed Tally migration

A troubled Indian go-live frequently has a data story behind it. Opening balances were loaded in a hurry, party masters were imported from Tally with duplicates and inconsistent state codes, and item masters arrived without proper units, HSN codes or batch details. Everything that followed was built on that base.

Data repair needs a plan, not a burst of manual corrections. I start by sorting problems into categories:

• masters: duplicate customers and vendors, missing GSTINs or state codes, items without correct tax or unit settings
• opening position: ledger, receivable, payable and stock balances that never agreed with the legacy books
• transactions since go-live: documents posted with wrong tax, wrong branch or wrong warehouse

For each category, finance and the partner agree how it will be corrected, who approves the entries and how the correction will be checked. Where corrections touch tax figures already reported, your CA decides how they should be handled. Fixing masters first matters, because correcting transactions while bad masters are still in use only creates new errors. The ERP migration checklist covers the controls that should have been in place the first time.

Choosing between carrying on, shrinking scope and switching system

Once operations are stable and the facts are clear, leadership has a real decision to make. I lay out three options in one document, each with what it would take, what it risks and what it would disrupt, described in words rather than invented figures.

• Continue with the current scope and partner under a fresh plan, if the software suits your operations and the trouble lay mostly in planning, data or people.
• Re-scope to a smaller core, such as finance, sales and stock, going live properly before production planning or dealer portals are added.
• Re-platform when the evidence shows the chosen system cannot handle your core processes without heavy customization, accepting the cost of starting again.

Contracts often shape this decision. Before you notify a partner, withhold a payment or sign a revised statement of work, the contract terms should be reviewed by your lawyer. I prepare a factual summary of scope, deliverables and change history to support that review, but legal interpretation stays with them.

I take no commissions or referral fees from any vendor or partner, so a recommendation to stay, shrink or switch is based on your situation alone. For the broader picture, see my ERP audit work for live Indian systems, the India overview and the ERP consultant page for India.