A growing company sooner or later reaches a point where conversations, spreadsheets and individual reports are no longer enough for calm management. The number of customers, orders, employees, processes and systems increases, and so does the number of decisions that need to be made from the same data. This applies both to companies that scaled according to a deliberate plan and to those that developed step by step as the market, customers and new opportunities appeared.

At that point, questions appear that intuition no longer answers. Was this month better than the previous one if margin dropped but revenue went up? Which customer segment actually earns money? Is the service team keeping pace? Where does the gap between the sales report and the accounting books come from? The board asks for one number and gets three different values from three different departments. Each looks correct and each is defended by its author.

This is the moment when the company starts to need KPIs understood as a shared language of decisions. A language in which the people running the company talk about progress, risk and priorities based on the same numbers, not on their own private reports. This article explains what KPIs are, what they are for, how to choose them for different types of company, how to calculate them, where the data should come from, and how a data warehouse and a BI system can help keep these measures consistent. With no ready-made list of “the most important KPIs for every company”, because no such list exists, and with pointers to solid sources at the end.

What a KPI is

KPI stands for Key Performance Indicator. The simplest way to think of it is as a chosen, measurable indicator of progress against a previously defined goal. The definition used by KPI.org / Balanced Scorecard Institute emphasises four traits: the indicator must be tied to a goal, must show progress, must be understandable to the people making decisions, and must be calculated in a repeatable way so that comparisons across time mean something.

It is worth separating two concepts that companies often confuse:

• A performance measure is a number describing what the company does: how much it sells, how well it serves customers, what the quality is, how many people it employs. The State of Washington Performance Measure Guide describes such measures as data that answer questions like: how much are we doing, how well are we doing it, and is the recipient of our work better off because of it. The measure itself is information; it does not yet decide that this is the indicator a board will rely on.
• A KPI is a measure that has been consciously selected as key to managing a particular area, because it is connected to a goal, a decision and a responsibility to react.

In other words, every KPI is a measure, but not every measure should be a KPI. The difference comes from how the company uses a given number in management. The same Washington guide stresses that measurement should support learning and the improvement of results. Tying measures too mechanically to incentives quickly directs the organisation’s attention to the wrong activities.

In practice a good KPI passes a simple test: does this number help someone make a decision, set a priority, react to a deviation or assess progress against a goal? If the answer is no, what you have is a measure that can serve analysis but does not play the role of a management indicator.

KPI.org also distinguishes types of measures that are useful to keep apart in management: input measures (e.g. headcount, budget), process measures (e.g. cycle time), direct output measures (e.g. number of shipped orders), outcome measures for the recipient (e.g. customer satisfaction), and leading and lagging indicators. Lagging indicators, such as monthly margin, tell you what has already happened. Leading indicators, such as the sales pipeline or first response time, tell you what to expect. The board of a company that wants to scale usually needs both.

Why KPIs matter in running a company

The most important function of KPIs in a growing company is to bring different people to the same table with the same information. Where there are shared measures, the board discussion revolves around decisions, not around the question of “whose number is the true one”.

KPI.org points to three deeply practical roles of KPIs: improvement of results, data-based decisions, and connecting the daily work of teams to broader company goals. The last point is particularly important for the owner. When the sales team, the warehouse, finance and customer service do not see indicators connected to the same goal, each starts to optimise its own piece. The result is sales that break records while the warehouse cannot keep up and customers wait two weeks for goods.

Practical benefits of well-set KPIs, visible in companies scaling from the inside:

• The board sees the same numbers as the people responsible for delivery, and does not have to settle which version is “the real one”.
• Deviations can be caught earlier, before they turn into a problem visible in the monthly result.
• Responsibility for an outcome can be tied to a person or a role in the company, not to a department as an abstract entity.
• Setting priorities stops being a game of storytelling. The argument “I think this is important” gives way to the argument “indicator X has been falling for three weeks and is not responding to the actions taken so far”.

On the other hand, KPIs without shared definitions can, in the same company, create fights over numbers instead of helping. If a growing company rolls out indicators without agreeing what exactly is being counted, over what period and from which system, board discussions quickly come down to reconciling numbers rather than agreeing on decisions. dbt Labs writes about this phenomenon among others in their materials on the semantic layer and central metric definitions (Build, centralize, and deliver consistent metrics with the dbt Semantic Layer).

A historical reference point on linking measures to strategy is the Balanced Scorecard by Robert Kaplan and David Norton, published in Harvard Business Review in 1992, and later developed in the book The Balanced Scorecard: Translating Strategy into Action (Harvard Business School Press, 1996). The authors showed that financial indicators alone are not enough to run a company: they should be complemented by measures of the customer, of internal ways of working, and of organisational learning and growth. For someone running a growing company, the conclusion translates directly into daily work. The financial result alone tells you what happened. To understand why, and what to do next, you need additional measures that stay close to the strategy.

Choosing KPIs for different types of company

The most common mistake of companies that start to put their indicators in order is to copy a “universal list of the most important KPIs”. Such lists circulating online usually come from different business contexts and, taken together, produce a set of measures with no internal logic. KPI.org explicitly notes that KPI examples are not a ready-made list to copy. Effective indicators must follow from the company’s strategy, goals and situation.

A more sensible approach starts with the questions a leader should answer for themselves before choosing the first indicator:

• What goal do we want to reach in the coming period? Growth, profitability, shorter lead time, customer retention, putting service in order.
• What decision should be made on the basis of the indicator? An investment, a change in priorities, a management intervention, a change in process.
• Who can actually influence the result? An indicator without an owner responsible for the work in that area quickly turns into a reporting totem.
• How quickly do we need to see a deviation? Every day, once a week, once a month, once a quarter.
• Which system holds the closest record of the event we want to measure? Sales, invoice, shipment, work order, customer contact.

After that conversation it is easier to pick a few KPIs that match the business model and area of responsibility. The examples below are best treated as a map for a conversation with the team, not as a ready-made list to roll out.

Retail or e-commerce. Natural indicators include orders, net sales, margin, conversion, average basket value, returns, stock availability and on-time shipments. Data usually comes from the online store, the point-of-sale (POS) system, the invoicing system or ERP, the warehouse system and marketing tools. The terms ERP (Enterprise Resource Planning, usually the system that handles accounting and logistics, among other things) and WMS (warehouse management system) are explained in more detail further on.

B2B project or subscription sales. Typical indicators here include pipeline (the total value of current sales opportunities), the number of opportunities, win rate (the share of won deals), contract value, sales cycle time, receivables, churn (the share of customers who leave in a given period) and customer retention. The main data sources are CRM (customer relationship management), an invoicing or finance system and, if the company provides post-sales support, a ticketing system.

Manufacturing. The key indicators are usually plan vs. actual, line throughput, downtime, defects, on-time orders, material consumption and quality. The data flows from ERP, from MES and SCADA (systems that support production work and collect data from the shop floor), from quality systems and from the warehouse. The ISA-95 standard, defined by the International Society of Automation, organises this picture by placing ERP at the level of business planning and MES and SCADA closer to the shop floor.

Logistics and warehousing. Natural measures include stock availability, turnover, picking accuracy, order lead time and shipping delays. The natural data source for warehouse work is WMS, supplemented by ERP and the store or POS system. Oracle defines WMS as a system that provides inventory visibility and manages fulfilment from the distribution centre to the store or customer. Which source is the “official one” for a particular indicator should follow from that indicator’s definition card; sometimes board reporting reaches into ERP or a data warehouse even though the original record of warehouse events is created in WMS.

Service, help desk and customer support. Indicators include the number of tickets, resolved tickets, backlog (the queue of unresolved cases), first response time, resolution time, CSAT (customer satisfaction score) and contact reasons. The main sources are a ticketing system (e.g. a help desk), CRM and surveys. Zendesk documents examples of such metrics and their formulas in its knowledge base.

Finance and controlling. Natural KPIs include revenue, margin, costs, receivables, payables, cash flow and the profitability of a customer, product or project. The data usually comes from accounting, ERP, invoicing and, if the company already has one, from a data warehouse. Inside ERP, the central register of financial entries is the general ledger, described for instance in the Microsoft Dynamics 365 Finance documentation.

HR and workforce planning. Indicators include headcount, turnover, absence, overtime, time utilisation and training. The data comes from an HRIS (a human resources information system), from a time-and-attendance system and from payroll. Oracle defines HRIS as a system that manages employee information and HR procedures, while ADP describes time-and-attendance systems as tools that collect hours worked through clocks, paper and electronic timesheets, kiosks or mobile apps.

Even if a company recognises itself in several of these areas at once, it should not try to roll out dozens of indicators at the start. It is more sensible to pick a few KPIs at the board level and a few KPIs at the level of each department, which together tell one coherent story about the company.

How to calculate KPIs so that they count the same way everywhere

The most common problem of a growing company does not come from KPIs being badly chosen. It comes from the fact that the same indicator calculated in two places gives two different values. It is enough to have a board meeting where sales shows revenue for March, finance gives a different number, and the person reporting to the bank has yet another one. Everyone is right, because everyone counted differently, but the company does not have one number it can rely on.

The answer is a KPI definition card. It is a simple document that, for each KPI, states how to calculate it, on which data and who is responsible for it. Templates of such a document have long existed in the public and health-care sectors. The Performance Measure Methodology Sheet Template prepared by the International City/County Management Association (ICMA) covers, among other things, the indicator’s name, owner, reason for collection, meaning, data source, formula, frequency, target and unit. The American CMS Measures Management System describes a measure specification as instructions for building an indicator, precise enough so that every implementation calculates the same thing in the same way.

Translated into an ordinary commercial company, a KPI definition card should contain at least:

The table looks formal, but in daily work it saves time for a simple reason: if anyone ever asks “where does this number come from”, the answer does not depend on the memory of the person who put the report together. It comes from a document that can be shown, corrected and versioned.

In practice it is more sensible to start with a few of the most important KPIs, describe them in this way, and only then add more. Trying to write definitions for every indicator in the company at once usually overloads the team and gets lost in daily work.

Where the data should come from

The definition card answers the question of how to calculate. The next question is from where. In a growing company a KPI usually has several possible sources, and the choice matters.

Sales values can be pulled from the store system, from CRM, from the invoicing system or from accounting. Each of these sources has its own logic. The store knows the order from the moment of clicking “buy”, CRM knows opportunities and contracts, the invoicing system knows the invoice, and accounting knows the final booked revenue after adjustments. These numbers may diverge for natural reasons, not because of an error.

The main types of source systems that feed KPIs in an average growing company:

• ERP (Enterprise Resource Planning). SAP defines ERP as a system that helps organise the company’s core processes, such as finance, HR, manufacturing, supply chain, sales and procurement, providing a unified view of activity. In practice, ERP is usually the main source of truth for finance, stock and invoicing.
• CRM (Customer Relationship Management). Salesforce defines CRM as a system for organising customer data, tracking interactions and managing relationships across sales, service, marketing and commerce. It is a natural source of sales indicators: pipeline, win rate, sales cycle time, customer retention.
• E-commerce and POS systems. Shopify’s documentation shows how to track order metrics for a chosen period in the store admin, including the number of orders and the number of ordered items. POS is the in-store sales system (software with a terminal), usually tied to the same sales logic.
• WMS (Warehouse Management System). Oracle describes WMS as a system that provides inventory visibility and manages order fulfilment from the distribution centre to the store or the customer. It is a natural source of indicators related to stock availability, picking and shipping.
• MES and SCADA. These are systems from the shop floor, described together with ERP in the ISA-95 standard. MES (Manufacturing Execution System) knows individual production orders; SCADA collects data directly from machines.
• Ticketing / help desk system. Zendesk documents typical ticket metrics, for example the number of tickets created, solved and unsolved, together with the formulas.
• HRIS, time-and-attendance and payroll. Oracle defines HRIS as an employee information system, and ADP describes a time-and-attendance system as a tool that collects hours and is connected to payroll.
• Data warehouse. IBM describes a data warehouse as a system that integrates data from many sources; the data goes through an ETL process that cleans and structures it before analytical use.

The choice of source system is not neutral for an indicator. Revenue counted “by order” will show different values than revenue counted “by invoice” or “by booked payment”. The definition card should clearly indicate which moment and which system is the point of truth for a given KPI. Without that, even correct data from each of the systems can produce different values for the same indicator, and the company finds it hard to decide which is “the right one”.

Why the same KPI can produce different values

The most important practical observation for someone running a growing company is this: differences in KPIs between systems are the norm when the company does not have a single definition layer and shared dictionaries. They usually do not come from an error or bad intent — they come from the fact that each system looks at the company from a different angle.

The most common causes of differences worth checking before disputes about “the right number” begin:

• Different event dates. Order date, payment date, invoice date, shipment date, close date. Sales usually looks at orders, finance at invoices, the warehouse at shipments.
• Different record statuses. Test, cancelled, returned, on-hold, draft orders. If one report counts everything and another skips cancelled ones, they will differ.
• Different scopes. The whole business, a chosen company, a branch, country, channel, customer segment, warehouse. The same indicator can be counted “at the group level” or “at the parent company level”, and the difference is not an error.
• Different value definitions. Gross vs. net, with or without tax, with or without discounts, before or after corrections.
• Different customer and product identifiers. The same customer can be different in CRM, ERP, the store and WMS if each system stores them under a different code.
• Different refresh moments. Daily report, near-real-time data, values from a month ago. The board looked at different reports at different moments and sees different numbers.
• Different currency and conversion rules.
• Different permission filters. The same dashboard shown to two people can yield different values if each one sees a different slice of the data.
• Different aggregations. Sum of transactions, value of unique orders, average per customer, average per day. Everything sounds like “average sales”, yet each means something different.

For the board, the conclusion is pragmatic. If sales, finance and the delivery teams see different values for the same KPI, decisions rest on a local version of the data, not on a shared definition. Inconsistent KPIs complicate period comparisons, bonus payouts, stock planning, customer profitability assessment, month-end close, and conversations with investors or a bank.

dbt Labs, in its material on the semantic layer (Build, centralize, and deliver consistent metrics with the dbt Semantic Layer), describes this problem directly: different calculations of critical measures can lead to disputes about which version of reality is correct, weaken trust in data and make decisions harder. In the everyday language of a manager, the same phenomenon sounds simpler: “meetings where half the time is spent on agreeing whose number is the right one”.

How a data warehouse, master data, governance and BI help

The question of how to make the same KPI produce the same value regardless of who asks and where they ask is answered, in data management, by several elements. They are not interchangeable; together they form a package whose individual elements rarely work in isolation.

A data warehouse is a central place where data from various company systems is collected, organised and prepared for analysis. IBM describes it as a system that integrates data from many sources: transactional databases, business systems and CRM platforms; the data usually goes through an ETL process (extract, transform, load) that cleans and organises it before loading. The warehouse offloads the source systems from heavy reporting queries, records historical changes (for example how a customer’s status changed over time) and lets you compare periods even when the source systems have changed their data structure.

Master data management (MDM) answers the question of what, in fact, a customer, product, branch, warehouse, supplier or employee is. IBM describes MDM as an approach that consolidates key company data and reduces fragmentation, duplicates and inconsistencies. Without it, the company may talk about “the same customer” while ERP, CRM and the store each have them stored under three different codes, and a report combining the three systems treats them as three different customers.

Data governance is the set of rules and responsibilities through which definitions are written, approved, changed and maintained consciously. IBM notes that governance can create a so-called single source of truth — one shared source of truth for the organisation — by centralising definitions and metadata in a data catalogue. In management practice, governance ensures that a KPI definition does not disappear together with the person who created it.

The metrics layer (semantic layer / metrics layer) is the practical idea of keeping indicator formulas in one place, while different tools (BI, spreadsheets, analytical notebooks, board reports) query the same definitions. dbt Labs describes this approach, among other places, in Unify metrics and accelerate analytics with dbt Semantic Layer. For the board this means roughly: if the margin formula is the same in Power BI, in the financial controller’s spreadsheet and in the management app, because everything reaches for one definition, fights over numbers are rarer.

BI (Business Intelligence) is the set of tools through which data becomes visible to the people running the company. Microsoft, in the Power BI documentation, describes scorecards and goals as a way to curate goals and track their delivery in a single view, with accountability, team alignment and visibility of initiatives. A value on a scorecard refreshes as often as the underlying data model refreshes. This matters because BI by itself does not fix data. It shows what it receives.

The most important takeaway: a data warehouse and BI do not create KPI consistency on their own. Consistency is created by shared definitions, master data, governance and a deliberately designed data layer. The warehouse and BI are the tools that make these agreements repeatable and comparable over time.

How to start in practice

For someone running a growing company that does not yet have a formal KPI management system, a sensible sequence usually looks like this:

1. Start with a few business goals that genuinely matter for the next six months. Not with a list of “all areas of the company”. Goals usually let the company itself recognise which decisions are critical.
2. For each goal, name the decisions the board wants to be able to make faster and with more confidence. This leads to the question of which indicators are really needed and which are convenient but unused.
3. Pick a small number of KPIs that together tell one coherent story about the company. It is better to start with a few indicators at board level and a few at the level of each department and to expand the list carefully than to roll out dozens of indicators that no one will maintain afterwards.
4. Write a definition card for each KPI, following the schema described earlier. Without this, further technical work hits a wall.
5. Indicate which source system the data comes from. If a given indicator can be calculated from several systems, decide which source is the official one for the board.
6. Designate business owners and data owners. The business owner approves what the indicator means. The data owner is responsible for ensuring the number is correct and explains differences when they appear.
7. Test whether the same KPIs calculated from different systems produce the expected result. If they differ, work out why: date, status, scope, value definition, identifier, aggregation, refresh, currency, permissions.
8. Only then make decisions about tools: data warehouse, metrics layer, BI. A tool decision after the definitions are in order is usually calmer and leads to better-chosen tools, because you already know what they have to support.

This sequence does not require the company to buy tools first and then find a use for them. It requires it to name its goals and decisions first, and then choose indicators and technology to support those decisions.

A practical take on a similar rhythm of work on indicators can be found, among others, in Stacey Barr’s book Practical Performance Measurement: Using the PuMP Blueprint for Fast, Easy and Engaging KPIs, which describes how to build measures that are understandable and useful to managers, not just formally correct.

A short summary for the board

KPIs are a management tool when they are well defined, calculated from reliable data and understood in the same way across different parts of the company. Without these conditions, they remain a set of charts that look like a management report but are not one.

A growing company that has moved into a larger scale needs a shared language of decisions. KPIs are a pragmatic form of that language and work well in management. A definition card, agreement on the data source and the owner, and a deliberate understanding of why the same indicator can diverge between systems, deliver the most value. A data warehouse, master data, governance, a metrics layer and BI become valuable once those agreements are in place.

In such a setup, the board receives a tool for running the company. Without it, even a very nicely designed dashboard mostly shows inconsistent data.

Further reading

Books that help owners and managers organise their thinking about KPIs, measures and data-driven management:

• Robert S. Kaplan, David P. Norton, The Balanced Scorecard: Translating Strategy into Action, Harvard Business School Press, 1996. A classic on linking measures to strategy across several perspectives.
• David Parmenter, Key Performance Indicators: Developing, Implementing, and Using Winning KPIs, 4th ed., Wiley, 2019. A guide to the process of designing KPIs and to accountability for measurement.
• Stacey Barr, Practical Performance Measurement: Using the PuMP Blueprint for Fast, Easy and Engaging KPIs. A practical guide to choosing and implementing measures that managers can understand.
• John Doerr, Measure What Matters, Penguin Publishing Group, 2018. On OKRs and the management rhythm built on measurable outcomes.
• Ralph Kimball, Margy Ross, The Data Warehouse Toolkit: The Definitive Guide to Dimensional Modeling, 3rd ed., Wiley, 2013. A classic on modelling data for reporting and BI.
• DAMA International, DAMA-DMBOK: Data Management Body of Knowledge, 2nd edition. A framework for data governance, master data, data quality and enterprise data management.

Sources

• KPI.org / Balanced Scorecard Institute, What is a Key Performance Indicator (KPI)?
• Washington State, Performance Measure Guide
• Robert S. Kaplan, David P. Norton, The Balanced Scorecard — Measures that Drive Performance, Harvard Business Review, January–February 1992.
• ICMA, Performance Measure Methodology Sheet Template
• CMS Measures Management System, Measure Specification
• IBM, What Is a Data Warehouse?
• IBM, What is Data Governance?
• IBM, What is Master Data Management?
• Microsoft Learn, Get started with goals in Power BI
• dbt Labs, Build, centralize, and deliver consistent metrics with the dbt Semantic Layer
• dbt Labs, Unify metrics and accelerate analytics with dbt Semantic Layer
• SAP, What is ERP?
• Salesforce, What is a CRM system?
• Microsoft Learn, General ledger overview — Dynamics 365 Finance
• Shopify Help Center, Viewing order analytics
• Oracle, What Is a Warehouse Management System (WMS)?
• ISA, ISA-95 Standard: Enterprise-Control System Integration
• Zendesk Help, Metrics and attributes for Zendesk Support
• Oracle, What Is HRIS?
• ADP, Time & attendance solutions for businesses

When companies evaluate BI tools, they usually compare features: connectors, refresh speed, visualisation types and licensing. These are reasonable things to check. However, they’re also the wrong starting point. The question that determines whether a tool gets used daily or abandoned after the first quarter is simpler: Will your managers actually open it?

Selection starts with decision routines

A useful selection process begins with one recurring decision that matters commercially. Weekly sales steering, margin control, inventory prioritisation, and campaign reallocation are common examples. When the decision is clear, tool evaluation becomes concrete. You can test whether the platform delivers trusted numbers on the right day, for the right audience, with clear drill-down paths.

This approach removes a lot of noise. Demo environments usually present ideal data and prebuilt dashboards. Real usage happens in messier conditions: source systems are inconsistent, definitions drift, and users need quick answers during meetings. A platform that holds up in those moments has a much higher chance of becoming part of the weekly workflow.

For context on how decision-support discipline has evolved, this article is a useful reference.

Data trust decides adoption faster than design quality 

Users return to a BI platform when they trust metric logic. Attractive dashboards with weak definitions lose credibility quickly. Once teams start questioning numbers, they move back to manual reconciliation and private spreadsheets. 

This is why governance should be part of tool selection, not a follow-up workstream. Tableau’s governance guidance explains governance as an ongoing model for trusted data and trusted content, with clear ownership and transparent workflows. Microsoft’s Fabric adoption roadmap presents a similar view, linking adoption to organisational maturity, accountability, enablement, and measurable return on analytics investment. 

In practical terms, selection teams should verify how each platform supports semantic consistency, access control, lifecycle management of reports, and change handling when business logic shifts. These capabilities influence daily trust much more than long feature checklists. 

Define adoption before you buy 

If adoption is not defined before purchase, every post-launch review turns into an interpretation. One team can point to published dashboards, another can point to continued Excel checks, and both can be technically correct. The issue is that “used” was never translated into observable behaviour. 

A better approach is to define adoption as repeated usage in real decision moments. That means leaders and managers open reports on their own, use them during recurring meetings, and rely less on manual reconciliations over time. This should be measured monthly from day one, so the business can see whether behaviour is actually changing or staying the same. 

Most platforms already support this type of evidence. For example, usage metrics in Power BI let teams monitor report views, unique users, and page activity, which gives a practical baseline for adoption tracking instead of opinion-based assessment.

Operating effort has to be priced before purchase

While license pricing is clear during procurement, operating effort is where most BI projects exceed their budget. Ongoing support, including data model maintenance, user permissions, and constant change requests, frequently consumes more resources than the software itself. In lean organisations, these tasks can easily overwhelm the analytics team if the platform’s complexity is underestimated.

A reliable evaluation must calculate the total cost of ownership across the first year, factoring in reporting growth and governance needs. You should test the platform against your internal staff’s technical capacity and your long-term plan for external partners. If an agency builds your initial dashboards, you need a clear strategy for how your team will handle the maintenance once that contract ends. Ultimately, the tool must be flexible enough to match your pace of business change without requiring constant, expensive manual updates.

What a strong final decision looks like 

The goal of a good selection process is to ensure the focus stays on the business, not the technology. When you account for the operating effort and clarify governance from the start, the platform becomes a reliable part of the daily routine rather than a source of technical debt. Success is not measured by the features available on launch day, but by whether the team is still using the tool six months later to solve real problems.

By matching the tool to your internal capacity and your decision-making rhythm, you create an environment where data actually informs action. This practical approach transforms BI from a one-time purchase into a lasting asset that helps the company move forward with confidence. Getting the choice right means the technology eventually becomes invisible, leaving only the insights and the results behind.

Not sure how to balance your team’s capacity with the right tech? Let’s talk. Just fill out the form below, and we can figure out the best path forward for your data!

Something has clearly been shifting in Europe over the last few years. Public administrations in France, Germany, and Denmark have decided to move away from commercial platforms — for example, by replacing Windows with Linux. They are choosing open document formats and opting for tools they can host and control themselves. The motivation is a mix of cost, data sovereignty, and a growing reluctance to depend so heavily on a handful of global (meaning: American) vendors.

Sooner or later, this strategy reaches the data layer. If the operating system, the office suite, and the document format are open, what about the warehouse, the pipelines, and the dashboards the board looks at every Monday morning?

What options do we actually have in 2026? Is moving away from the commercial systems of the leading vendors a problem, or an opportunity? What does an ecosystem built on open-source technologies look like in practice? That is what we will try to answer below.

What a modern BI system is made of

To compare tools sensibly, you first need to separate their roles. Otherwise, it becomes very easy to put fundamentally different things into the same category.

The first area is data storage and query execution. This includes tools such as PostgreSQL, ClickHouse, DuckDB, and Trino. Some work well as analytical databases, some are better for local analysis, and others are really a query layer over multiple sources.

The second area is extracting and loading data from source systems. On the open source side, Airbyte is an important reference point, while on the managed-service side Fivetran is a common comparison.

The third area is data transformation and modeling, which turns raw tables into something stable enough for consistent reporting. Here, dbt and SQLMesh matter most.

The fourth area is orchestration, meaning scheduling and supervising data jobs. The classic reference point here is Apache Airflow.

The fifth area is reporting and self-service BI. On the open source side, teams most often evaluate Metabase, Apache Superset, and Lightdash, while on the commercial side the reference points are usually Power BI, Tableau, and Looker.

Only after separating those roles does it become clear that open source BI is not a single product. It is a set of separate decisions that have to be made layer by layer.

What makes sense in each area

Data warehouse, analytical database, and query layer

This is the foundation of the whole setup. Choices made here affect query performance, scaling, and the cost of further development.

PostgreSQL remains a very strong starting point. The project has nearly 40 years of active development behind it, and the official site shows current updates for supported versions in 2026 as well. For small and mid-sized analytical workloads, PostgreSQL can be entirely sufficient, especially if the team already knows it well.

ClickHouse is a column-oriented database designed for OLAP analytics. It tends to perform well when data volumes grow and query workloads become heavier. It offers strong performance but usually demands a more deliberate approach to modelling, and operations than managed services do.

DuckDB works extremely well for local analysis, file-based workflows, and quick prototyping. At the same time, it is important to remember the concurrency limits described in the documentation: one process can read and write to the database, multiple processes can read, but then none can write, and multiple writers are supported only inside a single writing process. That makes DuckDB an excellent tool for an analyst, but not a natural choice for a central shared database used by many people at once.

Trino serves a different purpose than a classic warehouse. It is a distributed SQL query engine that lets organisations query data where it already lives. It makes sense when data is spread across many systems and the company wants a common access layer without moving everything into one place.

On the commercial side, the main reference points are Snowflake and BigQuery. Their advantage is convenience: maintenance, updates, and much of the tuning stay with the provider. The price for that convenience is less architectural control and deeper dependence on the service model.

The conclusion is straightforward: open source makes sense in this area when a company truly needs more control or has requirements that a convenient managed service cannot reasonably meet. If the priority is fast delivery and low operational overhead, a managed model is often the better choice.

Extracting and loading data

In practice, this area is about how data gets into the warehouse and how much work it takes to keep source connections running.

Airbyte advertises more than 600 pre-built connectors, and Airbyte Core can be deployed as a self-managed system. For many teams, that is attractive because it offers more control over data movement without having to build everything from scratch.

It also matters that Airbyte Enterprise Flex separates the management layer from the part that actually transfers data inside the customer’s infrastructure. In multi-region deployments, workspaces can be mapped to specific regions, and the documentation says clearly that data in such a workspace is moved only through the assigned processing environment. That is a real argument for organizations that need tight control over where data is processed.

At the same time, this choice does not remove operational work. Anyone who self-hosts such a system also takes responsibility for monitoring, upgrades, connector failures, and environment maintenance. This is where the main rule of open source BI becomes visible: more control usually means more day-to-day responsibility.

Data transformation and modeling

This is the area that often determines the actual quality of analytics. Without it, a company usually ends up with an unstructured collection of tables and SQL queries. With it, the company can have consistent metric definitions, quality tests, and a logical data model.

dbt is the main reference point here. Its documentation emphasizes that it brings software engineering practices into analytics work: version control, testing, modularity, CI/CD, and documentation. The installation documentation also states clearly that dbt Core remains an open source project under the Apache 2.0 license.

SQLMesh moves in a similar direction, but places stronger emphasis on change planning and impact analysis before execution. For some teams, that can be a very sensible alternative.

This is also one of the areas where open source performs especially well. It is possible to build a mature transformation layer without buying a full commercial platform, as long as the team works with the discipline required by code, tests, and deployment processes.

Orchestration

Apache Airflow is an open platform for scheduling, running, and monitoring batch workflows. Workflows are defined in Python, and the web interface helps teams follow dependencies and troubleshoot problems.

On paper, that sounds simple. In practice, you still need to operate the scheduler, metadata database, workers, and the rest of the surrounding production setup. That is why Airflow fits organizations that want that control in-house or already have a team capable of operating such a platform. If not, managed variants of this type of solution are often the more sensible route.

Reporting and self-service BI

This is the area most visible to end users, and at the same time the one where the difference between open source and commercial tools is often the most noticeable.

Metabase Open Source can be run as an official Docker image or a standalone JAR file. It is relatively easy to start with. But the Metabase self-hosting documentation also lists the components needed for production operation: high-availability servers, a load balancer, an application database, SMTP, backups, monitoring, and SSL certificates. The infrastructure costs shown there start at roughly 112–132 dollars per month before team time is added.

Apache Superset offers more flexibility and broad data exploration capabilities, but the Superset quickstart explicitly says that Docker Compose is intended for quick starts and sandbox or development environments, not recommended for production. The production documentation points further toward Kubernetes-based deployments.

Lightdash is especially interesting for organizations already working heavily with dbt. At the same time, the Lightdash documentation is equally clear that secure production self-hosting requires strong knowledge of Docker, Kubernetes, and security, and that for most teams the cloud version is the recommended route.

On the commercial side, Power BI, Tableau, and Looker still have an advantage where user convenience, product maturity, and wide support for larger business audiences matter most. That is why reporting is the area where it is worth calculating very carefully whether self-hosting really pays off.

What open source really gives you, and what it only promises

The strongest argument for open source is still control. A company can choose its own infrastructure, understand the boundaries of the solution more precisely, and avoid accepting the full logic of a single vendor. In some areas, especially data transformation and orchestration, that is a very real advantage.

The second argument is the lower risk of being trapped inside one ecosystem. But this is where simplifications become dangerous. The open source BI market in 2026 often works in a mixed model: open editions exist alongside paid versions, cloud services, or management layers operated by the vendor. That does not cancel the benefits of open source, but it does show that “no lock-in” is not a binary state.

The third argument is cost. And this is the easiest place to oversimplify. No license fee does not automatically mean a lower total cost. If a company operates its own analytical database, integrations, monitoring, backups, upgrades, and high-availability environments, the cost comes back in another form: team time, infrastructure, and greater operational complexity.

The fourth argument is flexibility. It is true, but only when the organization has a real reason to use it. If the needs are standard and the team is small, a very flexible setup may turn out to be simply a more expensive way to achieve the same result.

Security, data sovereignty, cost, and AI

Security

Self-hosting can provide greater control over networking, access policies, and where data is processed. But that does not automatically make the system more secure. That advantage still has to be delivered operationally through fast patching, monitoring, backups, change control, and incident response.

In other words, open source can increase control over security, but it does not remove responsibility for security. In many organizations, that is the line between a good idea and an expensive illusion.

Data sovereignty

This is another area where simple slogans do not help. Storing data in Europe or inside your own infrastructure does not settle the sovereignty question on its own. You still need to distinguish at least a few things: where processing happens, how management is structured, what access the vendor has, what the contractual relationship looks like, and whether international transfers are involved.

That is why tools such as Airbyte can genuinely help with control over where data is processed, but they do not create a universal legal answer by themselves. If the issue concerns data transfers to third countries, the reference point remains the EDPB Recommendations 01/2020. Stronger conclusions require legal analysis, not just a technology statement.

Cost

The most honest answer is: it depends on the type of organization. Open source can reduce licensing costs and offer greater flexibility. However, the full picture also includes implementation, maintenance, DevOps and data engineering expertise, monitoring, support, and the time required to respond to issues.

For a company with a mature technical team and specific requirements, this model can be very cost-effective. For a smaller organization that simply wants to report on data efficiently without building its own platform, the operational overhead can quickly outweigh the apparent savings.

AI

AI genuinely helps with execution work: writing SQL, helper code, tests, documentation, or diagnosing simpler problems. But there is no basis for turning that into a universal promise of faster end-to-end BI delivery.

The evidence is mixed. A study on GitHub Copilot reported a 55.8 percent speed-up in a task focused on implementing a simple HTTP server in JavaScript. By contrast, a METR study on experienced open source developers found the opposite result: on average, work took 19 percent longer when AI tools were allowed.

The practical conclusion for BI is simple. AI can accelerate some execution-heavy work, but it does not replace decisions about the data model, metric definitions, data quality, operational responsibility, or security architecture.

When open source BI makes sense

Open source BI makes sense when an organisation clearly understands why it wants to take control over a specific part of the data platform.

Most often, it is a sensible path when the company:

• has or is building a team capable of operating production systems,
• truly needs more control over architecture, integrations, or where data is processed,
• consciously accepts the additional operational responsibility,
• wants to avoid full dependence on a single vendor ecosystem.

A more managed model is usually a better fit when:

• the team is small and does not want to build its own data platform,
• fast launch and predictable maintenance matter most,
• business-user convenience is the top priority,
• the cost of self-hosting does not create proportional benefit.

In practice, the best results often come from a mixed approach. Some companies choose open source because it brings the most real advantage, for example, in transformation or orchestration. At the same time, they keep more managed solutions where self-operation would be too expensive or simply unnecessary.

In the end, it is worth asking a few simple questions:

• Which parts of our data platform are truly strategic?
• Where do we need more control, and where is a reliable service enough?
• Do we have the skills to operate this setup without losing quality or security?
• Where will open source actually reduce cost or improve fit?
• Which tasks can AI sensibly speed up today and which ones should still not be handed over to automation?

If an organisation can answer those questions honestly, open-source BI stops being a trend or a worldview. It becomes a reasonable project decision.

If you are curious about the cost of implementation of Business Intelligence systems, you are already asking the right question. Most teams start with license pricing, but the real budget sits in delivery work, internal involvement, and long-term maintenance. A BI project can be a small pilot or a company-wide data platform. These two options are not remotely comparable in cost. What matters is not “How much is BI?” but “What scope are we implementing, and what operating model are we choosing?”

Business Intelligence is often associated with dashboards. In reality, dashboards are the visible layer of a deeper structure. A useful way to estimate cost is to look at the Total Cost of Ownership.

In practice, BI cost is usually built from:

• Planning and discovery work (requirements, KPI definitions, source mapping)
• Licensing and infrastructure (cloud capacity, user licensing, security setup)
• Implementation services (data modelling, ETL/ELT pipelines, reports, testing)
• Adoption and operations (training, support, ownership model, change process)
• Ongoing maintenance and development (new reports, source changes, performance tuning)

This is why two companies can pick the same tool and still end up with very different budgets.

What changes the price the most

Scope and operating model set the baseline because they define how much work must happen before anyone sees usable dashboards. License pricing is visible, yet delivery effort and internal time usually shape the budget more.

When data comes from an ERP, a CRM, spreadsheets, and e‑commerce exports, the team must map fields and reconcile definitions, so alignment work grows. For example, revenue can mean invoice date in finance and order date in sales, therefore you need explicit rules and a single source of truth. If the chart of accounts changes or cost centres are inconsistent across systems, the model requires additional transformation steps, which extend delivery.

Refresh rules add effort as well. A daily sales dashboard with late‑arriving data needs backfill logic and validation, so testing expands. Security rules add work when access must follow department, region, or customer segment, because you have to design, test, and document row‑level access. Internal availability matters too; when business owners review definitions less frequently, feedback cycles slow down and the plan grows.

Three common implementation scenarios

In BI projects, three patterns show up often, and they help explain why cost varies even with the same tool.

1. A focused pilot is typical when one area needs reporting for a narrow set of decisions. Data sources are limited and the model can stay compact. Cost is lower, yet later expansion may require rework if definitions were not designed for scale.
2. Shared reporting across teams adds alignment work. Several departments need consistent numbers and shared definitions, which means more workshops and governance. Validation takes longer because the logic must hold across different contexts.
3. A data platform foundation plus reporting is used when data quality and stability are the main risks. This includes pipelines and quality checks before reports are built. Cost is higher at the start, with better long‑term stability and fewer emergency fixes.

Hidden costs that are easy to miss

Work outside the dashboard often adds more effort than expected, and the reason is usually found in data readiness and decision‑making time.

After discovery, teams often find missing IDs, duplicate customers, or inconsistent product codes, so they must add cleanup steps and agree on master data rules. Internal validation takes longer when numbers affect incentives, budgets, or commissions, therefore sign‑offs require extra review rounds. Access and security reviews add time when legal or IT must confirm data usage, retention, or audit requirements, and these reviews often run in parallel to development rather than after it. Training and onboarding take effort because users need to understand filters, definitions, and reporting cycles; otherwise, they keep exporting to Excel. Ongoing changes continue because new sources appear, reporting logic evolves, and each source update triggers a small round of regression checks.

These items are normal, and they add real effort even when the tool is already selected.

How to control BI cost without reducing value

Cost control works best when scope and ownership are clear, because that limits rework and keeps decisions moving.

Start with the decisions the first release must support, and then align the scope to that list. If you focus on what actually drives decisions, you avoid building reports that look useful but do not change actions.

Next, prioritise data sources by business impact, so the team works on the inputs that matter most instead of the easiest ones. Build reusable definitions and models early, so later additions cost less and stay consistent. Assign ownership for changes and support, because a clear process prevents stalled approvals and repeated fixes. Plan a steady improvement cadence, since ad hoc requests usually add cost and slow delivery.

This approach keeps value intact while keeping delivery predictable. However, what if you feel like it’s too much work at the moment? Don’t worry, that’s where we’ve got your back – this is exactly what we do on an everyday basis. We are experts in analytics and data warehousing – we help companies to utilise their data: from strategy, through analytics and data warehousing, to automation and AI. Check out our Data-Driven Starter – a 2-day service with a senior data consultant to explore how data can support your business, assess your situation, and provide a report with recommendations and next steps.

Don’t hesitate to contact us using the contact form below – book your first free consultation with our expert now!

Decision Support Systems (DSS) have evolved over more than six decades, reflecting our changing relationship with data, technology, and decision-making itself. What began as experimental collaborations between human analysts and early computers has become a world of intelligent platforms that learn, adapt, and increasingly operate on their own. To understand how we got here (and where we’re going) we need to trace the layers of innovation, from military strategy rooms to predictive analytics embedded in everyday tools.

1960s: The Birth of Interactive Computing and Human-Machine Collaboration

The story begins in the Cold War era, where urgency drove innovation. The SAGE system, developed by the U.S. military, was not just a feat of engineering — it was one of the first examples of a real-time, data-driven system designed to support strategic decision-making. Operators interacted directly with data via light pens and CRT displays, helping monitor and coordinate air defense. This interaction planted the idea that people and machines could solve complex problems together.

Meanwhile, in academic halls, researchers like Michael S. Scott Morton at MIT conducted experiments on how computers could aid managers. In one study, production and marketing teams used simulation models to plan operations more effectively. His findings were revolutionary: decision-making could become more informed, timely, and rational, provided systems were designed around human needs and not just machine capabilities.

1970s: Establishing DSS as a Field and Framework

By the 1970s, DSS had become an area of structured inquiry. Theorists like Peter G.W. Keen and Scott Morton shifted the focus from tools to processes. They emphasized iterative design, adaptability, and user-centered development — ideas still central to DSS today.

At the core of many systems was the DDM architecture, proposed by Ralph Sprague. It broke down a DSS into three symbiotic parts: dialog (interface), data (storage and retrieval), and model (analytical logic). This framework helped organizations build systems that weren’t just technically sound but strategically aligned.

Case studies by Steven Alter documented how DSS were being used in industries — from banking to manufacturing — offering tangible evidence that theory was translating into real business value.

1980s: The Democratization of Analytics

With the spread of personal computing, DSS moved out of the lab and into offices. Spreadsheets enabled business users to run forecasts, budget scenarios, and what-if analyses with little technical training.

In parallel, the corporate world saw the rise of Executive Information Systems. These tools distilled key performance metrics into high-level dashboards, letting C-suite executives make faster strategic decisions. Other innovations, like Group Decision Support Systems, allowed teams to collaborate through shared interfaces: an early precursor to today’s real-time collaboration platforms.

The concept of DSS was maturing, shifting from toolkits to environments that matched how people actually work, think, and decide.

1990s: Scaling Up with Warehouses and OLAP

The 1990s marked a shift from local, individual support to enterprise-wide intelligence. With the explosion of corporate data came the need for centralization. Enter the data warehouse, promoted by Bill Inmon and Ralph Kimball. These centralized repositories enabled consistent, reliable access to historical data across departments.

To navigate these massive datasets, businesses adopted Online Analytical Processing (OLAP) tools. With their cubes, hierarchies, and drill-down functions, OLAP tools turned raw data into navigable knowledge. Users could spot anomalies, trends, and correlations in seconds rather than days.

Importantly, this era also saw a shift in architecture — from mainframes to client-server systems — which allowed for more scalable, distributed computing and positioned DSS as a core element of IT strategy.

2000s–2010s: The BI Era and Cloud-Driven Transformation

By the early 2000s, web-based DSS had become mainstream. Organizations connected employees across geographies using browser-accessible dashboards and reporting tools. This set the stage for a new wave of integration under the term Business Intelligence (BI).

BI platforms offered end-to-end capabilities: from data ingestion to visualization. DSS was no longer a standalone concept but a foundational layer of digital business operations.

In the 2010s, the rise of cloud computing and mobile analytics reshaped the landscape again. Cloud architecture reduced infrastructure costs and offered elastic scalability. Meanwhile, smartphones and tablets enabled decision-making at the edge — whether on a factory floor or during a sales pitch.

Data was now fast, voluminous, and decentralized. Big data platforms emerged to cope with streaming data, unstructured formats, and predictive demands. DSS adapted by incorporating real-time data pipelines and scalable storage solutions.

2020s: Learning Systems, Automation, and Algorithmic Decisions

Today’s DSS are intelligent systems. They learn from patterns, adapt to user behavior, and sometimes act autonomously. Algorithms sort through billions of records to detect fraud, forecast supply needs, or flag patient risks — often before a human knows to look.

The boundary between recommendation and action is eroding. In many industries, DSS doesn’t just inform the decision — it makes it. From IoT-integrated systems in logistics to algorithmic trading in finance, machines are now part of the decision-making team.

Yet, this rise also calls for scrutiny. How do we ensure accountability in automated decisions? How do we design systems that are transparent, auditable, and fair?

AI, Language Models, and Autonomous Agents

The most recent wave of innovation in DSSs is being shaped by artificial intelligence (AI) and by advances in language models and autonomous agents. Unlike traditional DSS, which rely on structured databases and predefined models, these systems can interpret unstructured information, generate insights in natural language, and even carry out tasks on behalf of users.

Large Language Models (LLMs) such as GPT demonstrate the ability to synthesize vast bodies of knowledge, contextualize data, and communicate recommendations in human-like dialogue. This changes the way decision-makers interact with systems: instead of navigating dashboards or coding queries, they can simply ask questions and receive nuanced answers. Beyond passive support, the rise of autonomous agents takes DSS one step further. These agents can plan sequences of actions, connect to enterprise systems, and execute workflows automatically. For example, an agent might not only recommend adjusting inventory levels but also trigger supply orders, update forecasts, and notify stakeholders.

Practical applications are emerging across industries. In finance, AI-powered DSS detect fraud in real time and execute algorithmic trades within milliseconds. In healthcare, language models assist clinicians by summarizing patient histories, suggesting treatment plans, or monitoring critical care alerts. In manufacturing, autonomous agents coordinate supply chains by predicting demand fluctuations, managing procurement, and optimizing logistics. Even in public administration, AI-driven DSS are helping governments model policy outcomes and allocate resources more effectively.

The integration of LLMs and agents into DSS brings unprecedented speed and accessibility, but it also raises new challenges. Reliability, explainability, and control become critical: organizations must ensure that automated reasoning is transparent and that human oversight remains central to decision-making.

In many ways, AI-driven DSS represent the culmination of the field’s long journey — from static reports to dynamic, learning systems that operate as collaborators. At the same time, they point forward. As we look ahead to quantum computing, ethical governance, and the broader question of human purpose in an algorithmic world, these AI-based systems form the bridge between today’s decision support and tomorrow’s intelligent, autonomous environments.

The Near Future: Quantum Speed, Ethical Design, and Human Purpose

On the horizon lies quantum computing, promising to solve complex optimization problems beyond the reach of classical systems. The potential to revolutionize DSS is enormous — imagine instantly simulating thousands of supply chain paths or policy scenarios.

But alongside technical breakthroughs, DSS will need new governance. Autonomous decision-making systems must be built with ethics at their core. That means creating standards for explainability, bias mitigation, and human override.

The future of DSS is not just about faster machines. It’s about wiser systems — ones that augment human judgment, respect human agency, and act with integrity.

DSS has never been just about technology. It’s about the ongoing negotiation between human insight and computational power. From Scott Morton’s laundry production models to predictive AI in intensive care units, the goal remains the same: better decisions, made with clarity and confidence.

As organizations face increasing complexity and volatility, those that treat DSS not merely as a tool — but as a strategic partner — will be best positioned to adapt, grow, and lead.