What a Real SAP Business One Implementation Looks Like

What a Real SAP Business One Implementation Looks Like

Most conversations about ERP focus on the software. Which modules you need, what it costs, how it compares to alternatives.

Those are reasonable questions. But they're not the ones that determine whether this works.

The software is largely a known quantity. SAP Business One is a mature, widely deployed system. What varies — enormously — is the implementation. Two companies can buy the same system, and one ends up running their entire operation on it while the other is back in spreadsheets within a year.

So here's what the process actually looks like when it's done properly. There are six phases. The one most people underestimate is the last.

Phase 1: Discovery

Before anything gets configured, we need to understand how your business actually runs.

Not how it's supposed to run. How it actually runs — including the workarounds, the exceptions, and the things people do that aren't written down anywhere.

This means sitting with the people who do the work. How does an order move through your business from first contact to final invoice? Where does information get re-entered? What breaks when someone's on vacation?

This phase is where implementations are won or lost. A system configured against an idealized version of your process will fail the moment it meets the real one.

Phase 2: Configuration

Now the system gets built around what we learned.

Chart of accounts, item master, pricing structures, approval workflows, user roles and permissions. Every one of these is a decision, and every one should trace back to something we observed in discovery.

This is also where we're honest about tradeoffs. Some of how you work today is worth preserving and building around. Some of it is a workaround for a limitation you're about to leave behind, and carrying it forward would just import an old problem into a new system. Those conversations happen here, with you in the room.

Phase 3: Testing

Before anyone's daily work depends on this, we run your actual scenarios through it.

Not generic test cases. Your real ones — including the awkward ones. The rush order that skips a normal approval. The customer with unusual terms. The month-end sequence that has to happen in a specific order.

Things surface here. That's the point. Finding a gap during testing costs you a conversation. Finding it the week after go-live costs considerably more.

Phase 4: Training

Training fails when it's treated as a software demo.

Your team doesn't need a tour of every screen. They need to know how to do their job in the new system — the specific sequence of things they do every day, in the order they do them.

So training is role-based. The person entering orders learns order entry deeply. The person closing the month learns the close. Everyone gets the parts they'll actually use, with time to practice before it counts.

Phase 5: Go-Live

Data migrates, the system goes live, and people start working in it.

This is the visible milestone, and it gets treated as the finish line because it's the part everyone can see. It isn't the finish line. It's the point at which the real questions start — because until people are doing their actual work in a system, they don't know what they don't know.

Phase 6: After Go-Live

This is the phase most implementations skip, and it's the one that determines whether the system sticks.

The first few weeks generate a steady stream of questions. Someone hits a scenario training didn't cover. A report needs adjusting. A workflow that made sense on paper turns out to need a tweak.

If nobody answers those questions, people improvise. They build a spreadsheet to handle the thing the system won't do. And that spreadsheet becomes permanent.

We stay engaged through this period, because that's when engagement matters most. The questions are small. Left unanswered, they compound.

What this means for timing

Everyone asks how long this takes, and the honest answer is that it depends on the complexity of your operations, how clean your existing data is, and how much time your team can give the project.

What we can say is that the phases don't compress well. Skipping discovery to save time usually costs more later. So does thin testing.

A realistic conversation about scope and timing is part of the process, and it should happen before you commit to anything.

Where to start

If you're evaluating SAP Business One, the useful first step isn't a software demo. It's a conversation about how your business runs and whether an ERP is the right answer for where you are right now.

Sometimes it isn't.

We'd rather tell you that early.

If you want to have that conversation, reach out to the SDW Labs team.