How to choose a SAP Business One partner or consulting firm

Why the choice of firm is the most critical decision

SAP Business One is the same product whichever firm implements it. What differs is how that product is fitted to your processes: which flows are solved with the standard behaviour, which ones need configuration or development, how your data is migrated, how users are trained, and who looks after the system once you are live. In other words, you are choosing a team, not a product.

Thin analysis, undefined scope, unplanned data migration, insufficient testing and an undefined post-go-live support arrangement all raise the risk on an ERP project. Every one of those items can be asked about before a contract is signed and written into the quotation.

The sections below set out what to look for and what to ask on each topic. Taking these questions into a meeting clarifies the scope of a quotation from the first conversation.

How to probe real SAP Business One project experience

"We do SAP Business One" carries no information on its own. What matters is how many projects of your size and process complexity the firm has taken from start to finish, and what role it played in them. A firm may have handled only the installation on a project, or it may have run everything from analysis to post-go-live support.

Industry experience helps, but process experience decides. A team that has already worked with manufacturing, multi-warehouse distribution, import costing, service and call management or multi-branch retail will understand your problems without needing you to explain them from first principles.

In the meeting, ask for the anatomy of a specific project rather than a general reference story: scope, duration, team, the difficulty that came up and how it was resolved. Specific project examples help you understand how the team works on processes like yours.

• How many SAP Business One projects have you completed at our scale and process complexity?
• In those projects, which phases did you run yourselves, from analysis through to go-live?
• In the project closest to ours: what was the scope, how long did it take, how many users?
• What unexpected difficulty came up there, and how was it resolved?
• Have you ever taken over a project started by another firm? What did that involve?
• How many projects are you running right now, and where does ours fit in your schedule?

The capability of the team that will actually work on your project

The person preparing the quotation is often not the person you will work with. So the composition of the team assigned to you matters as much as the firm's total headcount: how many consultants, in which specialisations, for how much of their time?

A healthy SAP Business One project usually involves several profiles: a functional consultant who models the business processes, a finance consultant who knows local accounting and statutory requirements, a technical team for development and integrations, a systems specialist for installation and the database layer, and a project manager who plans all of it. On smaller projects these roles merge. What matters is that it is clear from the start who covers each one.

Ask about continuity as well. If a consultant leaves mid-project, how is the knowledge handed over? Is there a backup for holidays, illness or resignation? A project that depends on one individual is fragile, however good that individual is.

• Who exactly will work with us? Can you list them by name and role?
• Can we meet those people and hold a short technical discussion before signing?
• Are the functional, finance, technical and project management roles separate or combined?
• If a consultant leaves, how is the handover handled and is there a backup profile?
• How much time per week will the team dedicate to our project?
• Who will be responsible for statutory and localisation topics (e-invoicing, e-ledger and so on)?

The quality of requirements analysis: the earliest clear signal

The earliest way to judge a firm is to watch how it asks questions. Where a quotation is prepared without seeing the processes, there is a greater chance that some requirements fall outside the scope. An approach that listens and maps your current flows, document types, approval points, exceptions and reporting expectations starts the project on realistic ground.

Good analysis is not about copying your current way of working into software. It is about separating what the standard SAP Business One flow already solves, what genuinely needs adaptation, and what turns out to be unnecessary. "We can build whatever you want" sounds like flexibility; in practice it often means uncontrolled customisation and painful upgrades later.

Insist that the analysis produces a written output. Without a scope document, every later request turns into an argument about whether it was included. A document that also states what is out of scope protects both sides.

• Is the analysis phase included in the quotation or charged separately? How long does it take?
• What document is delivered at the end of analysis? Can we see an anonymised example?
• Will the scope document also list out-of-scope items explicitly?
• How will you distinguish processes solved by standard behaviour from those needing adaptation?
• Who from our side needs to take part in the analysis, and how much time should they allow?
• If the scope changes after analysis, how are the quotation and timeline updated?

Project methodology, planning and communication discipline

Methodology defines the phases the project will go through, the output of each phase and the responsibilities of both sides. Whatever it is called, a sound structure covers the same skeleton: analysis and design, installation and configuration, data migration, development and integration, testing and UAT, training, go-live and post-go-live stabilisation.

The realism of a plan shows in its dependencies more than in its dates. A good plan states what is expected from you as well: data cleansing, decision-makers' time, participation in testing. Plans that show only consultant effort leave the responsibility for delays undefined.

Communication rhythm is part of the methodology too: a weekly status meeting, an open-items list, a decision log and one accountable contact on each side. These look like bureaucracy, but they are the cheapest available protection against scope creep and "who said what" disputes.

• Are the project phases, deliverables and approval gates defined in writing?
• Does the schedule include the tasks and effort expected from our side?
• How will weekly reporting and open-item tracking work?
• Through which process are change requests assessed and priced?
• Who will be the project manager, and in which forum are decisions taken?
• What is the early-warning mechanism when a delay risk appears?

User and license planning: an analysis task, not a purchase

SAP Business One is licensed per named user, meaning a license belongs to each individual who will access the system. Some users need full access to the whole system, while people who only work within a single functional area can be covered by more restricted and more economical license types.

A capable partner analyses the license mix before quoting: who works on which screens, who approves, who only enters data. Proposing full-access licenses for everyone creates unnecessary cost; squeezing everyone into limited licenses leaves people unable to do their jobs and produces mid-project upgrade surprises.

License planning also has a time dimension. Buying licenses on day one for users who only join in a later phase pulls an unused investment forward. Ask to see how user numbers are expected to grow across phases in the quotation itself.

• What analysis is your proposed license mix based on? Can we see the user-role table?
• Which users will have full access, which will use limited licenses, and why?
• How many users go live in phase one, and how many are added in later phases?
• How can a license type be upgraded later, and under what conditions?
• Is the annual maintenance or subscription fee shown as a separate line in the quotation?
• Are additional licenses or environments needed for test and development?

The approach to data migration: the most underestimated item

Data migration is the most underestimated topic in ERP projects and the most frequent source of delay. Business partners, item master data, bills of materials, open orders, open invoices, stock balances and opening accounting balances arrive from different sources in different states. What gets migrated matters, but so does who is responsible for cleaning it.

A sound approach puts the migration list, source systems, transformation rules and the responsibility boundary in writing: which cleansing is done by you, which by the consultants. Trial loads are run, the results are verified through reconciliation, and at least one full rehearsal takes place before the live migration.

Decide early how far back you will go. Migrating every transaction from years past is usually unnecessary cost; open balances, open documents and a defined minimum of history are typically enough. Planning read-only access to the legacy system for a period removes most of the remaining argument.

• Which data will be migrated and which will not? Is the list written down?
• Where is the responsibility boundary for data cleansing? What is ours to do?
• How many trial loads are planned, and how will results be verified through reconciliation?
• Who checks the opening balances, as of which date, and how?
• How far back will historical transactions be migrated, and how will we access the rest?
• If a migration goes wrong, what is the rollback plan?

Integration capability: how will your systems talk to each other?

In most companies SAP Business One does not run alone; it exchanges data with e-invoicing infrastructure, bank statements, e-commerce platforms, warehouse and field applications, CRM or production data collection systems. Each of those connections is a separate piece of analysis, development, testing and monitoring.

When assessing integration capability, "how do you build it?" is far more revealing than "can you build it?". Which interfaces are used, in which direction and how often does data flow, where do failures get logged, is there a retry mechanism, and who watches it? An integration that quietly stops is often noticed days later.

The responsibility for the other system must be clear too. Who coordinates with your e-commerce or banking provider, and who bears the cost if that provider changes its interface? If the contract is silent on this, you end up caught between two vendors when something breaks.

• Have you built something similar for every item on our integration list?
• How will each integration be built, and at what frequency will data flow?
• How do alerting and retry work on failure, and who monitors it?
• Who coordinates with the provider of the other system?
• If that provider changes its interface, how are the scope and cost of the update determined?
• With what data and in which environment will the integrations be tested?

Custom development capability and reporting

Every business has a few processes that do not fit the standard flow exactly. The real question is not whether the firm can develop, but how it decides when development is warranted. Proposing custom code for a need the standard system already covers creates both cost and a maintenance burden at every future upgrade.

Where development is justified, discuss the method and the ownership: will it use SAP Business One's supported extension mechanisms, will the source code and documentation be handed over to you, and who ensures compatibility during version upgrades? The answers to those three questions directly affect your ability to work with a different firm later.

On reporting, set expectations early. Standard reports cover many needs, but the specific reports, dashboards and KPIs management wants to see regularly are a separate effort item. Seeing in writing which reports are in scope and which belong to a later phase prevents disappointment right after go-live.

• Which needs are met by standard behaviour and which by development? Are the reasons documented?
• How will developments be built, and how will they survive version upgrades?
• Who owns the source code, documentation and usage rights of the developments?
• What is the list of reports included in the project scope? How many custom reports?
• Is a management dashboard in scope, or priced separately?
• At what unit rates will later report and development requests be handled?

How testing and user acceptance (UAT) should be planned

Testing is the easiest phase to sacrifice and the most expensive one to skip. When the schedule tightens, testing is usually the first thing cut, and the bill arrives as defects discovered after go-live.

In a sound setup, tests are scenario-based: quote to order to delivery to invoice, purchasing and goods receipt, production order and costing, stock counting, month-end close; end-to-end flows run with realistic data. Crucially, these tests should be executed by the people who do the work, not by the consultants. That is what user acceptance testing means.

Acceptance criteria should be written down as well: which scenarios must pass for a phase to be accepted, and with what priority and within what timeframe defects are fixed. "Let's go live and look at the rest later" is the most common way open items become permanent.

• Who writes the test scenarios, and how many end-to-end flows will be tested?
• Who from our side takes part in UAT, and how much time should they set aside?
• Will a test environment be set up separately from live, and with which data?
• How are defects prioritised, and within what timeframe are they fixed?
• Which criteria must be met for a phase to count as accepted?
• Under what conditions would the go-live decision be postponed?

Training and go-live

A system becomes real on the day people start using it, which is why training is a planned phase rather than a formality squeezed into the final week. Effective training is role-based: the buyer works through their own screens, the warehouse supervisor through their own transactions, finance through their own closing routine.

The key-user model works well in practice: one or two people from each department are trained in depth, learn the system and become the first point of contact for their own team. Freeing up those people's time is one of the most valuable contributions the business side can make.

Go-live is an operation whose timing should follow your business rhythm: the start of a period, just after a stock count, outside peak season. The cutover plan should state in writing how opening balances are entered, the cut-off date, when the legacy system is switched off, who is at which desk on the day, and what the fallback is if something goes wrong.

• Is training role-based? How many sessions and hours are planned?
• Will training materials and user guides be delivered?
• Will a key-user model be used, and who should be selected?
• Which criteria will determine the go-live date?
• What level of support is provided on cutover day and during the first week, and with how many people?
• Is support for the first month-end close included?

Post-go-live support and the approach to SLAs

A project does not end at go-live; real usage starts there. The support model therefore needs to be settled at contract stage. Most firms offer two shapes: a monthly or annual support agreement, or per-incident support. For a business running critical processes on its ERP, a predictable agreement usually costs less than unplanned downtime.

When discussing an SLA, do not confuse two different measures: first response time and resolution time. A serious quotation defines separate response targets by severity (production-stopping, work-blocking, low impact) and states the support channels, working hours and what is covered outside them.

The boundaries of support should be explicit too: are user questions, defect fixes and small configuration changes included, and how are new reports, new developments and new modules priced? Support agreements without a defined boundary turn into arguments in practice.

• What does the support agreement cover, and what does it explicitly exclude?
• Are first response and resolution targets defined by severity, in writing?
• What are the support channels, working hours and out-of-hours coverage?
• Are requests logged and trackable? Is there monthly reporting?
• At what unit rates is work outside the agreement carried out?
• Will the team that knows our project also be the team handling support?

How to evaluate references

A list of logos is not information; how those projects went is. When you evaluate a reference, ask what role the firm played and what stage the project reached: did it run everything from analysis to go-live, or did it join later?

Ask for a reference call where possible. This is a normal request in the market, and serious firms will arrange it with their customer's consent. In the call, ask about process rather than satisfaction: did the schedule hold, where did they struggle, how did the firm behave when problems appeared, and how is support working for them today?

How similar the reference is to you matters as well. A reference that is far larger or has a completely different process structure tells you little about your own project. Accept, too, that some customers cannot be shared for confidentiality reasons; that alone is not a bad sign, but being unable to arrange any reference conversation at all deserves scrutiny.

• Can we speak with a reference of similar size and process complexity?
• What was your role in that project, and which phases did you run?
• Was the project completed on the planned schedule? If not, why?
• Who provides support to that customer today?
• Have you had a project that was halted or handed over? What was the reason?
• Can you arrange a site visit or an online reference call?

Documentation, sustainability and dependency risk

An ERP is a decade-long investment, not a two-year one. That makes "what do we hold at the end of the project?" as important as the price question. What you should hold: the scope and design document, configuration records, the data migration map, development documentation and source code, integration interface definitions, user guides and system access credentials.

Vendor lock-in usually grows out of neglect rather than bad intent: undocumented customisations, settings only one consultant knows about, developments whose source code was never handed over. A year later, moving to another firm may remain technically possible but become expensive in practice.

The way to prevent this is to put the deliverables list into the contract. Also grow at least one person on your own side who knows the system: an internal resource trained in administrator rights, backups and user management speeds up day-to-day work and reduces dependency at the same time.

• Which documents will be delivered at the end of the project? Is the list in the contract?
• Will the source code and technical documentation of developments be handed over to us?
• Who will hold the system, server and database access credentials?
• Who runs backup and recovery procedures, and how often?
• Do you provide training so we can grow an internal system administrator?
• How are version upgrades planned, and who tests the compatibility of customisations?

Do not look at price alone: how to compare quotations

Quotations from different firms rarely cover the same work, which makes side-by-side numbers misleading. One may include analysis, data migration, training and go-live support while another covers only installation and basic configuration. Normalise the scopes before you compare the totals.

A low quotation is not automatically a bad one; it may simply be narrow. The dangerous case is a low quotation with an undefined scope: a budget that grows mid-project under "that was out of scope" quickly overtakes the initial saving. Equally, a high quotation is not automatically better; ask what justifies the difference.

A fair comparison is made over a three-to-five-year total cost of ownership rather than the first invoice: licensing or subscription, annual maintenance, infrastructure, project services, training, support and version upgrades. Against that, put the time and error reduction the project should produce in your operation, using your own numbers.

Finally, read the contract as an extension of the quotation. Scope, deliverables, timeline, a payment plan tied to phase acceptance, acceptance criteria, treatment of delays, support terms, confidentiality and data protection, and intellectual property should all be in writing. A good partner is comfortable discussing every one of those clauses.

• Do the quotations cover the same scope? Have you listed the differences item by item?
• Are analysis, data migration, training and go-live support included in the price?
• Are out-of-scope items and the unit rates for later requests written down?
• Is the payment plan tied to phase deliverables and acceptance criteria?
• Are annual maintenance, support and infrastructure shown as separate lines?
• Have you calculated a three-to-five-year total cost for each quotation separately?

What NFKSOFT does on these points

Every heading above is an area we work on in a SAP Business One project. Requirements analysis is the first step, and the scope and phases are put in writing. Data migration is planned as a separate workstream, with the decision on what moves and what stays archived taken at the start.

Integration, custom development and reporting are built by our own team. For e-commerce, banking, shipping and field applications we work through SAP Business One's service interfaces. After go-live, support continues with the same team.

We also take over systems implemented by another firm: a short assessment maps the current setup, the developments on it and the risk areas, and the scope is agreed together.

Frequently Asked Questions