Why Every New Finance Question Takes a Week – Even When the Data Exists
By the team at Human Ready · Updated July 2026
Every new finance question takes about a week to answer. The data isn't missing, but answering a question nobody pre-built a report for still requires a human pipeline: someone files a request, an analyst gets assigned, IT extracts the data, the analyst builds the analysis, and only then does an answer come back. The data warehouse is fine. The dashboards are fine. The bottleneck is the distance between having the numbers and being able to interrogate them at the speed a decision requires. This page explains why that gap exists in mid-market and enterprise finance teams, what it costs, and what closing it actually looks like.
Why does a new question take a week when the data already exists?
A new question takes a week because dashboards and reports only answer questions someone already anticipated. A genuinely new question falls out of that system entirely, back onto people. In more than 25 buyer conversations Human Ready has held with CFOs, FP&A directors, and planning leads at European mid-market and enterprise companies, the same shape repeats, in different words:
- A chief procurement officer at a large enterprise put it in six words: "Every new question takes a week" – "cada pergunta nova demora uma semana." His company had a dedicated dashboards team; his description of it was that it was becoming "a monster."
- A finance leader at a global manufacturing group described a double bottleneck: a non-standard question means IT must first extract the data, and then an analyst works roughly a week before the question can even be answered. The data exists; every new question still costs a human-plus-IT cycle.
- The head of FP&A at a multi-country healthcare group described her team's most important analysis this way: "This insight today is very manual. It's sitting every Monday with five analysts... doing queries, having hypotheses, drawing conclusions. There are questions I just have no answers to."
Read that last line again. There are questions I just have no answers to. This is not a company that lacks data. It has the warehouse, the BI team, the dashboards, five capable analysts in a room. And still – month after month – the same ritual.
The pattern has a precise shape: the data is there; the decisions still take forever. The bottleneck moved from data to the pipeline between a question and its answer.
What actually happens between the question and the answer?
Between a new question and its answer sits a four-step human cycle – request, queue, extract, build – and each step adds days:
| Step | What happens | Typical cost |
|---|---|---|
| Request | The question is translated into a ticket, an email, or a hallway ask | Hours to days (and detail is lost in translation) |
| Queue | The request waits for analyst and/or IT capacity behind other requests | Days |
| Extract | IT or a data engineer pulls the data the existing reports don't expose | Hours to days |
| Build | An analyst assembles the extract, the model, and the deck | Days |
None of these steps is anyone's failure. Each one exists because the asking layer – the dashboard – can only serve questions that were designed in advance. The moment the question is new, the tooling steps aside and the org chart takes over.
The numbers back the pattern up. According to the 2024 FP&A Trends Survey (run annually across 2,400+ finance practitioners), only 35% of FP&A professionals' time goes to high-value work like generating insights – the rest is consumed by data collection and validation. For 29% of teams, finalising a single forecast takes more than 10 days. In the 2025 AFP FP&A Benchmarking Survey (362 practitioners, published January 2025), 60% of FP&A professionals said lack of accessibility to data holds them back – in organisations where more than half of teams juggle at least eight categories of reporting tools.
Why don't dashboards solve this?
Dashboards don't solve this because dashboards answer yesterday's questions – they are built for the numbers you check every day, not for the question that is always different. An FP&A director at a large healthcare provider put the distinction as cleanly as anyone we've spoken to:
"Deixar de fazer browse pelo dashboard certo e fazer search — eu pergunto e a análise certa aparece." Stop browsing for the right dashboard and start searching – I ask, and the right analysis appears.
A dashboard is a cockpit: same instruments, same place, built for decisions that need a fast look at known metrics. That is exactly what you want for monitoring. Analysis is a different job. A finance-and-strategy executive who has run controlling across several groups explained why:
"As pessoas querem usar dashboards para fazer análise — mas os dashboards são o que já conhecemos. Análise pressupõe novas perguntas que ainda não estavam pensadas." People want to use dashboards to do analysis – but dashboards are what we already know. Analysis assumes new questions that weren't thought of yet.
Her framing: there are three tiers of data consumption – the daily operational view, the periodic monitoring of tracked variables, and ad-hoc analysis, the new question nobody built a view for. The failure mode is using a tier-one or tier-two tool to answer a tier-three question. The dashboard was never meant for it, so the work falls back onto people – the request, the queue, the extract, the week.
Scale makes it worse, not better. A planning lead at a large retail group:
"A equipe é muito curta e os dados são gigantes... vivemos sempre com a frustração de estar a olhar só para a ponta [do iceberg]... elas têm uma escala que se torna doloroso reagir." The team is very small and the data is enormous... we live in constant frustration, looking only at the tip [of the iceberg]... the scale becomes painful to react to.
Every new dashboard is one more thing to browse – and one more thing nobody has the hours to interrogate. (If your organisation runs Power BI and everyone still exports to Excel, that is the same mechanism wearing different clothes – we unpack it in why everyone still exports to Excel.)
What does the week actually cost?
The week costs decisions, not just analyst hours – and decision speed is measurably tied to business outcomes. McKinsey's decision-making research found that organisations that make decisions quickly are twice as likely to report high-quality decisions than slow decision-makers. Executives spend nearly 40% of their time on decision-making – most of it, by their own account, poorly used.
A mid-market CFO drew the cost line herself, weighing whether faster analysis was worth paying for:
"Não sei até que ponto iria ter assim um ganho tão grande em termos quantitativos... eu posso ajustar mais rapidamente se o forecast for [melhor]... tornar estas decisões [de corte] mais rápidas." I don't know that I'd get such a big gain in quantitative terms... but I can adjust faster if the forecast is [better]... make these [cost] decisions faster.
She was unconvinced the numbers would be dramatically better. She was very convinced that deciding faster was worth paying for – because a month lost waiting for the analysis is a month of cost adjustment you never get back. The value of closing the gap is not a better answer. It's a faster one: the question answered inside the meeting instead of the week after it. (When the question comes from the board, the cost compounds – that specific case is covered in why board questions take a week.)
Why hasn't anyone inside the company fixed it?
Nobody fixes the week because almost nobody registers it as a problem – chronic friction stops being visible. A CFO at a multi-country industrial group described his month-end analysis grind as, in his own words, dumb work:
"...e eu no quinto dia tenho que ter uma análise feita... um trabalho... estúpido, porque não deixa de ser começar a ver um sapo." By day five after close I have to have an analysis done... dumb work, really – it's like starting to pick at a frog.
Then, unprompted, he said the thing we think about most:
"Nós nem nos apercebemos das dores que temos. Nem nos apercebemos do tempo que perdemos. Portanto, eu não tenho dores identificadas." We don't even notice the pains we have. We don't even notice the time we lose. So I have no identified pains.
That is why "we already have dashboards" and "we don't really have a pain here" are so often the same sentence. The dashboards handle the questions you knew to ask. The week lives in all the questions you didn't – and nobody is counting the time they cost. The FP&A team at a large healthcare group told us their monthly business review runs to roughly 200 slides, and that it is "hard to manually identify the most material deviations and trends" in it. The deck gets made anyway. Every month. That's what normalised pain looks like.
What does fixing it look like?
Fixing the week means adding a layer above the existing stack where a new question can be asked in plain language and answered against the same governed data – without a ticket, a queue, or a rebuild. Concretely, the shift from dashboards to questions requires four things:
- The stack stays. The warehouse, the BI layer, and the systems of record remain. This is not a rip-and-replace; it is an analytical layer on top. An IT director at an industrial company – mid-rollout on his own modern data platform – framed it himself as replacing the presentation layer, not the warehouse, and called it "o BI do futuro" – the BI of the future.
- Questions replace navigation. A new question is typed, not translated into a ticket. The analysis a person would have assembled in the war room is done against the same data, in minutes.
- Every answer shows its work. Speed without trust is worthless in finance – a number nobody can trace is a number nobody will take to the board. How that traceability works is a topic of its own: how AI-generated numbers can show exactly how they were produced.
- Dashboards keep doing what they're good at. The cockpit stays for tier-one and tier-two consumption. The question layer exists for tier three – the question that's always different.
Where Human Ready Advisor fits
Human Ready Advisor is our implementation of that fourth tier-three layer: an AI-native advisory platform that sits above a company's existing data stack and answers new finance questions in plain language – with every number traceable back to how it was produced. It doesn't replace Power BI, the warehouse, or the EPM; it answers the questions they were never built for. If your team has the dashboards and still spends its best hours answering new questions by hand, that's the gap we work on – humanready.io.
Related reading in this series:
- Every new board question takes my analysts a week — why, and what fixes it
- We have Power BI, but everyone still exports to Excel
- How AI analytics can show exactly how it got the number
Buyer quotes on this page come from Human Ready's ongoing conversations with finance leaders at European mid-market and enterprise companies, anonymised to role and company profile. Portuguese quotes are translated faithfully; bracketed insertions are editorial.