The brief was clear enough. A provincial electric utility wanted timely, trustworthy information about what it buys, so that operational and strategic purchasing decisions could rest on data instead of on whoever had the freshest spreadsheet. The supply chain group already had reports. Dozens of them. The problem was that nobody could say which report answered which question, which one was current, or what a given column actually meant when it came out of the SAP warehouse.
That last point is the whole story.
Start with the gaps, all three kinds
Before designing anything, I ran workshops with the supply chain leads and subject matter experts to document how they used data today and where it hurt. The pain points sorted cleanly into people, process, and technology, and the split mattered more than the list.
People: analysts had learned the warehouse by folklore. When one of them left, the meaning of a field left with them. Process: there was no owner for a report once it shipped, so duplicates multiplied and nobody retired anything. Technology: the warehouse could answer the questions; the tooling in front of it could not explain itself.
I presented those gaps to supply chain leadership with a recommendation for the program’s next phases, and the recommendation was deliberately unglamorous: fix the explanation problem before building more dashboards.
Governance that a sustainment manager would actually run
Working with sustainment managers and the functional leads, we defined an integrated reporting and data management governance model. The test for every rule in it was whether a named role would still be doing this in two years without a consultant in the room. Report ownership, retirement criteria, and a path for requesting changes all had to survive that test. With the SAP technical experts, we added a framework for prioritizing requirements and assessing candidate solutions, so the backlog stopped being a popularity contest.
The unexpected hero: a dashboard about the dashboards
The piece that changed adoption was a Power BI dashboard that integrated two things the organization already had but had never joined: the reporting catalogue and the SAP Business Warehouse data dictionary. Pick a report and you see the fields it uses. Pick a field and you see its definition, its source, and every report that depends on it.
That is not a supply chain metric. It is data literacy delivered as a tool, and it removed the single biggest reason people distrusted the numbers: they had never been able to check what the numbers were made of.
Then the dashboards
With definitions settled, the four supply chain and finance dashboards went quickly. I facilitated the design sessions and wrote the functional specifications, one set tailored to executives, one to managers, one to operational staff, each showing the same truth at a different altitude. Alongside them, the functional experts and I defined business logic for exception reports that surface data quality issues instead of hiding them under averages.
User acceptance testing was done live, with the experts reconciling supply chain metrics against their own numbers in the room. Where the figures disagreed, we traced it, and more than once the trace ended at a data quality problem the exception reports had already flagged. That is the moment a dashboard earns trust: when it tells you something inconvenient and turns out to be right.
What I took from it
Every organization that asks for a dashboard is really asking for confidence. Confidence comes from being able to see how a number was made. Ship the dictionary first, or ship it alongside, and the charts get used. Ship the charts alone and you have built another spreadsheet with better colours.