Beyond Power BI: What Native Quality Dashboards Actually Look Like

The export is the bug

Here is the standard pattern for putting quality data in front of leadership. The QMS holds the records — nonconformances, CAPAs, inspection results, supplier scores. A data pipeline exports those tables on a schedule. A modeling layer reshapes them into a star schema. Power BI loads the model, someone writes DAX measures, and a dashboard renders. Four systems, three copies of the data, two teams, and one refresh cadence that runs at 6am and is wrong by 9.

Every one of those hops is a place for the numbers to drift from reality. A nonconformance reopened at 8:15 does not show up until tomorrow's pull. A supplier gets re-rated and the dashboard keeps quoting last week. None of this is a Power BI defect — it is a presentation layer doing exactly what it is designed to do, which is show what someone already modeled. The problem is the distance between the chart and the record. We think that distance is the whole ballgame.

Our strong opinion, stated plainly: a quality dashboard disconnected from the system of record is one schema change from being confidently wrong. The day someone renames a status field or splits a category, the export still runs, the model still loads, the chart still renders — green, precise, and quietly detached from the truth. Nobody gets an error. That is the dangerous part.

What "native" actually means

When we say a dashboard is native to the quality system, we mean the chart and the record live in the same place, on the same data, with no copy in between. In Kanso the dashboards read the live quality tables directly. There is no export step because there is nothing to export to — the analytics engine and the QMS are the same application, over the same Postgres database, behind the same row-level security.

That has a concrete consequence you can feel in a meeting. When a chart looks wrong, you click the bar and drill into the underlying dataset — the actual nonconformances behind the number, not a summarized extract. You are looking at rows you could open, edit, and act on. The dashboard is a lens on the records, not a photograph of them taken at dawn.

It also means permissions are not re-implemented. In the export model, someone has to rebuild access rules in the BI tool so the plant manager in Ohio does not see the Munich line. Miss a rule and you have a data-governance incident. When the dashboard reads through the same row-level security as the records, a person sees in a chart exactly what they are allowed to see in the system — one set of rules, defined once.

The dashboards themselves

None of the above matters if the visualization layer is thin, so it is not. Kanso ships 19 native chart types — the run charts, Pareto, box plots, and control charts that quality work actually needs, not just the bar-and-donut starter kit. Cross-filter is built in: click a supplier on one widget and every other widget on the board re-scopes to that supplier. Drill-down goes the other way, from a category into the next dimension down, then into the raw rows.

Filters work at three levels — global to the whole board, local to one widget, and cross-filter fired by a click — so one dashboard answers a dozen questions instead of one. When the answer needs to travel, there is scheduled email delivery: pick a cadence, and the report computes on the server and lands in inboxes with a deep link back into the live board. The recipient who wants to dig gets a real door, not a flat PDF.

The datasets underneath are modeled once, on write. You define the transform — the joins, the derived fields, the refresh cadence — and every widget built on that dataset inherits it. This is the same modeling discipline a BI team applies in a separate tool, except it lives next to the records and the notebooks, so the definition of "on-time CAPA" is written in one place and cannot fork.

Where the chart runs out of road

Every dashboard tool hits a ceiling, and for quality data the ceiling is close. A dashboard can tell you the mean shifted. It cannot run a capability study, fit a distribution, test whether two suppliers differ at a level you would defend to an auditor, or build a model that predicts which lots will fail. That work needs real statistics, and in most stacks it means the data leaves the tool — exported again, into someone's laptop copy of a notebook, disconnected from the records and from everyone else.

This is the gap that a BI-only approach cannot close, because presentation layers are not built to compute. DAX is a measure language, not a statistics engine. The moment a quality engineer needs a Gage R&R, a Cp/Cpk gated on a normality check, or a regression, they are out of Power BI and into Minitab or Excel, and the analysis lives nowhere the team can find it next quarter.

Kanso keeps that work in the building. Power mode drops you into SQL against the same live tables the dashboards read. Python and R notebooks sit in a Data Lab beside the dashboards, on the same data, so a capability study and the chart that summarizes it are one click apart and share a source. When a chart is not enough, you do not leave — you go deeper in the same place, and the deeper analysis stays with the records instead of walking out the door on a USB stick.

Live data from the systems that hold it

Quality data does not all originate in the QMS. Receiving inspection, returns, cost of poor quality, and supplier spend often live in the ERP. Kanso's connectors pull live from Microsoft Business Central and Dynamics, so the dashboard that shows scrap cost against nonconformances is reading both systems without a nightly batch stitching them together in a warehouse first.

That matters because the most useful quality questions are cross-system. What did this defect class cost us in returns? Which supplier's late deliveries correlate with our line stoppages? Answering those in the export model means building a warehouse, aligning two schemas, and maintaining the pipeline forever. Reading the sources live means the correlation is a query, not a project.

Keep Power BI where it belongs

We are not telling anyone to rip out Power BI. For company-wide BI — finance rolling up across entities, sales pipeline, the executive scorecard that spans every function — Power BI is a sensible standard, the org already has the licenses, and the whole point is to blend many sources into one presentation layer. Keep it. That is the job it is good at.

The argument is narrower and, we think, harder to dodge. For quality data specifically, wrapping a general BI tool around your QMS buys you a chart and costs you the connection to the record, the depth past the chart, and a live line to the systems that hold the rest of the data. You get the last mile and pay for the whole pipeline. A native quality analytics layer collapses the pipeline: the records, the dashboards, and the SQL, Python, and R all sit on the same live data, governed once.

The test we would apply is simple. When a number on your quality dashboard looks wrong, how many systems and how many people stand between you and the row that produced it? If the answer is more than zero, you are not looking at your quality data. You are looking at a copy of it, and the copy is only ever as current as the last refresh. Kanso is built by eClips (eclips.tech) to make that answer zero.