Andrew Veal
← All case studies

Case Study · Canopy Growth · SAP S/4HANA · 2019–2020

The subcontract chain hiding inside an SAP deployment

DRAFT — core write-up complete; final narrative being refined.
RoleUS Procurement lead, greenfield deployment
Company~100 people, four months old
BecameManager of the operation it supported

The bet

I joined to deploy SAP S/4HANA from the ground up for a US operating company that was roughly four months old and about a hundred people. That's an unusual thing to do at that size — enterprise ERP is normally what you graduate into, not what you start with.

The parent company was making a deliberate bet: stand up real enterprise systems at the beginning, and you get infrastructure that can absorb growth instead of being replaced by it — and you make the eventual merge into the parent company far cleaner. Greenfield, no legacy to migrate, but also no existing process to copy. I was the US procurement lead.

The job I was hired for, and the problem that showed up

On paper the assignment was configuring procurement: purchase orders, approvals, the standard build. Within weeks it became something else entirely.

The operating model turned out to depend on subcontract manufacturing — and not one clean hand-off. Procurement would own several key BOM items at several different stages of production. We'd issue standard purchase orders for components at the front of the chain, but those components weren't coming to us; they were drop-shipping straight into a subcontractor. That subcontractor's output then moved to a second subcontractor, where more drop-shipped components joined it, and the assembly stepped forward again. The chains nested several levels deep before a finished good existed.

At the end, the final good drop-shipped into a third-party facility that consumed the component inventory and received the finished product.

What that actually demands from a system

Diagram of a multi-tier subcontract chain: components purchased and drop-shipped into successive subcontractors, each consuming inventory owned at their site, with batch genealogy maintained across every tier

Every tier in that chain needs its own subcontractor BOM. Every component-supplier relationship needs purchasing info records that hold the commercial terms together. And critically: you are carrying inventory you own, valued on your books, sitting inside facilities you don't operate — and it has to be consumed accurately as each tier does its work, or your inventory position and your cost of goods both drift away from reality.

Then the hard constraint on top. This was a batch-controlled product under federal oversight. Any finished lot has to trace back through every tier to the specific component lots that made it. A traceability chain is only as good as its weakest hand-off, and this one had a lot of hand-offs.

So my role stopped being "set up purchase orders" and became: figure out how this entire manufacturing process actually works, then figure out how to represent it faithfully in SAP.

The mentor

Worth saying plainly, because it's rare in my career: I didn't figure the subcontracting piece out alone. I teamed up with a mentor who knew SAP subcontracting deeply and guided me through it.

That was the highest-leverage thing available. Multi-tier subcontracting in SAP is a domain where the difference between someone who's done it and someone reasoning from documentation is measured in months. Finding that person and learning fast beat any amount of independent effort.

Then I had to teach it

A process this involved is worthless if only one person can operate it. So the second half of the work was transfer: I trained the team on SAP and built out a full video training series so the knowledge didn't live in my head or in a one-time session. I also built and delivered the purchase-order approval training — including training C-suite executives on their own approval responsibilities.

And because the team was small, I kept hold of the plumbing myself: I managed all of the subcontractor BOMs and purchasing info records that held the chain together. Eventually I was issuing purchase orders too.

Where it led

This is the part I find most telling. It snowballed — from architecting the system, to maintaining the master data, to issuing the orders, to taking an official manager role over the eCommerce operation itself.

I came in as the systems person and left running part of the operation the system supported. For a startup-stage company, championing a process that complex and then being trusted to operate it is the outcome I'd point to: not that the configuration worked, but that the process held up well enough for the business to hand me the business.