There’s a lot of ERP-slamming about at the moment. Failed implementations, budgets doubling, go-lives slipping past peak, finance teams not trusting the data in them and rebuilding the whole thing in Excel eighteen months after launch.
Most of it is aimed at the wrong target.
NetSuite is a serious system. So is Business Central, so is SAP. They are going to be very good in the AI era, because a system of record with clean data underneath it is exactly what any of this needs. I’d argue the systems aren’t what’s failing.
What’s failing is the way they get delivered and adopted. That hasn’t meaningfully changed since about 2016, and it’s the bit nobody puts in the case study.
The question at the start of every project is unanswerable
The moment it starts going wrong happens in week two.
A partner asks what you need. Your team answers as well as anyone could, which is partially, because nobody in the room has run this system before. The detail of what the system requires also lives in fifteen people’s heads and half of it has never been asked for or written down.
Those answers become requirements. The requirements become a scope. The scope becomes a fixed price and a date.
Nine months later you’re in UAT. Your merchandiser sees a purchase order screen for the first time and says “this isn’t how buying works here”.
The requirements were flawed from the start.
Because on one side of the table, were brand side stakeholders who didn’t have the experience or system knowledge to know how to answer the requirements questions asked by a vendor or traditional SI at the beginning of the project.
On the other, a project team working in an outmoded delivery model that captures requirements upfront, locks scope, and puts big lead times in front of users actually getting a chance to work in or familiarise themselves with the system. Often by discovery and design “experts” who have little context experience (i.e. they’ve never been a merchandiser in a brand, or haven’t actually worked as a financial controller, or managed a project from the brand-side).
The truth arrives at the moment it’s most expensive
Look at when a brand actually gets to see the new system doing its job. The first tailored demo, if there is one, lands around week seven (or later). Real hands-on time usually comes with training, which can fall as late as month five of a nine to twelve month programme.
So the entire scope is agreed months before anybody on the brand side has enough context to have an opinion worth having. And when the opinions finally arrive, they arrive as change requests. New cost, new risk, and a date that moves.
This was rational, right up until it wasn’t
Here’s the part the industry hasn’t caught up with.
That sequence made sense when the technical build genuinely was the expensive, slow, uncertain part. If configuring the system, wiring the integrations and testing the whole stack is six months of specialist work, then of course you nail the scope first. You can’t afford to find out late.
But in most scaleup and grownup brands, that’s no longer true, and it stopped being true fairly recently.
Most of what a fashion or lifestyle brand does has been done before. There is a finite number of ways to get a product concept to a purchase order. A finite number of ways to allocate stock across DTC, retail and wholesale. Brands think they’re the exception, and they are, in roughly one place out of twenty. The other nineteen are the same shapes we’ve all seen dozens of times.
Which means the standard configuration, the integration patterns, the test suites and the documentation don’t need building from scratch every time. They need deploying. And the tooling to do that properly, including generating test coverage and documentation off the build itself, didn’t exist a few years ago.
So the sensible order has inverted. You can now ask, build, ask, build, ask in a much more dynamic way.
Deploy the standard. Connect it to the brand’s own store. Pull their products and their purchase orders through it. Then put it in front of them and let them react to something real, in week one, while changing your mind is still free.
The handful of things they genuinely do differently show up immediately, because that’s precisely where the standard doesn’t fit. You find them in week one, price them in week one, and build them alongside the standard rather than discovering them at UAT.
The saving doesn’t go where you’d expect
One honest caveat, because this is where I think a lot of the AI-in-delivery talk falls over.
Training can’t be compressed. The person learning how their month end changes needs the same hours they always needed. Adoption is a human process and there is no version of this where a brand’s team absorbs a new operating model faster because the build was quicker.
So the time that comes off the technical work shouldn’t come off the invoice as a discount and disappear. It should move. Into the part that decides whether any of this actually works: your team knowing what to do, and having the confidence to do it.
That’s the whole argument, really. The build is commoditising but the judgement isn’t.
We’ve been building this
I’ve spent a good chunk of this year putting that into a proper delivery model rather than a strong opinion. It’s called Atelier, and it’s how we’ll be delivering NetSuite into fashion and lifestyle brands in the future.
I’m not going to put numbers on it yet. We’ll publish those when we can prove them rather than when they’d be useful to me.
But if you’re staring down an ERP decision and the six-to-nine-to-twelve-month version of it is making you flinch, reply to this. I’d rather show you than describe it.