Réponse courte : aucune fonctionnalité ne change la donne à elle seule. Ce qui la change, c’est la capacité à répondre aux besoins métiers quotidiens, et ce sont les choix d’architecture, pas le catalogue de fonctions, qui déterminent la vitesse à laquelle on peut y répondre. La formule de la vidéo : on ne répond pas à une vision métier par une solution technique, on y répond par une solution métier.
L’essentiel en 30 secondes
- La question posée : quelle fonctionnalité d’AlibeeZ change vraiment la donne ?
- La réponse : aucune. Ce qui compte est d’aider ou non les clients dans leurs besoins quotidiens.
- Les trois capacités citées : dématérialiser facilement les processus, modifier rapidement les règles de gestion, traiter les droits d’accès comme un sujet fonctionnel.
- Le principe : une vision métier appelle une solution métier ; la technique ouvre des possibilités, elle ne remplace pas la réponse.
- Le critère de décision : est-ce que ce choix tiendra encore dans cinq ou dix ans ?
Pourquoi une liste de fonctionnalités ne décide de rien
Toute personne ayant mené un appel d’offres ERP connaît le tableau comparatif à quatre-vingts lignes où tous les éditeurs cochent presque tout. Il ne discrimine pas, parce qu’il mesure la présence d’une fonction et jamais le coût de l’obtenir dans son propre contexte.
La position tenue dans la vidéo est que la bonne question porte sur le délai : combien de temps faut-il pour qu’une règle de gestion particulière (une règle de validation, un mode de facturation, un axe d’analyse) existe réellement chez vous ? C’est ce que nous appelons ailleurs le test d’adaptabilité, développé dans Champs personnalisés : le test qui révèle si un ERP s’adapte vraiment et dans Paramétrage ou développement spécifique.
Les trois capacités qui en découlent
| Capacité | Ce qu’elle permet concrètement |
|---|---|
| Dématérialiser facilement les processus | Faire passer une validation du mail au circuit outillé sans projet d’intégration |
| Modifier rapidement les règles de gestion | Changer un seuil, un circuit ou un mode de facturation sans développement |
| Traiter les droits d’accès comme un sujet fonctionnel | Qu’un manager de business unit voie sa marge sans voir celle de ses voisins |
La troisième mérite un mot, parce qu’elle est presque toujours traitée comme un sujet de sécurité. Dans une organisation multi-entités ou multi-BU, la question des droits n’est pas « qui peut entrer » mais « qui voit quel périmètre de marge, de coût et de salaire ». C’est une règle de gestion, avec ses exceptions et son historique, et un modèle de droits pensé comme un pare-feu ne sait pas l’exprimer.
Un pari à cinq ou dix ans
La vidéo se termine sur la question qu’un éditeur se pose avant chaque décision d’architecture : est-ce que ce choix sera toujours valable dans cinq ou dix ans ? Elle est honnête sur le fait que c’est un pari, et c’est ce qui la rend intéressante.
Pour un acheteur, la transposition est directe. Le SI d’une organisation vivra plus longtemps que la plupart des outils qui le composent, et ce qui doit durer n’est pas la fonction mais le référentiel sur lequel elle s’appuie : voir Système intégré vs best of breed.
Transcription de la vidéo
Transcription intégrale, légèrement corrigée pour la lecture.
Quelle fonctionnalité d’AlibeeZ change vraiment la donne ?
Pour moi, une fonctionnalité ne change pas la donne. Ce qui va changer la donne, c’est d’aider ou non les clients dans leurs besoins quotidiens. De bons choix techniques vont permettre de répondre rapidement aux besoins métiers : par exemple une architecture qui permette de dématérialiser facilement les processus, de modifier rapidement les règles de gestion, ou de répondre à des problématiques de droits d’accès, qui sont des problématiques hautement fonctionnelles, au-delà de la sécurité.
Comment transformez-vous une vision métier en solution technique ?
Selon moi, on ne répond pas à une vision métier par une solution technique. On répond à une vision métier par une solution métier. La technique et les choix techniques vont permettre d’ouvrir des possibilités sur la manière de faire, en prenant les technologies existantes et les technologies futures, en faisant un pari : est-ce que, quand je prends une décision aujourd’hui, elle sera toujours valable dans cinq ou dix ans ?
Pour aller plus loin
- Personnalisation : ce qui se règle sans développement.
- Paramétrage ou développement spécifique : de quel côté tombe votre besoin.
- Notre expertise : l’équipe qui construit la solution.
Questions fréquentes
Pourquoi dire qu’aucune fonctionnalité ne change la donne ?
Parce que deux ERP peuvent cocher la même ligne d’un cahier des charges avec des coûts d’adaptation totalement différents. Ce qui distingue vraiment une solution, c’est le délai avec lequel elle absorbe une règle de gestion qui lui est propre, pas la présence d’une fonction dans un catalogue.
En quoi les droits d’accès sont-ils un sujet fonctionnel ?
Parce que dans une entreprise multi-entités ou multi-business units, la question n’est pas de savoir qui peut se connecter mais qui voit quel périmètre de marge, de coût et de rémunération. C’est une règle de gestion, avec ses exceptions, pas un réglage de sécurité.
Comment juger l’architecture d’un ERP pendant un appel d’offres ?
En demandant une modification réelle plutôt qu’une démonstration : un nouveau champ suivi dans les rapports, un circuit de validation modifié, un axe d’analyse ajouté. Le temps et le mode de réalisation, paramétrage ou développement, sont la réponse.
