Know what your company needs before anything is chosen or built
A business analysis maps your processes, users, integrations and exceptions and translates them into a specification document vendors and developers can quote against on comparable terms.
- No vendor lock-in · No commissions
- Mutual NDA before every conversation
- Reply within 1 business day
Analysis first, choosing or building second
Most software projects do not run aground on technology but on what nobody articulated upfront. The process that looks simple on paper but carries five exceptions in practice, the link with that one legacy system the whole schedule depends on, the department quietly working from its own Excel sheets.
A business analysis brings all of that to the surface before you sign a contract or put a developer to work, so you decide based on how your company actually operates instead of on an assumption.
The result is not a thick report that disappears into a drawer but a specification document you can act on straight away: process maps, prioritised requirements, an integration map and acceptance criteria.
With it you request vendor quotes you can genuinely compare, or you brief a development partner without noise. A typical analysis runs over four to eight weeks and we carry it out as an independent party: we sell no software, receive no commissions and implement nothing ourselves.
Three situations where a business analysis makes the difference
Your current software no longer fits
Your organisation grows, processes change or employees get stuck. A business analysis maps the needs and determines what a new system really has to be able to do.
You want to purchase new or custom software
You have an idea, but the scope and requirements are not yet sharp. The analysis translates your needs into clear functionalities, a realistic schedule and a focused budget.
You want to compare vendors and quotes
Every vendor proposes a different solution. With one clear specification document you compare the same scope and avoid surprises, missing functionalities and expensive change requests.
What you get in concrete terms
Process map of the current situation
How the work really runs today, per department and including the exceptions no handbook mentions.
Requirements document with weighting
Functional and non-functional requirements, prioritised so vendors know what is essential and what is desirable.
Integration map
Every system and data flow the new solution has to talk to, with the risks named per connection.
Acceptance criteria
Defined per process step what "working" means, so at delivery you do not depend on your vendor's definition.
Risk analysis and assumptions
The points where the project can slip, named explicitly together with the assumptions estimates are based on.
Decision advice
An honest recommendation: go, no-go or a phase 0 first. Even when that means the project is better off not happening.
Five steps from first call to specification document
Scope call
Together we agree what the project has to deliver, who is involved and which departments and systems the analysis will cover.
Interviews and shop floor
We talk to the people who do the work and watch how processes really run, because the gap between the handbook and daily practice is exactly where projects break later.
Exceptions and integrations
We deliberately hunt for what happens once a month and can still break the entire project: special customers, seasonal peaks, links with legacy systems.
Specification document
Everything comes together in one document: process maps, weighted requirements, integration map, acceptance criteria and the explicit out-of-scope.
Validation and decision advice
We walk through the document with your team, sharpen where needed and close with an honest recommendation: go, no-go or a phase 0 first.
What it delivers for you
Discussions about change requests start with what was never written down. A sharp analysis shrinks that grey zone drastically: vendors quote against the same document, you negotiate on recorded requirements and at delivery you test against acceptance criteria agreed upfront. The conversation with your vendor shifts from "we understood that differently" to "this is what the specification says". That is the difference between a project you steer and a project that steers you.
When it fits and when it does not
A business analysis makes sense when
- ✓ you face a software choice or build project and the scope is not yet fixed
- ✓ you have quotes on the table that cannot be compared with each other
- ✓ your team disagrees internally about what the system exactly has to do
Better not when
- ✕ the contract is already signed and you are only looking for confirmation of that choice
- ✕ it concerns a small tool where an analysis costs more than it returns, in which case we say so in the first call
- ✕ you want a party that starts building right away, because that is deliberately not what we do
Frequently asked questions about business analysis
How long does a business analysis take?
A typical business analysis runs over four to eight weeks, depending on the number of processes, departments and integrations. In the scope call we agree upfront which parts we cover and when the specification document lands on your desk.
What does a business analysis cost?
That depends on the number of processes, departments and integrations we map. Ask for an indication in the scope call: we look at the size of your project together and you know where you stand before we start.
Can the vendor not do the analysis themselves?
They can, but then the party that has to deliver writes its own assignment. A vendor analyses towards their own solution. An independent analysis describes what your company needs, so every vendor quotes against the same document.
What if the analysis shows we should not start?
Then that is the advice. A no-go or a phase 0 is just as valuable an outcome as a go: it saves you a project that would run aground. Because we sell no software and implement nothing, we have no interest whatsoever in a project that should not happen.
Does the analysis also work for custom software and AI projects?
Yes. The method is the same for ERP selection, custom software, AI assistants and 3D configurators: processes and exceptions first, then requirements and acceptance criteria. For each domain we also host a free Readiness Check on the site.
You might also be interested in this
SEMANU is an independent software advisory firm for SMBs: we sell no software and receive no vendor commissions. Read how we work as an independent software advisory firm.