Key takeaways
- A reporting rollout built around today's requirements starts falling behind as soon as the business changes direction and new operating questions appear.
- For multi-location retail and HoReCa, stale reporting creates a patchwork of one-off spreadsheets and erodes the comparable view that makes a network manageable.
- An adaptable reporting layer lets each new question become a conversation instead of another scoped, budgeted, and delayed build cycle.
A retail chain or restaurant group used to be able to plan a technology rollout the way it planned a store renovation. Pick a system, implement it over six months to a year, run it largely unchanged for the next three to five. That timeline made sense when the business itself changed at roughly the same pace.
It doesn't anymore. A network that used to revisit strategy once a year now finds itself changing course within a quarter, sometimes within weeks, because a supplier relationship shifted, a channel opened or closed, or a competitor's move forced a reaction nobody had time to plan for a year in advance. The businesses I've worked with have all been getting faster at needing to change. Very few of their reporting systems have kept up.
What "digitalization" usually means, and why it stops there
Most reporting and BI rollouts I've seen follow the same shape. Someone specifies the reports the business needs today, a system gets built or configured to produce exactly those reports, and the project is declared done. For a year or two, it works well. Then the business pivots, and the reports that were carefully built to answer last year's questions quietly stop being the reports anyone needs.
At that point, updating the reporting stack becomes its own project. Someone has to scope new requirements, get budget, wait for a build cycle, and by the time the new reports ship, the business may have already moved again. This tracks with a well-known idea in strategic management. Teece, Pisano, and Shuen's dynamic capabilities theory argues that competitive advantage rarely comes from having once made the right call or built the perfect plan. It comes from continuously sensing changes and opportunities, understanding what they mean for the business, and adapting fast enough to use them (Teece, Pisano & Shuen, 1997). A boss of mine, who also got me into the habit of playing sports, used to call this keeping the periscope up. Most reporting stacks are built as if that kind of ongoing sensing ends the day the project closes.
Why this specifically hurts multi-location retail and HoReCa
A single-location business can sometimes work around a stale reporting stack with a spreadsheet and a manager who knows the store well. A network of ten, thirty, or a hundred locations doesn't have that option. Every pivot, a new format, a new delivery channel, a change in category mix, a new region, needs to be visible consistently across every location almost immediately, or leadership loses the one thing that made the network manageable in the first place: a comparable view across sites.
When the reporting stack can't keep pace, what usually happens isn't a dramatic failure. It's a slow drift. Leadership starts asking questions the current reports can't answer, someone builds a one-off spreadsheet to cover the gap, that spreadsheet becomes the unofficial source of truth for one particular question, and within a year the company is quietly running on a patchwork of workarounds nobody planned and nobody fully trusts.
A reporting layer that doesn't need to be re-specified every time the business changes course is a different kind of system to build.
A different way to build the reporting layer
Trying to anticipate every future question with a bigger, more comprehensive rollout doesn't work, since nobody can specify a business's questions three pivots in advance. A reporting layer that doesn't need to be re-specified every time the business changes course works better, and that's a different kind of system to build.
This is the practical reason marql is built around a question rather than a fixed set of reports. A retail chain, restaurant group, or franchise network keeps its existing systems exactly as they are, POS, accounting, inventory, connected read-only, hosted in the EU. When the business pivots and a new question shows up, whether that's a new channel's early performance or a category shift's effect on stock, it's a new conversation, not a new build cycle. Nobody has to file a request for a report that doesn't exist yet.
We're not claiming this makes an organization agile on its own. A reporting layer is one part of a larger picture that includes people, process, and decision rights, and no product changes that by itself. What we can say plainly is narrower: a qualified stack review, a first live view within 24 hours, and pricing starting from EUR 200 a month, aimed specifically at removing the lag between a business pivot and a reporting stack that can answer questions about it.
The question worth asking before the next pivot
Most companies find out their reporting stack is behind the business at the worst possible moment, mid-pivot, when leadership needs an answer the current reports were never built to give. It's worth checking earlier than that. When your business last changed direction, how long did it take before your reporting could see the new picture clearly?
See it on your own data
Bring one operating question from your next likely pivot to a reporting-stack review, and we'll show you what it looks like when the reporting layer doesn't need its own project every time the business does.
Talk to your business. Ask. Understand. Act.
Written by
Evan Kazakov
Founder, marql