After Go-Live: How to Diagnose and Stabilize an ERP That Is Live but Not Running the Business

A health check starts with the operating truth

An ERP health check is a structured assessment of whether the system, data, processes, roles, controls and operating behavior are working together as intended. It is broader than a technical system check and narrower than a full transformation redesign. Its purpose is to establish where the operating model is healthy, where it is drifting, and what evidence should drive the next decision.

One of the most misleading situations in enterprise technology is a system that is technically live but operationally secondary. Interfaces are running. Users can log in. The partner is closing incidents. Month-end may even be completed. Yet production priorities may still be agreed in an offline meeting, warehouse movements may be posted after the physical activity, and approvals may happen informally before the ERP is updated.

In that situation, the ERP has not necessarily failed technically. The deeper problem is that the operating truth is split between the system and the organization around it.

This is why a health check should not start with a generic question such as "What is wrong with the ERP?" or "Why are users resisting?" It should start with a more neutral diagnostic question: where is the business actually being run today?

That question is useful even when there is no crisis. A healthy organization can use it proactively to test adoption and process integrity. A troubled program can use the same evidence to separate stabilization needs from deeper recovery work.

Start with evidence, not the loudest complaint

After a difficult go-live, every stakeholder sees a different problem. End users may describe screens, access or workload. Management may see delayed reports. IT may see integration defects. The implementation partner may see open tickets. Finance may see reconciliation problems. Operations may see disrupted flow.

All of these can be real. None of them, alone, is the operating diagnosis.

A serious health check combines system evidence with field observation. Compare transactions with what happened on the ground. Follow an end-to-end process from demand to supply, procurement to payment, order to cash, production to quality, or project commitment to financial posting. Ask where people leave the designed process, why they leave it, and what happens next.

In post-go-live work, I also like a simple Red Team mechanism: a small group deliberately goes to the operating floor or business function and observes what people are actually doing, including exceptions that never become system tickets. Its job is to find the gap between the designed process, the recorded process and the lived process before that gap becomes normal.

In my work across the region, I have learned not to assume that the formal process is the whole operating process. A plant, branch or finance team may have developed an informal approval, local priority list or offline bridge simply to keep work moving. You do not diagnose that from the project room; you have to follow the transaction and ask why the workaround exists.

The group is there to understand why the bypass exists: a defect, missing data, poor process design, lack of capacity, unclear ownership, a policy decision, a habit, or a deliberate refusal to follow the new operating model.

Use the ERP as a sensor for business behavior

ERP systems contain behavioral signals if you know where to look. A login count tells you that someone opened the application. It does not tell you whether the new process is running properly.

More useful signals are process-specific: were transactions entered at the right time? Are production orders connected to real demand? Are purchase and stock movements following the intended flow? Are manual postings and exceptions increasing or falling? Are documents left open because the process stops between departments? Is the same workaround reappearing in the ticket mix?

The exact indicators differ by process and industry. The principle is the same: measure the behavior that should create value, not the activity that is easiest to count.

Prosci uses three people-side ROI factors that are useful for adoption: speed of adoption, ultimate utilization and proficiency. In an ERP health check, I translate those ideas into operational questions: how quickly did the process move toward the new way of working, how much of the relevant business is actually using it, and how well can teams perform under real workload?

Prosci reported in 2026 that organizations with strong ERP measurement were 2.5 times more likely to exceed expectations in its research. I would not treat that as a universal causal law, but it reinforces a practical point: a dashboard can create false confidence if it measures what is easy rather than what tells you whether the new operating model is forming.

Those questions are more revealing than asking whether training was completed. They should also come back at the end of the health check: how fast is adoption stabilizing, how much of the intended process is genuinely being used, and how well can the business perform without rescue support?

One diagnostic caution is still important: when users know what to do but cannot execute the process reliably under real operating conditions, the constraint may be access, data, capacity, hand-offs or process design rather than training.

Find the shadow operating model

The biggest recovery risk is often not one workaround. It is a parallel operating model that becomes normal.

A printed sheet starts as a temporary bridge. A planning meeting becomes the real source of production priority. A local approval happens in chat and is recorded in the ERP later. A team keeps a parallel list of open actions because the official workflow feels too slow. Finance or operations then posts the final result so reporting can continue.

Over time, the ERP becomes a repository for the outcome rather than the mechanism through which the business is managed. The organization may still describe the problem as "system instability," while the real issue is that the old way of working has rebuilt itself around the new technology.

Recovery therefore needs explicit visibility of shadow work. Some temporary workarounds are legitimate contingency measures. The difference is governance: a contingency has a known trigger, owner, duration, reconciliation method and exit condition. A shadow process survives because nobody owns its removal.

This gap will matter even more as AI and agentic capabilities become part of ERP. If the operating truth is split between governed transactions and invisible shadow work, an AI layer is working from an incomplete picture of the business. Before asking what an agent can automate, I want to know whether the process is visible, trusted and actually used.

Stabilize the operating model, not only the software

Technical stabilization is necessary: critical incidents must fall, recurring defects must be fixed, integrations must run and performance must be acceptable. But ERP stabilization is broader.

A useful recovery plan typically has to work across several connected areas at the same time:

System and integration defects that genuinely block the designed process.

Master data and transactional data that prevent planning, execution or reporting from being trusted.

Process gaps and hand-offs that make the future-state design impractical in daily operation.

User ability, workload, access, support and role clarity under real conditions.

Governance gaps that allow local exceptions to become permanent operating rules.

Business ownership of the end-to-end process and the metrics that show whether recovery is working.

If the recovery office only closes tickets, the dashboard can improve while the business quietly learns to live outside the ERP.

Exit hypercare with evidence, not with a date

Many programs treat hypercare as a fixed number of weeks. A calendar is useful for planning resources, but it is a weak exit criterion.

The better question is whether the business is ready to operate without rescue mode. Critical incidents should be controlled. Repeat issues should be declining. Cycle times should be acceptable. Key adoption signals should be stable. Manual workarounds should be governed and reducing. Business owners should be able to take the process back from the war room.

A simple field observation can also be useful: when normal operations still require people to work heroic hours every day, the operating model is probably not stable yet. That is not a formal KPI, but it is a meaningful warning signal.

A health check is a management diagnosis, not a technical blame exercise

The purpose of an ERP health check is not to prove that the partner failed, the users resisted or the design was wrong. Sometimes the system is defective. Sometimes the business never made a policy decision the system depends on. Sometimes data is the real constraint. Sometimes governance allowed workarounds to multiply. Sometimes the system is healthy and the organization simply needs evidence that adoption is on track. Often several conditions coexist.

The value of an independent health-check or recovery view is that it can challenge all sides against the same operating evidence. The decisive question is what must change for the ERP to become the real operating system of the business.

A live ERP should not merely record what the company did. It should help the company run the way it intended to run.