Case Studies
Three problems, described without the specifics.
Everything below is anonymised. No client or employer is named, no client data appears here, and the details that would identify an organisation — industry, size, location, systems by name, item numbers and dollar figures — have been removed rather than disguised. What is left is the part that transfers — the problem as it presented, what it actually turned out to be, and what was built. Where a number would matter, it is called out as something to measure rather than asserted.
Why there are no percentages on this page. Consulting case studies tend to open with a figure — 82% faster, 40% fewer errors. Those numbers are only worth anything if someone measured the before state, and in most operational work nobody did, because the before state was nobody's job to instrument. Where a baseline was captured, it is named. Where it was not, saying so is more useful than a number nobody can reproduce. When a figure on this site turns out to be wrong, or to have been stood beside things it does not belong with, it is written up in the corrections log rather than quietly edited away.
A KPI console for people who were reading the operation from memory
Two audiences, two trust levels. Cost-bearing reports are refused to floor displays at the report-definition layer, not the render layer.
The report that worked on Today and timed out on Month
Fast on Today, dead on Month-to-date. The most consistently misdiagnosed complaint in ERP reporting.
One label service instead of a label program per label
A program per label became one configuration-driven service. New labels stopped being deployments.
The pattern across all three
None of these started as the problem they turned out to be. “We need a dashboard” was really a question about which rows count as evidence. “The dashboard is slow” was one missing index on a vendor table. “We need another label program” was the absence of anywhere to define a label source.
That is the common shape of operational software work: the request describes the symptom accurately and the cause not at all, and the useful first move is always to reproduce the symptom against the actual data before agreeing to build anything.
Related
- All insights — articles and case studies in one place.
- Operations modernization — the larger engagement these sit inside: consolidate onto one system of record, then optimize on top of it.
- CRM & ERP integration — the integration and pipeline work that feeds reporting like this.
- How the analysis actually gets done — the working method behind these engagements.
- Why your ERP report times out on month-to-date — the technical write-up of Case 02.
- Technology for distributors — the shape of operation all three of these ran inside.
Recognise any of these?
If a report is slow on longer date ranges, or a number nobody trusts is driving a decision, the first conversation is short and costs nothing.