Business Intelligence Dashboards on Live System Data

The monthly export, and what it costs you

The pattern is the same in most companies of this size. Somebody exports the ERP, somebody else exports the CRM, a third file comes from the online channel, and one person spends two days a month joining them into a pack. Nobody thinks this is good, and it survives because it works. What it costs is not obvious from the outside.

The filter that produced the file is not recorded. Cancelled orders in or out, intercompany transactions in or out, the date field used. Three months later nobody can say, so the figures cannot be compared with the ones from before.
The file forks. It is emailed, someone adjusts a column, that version is forwarded on. Two people are now certain of different numbers, and both are quoting “the report”.
You cannot get from a total to a record. The pack says receivables over ninety days rose. Which customers? That is a second request and another day.
The data leaves the permission system. Once it is a file in an inbox, the access rules of the source systems no longer apply to it.
It arrives after the decision window. A margin problem visible in week two of the month is reported in week two of the next month.
Silent truncation. Row limits, a filter left from last month, a paste that missed the last rows. Nothing warns you; the total is simply lower.

None of this is an argument against spreadsheets. For a one-off analysis a spreadsheet is the right tool and we will tell you to use one. The argument is against a recurring decision that depends on a manual export.

Live system data against an exported spreadsheet

The differences that matter are structural, not cosmetic.

Criterion	Exported spreadsheet	Dashboard on live system data
Metric definition	Whatever filter the author applied that time	One stored query per metric, versioned and owned
Reproducibility	Cannot be reproduced without the author	Same definition returns the same figure for the same window, every time
Drill-down	Ends at the total	From the total to the records, and from a record to the action
Access control	Lost the moment the file is sent	The viewer's own permissions apply to every figure
Freshness	As of whenever it was built; usually unstated	Shown on screen: last refresh time and whether the current period is complete
Comparison window	Whatever the author included	Built in: current period beside the comparable previous period
Cost of one more reader	Free, and that is the problem	No per-user fee, and the reader sees the current figure rather than a copy

Why every metric needs one definition in one place

Ask four departments what an active customer is. You will get: ordered in the last twelve months; has an open contract; has a non-zero balance; is not marked inactive in the CRM. All four are defensible. All four give different numbers. The meeting then reconciles the numbers instead of deciding anything, which is the most expensive possible use of the people in the room.

The fix is a definition layer that sits between the source systems and every report:

Each metric has a written description in business language, agreed with the people who use it
Each metric has exactly one query that implements that description
Each metric has a named owner who approves changes to it
Changes are versioned, so a discontinuity in a chart has an explanation attached
Every report, alert and export reads the layer instead of re-implementing the calculation

This is a governance mechanism dressed as a technical one. Its real value is that the argument about what a number means happens once, on the day the definition is written, rather than every month for the next five years.

How a badly built dashboard produces a wrong decision

A dashboard is a decision instrument, and a wrong one is worse than none because it carries authority. These are the failure modes we look for first, in your existing reporting and in anything we build.

A single total with no window to compare

The clearest case. A lifetime or year-to-date total keeps rising even while the current period collapses, because it still contains a cohort that stopped months ago. The screen looks healthy throughout a decline. The correction is to show the last 7, 30 and 90 days beside the all-time figure on the same panel, always, so a divergence between them is visible without asking.

An average hiding the distribution

Mean order value jumps because one unusually large order landed. Mean resolution time looks acceptable while a tail of cases sits open for weeks. Show the median and the count alongside the mean, and where the tail matters, show a percentile rather than an average.

A ratio whose denominator moved

Conversion improves because bot traffic was excluded from the denominator, not because anything converted better. Any ratio needs its numerator and denominator visible, and a change in either definition needs to appear as a marked discontinuity on the chart.

A partial period shown as complete

Read at nine in the morning, today's figure is a fraction of a day compared against full days. The daily panic that follows is entirely artificial. Either exclude the incomplete period or label it as incomplete on the chart.

Axis and scale tricks, usually accidental

A truncated vertical axis turns a two percent movement into a cliff. A dual axis makes two unrelated series appear correlated. Neither is usually intentional; both change what the reader concludes.

Alerts on a noisy metric

A threshold on a figure that fluctuates normally produces alerts every day, people stop reading them, and the one alert that mattered is missed. Alerts belong on metrics with a stable baseline, with a tolerance derived from the observed variation rather than from a round number.

Two more that are less visible and equally destructive. Period boundaries that disagree between systems: if “today” ends at midnight in one system and at a cut-off in another, joined figures will never reconcile and the mismatch will be blamed on the dashboard. And records that change state after the fact: an order cancelled after it was counted, an invoice credited, a lead marked as duplicate. Whether a metric counts the state at the time of the event or the current state has to be decided, written down, and applied consistently, because both are correct and only one is what you meant.

What we build, and where the figures come from

Dashboards are one layer over the operational systems, not a separate product. The work is mostly in the plumbing beneath them.

Sources. Your ERP, CRM, operational system, online channel and bank statement feeds, read through their APIs, a reporting replica, or scheduled extracts where that is all the system offers.
The definition layer. One query per metric, as described above, with owners and version history.
Role-based views. Finance looks at receivables ageing, exposure and the cash position; operations at throughput, backlog and on-time delivery; sales at pipeline and account activity. The same definitions underneath, different selections on top.
Freshness indicators. Every panel states when it was last refreshed and whether the current period is complete. A dashboard that hides its own staleness is a hazard.
Drill-down and action. From a total to the records behind it, and from a record to the screen where something can be done about it. This is the practical advantage of building the dashboard inside the operational system rather than beside it.
Alerts with tolerances. Few, on stable metrics, tuned so that an alert still means something after three months.

When this is not the right investment

Your source data is not reliable yet. A dashboard over inconsistent master data publishes the inconsistency with a chart around it. Fix the data first; it is cheaper than arguing with a screen.
Nobody has agreed what the metrics mean. If the definitions are contested, building the dashboard moves the argument rather than settling it. Write the definitions first, on paper, with the owners named.
The decision is not actually made from data. Some decisions are made on judgement and relationships, and a dashboard for them is decoration that gets checked twice and then never again.
You need free-form analyst exploration over many sources. That is what established BI platforms and a warehouse are for, and we will say so rather than rebuild them.
You want a large dashboard covering everything. Panels nobody uses are the normal outcome. Five metrics people check daily beat forty nobody trusts.

How a build starts

Name the decisions, not the charts

For each proposed panel: which decision does this change, who makes it, and how often? Panels that survive this question are worth building. In most first workshops roughly half do not survive, which is the point.
Write the metric definitions

Five to seven metrics, each with a description, an owner and the exact inclusion rules, agreed before any query is written. This is the step that is skipped and the step that decides whether anyone trusts the result.
Prototype in the first 2 weeks

Real figures from your own systems on real screens, so people can say “that number is wrong” while it is still cheap to find out why. That sentence, early, is the most valuable output of the prototype.
First dashboard in production, 2–4 weeks

At $3,000–6,000, with comparison windows, freshness indicators and drill-down. A wider reporting layer with role views, alerting and several sources is $8,000–15,000 over 4–8 weeks. The bands are on pricing.

The source code is delivered to you, the licence is perpetual with no per-user fee, and maintenance is optional at 12–25% of build cost. The systems this reporting layer usually sits on are the ones we build: Elevatora SAHA, a multi-tenant lift maintenance and field service system, Elevatora İMALAT, a manufacturing and ERP system for lift components, SEMP Group, a group-wide operations platform, SmartHukuk, our own legal technology product, and a pharmaceutical import and export process tracking system; Elevatora PROJE is in development. See cases. Where the figures are pulled from other systems, the connection layer is on integrations, and the AI layer that answers questions over the same data is on AI integration.

Frequently Asked Questions

What actually changes when a dashboard reads live system data instead of a monthly export?

Three things, and speed is the least important. First, the definition stops drifting: the figure comes from one stored query rather than from whatever filter the person who built the spreadsheet happened to apply. Second, you can drill from the total down to the individual records behind it and act on one, which a flat export cannot do. Third, access control is preserved, because the numbers stay inside the permission system instead of leaving as a file that gets forwarded. Freshness matters too, but a wrong number delivered instantly is not an improvement.

Why does every metric need a single written definition?

Because otherwise the same word means different things in different rooms. Active customer, open order, delivered on time and gross margin each have several defensible definitions, and two departments will pick different ones. The result is a meeting spent reconciling two numbers instead of deciding anything. A definition layer fixes it: each metric has one written description, one query that implements it, one owner and a change history. Reports read that layer rather than each re-implementing the calculation.

How does a badly built dashboard produce a wrong decision?

The most common way is a single cumulative total with nothing to compare it against. A lifetime figure keeps rising even while the current period collapses, so the screen looks healthy during a decline. Showing the last 7, 30 and 90 days beside the all-time figure makes the divergence visible immediately. Other frequent causes are averages that hide a skewed distribution, a ratio whose denominator definition changed silently, a partial current day shown as if it were complete, and a truncated chart axis that turns a small movement into a cliff.

Do we need a data warehouse first?

Usually not for the first dashboards. If the figures come from one or two systems and the volumes are ordinary, reading replicas or scheduled extracts are enough, and they get you a working dashboard in weeks rather than a warehouse programme in quarters. A warehouse earns its keep when you need to join many sources, keep history that the source systems overwrite, or run analysis heavy enough to disturb production. Building it before you know which questions matter tends to produce an expensive copy of data nobody queries.

When is a general BI tool the better choice?

When the audience is analysts who need to explore freely, when the questions change constantly, and when you have a warehouse and someone whose job is to model data in it. Established BI platforms are strong at that and we will say so. A custom dashboard inside your operational system fits the opposite case: a fixed set of metrics, an operational audience, drill-down to the record with an action attached, no per-seat licence, and screens that live in the same application people already use.

What does a first dashboard cost and how long does it take?

A focused dashboard covering five to seven metrics from one or two systems is $3,000–6,000 and reaches production in 2–4 weeks, with a clickable prototype in the first 2 weeks. A wider reporting layer with role-based views, alerting and several sources is $8,000–15,000 over 4–8 weeks. The source code is delivered to you, the licence is perpetual with no per-user fee, and annual maintenance is optional at 12–25% of build cost.

One definition, one query, and a window to compare it against