Every time I am handed a requirements specification with its hundreds of lines of requirements, I have the same urge: to answer "I love you too".
Because it is a declaration, a table of requirements. Weeks of work, a "desired / expected / essential" column, a box to tick next to each line. People put their whole heart into it. And I will answer "yes" almost everywhere, a little less often than the others because I have the weakness of putting "no" where it is no. But the effect is the same for everyone: Odoo says yes, SAP says yes, Oracle says yes, Cegid says yes, Sage says yes, Business Central says yes. In the end, the customer holds a magnificent signed binder in which everyone agrees on everything. The ERP equivalent of a first date where, by coincidence, you both love hiking and sushi.
I have been seeing these tables go by for fifteen years. They come from the big consulting firms, everyone copies them, and nobody questions a method that is as reassuring as it is ineffective. This article is my attempt to say out loud what many integrators think privately, and to propose something else.
A Grid That Distinguishes Nothing
Let's start with the most awkward point: the requirements table does not separate the good from the bad. It lumps them together.
Ask ten vendors whether they can handle quotations, sales orders, invoicing, expense reports, time off, a bit of analytics. They will all answer yes. And they will be right. The functional foundation of a modern ERP is now a given: the "what" is common to the whole market. Ticked or not, it says nothing about the quality of the project that will follow.
Worse: the more lines there are, the more it feels like everything has been planned for. Hundreds of requirements impress the steering committee, give a feeling of duty done, fill a meeting. But a long list is not an understanding. You can tick three hundred boxes (or seven hundred, I have seen it) and still have no idea how the company actually earns its living. Length is not depth. It is just length.
Everything Is Decided in the "How"
Let's take a line at random, one of those found in every specification: "expense report management: essential".
Everyone can do it. Really everyone. But ask the real questions:
- Who enters the report: the employee, their assistant, the accountant?
- At what point, and with which supporting document?
- On which project, which cost center, which analytic plan is it allocated?
- Who approves, in what order, with what delegation threshold?
- Within how many days is the reimbursement paid, and through which flow to payroll and accounting?
None of these questions appears in the table. Yet this is exactly where the difference is made between an implementation that saves time and one that wastes it. The "what" is identical everywhere; the value lives in the "how". And that is precisely the one thing a checkbox is structurally incapable of capturing.
Multiply that by three hundred lines. On every line, the richness of reality has been crushed under a yes/no. We have confused "the tool can do it" with "the tool will do it the way you need it". These are not the same projects at all.
The Frozen Snapshot of an Endured Way of Working
Here is the deepest, and most costly, flaw.
A specification is a snapshot of current operations, turned into a contractual commitment. You take the way the company works today, cut it into requirements, and have it signed. Except that this current way of working is only very rarely a considered choice. It is sedimentation. An accumulation of workarounds and scars: the customer lost one day that led to an added control step, the tax reassessment that imposed double archiving, the big receivable never collected that gave rise to a lengthy approval procedure.
And then there are my favorites: workaround processes. Those little gems of ingenuity that teams invented because the old tool was too rigid. The parallel Excel file nobody dares delete. The "temporary" double entry that has lasted six years. The stamp kept "just in case". The manual export every Friday evening. These are masterpieces of resourcefulness that have saved the company day to day, but they exist only to compensate for the limits of a piece of software we are about to replace.
And what does the specification do? It religiously asks to reproduce all of it identically in the new tool. We move into a new house, taking care to bring the leaks along.
No one, at any point, asks the only question that matters: why do you do it this way, and does it still need to exist tomorrow?
The Opportunity of the Decade, Missed by Method
This is the whole paradox, and it is what saddens me most.
Changing ERP is the best opportunity a company encounters in ten years. The opportunity to sort things out. To eliminate double entries, to scrap the patches, to question the steps that existed only to compensate for yesterday's rigidity. It is the ideal moment to review processes in depth, not just tidy them up but optimize them:
- Operationally: eliminate re-keying, make information flow more smoothly, automate what was manual by default, give teams back their autonomy.
- Financially: finally look at where margin is built and where it is destroyed, where cash gets stuck, where working capital deteriorates, where teams' time goes up in smoke.
In short, use the ERP project as a transformation lever, and not as a simple replacement of the plumbing.
The requirements table does exactly the opposite. It sanctifies yesterday's way of working, workarounds included, before anyone has taken the time to understand how the company runs. It freezes the need at the worst moment: too early, when nothing has yet been questioned.
So What Is This Table Really For?
Let's be honest to the end. The specification has a real function, but not the one people think. It serves two purposes: comparing vendors on a uniform grid, and covering yourself legally.
It is a purchasing tool and a litigation tool. Its most concrete use, deep down, is to serve as an exhibit the day the project goes off the rails and ends in a dispute: the written and signed proof of who ticked what. Excellent at that function, by the way.
But on the business side (understanding the company, choosing the right partner, preparing a project that succeeds), it is useless. We took a purchasing instrument and disguised it as an instrument for understanding the business. The disguise holds because it is the method of the big consulting firms and it reassures everyone in the room.
The Absurdity of Mass Form-Filling
Let's take the waste one step further. Candidates are asked to fill in these tables before they have even been shown the tool.
Do the math for a second. A serious consultation easily has fifteen companies responding. Each spends from one to several days of work on it. So, across the market, between fifteen and forty-five person-days have been mobilized, for nothing, to produce fifteen binders that will all say "yes" to the same lines. Fifteen to forty-five days of expertise burned ticking boxes that nobody will really read.
Doesn't anyone think there might surely be something smarter to do with that time? Something like, say, understanding the company?
The Grand Show of the Final Pitch
And as all of this has, in the end, clarified nothing, we move on to the next stage of the ritual: the finalists are summoned for the big final pitch.
There, the integrator's salesperson is asked to perform the salesman's dance. The shiny demo, the screens flowing without a hitch, the slides that pop, the rehearsed-to-the-millimeter scenario. All this theater serves one purpose: to create an illusion. To mask the fact that, in the previous steps, nobody really understood how the company works. Understanding has been replaced with spectacle.
And that is how we choose the ERP that will structure the company for the next ten years: on the quality of a tap-dance number.
We Get the Consultant Wrong
In the middle of all this, there is a figure we misuse: the consultant.
We call them in, and ask them to help us... write the specification. To build the table. We pay someone whose job is precisely to understand companies, and put them to work producing a checklist. It is a waste of talent.
What we should ask them is the exact opposite: help us rethink the way we work, and find the solution that truly fits who we are. A good consultant does not fill in boxes. They ask the right questions. They shake up the obvious. They trace the flows back to their source.
And the good news, because there is some, is that this is happening more and more. We regularly come across projects where the consultant really thought in business terms upstream: they dug into the flows, shook up the processes, understood how the company runs before even talking about tools. And it shows immediately. We have real flow diagrams in hand, not a list of functions. Those projects start ten lengths ahead, because the real work, the work of understanding, has already been done, and done well. When the consultant plays that role, we are no longer filling in a table: we are building something.
The ANOR Method: Follow a Deal, Don't Tick Boxes
At ANOR, our method rests on this way of thinking. It is less glossy than a three-hundred-line binder, I readily admit.
In practice: we sit down for a day in your offices and follow a real deal from end to end. A sales order that we accompany until it becomes a collected invoice. We look at how it is born, where it passes through, who touches it, where it gets stuck, which exceptions take up 80% of the teams' time. Because a deal followed in real conditions teaches you more than three hundred lines of Excel. And at a trading company, for example, it is a margin that is built or destroyed at every step. No checkbox will tell you that.
No signed binder, no "essential" column. On the way out, you leave with two concrete things:
- The diagram of all your processes: the true map of the life of your company, the one no table contains.
- The optimizations we recommend: operational and financial, step by step, before a single tooling decision is made.
And if a consultant has already done this groundwork upstream? All the better. We build on it, save time, go further. Otherwise, we do it. In both cases, we refuse to start a project that commits you for ten years on the basis of a checklist that nobody has really read.
It is less reassuring than a three-hundred-line document.
It is infinitely more useful.
And incidentally, it makes for much better first dates.
Are you preparing an ERP project and sense that the upstream phase deserves better than a tick-box table? Let's talk. At ANOR, we always start by understanding your business before talking about tools.