The Operations Bridge

Welcome to a five-part series I’m calling From Data to Decisions: The “What, So What, Now What” Series. It’s the first AI-adjacent writing I’ve done on this blog, and it grew out of a very ordinary leadership problem.

I was not looking for a technology project

The project did not begin with a desire to learn a new piece of software. It began with a familiar leadership problem: I had a report, but I still had questions.

Like many operational reports, our daily production report contained useful information. It showed activity, output, time, and performance. It helped establish a record of what had occurred. But reviewing a report and understanding an operation are not the same thing.

The report could tell me that performance changed. It did not always make it easy to see what drove the change, where the loss originated, whether it was an isolated event or part of a pattern, and which issue deserved attention first.

I did not need more numbers. I needed more insight from the numbers we already had.

That distinction became the starting point for my Power BI journey.

The problem behind the report

Static reports are valuable, but they tend to answer the questions they were designed to answer. Operational leaders rarely get to stay inside those boundaries.

One answer usually creates three more questions:

• Was the result driven by production performance, planned activity, or an unexpected interruption?
• Did the operation struggle throughout the run, or only during a specific period?
• Was the loss concentrated in one category, spread across several causes, or connected to the transition into production?
• Is this a new problem or a recurring one?
• What should the team do differently because of what we learned?

Answering those questions manually often means moving between spreadsheets, filtering rows, performing calculations, comparing time periods, and reconstructing the story after the fact. By the time the analysis is complete, the organization may already be dealing with the next issue.

I wanted a visual management system that made the operational story easier to see. I wanted leaders and supervisors to move from reviewing a report to exploring the conditions behind it.

Power BI appeared to be the right tool. There was only one problem: I did not know how to use it.

Turning to AI—but not for a finished answer

I did not know how to build the data model I needed. I did not know how to write DAX measures. I did not know which calculations should be measures, which transformations belonged earlier in the process, or why a visual sometimes produced a result that looked correct but was logically wrong.

So I turned to ChatGPT.

My purpose was not to have AI build a dashboard that I could present as my own work. I wanted it to teach me how to develop in Power BI while I worked on a real operational problem.

That choice changed the nature of the experience.

When a measure failed, I had to explain what I expected it to do. When the output was wrong, I had to describe the business logic more precisely. When AI suggested a formula, I had to test it against the operation. When the calculation worked technically but failed operationally, I had to challenge the assumptions behind it.

The process became a collaboration between two different kinds of knowledge:

• AI contributed technical patterns, explanations, syntax, and troubleshooting support.
• I contributed process knowledge, operating definitions, context, constraints, and judgment.

Neither was sufficient alone.

The deeper lesson

Before this project, it was easy to think of AI primarily as a conversational tool: ask a question, receive an answer.

Developing with AI revealed something much more important. The quality of the result depended on my ability to define the problem, supply the right context, recognize weak assumptions, test the output, and refine the request.

AI did not remove the need to think. It increased the value of thinking clearly.

The dashboard was the visible result, but the more important development was learning how to work with AI as a tutor and technical partner. I was not merely consuming an answer. I was building a capability.

That experience eventually led me to a simple framework for evaluating analytics and AI initiatives:

1. What? What happened? What do the facts show?
2. So what? Why does it matter? What does it mean in context?
3. Now what? What decision or action should follow?

Most reports are built to answer the first question. Some analytical tools help with the second. The real value appears when leaders and teams can confidently reach the third.

This five-part series is about that journey—from data to understanding, and from understanding to action.

A question for leaders

Look at the reports your team reviews every day or every week.

Do they help you understand the operation, or do they simply document it?

In the next post, I will explore the first layer of the framework: What? It sounds simple, but establishing a trustworthy version of what happened is often the hardest part.