Why can’t I just ask any question and get the answer?

Adnan Krso
Jul 14
6 min read

Imagine a world where anyone in the company can just ask a business question - and get the answer.

I mean, how hard can it be?

Why is it so difficult in your company?

At least know this: you’re not alone. It’s hard in every company - especially in large, legacy-heavy ones.

As a business person, the frustration is real. You look at IT and data teams and wonder:

“We have the data. We have the systems. Just give me the answer.”

And honestly, you’re not wrong to ask.

But to understand why it's so hard to get "simple" answers, you have to follow the data journey - and what it really takes to connect the dots.

(Note: I’m assuming you already have the IT competence, integration capabilities, a functioning data platform, and other core tech infrastructure in place - and that alone is no small feat, even before we get to what follows.) SO lets get to it, answering our business questions:

Step 1: The Questions

Let us start with a seemingly simple task:

Can we answer our business questions, we should be able to do that in 2025.

Sounds fair. But now we enter the data teams world.

Step 2: Mapping the Questions

The first job? Together with managers, data team Identifies every question the business might want to answer.

Revenue by product, region, customer type
Churn and retention by cohort
Gross margin impact by channel
CAC vs CLV by market
Active vs inactive users and PnL impact
Or whatever..

These are real, complex, strategic questions.

The problem: None of them exist in any system!

Step 3: The System Hunt

Now comes the systems audit. Where can we find all this data?

ERP systems (systems for your core processes), Subscription engine, Customer support system, Finance ledgers. Marketing tools, 30 databases on different data, Telemarketing system, Billing system, Website, App, Bookeeping system, consent management database, External systems, Partner data.. the list goes on.

But here’s the twist:

These systems were never built to answer questions.

They were built to execute workflows and processes - not explain business impact.

Your CRM stores interactions, not conversion logic. Your ERP processes orders - it doesn’t care about churn. Your billing and finance system tracks invoices - not CAC.

Each system speaks its own language. None of them speak business.

Step 4: Extracting the Data

The data team now digs in.

Every question must be broken down into system - level components. They start pulling data - but what they find is cryptic.

Fields like TRX_56XG with no documentation. What is that?
Timestamps with three different formats. How was that developer thinking?
Status fields with unclear logic like 1=Open, 2=Processed, 3=Cancelled - but maybe still active. Or WHAT?

Often, data team wonder, how is this system even working, and why did we not asked how their data structure is when we bought the system, or at least can they even share data in the first place.

It’s a mess. But it gets worse.

Step 5: Data that’s Dirty - or Missing

Some data is outdated. Some is incomplete. Some doesn’t exist.

Important pieces - like cost allocation keys, customer tags, and report subscriptions - live only in Excel. Or worse, in people’s heads. How to fetch that and is it updated and by who?

No system holds it. No documentation explains it, hard to find responsible person.

The only way to fix it? Track down every stakeholder, extract their tribal knowledge, and translate it into a shared, machine-readable format.

Easier said than done. Everyone’s busy. And somehow the data team is expected to understand the entire business - every function, every edge case, who knows what, and who’s responsible for what.

That alone can take weeks. Or months. Or never - especially when the data team isn’t just gathering knowledge, but also has to create structure around it and design processes to keep it up to date.

Wait… are we driving process change now too?

Step 6: Stitching It All Together

Now, after long time of fighting and scrapping, the data team has a raw model. And some more gray hair on their heads.

Every system cleaned, translated, documented, and stitched together into one consistent company data model in the new data platform.

The questions should be answerable now, right? Now we at least know what to ask against!

Not quite :-)

Step 7: The Logic Gap

Team realizes: business logic still isn’t applied.

What is a “customer”? How do we define that?
What counts as “active”?
Is churn defined by last login, contract end, or lack of purchases?

These rules don’t exist in data - they live in leadership heads.

Even worse: they vary by department.

Sales has one definition. Finance has another. Ops has a third. What is correct? And who decides?

Without a shared semantic layer - business-aligned, consistent logic - you’ll always get three answers to one question even if the underlying data is correct.

Step 8: Building Business Logic

Finally, the data team sits with finance and controlling. They define it all and everyone must follow that! Lets hope so anyway!

Contribution margin = X - Y - Z
Active user = 2 logins in last 30 days and a transaction last 3 months.
Churn = Inactivity + no contract renewal after 45 days

Data team writes these into a reusable semantic layer and make calculations that every analyst follows in one place. They forbid everyone to calculate themselves. They hope so anyway.

Now the data model is smart. Now the logic is embedded.

It’s ready. Or is it?

Step 9: Delivery… and the Crash

The questions start coming in. The answers flow. Business is excited, data teams are proud.

Until someone says:

“This number looks wrong. And here we miss data”

The data team digs in.

Turns out, a core system changed its table structure - without telling anyone. A pipeline broke. The logic silently failed.

No alerts. No warnings. Just weak data contracts.

The data team never set clear boundaries on what source systems are allowed to change without coordination. Or maybe they did - but in a company that doesn’t operate as a unified whole, those rules were forgotten.

That system who made changes, suddenly wasn’t only just doing its job anymore - it had quietly become a source of truth for analytics across the entire company. And they did not understand that.

Data people now, are the only ones who knows how it all works on top of all systems.

And that’s terrifying.

Step 10: One More Twist

Even with the model built and logic applied, data team faces one last problem:

The BI tool can’t answer all the questions at once.

Why?

Because most older (most currently used) BI tools are domain (data mart) - bound.

They most often sort data into data domains to scope it down (make it manageable) and present data in domain "apps" which you build dashboards on.

But the business doesn’t think like that.

It wants to ask: “How did all our product changes last quarter affect CAC and churn in our top three markets?”

That sometimes spans 14 systems and 5 departments.

Domain based dashboards can’t answer that without building a specific, larger one for just that question. Each product has own data mart and model and on top of it sits one, or multiple dashboards. If you want to ask cross domain questions, WELL build one more app.

Or even worse, extract multiple apps to excel (who has time to wait for data team to build new app) and start sharing those insights. Yes now you are a data team owning all problems, but you don´t realize that (yet).

Step 11: Time for AI?

So data teams looks at LLMs. Text-to-SQL tools. Generative analytics.

Game-changers? Business asked can we apply AI on this?

Only if you already have:

Clean, joined, structured data across all systems and domains
Shared business logic and super clear context that no human can suddenly change
Transparent semantic layer (all that business logic in one place)
IT infrastructure and knowledge in your team to build it correctly
All above steps sorted out and structured and fixed
Getting data platform as federated "brain" on top of all your systems

Otherwise, AI just gives you wrong answers faster.

Final Realization

The issue was never the tool.
It was how we structured our systems, teams, definitions, and logic.
It’s not enough to “have the data.”
You need to align business understanding, embed logic, clean sources, and build models
Make your whole IT ecosystem designed to answer - not just store and process

So why can’t you just ask a question and get an answer?

Because the journey from curiosity to clarity isn’t automatic.

It’s designed.

And if you want better answers you have to design for them. //AK