A company can have a fully implemented Enterprise Resource Planning (ERP) system and still operate through the same old habits. Purchase orders are entered into the software, but approvals continue over WhatsApp. Inventory is available in the system, but managers still ask for separate Excel sheets. Reports are generated, yet leadership wants someone to personally verify the numbers before making a decision.
Technically, the ERP is live. Operationally, the business is still running two different ways.
This is one of the most overlooked problems in ERP adoption after go-live. Organisations spend considerable time selecting software, mapping processes, migrating data and completing implementation. Yet the real business benefits depend on whether employees, managers and leaders consistently use the new system to carry out work and make decisions.
Research involving 1,618 ERP implementation professionals highlights this imbalance. Organisations allocated approximately 92% of ERP budgets to technical activities and 8% to change management, while respondents considered human and organisational factors six times more important than technical factors when identifying opportunities to improve ERP outcomes.
The lesson is not that technology is unimportant. It is that implementing technology and changing organisational behaviour are two different responsibilities, and both must be managed deliberately.
ERP Adoption After Go-Live: Why Organisations Return to Old Habits
When ERP goes live, management often expects better planning, accurate inventory, faster reporting, improved coordination and stronger business control. These are reasonable expectations because an integrated system can bring information from multiple functions into one operating environment. However, ERP cannot guarantee that the organisation will immediately develop the discipline required to use that information effectively.
Consider what happens when a purchase request moves through procurement, stores, finance and management. Before ERP, the process may have depended on phone calls, informal confirmations and personal relationships. The new system introduces defined approval levels, required information, transaction records and accountability at each stage.
For the first time, a delay that was previously handled through personal intervention becomes visible as a pending transaction. The system may show that an approval was not completed, a material receipt was not recorded or an invoice cannot be processed because the underlying information is incomplete. What management considers an ERP problem may actually be an old process weakness that has become easier to identify.
However, not every problem revealed during implementation existed beforehand. Poor system configuration, unsuitable workflows, integration defects, inaccurate migration and unnecessary customisation can create genuine new difficulties. A responsible organisation must distinguish technical defects from process gaps, weak data ownership and user adoption problems before deciding what needs correction.
The business begins running two operating systems
One system is the ERP, where transactions are expected to follow agreed workflows. The other is the informal system built around spreadsheets, phone calls, personal approvals and established relationships. Employees may use the ERP because the company requires it, but continue using older methods because those methods feel faster, familiar or easier to control.
The problem is that the two systems rarely remain aligned. A department may complete work outside ERP and enter the transaction later, while another department makes decisions using information that is already outdated. Eventually, the organisation starts questioning the reliability of the very system it purchased to improve visibility.
This is also how parallel reporting becomes normal. The ERP produces one figure, departmental spreadsheets produce another, and management spends review meetings reconciling differences rather than examining business performance. Instead of eliminating duplicate effort, the organisation may unintentionally create more of it.
The answer is not to prohibit spreadsheets without understanding why people still use them. Management first needs to identify what the informal method provides that the new process does not. Sometimes the issue is inadequate training, sometimes it is a missing system capability, and sometimes people simply prefer the authority and flexibility of the previous arrangement.
Until that distinction is understood, forcing greater ERP usage may increase frustration without improving adoption.
Leadership behaviour can quietly protect the old system
Employee resistance is frequently discussed during ERP implementation, but management resistance can be equally damaging. A promoter may approve the project and encourage departments to adopt the new system, yet continue asking for information through the same personal channels used before implementation. A functional head may insist on standard workflows while allowing exceptions whenever a familiar supplier or important customer is involved.
Employees quickly notice these contradictions. If a manager regularly accepts manual approvals, people have little reason to follow the system-based approval route. If leadership continues making decisions from private spreadsheets, teams learn that the ERP dashboard is not the organisation’s final source of information.
This creates a difficult situation for middle management. They are expected to enforce the new process, but the exceptions often come from people above them. Eventually, following the system becomes a matter of individual preference rather than a consistent organisational requirement.
The real test of leadership commitment is therefore not whether senior management attends ERP review meetings. It is whether leaders themselves change the way they request information, approve decisions, review performance and respond to process deviations.
When leadership behaviour remains unchanged, technology adoption reaches a limit.
A working transaction is not proof of a working process
Many implementation reviews measure whether users can log in, transactions can be posted and reports can be generated. These are necessary technical checks, but they do not fully establish that the new operating process works as intended. A transaction may be completed in ERP even though several important decisions happened outside the system.
For example, a purchase order may be entered only after the promoter has already approved it verbally. The software records the transaction, but it did not actually control the decision. Similarly, an inventory adjustment may appear in ERP without the organisation having investigated why the stock difference occurred.
This is why ERP adoption must be evaluated through the entire business process rather than isolated software activities. Management should examine where work begins, who makes each decision, how information moves, where exceptions are handled and whether the final outcome is properly recorded.
If the organisation only checks whether transactions are entered, it may mistake documentation for process discipline.
How to make ERP work after implementation
The most useful post-go-live intervention is often a focused examination of how work actually moves through the organisation. Instead of starting with another round of general training, management can select a few important processes and trace them from beginning to end. The aim is to identify where the new way of working is being followed, bypassed or misunderstood.
A practical improvement approach can include seven actions:
- Trace the complete decision path. Select a few representative transactions such as procurement, dispatch, invoicing or customer order fulfilment. Follow each transaction from initiation to closure, including the approvals, corrections and informal discussions that took place. Compare the actual working method with the approved ERP workflow to identify where the two differ.
- Classify the gap before prescribing a solution. Separate configuration defects, missing functionality, data-quality problems, unclear roles, inadequate training and deliberate process bypasses. Each requires a different response. Repeatedly training users will not resolve a defective workflow, just as additional customisation will not fix a manager who continues approving transactions informally.
- Give business processes clear ownership. Every critical process needs an accountable business owner who understands the operational outcome, not merely the software screen. For procurement, this could involve responsibility for request approval, purchase-order accuracy, vendor coordination and timely closure. The Information Technology (IT) team and implementation partner support the system, but business functions must own the way work is performed.
- Control exceptions instead of normalising workarounds. Some temporary manual procedures may be necessary during stabilisation, particularly when a critical defect affects operations. These exceptions should be authorised, documented, time-bound and reviewed. A workaround that continues indefinitely without an owner or corrective plan can eventually become a permanent parallel process.
- Train employees around real decisions. Training should go beyond demonstrating which fields to fill and which buttons to select. Employees need to understand why information is required, what happens to the next department when it is incorrect and when an issue must be escalated. Role-specific examples using actual business scenarios are more useful than repeating a generic software demonstration.
- Move management reviews into the new operating rhythm. Leadership should begin using system-generated information wherever it has been validated as reliable. Weekly reviews can examine pending transactions, approval delays, data exceptions and process bottlenecks, while monthly reviews can focus on inventory accuracy, working capital, margins and other business outcomes. When managers consistently review the process through ERP, the organisation receives a clear signal about the expected way of working.
- Keep adoption under review after stabilisation. Go-live support should not disappear as soon as the implementation team closes its initial task list. Process owners should continue checking recurring errors, user difficulties, delayed transactions and unnecessary manual work. Improvements should be incorporated into operating procedures, training materials and system controls so that the process remains reliable as the business changes.
These actions require coordination between management, department heads, employees and the ERP implementation partner. A consultant can configure the approval process, but the organisation must decide who genuinely has approval authority. A system can enforce mandatory information, but the business must ensure that the information entered is accurate and responsibly maintained.
That division of responsibility is essential for sustainable adoption.
Build a post-go-live review that measures actual adoption
A company does not need another complicated dashboard merely to measure how often employees open the software. User activity is useful, but it should be connected to evidence that business processes are functioning more effectively. The objective is to determine whether ERP is improving execution and reducing avoidable dependence on manual intervention.
A useful post-implementation review can examine 5 categories of evidence:
- Process compliance: are transactions following the approved workflow, or are significant steps still being completed outside the system? Management can examine the percentage of transactions requiring manual intervention and the reasons for repeated exceptions.
- Data reliability: are inventory, procurement, production and financial records entered accurately and on time? This can be assessed through reconciliation differences, delayed entries, incomplete master data and recurring corrections.
- Decision efficiency: are routine approvals moving at the intended level, or are decisions still returning unnecessarily to senior management? The review should examine approval ageing, unresolved exceptions and the actual time taken to close important decisions.
- Employee capability: can people complete their responsibilities independently, understand the purpose of required controls and resolve ordinary issues without depending on one experienced colleague? This requires observation and practical proficiency checks, not only training attendance records.
- Business outcomes: has the organisation improved inventory accuracy, order turnaround, reporting timeliness, working capital visibility or another objective identified before implementation? These measures connect adoption with the original business purpose of the ERP investment.
A company can use these measures to build a practical 30-, 60- and 90-day stabilisation review, adjusting the period to suit implementation complexity. The first stage can focus on critical process failures and operational continuity, the second on recurring workarounds and ownership, and the third on sustained adoption and measurable operating improvements.
The purpose of this review is not to punish users for early difficulties. It is to identify which parts of the business have changed successfully and which still need management attention.
The most uncomfortable change may be required at the top
There is a particular moment in an ERP transformation when leadership must choose between convenience and the new operating discipline. A critical approval may be delayed because the authorised manager has not acted. The promoter can resolve it immediately through a phone call, but doing so repeatedly may reinforce the very dependency the new system is intended to reduce.
The more useful response is to understand why the approval is delayed and whether the decision authority, escalation process or workflow design needs correction. If an urgent exception genuinely requires intervention, the organisation should still ensure that the action is properly authorised and recorded. The aim is not to make the system inflexible, but to prevent convenience from becoming an excuse for uncontrolled processes.
This is where organisational change management becomes more than a communication or training exercise. It involves changing how managers exercise authority, how departments coordinate and how leaders respond when the new process reveals uncomfortable information. Without those changes, employees may follow the system temporarily but return to familiar habits when implementation pressure reduces.
In a growing organisation, the willingness of leadership to follow its own operating rules is one of the strongest practical demonstrations of commitment to change.
When should the business consider its ERP transformation successful?
ERP implementation should not be considered complete merely because the software is available, users have received training and the initial technical problems have been resolved. Those are important milestones, but they represent system readiness rather than the full achievement of business objectives. Sustainable results require the new processes to operate reliably without constant intervention from the implementation team.
A meaningful review should therefore examine whether the company is still maintaining duplicate records, whether functional heads trust common information, whether accountability has become clearer and whether important decisions are being made through the agreed structure. It should also assess whether employees can explain the reasons behind the new process rather than merely follow instructions.
This is the difference between technology being installed and digital transformation becoming part of daily operations. The first creates a new capability. The second changes how that capability is used to manage the business.
It also explains why ERP transformations require continued attention after implementation. Business volumes change, new employees join, reporting requirements evolve and existing processes need improvement. The organisation must have a reliable method for reviewing those changes without allowing uncontrolled workarounds to return.
This requires management-led process and technology adoption, where leadership accepts responsibility for changing its own working habits alongside those of employees. The process owners, implementation partner and IT team all have important roles, but none can substitute for consistent management behaviour.
The most convincing evidence of ERP success is not that every department has started using the software. It is that the company has developed a common way of working, decisions are supported by reliable information, and operational problems are resolved through clear ownership rather than personal intervention.
That is when ERP begins to deliver the business control, transparency and scalability it was intended to provide.
A successful go-live shows that the organisation can operate the new system. A successful transformation shows that the organisation has changed the way it operates.
