SAP Business One · Implementation
SAP Business One® implementation, decided before it is configured.
A structured implementation that starts with how your business actually buys, stocks, prices and ships, and ends with a system your team runs every day without us in the room.
We do
- Configuration and development
- Data mapping and load
- Test scripts and issue tracking
- Training delivery
- Cutover plan and go-live support
You do
- Decide how processes should work
- Clean the data we cannot clean for you
- Test with real transactions
- Attend training
- Sign off each phase
Methodology
Nine phases, each with something real at the end of it
No week counts here. A schedule depends on your scope and on how fast your side can decide, and a number published before either is known is a guess. What we can state is the sequence, what you get, and where it usually goes wrong.
We sit with the people who run the operation and learn how orders come in, how stock moves, how prices are decided and how the books close.
- What exists after
- A written picture of the business as it actually works, including the parts nobody documents.
- Who you need
- Owner or GM, operations lead, whoever really controls pricing.
- Where it goes wrong
- Talking only to management. The person who knows how the process works is usually not in that room.
Each process is mapped end to end and marked as keep, change or drop. This is where the arguments happen, which is the point of doing it early.
- What exists after
- Process maps with decisions recorded, and an explicit list of what will change about how you work.
- Who you need
- The people who perform each process, not their managers.
- Where it goes wrong
- Agreeing to keep a workaround that only exists because the old system could not do the thing properly.
How SAP Business One® will be configured, what sits around it, which interfaces carry what, and where data lives. Written down before anything is built.
- What exists after
- An architecture document covering configuration, integrations, custom work and the data model.
- Who you need
- Your IT contact, plus anyone who owns a system that has to connect.
- Where it goes wrong
- Discovering a required integration late, after the shape of everything else is fixed.
The chart of accounts, item and business partner structures, warehouses and bins, price lists, document numbering, approvals and authorisations.
- What exists after
- A configured company you can log into and use, on your own structures rather than a demo.
- Who you need
- Finance for the chart of accounts, operations for the rest.
- Where it goes wrong
- Configuring around today's org chart instead of the process, so it breaks the first time someone changes role.
Anything configuration cannot cover: integrations, custom reports, add-ons, and any of our applications you are taking.
- What exists after
- Working software against the supported interfaces, with the integration monitoring in place.
- Who you need
- Usually nobody full time, but somebody available for questions.
- Where it goes wrong
- Building to a spec written before anyone had used the configured system.
Business partners, items, price lists, open documents and opening balances, cleaned, mapped and loaded. Usually more than once.
- What exists after
- Your data in the new system, reconciled against the source and signed off by your team.
- Who you need
- Finance for balances, operations for item and customer data. Real hours, not spare hours.
- Where it goes wrong
- Migrating a mess. Bad data in the old system becomes bad data in the new one, only faster.
Your people run your transactions against your migrated data. Not a scripted demo, the awkward orders you actually get.
- What exists after
- A tested system with issues logged, fixed and retested, and a list of what is deliberately out of scope.
- Who you need
- Everyone who will use the system daily.
- Where it goes wrong
- Testing being squeezed because the business is busy. This is where projects go wrong quietly.
Role-based training on the configured system, a rehearsed cutover, then the switch, with us present for the first days of live trading.
- What exists after
- A live system and people who can use it without a manual open beside them.
- Who you need
- All users, plus a decision maker available during cutover week.
- Where it goes wrong
- Training on a generic system rather than yours, so day one is the first time anyone sees the real screens.
The first month-end is the real test. After that, reporting, small improvements and the things everyone parked during the project.
- What exists after
- A closed first period, a support arrangement, and a list of improvements with owners.
- Who you need
- Finance for month-end, then whoever owns continuous improvement.
- Where it goes wrong
- Treating go-live as the end. The improvements parked during the project are usually the ones people wanted most.
Scope
What an implementation covers, and what is quoted separately
Itemising this is what stops a project turning into an argument about whether something was included.
In an implementation
- Chart of accounts and financial setup
- Business partners, items and price lists
- Warehouses, bins and inventory policies
- Sales and purchasing document flow
- Approvals and user authorisations
- Print layouts and the reports people use
- Data migration with reconciliation
- Role-based training and go-live support
Quoted separately
- Integrations to systems outside SAP Business One
- Custom add-ons and applications
- Hosting and the managed environment
- Ongoing support after the first period close
Separate does not mean later. They are usually scoped at the same time and delivered alongside, they are just priced as their own line.
Rescues
If you already have SAP Business One and it is not working
A meaningful share of the work we take on is somebody else's implementation. It is a different engagement and we scope it differently.
- 01
Assessment first
A week or so establishing what is configured, what is customised, what is undocumented and what is actually wrong. No proposal before that.
- 02
Separate the symptoms
Bad configuration, bad data and bad process feel identical to the people suffering them, and need completely different fixes.
- 03
Fix in order of pain
Whatever is stopping people working today, then the structural problems, rather than a rebuild nobody can absorb.
- 04
Then decide about the rest
Sometimes the answer is a reimplementation. More often it is not, and we will say which.
After go-live
What usually comes next
Most implementations are the first phase. These are the ones that follow.
- CoreSAP Business OneThe system of record everything else reads from and writes to.Overview
- Layer 01B2B eCommerceCustomers who order themselvesA portal with their pricing, live stock and account history. Orders arrive as SAP Business One sales documents.See it
- Layer 02Sales Rep AppCustomers who need a visitReps carry pricing and stock on the route, work with no signal, and sync orders when they reconnect.See it
- Layer 03Inventory CountingMaking the stock figure trueBarcode counts and cycle counts, with variances reviewed before anything posts to the ledger.See it
- Layer 04Price Label PrintingThe shelf edgeLabels generated from the same item and price data, so what is on the shelf matches the invoice.See it
Questions
About implementation
Next step
Talk through your SAP Business One project with someone who will actually work on it.
A short conversation about where you are today, what is not working and whether SAP Business One and our team are the right fit. No slide deck.