Case 02, Launch planning

The Clear to Build system, 200 cutovers

One operating view that collapses fragmented supply signals into what will actually run out, when, and what to do about it. SAP to SQL to Excel and VBA to Tableau. I built it end to end at Lucid, and it still runs in production after my departure.

~200cutovers executed, counted in parts

250+concurrent parts, ~50 changes at peak

35+suppliers fused into one view

Livein production use after departure

01Context

MRP gave the system view, not the truth

Launch planning meant moving hundreds of parts from an old revision to a new one without stopping the line, while the underlying system data was never fully clean. MRP could not separate supply that existed on paper from supply that was physically there and usable.

The Clear to Build system was my answer: a single view that fuses MRP, supplier commits, carrier ETAs, crossdock status, Tier 2 raw material, physical counts, and production demand into one part level readiness picture.

Fig. 2.1

Seven fragmented feeds join into one part level readiness picture; the value sits in the join.

02Constraints

Every feed drifts, and none is the truth alone

The data liesSystem inventory, advanced shipping notices (ASNs), and master data all drift. A tool that trusts them produces false confidence and aims people at the wrong limiter.
Signal arrives in fragmentsSupplier, carrier, warehouse, and production data live in different systems and formats. Any one feed on its own misleads; the readiness picture exists only once they are joined.
Confidence is not binaryReceived supply, in transit, supplier commits, technically pending substitutes, and scenario material each deserve different weight. A tool that flattens them is wrong even when every cell is populated.
A tool is only useful if it changes a decisionA dashboard that reports status without forcing the next action is overhead.

03Role and authority

The stack was mine; release stayed with engineering

The data model, the automation, and the dashboard were mine. Cutover dates and the call to hold a launch were mine; the mitigation paths the tool surfaced went to review as recommendations. The system made technical approval timing visible as a gate. It never approved anything.

I owned

The full stack: data model, VBA automation, Tableau view
Cutover dates, and the authority to hold a launch
The recommendation on every mitigation path it surfaced

I did not own

Technical acceptance and engineering release
Approval of substitute material; the tool showed the gate, it did not open it

04How it is built

SAP to Tableau, and the logic under it

SAPS/4HANA, the transactional coreWorking set: MD04, MB52, MB51, VL06I, ME2M, the Inbound Delivery Dashboard, Warehouse Monitor, and COGI. No custom Z transactions.
SQLRedshift, mirrored for speedSAP data queried directly for the joins the SAP screens can't do cheaply.
XLExcel and VBA, the assembly layerXLOOKUP architecture under the core files, plus a crossdock cleanup macro that reconciles inbound against ASN.
TABTableau, the shared viewThe presentation layer and single operating picture for cross functional teams.

Design logic, the part that matters

One operating view, built for a decisionFuse system, supplier, carrier, warehouse, and demand signals into a single part level readiness picture.
Separate confirmed from assumed supplyReceived, usable supply is visibly distinct from committed, in transit, technically pending, and scenario supply. This is the core idea. It keeps the tracker from mixing reality with optimism.
Time phase against demandTie usable supply to the exact runout point against the build window, rather than to a days of supply average.
Attach a decision to every numberEach at risk part carries a status, runout date, risk level, mitigation owner, and next action. The number arrives with the decision it forces.

Part	Status	In house	In transit	T1 FG and WIP	T2 raw at yield	Build per wk	ETA	Runout	Mitigation
STP-1042	Stable	1,400	1,000	1,700	2,500 at 82%	150	10/18	11/08	Covered to 11/08
STP-3318	Caution	280	200	400	600 at 80%	100	10/16	10/23	Reallocate coil, push supplier
STP-4177	Urgent	120	150	280	500 at 72%	50	10/15	10/21	Escalate, alt material, air
STP-2075	Stable	2,100	640	1,250	3,200 at 85%	180	10/19	11/22	Covered to 11/22
STP-5310	Caution	410	0	520	900 at 78%	120	10/24	10/29	Resequence build, confirm ETA

Fig. 2.2

Coverage shows to runout; an ETA landing after runout is a line down risk.

Part identifiers, values and supplier labels are fabricated for illustration.

How supply enters the model

Confidence tiers, weighted differently

Every supply position enters the model at a confidence level. Received and usable supply anchors the picture; scenario material stays visible and is never counted as coverage.

01Received and usablePhysically on site and buildable
02In transitShipped and tracked to a real ETA
03CommittedSupplier promise, not yet moving
04Technically pendingAwaiting engineering and quality release
05ScenarioModeled coverage, visible and never counted

05Result

Earlier risk detection, fewer panic escalations

MRP gave the system view, not the truth, and closing that gap is what the system did every day. Cleaner signal, earlier risk detection, more precise mitigation, fewer panic driven escalations. It ran as the operating engine through the Tier 3 aluminum disruption; Case 01 carries the stress test outcomes it produced.

~200 cutovers executed across the role
1,000+ inventory records corrected by physical count
~$350K phantom inventory cleared, disruption scope
Live in production after departure

Runs alongside two related artifacts I built and left behind: the Total Inventory File (Excel, with the crossdock cleanup macro) and the engineering change dashboard (Smartsheet).