Progiciel de Gestion Intégré (ERP)

Le Progiciel de Gestion Intégré (Enterprise Resource Planning ou ERP en anglais) désigne une classe de logiciels d’entreprise qui soutiennent les opérations courantes de l’entreprise et suivent ses ressources, notamment la trésorerie, les matières premières, les travaux en cours, les produits finis, les commandes clients, les commandes d’achat et la paie. Les ERP comprennent généralement de nombreux modules destinés aux fonctions commerciales de base, telles que 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 généralement une conception très étendue : un grand nombre d’entités (par exemple, produits, clients, factures, etc.), de nombreuses interfaces et un degré élevé de configurabilité.

Origine et motivation

Au cours des années 70, il est devenu évident que les enregistrements électroniques présentaient de nombreux avantages par rapport à la trace papier traditionnelle. Les enregistrements électroniques devenaient moins chers, plus rapides et plus fiables que les enregistrements papier. Deux inventions antérieures aux ERP ont été essentielles pour permettre les enregistrements é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 meilleure façon de gérer les flux de marchandises, augmentant la productivité tout en réduisant les erreurs de saisie. Cependant, bien que les lecteurs de codes-barres aient considérablement amélioré l’acquisition de données dans de nombreuses situations, le stockage, l’organisation et le traitement des enregistrements électroniques sont restés quelque peu un problème ouvert pendant deux décennies. Les bases de données relationnelles ont été la réponse de l’industrie du logiciel à ce problème à la fin des années 70 et, cinq décennies plus tard, les bases de données relationnelles restent la pratique dominante en matière de gestion des données commerciales.

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 sont révélés très coûteux à mettre en œuvre, car chaque entreprise réinventait comment représenter chaque élément dans sa base de données : produits, clients, factures, paiements, etc. Ainsi, au cours des années 80, une série de sociétés de logiciels ont émergé, vendant des systèmes relationnels “préconfigurés”. Ces produits seraient plus tard collectivement désignés sous le nom d’ERPs, un terme inventé dans les années 90. Malheureusement, l’acronyme ERP est un abus de langage ; il aurait dû être Enterprise Resource Management plutôt que Planning. En effet, la planification est - au mieux - une préoccupation secondaire pour les ERPs. Comme expliqué ci-dessous, l’analyse prédictive est essentiellement en contradiction avec la conception fondamentale des ERPs.

Historiquement, les ERPs ont gagné en popularité car ils ont simplifié une série d’opérations qui nécessitaient auparavant des efforts administratifs considérables. Par exemple, l’émission d’un bon de commande à un fournisseur nécessitait de remplir un formulaire avec le nom et l’adresse du fournisseur. Les lignes de commande devaient uniquement inclure des références de produits valides. Ensuite, lors de la réception des marchandises, les quantités reçues devaient correspondre à celles figurant dans 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 avec le montant approprié, la date correspondant aux conditions de paiement du fournisseur et le numéro de compte bancaire du fournisseur correctement identifié. Toutes ces informations peuvent être trouvées dans l’ERP et des vérifications de cohérence peuvent facilement être effectuées de manière automatisée.

Le marché des ERPs 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), qui était devenu accessible aux entreprises de toutes tailles.

Dans les années 90, les ERPs sont devenus le cœur logiciel de la plupart des grandes entreprises lorsque l’activité était principalement axée sur le flux de marchandises. En revanche, les entreprises principalement axées sur les services adoptaient généralement un logiciel CRM (Gestion de la Relation Client) comme cœur de leur activité. Les ERPs et les CRMs partagent de nombreuses caractéristiques, notamment leur conception commune sur des bases de données relationnelles. Les ERPs adoptent généralement une perspective centrée sur les transactions pour la plupart de leurs fonctionnalités, tandis que les CRMs adoptent une perspective centrée sur le client.

La conception des ERPs

Les ERPs sont divers, car le marché comprend de nombreux fournisseurs qui ont continué à proposer de nombreuses versions de leurs produits ERP sur plusieurs décennies et pourtant, au cœur, la plupart des implémentations suivent toujours des lignes de conception très similaires. Les ERPs sont apparus comme des couches logicielles “préconfigurées” mises en œuvre sur des bases de données relationnelles. Ainsi, le processus de conception des ERPs implique la catégorisation :

• entités, c’est-à-dire tous les concepts ou objets que l’ERP doit représenter, tels que les produits, les paiements, les stocks, les fournisseurs… Chaque entité peut impliquer une ou plusieurs tables dans la base de données relationnelle sous-jacente. La plupart des ERPs définissent des centaines d’entités, voire des milliers pour les ERPs 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 (Create / Read / Update / Delete), qui représente les opérations les plus basiques auxquelles les utilisateurs finaux s’attendent lorsqu’ils traitent avec des entités.
• logique métier qui fournit des comportements automatisés qui éliminent le besoin de nombreuses tâches administratives, qui peuvent être automatisées en fonction de règles bien définies, telles que la conversion des commandes clients en factures clients.

Comme les entreprises sont incroyablement diverses et complexes, il y a un flux constant de besoins en entités, interfaces utilisateur et logiques métier plus récentes ou affinées qui sont nécessaires pour couvrir les pratiques commerciales en évolution. Cela représente un effort continu massif de la part des fournisseurs d’ERP. Ensuite, ce défi est aggravé par toutes les ambiguïtés qui surgissent lorsqu’on essaie de servir des secteurs très diversifiés. Le même terme, comme “paiement”, reflète des réalités et des processus très différents d’un secteur à l’autre. Dans les logiciels, la complexité a tendance à avoir des coûts non linéaires, c’est-à-dire que le fait de prendre en charge 2 fois plus de fonctionnalités dans un produit coûte beaucoup plus que le double du 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

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

En particulier, de nombreux fournisseurs d’ERP ont conçu des langages de programmation spécifiques au domaine (DSL - Domain Specific Programming) qui sont 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 sous-jacente. Grâce à un DSL bien conçu, l’extension de l’ERP (c’est-à-dire de nouvelles entités, interfaces ou logiques) pour couvrir les spécificités d’une entreprise donnée peut être réalisée avec moins de ressources par rapport à un effort similaire réalisé avec un langage de programmation généraliste.

Depuis les années 2000, les fournisseurs d’ERP open source - qui ont émergé en exploitant les bases de données relationnelles open source qui étaient devenues 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, qui est écrit dans le même langage de programmation généraliste que l’ERP lui-même. Cette stratégie est plus légère à exécuter pour le fournisseur d’ERP (pas de DSL à concevoir) et est alignée sur la nature open source de l’ERP.

Offre

Comme le coût de mise en œuvre et de support des fonctionnalités augmente avec le nombre total de fonctionnalités, la plupart des fournisseurs d’ERP adoptent une stratégie de tarification basée sur des modules : 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 sur une base de modules, permettant aux entreprises clientes de choisir les modules les plus urgents et de reporter les autres pour des investissements ultérieurs.

La stratégie de tarification basée sur des modules offre également au fournisseur d’ERP une stratégie de vente incitative naturelle, où la base de clients existante devient la cible principale pour les ventes futures. Les domaines d’activité qui n’avaient pas été initialement couverts par l’ensemble initial de modules de l’ERP reçoivent de nouveaux modules dédiés qui peuvent, à leur tour, être vendus aux entreprises clientes.

Cette stratégie de tarification basée sur des modules est un mécanisme efficace pour faire face à la complexité, car elle donne un retour direct au fournisseur d’ERP sur les domaines fonctionnels où la volonté de payer est la plus grande. En tant que telle, elle aide le fournisseur à hiérarchiser correctement ses efforts d’ingénierie logicielle.

Écosystème

Chaque fonctionnalité supplémentaire ajoutée à un ERP a tendance à donner des rendements décroissants pour le fournisseur d’ERP qui a correctement hiérarchisé ses efforts d’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 en premier lieu. De plus, les organisations elles-mêmes - y compris les fournisseurs d’ERP - ont tendance à être soumises à des déséconomies d’échelle : l’ajout de développeurs logiciels supplémentaires à un produit logiciel est notoirement connu pour ne pas entraîner de gains linéaires dans le débit des 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 efforts de développement de dernière minute nécessaires pour rendre l’ERP opérationnel 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 fonctionnalités qui ne sont pas offertes par l’ERP “brut”. Historiquement, jusqu’aux années 2000, lorsque les entreprises adoptaient des ERP pour la première fois, le travail des intégrateurs était généralement centré sur l’introduction de fonctionnalités supplémentaires pour l’ERP. De nos jours, cependant, la plupart des projets ERP sont des mises à niveau, car un ERP existant est déjà en place. Ainsi, la valeur ajoutée principale de l’intégrateur est de garantir une transition en douceur de l’ancien ERP vers le nouveau. En pratique, ce travail consiste à migrer les données et les processus entre les systèmes.

Contrairement aux fournisseurs d’ERP qui ont une stratégie commerciale 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 forme de tarification basée sur les jours-hommes. Ils facturent leur travail en fonction du nombre de jours travaillés et la propriété intellectuelle du travail livré revient généralement, par contrat, à l’entreprise cliente elle-même.

Le développement d’un écosystème diversifié d’intégrateurs, tant sur le plan géographique que vertical, est un moyen efficace de réduire la complexité inhérente au développement d’un ERP. Presque tous les grands fournisseurs d’ERP ont développé des réseaux importants 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 ce sont des limitations de conception et, par conséquent, il est peu probable qu’elles soient résolues par de nouvelles versions d’ERP, ou plutôt résoudre ces limitations impliquerait probablement de dénaturer les ERP au point où il ne serait plus très pertinent de les considérer comme des produits logiciels ERP.

Adverses 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 axée sur une charge de travail qui implique principalement de petites opérations de lecture et d’écriture, qui doivent être effectuées avec de faibles latences - généralement une fraction de seconde - les lectures et les écritures étant à peu près équilibrées en volume. 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 largement inadaptés à l’analyse, aux statistiques et aux rapports lorsque la quantité de données est non négligeable. Accéder à une quantité non négligeable de données dans n’importe quel ERP - pendant que les opérations commerciales sont en cours - pose toujours un problème, car lorsque le système est affamé en raison de trop nombreuses lectures ou écritures de données, le système ralentit. En pratique, cela signifie que les opérations courantes, telles que le traitement des codes-barres, ralentissent également. Dans le pire des cas, toute l’entreprise s’arrête. Ainsi, chaque opération dans l’ERP, lecture ou écriture, doit rester petite, idéalement “triviale”. La quantité de données qui peut être considérée comme non négligeable a considérablement augmenté au cours des quatre dernières décennies, avec l’amélioration des matériels informatiques, moins chers. Cependant, les entreprises ont également profité de ces progrès pour augmenter considérablement la quantité de données versées dans leurs ERP. En conséquence, les systèmes ERP actuels ne sont généralement pas sensiblement plus rapides qu’il y a deux décennies.

Par exemple, les ERP conviennent bien pour afficher le niveau de stock d’un SKU, ou pour mettre à jour sa valeur lorsqu’une unité est prélevée ou chargée, mais les ERP ne conviennent généralement pas pour afficher la chronologie quotidienne consolidée des variations de stock d’un SKU au cours des trois dernières années. Le segment des produits logiciels de Business Intelligence (BI) a émergé dans les années 90 en réponse aux limitations analytiques des ERP (et des CRM également). Contrairement aux ERP, les outils de BI sont conçus autour de cubes en mémoire, généralement appelés OLAP (Online Analytical Processing). En abandonnant les propriétés ACID, les systèmes OLAP sont beaucoup plus efficaces en termes de 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 intrigant de constater que la plupart des fournisseurs d’ERP ne semblent pas être pleinement conscients de cette limitation de conception dans leurs propres produits, même ceux qui ont émergé après les années 90, lorsque le segment de la 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, complètement 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’ensemble de l’historique des données transactionnelles de l’entreprise : ventes, retours, niveaux de stock, remises, etc. Bien que le calcul soit généralement prévu pour être effectué en lot pendant la nuit, atténuant ainsi le problème de pénurie de ressources mentionné ci-dessus, les bases de données relationnelles entraînent de vastes surcharges accidentelles lorsqu’il s’agit d’effectuer ce type de calcul. Par conséquent, de nos jours, la plupart des ERP disposent de capacités de prévision “héritées”³ qui sont tombées en désuétude il y a des années, voire des décennies.

Adverses aux nouveaux ou distincts paradigmes

La stratégie de catalogage des entités utilisée par les fournisseurs d’ERP ne s’échelonne pas linéairement en termes de gestion de la complexité. Les meilleurs outils, comme discuté ci-dessus, n’apportent qu’un soulagement linéaire - en ce qui concerne le nombre d’entités - tandis que les coûts de complexité augmentent de manière superlinéaire. En conséquence, les nouveaux ou distincts paradigmes s’avèrent généralement coûteux à la fois en termes de coûts et de délais d’intégration, atteignant fréquemment le point où il est préférable de sauter complètement l’ERP. Ces situations sont diverses, nous en listerons quelques-unes ci-dessous, mais elles se résument toutes de manière similaire à des paradigmes difficiles à intégrer car ils sont apparus tardivement dans le processus de développement de l’ERP⁴.

Atteindre zéro temps d’arrêt opérationnel est difficile car, comme indiqué ci-dessus, toute lecture ou écriture importante expose l’ERP à un ralentissement du système. Ainsi, toutes ces opérations sont généralement effectuées sous forme de lots nocturnes, lorsqu’il y a peu ou pas d’opérations en cours. Pourtant, cette conception est en contradiction avec les exigences du commerce électronique qui ont émergé relativement tard dans l’histoire des ERP. En conséquence, la plupart des fournisseurs d’ERP ont largement séparé leur module de commerce électronique, en utilisant fréquemment un système de base de données distinct, enfreignant ainsi la règle de conception implicite selon laquelle tous les modules ERP vivent dans la même base de données (s). En conséquence, les modules de commerce électronique basés sur les ERP ont tendance à être aussi difficiles et coûteux à déployer que les applications tierces.

Traiter les secteurs de reconditionnement où les marchandises suivent des flux cycliques complexes (c’est-à-dire les réparations), alors que les ERP classiques sont fortement orientés vers les flux en avant - des producteurs aux consommateurs - comme on le trouve couramment dans les FMCG et la distribution. Alors que la plupart des entités pertinentes nécessaires à des fins de reconditionnement (c’est-à-dire les produits, les stocks, les commandes) existent déjà dans les ERP, leurs conceptions sont généralement complètement incompatibles avec les exigences du reconditionnement. Il est souvent plus facile de réimplémenter entièrement ces entités plutôt que d’essayer de recycler celles d’un ERP classique dans ces secteurs.

Offrir des latences faibles garanties, disons en dessous de la perception humaine (c’est-à-dire en dessous de 50 ms), est difficile car ni l’ERP ni sa base de données relationnelle n’ont été conçus en tenant compte de ces exigences. Pourtant, la conduite de systèmes hautement automatisés tels que les entrepôts robotisés nécessite ce type de latences 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 - bien qu’ils ne se réfèrent pas toujours à eux-mêmes comme des ERP - qui ont emprunté des voies de développement alternatives afin de faire face précisément à ces situations. Ces ERP ciblent généralement des secteurs de niche qui ne sont pas correctement desservis par les ERP classiques. Cependant, ces voies de développement alternatives sont généralement en contradiction avec les exigences classiques.

Risques lors des transitions ERP

Bien que cela puisse sembler paradoxal, il est généralement beaucoup 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 de plusieurs années. Même les simples mises à niveau de version de l’ERP - en conservant le même fournisseur - s’avèrent généralement difficiles et prennent plusieurs mois. De manière anecdotique, cette difficulté fait régulièrement les gros titres lorsque de grandes entreprises publient des communiqués de presse indiquant que leurs efforts de mise à niveau de l’ERP ont dépassé le budget de plusieurs centaines de millions de dollars ou d’euros. Dans de telles situations, le fournisseur d’ERP, l’intégrateur et/ou l’entreprise elle-même sont blâmés. 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 sont conçus par les forces du marché énumérées ci-dessus.

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

Cependant, lorsque l’entreprise doit passer à un autre ERP, elle est confrontée au problème de la transition de tous les modules en même temps. En effet, les ERP sont, par conception et par forces économiques⁵, des monolithes logiciels construits sur un petit ensemble de bases de données. Ainsi, lorsque le nouveau ERP doit être déployé, le chemin d’adoption incrémentale utilisé pour l’ERP d’origine ne peut pas être reproduit. L’entreprise doit donc effectuer une transition de manière globale. En conséquence, les coûts de mise en œuvre initiaux ont tendance à être très élevés, tandis que la situation après le déploiement tend à être des situations partiellement défectueuses qui prennent plusieurs années à résoudre.

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 affaire de correspondance un à un. La sémantique des entités évolue avec le temps. Par exemple, le fournisseur de l’ERP a peut-être commencé avec une table nommée “Commandes” destinée aux commandes des clients. Cependant, en cours de route, le fournisseur doit répondre aux nouvelles exigences, qui n’étaient pas prévues à l’origine, de gestion des retours clients. La version suivante de l’ERP réutilise la table “Commandes” pour les retours clients, mais ces lignes ont maintenant des quantités de commande négatives. Ce changement en apparence anodin complique considérablement la migration de l’ancienne version de l’ERP vers la nouvelle.

Cependant, la mise à niveau vers un nouvel ERP, ou vers une version ultérieure du même ERP, n’est pas la seule option pour les entreprises. De multiples alternatives sont en réalité disponibles pour atténuer les risques de transition. Naturellement, tout l’écosystème des fournisseurs d’ERP et des intégrateurs a un vif intérêt financier à promouvoir le contraire, en tant que survie de leur modèle économique.

Au-delà du monolithe

Les ERP ont émergé en tant que monolithe logiciel, 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, la construction de systèmes distribués - c’est-à-dire des logiciels qui fonctionnent sur un ensemble de machines plutôt que sur quelques machines centrales - était significativement plus difficile et coûteuse⁶. Ainsi, dans une large mesure, les fournisseurs d’ERP (dont la plupart ont plusieurs décennies) n’avaient pas d’autre choix que de construire leurs produits en tant que monolithe.

Néanmoins, avec l’adoption généralisée du cloud computing, les outils et les bibliothèques - fréquemment open source - sont devenus plus populaires et plus accessibles. En conséquence, les coûts et les surcharges associés à la conception d’applications distribuées ont diminué régulièrement au cours de la dernière décennie. L’industrie du logiciel a commencé à revoir de manière approfondie comment la valeur ajoutée qui était historiquement uniquement fournie par les ERP (ou les logiciels similaires aux ERP) peut être fournie.

L’approche moderne des logiciels d’entreprise consiste à briser le monolithe en une série de petites applications qui, idéalement, font une seule chose et la font bien⁷. L’assemblage des applications se fait par le biais d’API (Interfaces de Programmation d’Applications) qui sont précisément conçues pour faciliter les intégrations sur mesure dans des paysages applicatifs diversifiés. La plupart des API sont conçues pour tirer parti des outils d’API open source populaires qui réduisent considérablement les coûts de développement associés à ces intégrations sur mesure.

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

Au-delà des bases de données relationnelles

Les bases de données relationnelles ont été le socle de facto 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é à Command Query Responsibility Segregation (CQRS). Cette approche offre une évolutivité et une latence supérieures tout en permettant des conceptions plus expressives, c’est-à-dire capables de capturer plus précisément les intentions commerciales dans différentes situations.

L’essentiel de l’event sourcing consiste à traiter chaque changement dans le système comme un événement immuable. L’angle de l’immutabilité est inspiré des pratiques comptables : lorsqu’une ligne se révèle incorrecte dans un grand livre, le comptable n’efface pas la ligne pour résoudre le problème, il ajoute plutôt une autre ligne corrective dans le grand livre. Conserver l’intégralité de l’historique des événements - en supposant 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’angle de l’immutabilité facilite la mise à l’échelle des systèmes basés sur les événements. Les données peuvent être largement copiées et répliquées sans avoir à gérer les modifications des données.

La conception CQRS reconnaît que, dans la plupart des systèmes, les volumes respectifs de lectures et d’écritures sont fortement déséquilibrés. Dans de nombreuses situations, le volume des lectures (de données) dépasse de plusieurs ordres de grandeur le volume des écritures. Cependant, les bases de données relationnelles sont conçues pour des volumes de lectures et d’écritures (plus ou moins) symétriques. CQRS sépare explicitement les responsabilités des lectures et des écritures, généralement dans deux sous-systèmes distincts. Cette conception offre également des avantages, principalement en termes de latence, d’évolutivité et d’efficacité matérielle.

Pourtant, bien que ES et CQRS soient déjà populaires dans les grandes entreprises technologiques orientées consommateur et dans le trading quantitatif (finance), ils ont récemment commencé à gagner du terrain dans les logiciels d’entreprise grand public. Par conséquent, les outils ES+CQRS sont encore naissants par rapport à leurs homologues dans le domaine des bases de données relationnelles. Néanmoins, cette approche offre des moyens non seulement de réduire considérablement les coûts matériels, mais aussi de compresser les latences qui restent souvent un problème aigu pour la plupart des implémentations ERP.

La vision de Lokad

Comme les ERP ne conviennent même pas à des fins analytiques - d’où la nécessité d’outils de BI (Business Intelligence) - il n’est pas surprenant que leur bilan soit médiocre chaque fois qu’il s’agit d’analyse prédictive. À titre de preuve anecdotique, aucune des révolutions en matière d’apprentissage automatique / science des données ne s’est produite dans les ERP, et lorsque ces types de besoins se présentent, les équipes se tournent invariablement vers des feuilles de calcul 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 des chaînes d’approvisionnement. La plupart de nos fonctionnalités de base, telles que les capacités de prévision probabiliste, destinées à soutenir des décisions courantes telles que les stocks / les achats / la production / l’assortiment / la tarification, sont tout simplement impossibles à mettre en œuvre dans les systèmes ERP.

Notes