Loading...
Menu
Loading...
Two to four weeks, fixed price, ending in a ranked list of what to build and what to leave alone. The findings are yours whether or not you continue with us.
Readiness assessments have a bad reputation, and mostly they have earned it. A questionnaire produces a maturity score, the score produces a slide, and nobody can act on either. If the output does not name a specific process and a specific first build, it was an expensive way to feel diligent.
So this one is built backwards from the decision. We look at how work is actually done, where information gets copied between systems by hand, what the data really looks like rather than what the schema claims, and which constraints are real. Then we rank candidates by effort against expected gain.
The other half is measurement. For the top candidates we record how long the work takes today, before anything is built. Without that number, any improvement claimed later is an assertion, and everybody in the room knows it.
What gets examined
Where human time goes, which tasks are repetitive and rule-heavy, and where people compensate for systems that do not talk to each other.
What exists, where it lives, how clean it really is, and which integrations are available versus which would have to be built.
Regulatory and contractual limits on where data can go, including GDPR obligations where you serve European customers, and what that rules in or out.
Who would own a new system, who has to change how they work, and whether that change has a realistic path. This is where most stalled projects actually failed.
A ranked list of candidate processes, each with an estimated effort, an expected gain, and the obstacles we found. Written plainly, and specific enough that another vendor could execute it.
A measured baseline for the top candidates, so whatever is built next can be compared against a real starting number rather than a remembered one.
A recommended first build, chosen for payback speed rather than ambition. Proving the approach on something small buys the credibility to attempt something larger.
A short review of where your data, systems and processes actually stand, ending in a ranked list of what is worth building and what is not. The useful version is specific to your operations. A generic maturity score out of five tells you nothing you can act on.
Two to four weeks depending on how many systems are in scope, at a fixed amount agreed before we start. It is deliberately priced so that stopping afterwards is a reasonable outcome rather than a loss.
A ranked list of candidate processes with an estimated effort and expected gain for each, a measured baseline for the top candidates, the data and integration obstacles we found, and a recommended first build. It is written to be handed to another vendor if you prefer.
No, and waiting for clean data is one of the more common ways companies spend two years not starting. Part of the assessment is finding out which processes can proceed on the data as it is, which is usually more of them than expected.
The assessment decides what to build. A proof of concept tests whether one specific thing works on your real data, usually over two to three weeks. Doing them in that order is cheaper than the reverse, because a proof of concept on the wrong process still fails even when the technology works.
Yes, and it happens. A meaningful share of what people bring us is an integration problem, a reporting problem, or a process that should be removed rather than automated. That finding is part of what the assessment is for.
If the answer turns out to be nothing yet, that is a useful result and considerably cheaper than discovering it in month six.
Request an assessment