The problem was never the data. It was visibility.

In 2019, a fire hit a major additive supplier in Rouen, France. Shortly after, Covid-19 produced the highest volume of supply disruptions Shell had seen, including additive shortages that affected several plants and customer accounts at once. Both exposed the same gap: when something broke upstream, nobody could quickly see what it touched downstream.

Tracing a disruption meant phone calls to plants, emails to sales teams, separate Excel trackers and desktop apps that didn't talk to each other, reassembling the same picture by hand every time.

The Product Owner framed the brief as "we need better visibility." That was accurate. The design question was what kind of visibility, surfaced how fast, and suppressing what.

The bottleneck was never any single system. It was the manual work of joining them: tracing one disruption by hand across five domains. By the time the picture was assembled, it was out of date, and teams were managing fallout instead of cause.

Earning the mandate

The vision came from the Product Owner I worked with. Getting it built meant making the business case first: explaining why this mattered enough to commit engineering effort. The project then moved through an MVP, into a second stage for production use where impact was measured, and kept expanding, with architecture and information architecture rebuilt as new requirements came in.

Power BI is a reporting tool, not an operations console, and the platform choice was non-negotiable. Shell had invested in it and its teams trusted it. So the job became getting operations-console behaviour out of a reporting platform, honestly, using what Power BI and the Azure stack could actually do.

I started with Shell's own design system: established components, institutional trust, a visual language the organisation knew. When those designs went into Power BI, the platform couldn't reproduce them.

So I stopped trying to make Power BI approximate the ideal and asked what it does well. I explored other visualisation patterns for the dependency chain, then designed deliberately for what it could render under real-time conditions: bar graphs, line charts and diagram-style chain views. A custom build outside Power BI would have broken the DirectQuery pipeline the whole design depended on.

The handoff went to data architects and Power BI developers, not front-end engineers, so the deliverable was closer to a definition of measures, thresholds and conditional logic than to a redline.

I didn't calculate it. Shell's business team produced the figure through its own value-tracking process, which is how benefit is attributed on engagements like this: the delivery team builds, the business quantifies. It was reported for the Americas once the tool reached production.

The mechanism is simpler than the number looks. Collapsing days-to-weeks of manual assembly into about ten minutes means disruptions are caught while they're still commercially recoverable, and removing the manual work is where the 3,000+ hours a year come from. Hours saved is the number I'd defend hardest, because it's directly observable.

I spent the first weeks quietly resenting Power BI. Every concept I liked ran into something the platform wouldn't do on its own. What changed my mind was noticing that the limitation and the adoption were the same fact: a new tool would have meant procurement, training, and a reason for a planner mid-crisis to open something unfamiliar.

If I did it again, I'd make the case for the tool's broader expansion earlier. And I'd point to this as the difference from a well-run delivery: nobody handed me a fully scoped brief. Turning a vision into funded, shipped work meant earning the mandate at each stage, from MVP to production to expansion.