Implementing a business management system rarely stalls because of the technology. More often it stalls because of what wasn't discussed before it started: who is responsible for what, which data is treated as correct, and what a verifiable result will look like. This article covers questions worth answering before you even choose a system or finalize a contract with an implementation partner.
The text is aimed at managers and decision-makers who don't need a detailed technical plan, but a clear understanding of what to expect from the project and what decisions the company itself will need to make.
Start with the process, not the feature list
A feature list is convenient for comparing offers, but it says little about how the system will actually work in your company. It's more useful to answer simpler questions: who submits the information, who approves it, and where it's used next. Once these steps are described, the need for specific features becomes clear, and some of the planned modules may turn out to be unnecessary, at least in the first stage.
In practice, this means that before implementation it's worth describing your users, their actions, the data they use, and the rules by which decisions are made. You don't need a perfect document. It's enough for the team and the implementation partner to have a shared understanding of how the process looks today and how it should look after implementation.
Define scope, responsibilities and exceptions
Most misunderstandings arise not from what was agreed, but from what was left unsaid. That's why the scope should be stated clearly: which processes are included, which are left for a later stage, which integrations with existing systems are needed, and who will prepare the initial data.
Before you start, it's worth having answers to these questions:
- Who on the company's side makes decisions about process changes and has time to devote to them.
- Which information will have a single source of truth, and where it will be stored.
- What access rights different roles need, and who will approve them.
- How the system will behave in exceptional cases: when a document is sent back for correction, when the responsible person is unavailable, when the data doesn't match.
- Under what terms the code, documentation and ongoing maintenance are handed over.
Exceptions deserve particular attention. Systems tend to describe the normal workflow well, but in everyday life it's the non-standard situations that take up the most time. If these are discussed in advance, no rushed decisions will be needed during implementation, and users will know what to do when something doesn't go according to plan.
Prepare the data and the people
A new system can't be tidier than the data migrated into it. Before implementation, it's worth reviewing your customer, supplier, product or employee lists, agreeing on a common structure, and deciding what gets migrated and what stays in the archive. This work often takes longer than planned, so it's better to start early and assign someone responsible for it.
A system is only as organized as the data migrated into it, and as clearly agreed as who is responsible for that data.
Preparing the team matters just as much. Users need to know what's changing in their daily work, when the transition will happen, and who to contact with questions. It's worth planning training by role rather than treating everyone the same: an accounting employee and a warehouse manager care about different aspects of the system, so the training content should differ too.
Agree on how you'll verify the result
It's worth breaking implementation into stages, each with a verifiable result. This way, discrepancies are caught early, and decisions are based on what's already working rather than what was planned.
Verification before launch could include the following steps:
- Testing business logic against real work scenarios, not just reviewing screens.
- Checking access rights: whether each user sees and can only do what they're supposed to.
- Testing how integrations perform, including what happens when an external system is temporarily unresponsive.
- Testing data recovery, so it's clear how information is restored in case of a failure.
- Reviewing the agreed acceptance criteria together with the responsible people at the company.
Acceptance criteria are best agreed at the start, not on launch day. When both sides know in advance what counts as finished work, it's easier to assess both the progress of each stage and the final result.
Implementing a business system is not only a technological decision but an organizational one. A clear scope, defined responsibilities, discussed exceptions and a verifiable result help keep a project manageable from the first meeting through to launch. These questions are worth considering even before you choose a specific solution.