Short answer: no single feature changes anything on its own. What changes things is whether the tool answers day-to-day business needs, and it is architectural choices, not the feature catalogue, that set how fast those needs can be answered. The video's formula: you do not answer a business vision with a technical solution, you answer it with a business solution.
The short version
- The question asked: which AlibeeZ feature really changes things?
- The answer: none. What matters is whether clients are helped with their daily needs.
- The three capabilities named: digitising processes easily, changing business rules quickly, treating access rights as a functional subject.
- The principle: a business vision calls for a business answer; technology opens possibilities, it does not replace the answer.
- The decision test: will this choice still hold in five or ten years?
Why a feature list decides nothing
Anyone who has run an ERP tender knows the eighty-row comparison sheet on which every vendor ticks almost everything. It does not discriminate, because it measures the presence of a feature and never the cost of getting it in your own context.
The position held in the video is that the real question is about lead time: how long does it take for a particular business rule (an approval rule, a billing model, an analysis axis) to genuinely exist in your setup? That is what we call the adaptability test elsewhere, developed in Custom fields: the test that shows whether an ERP really adapts and in Configuration or custom development.
The three capabilities that follow
| Capability | What it actually allows |
|---|---|
| Digitising processes easily | Moving an approval from email to a tooled chain without an integration project |
| Changing business rules quickly | Changing a threshold, a chain or a billing model without development |
| Treating access rights as functional | A business unit manager sees their own margin without seeing their neighbours' |
The third deserves a word, because it is nearly always treated as a security matter. In a multi-entity or multi-BU organisation, the rights question is not "who can get in" but "who sees which scope of margin, cost and pay". That is a business rule, with its exceptions and its history, and a rights model conceived as a firewall cannot express it.
A five to ten year bet
The video ends on the question a vendor asks before every architectural decision: will this choice still be valid in five or ten years? It is honest about the fact that this is a bet, and that is what makes it interesting.
For a buyer, the translation is direct. An organisation's information system will outlive most of the tools inside it, and what has to last is not the feature but the repository underneath it: see Integrated system vs best-of-breed.
Video transcript
Full transcript, translated from the French and lightly tidied for reading.
Which AlibeeZ feature really changes things?
For me, a feature does not change things. What changes things is whether or not clients are helped with their daily needs. Good technical choices allow you to answer business needs quickly: for example an architecture that lets you digitise processes easily, change business rules quickly, or answer access-rights questions, which are highly functional questions, well beyond security.
How do you turn a business vision into a technical solution?
In my view, you do not answer a business vision with a technical solution. You answer a business vision with a business solution. Technology and technical choices open up possibilities in how you do things, taking existing technologies and future ones, and making a bet: when I take a decision today, will it still be valid in five or ten years?
Read next
- Customisation : what can be set up without development.
- Configuration or custom development : which side your need falls on.
- Our expertise : the team that builds the solution.
Frequently asked questions
Why say that no feature changes things?
Because two ERPs can tick the same line of a requirements document with completely different adaptation costs. What really distinguishes a solution is how quickly it absorbs a business rule specific to you, not whether a feature appears in a catalogue.
How are access rights a functional subject?
Because in a multi-entity or multi-business-unit firm the question is not who can log in but who sees which scope of margin, cost and pay. That is a business rule with its own exceptions, not a security setting.
How do you judge an ERP's architecture during a tender?
By asking for a real change rather than a demonstration: a new field tracked through to the reports, a modified approval chain, an added analysis axis. The time it takes and the way it is done, configuration or development, is the answer.
