Thoughts

By the time the data is ready, the decision has already been made.

A team needs last quarter’s numbers by region. The data exists, split across an accounting export, a sales tracker and another spreadsheet. Forty-five minutes to piece it together, because each source defines “region” slightly differently. By the time there is an answer, the meeting has moved on.

This is the pattern. Data analysis exists in most organisations, but it arrives after decisions rather than before them. As systems multiply, understanding drops. People cope with judgement, habit and workarounds. They are not careless. Their tools, their numbers and their decisions have fallen out of sync.

Excel sits at the centre of most of this work. Not by accident. It is fast, reliable, flexible and close to the work itself.

The costs of structural disorder accumulate in the background: decisions delayed because no one trusts the numbers, staff time spent reconciling data that should already agree, institutional knowledge that walks out the door because it was never made explicit.

These are not technology problems. They are problems of structure and visibility. Most businesses already have the technology they need: Excel, existing systems, basic data. What is missing is the expertise to connect what already exists to how work actually happens. Solutions built for your context, not against it.

Most operational friction in micro, small and mid-sized businesses is caused by poorly structured technology that no one fully understands.

Consider the dashboard someone built last year. Fifteen charts, forty metrics. Consulted on Monday mornings but rarely the basis for decisions. Those still come from conversations, from feel, from experience. That is not the problem. The dashboard failed because it was not built from how decisions are actually made. Good analysis starts with those conversations: what people already pay attention to, what makes them worried, what changes their mind. Then it works backward to what should be measured. A dashboard no one consults is a design problem that begins with the wrong question.

Most everyday problems come from unclear ways of working, slow feedback and tasks that are hard to explain or hand over.

Excel-based, custom-built solutions earn their place because they live inside the work. They make assumptions visible. They make trade-offs easier to see. They can be used, maintained and fixed by the people who depend on them, without the person who built them present.

Data analysis does not remove uncertainty. What it does is help people understand what they actually know, what they are estimating and what would change their mind.

Before adding new software, three things need to be in place: how work actually flows, what assumptions are being made and how decisions were reached. Tools earn their place once those things are clear. They fail when they are expected to do the thinking.

Nothing breaks when I leave. That is the only acceptable outcome.

Most operational problems can be solved internally. Why bring in outside help?

Because most organisations cannot see their own structure clearly enough to fix it.

The people closest to the work know exactly how things get done. They also know why certain reports take two days, why month-end always always feels rushed, why some numbers are trusted and others triple-checked before being shared. That knowledge is real and it matters. But proximity also creates blind spots. The workaround that has been in place for three years no longer reads as a workaround. It reads as how things work

Outside help is not technical expertise imported to replace internal knowledge. It is a second pair of eyes with no stake in the current arrangement, no history with the systems that exist and no reason to preserve the logic that has accumulated by accident rather than by design.

Capability is not the constraint. Visibility is.

If AI can do the work, why do we still need help?

The real question is whether your team has the foundational understanding to use it effectively, or whether they will spend months building well-constructed solutions to the wrong problems.

AI will generate logic, write code and produce analysis at a speed that did not exist before. That leverage is real. But leverage still requires judgement about what to build, and understanding about whether what was built is correct.

Used well, AI genuinely supports processes and operations. Used without foundational understanding, it does not save time. It consumes attention, compounds errors at scale and produces systems that cannot be explained or defended when it matters.

Understanding is not accelerated by AI. It must still be built the slow way.

This approach sounds deliberately constrained. Is that a limitation?

It is a design decision.

Better thinking. Fewer tools. Clearer logic. Full visibility into how the system works and why. That constraint keeps work understandable, controllable and reliable under pressure. It shortens the path from data to decision.

This will not suit every environment. Teams seeking rapid scaling through external platforms, or requiring complex infrastructure, will find it too limited. That is an honest trade-off and not the right fit for every situation.

For teams making decisions under pressure, operating with limited room for error and without the budget for dedicated data operations, that same simplicity is the point.

We have data scattered across spreadsheets, emails and systems. Should we buy new software?

Not yet. Start with one weekly task: a report, an update, a regular decision.

Where does its information come from? How is it checked? Who depends on it?

If those questions can be answered reliably with what already exists, software is not the issue.

We spend hours producing the same report. Is automation worth it?

Check what happens after the report is sent.

If it sits untouched, stop making it. If it informs action, automation is worth building.

We have years of data but do not know what to do with it.

Start with one question: what decision would I make differently if I understood this data better?

If you can name it, which product line to phase out, which customer segment to focus on, then analyse. If you cannot name it, the first task is naming it. Without a clear question, analysis produces volume, not value.

We track many numbers. How do we know which ones matter?

Run the omission test. Stop updating half of them for a month. The numbers people ask for when something feels wrong are the ones that matter.

What should Excel be used for and where does it stop being the right tool?

Excel is not a temporary fix. It is the right environment for building the smallest setup a business truly needs: keeping critical logic in-house and transparent, analysing data, testing assumptions, modelling scenarios and explaining how the business works to other people.

It has real limits in data scale, simultaneous multi-user editing and granular access control. My approach is honest about them. When those limits become binding, the right tool changes. Until then, complexity introduced before it is necessary is a cost, not a feature.

Why do teams avoid tools that were meant to help?

Because the tool adds work before it removes work. In a busy day, people default to what they already know, even when it is imperfect.

Change sticks when it removes a frustration people already feel. When the frustration disappears, adoption follows without being pushed.

How do I run the blackout test?

Imagine your primary software is unavailable for a week.

Can you still serve your customers? Make basic operational decisions? Explain to someone how the business works? Access the core information you actually need?

If yes, the tool is support: useful and not a significant operational risk. If losing access means you cannot function or cannot explain what you are doing, you have let a tool become a substitute for understanding your own business.

The answer should always be: everything that matters still works. Maybe slower, maybe manually, maybe less efficiently. But it works.

Phronesis works with micro, small and mid-sized businesses and functional teams that carry operational responsibility without dedicated data and analytics support. Engagements are fixed-scope, Excel-based and built to be owned entirely by the client from day one.