The Operations Bridge

This is Post 2 of the five-part series From Data to Decisions: The “What, So What, Now What” Series. Last time I explained why a production report wasn’t enough, and why I turned to Power BI—and to AI—to get real insight from it. This post covers the first layer of the framework.

The first question sounds easy

What happened?

At first glance, this is the simplest layer of operational analysis. A line ran. A process stopped. Output finished above or below expectation. A transition took longer than planned. A quality measurement moved.

Surely the data can tell us what happened.

Sometimes it can. Sometimes it tells us what was entered, how the system categorized it, or what the calculation was instructed to count. Those are not always the same thing.

That is why the “What” layer deserves more respect than it usually receives.

Data is a representation of the operation

A production system does not observe reality in the way a person standing on the floor does. It records events according to rules.

A status begins when someone changes it. A downtime category reflects the option selected. A performance measure depends on an established target. A time calculation depends on where the clock starts and stops. A rate depends on which units are included and how different products or formats are normalized.

Every metric contains a definition, whether that definition is visible or hidden.

When I began developing operational reporting in Power BI, one of the first lessons was that a clean visual can create a false sense of certainty. A chart may be mathematically correct and still misrepresent the process because the underlying business definition is incomplete.

For example, “production time” sounds straightforward. But does it include the period immediately after a changeover? What happens when equipment is running but has not yet reached a stable rate? How are planned interruptions separated from unexpected ones? If a status is changed late, does the system record the event or the entry?

These questions are not technical details. They determine what the organization believes happened.

Define the fact before designing the visual

The temptation in Power BI is to begin with the dashboard: choose a chart, add a measure, select colors, and create a layout.

The better starting point is a metric definition.

For every important measure, the team should be able to answer:

• What business question does this measure answer?
• What is included?
• What is excluded?
• What starts and stops the calculation?
• What is the comparison point or target?
• At what level should the result be evaluated?
• Who owns the accuracy of the underlying entries?

If those questions do not have clear answers, the dashboard may accelerate confusion rather than understanding.

This was one of the places where working with AI became valuable. ChatGPT could help me write a DAX measure, but it could not independently decide what our operation meant by a successful ramp-up, a productive hour, or a meaningful loss category. I had to translate operating reality into explicit logic.

The act of teaching the logic to AI forced me to clarify it for myself.

Trust is built through reconciliation

A new dashboard should not be trusted merely because it looks professional. Trust is earned by comparing it with known events and asking people closest to the process whether the story is accurate.

That means selecting examples the team remembers and tracing them through the data:

• Does the recorded timeline match what occurred?
• Do totals reconcile with the source report?
• Are categories behaving as intended?
• Can the team explain apparent exceptions?
• Does filtering preserve the meaning of the measure?

This is not a one-time technical validation. It is a conversation between the data and the people who operate the process.

When employees challenge a dashboard, that is not necessarily resistance. They may be identifying a gap between the system’s representation and the real work. Leaders should investigate that gap instead of defending the visual.

“What” is necessary—but not sufficient

Once the organization trusts the facts, the dashboard can answer useful questions quickly:

• What changed?
• When did it change?
• Where was the loss concentrated?
• How frequently did it occur?
• Which categories contributed most?

This is a major improvement over manually reconstructing the day. It gives the team a common starting point and reduces debate about whose spreadsheet is correct.

But a trustworthy fact is still only a fact.

Knowing that performance declined does not tell us whether the change is meaningful, what conditions produced it, or whether intervention is necessary. Knowing that one category increased does not prove it caused the overall result.

The “What” creates visibility. It does not automatically create understanding.

A question for leaders

Choose one metric that appears in a report your organization relies upon.

Could the people reviewing it clearly explain its definition, inclusions, exclusions, timing rules, and intended use?

If not, the next improvement may not be a more sophisticated dashboard. It may be a better definition.

In the next post, we will move from fact to meaning and ask the question that gives analysis its value: So what?