ERP Go‑Live Doesn’t Break Operations, It Removes the Mask

The System Did Not Create the Dysfunction

• Our client operated a mid-size manufacturer, six years of which the production, procurement, and finance departments were using different systems. Every team had developed its reconciliation layer in the meantime. At the time the ERP became operational, the layers were eliminated. The holes about which they had been quietly secretive were seen at a glance. The dysfunction was not established by the implementation. It eliminated what had been obscuring it to leadership.

• This was interpreted by the organization as a failure in the system. Reports were inaccurate. The stock levels were inaccurate. Finance was unable to close punctually. Questions were raised on the ERP due to the fact that it was new and the issues were now being felt. What was really occurring is that the organization was experiencing the misalignment of its own process without the cushioning of manual rectification of its processes. The problem was not created by the system. It revealed it.

Process Ownership Was Already Absent Before Go-Live

In one project, we mapped the order-to-cash process in five departments prior to configuration. Each handoff point had informal rules but no owner was written down. There was one definition of a committed order in sales. Finance had a different one. The warehouse was running on a third. The gap had been filled by the teams separately over the years. Only one definition was needed by the ERP. There was nothing written about the organization.

This is not an issue of configuration. It is a governance issue that precedes the implementation fully. It is revealed through ERP as configuration requires explicit responses. The system is not tolerant of ambiguity like a spreadsheet or informal process. In the event that there is no rule, the project team creates one when there is time pressure. The artificial rules created are the new generation of reconciliation within the new system.

Configuration Gaps Are Organizational Gaps Written in Code

All ERP implementation choices are organizational choices that are converted into system logic. When a chart of accounts is constructed, a person determines the way revenue is categorized. When there are set approval workflows, ownership of every decision is defined by someone. When mapping cost centers, a person determines the structure of the business. Every such surface on which there was no consensus in the organization simply accreted habits and postponed discussion.

We have had implementations breakdown not due to complexity but due to inability of departments to agree on how to categorize a transaction. In one scenario, intercompany billing logic disagreement that pushed the go-live back by eleven weeks was not a new dispute. It had been in existence since four years ago when it was acquired. The ERP could not allow hiding anymore. It compelled a debate that the company had never wanted to discuss.

Data Quality Is a Mirror, Not a Project Task

1. Data migration is always underestimated in implementation time. Organizations consider it as a technical activity. Export the records, scrub the format, migrate to the new system. Instead, what they see is a mirror. The existing data indicate years of haphazard entry procedures, undefined master data management and field use that has continually changed over the years without actively imposed standards or defined ownership by department.

2. In one of our distribution projects we operated, the product master had fourteen thousand active SKUs. Cleaning showed that thirty percent of them had duplicates, two out of ten had missing unit-of-measure information, and another subgroup contained cost fields last updated three years before during a pricing review. The legacy system never imposed any rules hence making all this invisible. The ERP did. The mirror became unavoidable.

Reporting Expectations Were Never Grounded in System Design

• ERP reporting leadership expectations are usually determined in the vendor sales cycle. The demo shows dashboards. It displays real time visibility in all operations in slides. The process of configuration starts and decisions determined silently limit the options of what can actually be done. The reports that are made are not similar to those that were previewed by go-live. The system is blamed as the cause of the gap. It was developed in presales several months before.

• This was observed in a retail group implementation. The expectation of finance was to have consolidated by store P&L within 2 weeks of going live. The data model was not designed to generate such a view. The statutory reporting, and not management reporting was constructed in the chart of accounts. No one wrote down what the demo displayed and what had been constructed in design. Such disconnection existed in a dialogue that did not take place.

Readiness Cannot Be Retrofitted After Cutover

The organizations that have go-live properly are not those with the highest implementation budgets. They are those that settled ownership, process, and data issues, prior to configuration. They failed to take the ERP as the solution to prevailing problems. They also took advantage of the implementation in order to finish structural tasks that the organization had put off. Clarity instead of absorbing ambiguity was inherited in the system.

The proportions of what ERP go-live reveals is equal to the degree of unfinished organizational work prior to the commencement of the project. The implementation fails alone. It accepts all the deferred decisions, all the undocumented processes, all the gaps in governance brought into it. The reason why the implementation did not go well is not the only one that the signal is worth reading. It is what that struggle brings out about the organization that was in existence prior to the arrival of the system.

Listen to the Podcast: Why Do ERP Implementations Fail?