I build automated data systems.

Global partner reporting platform

A software channel of hundreds of tier-one partners was being tracked partner by partner in spreadsheets, rolled up manually through country and zone leadership, and reconciled by hand between the company and its partners. An earlier dashboard effort existed, but only in one region.

I took that regional concept global and expanded it substantially into a single governed, automated, externally-facing platform. I owned the dashboard experience, the business logic, the ETL workflow, the entitlement design, validation, and day-to-day operation for five years. Partners saw only their own data; internal account, country, zone, and executive users each saw their own scope — all from one product with dynamic entitlements rather than per-partner copies.

The design goal was minimal recurring manual overhead: automated daily refresh, fiscal-year rollover handled in logic, region-specific business rules built in rather than patched around. It became the primary detailed source for quarterly business reviews.

Shipping a global tool tells you nothing about whether it landed, so I built the measurement too. The richest usage data sat in an administrative database I asked for and was refused, so I worked around it — exports run through an automated process that mapped usage back to specific dashboards and sections and joined users to their geographic entitlements, producing adoption by country and by zone. The point wasn't counting views. It was diagnosing gaps: does this country know the report exists, can users find the link, is a section simply not useful in this region. Those went to zone leadership as adoption problems with causes attached.

I didn't own the upstream enterprise systems it drew from — those stayed with IT. What I owned was everything between those systems and the people making decisions.

Tableau · Alteryx · row-level security · Salesforce / SAP / Oracle sources

Customer identity across systems

I was handed a narrow ticket: fix some mismatches that were breaking someone else's dashboard. Looking at it, the mismatches weren't the problem — they were a symptom of customer identifiers disagreeing across enterprise systems, with automated processes continuously reassigning them.

That mattered because new-logo revenue is determined at the identifier level. When a customer got reallocated to a different identifier, the new-logo number moved week to week, and leadership couldn't trust a metric they were running the business on.

I built linkage logic to identify records across systems that represented the same customer, quantified how much revenue sat on affected records within about a week, and reverse-engineered the undocumented workflow across the systems involved. I pushed for the end-to-end process to be mapped — it hadn't been — and the resulting map isolated where it was actually failing. My reporting surfaced breaks at the account level rather than as summary counts, which is what made it something the technical teams could act on in batches.

I didn't own those systems or run the corrections. What I did was turn a vague complaint into a measured problem with a workable queue attached.

Learning analytics: from spreadsheets to a governed source

Partner and employee learning reporting ran on a legacy Excel process that nobody could fully explain. I reverse-engineered it, consolidated it onto a relational source, and built a reusable security framework that new dashboards could inherit instead of reimplementing. It grew to dozens of dashboards across the full curriculum portfolio on one governed source, and it's still in production years after I built it.

I also ran it as a program, not just a build: weekly status on the data and operations side, dashboard demos directly to executives, and delivery sequenced against the learning team's own curriculum roadmap. I owned the analytics workstream — the learning content and the upstream platform belonged to other teams.

The interesting problem inside it: the learning team needed to target employees for curricula by role and job function. The clean fix was audience flags in the source system; I asked, and the upstream team couldn't do it. The lazy fix was hundreds of conditional calculations hardcoded into dashboards. I did neither — I built a mapping the learning team maintains themselves in a shared spreadsheet, integrated through a prep workflow into a multi-million-row dataset. They change their own audience definitions now, without an analyst in the loop, and none of it lives in dashboard logic.

Relational modeling · Tableau + Tableau Prep · row-level security · parameter actions

Putting the reporting where people already work

A lending technology company had no BI environment at all. Reporting ran out of a legacy Access process, and anyone who needed a number had to go somewhere other than where they actually worked to find it.

I stood up the company's first Tableau environment and embedded the reporting directly into the Salesforce interface, so the numbers lived inside the system people were already in rather than in a separate tool they had to remember to open. I taught myself SQL to build it.

The instinct that stuck: adoption is a placement problem before it's a design problem. A good dashboard nobody navigates to is a dashboard nobody uses — which I ended up proving again years later, measuring a global platform and finding that most of the gaps were about whether people could find the thing at all.

Tableau · embedded analytics in Salesforce · SQL, self-taught · migration off a legacy Access process

Network design: how many distribution centers, and where

A retail network design case — a national retailer, 55,799 SKUs, three years of forecast demand, and up to six candidate distribution centers. The question was how many sites to operate and which ones, trading the fixed cost of opening a facility against the per-unit cost of running it and the transport cost, which climbs with the distance between a site and the customer. That last term is why the answer moves with where the customers actually are.

We cut the long tail of SKUs first, keeping the products that cumulatively carried 95% of demand, then built the baseline the business was really operating: every customer served from its nearest site, no capacity limits. That gives you the number to beat and the throughput each facility is actually carrying.

Then we added capacity constraints, and the interesting failure appeared. Assigning greedily by lowest cost filled 92.6% of demand by volume while leaving 98.6% of customers with an incomplete order — cheapest-first spreads supply thinly across everyone rather than completing orders for anyone. The fix isn't a better solver, it's a different objective: fill-rate floors, tiering to protect key accounts, regional balancing. A single objective function optimizes exactly what you tell it to and quietly wrecks whatever you forgot to measure.

Python · pandas · network design · demand segmentation · capacity-constrained allocation · scenario analysis