Business intelligence tools: how to choose without regretting it six months later

The conversation about business intelligence tools almost always starts badly: someone has seen a demo, the demo was beautiful, and the question that reaches the meeting is "which one do we buy?". That's the wrong question at the wrong time. Every serious platform on the market draws lovely charts from clean data; the difference between a good choice and a dead licence isn't the visualisation catalogue, it's how the tool fits your sources, your people and the way you actually decide.

This guide is the criteria we use when a client asks us to help them choose. You won't find a ranking of products by name — those rankings age in a quarter and are usually sponsored. You will find the four types of tool that genuinely exist, the questions to answer before looking at prices, where the cost nobody shows you in the demo hides, and how to run a trial that actually settles the decision.

What does a business intelligence tool really do?

Less than people think. A BI platform does three things: it connects to your sources, it lets you define a model with metrics and relationships, and it publishes dashboards and reports for people to consult. That's it. It doesn't clean your data, it doesn't agree on what a customer is, and it doesn't force anyone to look at the dashboard before deciding.

That misunderstanding explains most failed projects. If your three systems give three different revenue figures, the tool will show you all three, faster and with better typography. The groundwork — agreed definitions, an owner for each data point, a written source of truth — is not something any software does. We cover it in detail in data strategy and data governance, and if you're starting from scratch it's worth reading what business intelligence is first.

That said, the tool does matter in very concrete ways: how long it takes a business person to answer a new question without asking for help, how much it costs to maintain the model when the ERP changes, and whether the bill grows predictably when you go from 5 users to 60.

The tool doesn't fix the data. At best, it makes the mess visible sooner, and in colour.

What types of business intelligence tools are there?

Underneath the brand names there are four archetypes, and picking the wrong archetype hurts far more than picking the wrong brand within the right one.

| Type | How to spot it | Fits when | Its weak point | |---|---|---|---| | Suite bundled with your office stack | Comes with the corporate licence you already pay for | Mid-sized company, users already used to the ecosystem, small IT team | Real cost shows up when scaling users and capacity | | Standalone visualisation platform | Bought for its analytical power, not as part of a bundle | You have dedicated analysts and frequent data exploration | Needs someone to exploit it; otherwise it's an expensive viewer | | BI embedded in the ERP or CRM | A module of the management system itself | You only ever need that system's reports and nothing else | Chokes as soon as two sources must be combined | | Self-hosted open source | No licence cost, real infrastructure cost | There's a stable technical team willing to maintain it | Maintenance eats the saving if that team doesn't exist |

A fifth format shows up increasingly often: a semantic layer separate from the viewer, where metrics are defined once and several tools consume them. It makes sense when two or three viewers already coexist in the building and you want them all to say the same thing. As a first step in a company that doesn't yet have a dashboard in production, it's over-engineering.

Our bias, stated plainly: in a mid-sized company the bundled suite usually wins on adoption and learning curve, and the standalone platform wins when at least one person's main job is analysis. Embedded BI is a respectable option if you genuinely will never combine sources — which is almost never true on a two-year horizon.

What questions should you answer before looking at prices?

Six. Answer them in writing and the comparison resolves itself; skip them and any demo will convince you.

• Which three decisions must improve? Named, with an owner. "Visibility of the business" is not a decision. "Deciding weekly replenishment for product family A" is.
• Where does the data come from? A list of systems, with versions, on-premise or cloud. An ageing ERP with no decent connector reshuffles the whole ranking.
• How many people will read and how many will build? The ratio of consumers to authors drives the licensing model, and it's usually 20:1, not the 3:1 the sales rep assumes.
• Who maintains the model a year from now? If the answer is "we'll see", choose the most boring, standard tool available. The exotic one dies when whoever built it leaves.
• Where must the data live? If you handle personal or sensitive customer data, this constrains deployment before any functional criterion does.
• What sustainable annual budget exists? Annual and recurring, not the first-year price with the onboarding discount.

There's a seventh almost nobody asks that saves a lot of pain: what happens if we want to leave in three years? Ask whether the data model and the calculations export in a readable format or stay locked inside the product. The answer shouldn't disqualify anyone, but you should know the price of the exit door before walking in.

What does a BI platform actually cost?

The licence is the small part, and the only one that appears in the proposal. In the projects we've seen, first-year spend breaks down roughly like this:

| Line item | Typical first-year share | Comment | |---|---|---| | Licences | 15-25 % | The only thing anyone puts in the comparison spreadsheet | | Ingestion and data preparation | 30-40 % | Connectors, transformations, fixing whatever surfaces | | Modelling and dashboard building | 20-30 % | Less than feared, if scope is tight | | Adoption and training | 10-20 % | The line that gets cut, and the one that decides the outcome | | Infrastructure | 5-15 % | Higher if self-hosted or if volumes are large |

Three concrete costs that get discovered late:

Capacity, not users. Many models charge per user but cap refreshes, volume or concurrency. The jump to the higher tier isn't triggered by headcount, it's triggered by one heavy dashboard someone refreshes hourly.

Connectors to your systems. Standard connectors exist for popular systems. For the niche sector ERP from 2011 you'll need an intermediate extraction, and that's recurring hours, not a one-off.

Year two. The first year usually comes with an acquisition discount. Ask in writing for the three-year price at the number of users you expect to have, not today's.

An honest order of magnitude for a mid-sized company starting with one decision and two metrics: the licence is affordable under almost any option, and the project is decided by people's hours, not by software. If someone hands you a budget where the licence is the biggest line item, there's work still missing from the estimate.

How do you run a trial that actually settles the decision?

Sales demos use toy data, which is why they all go well. A useful trial uses your data, including the ugly parts, and is scoped hard.

• One use case, two metrics, two weeks. Pick the decision most often made by gut feel. If it doesn't fit in two weeks, the problem is the scope, not the tool.
• Real, dirty data. Include your worst-documented system. That's where the options separate; with a clean CSV they all tie.
• Let your people build it. The vendor's consultant can help, but if they build the whole dashboard, what you've evaluated is them, not the product.
• Measure times, not impressions. Hours to first connected data, to first valid dashboard, and to a business user answering a new question unaided.
• Test maintenance. Change a definition halfway through, the way life works, and time how long it takes to propagate.
• End with a written decision. Against criteria scored in advance. Without that, the winner is whichever tool showed the flashiest chart on presentation day.

If you're trialling two candidates, run them in parallel with the same use case and the same team. Comparing a March trial against a September one doesn't compare tools: it compares how much your team learned in between.

Which mistakes cost the most when choosing?

The same ones, over and over, in very different companies.

• Buying by feature list. You'll use 15 % of it. A geospatial heat map existing changes nothing if your real decision is restocking.
• Choosing without whoever will maintain it. If IT wasn't in the decision, the handover will be contentious and the model will age with no owner.
• Licensing the whole workforce on day one. Start with the users of the first use case. Expanding is easy; explaining 80 unused licences to the board is not.
• Building 40 dashboards before one is adopted. A huge catalogue dilutes attention and multiplies maintenance. One that gets used beats thirty that merely exist.
• Confusing BI with prediction. A dashboard explains what happened and what's happening. Anticipating is a different project with different history requirements; we cover it in predictive analytics.
• Buying the tool in order to tidy the data. It works the other way round, which is why we keep insisting on data before AI.

When do you not need a BI tool?

Sometimes the honest answer is "not yet". If all your information lives in a single system, fewer than ten people consult it and decisions are monthly, that system's native reports plus one tidy spreadsheet will do. Buying a platform in that scenario adds a layer to maintain without solving any problem.

The signals that the moment has arrived are fairly clear: someone spends more than a day a month copying and pasting the same report; two departments present different figures for the same concept in the same meeting; weekly decisions get made on month-old data; or the important report depends on one person and their file. With two of those four, the tool pays for itself. With none of them, wait.

Frequently asked questions

What is the best business intelligence tool?

There is no best one in the abstract. The best fit depends on your data sources, whether you have dedicated analysts, the ratio of readers to builders, and who will maintain the model a year from now. Any ranking that answers without knowing those four things is selling, not advising.

Can you start with business intelligence without a data warehouse?

Yes, and that's the norm for a first use case. Tidy extractions from one or two sources plus a small model will comfortably get a dashboard into production. The warehouse is justified when several sources must be combined daily, or when you need history the source systems don't keep.

How long does a dashboard take to go live?

With scope limited to one decision and two metrics, six to ten weeks including business validation. What stretches timelines is almost never building the dashboard: it's agreeing definitions and cleaning the source data, which can consume half the calendar.

Is open source worth it to save on licences?

Only if you have a stable technical team willing to maintain it. The licence saving is real, but it transfers into hours of upgrades, security and integrations. Without that team, total cost usually ends up higher than a commercial option, with a greater risk of abandonment.

If you're comparing business intelligence tools and the conversation has turned into a feature battle, the step before it is probably missing: knowing which decisions the tool has to improve, and what state the data feeding them is in. That's what the audit resolves, and it ends with a prioritised use case and selection criteria you can defend. If you'd rather test the thinking in half an hour before signing anything, let's talk.