Case Study · 3D Systems · Oracle 11 → R12 · 2016–2019
Upgrading the system I'd run $33M through
How I got the role
I didn't get assigned this. I got picked for it, and the criterion was usage.
As a buyer/planner I ran more than $33M in purchase orders through Oracle — blanket agreements, MRP-driven requisitions, the daily mechanics of keeping a production line supplied. Somewhere in there I stopped being someone who operated the system and became the person who understood what it was actually doing underneath. When the upgrade came, that's why I was named Procurement's lead: I had shown the most capable use of the thing we were about to rebuild.
Usage, not seniority: the path from heaviest user of the system to lead of its rebuild.
The upgrade
Oracle 11 to R12 for Procurement — an upgrade with a well-worn path, which is exactly why the interesting decisions were the ones that departed from it.
The first was staffing. Rather than route the work through a consultancy, we brought in a team from Oracle directly. Consultancies deliver an implementation; the product team explains why the system behaves the way it does. That distinction paid off well past go-live — the working knowledge we picked up about how R12 actually handled procurement data is what made everything I built afterward possible.
The second was testing volume. I ran an exhaustive test cycle against real procurement scenarios, because the failure mode here isn't a bad report — it's a production line that stops because a requisition didn't convert. We went live without missing a beat. No production impact, no scramble, no post-go-live firefight.
Making it stick
The part I'd argue mattered most came after go-live. I documented my own method for processing requisitions from MRP into purchase orders, and it was adopted as the team's standard work.
That's the difference between an upgrade and a change. The system going live only moves the technology; codifying how the work gets done on top of it is what moves the team. And having the process owner be the person who'd run the highest volume through the old system meant the standard reflected what actually worked, not what the manual said.
The foundation it became
Framed narrowly, this was a classic ERP upgrade. Framed honestly, it was the platform everything else at that site ran on for the next three years.
The upgrade as platform — three years of dashboards and analytics ran on R12 data.
The 52-week MRP dashboard and the procurement analytics suite — including the supplier on-time-delivery reporting required for the site's ISO 9001 certification — were built directly on R12 data, using pulls I wrote against the reporting layer. None of that was possible without knowing the platform at the level the upgrade taught me.
Seeing the system where it lands
I ran this from the manufacturing site, with regular trips to headquarters. That mattered more than it sounds. I watched the system evolve alongside the production line, the warehouse, and the outbound order crew it was supposed to serve — which meant configuration questions got answered against what actually happens on a floor, not against a process diagram.
Most ERP disappointments trace back to that gap. Being physically present on both sides of it is a large part of why this one landed.
The second deployment
Years later I led the US Procurement workstream for a greenfield SAP S/4HANA deployment at Canopy Growth — same posture, considerably larger stakes. That one turned into a multi-tier subcontract architecture with batch genealogy under federal oversight, and it has its own case study.
A third platform followed at BioSteel, where I ran the selection process that landed on NetSuite.
Why it matters
This isn't the boldest thing on this site, and I won't pretend otherwise. What it is: the underpinning. Three ERP platforms across three companies, and in each case the same pattern — learn the system deeply enough to be trusted with it, deliver without breaking the operation, then build the thing the system was supposed to make possible in the first place.
Cost models and AI workflows are the visible work now. This is where the fluency came from.