Most businesses that call us describe the same symptom. We cannot see what is going on. What they need next depends entirely on which of two different problems is causing it, and the two need opposite treatments.
A data problem means the information exists but you cannot get at it, or you cannot trust it when you do. A process problem means the information was never captured properly in the first place, because the way the work happens does not produce it.
Spend money on the wrong one and you get an expensive dashboard nobody believes.
The test
Pick a question your business genuinely cannot answer quickly. Something like: which customers were unprofitable last quarter, or how long a job really takes from order to invoice.
Now ask a different question. If I gave you two weeks and unlimited access to every system, could you answer it at all?
If the answer is yes, painfully, by hand, you have a data problem. The facts are in there. They are scattered across systems that do not talk to each other, in formats that need cleaning, and the effort of assembling them is why nobody asks. That is fixable with integration and a place where the numbers agree.
If the answer is no, not even with two weeks, you have a process problem. The data does not exist because nothing in the workflow ever recorded it. No amount of integration will conjure it. You have to change how the work happens first so the fact gets captured, then wait for enough of it to accumulate.
Why it matters so much
The treatments have completely different shapes.
A data problem is a technical project with a predictable end. You map where facts live, decide which system owns each one, resolve the disagreements, and build the connection. It is real work but it is bounded, and once it is done, the questions get answered in seconds instead of days.
A process problem is a change project. You are asking people to do something differently, usually to capture something that feels like admin to them and only pays off for somebody else. That needs a reason people accept, a way of capturing it that costs them almost nothing, and months before the data is useful. Treating that as a technical build is the classic mistake, and it is how you end up with a mandatory field full of junk.
The most common case
In practice it is usually both, in a specific ratio. About two-thirds of the questions turn out to be data problems and can be fixed reasonably quickly. The remaining third are process problems, and one or two of those are the ones that actually matter.
That is a good outcome, not a bad one, as long as you know which is which. Fix the data problems first, because they are faster and they build the credibility you will need for the harder conversation. Then take on the one process change that unlocks the question you most need answered.
What you should not do is bundle them into a single programme with one timeline. The data work finishes and delivers. The process work drags, gets blamed on the software, and takes the whole thing down with it.
A shortcut
If you want a quick read on your own business, look at where the manual effort sits.
If people are exporting, copying and reconciling, the facts exist and the systems are not connected. Data problem. If people are guessing, estimating, or telling you nobody has ever tracked that, the facts were never captured. Process problem.
Both are worth solving. They are just not the same job, and it is worth knowing which one you are buying. A Rapid Insight Workshop sorts your list into the two piles and tells you what each one is worth.
