ERP friction usually starts long before a user complains about too many screens. It begins when a company tries to force undocumented workarounds, inconsistent master data, and unclear approval ownership into a system designed to enforce a common process. For organizations running Microsoft Dynamics 365, SAP, Oracle NetSuite, or a legacy on-premises platform, the practical remedy is to treat the ERP program as an operating-model project with software attached—not as an IT deployment.
That conclusion is more useful than the generic advice to “improve adoption.” Microsoft’s Dynamics 365 implementation guidance puts business-process modeling, data migration, integrations, testing, security roles, and change management in the same implementation plan for a reason: each can break the user experience even when the application itself is running correctly. Academic ERP adoption research reaches the same broad finding: perceived usefulness and ease of use are tied to satisfaction, but technology, project management, organizational fit, and user behavior all shape whether the system takes hold.
The immediate action for business and IT leaders is to find where employees abandon the ERP workflow. A spreadsheet used to calculate inventory, a shared mailbox for approvals, a paper traveler on the shop floor, or a manual CSV export before month-end close is not merely a training problem. It is evidence that the official system is failing a real task, is asking for data people do not have, or is enforcing a rule nobody owns.
Most ERP projects document the intended process: purchase requisition becomes purchase order, receipt is posted, invoice is matched, payment is released. Friction lives in the exceptions—partial deliveries, substitute items, disputed prices, emergency purchases, customer-specific terms, returns, and corrections after the accounting period has closed.
Businesses should map each high-volume workflow with the people who perform it, rather than relying only on managers, implementation partners, or the original requirements document. The useful unit of analysis is a transaction from start to finish: what triggers it, which data is required, which system is authoritative, what approval is needed, how long the work waits, and what workers do when the expected path fails.
For Dynamics 365 administrators, this means reviewing more than configuration. Examine security roles, required fields, workflow steps, Power Automate flows, custom extensions, and integrations with Microsoft 365, warehouse systems, point-of-sale software, CRM platforms, payroll tools, and business intelligence reporting. A workflow that appears simple in Finance or Supply Chain Management can still require employees to switch among Teams, Excel, SharePoint, a scanning device, and a third-party portal.
The important distinction is between necessary control and accidental effort. Segregation-of-duties rules, audit trails, and approval thresholds often have legitimate business or regulatory purposes. Re-entering the same supplier, item, or customer information in multiple systems does not. The first should be made understandable and proportionate; the second should be eliminated.
A short list of measurable friction indicators can keep this work from becoming a subjective complaint exercise:
Microsoft’s Dynamics guidance explicitly includes sourcing, cleansing, mapping, transformation, and importing in data-migration planning. That framing is correct but incomplete if data cleanup stops at go-live. Master data needs named business owners, rules for creating and changing records, controls over duplicates, and a regular process for resolving exceptions.
The practical discipline is to assign accountability at the domain level. Procurement should own supplier governance; sales operations should own customer-account standards; supply chain or product management should own item and unit-of-measure definitions; finance should own account structures, accounting periods, and tax configurations. IT should provide the platform controls and integration monitoring, but it cannot decide whether two customer records represent the same legal entity or whether an item description is adequate for receiving staff.
Businesses should also avoid treating data quality as a clean-versus-dirty binary. A record can be technically valid while being operationally unusable. A product may have an item number and cost but lack the replenishment parameters, warehouse dimensions, vendor cross-reference, or lead-time information that lets a planner, buyer, or warehouse operator do their job without calling someone else.
The critical test is whether a user can finish the transaction using the data in the system without a side conversation. If the answer is no, that data domain remains a source of friction regardless of whether the migration technically succeeded.
Each customization should have an accountable business sponsor and a written answer to three questions: which specific workflow does it protect, what measurable result does it improve, and what will it cost to test and maintain through upgrades? If no owner can make that case, the customization is a candidate for retirement.
This is especially relevant for organizations modernizing from an on-premises ERP or moving functions into Dynamics 365 cloud services. Custom code can turn routine platform updates into regression-test projects; custom integrations can become hidden single points of failure; and custom reports can perpetuate obsolete definitions long after the underlying process changes.
A better approach is to distinguish between a real competitive process and an inherited workaround. A proprietary production-planning method that drives margin or quality may justify investment. A custom approval step created because someone distrusted a previous manager’s email process probably does not.
Microsoft’s go-live guidance calls for signed-off integration, user-acceptance, and performance testing alongside data migration, user training, security-role assignment, and cutover planning. Organizations should apply that same discipline to significant changes after go-live. A workflow automation that saves one department time but slows down another department, bypasses controls, or produces inconsistent reporting is not reducing friction; it is moving it.
Teams need role-based training built around common scenarios, exceptions, and consequences—not feature tours. An accounts-payable clerk needs to practice duplicate invoices, partial receipts, disputed charges, and missing purchase orders. A warehouse worker needs to understand what to do when a barcode fails, stock is in the wrong bin, or a picked order changes. A manager needs to know which exception they own and how long an approval is allowed to sit.
The strongest feedback loop begins before deployment and continues after it. Microsoft’s implementation materials advise involving process owners and business users early, then reinforcing change after go-live rather than declaring the project complete at cutover. That is where many organizations fall short: project specialists leave, support teams inherit a system they did not help shape, and power users become unofficial support desks without authority or time.
A durable operating model includes a small cross-functional ERP council that can prioritize fixes, reject local workarounds that corrupt data, and publish what changed. It should have representation from finance, operations, supply chain, sales or customer service, IT, security, and the teams doing the transaction work. The council’s backlog should be ranked by business impact: errors that affect inventory accuracy, revenue, payment, customer commitments, compliance, or close timing should outrank cosmetic requests.
The supplied article page offers no evidence that a new ERP product, methodology, or benchmark has been released. Its value is as a prompt to revisit a problem businesses routinely misdiagnose as user resistance. The underlying record points instead to process misalignment, weak data ownership, overgrown customizations, and insufficient post-go-live support.
For Windows and Microsoft administrators, the most concrete starting point is to review one recurring off-system process this month—an Excel-based reconciliation, an emailed approval, a manual import, or a user-created tracker—and trace it back to the ERP transaction that caused it. Fixing that single break with the process owner in the room will do more for adoption than another company-wide reminder to “use the system.”
The immediate action for business and IT leaders is to find where employees abandon the ERP workflow. A spreadsheet used to calculate inventory, a shared mailbox for approvals, a paper traveler on the shop floor, or a manual CSV export before month-end close is not merely a training problem. It is evidence that the official system is failing a real task, is asking for data people do not have, or is enforcing a rule nobody owns.
Map the real process before changing the ERP
Most ERP projects document the intended process: purchase requisition becomes purchase order, receipt is posted, invoice is matched, payment is released. Friction lives in the exceptions—partial deliveries, substitute items, disputed prices, emergency purchases, customer-specific terms, returns, and corrections after the accounting period has closed.Businesses should map each high-volume workflow with the people who perform it, rather than relying only on managers, implementation partners, or the original requirements document. The useful unit of analysis is a transaction from start to finish: what triggers it, which data is required, which system is authoritative, what approval is needed, how long the work waits, and what workers do when the expected path fails.
For Dynamics 365 administrators, this means reviewing more than configuration. Examine security roles, required fields, workflow steps, Power Automate flows, custom extensions, and integrations with Microsoft 365, warehouse systems, point-of-sale software, CRM platforms, payroll tools, and business intelligence reporting. A workflow that appears simple in Finance or Supply Chain Management can still require employees to switch among Teams, Excel, SharePoint, a scanning device, and a third-party portal.
The important distinction is between necessary control and accidental effort. Segregation-of-duties rules, audit trails, and approval thresholds often have legitimate business or regulatory purposes. Re-entering the same supplier, item, or customer information in multiple systems does not. The first should be made understandable and proportionate; the second should be eliminated.
A short list of measurable friction indicators can keep this work from becoming a subjective complaint exercise:
- Track the number of manual handoffs, re-keyed fields, and off-system spreadsheets required to complete a transaction.
- Measure queue time separately from active work time, especially for purchasing approvals, invoice exceptions, inventory adjustments, and customer credit holds.
- Count transactions that require correction, reversal, or post-entry journal work because the source data was incomplete or wrong.
- Identify which user groups have the most help-desk contacts, failed approvals, access denials, or abandoned transactions.
Treat master data as a product, not a migration chore
ERP users lose confidence quickly when item records, customer accounts, units of measure, tax rules, supplier terms, locations, or chart-of-account codes are unreliable. Once trust drops, teams build their own local records in Excel or email threads. The company then has two versions of operational reality: one in the ERP and one people actually use.Microsoft’s Dynamics guidance explicitly includes sourcing, cleansing, mapping, transformation, and importing in data-migration planning. That framing is correct but incomplete if data cleanup stops at go-live. Master data needs named business owners, rules for creating and changing records, controls over duplicates, and a regular process for resolving exceptions.
The practical discipline is to assign accountability at the domain level. Procurement should own supplier governance; sales operations should own customer-account standards; supply chain or product management should own item and unit-of-measure definitions; finance should own account structures, accounting periods, and tax configurations. IT should provide the platform controls and integration monitoring, but it cannot decide whether two customer records represent the same legal entity or whether an item description is adequate for receiving staff.
Businesses should also avoid treating data quality as a clean-versus-dirty binary. A record can be technically valid while being operationally unusable. A product may have an item number and cost but lack the replenishment parameters, warehouse dimensions, vendor cross-reference, or lead-time information that lets a planner, buyer, or warehouse operator do their job without calling someone else.
The critical test is whether a user can finish the transaction using the data in the system without a side conversation. If the answer is no, that data domain remains a source of friction regardless of whether the migration technically succeeded.
Limit customization to the advantage worth maintaining
Customization has a deservedly mixed reputation, but “use standard functionality” is not a strategy by itself. A company may have legitimate regulatory, manufacturing, contractual, or operational requirements that its ERP cannot meet out of the box. The mistake is allowing every historical preference to become permanent code.Each customization should have an accountable business sponsor and a written answer to three questions: which specific workflow does it protect, what measurable result does it improve, and what will it cost to test and maintain through upgrades? If no owner can make that case, the customization is a candidate for retirement.
This is especially relevant for organizations modernizing from an on-premises ERP or moving functions into Dynamics 365 cloud services. Custom code can turn routine platform updates into regression-test projects; custom integrations can become hidden single points of failure; and custom reports can perpetuate obsolete definitions long after the underlying process changes.
A better approach is to distinguish between a real competitive process and an inherited workaround. A proprietary production-planning method that drives margin or quality may justify investment. A custom approval step created because someone distrusted a previous manager’s email process probably does not.
Microsoft’s go-live guidance calls for signed-off integration, user-acceptance, and performance testing alongside data migration, user training, security-role assignment, and cutover planning. Organizations should apply that same discipline to significant changes after go-live. A workflow automation that saves one department time but slows down another department, bypasses controls, or produces inconsistent reporting is not reducing friction; it is moving it.
Give users a route to report friction—and authority to fix it
Training is necessary, but it cannot compensate for a workflow that does not match the work. Asking employees to complete the same painful sequence more accurately merely produces better-documented frustration.Teams need role-based training built around common scenarios, exceptions, and consequences—not feature tours. An accounts-payable clerk needs to practice duplicate invoices, partial receipts, disputed charges, and missing purchase orders. A warehouse worker needs to understand what to do when a barcode fails, stock is in the wrong bin, or a picked order changes. A manager needs to know which exception they own and how long an approval is allowed to sit.
The strongest feedback loop begins before deployment and continues after it. Microsoft’s implementation materials advise involving process owners and business users early, then reinforcing change after go-live rather than declaring the project complete at cutover. That is where many organizations fall short: project specialists leave, support teams inherit a system they did not help shape, and power users become unofficial support desks without authority or time.
A durable operating model includes a small cross-functional ERP council that can prioritize fixes, reject local workarounds that corrupt data, and publish what changed. It should have representation from finance, operations, supply chain, sales or customer service, IT, security, and the teams doing the transaction work. The council’s backlog should be ranked by business impact: errors that affect inventory accuracy, revenue, payment, customer commitments, compliance, or close timing should outrank cosmetic requests.
The supplied article page offers no evidence that a new ERP product, methodology, or benchmark has been released. Its value is as a prompt to revisit a problem businesses routinely misdiagnose as user resistance. The underlying record points instead to process misalignment, weak data ownership, overgrown customizations, and insufficient post-go-live support.
For Windows and Microsoft administrators, the most concrete starting point is to review one recurring off-system process this month—an Excel-based reconciliation, an emailed approval, a manual import, or a user-created tracker—and trace it back to the ERP transaction that caused it. Fixing that single break with the process owner in the room will do more for adoption than another company-wide reminder to “use the system.”
References
- Primary source: KMVU FOX 26 Medford
Published: 2026-08-04T15:00:04+00:00
Loading…
www.fox26medford.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: learn.microsoft.com
Loading…
learn.microsoft.com - Related coverage: docs.oracle.com
Loading…
docs.oracle.com - Related coverage: docs.oracle.com
Loading…
docs.oracle.com