Three months after go-live, the floor supervisors are tracking jobs in Excel. Purchasing is maintaining its own price list in a shared Google Sheet. Finance reconciles every report before trusting it. The system is live, the data was migrated, and somehow the team is still working around Epicor instead of through it.
This is not a software problem. It is an adoption problem, and it is more common than most implementation teams admit.
Adoption problems leave visible tracks inside the system. Knowing where to look tells you how serious the gap is.
When a team receives goods but logs receipts in a spreadsheet before entering them into Epicor later, inventory counts are always slightly off. That inaccuracy creates distrust. Distrust creates workarounds. Workarounds feed more bad data back into the system. The cycle reinforces itself until Epicor becomes the secondary source of truth and the spreadsheet becomes the primary one.
If purchasing is getting real daily use but production scheduling and quality management are sitting idle, that usually means those modules were configured during the project but never fully tested against how people actually do their jobs. The screens are there. Nobody opens them.
When your finance team exports from Epicor and cleans up the output before they can use it, something is wrong upstream. The BAQ reports are pulling the wrong fields, the cost structures were not set up correctly, or the data coming in from operations is inconsistent. Any of those problems sends people back to manual processes fast.
“Change management” is the standard explanation. It is not wrong, but it is too vague to act on. The real causes are more specific.
This is the most common one. Epicor gets configured based on how the project team described their processes during discovery. But the people who actually run the warehouse, manage production, or handle purchasing often were not in those sessions. The system works according to a version of the business that does not quite match reality. So people adapt around it.
Most implementations treat training as something that happens before go-live and then stops. People learn the screens, go live, and then the questions start. By then the training session is two months in the past, no one is around to answer questions, and habits from the old system fill in the gaps.
Epicor needs someone on the client side who understands it well enough to answer questions, troubleshoot small issues, and keep configuration aligned with how the business is changing. When that person does not exist, or exists but has no authority to act, every problem becomes a support ticket. Tickets take time. People find faster workarounds.
Almost every implementation defers something to meet the go-live date. The problem is when the deferred items are the ones that would have made the system usable: automated notifications, reporting that matches how the team actually works, workflows that reduce manual data entry. Phase 2 gets scheduled. It rarely happens on schedule.
Adoption problems are fixable. The work is different from the original implementation, but it is not complicated.
Not how they were trained to use it. Sit with the production supervisor for an hour. Walk through the daily purchasing routine with the buyer. Look at where people are going back to spreadsheets and ask why. The answer is almost always a configuration gap or a missing piece of training.
This is often simpler than it sounds. A workflow that sends a notification when a PO is approved. A report that pulls the numbers finance actually needs instead of the ones built during the project. A scheduling board configured around how the shop floor actually operates. Small changes in the right places have a larger effect on adoption than most teams expect.
The goal is not to reteach Epicor from scratch. It is to help specific people do their actual jobs more effectively using the system. Focused sessions with the people who are struggling with specific tasks work better than sending everyone back to a general training session.
Not just access. Ownership. Someone who knows the system well enough to answer questions without going to a consultant every time, and who has enough authority internally to push back when a team wants to build another spreadsheet instead of configuring Epicor correctly.
Companies absorb poor adoption as background noise. The workarounds become normal. The shadow spreadsheets become part of the process. And the value the ERP was supposed to deliver, faster reporting, accurate inventory, better visibility into production, never arrives.
The investment in the system was real. The time to go live was real but the business is still running on manual processes because nobody went back and finished the job.
That gap is fixable. It usually does not require a new implementation or a large project. It requires focused work from someone who knows where to look.
The most common reasons are a configuration that does not match how work actually gets done, training that stopped at go-live, and no internal owner who can support the team day to day. When people cannot get what they need from the system quickly, they go back to what used to do the job.
Most teams notice some signs within 30 days of go-live. That is when the project team has moved on, the urgency of go-live has passed, and the daily friction of working around the system starts to add up.
Yes, most adoption gaps come down to specific configuration issues or missing workflows, not a fundamental problem with how the system was set up. A targeted review of where people are working around Epicor, followed by focused fixes, is usually enough.
Transactions are entered where they happen, in real time. Reports are trusted without manual cleanup. Modules that were implemented are getting daily use. And the team goes to Epicor first, not a spreadsheet.
Ideally someone with a working knowledge of how the system is configured and enough organizational authority to push back on workarounds. This is often a systems administrator, an operations manager with ERP experience, or a dedicated internal analyst depending on the size of the business.
TeccWeb works with Epicor users to close the gap between a system that went live and a system that actually gets used. If your team is relying on spreadsheets to fill in what Epicor should be doing, get in touch.
