I have a confession to make. When a requirements table lands in my inbox, I know my answer before even opening it. It will be yes. Yes everywhere, or almost. And it's not arrogance: it's that the question is badly asked.
An ERP requirements document, in its usual form, is a column of features, a "desired", "expected" or "essential" tag next to each, and a box to be filled in by each candidate. The exercise looks like a job interview where you ask every applicant whether they can "work in a team" and "handle pressure". Obviously, everyone says yes. And at the end of the interview, you have learned absolutely nothing.
I have watched these tables go by for more than twenty years. They come down from the big consulting firms, get passed from project to project like a custom no one discusses anymore, and continue to be mistaken for a business-understanding tool when they are not one. Here is why, and what I propose instead.
Why everyone ticks "yes"
The first problem is that the grid sorts no one out.
The basic functions of a mainstream ERP are now commoditized. Managing quotations, orders, invoicing, leave, analytic tracking: any serious solution can do it. When you ask ten vendors whether they tick the box, they all tick it, and they are right to. The answer tells you nothing about what will actually happen next.
Yet we think we reassure ourselves by lengthening the list. The more lines it has, the more we feel we have covered every angle. I have seen grids of two hundred and fifty lines, I have seen some of seven hundred. Neither tells how the company makes its living. An exhaustive list is not knowledge. It is a list, just a longer one.
The truth is in the mechanics, not in the box
Let's take a requirement found in almost every file: leave and absence management.
Everyone can do it. But behind these three words lies an entire mechanism that the box ignores. Who submits the request, and who approves it: the direct manager, human resources, both in succession? What happens when the approver is absent too? How does the absence affect team planning, the invoicing of a fixed-price service, the feed to payroll? What do we do with balances, carry-overs, recoveries, the special cases that make up half of an HR department's daily life?
None of this fits in a yes or a no. And it is precisely here, in the way things really chain together, that the gap lies between a project that relieves teams and a project that burdens them. The "what" is common to all ERPs. The difference lives in the "how", and the table methodically erases it, line after line.
We set in stone a way of working we never chose
This is where the harm becomes serious.
Writing a requirements grid means taking a photo of the current way of working and turning it into a contract. We observe how work is done today, slice it into boxes, have it signed. The catch is that this way of working has almost never been decided. It has settled, layer after layer, over the years. A tax and social security audit that imposed an extra procedure. A customer dispute that gave birth to a validation step. A painful unpaid invoice that produced an endless approval circuit.
And above all, there are all those workarounds that teams ended up inventing because the old software couldn't keep up. The spreadsheet kept on the side that no one dares touch anymore. The "temporary" re-entry that has lasted four years. The shared file that serves as unofficial memory. These tricks made it possible to keep day-to-day work going, but they exist only to compensate for the rigidity of a tool we are about to throw away.
What does the requirements grid ask for? To copy all of this identically into the new tool. It's moving into a new house while carefully taking the cracks with you.
At no point do we ask the question that would make all the difference: why do you do it this way, and does it really have to continue?
The real opportunity: the ERP as a lever, not a copy
This is what saddens me most in this story.
Changing ERP is one of the rare occasions, in the life of a company, to put everything back on the table. It is the perfect moment to clean house: eliminate re-entries, drop the patches, question every step inherited from a constraint that perhaps no longer exists. Not to reproduce the old world in sharper detail, but to rethink it.
Operationally, that means streamlining the flow of information, automating what was done by hand for lack of better, making teams more autonomous. Financially, it means lifting the hood and finally looking at where margin is built and where it evaporates, where cash gets stuck, where hours are lost. A well-run ERP project is a performance lever before it is a software change.
The requirements grid does the exact opposite. It sanctifies yesterday's way of working, workarounds included, before anyone has tried to understand how the company lives. It locks in the need too early, when nothing has yet been questioned.
What the table is really for
Let's be fair: the grid has a real use. It lets you compare vendors on a common basis, and it legally protects the buyer. It is a procurement instrument, and it is even excellent evidence the day a project goes wrong and ends up before a court, since it establishes in black and white who committed to what.
But as a business-understanding tool, it is worth nothing. A buyer's document has been taken and disguised as an analysis approach. The disguise holds because it comes from the big consulting firms and reassures everyone around the table.
The absurdity no one points out
Shall we push the reasoning further? Candidates are required to fill in these tables before even having been shown the solution.
Let's do the math. A reasonably serious consultation readily gathers about fifteen respondents. Each spends one to several days on it. At the scale of one tender, that burns fifteen to forty-five days of expertise, to end up with fifteen binders that will all answer "yes" to the same lines. A few weeks of competent minds, spent ticking boxes that almost no one will read in detail. Hard to believe there isn't a better use of that time, such as understanding the company.
And since nothing has been clarified, the finalists are summoned for oral presentations. The integrator's salesperson is then asked to perform their act: the flawless demo, the screens flowing one after another, the well-oiled story. All this theater aims at one thing: hiding the fact that no one, until then, has really grasped how the house works. Analysis has been replaced by a show, and the tool of the decade is chosen on the quality of the performance.
The consultant employed backwards
In all this machinery, one skill is wasted: the consultant's.
They are called in, and entrusted with what? Writing the requirements document. A specialist in understanding organizations is paid to produce a checklist. It is a misreading of their profession. What should be asked of them is the opposite: help us rethink our way of operating and identify the solution that truly matches who we are. A good consultant doesn't tick boxes, they ask the uncomfortable questions and trace flows back to their origin.
The good news is that this is encountered more and more. We sometimes take over projects where the upstream consultant truly dug into the business: flows dissected, processes challenged, the company's operation understood before anyone talks about tools. You can see it right away, because we then inherit real flow diagrams and not an inventory of functions. These projects start with a considerable head start: the hardest part, understanding, has already been done seriously.
The Auguria method: follow a case, don't fill in a grid
Our conviction guides how we work. It is less spectacular than a binder of several hundred lines, and I own it.
We spend a day in your offices, and we follow a real case from start to finish. An order, from the moment it is born to the moment it becomes a settled invoice. We observe where it goes, who handles it, where it jams, which exceptions eat up most of the teams' time. A case followed in real conditions teaches more than a spreadsheet of several hundred lines. At a distributor, for example, it is a margin that is made or unmade at each step, and no box will tell you that.
No signed binder, no "essential" column. In the end, you leave with two concrete deliverables. First, the complete mapping of your processes, the faithful portrait of your company's life, the one no grid contains. Second, the optimizations we recommend, operational and financial, laid out step by step, before any tooling decision.
And if a consultant has already done this work upstream? All the better, we build on it and go further. Otherwise, we do it ourselves. In both cases, we refuse to commit a company for ten years on the strength of a list no one has really read.
It is less reassuring than a thick document. It is far more useful.
An ERP project is prepared long before the first demo. If you feel the upstream phase deserves better than a checklist, let's talk: at Auguria, we always start by understanding your business.