An in-progress portfolio piece where I'm rebuilding operational reporting around event logs — so a dashboard can tell me where work waited, not just what totals hit.

Tech: SQL Server (SSMS) · Power BI · Deneb (Vega-Lite) · DAX · MCP (Filesystem + Git + Power BI Modeling) · Claude

Dataset: Microsoft Wide World Importers (WWI) — OLTP + DW sample

Status: Work in progress. SQL layer and semantic model are in; storytelling pages are the active block of work. Screenshots coming once the Control Tower page is presentable.

Why I'm building this

Most operational reporting I've seen — in healthcare, in ops, in every BI deck that crosses my desk — stops at totals, averages, and a trend line. It answers what happened: 1,423 orders shipped this week, average cycle time 3.2 days, on-time rate 87%. Fine. But it doesn't answer the question anyone running the operation actually cares about:

Where did the work wait, and why?

That question is different in shape. It's about the path each case takes, not the aggregate. It's about the gaps between events — the time a chart sat in a queue, the hours a package sat on a dock, the days a referral sat in a triage pile. Averages hide all of it. A median hides most of it. Even a distribution chart hides it unless you've already modeled the data as a sequence of events per case.

I work in healthcare (cancer-system intelligence), and this is the gap I keep bumping into. Performance reporting is summary-heavy. Throughput numbers, wait-time averages, volumes by month. It's all correct and none of it helps you actually fix throughput, because fixing throughput requires knowing which step in the patient journey is the bottleneck on a given week, for a given cohort, under given constraints. That's journey thinking. That's event-log thinking. And it's almost never how the underlying data is modeled.

So this project is me, on my own time, on a public dataset, building the thing I wish existed at work: a Power BI report whose foundation is an event log, whose measures are written with percentile and cycle-time semantics, and whose pages read like a story — Control Tower → Bottleneck Finder → Journey Explorer → Root Cause Lab → Show Your Work — rather than a grid of KPI cards.

It's also me proving to myself that the skills transfer. If I can make the order-fulfillment process in Wide World Importers legible as a journey, I can do the same for ED throughput, surgical scheduling, and oncology pathway timing. The data model is the same shape. The metrics are the same shape. The dashboards are the same shape. Only the domain changes.

Why Wide World Importers

Picking a dataset for a portfolio project is half the battle. I wanted something:

• Public, so anyone can reproduce it without an NDA.
• Large enough to be interesting but small enough to run on my laptop in SQL Server Express.
• Operational, meaning it has a real process (order → pick → pack → ship → deliver) with real timestamps per step.
• Both OLTP and DW, so I can decide which layer to build from and show that decision explicitly.
• Well-documented by Microsoft, so I'm not fighting the dataset.

Wide World Importers (WWI) hits all of those. Microsoft ships two companion databases — WideWorldImporters (OLTP) and WideWorldImportersDW (data warehouse) — both distributed as BACPAC files on GitHub. The OLTP side has Sales.Orders, Sales.Invoices, Warehouse.StockItems, Warehouse.PackageTypes, picking/packing timestamps, delivery confirmations. It's a working small-business fulfillment system. The DW side is the same business pre-modeled as a star schema.