“We need ERP” is rarely the whole problem
A leadership team usually starts looking at Business Central when the business has become harder to control. Month-end takes too long. Stock numbers cannot be trusted. Reports arrive late. Teams copy the same information between spreadsheets, finance tools and operational systems.
The phrase “we need ERP” is often shorthand for a more specific issue: weak process design, poor data quality, limited visibility, unclear ownership or a system that no longer matches the way the business operates.
Before buying Business Central, define the operational problem, the outcome you need, the data required, the people affected and the decision the system must support. This reduces the risk of wrong scope, wasted spend and a Business Central implementation that goes live without fixing the real business issue.
That distinction matters. A product demo can show what Business Central can do. It cannot, by itself, tell you whether the business needs a full ERP move, a phased finance-first setup, cleaner data, better stock control, fewer manual approvals or a more disciplined reporting model.
A finance director may describe the pain as slow reporting. The root cause might be inconsistent posting rules, poor dimensions, missing approvals or manual invoice handling. An operations leader may ask for better inventory visibility. The issue might sit in item setup, warehouse processes, stock movement discipline or disconnected purchasing data.
The visible symptom is not always the real problem.
That is why Business Central evaluation should start with current-state mapping, not feature comparison. Leaders need a clear view of how work happens today: where information is entered, where it is checked, where it is rekeyed, where it gets delayed, and where people have built workarounds because the existing system does not support the job properly.
This is also the point where people and process readiness enter the decision. Business Central can create stronger control across finance, stock, purchasing and reporting, but it will not repair unclear ownership or inconsistent working habits on its own. Weak processes simply become configured processes. Poor data simply becomes migrated poor data.
The safer question is not, “Which ERP should we buy?”
It is, “What business problem must this system remove, and what would prove it has been removed?”
For a growing business, that answer might be faster close, fewer finance admin steps, better stock accuracy, stronger approval control, cleaner reporting or less dependency on spreadsheets. Each outcome leads to different decisions about setup, data, workflows, integrations, training and phasing.
Business Central is a serious operational decision, not a software shopping exercise. The earlier the real problem is named, the easier it becomes to protect scope, budget, adoption and delivery confidence.
Use the Problem Fit Test before you look at features
The fastest way to improve a Business Central decision is to separate the symptom from the cause. A slow report, a stock error or a manual approval chain may point to a process issue, a data issue, a scope issue or a genuine capability gap. Each one needs a different buying decision.
Use the Problem Fit Test before demos, quotes or detailed solution design.
| Business symptom | Likely cause | Business risk | Discovery question |
| Reports take too long to produce | Data is entered late, duplicated or held in different systems | Leaders make decisions from stale information | Where does the source data begin, and who owns it? |
| Stock figures are disputed | Item, location or movement rules are unclear | Purchasing, fulfilment and cash flow become harder to control | Which stock movements are trusted today, and which are checked manually? |
| Finance spends too much time on admin | Workflows depend on email, spreadsheets or rekeying | Cost increases, errors rise and close becomes harder to predict | Which steps could be standardised before Business Central is configured? |
| Teams ask for “more functionality” | Requirements have not been prioritised | Scope expands before value is proven | Which needs are must-have, and which can wait for a later phase? |
| Dashboards are not trusted | Reporting is built on weak data discipline | Visibility improves on paper but not in decisions | What data rules must be fixed before reporting can be useful? |
This test prevents a common ERP selection mistake: treating every operational frustration as a software feature request.
A process issue needs current and future process maps. Leaders should know where work starts, who approves it, what exceptions occur, and where delays or duplicate effort appear. Business Central can support better workflows, but it needs a clear operating pattern to support.
A data issue needs ownership, structure and cleaning rules. Poor customer, supplier, item, finance or stock data will not become trustworthy because it has moved into a new system. Data migration should be treated as a business control task, not a technical upload.
A scope issue needs prioritisation. Many Business Central projects become expensive because every department brings a wish list before the business has agreed what matters first. Separate must-have requirements from useful improvements, and decide what belongs in phase one.
A capability gap needs honest fit-gap analysis. Some needs will fit standard Business Central. Some may need configuration, an approved add-on, Power Platform, integration with another system or a later design decision. The danger is not customisation itself; the danger is customising before the business understands why.
The Problem Fit Test gives leaders a practical way to slow the wrong conversations down and speed the right ones up. It moves the Business Central implementation discussion from “show us what the system does” to “show us how this fixes the constraint that is costing time, control or confidence”.
What should be agreed before Business Central is set up?
Business Central setup should follow the outcome the business wants, not the other way round. Before modules, workflows, integrations or migration choices are discussed, leaders should agree what must improve: faster close, better stock control, fewer manual finance steps, clearer approval routes or more reliable reporting.
This is where many ERP decisions drift. The business starts with a valid pain, then moves too quickly into screens, licences and configuration. The practical risk is that the project becomes technically active before it is commercially clear.
A better Business Central decision starts with the outcome and works backwards.
If the goal is a faster month-end close, the discovery conversation needs to test posting rules, approval points, recurring journals, bank matching, invoice capture, reporting packs and who owns each close task.
If the goal is better inventory control, the setup discussion needs to cover item data, locations, stock movements, purchasing rules, replenishment, warehouse processes and the reporting needed to trust availability.
If the goal is less manual administration, the business needs to identify which steps should be standardised, which can be automated, and which still need human review because they carry financial or operational risk.
The outcome also shapes what data matters. A business that wants cleaner margin reporting may need better dimensions, product categorisation and transaction discipline. A business that wants stronger stock visibility may need item, location and unit-of-measure data cleaned before migration. A business that wants fewer finance bottlenecks may need clearer roles and approval limits before workflow design begins.
Use this simple risk map during early Business Central planning:
| Weak input before setup | Likely project risk | Decision implication |
| No agreed outcome | Go-live becomes the success measure | Define value before delivery starts |
| Poor current process maps | Configuration reflects old workarounds | Map the process before designing the system |
| Unclear data ownership | Reports are questioned after launch | Assign owners before migration |
| Vague requirements | Scope expands late | Separate phase-one needs from future improvements |
| No baseline measures | Value is hard to prove | Record today’s close time, error rate, admin effort or stock accuracy |
This is not bureaucracy. It is how leaders protect the business case.
A Business Central implementation should be judged against business change, not only system availability. Did the close become faster? Are stock figures trusted? Are fewer people rekeying data? Can leaders see the numbers they need without chasing spreadsheets? Are teams using the system as designed?
Those questions make the project more useful because they connect configuration to value. They also make trade-offs easier. A requested customisation may sound reasonable until it is tested against the agreed outcome. An integration may look attractive until the business sees that the data feeding it is not ready. A phased rollout may feel slower, but safer, if ownership and adoption need time to mature.
Outcome-first planning gives Business Central a clearer job: not to replace the old system, but to improve how the business runs.
Better discovery reduces waste after you buy
A pre-buy discovery conversation is not a delay before a Business Central project. It is the point where leaders reduce the risk of wrong scope, weak ownership, poor data preparation and late change requests. The aim is to confirm what should happen first, what can wait, and what the business must prepare before spend is committed.
This is where buying confidence improves. A demo shows capability. Discovery tests fit.
Before committing to a Business Central implementation, leaders should be clear on six things:
- Process owners: who can make decisions about finance, purchasing, stock, approvals and reporting.
- Data baseline: which records are clean enough to migrate and which need work first.
- Decision rights: who can approve scope, phasing, integrations and trade-offs.
- Internal capacity: which people will support workshops, testing, training and go-live readiness.
- Scope guardrails: what belongs in phase one and what should be parked.
- Adoption risk: which teams need early involvement because their habits will change.
These checks protect cost and time because they surface risk before it becomes delivery friction. A business that has not assigned process owners will struggle to make setup decisions. A business with weak data quality will struggle to trust reports. A business with no internal capacity will slow testing, training and adoption.
Clear diagnosis also helps leaders choose the right delivery shape. Some businesses need a fast-start standard Business Central setup to move away from Excel and disconnected finance tools. Others need deeper analysis because stock, integrations, multi-site working, reporting or legacy processes make the change more complex. A phased rollout may be safer where ownership, data or adoption need time to mature.
FAQs: Business Central readiness
Do we need Business Central or better processes first?
You may need both. The right starting point is to identify whether the pain comes from weak process discipline, poor data, system limits or all three.
What should be checked before a Business Central demo?
Check the core problem, target outcomes, process gaps, data quality, reporting needs, integrations, user groups and phase-one priorities.
How much historical data should be migrated?
Not every business needs full history moved. In many cases, cleaner opening balances and selected reference data are safer than carrying years of untidy records into a new system.
Who should own ERP discovery?
Ownership should sit with business leaders, not IT alone. Finance, operations, commercial teams and senior decision-makers all need a voice because ERP changes how work is done.
When is a phased rollout safer?
A phased rollout is often safer when the business has complex processes, uncertain scope, data quality issues, limited internal capacity or several teams needing training.
The useful next step is not always another product demonstration. For many leadership teams, it is a Business Central discovery workshop or scoping review that tests process, data, scope and readiness before the project is shaped.
That gives the business a clearer decision: what to fix, what to buy, what to prepare, and how to move with less risk.
