Our Approach

Build us a report finance and operations can both work from.

Two departments, two defensible methods, one figure that has never matched. No report settles that.

What stops reconciling the day we switch the old system off?

The platform move was well understood. The forty things quietly reading from it were not.

Twelve views existed and four were opened. The rest reported categories rather than the work somebody picks up.

Not a requirements workshop. We attend the meetings where the argument already happens and record who says what. Most organisations have diagnosed themselves already, in fragments held by people who do not speak to one another.

One order, one claim, one deal, one close. End to end, without shortcuts. The gap between the documented process and the real one is where the problem almost always lives, and it does not appear in any extract.

One sentence, no conjunctions. If it cannot be written that way it has not been understood yet. This is the deliverable clients remember, and it is regularly uncomfortable to read.

Step by step, with what each one is for. Often less than was requested. Sometimes no build at all, because the question can be answered without one. Occasionally nothing, because the answer is a decision that has been avoided and no system substitutes for making it.

Built small and tied to decisions somebody makes on a schedule, then maintained rather than handed over and abandoned.

Several systems reconciled into one place that returns the same answer to everybody who asks the same question.

Dependency mapped first, rehearsed at real volume, with reporting repointed on the day rather than discovered missing after it.

The contested terms written down, applied once, with the lineage behind them in a form somebody outside can read.

Configured around how a team actually sells, with reporting live from the first day and training in their language.

Analysis and modern capability inside boundaries where nothing is permitted to leave, with governance written alongside the build.

Answers grounded in your own documents with a citation somebody can check, and a written rule for what the system refuses to answer and who it escalates to instead.

Repetitive processing, extraction and multi-step handoffs, designed around the exception queue rather than the happy path, with an audit trail per item.

Whether the data can support the idea at all, established on your own records in weeks rather than discovered six months into a build. Frequently ends in a recommendation not to proceed.

If you already know it is a dashboard, the outcome has been decided and we would only be renting you hands. Plenty of firms will do that well and for less.

Being engaged to produce the conclusion the sponsor arrived with is a real request, politely made, and not one we take.

An answer without an owner changes nothing, and we would rather not be paid to demonstrate that again.

There is no pyramid here to feed, which is the point, and it means some engagements are simply too large for us.

An assistant over four definitions of revenue answers the same question four ways, faster, and with the provenance stripped off. We will do the definitions first or we will not do it.

If the invoices arrive in nineteen formats because nobody has ever asked the suppliers to change, automating that makes the fault permanent and harder to see. The finding is unwelcome and worth more than the build.

Content goes stale, upstream systems change, accuracy decays quietly. Without an owner and a budget line for year two, we would be building something with a timer on it.

Every Thinklytics engagement has one written question. The first movement finds it and is priced separately. The second answers it, and usually that means building something.

One written question, found before anything is scoped, then answered. Two movements, priced separately.

The first movement finds that question and is priced separately. The second answers it, and usually that means building something, because that is what this practice has always done. What is new is that nothing is scoped before anyone knows what is being asked.

Each of these was a real request, and each would have been delivered on time exactly as written.

The roadmap is assembled for the question rather than taken off a shelf, so no two have matched yet. Length is set by what the question turns out to need, which is why these show the shape of the work and not a schedule.

The build is chosen by the question rather than assumed before it, and it is usually where most of the work sits.

Both roadmaps end in something real. One produces an automated reconciliation, the other a reproducible figure and the lineage behind it. Neither ends in a document nobody acts on.

Everything below is work this practice has done for seven years and still does.

Which of these an engagement produces is decided by the question, and most produce more than one.

Nearly every capability arriving now can be bought finished, assembled on somebody else's platform, or built. The question is asked as build versus buy, which omits the option most organisations belong in.

Which one an engagement lands on is decided in the first movement, in writing, with the reason recorded.

Right when the process really is standard, which is more often than people like to admit. Fast and cheapest to start, and you accept someone else's definitions and workflow. The cost shows up later, when your exception turns out not to be an exception the product has.

Your definitions, your workflow, infrastructure somebody else maintains. Most sensible work sits here and it is underrepresented in vendor material, because it is less profitable to sell than either of the alternatives.

Justified when the capability is the differentiator, when the process is the advantage and no product fits it, or when the data cannot leave your boundary at all. Building because a platform did not quite fit is how organisations acquire software they have to staff forever.

The failure is not choosing wrong. It is choosing without writing down which one was chosen and why, so that in eighteen months nobody can say whether the thing being maintained was ever meant to be.

Arrives, diagnoses well, produces a document, leaves. You are then holding a correct answer and no way to act on it, and the second firm you hire has to be told everything again from the beginning.

Arrives, builds it properly, invoices, leaves. Nobody in the room was ever paid to ask whether the thing being built was the right thing, so nobody did.

Nothing is lost being explained to a second firm, and nothing gets built before somebody has been accountable for asking whether it should be. We have always done the building. What is new is refusing to start there, and that combination is only available from a practice small enough that the same people stay on the work.

Finished means the question is answered and the answer will still hold next quarter.

Not that something was handed over. A dashboard can be delivered, accepted and invoiced while the question that prompted it stays exactly as open as it was, and both sides can call that a success. Under this arrangement neither of us can.

Whether the close actually gets faster depends on decisions your people make after we go, and we will not pretend to control that. What we are accountable for is that the answer is correct, that it is reproducible, and that it does not quietly rot the first time somebody renames a field.

Where the answer involves a model, finished additionally means it can be checked and it can be monitored.

That the output cites the source it came from, that an evaluation set exists and is held by you, that somebody is named to keep the underlying content current, and that the year-two running cost was written down before anything was built. A system nobody can audit and nobody maintains is not finished, however well it performs the week it ships.

The question is written down early and does not move after that.

If it turns out to be the wrong question, that is a finding worth having, and we reopen it in front of you rather than adjusting it quietly to match what we found.

Enough to establish whether there is work here, whether it is ours, or whether you should be speaking to somebody else entirely.