Most ops and finance leads have tried this: IT or an analyst sets up Tableau or Power BI, it works for three months, then the team is back in the spreadsheet. Here is why the maintenance model breaks, where BI tools actually do work, and what is different about a fixed-scope build.
Most operations and finance leads have tried this before. Someone on the team, usually IT, sometimes a data analyst hired specifically for the project, sets up Tableau, Power BI, or Looker. There is a kick-off meeting, a requirements document, a demo that looks exactly like what everyone wanted. The tool goes live. Three months later, the ops lead is back in the spreadsheet.
This is not an unusual outcome. It is the modal outcome. Understanding why it happens is useful whether you are evaluating a BI tool for the first time or trying to figure out why the last one did not work.
The maintenance problem
Self-serve BI tools are not actually self-serve for the person who needs the data. They are self-serve for the person who built the dashboard, which is usually not the same person.
The cycle goes like this. An analyst or IT resource builds the initial dashboards based on the requirements gathered during the project. The dashboards go live. Three things then happen in parallel over the next six to twelve months.
First, the underlying data sources change. A field gets renamed in the CRM. The ERP upgrades and the API endpoint moves. The warehouse changes its export format. Each of these is a small breakage that requires someone who understands the data model to fix. That person is the analyst or IT resource, not the ops lead who uses the dashboard every morning.
Second, the requirements that seemed stable in month one are no longer what the team actually needs. The business has shifted. A new sales segment was added. The company started tracking a new metric that does not exist anywhere in the current dashboard. Every change is a request that goes into a queue, gets triaged alongside everything else, and comes back somewhere between a week and three months later in a form that is never quite what was asked for.
Third, the person who built it leaves, or gets pulled onto something else, or is simply busy. The documentation they left behind describes how the tool works, not why specific decisions were made. When something breaks, nobody can fix it quickly. The team works around the broken tile for a while, then stops opening the dashboard.
The wrong-questions problem
Even when the maintenance holds up, BI tools built by someone other than the daily user tend to answer the wrong questions. Not because the analyst did bad work, because requirements elicited in a kick-off meeting are not the same as the questions an ops lead actually asks at 8:30am on a Monday.
The kick-off question is: "what would you like to see?" The 8:30am question is: "which depot is heading for an overflow problem today?" or "which deal has been stuck in negotiation for more than three weeks?" These are not the same question, and they do not look the same on a requirements document.
The ops lead knows the difference intuitively, but cannot always articulate it in advance. They know when a dashboard is right because it answers the question they were about to ask before they asked it. They know when it is wrong because they look at it, do not see the answer, and open the spreadsheet.
Discovery, the structured conversation about what actually happens on a bad Tuesday morning, what decision the ops lead makes at 9am that everything else depends on, what the spreadsheet is doing that the dashboard is not, is what produces the right tiles. That conversation takes time and requires the builder to understand operations, not just data modelling. Most BI implementations skip it or compress it into a single meeting.
The training-and-adoption problem
Enterprise BI tools are built for analysts. The interface reflects that. A finance lead who opens Power BI for the first time sees a canvas with dozens of options, a data pane with hundreds of fields, and a set of visualisation types that require knowing which one is appropriate for which kind of question. The learning curve is real, and it sits between the data and the person who needs it.
Most BI implementations address this with training, a half-day session, a recorded walkthrough, a how-to guide. Three weeks later, the team members who do not use the tool daily have reverted to asking the analyst to make changes, because that is faster than learning to do it themselves. The analyst is now maintaining the tool and handling ad hoc requests, which is not what the project was supposed to achieve.
This is not a failure of the tool or the team. It is the natural outcome when a tool optimised for power users is deployed to people whose primary job is not data analysis.
Where BI tools actually work
It would be dishonest to write this without acknowledging when a BI tool is the right choice. There are companies for which Tableau or Power BI is exactly the right answer.
They tend to share a few characteristics. A dedicated data team, at least one full-time analyst whose primary job is maintaining and extending the dashboards. A stable, well-documented data infrastructure, ideally a proper data warehouse that the BI tool can query directly. A user base that is comfortable with the tool and uses it often enough to maintain fluency. And a budget for licenses that scales without friction as the team grows.
For a company at this maturity level, a self-serve BI platform is a reasonable investment. The maintenance burden lands on someone whose job it is to handle it. The flexibility is genuinely useful because there is someone skilled enough to use it.
For a 40-person operations team without a dedicated analyst, that infrastructure does not exist yet. Installing a BI tool does not create it. The tool adds maintenance burden without adding the capacity to carry it.
What is different about a fixed-scope build
A dashboard built around one specific use case, the Monday morning ops check, the monthly close, the weekly pipeline review, is a different kind of thing from a BI deployment. It is not a platform. It is an answer to a specific question.
The differences that matter in practice:
It is built by someone who has to make it work for you. A seven-day build with a day-one discovery call and a day-six review creates accountability that a BI implementation does not. If the dashboard does not answer the Monday question, the build is not done. There is no softening that with "you can customise it yourself."
The maintenance model is explicit and bounded. The connectors are documented. The data sources are known. When a field changes in the CRM or the warehouse upgrades, the impact is understood in advance because the dashboard was built with specific sources in mind, not against a general-purpose data model. Changes are handled as part of ongoing support, not as a ticket in a queue.
There is no training curve for the daily user. The dashboard shows the tiles the ops lead actually looks at. There is no configuration interface, no canvas to adjust, no decision about which visualisation type is appropriate. It opens, it answers the question, it closes. The person who uses it every morning had input on what it shows.
The cost is known upfront and does not compound. A per-seat BI license grows as the team grows. A fixed-scope build does not. The question of whether it is still worth the cost does not arise every renewal cycle.
How to tell which one fits your situation
Two questions are usually enough. The first: do you have a dedicated analyst or data engineer who will own the dashboard after it goes live? If yes, a BI platform's flexibility is genuinely useful. If no, you are buying maintenance burden along with the tool.
The second: are you trying to answer one well-understood question, or are you building an analytics capability? If the question is "I need to know by 9am every day whether we have a depot capacity problem", that is a specific, answerable question. A fixed-scope build can answer it in seven days. If the question is "we want to be able to explore our data flexibly across all our teams", that is a capability, and it requires the analyst, the warehouse, and the platform to support it.
Most ops and finance leads who come to us have a specific question they have been unable to answer without a two-hour manual process. The dashboard is the answer to that question. The BI tool, for them, was the platform they bought hoping it would help them find the answer.