00:00:07 Importance des systèmes ERP.
00:02:42 ERP : Explication du mauvais nom.
00:03:54 Implémentation initiale du système ERP.
00:05:07 Capacités fondamentales des premiers systèmes ERP.
00:07:34 Systèmes ERP : entités, interfaces, logique.
00:09:14 Rôle de l’ERP dans l’automatisation des entreprises.
00:09:54 Évolution des ERP et stratégies.
00:11:32 Les langages spécifiques au domaine dans les ERP.
00:12:07 Structure modulaire des systèmes ERP.
00:14:22 Rôle des intégrateurs dans les ERP.
00:16:00 Des intégrateurs promouvant des solutions ERP personnalisées.
00:17:01 Pertinence des contraintes ERP traditionnelles.
00:19:01 Remise en question du besoin d’un système ERP unique.
00:20:01 Difficultés lors des mises à niveau des ERP.
00:21:35 Rôle de l’opérateur ERP et complications.
00:22:53 Risques/avantages des fournisseurs ERP spécialisés.
00:25:00 Systèmes ERP : complexité et défis.
00:26:52 Les petites entreprises et les applications SaaS.
00:28:42 Des produits ERP complexes pour les entreprises de taille intermédiaire.
00:30:16 Les grandes entreprises évitent les ERP monolithiques.
00:31:46 Stratégies des grandes entreprises.
00:33:39 Réflexions finales.
Résumé
Dans une interview avec Kieran Chandler, le fondateur de Lokad, Joannes Vermorel, aborde l’évolution des Enterprise Resource Planning (ERP). Retraçant leur apparition dans les années 1970, Vermorel met en avant deux innovations clés — l’avènement des bases de données relationnelles et des lecteurs de codes-barres —, essentielles au développement des ERP. Il suggère que “Enterprise Resource Management” est un terme plus précis pour désigner ces systèmes, qui sont passés de solutions sur mesure pour entreprises à des représentations préemballées de modèles d’affaires. Les fonctionnalités modernes des ERP, telles que les interfaces CRUD et la logique de workflow, ont automatisé les tâches routinières, améliorant ainsi la productivité. Vermorel explore les stratégies des fournisseurs ERP à succès, comme SAP, pour gérer la complexité des systèmes, et aborde également la sélection et la mise en œuvre des ERP pour des entreprises de tailles diverses.
Résumé étendu
Lors de l’interview, l’animateur Kieran Chandler s’entretient avec Joannes Vermorel, le fondateur de Lokad, pour discuter de l’évolution et du fonctionnement des systèmes Enterprise Resource Planning (ERP).
Vermorel retrace les origines des systèmes ERP, situant leur émergence dans les années 1970, bien que le terme “ERP” n’ait été inventé que dans les années 90. Selon lui, deux innovations clés ont conduit au développement des ERP. La première fut l’évolution du matériel informatique jusqu’au point où une base de données relationnelle devenait possible. Ces bases de données, bien que rudimentaires à leurs débuts, offraient un moyen polyvalent d’organiser les données. Le format relationnel, composé de tables et de colonnes, était adapté pour modéliser diverses activités commerciales, notamment les transactions, les paiements, ainsi que les interactions entre clients et fournisseurs.
La deuxième innovation cruciale mentionnée par Vermorel est l’invention des lecteurs de codes-barres. Bien que ces lecteurs soient apparus dans les années 1950, ce n’est qu’avec l’évolution du matériel informatique, permettant de stocker et de traiter d’importantes quantités de données dans les années 1970, qu’ils ont pu avoir un impact marqué. La combinaison de ces deux technologies a donné naissance aux ERP que nous connaissons aujourd’hui.
Vermorel aborde également le mauvais nom attribué aux ERP, en précisant qu’il s’agissait d’un stratagème marketing initié dans les années 90. Il explique que les ERP n’ont en fait rien à voir avec la planification, se concentrant plutôt sur la gestion — rendant “Enterprise Resource Management” un nom plus approprié. Il illustre cela en décrivant comment, dès les premiers temps, de nombreuses entreprises ont commencé à développer leurs propres systèmes logiciels pour gérer les ressources à l’aide des bases de données et des dispositifs de saisie de données disponibles à l’époque.
Observant les points communs dans ce que les entreprises devaient représenter — telles que les paiements, les stocks et les employés —, certaines ont commencé à proposer des versions préemballées de ces représentations de modèles d’affaires. Vermorel indique que c’est ainsi qu’est né ce que nous appelons aujourd’hui les systèmes ERP, bien qu’il suggère de les considérer comme des systèmes d’Enterprise Resource Management, compte tenu de leur véritable fonctionnalité.
Les interfaces utilisateur, typiquement catégorisées comme interfaces CRUD (Create, Read, Update, Delete), fonctionnent sur ces entités. Elles permettent des tâches basiques de saisie de données, comme l’ajout d’un nouveau produit (create), la consultation des attributs d’un produit existant (read), la modification d’un produit (update) et sa suppression (delete). Ce schéma CRUD s’applique à chaque entité au sein du système ERP.
La logique de workflow, le troisième composant, est l’endroit où l’automatisation entre en jeu. Vermorel donne l’exemple d’un processus d’achat, qui commence par l’émission d’un bon de commande, suivie par la réception d’une facture du fournisseur, puis l’expédition des marchandises par ce dernier. Le système ERP suit ces étapes et, si les marchandises ne sont pas reçues, il alerte l’utilisateur. Si les quantités reçues ne correspondent pas aux quantités commandées, le système ERP suggère les étapes suivantes, telles que contacter le fournisseur pour envoyer le reste ou retourner les marchandises. Cette automatisation des tâches routinières conduit à une amélioration significative de la productivité.
Passant à l’évolution des ERP, Vermorel met l’accent sur le rôle des fournisseurs dans la configuration de ces systèmes. Il note que le principal défi pour ces derniers est de gérer la complexité, puisqu’ils doivent déployer un flux sans fin d’entités, d’interfaces utilisateur et de logiques. Il évoque une stratégie en trois volets que les fournisseurs ERP performants utilisent pour maîtriser cette complexité et rester compétitifs.
Premièrement, les fournisseurs adoptent des technologies spécifiques pour rationaliser la production des entités, des interfaces utilisateur et de la logique. Vermorel cite l’exemple de SAP, un fournisseur ERP à succès, qui a inventé son propre langage de programmation spécifique au domaine, ABAP, pour accélérer le processus de mise en œuvre.
Deuxièmement, les fournisseurs ajustent la structure de leurs offres et leur tarification pour refléter le coût et l’effort nécessaires à la production et au support de la diversité des entités. Cela conduit souvent à une tarification modulaire, où les entités sont regroupées en modules ayant un sens commercial, et les clients sont facturés en fonction des modules utilisés.
Les systèmes ERP, qui sont devenus une composante dominante du monde des logiciels d’entreprise, n’arrêtent pas d’évoluer et de s’adapter pour répondre aux besoins des entreprises et à leurs opérations complexes.
Vermorel commence par aborder les incitations et le modèle économique des fournisseurs ERP. Il explique que ces derniers sont incités à développer continuellement de nouveaux modules ou fonctionnalités à vendre à leurs clients. Chaque implémentation réussie est souvent perçue comme une opportunité de créer et de vendre un module additionnel, créant ainsi un cycle perpétuel de ventes et de développement.
La conversation se tourne ensuite vers le choix entre différentes approches ERP. Vermorel suggère que les entreprises devraient se demander si les contraintes intégrées aux ERP depuis la fin des années 70 sont encore pertinentes pour leur situation actuelle. Il remet en cause la nécessité d’un système unique et intégré, arguant que cette approche peut entraîner une complexité accrue et une multitude de cas particuliers. Il propose plutôt de reconsidérer l’hypothèse selon laquelle un seul système doit tout gérer, tout en mettant en garde contre l’utilisation de trop nombreux systèmes distincts.
En évoquant la mise en œuvre de nouveaux systèmes ERP, Vermorel aborde les risques et coûts importants liés à la transition vers un nouveau système ou à la mise à niveau d’un système existant. Il prend l’exemple d’une entreprise ayant gaspillé un demi-milliard d’euros lors d’une mise à niveau SAP en 2009, soulignant que la sémantique des entités au sein d’un système ERP — largement déterminée par les opérateurs du système — change souvent, de manière subtile mais significative, d’une version à l’autre, entraînant de nombreux cas particuliers et défis.
Vermorel estime que les fournisseurs de plus petite taille comportent certains risques, mais qu’il vaut mieux choisir un produit doté d’un noyau restreint, reflétant la complexité et l’ampleur actuelles de l’entreprise. Il déconseille les fonctionnalités excessives susceptibles de perturber les processus et recommande de sélectionner un produit pouvant être complété par une intégration si nécessaire.
La discussion aborde également le choix approprié d’un ERP pour des entreprises de tailles différentes. Vermorel suggère que les petites entreprises de moins de 100 employés devraient opter pour des applications Software-as-a-Service (SaaS) étroites, simples et économiques. Il recommande d’utiliser deux ou trois applications distinctes répondant à des besoins spécifiques plutôt que de s’appuyer sur un ERP complet. Pour les entreprises de taille intermédiaire, d’environ 500 employés, il propose d’envisager un produit ERP intermédiaire plus complexe capable de gérer un éventail plus large de fonctions commerciales typiques. En revanche, pour les grandes entreprises regroupant des milliers d’employés, Vermorel déconseille une approche ERP monolithique et préconise une stratégie de division et de conquête. Il suggère de décomposer le panorama en domaines fonctionnels et de construire ou d’acheter des solutions adaptées à chaque secteur, plutôt que d’essayer de mettre en œuvre un système ERP unique.
Transcription Intégrale
Kieran Chandler: Aujourd’hui, nous allons découvrir comment cette catégorie de logiciels d’entreprise est née et comment les entreprises peuvent choisir parmi la multitude d’options disponibles. Alors, Joannes, peut-être pourrions-nous commencer par examiner les origines des systèmes ERP. Comment sont-ils apparus ?
Joannes Vermorel: Les systèmes ERP sont nés de deux forces motrices dans les années 70. D’ailleurs, le terme ERP a été inventé dans les années 90, mais ce que nous appelons généralement les systèmes ERP a en réalité débuté dans les années 70. Il y a eu deux innovations cruciales. La première était les systèmes de bases de données. Le matériel informatique a évolué jusqu’à un point où une base de données relationnelle est devenue possible. C’était la première innovation. La deuxième innovation fut les lecteurs de codes-barres. En combinant ces deux innovations, on se rend compte que les bases de données relationnelles étaient incroyablement polyvalentes et bien adaptées pour modéliser la plupart des activités commerciales, telles que les paiements, les clients, les fournisseurs et les transactions. Il est devenu évident que ce format était parfaitement adapté pour recevoir des données. Les codes-barres ont été inventés dans les années 50, mais ce n’est qu’avec l’évolution du matériel informatique permettant de stocker et traiter d’importantes quantités de données dans les années 70 qu’ils ont eu un impact significatif. Cependant, leur impact était déjà considérable par rapport au traitement manuel.
Kieran Chandler: Très bien, vous y avez fait allusion. Le nom ERP n’est apparu qu’un peu plus tard, dans les années 90. ERP signifie enterprise resource planning. Mais d’où vient réellement ce nom ? Pourquoi l’ont-ils choisi ?
Joannes Vermorel: En réalité, ERP est un mauvais nom. Malheureusement, son appellation ressemblait plus à un truc marketing introduit dans les années 90. Les systèmes ERP n’ont en fait rien à voir avec la planification. Un nom plus approprié aurait été enterprise resource management. Ce qui s’est passé, c’est que dès que les bases de données et les lecteurs de codes-barres étaient disponibles, de nombreuses entreprises ont réalisé qu’elles voulaient un système informatisé pour gérer toutes ces ressources. Elles ont commencé à déployer leurs propres implémentations logicielles sur la base des bases de données et des dispositifs de saisie de données alors disponibles. D’autres entreprises se sont aperçues que de nombreuses sociétés avaient des besoins similaires en matière de représentation. Par exemple, chaque entreprise doit représenter les paiements, les stocks pour celles traitant des matières physiques, ainsi que la paie des employés. Ainsi, certaines entreprises de logiciels ont pensé : “Proposons des versions préemballées de ces modèles d’affaires”, et c’est ainsi qu’est né le concept d’ERP. De nos jours, il vaut mieux le considérer comme ERP, non pas comme enterprise resource planning, mais plutôt comme enterprise resource management.
Kieran Chandler: Quelles étaient donc les capacités fondamentales des premiers systèmes ERP ?
Joannes Vermorel: Un ERP se compose essentiellement de trois éléments : les entités, les interfaces utilisateur et la logique de workflow. Les entités sont des abstractions basées sur des tables. Par exemple, si vous souhaitez représenter des produits, vous auriez une table appelée “products”, mais il se peut que vous disposiez de plusieurs tables pour différents attributs ou fournisseurs. Les entités représentent des concepts de haut niveau tels que les produits, les clients ou les transactions, par opposition aux détails d’implémentation de bas niveau sur la manière dont ils sont stockés dans une base de données.
Kieran Chandler: Les interfaces utilisateur sont spécifiquement conçues pour les opérations CRUD : create, read, update et delete. La plupart du temps, lorsqu’il s’agit d’entités, vous travaillez simplement avec des interfaces CRUD. Vous saisissez de nouveaux produits, consultez les détails d’un produit existant, modifiez des produits ou les supprimez. Cela s’applique à chaque entité, telles que les transactions, les clients, etc.
Joannes Vermorel: Le troisième élément est la logique de workflow. Prenons l’exemple de l’achat. D’abord, vous émettez un bon de commande, puis le fournisseur confirme par une facture. Vous recevez les marchandises, et vous devez le consigner dans le système. La logique de workflow garantit que vous êtes alerté en cas de manquement et vérifie que les quantités correspondent à la commande. Sur cette base, vous pouvez décider de retourner les marchandises au fournisseur ou de demander les articles restants. L’ERP automatise ces tâches banales et améliore la productivité en gérant les conséquences des opérations commerciales de base.
Kieran Chandler: Dans le domaine des logiciels, dans quelle mesure ont-ils évolué depuis ces toutes premières versions ? Ce qui est très intéressant, c’est que pour comprendre ce changement, il faut saisir les dynamiques qui animent le marché des ERP. Les ERP, et en particulier les fournisseurs ERP, jouent un rôle significatif dans leur implémentation, plutôt que les entreprises qui se chargent elles-mêmes de les mettre en place. Approfondissons cela. La plupart des fournisseurs ont adopté une stratégie en trois volets, que je qualifie d’Allah. Cette stratégie a permis de conquérir le marché. De nos jours, la majorité des fournisseurs ERP performants appliquent ces trois techniques.
Joannes Vermorel: Le principal défi auquel les fournisseurs d’ERP sont confrontés est la complexité. Pour relever ce défi, ils doivent implémenter un flux infini d’entités et fournir des interfaces utilisateur et des workflows qui ont du sens. La première manière d’être plus compétitif consiste à disposer de technologies spécifiques qui simplifient la production d’entités, d’interfaces utilisateur et de logique. Un exemple de ce type de technologie est un langage de programmation spécifique à un domaine. Par exemple, le fournisseur d’ERP à succès, CP, a inventé son propre langage de programmation spécifique à un domaine appelé ab app, ce qui leur a permis de déployer des entités, des interfaces utilisateur et de la logique plus rapidement que la concurrence.
Kieran Chandler: Intéressant. Donc, le deuxième axe consiste à ajuster la structure de l’offre et de la tarification. Pouvez-vous nous en dire plus ?
Joannes Vermorel: Certainement. En tant que fournisseur, le coût de production d’un ERP est fortement influencé par l’effort nécessaire pour implémenter tous les différents éléments. Bien que chaque pièce soit individuellement simple, les ERP concernent la gestion de tâches banales, comme le traitement des reçus. Comme les fournisseurs doivent produire et supporter de nombreuses entités, il est logique de commencer à facturer non pas à l’unité, mais par modules. Les modules regroupent des entités connexes et sont alignés avec des considérations commerciales. Cela soulève un point intéressant sur la manière dont les systèmes ERP facturent leur logiciel.
Kieran Chandler: Absolument. Donc, il y a un coût supplémentaire pour l’ajout de modules. Nous avons déjà abordé le verrouillage des fournisseurs. Les intérêts économiques des fournisseurs d’ERP convergent-ils avec cette tarification basée sur les modules ?
Joannes Vermorel: En effet, dès que vous introduisez des modules, cela offre un moyen efficace d’aligner la tarification sur le coût de mise en œuvre de toutes les fonctionnalités. Cependant, cela crée également des incitations spécifiques. Les fournisseurs sont motivés à continuer de développer de nouveaux modules à vendre en complément de ceux existants. Cela peut mener à un cycle sans fin de vente de modules supplémentaires aux clients. Mais avant d’entrer dans les détails, passons à la troisième idée.
Kieran Chandler: D’accord. Quelle est la troisième idée ?
Joannes Vermorel: La troisième idée est que les fournisseurs d’ERP à succès, en raison de l’immense complexité de capturer tous les détails affinés de la réalité, trouvent des moyens de croître encore plus rapidement grâce aux intégrateurs. Puisqu’une entreprise ne peut tout gérer, les fournisseurs d’ERP collaborent avec des sociétés externes, appelées intégrateurs, pour prendre en charge le dernier kilomètre, assurant ainsi une solution complète et globale.
Kieran Chandler: Donc, Joannes, vous avez mentionné plus tôt que Lokad lançait une nouvelle fonctionnalité pour ses clients. Pouvez-vous nous en dire plus ?
Joannes Vermorel: Oui, tout à fait. Nous lançons une nouvelle fonctionnalité pour nos clients. Elle implique de nouvelles entités, une nouvelle interface utilisateur et une nouvelle logique. Nous créons un réseau de partenaires appelés intégrateurs pour mettre en œuvre cette fonctionnalité. D’un point de vue du modèle économique, c’est intéressant pour les entreprises fournisseurs d’ERP car elles peuvent externaliser le coût et le risque associés à cette fonctionnalité. Il existe une longue traîne de fonctionnalités pouvant être sous-traitées à des entreprises tierces.
Kieran Chandler: Donc, les éditeurs de logiciels transfèrent le risque aux intégrateurs et, en fin de compte, à leurs clients. Les intégrateurs ont leurs propres incitations, qui peuvent ne pas être complètement alignées avec celles de l’éditeur. Est-ce exact ?
Joannes Vermorel: Exactement. Les intégrateurs sont incités à fournir aux clients un haut niveau de personnalisation parce qu’ils sont mieux rémunérés pour des modules sur-mesure plutôt que pour des modules intégrés. Ils peuvent convaincre les clients en affirmant que leur entreprise est unique et nécessite une solution reflétant cette singularité. C’est une dynamique intéressante.
Kieran Chandler: Je vois. Donc, il existe différentes approches que les entreprises peuvent adopter en matière d’ERP. Comment déterminer ce qui constitue une bonne approche et ce qui en est une mauvaise ?
Joannes Vermorel: De nos jours, lorsqu’on considère les choix d’ERP, il faut se demander si toutes les contraintes intégrées dans les ERP à la fin des années 70 sont encore pertinentes pour votre situation. Cela dépend de plusieurs facteurs. Par exemple, l’idée qu’il faut tout intégrer dans un seul système est souvent absurde parce que la complexité ne croît pas de manière linéaire. Ajouter plus d’entités au système entraîne plus de cas limites et des variations dans ce que différentes industries considèrent comme un « produit ».
Kieran Chandler: Donc, vous dites qu’il faut revoir l’hypothèse selon laquelle nous avons toujours besoin d’un système unique pour tout gérer ?
Joannes Vermorel: Exactement. Cette hypothèse n’est plus valable. Avoir 100 systèmes distincts qui nécessitent une coordination est un défi, mais avoir un système maître censé tout résoudre est également problématique. Lorsque vous souhaitez apporter des modifications à un tel système, cela devient un projet colossal affectant toutes les fonctions de l’entreprise.
Kieran Chandler: Je comprends. Il semble que la transition vers un nouveau système puisse être assez difficile. Certaines entreprises ont connu des échecs coûteux en tentant de passer à de nouveaux ERP. Dans quelle mesure cette transition est-elle réalisable ?
Joannes Vermorel: En effet, la transition vers un nouvel ERP peut être un véritable défi. Nous avons vu des entreprises gaspiller des milliards de dollars en tentant de telles transitions. Ce n’est pas une tâche facile en pratique.
Kieran Chandler: En 2009, ils ont gaspillé un demi-milliard d’euros pour une mise à niveau ASAP. Ce n’était même pas un déploiement, juste une mise à niveau. La question est donc la suivante : est-il plus difficile de mettre à niveau un ERP que d’en migrer vers un nouveau ?
Joannes Vermorel: C’est une question très intéressante. De manière surprenante, la mise à niveau d’un ERP est généralement plus difficile que de passer à un nouveau. Cela peut sembler contre-intuitif, mais c’est ce que j’ai observé. Lorsque vous migrez vers un nouvel ERP, vous n’êtes pas sous l’illusion que ce sera une entreprise colossale. Cependant, quand vous y pensez comme à une simple mise à niveau, cela peut sembler simple, alors qu’en réalité, c’est très, très compliqué.
Le problème est que lorsque vous passez d’une version à l’autre, il y a un décalage sémantique dans les entités. Vous voyez, les ERP consistent avant tout à représenter des entités reflétant divers aspects de votre entreprise, comme les produits. On pourrait penser que la sémantique de ces entités dans un ERP est définie par le fournisseur, mais ce n’est pas entièrement vrai. La sémantique finale de toute entité réside dans l’œil de l’opérateur, la personne qui interagit avec le système et effectue la saisie des données ainsi que le workflow.
Donc, la véritable sémantique d’une entité est déterminée par la personne qui exploite l’ERP. Malheureusement pour les fournisseurs d’ERP, ils n’ont pas beaucoup de contrôle sur ce que les utilisateurs font réellement avec le produit. Ils peuvent fournir des recommandations et des programmes de formation, mais en fin de compte, c’est compliqué. Certaines entreprises peuvent décider d’avoir une sémantique légèrement différente pour faire fonctionner l’ERP dans leur situation spécifique. Ce n’est pas parce qu’elles sont rebelles, c’est ce qu’il faut pour que l’ERP fonctionne.
Cependant, le problème se pose lorsque vous passez à la version suivante. Vous pouvez rencontrer de nombreux cas limites subtils où l’entité ne signifie soudainement plus exactement la même chose en raison de nouveaux développements et d’une myriade de cas particuliers.
Kieran Chandler: C’est intéressant. Donc, d’un côté, vous avez ces approches monolithiques de grande envergure, et de l’autre, de plus petites entreprises d’ERP plus spécialisées. Dans quelle mesure peut-on avoir confiance en ces petites entreprises qui pourraient ne pas survivre dans la prochaine décennie ?
Joannes Vermorel: Si vous êtes une petite entreprise, vous souhaitez un système où la complexité est proportionnée à votre échelle. Les produits ERP ont tendance à devenir de plus en plus complexes avec le temps. Ainsi, si vous êtes une jeune entreprise, âgée peut-être de seulement cinq ans, et que vous croissez rapidement, il serait dommage de rester avec un ERP vieux de trois ou quatre décennies. Ces anciens produits peuvent être incroyablement complexes, avec des centaines ou même des milliers de tables et d’entités. Gérer une telle complexité peut être accablant.
Donc, mon conseil est de considérer des entreprises ERP plus récentes, même si elles comportent un certain niveau de risque. Méfiez-vous de vous noyer sous un amas de complexité. D’après mon expérience à la tête de Lokad pendant plus d’une décennie, je n’ai jamais vu une entreprise faire face à une situation dramatique uniquement à cause de son choix d’ERP. Cependant, déployer un produit bien plus complexe que votre échelle peut en réalité être préjudiciable, voire tuer votre entreprise. J’ai vu cela se produire fréquemment, où des entreprises peinent parce qu’elles ont adopté un logiciel tout simplement trop complexe et chargé en fonctionnalités pour elles.
Kieran Chandler: Il semble que lorsqu’il s’agit de choisir un logiciel, avoir un noyau solide et des applications interconnectées soit crucial pour une entreprise en croissance. Joannes, pourriez-vous développer cette idée ?
Joannes Vermorel: Absolument. L’essence contre-intuitive de la chose, c’est qu’il vaut mieux avoir quelque chose avec un noyau étroit qui reflète votre complexité et votre échelle actuelles, même s’il manque encore certaines fonctionnalités. Vous pouvez toujours compléter les éléments manquants par le biais d’intégrations. En revanche, avoir trop de fonctionnalités conflictuelles peut engendrer des problèmes. Les fonctionnalités inutilisées tendent à semer le chaos dans vos processus et à vous empêcher d’exécuter des tâches simples. Les logiciels entièrement intégrés rendent difficile la suppression ou la modification de certaines fonctionnalités sans perturber l’ensemble du système.
Kieran Chandler: Donc, choisir un produit plus petit n’élimine pas entièrement ces problèmes ?
Joannes Vermorel: Non, l’ampleur et l’importance de ces problèmes dépendent de la complexité et des entités du logiciel. Toutefois, l’échelle de l’entreprise joue également un rôle. Pour les petites entreprises de moins de 100 personnes, il est conseillé de trouver une solution étroite, simple et économique, comme une application SaaS. Il se peut que vous ayez besoin de deux ou trois applications pour couvrir différents domaines, tels que les ressources humaines, la paie et la gestion des stocks. Il n’est pas nécessaire d’avoir un ERP unique qui englobe tout. Assurez-vous simplement que ces applications disposent d’API pour extraire les données afin de pouvoir les intégrer plus tard si nécessaire.
Kieran Chandler: Cela a du sens. Qu’en est-il des entreprises de taille intermédiaire ?
Joannes Vermorel: Pour les entreprises de taille intermédiaire, d’environ 500 employés, un produit ERP plus complet pourrait être envisagé. Il sera plus compliqué, avec de nombreuses tables et fonctionnalités. À ce stade, vous avez divers aspects typiques de l’entreprise à gérer, et un ERP peut couvrir ces besoins. Cela peut nécessiter un projet de mise en œuvre plus long et un bon intégrateur, mais il peut offrir la fonctionnalité souhaitée.
Kieran Chandler: Cela est plus productif comparé aux petites applications qui commencent à montrer leurs limites. Ensuite, si vous êtes plus grand, je dirais que la situation change à nouveau. Si vous êtes plus grand, disons, une entreprise de 5 000 employés… Vous savez, une grande entreprise. Alors, typiquement, je dirais qu’il y a deux choses qui entrent vraiment en jeu. Premièrement, vous devez les décomposer en éléments plus petits. Vous savez, le monolithe ne va tout simplement pas fonctionner si vous êtes grand. Si vous optez pour, disons, un ERP monolithique, ce que font la plupart des grandes entreprises… Je dirais que la plupart… c’est-à-dire, ce sera moche. Cela prendra des années. Ce sera incroyablement coûteux.
Joannes Vermorel: Si vous regardez ce que font les très grandes entreprises les plus performantes, elles déploient généralement, je dirais, des solutions assez sur-mesure. Et elles ont de très bonnes raisons. Si vous êtes une grande entreprise, il y a de fortes chances que vous disposiez d’un avantage concurrentiel unique qui n’est pas trivial. Il est intégré dans votre organisation, qui est grande, complexe, et peut-être avez-vous réalisé des acquisitions. Vous pourriez ainsi avoir, dès le départ, un paysage de génie erratique. Plutôt que de dire « Je veux un ERP pour tout régir », ce qui fonctionnait lorsque vous étiez, disons, 500 employés, cela devient très difficile quand vous êtes 5 000 employés. Mon conseil est donc de diviser pour mieux régner. Ce type d’approche, que je préconisais lorsque vous étiez très petit et que vous aviez quelques applications, peut être réexaminé d’une toute autre manière lorsque vous êtes grand.
Pour résumer, je vais diviser le paysage en, je ne sais pas, peut-être jusqu’à une douzaine de domaines fonctionnels. Ensuite, je vais construire ou acheter dans chacun de ces domaines, en fonction de la qualité des fournisseurs disponibles. Et le plus grand défi, ce que je recommanderais à ces grandes entreprises, est de briser le dogme selon lequel il faudrait un ERP unique pour tout régir. Je pense que c’est en grande partie… enfin, c’est surtout absurde. Et si vous regardez des acteurs ultra-compétitifs, disons Amazon, Alibaba, Rakuten, Zalando, ces acteurs technologiques qui doivent gérer la supply chain physique, alors, je ne parle pas de Microsoft, qui est, disons, presque… pas complètement un acteur purement digital. Vous savez, ils ont l’Xbox. L’Xbox est un produit très physique. Mais si vous observez des entreprises reconnues pour être au sommet de leur art dans la gestion d’une supply chain physique, comme Amazon, elles ont toutes opté pour une approche de division pour mieux régner dans leur paysage applicatif, où, de façon agressive, elles adoptent une stratégie de build or buy. Et fondamentalement, aucune de ces entreprises n’a réellement un ERP. Elles ont des listes de produits. Certains d’entre eux seraient plutôt proches d’un ERP. Et la plupart de ces entreprises ont d’ailleurs développé elles-mêmes leurs systèmes pour des parties spécifiques de ce qui serait typiquement désigné comme un module d’ERP.
Kieran Chandler: Bon, nous allons devoir conclure ici, mais merci beaucoup pour votre temps ce matin.
Joannes Vermorel: Merci, Kieran.
Kieran Chandler: C’est tout pour cette semaine. Au revoir pour le moment.
