Progiciel de Gestion Intégré (ERP)

Les Progiciels de Gestion Intégré (ERP) désignent une catégorie de logiciel d’entreprise qui supporte les opérations courantes de l’entreprise et suit ses ressources, notamment la trésorerie, les matières premières, les travaux en cours, les produits finis, les commandes clients, les bons de commande et la paie. Les ERP incluent généralement de nombreux modules destinés aux fonctions principales de l’entreprise, c’est-à-dire la comptabilité, les achats, la distribution, la finance, les ventes, … et offrent une intégration étroite entre ces modules pour faciliter le flux d’informations (transactionnelles) entre les fonctions. Les ERP sont construits sur des bases de données relationnelles et présentent typiquement une conception très étendue : un grand nombre d’entités (par exemple, produits, clients, factures, etc.), de nombreux écrans et un haut degré de configurabilité.

Origine et motivation

Dans les années 70, il est progressivement devenu évident que les dossiers électroniques présentaient de multiples avantages par rapport aux traces papier traditionnelles. Les dossiers électroniques devenaient moins chers, plus rapides et plus fiables que les dossiers papier. Deux inventions antérieures aux ERP ont joué un rôle clé dans l’adoption des dossiers électroniques : les lecteurs de codes-barres (années 1950) et les bases de données relationnelles (années 1970). Les lecteurs de codes-barres offraient une méthode supérieure pour gérer les flux de marchandises, augmentant la productivité tout en réduisant les erreurs administratives. Pourtant, bien que les lecteurs de codes-barres aient considérablement amélioré l’acquisition des données dans de nombreuses situations, le stockage, l’organisation et le traitement des dossiers électroniques restaient un problème partiellement résolu pendant deux décennies. Les bases de données relationnelles furent la réponse de l’industrie logicielle à ce problème à la fin des années 70 et, cinq décennies plus tard, elles demeurent la pratique dominante en matière de gestion des données d’entreprise.

Cependant, les systèmes de bases de données relationnelles bruts, tels qu’ils étaient généralement vendus au début des années 80, se révélèrent très coûteux à mettre en œuvre, chaque entreprise devant réinventer la manière de représenter tout dans sa base de données : produits, clients, factures, paiements, etc. Ainsi, dans les années 80, une série de sociétés spécialisées dans le logiciel fit son apparition en proposant des systèmes relationnels « préconfigurés ». Ces produits seront par la suite collectivement désignés sous le terme d’ERP, un terme inventé dans les années 90. Malheureusement, l’acronyme ERP est un abus de langage ; il aurait fallu parler de gestion des ressources d’entreprise et non de planification. En effet, la planification n’est, au mieux, qu’une préoccupation secondaire pour les ERP. Comme le détaille ce qui suit, l’analytique prédictive est essentiellement en contradiction avec la conception fondamentale des ERP.

Historiquement, les ERP ont gagné en popularité car ils rationalisaient des séries d’opérations qui nécessitaient auparavant d’importants efforts administratifs. Par exemple, l’émission d’un bon de commande à un fournisseur nécessitait le remplissage d’un formulaire avec le nom et l’adresse du fournisseur. Les lignes de commande devaient contenir uniquement des références de produits valides. Ensuite, lors de la réception des marchandises, les quantités reçues devaient correspondre à celles figurant sur le bon de commande initial, et une fois la livraison jugée conforme, un ordre de paiement devait être généré à partir d’un modèle indiquant le montant correct, la date correspondant aux conditions de paiement du fournisseur et identifiant correctement le numéro de compte bancaire du fournisseur. Tout cela se retrouve dans l’ERP et des contrôles de cohérence peuvent être facilement automatisés.

Le marché des ERP a connu une croissance rapide à la fin des années 90, principalement alimentée par les progrès constants du matériel informatique (processeur, mémoire, stockage), devenu accessible aux entreprises de toutes tailles.

Dans les années 90, les ERP sont devenus le noyau logiciel de la plupart des grandes entreprises lorsque l’activité reposait principalement sur le flux de marchandises. En revanche, les entreprises principalement orientées vers les services adoptaient généralement un logiciel de CRM (Customer Relationship Management) comme cœur de leur système. Les ERP et les CRM partagent de nombreux attributs, notamment leur conception commune reposant sur des bases de données relationnelles. Les ERP adoptent généralement une approche centrée sur les transactions pour la plupart de leurs fonctionnalités, tandis que les CRM adoptent une approche centrée sur le client.

La conception des ERP

Les ERP sont divers, car le marché comprend de nombreux fournisseurs qui n’ont cessé de proposer plusieurs versions de leurs produits ERP sur plusieurs décennies et pourtant, au cœur, la plupart des implémentations suivent des lignes de conception très similaires. Les ERP ont émergé en tant que couches logicielles « préconfigurées » mises en œuvre sur des bases de données relationnelles. Ainsi, le processus de conception des ERP implique de recenser :

• entités, c’est-à-dire tous les concepts ou objets que l’ERP doit représenter, tels que produits, paiements, stocks, fournisseurs… Chaque entité peut impliquer une ou plusieurs tables dans la base de données relationnelle sous-jacente. La plupart des ERP définissent des centaines d’entités, et jusqu’à des milliers pour les ERP les plus complexes.
• interfaces utilisateur qui permettent aux utilisateurs finaux de visualiser et de modifier les données des entités. Ces interfaces sont dominées par la conception CRUD (Créer / Lire / Mettre à jour / Supprimer), qui représente les opérations de base attendues par les utilisateurs lorsqu’ils traitent des entités.
• logique métier qui fournit des comportements automatisés éliminant la nécessité de nombreuses tâches administratives, pouvant être automatisées sur la base de règles bien définies, telles que la conversion de commandes clients en factures clients.

Comme les entreprises sont incroyablement diverses et complexes, un flux incessant de besoins en nouvelles entités ou en entités affinées, en interfaces utilisateur et en logiques métier est nécessaire pour couvrir l’évolution des pratiques commerciales. Cela représente un effort colossal et permanent de la part des fournisseurs d’ERP. Ce défi est ensuite accentué par toutes les ambiguïtés qui apparaissent lorsqu’il s’agit de servir des secteurs très diversifiés. Un même terme, tel que « paiement », reflète des réalités et des processus très différents d’un secteur à l’autre. En informatique, la complexité tend à avoir des coûts non linéaires, c’est-à-dire que supporter deux fois plus de fonctionnalités dans un produit coûte bien plus que deux fois le coût initial.

En conséquence, les fournisseurs d’ERP ont adopté une série de stratégies pour rendre leurs investissements logiciels plus compétitifs.

Technologie

Pour faire face à la complexité, la première stratégie adoptée par les fournisseurs d’ERP consiste à développer des technologies dans le but explicite de réduire le coût associé à la gestion de cette complexité.

En particulier, de nombreux fournisseurs d’ERP ont développé des langages DSL (programmation spécifique au domaine) destinés à compléter le langage de requête sous-jacent – généralement une variante de SQL de nos jours – de la base de données relationnelle. Grâce à un DSL bien conçu, étendre l’ERP (c’est-à-dire ajouter de nouvelles entités, interfaces ou logiques) pour couvrir les spécificités d’une entreprise donnée peut se faire avec moins de ressources que si l’on devait entreprendre le même effort avec un langage de programmation généraliste.

Depuis les années 2000, les fournisseurs d’ERP open source – apparus grâce aux bases de données relationnelles open source rendues disponibles à la fin des années 90 – ont généralement adopté une stratégie alternative de plug-in (au lieu des DSL), où l’ERP est conçu pour être étendu par l’introduction de code personnalisé, adapté à chaque entreprise cliente, écrit dans le même langage de programmation généraliste que l’ERP lui-même. Cette stratégie est plus simple à mettre en œuvre pour le fournisseur d’ERP (pas de DSL à concevoir) et est en adéquation avec la nature open source de l’ERP.

Offre

À mesure que le coût de mise en œuvre et de support des fonctionnalités augmente avec leur nombre total, la plupart des fournisseurs d’ERP adoptent une stratégie de tarification modulaire : les fonctionnalités sont regroupées en « modules », qui se concentrent sur des domaines fonctionnels distincts au sein de l’entreprise : gestion des stocks, finance, paie, etc. L’ERP est vendu par module, permettant aux entreprises clientes de sélectionner les modules les plus urgents et de reporter les autres pour des investissements ultérieurs.

La stratégie de tarification modulaire offre également au fournisseur d’ERP une stratégie naturelle de montée en gamme, où la base de clients existante devient la cible privilégiée pour les ventes futures. Les domaines d’activité qui n’étaient pas initialement couverts par l’ensemble initial des modules de l’ERP obtiennent de nouveaux modules dédiés qui peuvent, à leur tour, être vendus aux entreprises clientes.

Cette stratégie de tarification modulaire est un mécanisme efficace pour faire face à la complexité car elle fournit un retour d’information direct au fournisseur d’ERP sur les domaines fonctionnels où la volonté de payer est la plus forte. Ainsi, elle aide le fournisseur à prioriser correctement ses efforts en ingénierie logicielle.

Écosystème

Chaque fonctionnalité supplémentaire ajoutée à l’ERP tend à générer des rendements décroissants pour le fournisseur d’ERP qui a correctement priorisé ses efforts en ingénierie logicielle¹. En effet, si cette fonctionnalité n’avait pas été ajoutée auparavant, c’est probablement parce qu’elle ne concernait pas suffisamment d’entreprises dès le départ. Ensuite, les organisations elles-mêmes – y compris les fournisseurs d’ERP – tendent également à subir des déséconomies d’échelle car l’ajout d’ingénieurs logiciels supplémentaires à un produit logiciel est notoirement connu pour ne pas générer des gains linéaires en termes d’améliorations apportées au produit.

Ainsi, la plupart des fournisseurs d’ERP adoptent une stratégie d’écosystème pour déléguer les derniers efforts de développement nécessaires à la mise en service de l’ERP pour une entreprise donnée à des sociétés tierces, généralement appelées intégrateurs. Ces intégrateurs facturent aux entreprises clientes la mise en œuvre et le déploiement de toutes les capacités qui ne sont pas offertes par l’ERP « brut ». Historiquement, jusqu’aux années 2000, lorsque les entreprises adoptaient les ERP pour la première fois, le travail des intégrateurs se concentrait généralement sur l’introduction de capacités supplémentaires pour l’ERP. De nos jours, cependant, la plupart des projets ERP sont en réalité des mises à niveau, puisqu’un ERP hérité est déjà en place. Ainsi, la valeur ajoutée principale de l’intégrateur est d’assurer une transition en douceur de l’ancien ERP vers le nouveau. En pratique, ce travail implique la migration des données et des processus entre les systèmes.

Contrairement aux fournisseurs d’ERP dont la stratégie commerciale est principalement axée sur l’ERP lui-même, considéré comme un actif de propriété intellectuelle (IP), les intégrateurs adoptent généralement une tarification basée sur le nombre de jours-homme. Ils facturent leur travail en fonction du nombre de jours travaillés et la propriété intellectuelle du travail réalisé revient, par contrat, généralement à l’entreprise cliente elle-même.

Développer un écosystème diversifié d’intégrateurs, tant en termes de zones géographiques que de secteurs d’activité, est une façon efficace d’atténuer la complexité inhérente au développement des ERP. Presque tous les grands fournisseurs d’ERP ont développé d’importants réseaux d’intégrateurs.

Les limites des ERP

Les ERP héritent de la plupart des limitations de leurs systèmes de bases de données relationnelles sous-jacents². Ensuite, d’autres limitations découlent des stratégies d’atténuation de la complexité que nous venons de décrire dans la section précédente. Ces limitations sont particulièrement intéressantes car il s’agit de limitations de conception et, par conséquent, il est peu probable qu’elles soient résolues par de nouvelles versions des ERP, ou plutôt que résoudre ces limitations impliquerait de dénaturer les ERP au point qu’il ne serait plus pertinent de désigner ces produits logiciels comme des ERP.

Défavorable aux lectures ou écritures grossières

Les bases de données relationnelles utilisées par les ERP offrent les propriétés ACID (Atomicité, Cohérence, Isolation, Durabilité) avec une conception largement orientée vers une charge de travail impliquant principalement de petites opérations de lecture et d’écriture, qui doivent être exécutées avec de faibles latences – typiquement une fraction de seconde – avec un volume de lectures et d’écritures à peu près équilibré. Une analyse détaillée des bases de données relationnelles dépasse le cadre du présent article, mais cette observation concernant la charge de travail prévue pour les ERP explique à elle seule de nombreuses limitations mal comprises des ERP.

En raison de leur conception basée sur des bases de données relationnelles, les ERP sont en grande partie inadaptés aux analytics, aux statistiques et aux rapports dès lors que la quantité de données est non triviale. Accéder à une quantité significative de données dans un ERP – alors que les opérations commerciales sont en cours – pose toujours problème, car lorsque le système est saturé par un trop grand nombre d’opérations de lecture ou d’écriture, il ralentit. En pratique, cela signifie que les opérations routinières, telles que le traitement des codes-barres, ralentissent également. Dans le pire des cas, l’ensemble de l’entreprise s’arrête. Ainsi, chaque opération dans l’ERP, qu’il s’agisse de lecture ou d’écriture, doit rester petite, idéalement « triviale ». La quantité de données pouvant être considérée comme non triviale a considérablement augmenté au cours des quatre dernières décennies, parallèlement à l’apparition de matériel informatique plus performant et moins cher. Cependant, les entreprises ont tiré parti de ces progrès pour augmenter considérablement la quantité de données intégrées dans leurs ERP. En conséquence, les systèmes ERP actuels ne sont généralement pas perceptiblement plus rapides qu’ils ne l’étaient il y a deux décennies.

Par exemple, les ERP conviennent bien à l’affichage du niveau de stocks d’un SKU, ou à la mise à jour de sa valeur lorsqu’une unité est prélevée ou chargée, mais ils ne sont généralement pas adaptés à l’affichage de la chronologie quotidienne consolidée des variations de stocks d’un SKU sur les trois dernières années. L’ensemble du segment Business Intelligence (BI) des produits logiciels est apparu dans les années 90 comme la réponse de l’industrie aux limitations analytiques des ERP (et des CRM par ailleurs). Contrairement aux ERP, les outils de BI sont conçus autour d’hypercubes en mémoire, généralement désignés sous le terme OLAP (Online Analytical Processing). En renonçant aux propriétés ACID, les systèmes OLAP deviennent dramatiquement plus efficaces au niveau matériel que les bases de données relationnelles pour fournir des statistiques agrégées, telles que les ventes par jour, par magasin, par catégorie, etc.

Il est intéressant de noter que la plupart des fournisseurs d’ERP ne semblaient pas être pleinement conscients de cette limitation de conception dans leurs propres produits, même ceux apparus après les années 90, lorsque le segment BI était la preuve vivante de cet état de fait. Par exemple, la plupart des fournisseurs d’ERP se sont aventurés dans des fonctionnalités de prévision de la demande qui sont, par conception, totalement incompatibles avec leur base de données relationnelle sous-jacente – encore plus que les simples fonctionnalités de reporting. La prévision nécessite l’accès à l’historique complet des données transactionnelles de l’entreprise : ventes, retours, niveaux de stocks, remises, etc. Bien que le calcul soit généralement prévu pour être effectué en batch durant la nuit, atténuant ainsi le problème de la saturation des ressources mentionné ci-dessus, les bases de données relationnelles engendrent d’énormes surcharges accidentelles lorsqu’il s’agit de réaliser ce type de calcul. En conséquence, de nos jours, la plupart des ERP disposent de fonctionnalités de prévision « héritées »³ qui sont tombées en désuétude depuis des années, voire des décennies.

Défavorable aux paradigmes nouveaux ou distinctifs

La stratégie de catalogage des entités utilisée par les fournisseurs d’ERP ne s’adapte pas linéairement en termes de gestion de la complexité. Des outils plus performants, comme discuté ci-dessus, n’apportent qu’un soulagement linéaire – par rapport au nombre d’entités – alors que les coûts de complexité augmentent de façon superlinéaire. En conséquence, de nouveaux paradigmes ou des paradigmes distinctifs s’avèrent habituellement coûteux tant en termes de coûts que de délais d’intégration, atteignant fréquemment le point où il est préférable de contourner totalement l’ERP. Ces situations sont diverses, nous en énumérerons quelques-unes ci-dessous, mais elles se résument toutes de manière similaire à des paradigmes difficiles à intégrer parce qu’ils sont apparus tard dans le processus de développement de l’ERP⁴.

La réalisation d’une disponibilité opérationnelle nulle est difficile car, comme indiqué ci-dessus, toute lecture ou écriture importante met l’ERP à risque d’un ralentissement du système. Ainsi, toutes ces opérations sont généralement effectuées sous forme de traitements en batch nocturnes, lorsqu’il y a peu ou pas d’opérations en cours. Pourtant, cette conception est en contradiction avec les exigences du e-commerce, apparues relativement tard dans l’histoire des ERP. En conséquence, la plupart des fournisseurs d’ERP ont largement séparé leur module de e-commerce, tirant fréquemment parti d’un système de base de données distinct, brisant ainsi la règle implicite de conception selon laquelle tous les modules de l’ERP résident dans la même base(s) de données. Par conséquent, les modules de e-commerce adossés à l’ERP tendent à être aussi difficiles et coûteux à déployer que des applications tierces.

Traiter avec des secteurs verticaux de remanufacturation où les biens suivent des flux cycliques complexes (c’est-à-dire, des réparations), alors que les ERP traditionnels sont fortement orientés vers des flux allant des producteurs aux consommateurs – comme on le retrouve couramment dans les FMCG et la distribution. Bien que la plupart des entités pertinentes nécessaires aux fins de remanufacturation (c’est-à-dire, produits, stocks, commandes) existent déjà dans les ERP, leurs conceptions sont généralement en complète contradiction avec les exigences de la remanufacturation. Il est fréquemment plus simple de réimplémenter entièrement ces entités plutôt que d’essayer de recycler celles d’un ERP traditionnel dans ces secteurs verticaux.

Fournir des latences garanties faibles, par exemple en dessous du seuil de perception humaine (c’est-à-dire en dessous de 50ms), est difficile car ni l’ERP ni sa base de données relationnelle n’ont été conçus avec de telles exigences en tête. Pourtant, piloter des systèmes hautement automatisés comme des entrepôts robotiques exige ce type de latence afin d’éviter que l’orchestration pilotée par logiciel ne devienne le goulot d’étranglement du système. Ainsi, en pratique, la plupart des domaines associés au traitement « en temps réel » (4) disposent de systèmes dédiés en dehors de l’ERP.

Fait intéressant, il existe des ERP spécialisés – qui ne se désignent pas toujours comme des ERP, cependant – qui ont suivi des voies de développement alternatives afin de faire face précisément à ces situations. Ces ERP ciblent typiquement des secteurs verticaux de niche qui ne sont pas correctement desservis par les ERP traditionnels. Cependant, ces voies de développement alternatives sont généralement en contradiction avec les exigences du marché dominant.

Risques lors des transitions d’ERP

Bien que cela puisse sembler paradoxal, il est généralement bien plus difficile de mettre à niveau un ERP que de le déployer pour la première fois. Les mises à niveau sont réputées pour être des processus s’étalant sur plusieurs années. Même de simples mises à niveau de version de l’ERP – en conservant le même fournisseur – s’avèrent habituellement être des entreprises difficiles de plusieurs mois. De manière anecdotique, cette difficulté fait régulièrement la une, les grandes entreprises publiant des communiqués de presse indiquant que leurs efforts de mise à niveau de l’ERP ont dépassé leur budget de plusieurs centaines de millions de dollars ou d’euros. Dans de telles situations, le fournisseur de l’ERP, l’intégrateur et/ou l’entreprise elle-même se voit reprocher le problème. Pourtant, il semble que la plupart ne reconnaissent pas que de tels problèmes sont intrinsèques aux ERP eux-mêmes, tels qu’ils ont été conçus à travers les forces du marché énoncées ci-dessus.

Les coûts de complexité ne croissent pas de manière linéaire mais de manière superlinéaire. Lorsqu’une entreprise adopte un ERP pour la première fois, elle a le luxe d’adopter progressivement chaque module, un module à la fois. Ainsi, le nombre d’entités / interfaces / logiques impliquées à chaque itération est relativement réduit, et des extensions sur mesure peuvent être progressivement développées pour rendre l’ERP adapté aux besoins de l’entreprise.

Cependant, lorsque l’entreprise doit passer à un autre ERP, elle se retrouve face au problème de devoir transitionner tous les modules simultanément. En effet, les ERP sont, par conception et par forces économiques⁵, des monolithes logiciels construits sur un ensemble restreint de bases de données. Ainsi, lorsque le nouvel ERP doit être déployé, le parcours d’adoption incrémental utilisé pour l’ERP d’origine ne peut être reproduit. L’entreprise doit donc opérer une transition en mode tout-ou-rien. En conséquence, les coûts initiaux de mise en œuvre tendent à être très élevés, tandis que l’état post-déploiement tend à être constitué de situations à moitié réparées qui peuvent prendre plusieurs années à corriger.

Techniquement, ces mises à niveau sont toujours difficiles à mettre en œuvre car l’importation des entités / interfaces / logiques entre l’ancien et le nouveau système n’est pas une opération de correspondance un-à-un. La sémantique des entités évolue au fil du temps. Par exemple, le fournisseur d’ERP avait pu commencer avec une table nommée “Orders” destinée aux commandes clients. Cependant, par la suite, le fournisseur doit répondre à de nouvelles exigences, non prévues à l’origine, de gestion des retours clients. La version suivante de l’ERP recycle la table “Orders” pour les retours clients, cependant ces lignes présentent désormais des quantités de commande négatives. Ce changement apparemment anodin finit par compliquer considérablement la migration de l’ancienne version de l’ERP vers la nouvelle.

Cependant, passer à un nouvel ERP, ou à une version ultérieure du même ERP, n’est pas la seule option pour les entreprises. Plusieurs alternatives sont en réalité disponibles pour réduire les risques liés à la transition. Naturellement, l’ensemble de l’écosystème des fournisseurs d’ERP et des intégrateurs a un vif intérêt financier à promouvoir l’inverse, par souci de survie de leur modèle économique.

Au-delà du monolithe

Les ERP ont émergé en tant que monolithes logiciels, c’est-à-dire des produits logiciels où tous les composants internes sont étroitement couplés – une nécessité pour assurer un déploiement plug-and-play de tous les modules. De plus, jusqu’aux années 2010, construire des systèmes distribués – c’est-à-dire des logiciels qui fonctionnent sur une flotte de machines plutôt que sur quelques machines centrales – était nettement plus difficile et coûteux⁶. Ainsi, dans une large mesure, les fournisseurs d’ERP (dont la plupart existent depuis des décennies) n’avaient d’autre alternative que de construire leurs produits en tant que monolithes.

Néanmoins, à mesure que le cloud computing devenait courant, les outils et bibliothèques – souvent open source – sont devenus plus populaires et accessibles. En conséquence, les coûts et frais généraux associés à la conception d’applications distribuées ont diminué de manière constante au cours de la dernière décennie. L’industrie du logiciel a commencé à revisiter en profondeur la manière dont la valeur ajoutée, historiquement uniquement fournie par les ERP (ou logiciels de type ERP), peut être délivrée.

L’approche moderne du logiciel d’entreprise consiste à décomposer le monolithe en une série d’applications plus petites qui, idéalement, font une chose et la font bien⁷. L’assemblage de ces applications se fait via des APIs (interfaces de programmation d’applications) qui sont précisément destinées à faciliter des intégrations sur mesure dans divers environnements applicatifs. La plupart des APIs sont conçues pour tirer parti d’outils API open source populaires qui réduisent considérablement les coûts de développement associés à ces intégrations sur mesure.

Ces applications présentent parfois des coûts d’intégration initiaux plus élevés que les modules ERP intégrés. Cependant, elles offrent des avantages à long terme considérables car elles réduisent largement les risques liés aux évolutions futures de l’environnement applicatif. L’entreprise a ainsi la possibilité de mettre à niveau ou de remplacer une application à la fois, ce qui s’avère non seulement bien plus facile à exécuter, mais aussi moins coûteux et impliquant moins de risques. Enfin, les applications SaaS (Software as a Service) optent généralement pour une livraison continue de petites modifications incrémentales. Bien que ce modèle engendre une charge de travail continue – mais limitée – pour les équipes informatiques, le processus de changement SaaS est plus organique, moins coûteux et moins risqué comparé aux mises à niveau annuelles ou biennales.

Au-delà des bases de données relationnelles

Les bases de données relationnelles constituent l’épine dorsale par défaut des ERP depuis les années 80. Cependant, depuis les années 2010, des alternatives convaincantes ont émergé. La plus notable est probablement Event Sourcing (ES) couplé avec Command Query Responsibility Segregation (CQRS). Cette approche offre une scalabilité et des latences supérieures tout en permettant des conceptions plus expressives, c’est-à-dire capables de capturer de manière plus précise les intentions commerciales dans diverses situations.

L’essence du event sourcing consiste à traiter chaque changement dans le système comme un événement immuable. Cet aspect d’immuabilité est inspiré par les pratiques comptables : lorsqu’une ligne s’avère incorrecte dans un grand livre, le comptable n’efface pas la ligne pour corriger le problème, il ajoute plutôt une ligne corrective dans le grand livre. Conserver l’historique complet des événements – à supposer que le stockage des données soit suffisamment bon marché pour rendre cette stratégie viable – offre de nombreux avantages : meilleure traçabilité, auditabilité, sécurité… De plus, l’aspect immuable rend les systèmes pilotés par des événements plus faciles à faire évoluer. Les données peuvent être largement copiées et répliquées sans avoir à gérer les modifications de celles-ci.

La conception CQRS reconnaît que, dans la plupart des systèmes, les volumes respectifs de lectures et d’écritures sont très déséquilibrés. Dans de nombreuses situations, le volume de lectures (de données) dépasse celui des écritures de plusieurs ordres de grandeur. Cependant, les bases de données relationnelles sont conçues pour des volumes (quelque peu) symétriques de lectures et d’écritures. CQRS segmente explicitement les responsabilités entre lectures et écritures, typiquement dans deux sous-systèmes distincts. Cette conception apporte également des avantages, surtout en termes de latence, de scalabilité et d’efficacité matérielle.

Cependant, bien que l’ES et le CQRS soient déjà populaires dans les grandes entreprises technologiques orientées consommateurs et dans le trading quantitatif (finance), ils n’ont commencé à gagner du terrain que très récemment dans les logiciels d’entreprise grand public. En conséquence, les outils ES+CQRS en sont encore à un stade naissant comparé à leurs homologues dans le domaine des bases de données relationnelles. Néanmoins, cette approche offre des moyens non seulement de réduire drastiquement les coûts matériels, mais aussi de comprimer les latences qui restent fréquemment un problème aigu pour la plupart des implémentations ERP.

L’approche de Lokad

Comme les ERP ne sont même pas adaptés aux fins analytiques – d’où la nécessité d’outils de BI (Business Intelligence) – il ne doit pas être surprenant que leur bilan soit médiocre dès que des analyses prédictives sont impliquées. À titre d’exemple anecdotique, aucune des révolutions du machine learning / data science ne s’est produite dans les ERP, et lorsqu’il s’agit de répondre à ce type d’exigences, les équipes se retrouvent invariablement à recourir à des tableurs ou à des scripts ad hoc.

Lokad lui-même est apparu comme une application spécialisée destinée à compléter - et non à remplacer - les ERP en tant que couche analytique dédiée à l’optimisation prédictive de la supply chain. La plupart de nos fonctionnalités principales telles que les capacités de prévision probabiliste, destinées à soutenir des décisions routinières telles que les stocks / les achats / la production / l’assortiment / la tarification, sont tout simplement impraticables à mettre en œuvre à l’intérieur des systèmes ERP.

Notes