Summary
Roche Global Procurement was running decisions on an analytics estate that had grown by accretion. SAP BW/HANA at the core, Alteryx in the middle, and a thick layer of manual Excel at the edges. Every team could produce a number. Few of the numbers agreed. I lead the end-to-end transformation to move this estate toward a governed platform on Snowflake and dbt, where the data model, the metric definitions, and the ownership are explicit.
What was fragmented
The same metric was calculated in several places, each with its own logic, none of it documented in one place. Refreshes depended on individuals running Alteryx flows and stitching the output together in spreadsheets. When the numbers were questioned, and they were questioned often, there was no single model to point to. The estate worked, until a reorganization, a departure, or a hard question exposed how fragile it was.
Why it mattered
Procurement decisions at this scale move real money. Spend visibility, supplier performance, and savings tracking were all downstream of data that leaders did not fully trust. The cost was not only the analyst hours lost to manual reconciliation. It was slower decisions and a quiet discount applied to every number, because no one was sure it would hold up under scrutiny.
My mandate
Own the analytics transformation end to end: scope, timeline, governance, and stakeholder alignment across Business, IT, and Finance. Move Roche Global Procurement from a fragmented legacy estate to a governed Snowflake and dbt platform, and deliver data products that retire the manual Excel and Alteryx workflows rather than wrapping a new tool around them.
Current-state diagnosis
Before designing anything, I mapped how data actually flowed against how people believed it flowed. The gap was the project. Critical logic lived inside Alteryx canvases and individual spreadsheets, not in a modeled layer. Ownership was implicit. The first deliverable was not a pipeline. It was a clear picture of which metrics mattered, who depended on them, and where each definition actually came from.
Target model
A governed platform with three things the legacy estate never had. One modeled source of truth in Snowflake. Transformation logic versioned and tested in dbt. Metric definitions that are written down and owned. Data products replace reports, with a defined consumer and a defined decision behind each one.
Governance design
The platform is only half the work. The other half is the operating model around it. Clear ownership for each data product and each metric definition. A documented semantic layer, so the meaning of a number does not depend on who built the query. Change control, so definitions evolve deliberately instead of drifting. Governance that Business, IT, and Finance all recognize as theirs.
Migration approach
Modernization here is not a big-bang cutover. It is reverse-engineering the logic buried in the legacy estate, proving parity against the numbers people already rely on, and migrating in waves so the function keeps running throughout. Trust is earned wave by wave, by showing the new model matches the old one before the old one is retired.
Where it stands
The transformation is active and the direction is set. Work packages are approved and in progress, with the first sprint completed on June 26, 2026. The current work is scope, governance, ownership, metric definition, migration sequencing, and validation toward a governed Snowflake and dbt platform. Manual Excel and Alteryx workflows are on a path to retirement, but measured outcomes are not claimed here until confirmed.
Lesson
A reporting problem at this scale is rarely a tooling problem. The legacy estate was not failing because SAP BW/HANA was old. It was failing because the logic, the ownership, and the definitions had never been made explicit. The platform matters. The governance around it is what makes the platform worth trusting.
Summary
This is a global data transformation program inside procurement: multiple stakeholder groups, legacy technology, unclear ownership, and high trust requirements. My role is to turn that ambiguity into a sequenced program with scope, milestones, risks, decisions, governance cadence, and executive visibility.
What I owned
I built the program-management backbone: intake, prioritization, roadmap planning, RAID, decision logs, milestone tracking, change control, and leadership readouts across Business, IT, Finance, governance, analytics, BI, and platform teams.
How I worked
The work is not a simple platform migration. I translate technical blockers and ownership gaps into decisions leaders can make: sequence the work, assign owners, accept risk, descope, or staff the gap. That keeps hidden transition risk from accumulating below the surface.
Proof
The transformation has approved, in-progress work packages, clearer scope, delivery standards, governance routines, and visible risks. Manual Excel and Alteryx workflows are being moved toward governed delivery instead of being wrapped by another reporting layer.
Lesson
A data-platform migration fails when the program layer is weak. The hard part is not only moving logic to Snowflake and dbt. It is making ownership, validation, release control, and decisions explicit enough for the organization to trust the new system.
Summary
Seen as product work, this transformation turns fragmented procurement reporting into reusable data products. The goal is not more dashboards. The goal is certified spend and savings data products with clear users, definitions, validation, ownership, and adoption paths.
Product problem
Procurement teams had many outputs but few product boundaries. Reports, extracts, Excel logic, Alteryx flows, and dashboard requests were mixed together. I separated true data-product needs from reporting noise, source-system defects, enrichment work, BI consumption, and manual exceptions.
What I defined
For each priority output, I push for a product standard: decision need, consumer group, metric definition, owner, validation path, release criteria, documentation, support model, and downstream consumption pattern.
Proof
The operating model shifts the roadmap from ad hoc reporting demand toward governed spend and savings data products. It defines how business, finance, IT, and analytics teams can consume certified logic instead of recreating parallel interpretations.
Lesson
A data product is not a table, dashboard, or pipeline. It is a governed promise to a consumer. Until the owner, definition, validation path, support model, and decision use are clear, the organization still has reporting inventory.
Summary
This is also a process-control transformation. The legacy estate depended on undocumented logic, manual Excel and Alteryx work, shared accounts, informal fixes, and person-specific knowledge. My work is to make the critical process visible, controlled, and repeatable.
What was broken
The same metric could be calculated in several places, refreshed by different people, and corrected through manual steps no one fully owned. That created reconciliation effort, audit exposure, and a dependency on individuals who knew where the logic was buried.
What I changed
I established the control language around the work: metric definitions, lineage, data-quality checks, dual-run validation, change control, release gates, documented ownership, and clearer boundaries between source correction, enrichment, curation, reporting, and support.
Proof
The transformation is designed to reduce operational fragility by replacing hero-based reporting with governed routines. The measure of progress is not a prettier output. It is fewer black-box dependencies and a more defensible path from source data to decision.
Lesson
Process discipline matters as much as tooling. If ownership, validation, and change control are weak, a modern stack can reproduce the same fragility faster.
Summary
From the data and analytics angle, this is a migration from SAP BW/HANA, OPERA, Alteryx, Excel, and fragmented BI workflows into a governed Snowflake and dbt model with stronger engineering controls.
What I am building toward
The target state is a modeled data foundation with versioned transformation logic, CI/CD, DEV/TEST/PROD promotion, metric definitions, lineage, data-quality checks, and release criteria for certified procurement data products.
How I framed the work
Before pipelines, I mapped how data actually flowed against how people believed it flowed. The useful technical design starts where those two pictures diverge: undocumented logic, spreadsheet corrections, unclear ownership, and multiple versions of the same metric.
Proof
The adopted platform direction is Snowflake + dbt with governance and validation around the transformation layer, so downstream BI and business teams can consume trusted logic without parallel reconciliation.
Lesson
AI-ready analytics starts with deterministic definitions. If the data product, owner, validation path, and business rule are not clear, advanced analytics and AI will only accelerate confusion.
Summary
This transformation requires people leadership because the team is changing how it works, not just what technology it uses. Legacy domain experts, BI engineers, data engineers, data stewards, business users, IT, and finance all need clearer roles and expectations.
What I managed
I lead hiring, onboarding, role redesign, capability uplift, and transition planning while protecting engineering capacity from unmanaged intake and reactive stakeholder pressure.
How I coached the change
The shift from person-dependent reporting to production-grade data enablement is uncomfortable. I translate leadership urgency into priorities, sequence, standards, and coaching so the team can change without being buried by noise.
Proof
Three data engineers were hired/secured in the first 90 days, with two started by late June 2026 and one scheduled for September 2026. The function is also moving toward clearer ownership, delivery standards, support boundaries, and data-product expectations across legacy experts and modern data roles.
Lesson
A data transformation sticks only when the team can operate the new model. Capability building, role clarity, and psychological safety with standards are part of the delivery system.