A manufacturer near the end of its ERP evaluation process recently asked for a Q&A session to discuss how the engagement will work once it's approved. Who will we be working with? What do the first few weeks look like? How do we talk to each other week to week? What should we get ready? And what could push this off schedule?
Those are the right questions, and they come up on nearly every Microsoft Dynamics 365 Business Central project. Here are our answers in one place.
You meet your team before anything is signed
The people introduced to you during the sales process are the people who deliver the project. A solution architect leads the design, a senior functional consultant does much of the hands-on configuration with your team, and a project manager runs the schedule and the communication. One or two other specialists come in and out where their expertise is needed, but the core group stays with you from kickoff through go live.
You get a named primary contact in the project manager, and a named backup. That second name matters more than it sounds. Vacations and sick days happen on both sides, and a project should not stall because one person is away for a week.
The first weeks start with the chart of accounts
Whatever else is in scope, we start with your chart of accounts. The way it is structured shapes how you buy, how you sell, how you run operations, and what you can report on later, so it has to be settled before much else is built.
If yours is bare bones today, that is common, and restructuring it as part of the move is normal work. We bring starter templates as a reference point, chosen to match the kind of business you run, since a services company's accounts look different from a manufacturer's.
The related decision is dimensions, which are the tags Business Central uses to slice your financials by business unit, project, location, or anything else, without turning your account list into a thousand lines.
You can add a dimension later, but removing one is painful and adding one after go live can be messy. Tell us in week one where you expect the business to go, not only how it looks today. Building that in early costs very little; bolting it on afterwards costs a lot.
From there we move to the operational data: your product definitions, your item master, and for a manufacturer your bills of materials and routings. We map out the handful of data structures the whole system runs on, then design your operations around them.
What happens to your history
If you restructure the accounts, where does the old history go? It depends on how you sequence the cutover. If you move everything at once, transforming the old accounts matters less. If some integration has to keep running during a transition period, it is usually easier to restructure the accounts in your existing system first.
Either way, the future state goes into a mapping document. If you are going from 30 accounts to 90, we work out with you where each transaction and balance lands. That is designed up front, not improvised at cutover.
What the weekly rhythm looks like
Expect a standing half-hour stakeholder meeting each week. It covers the overall plan and the deliverables coming up over the next three or four weeks, so nothing on your side arrives as a surprise.
Around that sit the working sessions. Each one has an agenda, a defined list of what we need to get out of it, and a document that comes out the other end. We configure as we go, so a session on the chart of accounts is followed by a session where you are looking at your accounts set up in Business Central. By the second or third session you are seeing your own data in the system.
We plan the detail two or three weeks ahead while holding to the published milestones for the whole project. That keeps the plan honest as we learn how your operation really works.
Two smaller things that save a lot of friction. We keep a running log of risks, open issues, and change requests, so when something surfaces that was not in the original scope it is written down and decided on rather than absorbed quietly. And project documents live in a shared folder you have access to, not in email attachments, so there is one copy of the truth for both sides to look at.
What to get ready, and what to skip
If you already have it, gather your item list, your bills of materials and routings, your customer and vendor lists, and any notes on how different transactions should hit your general ledger. Existing process documentation helps too. Anything you can hand over on day one is time we spend on design instead of discovery.
Do not stay up nights drawing process flow diagrams before kickoff. Documenting how your business runs is part of what the project produces: you finish with a configured system and the documentation that describes it. Most companies come to us with very little written down, and it does not put them behind.
What tends to move a timeline
When clients ask us to name the single biggest risk, we give them five. Each one is easier to handle when it is named early.
The first is an integration nobody mentioned. A connection to a shipping system or a customer portal that never came up in scoping is the classic cause of a change request part way through a build.
The second is data quality. Duplicate customers, vendors with three spellings, and part numbers that mean different things in different spreadsheets all have to be untangled before anything can be migrated.
The third is change readiness. If your team has never worked out of a system like this, training is real work and it needs real time in the plan.
The fourth is fit of any third-party add-on. We pick those during scoping based on a high level view of your requirements. Once detailed process analysis is done, occasionally one turns out not to fit the way we expected.
The fifth is availability, on both sides. Your subject matter experts are the people who know how the business really works, and the first few weeks depend on their time. On our side, staffing changes and emergencies are a normal risk of running a delivery team, and we plan coverage for them.
None of these are exotic. They are the ordinary hazards of an ERP project, which is exactly why the first two weeks are built to surface them. The best way to handle a risk is to find it early and plan around it.
If you want to think it through
If you are sizing up a move to Business Central and want to understand what the early design work would look like for your business, bring us your current process and we will walk through it with you.