Tag: Manufacturing

The Power Buyer’s Guide to Choosing Your D365 ERP Implementation Partner for Manufacturing

Posted on by Ryan Carolan

You’re about to commit MILLIONS on a shiny new Dynamics 365 Finance & Supply Chain Management system. Besides a life partner, choosing a D365 ERP implementation partner is probably one of the biggest decisions you’ll ever make.

Most VPs of IT think of this as a software purchase, but it’s actually a high-stakes talent play. The partner logo gets them the meeting. But never forget it’s the individual consultants, the ones actually sitting in your conference room, the ones that see this thing through to the end with you: they determine whether you hit your go-live. Nobody cares about the logo at that point.

The best partners in the D365 ecosystem don’t want “easy” clients; they want Power Buyers. They want leaders who understand how the talent market works, ask the hard questions early, and know that a project’s success lives or dies by the people assigned to it.

Here are 5 ways to move past the sales pitch and show up as a Power Buyer before the SOW is signed.

1. Stop buying logos. Start buying names.

In the D365 staffing world, we see it every day: a partner has a “strong bench” of 200 people, but only six of them truly understand your specific manufacturing flow. Whether that’s metal extrusion, fresh fruit OR canned areosol products; chances are you will meet someone in the sales cycle who knows your specific industry.

When a partner shows you a polished org chart with titles like “Senior Solution Architect,” they are giving you placeholders. As a Power Buyer, you push past the titles. Ask for the actual names of the people who will be on-site on Day 1. 

The Power Move: Ask for the LinkedIn profiles of the specific team members assigned to your D365 F&SCM project. You aren’t buying “expertise” in the abstract. You’re vetting the track record of the humans configuring your production orders, your warehouse management, and your financial posting logic. If a partner won’t name the team before the ink is dry, they are likely still scrambling to staff your project. And sometimes that’s okay- but you just want to know up front. If you skip this, don’t be surprised if you never again see the awesome consultant who “just got it” during the pitch.

Need trusted D365 expertise your internal team doesn’t have yet? Our vetted independent contractors are ready to jump in. Let’s talk:

BOOK A FREE DISCOVERY CALLL

2. Audit your D365 ERP implementation partner’s project history

Every partner has three “gold star” references they’ve used for years. Those are marketing assets, and fair enough.

But to see how your D365 ERP implementation partner actually handles a complex manufacturing environment, ask for a list of every D365 F&O go-live they’ve done in your vertical in the last 24 months. Then, you pick three. When you get the VP of IT on the phone, ask the uncomfortable questions:

“What would you do differently if you were starting this project again?” Nobody says “nothing.” Their answer will tell you exactly where the blind spots were, whether it’s warehouse configuration, complex BOMs, or post go-live support.

“Were the people who started the project the same ones who finished it?” Consultant continuity is one of the biggest factors in D365 implementation success. Understanding how the partner manages team stability tells you what to expect on your project.

“How deep was their ‘X’ manufacturing knowledge?” There’s a massive difference between a partner who has implemented D365 for a professional services firm and one who has configured production orders, BOM structures, and advanced warehouse management for a company that actually makes things. Apples, packaging, golf balls, paperclips: you want to have consultants who have as close to whatever your ‘X’ is.

3. Stress-test with ugly scenarios from your plant floor

Most partner evaluations stay at the demo level. But manufacturing is messy. Light assembly is a world away from process manufacturing with catch-weights and shelf-life constraints.

Don’t let the D365 ERP implementation partner show you a clean demo. Give them a scenario that actually keeps your plant manager up at night.

The Power Move: Hand them a real-world problem: “We have a production line with 4 co-products where yield fluctuates 15% based on raw material quality. Our warehouse team needs to receive these into different storage zones based on shelf life and temperature requirements. Show me exactly how your team would configure this in D365 Supply Chain Management.”

If they get specific fast, they’ve been in the trenches. If they pivot back to “platform capabilities,” they’re learning on your dime.

This exercise helps both sides figure out fit early, before anyone commits serious time and budget. The best D365 partners actually appreciate this kind of detail in the sales process because it tells them you know your business and you’re ready to engage at a serious level.

4. Separate “delivery” from “outcomes” on your D365 project

Here is a staffing reality: the partner’s Project Manager and your Project Manager have different KPIs.

The partner’s PM is there to manage their team and hit SOW milestones. Your PM is there to protect your business outcomes. The person who pushes back when a configuration decision will break your shop floor reporting six months from now. The person who escalates when timelines are drifting but the status report still says green.

The Power Move: If you don’t have a D365 F&O-experienced PM internally, hire an independent ERP Project Manager with direct manufacturing experience. A Power Buyer knows that having an advocate who speaks “Partner” and “Manufacturing” fluently reduces friction and ensures the partner delivers value, not just code.

The best implementations I’ve seen have this structure in place. The partner appreciates having a client-side counterpart who understands D365, speaks the same language, and can make decisions quickly. It makes the whole project run better for everyone.

5. Negotiate talent insurance into your D365 implementation contract

The D365 talent market is competitive (no thanks to people like me :D)… Consultants get headhunted or moved to bigger projects constantly. Most VPs accept this as “just part of the game.”

You shouldn’t.

Before you sign, build resource continuity into your commercial agreement. This isn’t adversarial. It’s practical risk management that protects your manufacturing implementation timeline and your budget.

The Power Move: Negotiate these four staffing safeguards:

  • 14 days written notice before any key resource is rolled off your project. Not a phone call the day before. Written notice with enough time for you to assess the impact on your warehouse configuration, your finance setup, or whatever module that person owns.
  • Approval rights on replacements. You interview the new consultant just like a job candidate. If you’re running a D365 Finance & Supply Chain Management implementation in manufacturing, the replacement should have equivalent manufacturing experience. Full stop.
  • Two-week mandatory overlap for knowledge transfer. The outgoing consultant and the incoming one work side by side for at least two weeks ideally. This protects the project timeline and ensures nothing falls through the cracks.
  • A ramp-up rate adjustment while the new consultant learns your business. If a replacement needs 3-4 weeks to get up to speed on your plant floor processes, discuss how that ramp-up period is handled commercially. Good partners are open to this conversation because they understand the value of long-term client trust.

Choosing the right D365 ERP implementation partner: setting the standard

The difference between a live system and a successful business outcome is the quality of the people in the room. Yes, the people that come onto your project with your partner are crucial; but do not underestimate the importance of having excellent people internally too.

It shows you’re a serious client who is ready to engage. And in this market, serious clients get the best teams. And the best outcomes.

Want to know where you stand today?

We built a quick Partner Dependency Assessment that tells you whether you’re in control of your D365 implementation, or whether your D365 ERP implementation partner is running the show.

TAKE IT HERE

 

About the Author

Ryan Carolan is the founder of d365contractors.com, connecting US manufacturing companies with pre-vetted, independent D365 Finance & Supply Chain Management experts. 14 years exclusively in D365 staffing. Hundreds of contractor placements into manufacturing implementations across the US.

Most weeks, he waffles on about stuff like this online.

Follow Ryan on LinkedIn →

 

How to Build Your Internal D365 F&O Team While Using External Experts

Posted on by Ryan Carolan

When helping customers build their internal D365 F&O team, the story usually starts like this:

  • Company spends $ 3M to $10M+ on an ERP implementation.
  • The partner runs 95% of the project.
  • External consultants configure the system, build the integrations, and lead the testing.
  • The project goes live. Wahoo.
  • The partner rolls off. Uh oh.

IT leadership looks around the room and realizes nobody internal actually knows how D365 works. The system is live, but most of the ERP knowledge walked out the door with the consultants.

Building an internal D365 F&O team while using external experts isn’t something that happens naturally. It has to be designed. And it has to be driven by the VP of IT or CIO, because nobody else in the organisation has both the authority and the incentive to make it happen.

Why your internal D365 F&O team doesn’t develop by default

Let’s be honest about the incentive structure.

Your implementation partner is paid to deliver a working system. They are not paid to build your internal team’s capability. Knowledge transfer appears in every SOW, usually as a line item somewhere near the bottom. In practice, it means a few training sessions in the final weeks of the project, when everyone is exhausted and focused on go-live cutover, not learning.

The external consultants on the project are focused on configuration, testing, and hitting milestones. They’re good people doing their job. But their job is to deliver the system, not to teach your team how to run it. And your internal team members are often split between their day jobs and the project, which means they’re in the room for the workshops but not doing the hands-on work that creates real capability.

The result is predictable. Your team watches the consultants configure D365. They attend the training. They pass the knowledge transfer checkbox. And six months after go-live, when something needs to change, they don’t know how to do it. Not because they’re not smart. Because watching someone configure a system and actually configuring it yourself are two completely different things.

If you want to build a real internal D365 F&O team, you have to change the structure of the project itself. Not bolt on training at the end.

Need D365 expertise your internal team doesn’t have yet? Our vetted independent contractors are ready to jump in. Let’s talk:

BOOK A FREE DISCOVERY CALLL 

Decide what your internal D365 F&O team actually needs to own

You don’t need to replicate your partner’s entire team internally. That’s unrealistic and unnecessary. What you need is enough internal D365 F&O team that can handle 80% of your post go-live needs without picking up the phone.

For a manufacturing company running D365 Finance & Supply Chain Management, that typically means owning three things internally.

Functional configuration knowledge. Someone who understands how your D365 Finance module is configured and can make changes to posting profiles, number sequences, workflows, and reporting dimensions without calling the partner. Someone who understands your Supply Chain configuration well enough to adjust warehouse parameters, modify production order defaults, and troubleshoot planning runs. These don’t need to be the same person. But they need to exist.

Data and reporting capability. Someone who can build and modify Power BI reports, manage data entities, and handle routine data imports and exports. In manufacturing, this is critical. Your operations team will need new reports constantly as the business evolves. If every report requires an external engagement, you’ll never keep up.

Integration and technical troubleshooting. At least one person who understands how D365 connects to your other systems, can read integration logs, and knows when something breaks whether it’s a D365 issue, a middleware issue, or an upstream data issue. This person doesn’t need to be an X++ developer. But they need to understand the architecture well enough to triage problems quickly.

Everything else, deep X++ development, major configuration changes, version upgrades, complex new module deployments, those are the things you bring external experts in for. The goal is to stop paying consulting rates for things your team should be able to handle.

How to structure the project so your internal D365 F&O team actually learns

This is where most companies might struggle. They assign internal people to the project team but don’t change what those people actually do during the project.

If you want to build an internal D365 F&O team, your people can’t just attend workshops and review documents. They need to do the work. Alongside the external consultants, not watching from the side.

Pair your internal people with external consultants on every module. Not as observers. As co-configurators. Your Finance lead should be in the system configuring the chart of accounts alongside the partner’s consultant, not reviewing a document that describes the chart of accounts. Your Supply Chain lead should be setting up warehouse parameters, not approving a design document that lists them.

This slows the project down slightly at the beginning. Every partner will tell you that. And they’re right. But it accelerates everything after go-live, because your team actually knows what they built and why. The IT leaders I’ve worked with who insist on this approach consistently spend less on external support in the 12 months after go-live. Significantly less.

Make your internal team lead UAT, not just participate. User Acceptance Testing is the best learning opportunity in the entire project. When your team designs the test scripts, executes them, troubleshoots the failures, and documents the results, they build capability that no training session can replicate. If the partner is running UAT and your team is just clicking through scripts someone else wrote, you’ve missed the single best chance to build your internal D365 F&O team.

Require your team to deliver the end-user training. Nothing exposes knowledge gaps faster than having to teach someone else. If your internal Finance lead can’t train the AP team on the new invoice process in D365, that’s a gap you need to fill before go-live, not after. This also builds credibility. When your end users see that an internal person can answer their questions, they trust the system more. Trust is an underrated currency in ERP implementations.

Use external experts strategically, not as a crutch

None of this means you shouldn’t use external D365 F&O experts. You absolutely should. The question is how.

The best approach I’ve seen is what I’d call a “teach and transfer” model. You bring in an external expert for a specific capability gap, with a defined scope and a clear handover plan. Not an open-ended engagement where the consultant does the work and your team watches.

For example. Your internal team doesn’t know how to configure Advanced Warehouse Management in D365. Why would they!? You bring in an independent WMS specialist for 8-12 weeks. During those weeks, they configure the system alongside your internal warehouse lead. Your person is in the system every day, making changes, making mistakes, learning the logic. At the end of the engagement, your warehouse lead can handle 60-70% of WMS configuration changes independently. Much better than 0%, right? The specialist leaves behind documentation, but more importantly, they leave behind a person who actually understands the system.

Compare that to the alternative. You engage the partner for WMS configuration. Their consultant does it. Your team reviews the design document and signs off. After go-live, any WMS change requires a partner ticket, a scoping call, and a billing cycle. For years.

Independent contractors are particularly effective for this kind of targeted capability building. They don’t have a practice to feed or a bench to fill. Their success is measured by whether your team can operate independently after they leave. That’s a fundamentally different incentive than a partner whose revenue depends on your ongoing dependency (sorry partners :D). We covered this dynamic in detail in The Power Buyer’s Guide to Choosing Your D365 ERP Implementation Partner.

The “shadow team” approach that actually works

Another effective model I’ve seen for building an internal D365 F&O team is what some organisations call a “shadow team.” It’s simple in concept, but requires commitment from IT leadership to protect. And buy-in from the business.

For every external consultant on the project, you assign an internal person as their shadow. Not a full-time project resource necessarily, but someone who is present for every key decision, every Functional Design Document, every configuration session, every testing cycle for their module. They have access to the same environments. They’re making changes in the system alongside the consultant. They’re asking “why did you configure it that way?” constantly.

The shadow team approach works because learning happens through doing, not watching. After 6-12 months of working alongside a D365 Finance specialist, your internal Finance lead has seen every configuration decision, understood the trade-offs, and built the muscle memory to operate the system independently.

The challenge is protecting these people’s time. Their managers will want them back on their regular work. Other priorities will compete for their attention. This is where you, as the VP of IT, have to be firm. If you pull your shadow team members back to their day jobs during the implementation, you lose the capability building and you’ll pay for it in external consulting fees for years afterward.

Budget for backfill. Hire temps or redistribute work. Whatever it takes. The cost of protecting your shadow team during the implementation is a fraction of what you’ll spend on external support if you don’t.

Developing your internal D365 F&O team after go-live

Internal D365 F&O team building doesn’t stop at go-live. In fact, the first 6 months after go-live is when the most valuable learning happens, because your team is dealing with real transactions, real exceptions, and real users.

During this period, keep at least one experienced external D365 F&O resource embedded with your team. Not to do the work. To coach. When your internal Finance lead encounters something they haven’t seen before, they have someone to ask. When your Supply Chain owner needs to adjust a planning parameter, someone is there to guide them through it the first time so they can do it independently the next time. A fractional Solution Architect might be a good idea here.

This is a fundamentally different engagement model than traditional post go-live support, where the partner runs a ticket queue and your team submits requests. That model builds dependency. The coaching model builds capability. It costs the same or less, and the ROI compounds over time because every issue your team resolves independently is one you never pay an external rate for again.

We covered the broader post go-live strategy in D365 F&O Post Go-Live: Why the First 6 Months Define Your ROI.

Measure it. Report on it. Protect it.

If you don’t invest in your internal D365 F&O team, capability will erode. People leave. Priorities shift. The team that was confident at the 6 month mark starts losing ground by month 18 if nobody is paying attention.

Track simple metrics with simple questions:

  • How many configuration changes were handled internally versus externally this quarter?
  • What’s the average time to resolve a D365 support ticket internally?
  • How many reports were built by your team versus requested from a partner?
  • Are your module owners still getting development time, or have they been fully absorbed back into their operational roles?

Report these to your leadership team. Not as vanity metrics. As cost avoidance. Every configuration change your team handles internally is a partner engagement you didn’t pay for. Every report your team builds is $5K-$15K you didn’t spend. Over 3-5 years, the compound savings of a capable internal team versus permanent partner dependency is enormous.

And when your CFO asks why you’re requesting budget for training, D365 conferences, certifications, or a dedicated D365 support role, you have the data to justify it. Not as an expense. As an investment that’s already paying for itself.

The decision only a VP of IT can make (or a CIO!)

Building your internal D365 F&O team while using external experts is a leadership decision. It requires you to structure the project differently, protect your team’s time, budget for backfill, choose engagement models that prioritise knowledge transfer over speed, and measure the results over years, not weeks.

Nobody else in the organisation will drive this. Your partner won’t, because their business model benefits from your dependency. Your project manager won’t, because their focus is go-live. Your team won’t, because they’re overwhelmed and don’t have the authority to demand co-configuration time.

This one is on you. And the IT leaders who get it right build teams that can run, maintain, and improve D365 for years without calling for help every time something changes.

If you haven’t started these conversations internally yet, and you’re already in an implementation or about to start one, the questions in 5 Questions to Answer Before You Talk to Any D365 F&O Vendor will help you get your house in order first.

About the Author

Ryan Carolan is the founder of d365contractors.com, connecting US manufacturing companies with pre-vetted, independent D365 Finance & Supply Chain Management experts. 14 years exclusively in D365 staffing. Hundreds of contractor placements into manufacturing implementations across the US.

Most weeks, he waffles on about stuff like this online.

Follow Ryan on LinkedIn →

 

Why D365 F&O Data Readiness Is the #1 Project Killer for Manufacturers

Posted on by Ryan Carolan

D365 F&O data readiness is the single most underestimated factor in ERP implementations.

Despite what you see on LinkedIn: nobody ever killed an entire implementation with a bad configuration decision. Configurations can be fixed. Workflows can be adjusted. Security roles can be rebuilt. But when your data is wrong? That breaks everything, and it breaks it in ways that are almost impossible to fix quickly.

After 14 years in D365 staffing, I’ve placed hundreds of contractors into manufacturing implementations across the US. And the pattern is always the same. The project plan has a line item for “data migration.” It sits somewhere between “testing” and “cutover.” It gets a few weeks of attention near the end. And then it can blow up the entire timeline.

D365 F&O data readiness isn’t a task you check off. It’s the foundation everything else sits on. Get it wrong and your configuration doesn’t work, your testing is meaningless, your users don’t trust the system, and your go-live becomes a disaster recovery exercise.

And if you plan to board the Microsoft ERP AI train, this stuff has never been more important.

Why D365 F&O data readiness is YOUR responsibility, not your partner’s

Here’s something worth understanding early. Your implementation partner’s SOW almost certainly includes a line that says something like: “Client is responsible for providing clean, validated data in the agreed format by the agreed date.”

Read that again. That’s your partner being clear about where their scope ends. D365 F&O data readiness sits with you.

Partners scope their projects assuming your data will arrive clean, on time, and in the right format. Their timelines, their resource plans, their testing schedules — all of it assumes the data is ready when they need it. When it isn’t, and it almost never is, the project slips. But the partner isn’t absorbing that cost. You are.

This isn’t a criticism of partners. It’s just how the commercial model works. The partner can’t price the risk of your data being a disaster, because they don’t know the state of your data until they’re already deep into the project. So the SOW places responsibility with you, and most IT leaders sign it without realizing what they’ve just agreed to.

Data readiness starts 6 months before you think it does

Most manufacturing companies don’t start thinking about their data until the implementation partner asks for it. By then, you’re already behind.

For a mid-market manufacturer running a legacy ERP, or worse, running critical processes on spreadsheets alongside the ERP, the data landscape is usually a mess. You’ve got customer records in three different formats across two systems. Vendor master data that hasn’t been cleaned since the last ERP migration. Item masters with duplicate records, inconsistent units of measure, and descriptions that mean different things to different departments.

And that’s just master data. When you get into transactional data — open purchase orders, open sales orders, inventory balances, work-in-progress, open AR and AP — the complexity multiplies. Every one of those transactions has to be accurate on day one of go-live, because your finance team can’t close the month if the opening balances are wrong.

D365 F&O data readiness means starting the assessment and cleanup months before your implementation kicks off. Not weeks. Months. If you’re planning a January go-live, the data conversation should be happening in the spring of the prior year. That sounds aggressive. It isn’t. It’s realistic.

The 5 data problems that kill D365 F&O projects at manufacturing companies

In 14 years of placing D365 contractors into these exact projects, I see the same five D365 F&O data readiness failures over and over again. Every single one of them is preventable. None of them are surprising. And yet they keep happening.

1. Nobody owns the data. The project has a project manager. It has functional consultants. It has a steering committee. But who owns the data? Usually the answer is “everyone,” which really means nobody. D365 F&O data readiness requires a named person, ideally someone internal, who owns the entire data workstream end to end. Extraction, cleanup, validation, mapping, testing, cutover. One person. Full accountability.

2. The item master is a disaster. For manufacturers, the item master is the most critical and most neglected data set. You’ve got thousands of SKUs, many of them duplicated, many with incomplete Bills of Materials, many with incorrect units of measure. Some items are active. Some haven’t been ordered in 5 years but nobody marked them inactive. Your D365 configuration for Supply Chain Management depends entirely on the item master being accurate. Production planning, inventory valuation, procurement — all of it breaks if the item data is wrong.

3. Chart of Accounts doesn’t map cleanly. Your legacy chart of accounts was designed for a different system and a different era of the business. D365 F&O uses financial dimensions differently than most legacy ERPs. Mapping the old chart of accounts to the new structure is a design decision, not a copy-paste exercise. When this gets treated as a last-minute data task instead of a strategic finance decision, you end up with a chart of accounts that technically works but makes reporting a nightmare for years.

4. Historical data scope is undefined. How much history are you bringing over? All of it? 2 years? 5 years? Just open transactions? This decision affects timeline, testing complexity, and storage. And it’s usually not made until someone asks, which is usually too late. Every manufacturing company wants “all the history” until they realise what that actually means in terms of data cleanup, validation, and cutover time.

5. Nobody tested the data until UAT. This is the killer. The team extracts the data, transforms it, loads it into D365, and then doesn’t validate it properly until User Acceptance Testing. By that point, you’re weeks from go-live. The users start testing and immediately find that half the item records are wrong, opening balances don’t match, vendor payment terms are missing, and warehouse locations don’t exist. Suddenly the entire go-live timeline is at risk because of data issues that could have been caught 3 months earlier with a simple mock migration.

What good D365 F&O data readiness actually looks like

The companies that get this right do something very simple. They treat data as its own workstream with its own timeline, its own resources, and its own checkpoints. Not bolted onto the end of configuration. Not somebody’s side project. A proper workstream.

Good D365 F&O data readiness follows a pattern. First, you assess what you have. That means pulling every data source into the light — the ERP, the spreadsheets (YES finance team: that means EVERY spreadsheet you use!!), the Access databases somebody built 10 years ago, the warehouse system that doesn’t talk to anything else. You document what’s there, what’s missing, what’s duplicated, and what’s flat-out wrong.

Then you make decisions. What data migrates to D365? What gets archived? What gets cleaned up versus rebuilt from scratch? These are business decisions, not technical ones. Your finance team decides the chart of accounts mapping. Your supply chain team decides which items are active. Your operations team decides how much production history matters. The IT team coordinates, but the business owns the decisions.

Then you test early and test often. Run a mock migration in month 2 or 3 of the project, not month 8. Load the data into a sandbox environment and let users actually look at it. They’ll find problems immediately. Good. That’s the point. Find the problems early when you have time to fix them. Not during UAT when you don’t.

And you run the full mock cutover at least twice before the real thing. The first time will be ugly. The second time will be smoother. By the time you do it for real, the team has done it before and knows exactly what to expect.

Why your internal team has to own D365 F&O data readiness

Your partner can build the data migration templates. They can help you map fields from legacy to D365. They can run the technical import process. But they cannot clean your data for you. They don’t know your business well enough to decide whether item #4592 is the same as item #4592-A, or whether customer “ABC Industries” and “ABC Industries Inc” are the same entity, or whether that open PO from 2021 should be migrated or written off.

These are decisions that require deep business knowledge. The kind of knowledge that only exists inside your organisation, usually in the heads of people who have been there for years. Or a highly-skilled contractor who can come in, ask the right questions and get smart decisions made. Those people are the ones who need to be driving D365 F&O data readiness. Not the partner. Not the project manager. Your people.

This connects directly to something I wrote about in how to build your internal D365 F&O team. Data ownership is one of the earliest and most important capabilities your internal team should develop. If your team can’t own the data during implementation, they definitely can’t own it after go-live. And if nobody owns the data after go-live, the system degrades steadily from day one.

The real cost of poor D365 F&O data readiness

I’ve seen implementations delayed by 3-6 months because of data issues alone. That’s not 3-6 months of waiting. That’s 3-6 months of paying for partner resources who can’t move forward until the data is ready. That’s 3-6 months of your internal team being stretched across both the legacy system and the new one. That’s 3-6 months of change fatigue eroding user confidence before the system even goes live.

And the financial impact goes beyond the obvious. A delayed go-live means the ROI clock doesn’t start ticking. If you budgeted for 12 months to payback and the project is 6 months late, your finance team is now explaining to the board why the ERP investment isn’t delivering returns on the original schedule. That’s a career conversation nobody wants to have. I covered the mechanics of this in detail in why the first 6 months after go-live define your ROI.

Then there’s the hidden cost: user trust. When users log into D365 on day one and their data is wrong — the item descriptions don’t match, the inventory quantities are off, the customer addresses are outdated — they stop trusting the system immediately. And once users lose trust in an ERP, it is incredibly difficult to get it back. They revert to spreadsheets. They build workarounds. They stop entering data properly because “the system is wrong anyway.” That’s the death spiral that turns a recoverable data issue into a permanent adoption problem.

ERP data readiness is a leadership decision

If you’re a VP of IT or an ERP Program Manager reading this, the message is simple. Data readiness isn’t a task for someone on the project team to figure out. It’s a decision you need to make early, resource properly, and protect throughout the implementation.

That means assigning a dedicated data owner before the project starts. It means getting your finance, supply chain, and operations leaders to commit time — real time, not “squeeze it in between your day job” time — to data cleanup and validation. It means budgeting for data resources, whether that’s internal headcount, a contractor who specialises in D365 data migration, or both. And it means running mock migrations early enough that problems surface when there’s still time to fix them.

If you haven’t had the internal data conversation yet, the questions in 5 questions to answer before you talk to any D365 F&O vendor will help you figure out where you stand. Particularly question 4, which asks directly: how clean is your data? Your vendor might assume it’s fine. It probably isn’t.

The companies that nail D365 F&O data readiness don’t do anything magical. They just start early, assign ownership, test relentlessly, and treat data as a first-class workstream instead of an afterthought. It’s not glamorous. It doesn’t show up in any demo. But it’s the single biggest factor in whether your D365 implementation delivers real value or becomes an expensive lesson in what happens when nobody owns the data.

I’ll make a bet now: that starting in 2026 those companies that get data right will also flourish in the agentic ERP world we are without doubt transitioning to.

 

About the Author

Ryan Carolan is the founder of D365contractors.com, an elite community of independent D365 consultants. Spends most of his time connecting US manufacturing companies with pre-vetted, independent D365 Finance & Supply Chain Management experts (or permanent staff via Bond Patrick). 14 years exclusively in D365 staffing. Hundreds of contractor placements into manufacturing implementations across the US.

Most weeks, he waffles on about stuff like this online.

Follow Ryan on LinkedIn →

 

D365 F&O User Adoption: Why Your Plant Floor Doesn’t Trust the System

Posted on by Ryan Carolan

My 4-year-old taught me everything I need to know about D365 F&O user adoption the other day. If the toy does not work the way the box promised, it goes in the corner. No troubleshooting. No second attempt. Just “it’s broken, Daddy” and he moves on to something he trusts.

He is 4. He is also right. That is exactly what your warehouse team does when D365 ERP does not work the way they were told it would. They do not file a ticket. They open Excel and move on. Someone configured D365 based on how manufacturing should work. Not how yours actually works. The configuration missed the reality, and now the plant floor has decided the system cannot be trusted with the real work.

This is about more than insufficient training; it is a user adoption problem rooted in trust.

D365 F&O user adoption fails when the system does not match reality

Every trust breakdown starts with a gap between what was configured and what actually happens on the floor. That gap almost always originates in discovery: wrong people in the room, wrong questions asked, or not enough time allocated. We covered this in D365 F&O discovery: where your implementation is won or lost.

The exceptions are the real process. The third-shift dock crew handling returns differently. The scheduling workaround your lead planner invented six years ago. The biggest customer changing their order every Friday afternoon. When the system cannot handle these, the people who deal with them every day stop trusting it. And once trust is gone, no amount of training brings it back. Only fixing the actual gaps will.

Need D365 expertise your internal team doesn’t have yet? Our vetted independent contractors are ready to jump in. Let’s talk:

BOOK A FREE DISCOVERY CALL

The Monday 6am test

This exercise will tell you more about D365 F&O user adoption at your plant than any survey ever could. Have your production supervisor walk through a full day using the D365 process. Monday, 6am to last shipment. Not the happy path. Every exception. Every “oh, we always do it this way.”

  • Shadow the morning. Does the D365 production schedule match what actually gets run first? At most manufacturers, the first run of the day is already an adjustment. A machine went down. A delivery was short. A rush order came in. If the system cannot accommodate this cleanly, your planner is already working outside of it before 7am.
  • Follow the exceptions. A material substitution. A partial receipt. A production order that needs splitting because half the batch failed quality. These are not rare events. They are daily life. Every one the system cannot handle is a moment where trust erodes.
  • Watch the last shipment. By end of day, how much was captured accurately in D365? If your warehouse lead spends 30 minutes reconciling adjustments, the system is reflecting the plan, not reality. And at a manufacturer, those two have usually parted ways by mid-afternoon.

If the system cannot handle the exceptions, the design is not done.

Where D365 F&O user adoption (usually) breaks down at manufacturers

Trust breaks in the same four places at nearly every manufacturer:

  • Receiving. Delivery does not match the PO. D365 cannot process it as it actually arrived. “I’ll fix it in the system later” is where trust starts dying.
  • Production scheduling. The D365 schedule rarely survives contact with the plant floor. If adjusting it in real time is difficult, your planner stops using it for scheduling and uses it only for reporting. You paid for an ERP. You are getting a very expensive filing cabinet.
  • Month-end close. Workarounds upstream mean inaccurate production transactions. Finance inherits the mess, builds reconciliation spreadsheets, and adds days to the close.
  • Reporting. Leadership pulls a report. Plant manager says “those numbers are not right.” Once executives stop trusting the data, the entire ROI case is at risk.

How to rebuild trust and fix the adoption problem

Most companies try to fix D365 F&O user adoption with more training. More lunch-and-learns. More posters in the break room. None of that works when the root cause is a configuration that does not match how the plant operates. You cannot train someone into trusting a system that does not support their job.

  • Fix the configuration, not the people. Most trust gaps are configuration adjustments, not architectural problems. A senior functional D365 ERP consultant who knows Quality OR Advanced Warehousing can identify the changes needed in 2-4 weeks. We covered how this works in how to build your internal D365 F&O team while using external experts.
  • Start with the most visible pain. Run the Monday 6am test. Document every workaround. Fix the one that costs the most time first. One fixed problem is worth more than ten training sessions.
  • Involve the floor in the fix. The people who built the workarounds understand the gaps best. When they are part of designing the fix, they own it. That is how adoption actually works. Bottom-up trust recovery, one process at a time.

If you are past go-live and seeing workarounds multiply, the roadmap in D365 F&O post go-live optimization will help you structure the effort.

D365 F&O user adoption is a trust problem, and trust is earned on the plant floor

Your steering committee can declare the implementation a success. Your dashboard can show green. None of that matters if the people who run your operation do not trust the system. Trust is built one fixed gap at a time. When the receiving team sees that D365 handles deliveries the way they actually arrive. When the planner adjusts the schedule without calling IT. When finance closes the month without a reconciliation spreadsheet. When the COO pulls a report and the plant manager nods instead of wincing.

No ERP earns trust by being powerful. It earns trust by being accurate. And accuracy starts with a configuration that reflects how your plant actually operates, exceptions and all.

If your plant floor is running workarounds and D365 F&O user adoption is not where it needs to be, book a free discovery call. We will connect you with a community member who can talk through where the trust gaps are and what kind of targeted support would actually fix them:

BOOK A FREE DISCOVERY CALL

About the Author

Ryan Carolan is the founder of D365contractors.com, connecting US manufacturing companies with pre-vetted, independent D365 Finance & Supply Chain Management experts. 14 years exclusively in D365 staffing. Hundreds of contractor placements into manufacturing implementations across the US.

Most weeks, he waffles on about stuff like this online.

Follow Ryan on LinkedIn →