A distribution company in Kathmandu spent NPR 8 lakhs on ERP software, hardware, and staff training. Eight months after go-live, 40 percent of the team actively used the system. The remaining 60 percent had built parallel workarounds - manual registers in the drawer alongside the system, WhatsApp messages forwarding information the ERP already held, Excel files described as the "real" numbers while the system figures were treated as a formality.
The owner's assessment: the software was not good enough. The software vendor's assessment: staff were not using it properly. Both assessments missed the actual problem. The technology worked. The implementation was technically complete. What had not been managed was the transition - the human process of moving from one way of working to another, across multiple departments with different relationships to the change.
ERP rollout resistance is not a technology problem. It is a predictable human response to a change that threatens familiarity, status, and established working patterns. In Nepal businesses, it takes specific forms that management needs to recognise and respond to - differently by department, and with more patience and structure than most implementations allow for.
What ERP Resistance Actually Looks Like
Management typically expects resistance to look like open refusal - staff saying directly that they do not want to use the new system. In Nepal businesses, that almost never happens. Staff in a hierarchy where direct disagreement with management is uncommon will not say they refuse. They will say the system is slow, confusing, or keeps giving errors. They will raise issues that are real but minor, escalated as if they are major blockers. They will comply in meetings and revert in practice.
The clearest signal of active resistance is the parallel workaround. When staff maintain a manual register alongside the ERP, process transactions in the system after the fact rather than in real time, or keep an Excel file that they trust more than the system output - the ERP has not replaced the old process. It has been added to it. The team is doing twice the work, the system data is unreliable because it is entered late or selectively, and the promised benefits of real-time visibility and control do not materialise because the real transaction record still lives outside the system.
The parallel workaround is the primary diagnostic signal for ERP resistance. When staff maintain both the old system and the new one simultaneously, the new system has not replaced anything - it has been layered on top. This is the moment that requires a direct management response, not patience.
Why Resistance Looks Different in Each Department
Resistance is not uniform across the business. Each department has a different relationship to the change, and therefore a different form of resistance. The accounts team's resistance is about expertise and status - the senior accountant who has mastered the old system faces a period of visible incompetence on the new one. The procurement team's resistance often has a different texture: new controls close gaps that previously existed, and closing gaps changes who has discretion over what. The warehouse team objects to perpetual inventory tracking because physical counts never match system counts, and reconciling them takes time they did not previously have to spend. The sales team says the system slows down counter service. HR says the attendance records "don't match."
Each of these objections contains a real operational concern - and that real concern is what management must address. But each also contains something else: a preference for the conditions that the old system provided. Separating the genuine operational issue from the structural preference is the management task, and it requires understanding what each department's old system actually allowed them to do.
In Nepal's business culture, senior staff rarely say "no" directly to management. Resistance is expressed as technical difficulty, system errors, and politely persistent workarounds rather than open refusal. This makes ERP resistance harder to identify and address - the message from staff is always "we are trying" rather than "we will not." Management waiting for explicit pushback before responding may wait indefinitely while adoption quietly fails. The signal to watch for is behaviour, not statements: what people are actually doing versus what they say they are doing with the system.
The department-by-department guides in this series examine each form of resistance in detail: accounts and finance, procurement, warehouse and inventory, sales and POS, HR and admin, and management itself. Each article describes what resistance looks like in that department, what the old system allowed that the new system changes, and how to manage the transition without losing the team.
Each department's resistance has a different root cause. A change management approach that treats all resistance the same - more training, more patience - will not address the structural reasons why specific teams prefer the old environment.
"In most Nepal ERP rollouts that stall, the technology works exactly as intended. The gap is not in the software - it is in the transition from what the old system allowed to what the new system makes visible."
A pattern seen consistently across Nepal ERP implementations
What Management Typically Gets Wrong
The most common management mistake in ERP rollouts is treating go-live as the finish line. In reality, go-live is the beginning of the difficult phase. The vendor has delivered and departed. Training sessions are complete. The system is live. And for the next 60 to 90 days, the business is running at reduced efficiency while staff build proficiency - and some staff are actively working to stay on the old system. Management attention is most needed precisely when the vendor support is lightest.
The second mistake is allowing parallel systems to coexist indefinitely. Some parallel running is healthy during the transition - staff need a safety net while they build confidence in the new system. But parallel systems should have a defined end date. When the manual register is still being maintained six months after go-live, it has become the permanent system and the ERP has become the reporting overlay. At that point, the data in the ERP is selective and the promised benefits are not achievable without starting again.
Change management for ERP is not a training event. It is a process that starts before go-live - involving key staff in configuration decisions so they have ownership of the setup - runs through go-live with active management support rather than documentation, and continues for three months after with regular measurement of actual usage versus stated compliance. The three-month post-go-live period is where most Nepal ERP implementations either succeed or quietly fail.
The third mistake is framing the ERP as a management tool rather than a business tool. When staff perceive the system as primarily a monitoring device - a way for the owner to watch what they are doing - adoption resistance increases. The framing that works is operational: the system exists to make their work faster, more accurate, and easier to explain. The audit trail is not surveillance - it is the evidence that protects them when something is questioned.
Parallel systems need a hard end date, set before go-live. Every additional month of parallel running is a month where the ERP data is partial, adoption is optional, and resistance is structurally supported by the fact that the old system still works.
The Transition Model That Works
Successful ERP adoption in Nepal businesses we have worked with shares several characteristics. First, one module is implemented at a time, not all at once. Asking the entire business to change everything simultaneously creates resistance across all departments simultaneously. Starting with finance - the module where the ERP creates the clearest efficiency gain and where the team is most likely to see immediate benefit - builds confidence before extending to procurement, inventory, and HR.
Second, the system configuration involves the people who will use it. When the procurement manager helps define the supplier approval rules, they have a stake in the system working. When the warehouse team helps set up stock categories, they understand why the GRN process works the way it does. Involvement is not the same as control - management still makes the decisions - but it changes the relationship from "this was done to us" to "we helped build this."
Third, there is a visible and credible consequence for persistent non-compliance. This does not mean punishment - it means that management takes the ERP data seriously in meetings, questions staff when the system record and their verbal report differ, and asks for the system report rather than the Excel sheet. When management uses the system as the authoritative source, staff quickly understand that using it is not optional regardless of their preference.
The transition model that works is module-first, involvement-first, and consequence-aware. A business that implements one module well has a much higher chance of full ERP adoption than one that implements everything simultaneously and manages resistance reactively.
All departments go live simultaneously, resistance emerges everywhere, no department is succeeding
One department succeeds first, that success builds confidence and peer pressure for the rest
Manual registers coexist with the ERP for months, the ERP data is partial and untrustworthy
Transition period is bounded and managed - old system closes on the agreed date
Post-go-live support drops off exactly when adoption is most challenging
Active support continues through the resistance phase and measures actual usage weekly
Adoption resistance increases when the system is perceived as surveillance rather than operations
Involvement creates ownership - staff who helped design the workflow have a stake in it working
When ERP data is not required, using the ERP remains optional regardless of policy
When the ERP report is the one asked for, compliance follows naturally
Frequently Asked Questions
For most Nepal businesses, four to six weeks of parallel running is sufficient for finance and accounting. Inventory may need eight weeks if you are establishing opening balances simultaneously. HR and payroll can often transition in a single cycle if opening balances are loaded correctly. The key is setting the end date before go-live, not after. If the end date is set after go-live, it gets pushed indefinitely as resistance generates reasons to extend.
Distinguish between cannot and will not. True inability to adapt is rare in accounting and operations roles - the tasks in an ERP are the same tasks as before, done through a different interface. What presents as inability is usually resistance that has not been addressed directly. If after structured support and a defined time period a staff member genuinely cannot perform their role on the new system, that is a performance conversation, not an ERP configuration conversation. Do not redesign the system around one resistant user.
Involve key staff in the selection process - specifically the people who will use it daily. Sit them through a demonstration and ask for their operational objections. This serves two purposes: you get real feedback about whether the system matches the actual work, and the staff member who raised an objection that was addressed has a different relationship to the system than one who was handed a finished decision. Involve selectively - the finance manager, procurement manager, and warehouse manager are the right people; not every staff member needs to be in the evaluation.
Modular Rollout That Builds Adoption Naturally
MISAC's module-driven architecture is built for exactly this pattern. A business can start with the accounting module alone - the area where the efficiency gain is most immediate and the resistance most manageable - and activate inventory, HR, payroll, or procurement through configuration as each team is ready. There is no re-implementation, no data migration, and no disruption to the modules that are already running. The platform grows with the adoption curve, not against it.
The businesses we work with at MISAC Intelligence Pvt. Ltd. typically reach full adoption in 90 to 120 days when the rollout follows a module-first sequence. The first month is finance, run in parallel with the old system until the team is confident. Month two extends to procurement or inventory depending on where the next priority sits. HR and payroll usually follow in month three or four. At each stage, the previous module's success creates the social proof that makes the next team's adoption faster.
MISAC's implementation team has worked with Nepal businesses across trading, construction, cooperatives, schools, hospitality, and manufacturing for more than ten years. The resistance patterns in this article are patterns we have seen and navigated repeatedly. The implementation support we provide does not end at go-live - it continues through the adoption period because that is where the real work of an ERP implementation happens.
Ready to See MISAC in Action?
Discuss your current implementation challenges and how a module-first rollout approach would work for your business structure.