A $16B merger integration needed more than a plan. It needed an architecture for how two enterprises would function as one.
Cross-enterprise service blueprint program spanning the full supply chain — designed to surface risk, force consensus, and accelerate integration before disruption could take hold.
Two enterprises. Incompatible operating models. No shared language for what had to change — or when.
At the scale of a $16B merger, the risk isn't the deal — it's what happens after. Two organizations with different tech stacks, different process languages, and different operational cultures have to function as one before anyone has figured out what "one" actually means. Service disruption doesn't wait for alignment.
The integration team was drowning in scope. Every pillar — transportation, warehousing, yard operations, merchandising, wholesale — had its own complexity, its own dependencies, and its own politics. Without a system to contain that complexity, the work was swirling: meetings that didn't move anything forward, decisions made without full visibility, and critical gaps that no one had surfaced yet.
What was missing wasn't effort. It was architecture — a way to see the entire integration at once, zoom into any segment with precision, and hold both organizations accountable to the same picture of what needed to happen.
Seeing things at enterprise-wide scale — and then telescoping down to nuance without losing either — is the rare skill that makes service designers irreplaceable in integration work.
A methodical, section-by-section integration architecture — built to reduce overwhelm, force focus, and generate velocity.
Developed a 4-level service blueprint framework from scratch
I designed and standardized a template set of service blueprints across four fidelity levels — from bare-bones hypothesis sketches to fully detailed, socialization-ready artifacts. Each level had a defined purpose: capturing the as-is state, modeling the transition, mapping the to-be state, and exploring what-if scenarios.
Built a repeatable workflow for surfacing ground truth across both organizations
For each supply chain segment, I gathered all existing blueprints and documentation, then built a hypothesis as-is blueprint before any meeting. That hypothesis became the anchor for workshops — "Is this correct?" — which grounded the conversation, focused the group, and surfaced questions, pain points, and gaps that wouldn't have emerged from a blank-slate discussion.
Created a single enterprise-wide reference library spanning both organizations
I developed a master supply chain map for both companies — displaying all segments, essential functions at each stage, and points of contact for every decision. Built in a dedicated Mural collaboration space, it became the canonical reference for the entire integration team: who to ask, who the decider was, what dependencies existed, and where pain points had been logged.
Aligned two organizations on a shared operational vocabulary — and kept it aligned
One of the most underestimated integration risks is language drift — two teams using the same words to mean different things, or different words for the same thing. I established shared language at the outset and maintained it throughout, using service blueprints as consensus tools rather than documentation tools.
Expanded from one supply chain pillar to the full enterprise — and surfaced what others missed
My scope expanded from transportation and logistics to all segments of the supply chain, plus merchandising and wholesale operations. That breadth let me see connections across pillars that siloed teams couldn't see — most significantly, the interdependencies between transportation, warehouse, and yard operations that no one had mapped.
The tools that contained complexity and generated alignment.
Master supply chain map: Enterprise-wide view of both organizations — all segments, essential functions, contacts, and decision owners. The canonical reference that prevented swirl and surfaced cross-org dependencies. Actual artifact confidential.
Service blueprint (Level 4): A completed segment blueprint at full fidelity — decisions recorded with attribution, consensus reached across both organizations. Socialization-ready and referenced in leadership presentations. Actual artifact confidential.
Transition map: The as-is to to-be view, calendar-aligned across all supply chain segments — used to identify dependencies, surface disconnections before they became incidents, and prioritize tasks against real deadlines. Actual artifact confidential.
Insight snapshot: DC-level research findings — pain points, financial impacts, and journey maps — translated into a shareable format for business leadership. Content abstracted for confidentiality.
A validated blueprint system covering the full enterprise supply chain — with explicit decisions, dependencies, and ownership — gave leadership a clear, defensible picture of integration readiness before go-live.
Created the majority of all business process reference documentation across both organizations — artifacts that remained in use by teams well beyond the formal integration engagement.
Surfaced undocumented dependencies between transportation, warehouse, and yard operations — then influenced leadership to consolidate those teams. A structural change that resulted from design insight, not a directive from above.
This project is often described as a documentation exercise. It wasn't. It was a system design problem at enterprise scale — where the risk of getting it wrong was operational disruption across a $16B integration.
The blueprints were the output. The real work was creating the conditions under which two organizations with different languages, different politics, and different operating models could agree on what the future looked like — and commit to it in a form that survived the people who made the decisions