SpaceX as ERP strategy: how to be less dumb

Over the past 16+ years, I’ve sat at the table for hundreds of enterprise transformations. First at Workiva, where we tackled the reporting nightmare that almost always trails an ERP migration, and now at Zip, where I see the upstream version of the same problem play out every week. Different function, same disease: companies launch ERP transformations expecting clarity, agility, and speed, and instead they get the opposite. They get more complexity, more workarounds, and a system of record that bears only a passing resemblance to how the business actually operates.

The clearest way to think about why this keeps happening, and what to do about it, comes from an unexpected place: a SpaceX engineering manual.

Look at the engines above for a second. Same job, three generations. Raptor 3 has a fraction of the parts of Raptor 1, and it’s the most powerful and reliable of the three. That progression isn’t an accident.

It’s the output of the five-step design algorithm SpaceX uses across its hardware:

Make the requirements less dumb. Every requirement has a name attached, not a department. Question the requirement itself before you try to satisfy it.
Delete the part or process. If you aren’t adding back at least 10% of what you delete, you didn’t delete enough.
Simplify or optimize, but only what’s left after step 2.
Accelerate cycle time.
Automate, and only after the first four. Automating a dumb process just makes the dumb thing happen faster.

Here’s the truth: The ERP most companies have today is a Raptor 1. Bolted-on apps, custom workflows, special-case approval logic, vendor portals duct-taped to the side. Every one of them added for a real reason at some point, and almost none of them ever questioned again.

The ERP you can have with Zip in front of it is a Raptor 3. Same core engine. Far fewer parts hanging off it. Cleaner interfaces, faster cycle time, dramatically less surface area to break.

That is the fundamental choice at the heart of every migration. You are committed to an ERP transformation, but the outcome is still undecided. Which engine are you actually going to build?

Granted, the parallel isn’t exact. Re-engineering a back-office suite isn’t the same as building a propulsion system, and enterprise leaders rarely have the luxury of scrap-and-restart. Yet the logic remains bulletproof: most organizations tackle their migrations by running the algorithm in reverse, prioritizing automation before they’ve even questioned why the underlying process exists.

Here’s how the typical large ERP transformation goes. The CFO greenlights a multi-year program. A systems integrator parachutes in. The first 12 months are spent mapping current-state processes: every PO workflow, every approval matrix, every special carve-out the controller’s team built in 2019 to keep one VP happy. Then those processes get reimplemented inside the new ERP, often customized, occasionally with a fresh layer of bolted-on apps to cover the gaps the new ERP can’t.

And then something predictable happens. Twelve months in, the CFO asks, “Where’s the value?” The honest answer is that the company has spent $40M to roughly recreate the old system. The wiring is just as dense. The approval matrix is just as baroque. The “transformation” is a Raptor 1 with a new color of paint.

The reason is that step 1 of the algorithm, “make the requirements less dumb,” almost never happens in an ERP project. Requirements get gathered. They get documented. They almost never get questioned. Which means step 2, delete the part, also doesn’t happen. By the time anyone is talking about automation (step 5), the underlying process is the same Frankenstein it always was. That’s a Raptor 1 ending: same engine, more wires.

Key Takeaway: Reimplementing your old process inside a new ERP is not a transformation. It’s a re-skin. If you didn’t delete anything, you didn’t transform anything.

I want to be careful how I say this, because the best implementation partners I’ve worked with are essential to a successful transformation, and I’d put my name behind several of them in a heartbeat. But there’s a structural reality worth naming honestly. The traditional ERP implementation model is paid by the hour, by the seat, and by the scope of work. The more requirements that get gathered, the more workflows that get configured, the more custom integrations that get stood up, the bigger the engagement. It’s not that anyone is acting in bad faith, just poorly aligned incentives. It’s that the economic gravity of the model bends toward more, not less.

This is a big part of why so many ERP transformations end up at Raptor 1. The same forces that produce a $4M engagement also produce a $40M engagement, and the difference between them is very often complexity the business didn’t actually need. I’ve watched plenty of companies spend five to ten times what the underlying work was really worth, then end up with a Raptor 1 anyway, and call it a transformation. The wires are denser. The bill is bigger. The engine is the same engine.

An orchestration-first approach quietly changes the economics. When intake, approvals, and vendor management live outside the ERP in a configurable layer, you don’t need a six-figure change order to adjust an approval threshold. You don’t need an ERP customization to onboard a new vendor type. Work that used to be billable becomes a settings change. That is genuinely good for the business, and the best implementation partners are happy to lean into it because they care about their clients succeeding and hiring them again.

Key Takeaway: Traditional ERP implementation economics reward complexity. Companies routinely spend five to ten times what the project should cost and end up with Raptor 1 anyway. Design the engagement so that less complexity is the win condition.

This is the part where I’m supposed to say “and that’s why you need Zip.” But I want to make a slightly more nuanced argument first, because the usefulness of an orchestration layer like Zip is downstream of a more important point: most of the complexity in your ERP isn’t actually ERP work. It’s intake. It’s approvals. It’s vendor onboarding. It’s the choreography of getting a request from a budget owner to a buyer to a finance approver to a legal reviewer to a security reviewer to a PO. Your ERP got dragged into doing all of that because nothing else was sitting in front of it. That’s why your current ERP looks like Raptor 1. Every one of those bolt-ons is a wire on the engine.

When you put a procurement orchestration layer in front of the ERP, two things happen. First, you get to apply the algorithm honestly. You can actually delete steps, because the orchestration layer makes it visible which steps exist and who owns them. Most companies discover that 30 to 40% of their approval logic is vestigial. It was added once for a reason that no longer exists, and nobody has had the authority or the visibility to question it.

Second, the ERP gets to be the thing it’s actually good at: a system of record. Not a system of engagement, not an approval engine, not a vendor portal, not an intake form. The ERP holds the books. Everything else lives upstream, where it can change at the speed of the business instead of at the speed of an SI statement of work.

Key Takeaway: An ERP makes a great system of record and a terrible system of engagement. The work you’re doing inside the ERP that isn’t accounting is almost certainly work that belongs somewhere else.

Here’s the part that surprises people. Once intake, approvals, and vendor management live in an orchestration layer, the ERP itself becomes a swappable component. I’ve watched companies migrate from NetSuite to Workday, from a homegrown system to Oracle, from SAP ECC to S/4HANA, and the end users barely noticed. They kept submitting requests through the same intake. They kept getting the same approval notifications. The plumbing changed underneath them, and the day-to-day stayed the same.

That is the Raptor 3 outcome. Fewer parts. Cleaner interfaces. The system of record can evolve without the entire business holding its breath. A migration that used to be a two-year, capital-T Transformation becomes a back-office data project. Disruptive for finance and IT, mostly invisible to everyone else.

This is the piece I wish I’d understood at Workiva. We built phenomenal reporting on top of ERPs that were mid-transformation, and it worked, but the reporting was always running uphill against a system that was simultaneously trying to be the source of truth and the user interface and the workflow engine. Decoupling those layers, putting orchestration in front and leaving record-keeping behind, is what makes the whole stack movable.

Key Takeaway: When you separate the system of engagement from the system of record, your ERP stops being a 5-year decision. It becomes a vendor choice you can revisit.

There’s one more reason to be deliberate about this. ERP transformations are highly visible. Every employee files an expense, requests a vendor, or submits a PO. If the new system is slower or more confusing than the old one (and it almost always is on day one), you’ve lost the org’s confidence before you’ve delivered any of the back-end value the business case promised.

Procurement orchestration takes that risk off the table. The user-facing surface stays consistent (or, ideally, gets better) regardless of what’s happening to the ERP underneath. You get to do the genuinely hard, slow, careful work of an ERP migration without making it the entire company’s problem.

Key Takeaway: The most visible part of an ERP transformation is the part employees touch. Stabilize that surface first, and you buy yourself the runway to do the rest right.

If you’re staring down an ERP transformation, or you’re already in one and feeling the gravitational pull toward Raptor 1, here’s the order of operations I’d argue for.

Run step 1 of the algorithm before you write a requirements doc. For every approval, every workflow, every custom field somebody is asking you to bring forward, get a name on it. Not a department. A name. Then ask whether the requirement itself is still real. A surprising amount of the legacy gets deleted in this conversation alone.

Put intake and orchestration in place first. Before you touch the ERP, get the system of engagement in place and stabilize it. This gives you a clean, structured data feed into whatever ERP you eventually land on, and it gives end users a consistent experience throughout the transition.

Let the ERP shrink to its job. It’s a ledger and a system of record. The more responsibility you push out of it, the less customization you’re paying for, the cleaner your audit trail gets, and the easier the next migration becomes.

Save automation for last. Per the algorithm. Once you’ve deleted, simplified, and accelerated, then you automate. Not before. Automating a process you should have deleted is one of the most expensive mistakes in enterprise software.

Every CFO and CIO walking into an ERP transformation today is going to walk out of it with one of two engines. A Raptor 1: same baroque approval logic, same bolted-on apps, same custom workflows, just running on a newer license. Or a Raptor 3: a clean system of record, with intake and orchestration as a separate layer, fewer parts, faster cycle time, and the ability to swap the ERP itself out the next time you need to.

The companies that end up with Raptor 3 aren’t the ones with the best implementation partner or the cleanest data migration plan. They’re the ones willing to delete things. To question requirements. To put a layer in front of the ERP that lets them stop using the ERP for jobs it was never meant to do.

You don’t have to buy the framing wholesale to take the algorithm seriously. The order matters. Question requirements, delete what you can, simplify what’s left, speed it up, and only then automate. Most ERP programs do those steps in reverse and wonder why they end up with a Raptor 1.

So, which ERP will you end up with? The fewer parts you have hanging off it, the less there is to break, and the more your transformation actually transforms.

Justin Weller consults with new customers at Zip, working with accounting, finance and procurement teams on the upstream side of ERP transformations. Previously he was at Workiva and Alpha FMC, where he spent fifteen years on the financial and business performance reporting end of the same problem.