Supply Chain Scorecard Insights

Context

DC supervisors could see that something was wrong. They couldn't see why.

Lowe's Supply Chain Scorecard answered one question well: how are we performing? For leadership review, that's enough. For DC supervisors managing shifts, departments, and individual employees across complex distribution environments, it was the wrong question entirely. They needed to move through data — from building to department to the exact driver causing the problem. The existing system had no model for that.

System Failure

The tool wasn't broken. It was solving the wrong cognitive task.

Monitoring and diagnosis look like the same problem. They aren't. Monitoring tells you something is off. Diagnosis tells you where to look. The Summary template — KPI cards, a trend line, a data table — was built for one.

Before designing anything, I mapped the decisions supervisors were actually trying to make. Not what data they wanted to see, but what questions they needed to answer and in what sequence. That mapping revealed the real gap: the system had no model for investigation at all.

The Reframe

Product asked for a new report. I reframed the request as an information architecture problem.

One page for Off Standard hours. That was the ask. We didn't build that.

What supervisors needed wasn't a new page — it was a navigational logic that followed how an investigation actually works: start broad, move to specifics, ask different questions at each level. A supervisor investigating Off Standard hours doesn't want a static view. They want to start at the building level, pivot to department, drill into a specific jobcode, and land on an individual employee or shift. The relevant question and the relevant data change at each level.

I reframed the request from "build a report" to "design the information architecture that makes this class of problem solvable." That reframe changed the scope of everything downstream.

Process & Key Decisions

The ideal solution couldn't be built. That constraint made the thinking more rigorous.

The right solution was a graph view: a visualization that could represent multi-dimensional data and let users navigate across relationships fluidly. Competitive analysis confirmed it. Engineering couldn't build it.

Most teams retreat here. We went deeper.

If the graph wasn't executable, the underlying decision model still had to be correct. I mapped every variable: what dimensions supervisors pivot across, what questions each level answers, what information matters at Level 2 versus Level 4. That mapping produced a five-level hierarchy — building area, department, category, driver, insight — where each level had a primary user and a primary question.

The navigation came directly from that structure. Each node wasn't a menu item someone designed. It was a question a supervisor needed to ask, encoded as architecture. The constraint didn't force simplification. It forced precision.

Outcomes & Impact

One template request became the structural model for how Lowe's does diagnostic reporting.

Engineering built the first Insights page from the template. The second took half the time. The pattern extended beyond supply chain — other domains picked it up without a formal rollout.

Before this work, every new supply chain report page was scoped from scratch. After, the first question became "which type of problem are we solving?" — Summary or Insights. That shift in how the team reasoned about new pages is the second-order impact.

Reflection

The constraint didn't limit the solution. It improved it.

The graph view would have been more expressive. The hierarchical drill-down was more executable — and because the constraint forced a precise mapping of the decision tree, more structurally rigorous than the original concept. That's not a consolation. It's the lesson.

The timeline push — advocating for three additional months when the work was scoped for one — was the highest-leverage decision on this project. The ROI on that call is measurable in every page built on the template since.

If I'd instrument anything differently: I'd track how supervisors navigate the drill-down hierarchy in practice. Not just whether they find the answer, but whether the question sequence the system encodes matches the investigative logic they actually use. The architecture is grounded in discovery. It deserves the same rigor at validation.