00:00:07 Importance des systèmes ERP.
00:02:42 Explication du terme ERP.
00:03:54 Mise en œuvre initiale des systèmes ERP.
00:05:07 Capacités principales des premiers systèmes ERP.
00:07:34 Systèmes ERP : entités, interfaces, logique.
00:09:14 Le rôle des ERP dans l’automatisation des entreprises.
00:09:54 Évolution des ERP et des stratégies.
00:11:32 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 Promotion de solutions ERP personnalisées par les intégrateurs.
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 liées aux mises à niveau des ERP.
00:21:35 Rôle et complications de l’opérateur ERP.
00:22:53 Risques/avantages des fournisseurs ERP spécialisés.
00:25:00 Complexité et défis des systèmes ERP.
00:26:52 Petites entreprises et applications SaaS.
00:28:42 Produits ERP complexes pour les entreprises de taille moyenne.
00:30:16 Grandes entreprises évitant 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, discute de l’évolution des systèmes de planification des ressources d’entreprise (ERP). Retraçant leur apparition dans les années 1970, Vermorel met en évidence deux innovations clés - l’avènement des bases de données relationnelles et des lecteurs de codes-barres - comme cruciales pour le développement des ERP. Il suggère que “Enterprise Resource Management” est un terme plus précis pour ces systèmes, qui sont passés de solutions d’entreprise sur mesure à des représentations de modèles d’entreprise préemballés. Les fonctionnalités modernes des ERP, telles que les interfaces CRUD et la logique de flux de travail, ont automatisé les tâches routinières, améliorant la productivité. Vermorel explore les stratégies des fournisseurs ERP réussis, tels que SAP, pour gérer la complexité du système, et discute également de la sélection et de la mise en œuvre des ERP pour les entreprises de différentes tailles.
Résumé étendu
Dans cette interview, l’animateur Kieran Chandler s’entretient avec Joannes Vermorel, le fondateur de Lokad, pour discuter de l’évolution et de la fonctionnalité des systèmes de planification des ressources de l’entreprise (ERP).
Vermorel expose les origines des systèmes ERP, en les situant dans les années 1970, bien que le terme “ERP” n’ait été inventé qu’à partir des années 90. Selon Vermorel, deux innovations clés ont conduit au développement des systèmes ERP. La première était la progression du matériel informatique jusqu’à ce que les bases de données relationnelles soient possibles. 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é à la modélisation de diverses activités commerciales, telles que les transactions, les paiements, les interactions avec les clients et les fournisseurs.
La deuxième innovation critique mentionnée par Vermorel est l’invention des lecteurs de codes-barres. Bien que les lecteurs de codes-barres aient été inventés dans les années 1950, ce n’est qu’avec les progrès du matériel informatique dans les années 1970 qu’ils ont pu stocker et traiter des quantités importantes de données. La combinaison de ces deux technologies a donné naissance aux systèmes ERP que nous connaissons aujourd’hui.
Vermorel aborde également le terme trompeur d’ERP, affirmant qu’il s’agissait d’un stratagème marketing initié dans les années 90. Il explique que les ERP ont peu à voir avec la planification, mais sont plutôt axés sur la gestion, ce qui rend “Enterprise Resource Management” (gestion des ressources de l’entreprise) un nom plus approprié. Il illustre cela en décrivant comment, à leurs débuts, 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.
En observant les similitudes dans ce que les entreprises devaient représenter, telles que les paiements, les stocks et les employés, certaines entreprises ont commencé à proposer des versions préemballées de ces représentations de modèles commerciaux. Vermorel indique que c’est l’origine de ce que nous appelons maintenant les systèmes ERP, bien qu’il suggère que nous devrions les considérer comme des systèmes de gestion des ressources de l’entreprise, compte tenu de leur fonctionnalité réelle.
Les interfaces utilisateur, généralement catégorisées comme des interfaces CRUD (Create, Read, Update, Delete), fonctionnent sur ces entités. Elles permettent des tâches de saisie de données de base, telles que l’ajout d’un nouveau produit (créer), la visualisation des attributs d’un produit existant (lire), la modification d’un produit existant (mettre à jour) et la suppression d’un produit (supprimer). Ce modèle CRUD s’applique à chaque entité dans le système ERP.
La logique du flux de travail, le troisième composant, est là où l’automatisation entre en jeu. Vermorel donne l’exemple d’un processus d’achat, qui commence par une commande d’achat, puis la réception d’une facture du fournisseur, suivie de l’expédition des marchandises par le fournisseur. Le système ERP suit ces étapes et, si les marchandises ne sont pas réceptionnées, 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 prochaines étapes, 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é.
En ce qui concerne l’évolution des ERP, Vermorel souligne le rôle des fournisseurs dans la conception de ces systèmes. Il note que le principal défi pour les fournisseurs est de gérer la complexité, car ils doivent mettre en œuvre un flux continu d’entités, d’interfaces utilisateur et de logique. Il fait référence à une stratégie “triple” que les fournisseurs d’ERP réussis utilisent pour gérer cette complexité et maintenir leur compétitivité.
Tout d’abord, les fournisseurs adoptent des technologies spécifiques pour rationaliser la production d’entités, d’interfaces utilisateur et de logique. Vermorel cite l’exemple de SAP, un fournisseur d’ERP réussi, 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 de leur tarification pour refléter le coût et les efforts de production et de support de la gamme diversifiée d’entités. Cela conduit souvent à une structure de tarification basée sur des modules, où les entités sont regroupées en modules qui ont un sens commercial, et les clients sont facturés en fonction des modules qu’ils utilisent.
Les systèmes ERP, qui sont devenus une partie dominante du monde des logiciels d’entreprise, évoluent constamment et s’adaptent pour répondre aux besoins des entreprises et à leurs opérations complexes.
Vermorel commence par discuter des incitations et du modèle économique des fournisseurs d’ERP. Il explique que ces fournisseurs sont incités à développer continuellement de nouveaux modules ou fonctionnalités à vendre à leurs clients. Les fournisseurs considèrent souvent chaque mise en œuvre réussie comme une opportunité de créer et de vendre un module supplémentaire au client. Cela crée 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 toujours pertinentes pour leur situation actuelle. Il remet en question 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. Au lieu de cela, il suggère aux entreprises de reconsidérer l’hypothèse selon laquelle un seul système devrait tout faire, tout en mettant en garde contre le fait d’avoir trop de systèmes distincts.
En discutant de la mise en œuvre de nouveaux systèmes ERP, Vermorel aborde les risques et les coûts importants associés à la transition vers un nouveau système ou à la mise à niveau d’un système existant. Il utilise l’exemple d’une entreprise qui a 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 entre les versions, ce qui entraîne de nombreux cas particuliers et défis.
Vermorel estime que les petits fournisseurs présentent certains risques, mais il est préférable de choisir un produit qui a un noyau étroit, qui reflète la complexité et l’échelle actuelles de l’entreprise. Il déconseille les fonctionnalités excessives qui peuvent perturber les processus et recommande de choisir un produit qui peut être complété par une intégration si nécessaire.
La discussion aborde également le choix approprié d’un ERP en fonction de la taille de l’entreprise. Vermorel suggère que les petites entreprises de moins de 100 employés devraient opter pour des applications en tant que service (SaaS) étroites, simples et rentables. Il recommande d’utiliser deux ou trois applications distinctes qui couvrent des besoins spécifiques plutôt que de s’appuyer sur un ERP complet. Pour les entreprises de taille moyenne avec environ 500 employés, Vermorel suggère de considérer un produit ERP de taille moyenne plus complexe qui peut gérer un éventail plus large de fonctions commerciales typiques. Cependant, pour les grandes entreprises avec des milliers d’employés, Vermorel déconseille une approche ERP monolithique et propose plutôt une stratégie de division et de conquête. Il suggère de diviser le paysage en domaines fonctionnels et de construire ou d’acheter des solutions adaptées à chaque domaine, plutôt que de tenter de mettre en œuvre un seul système ERP.
Transcription complète
Kieran Chandler: Aujourd’hui, nous allons découvrir comment cette catégorie de logiciels d’entreprise a été créée et comment les entreprises peuvent choisir parmi la multitude d’options différentes. Alors, Joannes, peut-être pourrions-nous commencer par examiner les origines des systèmes ERP. Comment ont-ils été créés pour la première fois ?
Joannes Vermorel: Les systèmes ERP sont nés de deux forces motrices dans les années 70. Au fait, le terme ERP a été inventé dans les années 90, mais ce que nous appelons généralement les systèmes ERP ont réellement commencé dans les années 70. Il y a eu deux innovations majeures. La première était les systèmes de bases de données. Le matériel informatique a progressé à un point où une base de données relationnelle est devenue possible. C’était la première innovation. La deuxième innovation était les lecteurs de codes-barres. Lorsque vous combinez ces deux innovations, vous réalisez 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 clair que ce format était bien adapté pour recevoir des données. Les codes-barres ont été inventés dans les années 50, mais jusqu’à ce que le matériel informatique ait suffisamment progressé pour stocker et traiter des quantités importantes de données dans les années 70, cela n’avait pas autant d’impact. Cependant, c’était déjà énorme par rapport au traitement manuel.
Kieran Chandler: D’accord, vous en avez touché un mot. Le nom ERP n’est venu que plus tard dans les années 90. ERP signifie planification des ressources de l’entreprise. Mais d’où vient réellement le nom ? Pourquoi ont-ils décidé de cela ?
Joannes Vermorel: En réalité, ERP est un terme inapproprié. Malheureusement, son nom ressemblait davantage à un coup marketing qui est apparu dans les années 90. Les systèmes ERP n’ont pratiquement rien à voir avec la planification. Un meilleur nom aurait été gestion des ressources de l’entreprise. Ce qui s’est passé, c’est qu’à partir du moment où vous aviez à la fois des bases de données et des lecteurs de codes-barres, de nombreuses entreprises ont commencé à réaliser 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 de la base de données et des dispositifs de saisie de données disponibles à l’époque. D’autres entreprises ont réalisé que de nombreuses entreprises ont des besoins similaires en matière de représentation. Par exemple, chaque entreprise a besoin de représenter les paiements, les stocks pour ceux qui traitent des matériaux physiques et la paie des employés. Ainsi, certaines entreprises de logiciels ont pensé : “Créons des versions préemballées de ces modèles d’entreprise”, et c’est là que le concept de l’ERP est né. De nos jours, il est préférable de le considérer comme un ERP, non pas une planification des ressources de l’entreprise, mais plutôt une gestion des ressources de l’entreprise.
Kieran Chandler: Quelles étaient donc les capacités principales 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 flux de travail. Les entités sont les abstractions au-dessus des tables. Par exemple, si vous voulez représenter des produits, vous auriez une table appelée “produits”, mais vous pouvez avoir 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 de mise en œuvre de bas niveau sur la façon dont ils sont stockés dans une base de données.
Les interfaces utilisateur sont spécifiquement conçues pour les opérations CRUD : créer, lire, mettre à jour et supprimer. La plupart du temps, lorsqu’il s’agit d’entités, vous travaillez simplement avec des interfaces CRUD. Vous saisissez de nouveaux produits, vérifiez les détails des produits existants, modifiez les produits ou les supprimez. Cela s’applique à chaque entité, telle que les transactions, les clients, et plus encore.
Le troisième élément est la logique de flux de travail. Prenons l’exemple de l’achat. Tout d’abord, vous émettez un bon de commande, puis le fournisseur confirme avec une facture. Vous recevez les marchandises et vous devez les suivre dans le système. La logique de flux de travail garantit que vous recevez des alertes 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 fastidieuses et améliore la productivité en gérant les conséquences des opérations commerciales de base.
Kieran Chandler: Dans le monde du logiciel, dans quelle mesure ont-ils changé depuis ces premiers logiciels ? Ce qui est très intéressant, c’est que pour comprendre ce changement, il faut comprendre les dynamiques qui stimulent le marché des ERP. Les ERP, en particulier les fournisseurs d’ERP, jouent un rôle important dans la mise en œuvre de ces systèmes, plutôt que les entreprises qui les mettent en œuvre elles-mêmes. Plongeons dans cela. La plupart des fournisseurs ont adopté une stratégie en trois volets, que j’appelle Allah. Cette stratégie a remporté un franc succès sur le marché. De nos jours, la majorité des fournisseurs d’ERP à succès appliquent ces trois techniques.
Joannes Vermorel: Le principal défi auquel sont confrontés les fournisseurs d’ERP est la complexité. Pour relever ce défi, ils doivent mettre en œuvre des flux continus d’entités et fournir des interfaces utilisateur et des flux de travail qui ont du sens. La première façon d’être plus compétitif est de disposer de technologies spécifiques qui rationalisent la production d’entités, d’interfaces utilisateur et de logique. Un exemple de cette technologie est un langage de programmation spécifique au domaine. Par exemple, le fournisseur d’ERP à succès, CP, a inventé son propre langage de programmation spécifique au domaine appelé ab app, qui les a aidés à 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 chemin consiste à ajuster la structure de l’offre et de la tarification. Pouvez-vous développer cela ?
Joannes Vermorel: Certainement. En tant que fournisseur, le coût de production d’un ERP est fortement influencé par l’effort nécessaire pour mettre en œuvre tous les différents éléments. Alors que les éléments individuellement peuvent être simples, les ERP sont conçus pour gérer des tâches fastidieuses, telles que la gestion des reçus. Étant donné que les fournisseurs doivent produire et prendre en charge de nombreuses entités, il est logique de commencer à facturer non pas par entité, mais par modules. Les modules regroupent des entités liées et s’alignent sur des considérations commerciales. Cela soulève un point intéressant concernant la façon dont les systèmes ERP facturent leur logiciel.
Kieran Chandler: Absolument. Donc, il y a un prix supplémentaire pour l’ajout de modules. Nous avons précédemment discuté du verrouillage par le fournisseur. Les intérêts économiques des fournisseurs d’ERP sont-ils alignés sur 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 à développer de nouveaux modules à vendre en plus de ceux existants. Cela peut conduire à un cycle sans fin de vente de modules supplémentaires aux clients. Mais avant d’approfondir les détails de cela, 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 réussis, en raison de la grande complexité de la capture de tous les détails fins de la réalité, trouvent des moyens de croître encore plus rapidement grâce aux intégrateurs. Étant donné qu’une entreprise ne peut pas tout gérer, les fournisseurs d’ERP collaborent avec des entreprises externes appelées intégrateurs pour gérer la dernière étape, garantissant ainsi une solution complète et globale.
Kieran Chandler: Donc, Joannes, vous avez mentionné plus tôt que Lokad introduit une nouvelle fonctionnalité pour ses clients. Pourriez-vous nous en dire plus à ce sujet ?
Joannes Vermorel: Oui, en effet. Nous lançons une nouvelle fonctionnalité pour nos clients. Cela 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é. Du point de vue du modèle commercial, c’est intéressant pour les entreprises fournisseurs d’ERP car elles peuvent décharger le coût et le risque associés à cette fonctionnalité. Il existe une longue liste de fonctionnalités qui peuvent être externalisées à des entreprises tierces.
Kieran Chandler: Donc, les fournisseurs de logiciels transfèrent le risque aux intégrateurs et finalement à leurs clients. Les intégrateurs ont leur propre incitation, qui peut ne pas être complètement alignée sur l’incitation du fournisseur de logiciels. Est-ce correct ?
Joannes Vermorel: Exactement. Les intégrateurs ont une incitation à fournir aux clients un haut niveau de personnalisation car ils sont mieux rémunérés pour les modules sur mesure plutôt que pour les modules intégrés. Ils peuvent convaincre les clients en disant que leur entreprise est unique et nécessite une solution qui reflète leur 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 de systèmes ERP. Comment déterminez-vous ce qui est une bonne approche et ce qui est une mauvaise approche ?
Joannes Vermorel: De nos jours, lorsqu’on envisage des choix ERP, il faut se demander si toutes les contraintes qui ont été intégrées aux ERP à la fin des années 70 sont toujours pertinentes pour votre situation. Cela dépend de plusieurs facteurs. Par exemple, l’idée selon laquelle vous devez tout intégrer dans un seul système est souvent dénuée de sens car la complexité ne s’échelonne pas de manière linéaire. Ajouter plus d’entités au système entraîne plus de cas particuliers et de variations dans ce que différentes industries considèrent comme un “produit”.
Kieran Chandler: Donc, vous dites que nous devons revoir l’hypothèse selon laquelle nous avons toujours besoin d’un seul système pour tout gérer ?
Joannes Vermorel: Exactement. Cette hypothèse n’est plus exacte. Avoir 100 systèmes distincts qui nécessitent une coordination est difficile, mais avoir un seul système maître comme solution ultime pose également problème. Lorsque vous souhaitez apporter des modifications à un tel système, cela devient un projet massif qui affecte 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 essayant de passer à de nouveaux systèmes ERP. Dans quelle mesure est-il pratique de faire cette transition ?
Joannes Vermorel: En effet, la transition vers un nouveau système ERP peut être difficile. 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. Donc, la question est de savoir s’il est plus difficile de mettre à niveau un ERP que de passer à un nouveau ?
Joannes Vermorel: C’est une question très intéressante. Étonnamment, mettre à niveau un ERP est généralement plus difficile que passer à un nouveau. Cela peut sembler contre-intuitif, mais c’est ce que j’ai observé. Lorsque vous migrez vers un nouveau ERP, vous n’avez aucune illusion que cela sera une entreprise massive. Cependant, lorsque vous le considérez simplement comme une mise à niveau, cela peut sembler simple, mais cela peut en réalité être très, très difficile.
Le problème est que lorsque vous passez d’une version à l’autre, il y a un changement sémantique dans les entités. Vous voyez, les ERP sont tous basés sur la représentation d’entités qui reflètent diverses préoccupations de votre entreprise, telles que les produits. Vous pourriez penser que la sémantique de ces entités dans un ERP est définie par le fournisseur, mais ce n’est pas tout à fait 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 de données et les flux de travail.
Ainsi, 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 gens font réellement avec le produit. Ils peuvent fournir des recommandations et des programmes de formation, mais en fin de compte, c’est difficile. Certaines entreprises peuvent décider d’avoir une sémantique légèrement différente pour que l’ERP fonctionne dans leur situation spécifique. Ce n’est pas parce qu’ils sont des rebelles ; c’est ce qu’il faut pour faire fonctionner l’ERP.
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 limites différents.
Kieran Chandler: C’est intéressant. Donc, d’un côté du spectre, vous avez ces approches monolithiques, et de l’autre côté, vous avez des entreprises ERP plus petites et plus spécialisées. Dans quelle mesure pouvez-vous 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 voulez un système où la complexité a du sens par rapport à votre propre échelle. Les produits ERP ont tendance à devenir de plus en plus complexes avec le temps. Donc, si vous êtes une jeune entreprise, peut-être seulement âgée de cinq ans, et que vous avez connu une croissance rapide, il serait erroné de rester avec un ERP qui a trois ou quatre décennies. Ces anciens produits peuvent être incroyablement complexes, avec des centaines, voire des milliers de tables et d’entités. Gérer une telle complexité peut être écrasant.
Donc, mon conseil est de considérer les entreprises ERP plus jeunes, même si elles comportent un certain niveau de risque. Méfiez-vous de vous enfouir dans des tas de complexité. Dans mon expérience de la gestion de Lokad depuis plus d’une décennie, je n’ai pas vu une entreprise confrontée à une situation dramatique uniquement à cause de son choix d’ERP. Cependant, déployer un produit beaucoup plus complexe que votre échelle peut réellement être préjudiciable, voire tuer votre entreprise. Je l’ai souvent vu se produire, où les entreprises luttent parce qu’elles ont adopté un logiciel qui était tout simplement trop complexe et trop riche 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 cela 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 parties manquantes par l’intégration. En revanche, avoir trop de fonctionnalités contradictoires peut causer des problèmes. Les fonctionnalités inutilisées ont tendance à semer le chaos dans vos processus et vous empêchent d’effectuer des tâches simples. Les produits 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. Cependant, 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 rentable comme une application SaaS. Vous pourriez avoir besoin de deux ou trois de ces 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 seul ERP qui englobe tout. Assurez-vous simplement que ces applications disposent d’API pour extraire des données afin de pouvoir les intégrer ultérieurement si nécessaire.
Kieran Chandler: Cela a du sens. Et les entreprises de taille moyenne ?
Joannes Vermorel: Pour les entreprises de taille moyenne, 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 répondre à ces besoins. Cela peut nécessiter un projet de mise en œuvre plus long et un bon intégrateur, mais il peut offrir les fonctionnalités souhaitées.
Kieran Chandler: C’est plus productif par rapport 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, plus… Je veux dire, disons que vous êtes comme une entreprise de 5 000 employés… Vous savez, votre grande entreprise. Alors généralement, je dirais qu’il y a deux choses qui entrent vraiment en jeu. Tout d’abord, vous voulez les diviser en feuilles. Vous savez, le monolithe ne fonctionnera tout simplement pas pour vous si vous êtes une grande entreprise. Si vous optez pour un ERP monolithique, comme la plupart des grandes entreprises le font… Je dirais que la plupart… Je veux dire, ce sera moche. Cela prendra des années. Cela coûtera incroyablement cher.
Joannes Vermorel: Si vous regardez ce que font les meilleures grandes entreprises, elles déploient généralement, je dirais, des choses assez spécifiques. Et elles ont de très bonnes raisons. Si vous êtes une grande entreprise, il y a de fortes chances que vous ayez, par exemple, un avantage concurrentiel unique qui n’est pas une chose simple. Il est intégré dans votre organisation, qui est grande, qui est complexe, et peut-être que vous avez fait des acquisitions. Vous pourriez donc avoir, par exemple, un paysage de génie erratique à la base. Donc, au lieu de dire “Je veux un ERP pour tout régir”, ce qui fonctionnait lorsque vous aviez, par exemple, 500 employés, cela devient très difficile lorsque vous en avez, par exemple, 5 000. Donc ma suggestion est que vous devez essentiellement diviser pour mieux régner. Cette sorte d’approche que je suggérais lorsque vous étiez très petit, vous savez, et que vous aviez quelques applications, vous pouvez la revoir de manière complètement différente si vous êtes une grande entreprise.
Donc, pour dire, je vais diviser le paysage en, je ne sais pas, peut-être une douzaine de domaines fonctionnels. Et ensuite, je vais construire ou acheter dans chaque domaine, en fonction de la qualité des fournisseurs que je peux trouver. Et le plus grand défi, ce que je recommanderais à ces grandes entreprises, c’est de briser le dogme selon lequel vous devez avoir, par exemple, un seul ERP pour tout régir. Je pense que c’est surtout… Je veux dire, c’est surtout absurde. Et si vous regardez des acteurs très, très compétitifs, disons Amazon, regardons Alibaba, regardons Rakuten, regardons Zalando, vous savez, ces acteurs technologiques qui doivent gérer la supply chain physique. Donc, je ne parle pas de Microsoft, qui est, par exemple, un acteur purement… presque… Ce n’est pas complètement un acteur purement numérique. Vous savez, ils ont la Xbox. La Xbox est un produit très physique. Mais si vous regardez les entreprises qui ont été reconnues comme étant au sommet de leur jeu pour gérer une supply chain physique comme Amazon, elles ont toutes adopté une approche très… Je dirais, diviser pour mieux régner dans leur paysage applicatif, où essentiellement, elles optent de manière très agressive pour une approche de construction ou d’achat. Et elles… Et fondamentalement, aucune de ces entreprises n’a vraiment un ERP. Elles ont des listes de produits. Certains d’entre eux seraient plus proches d’un ERP. Et la plupart de ces entreprises ont également écrit leurs propres systèmes, pour des parties spécifiques de ce qui serait généralement appelé un module ERP.
Kieran Chandler: Eh bien, nous devons 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.
