De Joannes Vermorel, Mars 2020Le terme d'ERP (Enterprise Resource Planning ou Progiciel de Gestion Intégré en français) désigne une catégorie de logiciels d'entreprise qui prennent en charge les opérations courantes de l'entreprise et assurent le suivi de ses ressources, notamment les liquidités, les matières premières, les travaux en cours, les produits finis, les commandes des clients, les bons de commande et la paie. Les ERP comprennent généralement de nombreux modules destinés aux fonctions essentielles de l'entreprise, telles que la comptabilité, l'approvisionnement, la distribution, les finances, les ventes, etc. et offrent une intégration étroite au sein de ces modules afin de 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 nombreux écrans et un haut degré de configurabilité.
Origines et motivations
Dans les années 70, il est progressivement devenu évident que les documents électroniques présentaient de multiples avantages par rapport à la documentation papier traditionnelle. Les fichiers électroniques devenaient moins chers, plus rapides et plus fiables que les fichiers papier. Deux inventions antérieures aux ERP ont joué un rôle clé dans la mise en place des fichiers é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 un moyen supérieur de gérer les flux de marchandises, en augmentant la productivité tout en réduisant les erreurs de saisie. Pourtant, si les lecteurs de codes-barres ont considérablement amélioré l'acquisition des données dans de nombreuses situations, le stockage, l'organisation et le traitement des fichiers électroniques sont restés un problème en suspens 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 solution dominante en matière de gestion des données d'entreprise.
Cependant, les systèmes de bases de données relationnelles nus, tels qu'ils étaient généralement vendus au début des années 80, se sont avérés très coûteux à mettre en œuvre, car chaque entreprise réinventait la manière de représenter tout ce qui se trouvait 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 vu le jour, vendant des systèmes relationnels "préconfigurés". Ces produits seront plus tard collectivement désignés sous le nom d'ERP, un terme inventé dans les années 90. Malheureusement, l'acronyme ERP est une erreur ; il aurait fallu parler de
gestion des ressources de l'entreprise (Enterprise Resource
Management) plutôt que de
planification (
Planning). En effet, la planification est - au mieux - une préoccupation secondaire pour les ERP. Comme nous le détaillons ci-dessous, l'analyse prédictive est en contradiction profonde avec la conception de base des ERP.
Historiquement, les ERP ont gagné en popularité parce qu'ils ont simplifié des séries d'opérations qui nécessitaient auparavant des efforts administratifs considérables. Par exemple, pour émettre un bon de commande à un fournisseur, il fallait remplir un formulaire avec le nom et l'adresse du fournisseur. Les lignes de commande ne devaient comporter que des références de produits valides. Ensuite, à la réception des marchandises, les quantités reçues devaient correspondre à celles figurant sur le bon de commande original 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 l'identification correcte du numéro de compte bancaire du fournisseur. Tous ces éléments peuvent être trouvés dans l'ERP et les contrôles de cohérence peuvent facilement être effectués de manière automatisée.
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 (processeurs, mémoire, stockage), devenu accessible aux entreprises de toutes tailles.
Dans les années 90, les ERP sont devenus le cœur logiciel de la plupart des grandes entreprises dont l'activité repose sur la circulation des marchandises. A l'inverse, les entreprises majoritairement orientées vers les services ont généralement adopté un logiciel CRM (Customer Relationship Management ou Gestion de la Relation Client en français) comme noyau. Les ERP et les CRM partagent de nombreux attributs, notamment leur structure commune reposant sur des bases de données relationnelles. Les ERP adoptent en général pour la plupart de leurs fonctionnalités une perspective centrée sur les transactions, tandis que les CRM adoptent une perspective centrée sur le client.
La conception des ERP
Les ERP sont très divers, car le marché compte de nombreux fournisseurs qui n'ont cessé de proposer de nombreuses versions de leurs produits ERP pendant plusieurs décennies, et pourtant, au fond, la plupart des implémentations suivent toujours des lignes de conception très similaires. Les ERP sont apparus en tant que couches logicielles "préconfigurées" mises en œuvre au-dessus de bases de données relationnelles. Ainsi, le processus de conception d'un ERP implique de cataloguer:
- les entités, c'est-à-dire l'ensemble des concepts ou objets que l'ERP doit représenter, tels que les produits, les paiements, les stocks, les fournisseurs... Chaque entité peut impliquer un ou plusieurs tableaux 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.
- des interfaces utilisateurs 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 ou Créer / Lire / Mettre à jour / Supprimer en français), qui correspond aux opérations les plus basiques que les utilisateurs finaux attendent lorsqu'ils traitent avec des entités.
- la business logic ou logique d'entreprise qui fournit des comportements automatisés qui suppriment la nécessité de nombreuses tâches administratives, qui peuvent être automatisées sur la base de règles bien définies, comme la conversion des commandes des clients en factures.
Les entreprises étant incroyablement diverses et complexes, il y a un besoin constant d'entités, d'interfaces utilisateur et de logiques d'entreprise nouvelles ou améliorées pour couvrir l'évolution des pratiques commerciales. Cela représente un effort constant et massif de la part des fournisseurs d'ERP. De plus, ce défi est décuplé par toutes les ambiguïtés qui surgissent lorsque l'on tente de prendre en charge des secteurs verticaux très divers. Un même terme, comme "paiement", reflète des réalités et des processus très différents d'un secteur vertical à l'autre. Dans la conception de logiciels, la complexité tend à avoir des coûts non linéaires, c'est-à-dire que la prise en charge de deux fois plus de fonctionnalités dans un produit coûte beaucoup plus cher 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
Pour faire face à la complexité, la première stratégie mise en œuvre 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 conçu des langages DSL (Domain Specific Programming ou Langage Dédié en français) destinés à compléter le langage d'interrogation sous-jacent - généralement aujourd’hui une version de SQL (Structured Query Language ou Langage de Requête Structurée en français) - de la base de données relationnelle sous-jacente. Grâce à un DSL bien conçu, il est possible d'étendre l'ERP (c'est-à-dire d’ajouter des entités, interfaces ou logiques) pour couvrir les spécificités d'une entreprise donnée avec moins de ressources que si l'on utilisait un langage de programmation général.
Depuis les années 2000, les fournisseurs d'ERP
open source - qui sont apparus en exploitant les bases de données relationnelles open source disponibles à la fin des années 90 - ont généralement adopté une stratégie alternative de plug-in (au lieu des DSL), dans laquelle l'ERP est conçu pour être étendu par l'introduction d'un code personnalisé, adapté à chaque entreprise cliente, qui est écrit dans le même langage de programmation général que l'ERP lui-même. Cette stratégie est plus légère à exécuter pour le fournisseur de l'ERP (pas de DSL à concevoir) et s'aligne sur la nature open source de l'ERP.
Offre
Le coût de la mise en œuvre et du support des fonctionnalités augmentant avec leur nombre total, la plupart des fournisseurs d'ERP adoptent une stratégie de tarification par module : les fonctionnalités sont regroupées en "modules", qui se concentrent sur des domaines fonctionnels distincts au sein de l'entreprise : gestion des stocks, finances, paie, etc. L'ERP est vendu sur la base de modules, ce qui permet aux entreprises clientes de choisir les modules les plus urgents et de reporter les autres à des investissements ultérieurs.
La stratégie de tarification par module offre également au fournisseur d'ERP une stratégie naturelle de vente incitative, dans laquelle la base de clients existante devient la cible principale des ventes futures. Les secteurs d'activité qui n'étaient pas couverts par l'ensemble initial de 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 par module est un mécanisme efficace pour faire face à la complexité, car elle fournit un retour d'information direct au fournisseur de l'ERP sur les domaines fonctionnels où la volonté de payer est la plus forte. En tant que telle, elle aide le fournisseur à prioriser correctement ses efforts d'ingénierie logicielle.
Écosystème
Chaque fonctionnalité supplémentaire ajoutée à un ERP tend à produire des rendements moindres pour le fournisseur d'ERP qui a correctement hiérarchisé ses efforts en matière d'ingénierie logicielle (1). En effet, si cette fonctionnalité n'a pas été ajoutée auparavant, c'est probablement parce qu'elle ne concernait pas suffisamment d'entreprises au départ. Ensuite, les organisations elles-mêmes - y compris les fournisseurs d'ERP - ont tendance à être sujettes à des déséconomies d'échelle : il est bien connu que l'ajout d'ingénieurs logiciels supplémentaires à un produit logiciel ne produit pas 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 du
dernier kilomètre nécessaires pour rendre l'ERP opérationnel pour une entreprise donnée à des entreprises 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 ont adopté les 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. Aujourd'hui, cependant, la plupart des projets ERP sont des
mises à niveau, car un ERP
hérité est déjà en place. Ainsi, la principale valeur ajoutée de l'intégrateur est d'assurer une transition fluide de l'ancien ERP au nouveau. En pratique, ce travail consiste à migrer les données et les 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, traité comme un actif de propriété intellectuelle, les intégrateurs adoptent généralement une forme de facturation au jour/homme. Ils facturent leur travail en fonction du nombre de jours travaillés et la propriété intellectuelle du travail fourni 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 sur le plan vertical, est un moyen efficace d'atténuer 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 limites de leurs systèmes de bases de données relationnelles sous-jacents (2). 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 parce qu'elles sont des limitations de
conception, et donc, il est peu probable qu'elles soient abordées par les nouvelles versions des ERP, ou plutôt, résoudre ces limites impliquerait probablement de dénaturer les ERP au point qu'il n'y aurait plus beaucoup de sens à appeler ces produits logiciels des ERP.
Inadaptés aux opérations de lecture et d'écriture volumineuses
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 qui implique principalement de petites opérations de lecture et d'écriture, qui devraient être effectuées avec de faibles latences - typiquement une fraction de seconde - avec des volumes de lecture et d'écriture à peu près équilibrés. Une analyse détaillée des bases de données relationnelles dépasse le cadre du présent article, mais cette remarque concernant la
charge de travail prévue pour les ERP explique, à elle seule, nombre de limitations mal comprises des ERP.
En raison de leur conception basée sur les bases de données relationnelles, les ERP sont largement inadaptés à l'analyse, aux statistiques et à la production de rapports lorsque la quantité de données est non négligeable. L'accès à une quantité négligeable de données dans un ERP - alors que les opérations commerciales sont en cours - est
toujours un problème, car lorsque le système est affaibli par un trop grand nombre de lectures ou d'écritures de données, il ralentit. En pratique, cela signifie que les opérations banales, telles que le traitement des codes-barres, sont également ralenties. Dans le pire des cas, c'est toute l'entreprise qui s'arrête. Ainsi, chaque opération dans l'ERP, en lecture ou en écriture, doit rester petite, idéalement "négligeable". La quantité de données pouvant être considérées comme non négligeables a considérablement augmenté au cours des quatre dernières décennies, parallèlement à l'amélioration et à la diminution du coût du matériel informatique. Cependant, les entreprises ont profité de ce progrès pour augmenter considérablement la quantité de données déversées dans leurs ERP également. Par conséquent, les systèmes ERP actuels ne sont généralement pas beaucoup plus rapides qu'il y a vingt ans.
Par exemple, les ERP sont bien adaptés pour afficher le niveau de stock d'une
SKU (Stock Keeping Unit ou UGS en français), ou pour mettre à jour sa valeur lorsqu'une unité est prélevée ou insérée, mais les ERP ne sont généralement pas adaptés pour afficher la chronologie quotidienne consolidée des variations de stock d'une SKU au cours des trois dernières années. L'ensemble du marché des logiciels de Business Intelligence (BI) est apparu dans les années 90 comme la réponse de l'industrie aux limites analytiques des ERP (et en réalité aussi des CRM). Contrairement aux ERP, les outils de BI sont conçus autour d'"hypercubes in-memory", généralement appelés OLAP (Online Analytical Processing ou Traitement Analytique en Ligne en français). En abandonnant les propriétés ACID, les systèmes OLAP sont beaucoup plus efficaces sur le plan matériel que les bases de données relationnelles pour fournir des statistiques globales, 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 limite du design de leurs propres produits, même ceux qui sont apparus "après" les années 90, lorsque le marché de la BI était la preuve vivante de cet état de fait. Par exemple, la plupart des fournisseurs d'ERP se sont risqués à mettre en place des fonctions de prévision de la demande qui, de par leur conception, sont totalement incompatibles avec leur base de données relationnelle sous-jacente - encore plus que les simples fonctions de "rédaction de rapports ". La prévision nécessite l'accès à l'historique complet des données transactionnelles de l'entreprise : ventes, retours, niveaux de stock, remises, etc. Même si le calcul est généralement prévu pour être effectué pendant la nuit, ce qui atténue le problème de manque de ressources mentionné ci-dessus, les bases de données relationnelles entraînent d'énormes frais généraux accidentels lorsqu'elles tentent d'effectuer ce type de calcul. Par conséquent, de nos jours, la plupart des ERP disposent de capacités de prévision "historiques" (3) qui sont tombées en désuétude il y a des années, voire des décennies.
Inadaptés aux paradigmes nouveaux ou atypiques
La stratégie de catalogage des entités utilisée par les fournisseurs d'ERP ne gère pas la complexité en suivant une échelle linéaire. De meilleurs outils, comme nous l'avons vu plus haut, n'apportent qu'un soulagement linéaire - par rapport au nombre d'entités - alors que les coûts de la complexité augmentent de façon superlinéaire. En conséquence, les paradigmes nouveaux ou distincts s'avèrent généralement coûteux, tant en termes de coûts que de délais d'intégration, au point où il est souvent préférable de se passer complètement de l'ERP. Ces situations sont diverses, nous en énumérons quelques-unes ci-dessous, mais elles se résument toutes à des paradigmes difficiles à intégrer parce qu'ils sont arrivés
tard dans le processus de développement de l'ERP (4).
Il est difficile de parvenir à un
temps d'arrêt opérationnel zéro car, comme nous l'avons souligné plus haut, toute lecture ou écriture importante fait courir à l'ERP le risque d'un ralentissement du système. Ainsi, toutes ces opérations sont généralement effectuées en lots nocturnes, lorsqu'il y a peu ou pas d'opérations en cours. Or, cette conception est en contradiction avec les exigences du commerce électronique qui sont apparues relativement tard dans l'histoire des ERP. En conséquence, la plupart des fournisseurs d'ERP ont largement séparé leur module d'e-commerce, en exploitant fréquemment un système de base de données distinct, brisant ainsi la règle de conception implicite selon laquelle tous les modules d'ERP vivent dans la ou les mêmes bases de données. En conséquence, les modules de e-commerce soutenus par les ERP ont tendance à être aussi difficiles et coûteux à déployer que les applications tierces.
La gestion de verticaux de
remanufacturation où les biens suivent des flux cycliques complexes (c'est-à-dire des réparations), est difficile car les ERP traditionnels sont fortement orientés vers les flux
en avant - des producteurs aux consommateurs - comme c'est le cas dans les produits de grande consommation et la distribution. Bien que la plupart des entités nécessaires à la refabrication (produits, stocks, commandes) existent déjà dans les ERP, leur conception est généralement en contradiction totale avec les exigences de la refabrication. 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 verticaux.
Il est difficile de garantir des
latences faibles, par exemple inférieures à la perception humaine (c'est-à-dire inférieures à 50 ms), car ni l'ERP ni sa base de données relationnelle n'ont été conçus en fonction de telles exigences. Pourtant, le pilotage 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, dans la 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.
Il est intéressant de noter qu'il existe des ERP spécialisés - qui ne se désignent pas toujours comme des ERP - qui ont emprunté des voies de développement alternatives précisément afin de faire face à ces situations. Ces ERP ciblent généralement des niches verticales qui ne sont pas correctement desservies par les ERP traditionnels. Cependant, ces voies de développement alternatives sont généralement en contradiction avec les exigences générales.
Les risques des transitions d'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 connues pour être des processus pluriannuels. Même les simples mises à niveau de
version de l'ERP - en gardant le même fournisseur - s'avèrent généralement être des entreprises difficiles et de plusieurs mois. A titre anecdotique, cette difficulté fait régulièrement la une des journaux lorsque de grandes entreprises publient des communiqués de presse indiquant que les efforts de mise à niveau de leur ERP ont dépassé le budget de plusieurs centaines de millions de dollars ou d'euros. Dans de telles situations, le vendeur de l'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 ces problèmes sont intrinsèques aux
ERP eux-mêmes, tels qu'ils ont été façonnés par les forces du marché énumérées ci-dessus.
Les coûts de la complexité n'évoluent pas de façon linéaire mais 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 environ. Ainsi, le nombre d'entités/d'interfaces/de logiques impliquées à chaque itération est relativement faible, et des extensions sur mesure peuvent être fournies progressivement pour adapter l'ERP aux besoins de l'entreprise.
Cependant, lorsque l'entreprise doit passer à un autre ERP, elle est alors confrontée au problème de la transition de
tous les modules en même temps. En effet, les ERP sont, de par leur conception et les forces économiques (5), des
logiciels monolithiques construits à partir d'un petit ensemble de bases de données. Ainsi, lorsque le nouvel ERP doit être déployé, la voie d'adoption
incrémentale utilisée pour l'ERP original ne peut être reproduite. L'entreprise doit donc effectuer une transition complète maintenant ou jamais. En conséquence, les coûts initiaux de déploiement ont tendance à être très élevés, tandis que le statut post-déploiement se caractérise généralement par des systèmes à moitié défectueux dont la réparation peut prendre plusieurs années.
D’un point de vue technique, 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 correspondances strictes. La sémantique des entités évolue au fil du temps. Par exemple, le fournisseur de l'ERP peut avoir commencé avec une table nommée "Commandes", destinée aux commandes des clients. Cependant, plus tard, le fournisseur doit répondre à de nouvelles exigences, non prévues à l'origine, concernant la gestion des retours des clients. La version suivante de l'ERP recycle la table "Commandes" pour les retours clients, mais ces lignes ont maintenant 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, 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 fait disponibles pour rendre la transition moins risquée. Bien entendu, l'ensemble de la filière des vendeurs et des intégrateurs d'ERP a un fort intérêt financier à prôner le contraire, pour la survie de son modèle économique.
Au-delà du monolithe
Les ERP sont apparus comme des
monolithes logiciels, c'est-à-dire des produits logiciels dont tous les composants internes sont étroitement couplés - une nécessité pour garantir un déploiement
plug-and-play de tous les modules. En outre, jusqu'aux années 2010, la construction de systèmes distribués - c'est-à-dire de logiciels fonctionnant sur un parc de machines plutôt que sur quelques machines centrales - était beaucoup plus difficile et coûteuse (6). Ainsi, dans une large mesure, les fournisseurs d'ERP (la plupart d'entre eux datant de plusieurs décennies) n'avaient d'autre choix que de construire leurs produits de manière monolithique.
Néanmoins, à mesure que l'informatique sur le cloud s'est généralisée, les outils et les bibliothèques - souvent open source - sont devenus plus populaires et plus accessibles. En conséquence, les coûts et les frais généraux associés à la conception d'applications distribuées n'ont cessé de diminuer au cours de la dernière décennie. Le secteur des logiciels a commencé à réexaminer en profondeur la manière dont la valeur ajoutée qui, historiquement, n'était apportée que par les ERP (ou les logiciels de type ERP) peut être fournie.
L'approche moderne du logiciel d'entreprise consiste à briser le monolithe par une série de petites applications qui, idéalement, font une seule chose et la font bien (7). Le collage des applications entre elles se fait par le biais d'API (Application Programming Interfaces ou Interfaces de Programmation d’Applications en français) qui sont précisément destinées à faciliter les intégrations sur mesure dans divers paysages applicatifs. La plupart des API sont conçues pour exploiter des 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 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 futures 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 coûteux 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 permanente - mais limitée - pour les équipes informatiques, le processus de changement SaaS est plus organique, moins cher et moins risqué que les mises à niveau annuelles ou bisannuelles.
Au-delà des bases de données relationnelles
Les bases de données relationnelles sont la charpente 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 le
Event Sourcing (ES) couplé à la
Command Query Responsibility Segregation (CQRS). Cette approche offre une scalabilité et une latence supérieures tout en permettant des structures plus expressives, c'est-à-dire capables de capturer plus précisément les intentions des entreprises dans diverses situations.
La clé de l'
event sourcing est de traiter chaque changement dans le système comme un événement immuable. L'angle de l'immuabilité s'inspire des pratiques comptables : lorsqu'une ligne s'avère incorrecte dans un grand livre, le comptable n'efface pas la ligne pour régler le problème, il ajoute une autre ligne corrective dans le grand livre. Conserver l'historique complet des événements - en supposant que le stockage des données soit suffisamment bon marché pour rendre cette stratégie viable - présente de nombreux avantages : meilleure traçabilité, auditabilité, sécurité... En outre, l'angle de l'immuabilité rend les systèmes basés sur les événements plus faciles à mettre à l'échelle. Les données peuvent être copiées et répliquées à grande échelle sans avoir à faire face à des changements dans les données.
La
conception CQRS reconnaît que, dans la plupart des systèmes, les volumes respectifs d'opérations de
lecture et d
'écriture sont fortement déséquilibrés. Dans de nombreuses situations, le volume de lectures (de données) dépasse le volume d'écritures de plusieurs ordres de grandeur. Cependant, les bases de données relationnelles sont conçues pour des volumes (à peu près) symétriques de lectures et d'écritures. Le CQRS sépare explicitement les responsabilités de lecture et d'écriture, généralement dans deux sous-systèmes distincts. Cette conception présente également des avantages, principalement en termes de latence, d'évolutivité et d'efficacité matérielle.
Pourtant, alors que l'ES et le CQRS sont déjà populaires dans les grandes entreprises technologiques orientées vers le consommateur et dans le commerce quantitatif (finance), ils n'ont que très récemment commencé à gagner du terrain dans les logiciels d'entreprise grand public. Par conséquent, l'outillage ES+CQRS est encore embryonnaire par rapport à ses homologues du domaine des bases de données relationnelles. Néanmoins, cette approche offre des moyens non seulement de réduire fortement 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.
L'avis de Lokad
Les ERP n'étant même pas adaptés à des fins analytiques - d'où le besoin d'outils de BI (Business Intelligence) - il n'est pas surprenant que leur bilan soit médiocre lorsqu'il s'agit d'analyses
prédictives. À titre anecdotique, aucune des révolutions de Machine Learning/Data Science n'a eu lieu dans les ERP, et lorsqu'elles sont confrontées à ce type d'exigences, les équipes se rabattent invariablement sur des feuilles de calcul ou des scripts
ad hoc.
Lokad est née en tant qu'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évisions probabilistes, destinées à soutenir des décisions banales comme les stocks/les achats/la production/l'assortiment/la tarification, sont tout simplement impossibles à mettre en œuvre dans les systèmes ERP.
Notes
(1) Cette vision est un peu simpliste. En pratique, au cours des dernières décennies, l'ingénierie logicielle a fait un bond en avant en même temps que les ressources informatiques brutes. Par conséquent, des fonctionnalités qui auraient été extrêmement coûteuses à développer dans les années 80 sont devenues beaucoup moins chères quelques décennies plus tard. Les fournisseurs d'ERP redéfinissent les priorités de leurs efforts de développement en tenant compte de ce phénomène.
(2) Historiquement, les tout premiers ERP des années 70, ou plutôt les logiciels de type ERP, le terme ERP n'apparaissant que plus tard, reposaient sur des bases de données à plat rudimentaires. Les bases de données relationnelles sont apparues comme une alternative supérieure aux bases de données de fichiers plats sous pratiquement tous les points de vue. Les premiers fournisseurs d'ERP ont donc fait évoluer leur conception vers des bases de données relationnelles. Cependant, en ce qui concerne les traitements de données par lots sur l'ensemble de la base de données, les bases de données à plat sont restées supérieures en pratique - pour un même investissement en matériel informatique - jusqu'à ce que le style colonnaire des bases de données relationnelles devienne populaire dans les années 2010.
(3) Comme de nombreux fournisseurs d'ERP ont tenté de créer et d'offrir des
fonctionnalités de prévision, les fournisseurs de bases de données, à leur tour, ont tenté de créer et d'offrir des
capacités de prévision dans leurs systèmes également. À ma connaissance, ces capacités de
prévision natives des bases de données sont à la fois répandues et largement inutilisées (ou fortement compensées de manière manuelle par des feuilles de calcul Excel), et préservées par les vendeurs uniquement pour des raisons de rétrocompatibilité.
(4) Le traitement en temps réel est une terminologie relativement subjective. Techniquement, la vitesse de la lumière elle-même impose des limites strictes aux temps de latence que l'on peut atteindre avec des systèmes distribués. L'intérêt d'avoir un ERP est de coordonner les fournisseurs, les usines, les entrepôts, ... qui sont géographiquement dispersés.
(5) Le principal argument de vente d'une stratégie de tarification par module est que l'ajout d'un nouveau module est une expérience (presque) de prêt-à-l'emploi pour l'entreprise cliente. Cependant, le prix à payer, en termes de conception, pour cette facilité d'adoption est un couplage important entre les modules, c'est-à-dire une conception monolithique. Le fait de toucher à un module a des répercussions sur de nombreux autres modules.
(6) Les systèmes informatiques distribués existent depuis des décennies. Cependant, jusqu'à ce que l'informatique sur le cloud devienne courante vers 2010, la quasi-totalité des logiciels d'entreprise étaient construits autour de l'architecture client-serveur, qui centralise tous les processus et toutes les données dans quelques machines, généralement un front-end, un back-end et une base de données. En revanche, l'informatique sur le cloud implique une "flotte" de machines, à la fois pour des raisons de fiabilité et de performance.
(7) C'était à l'origine la philosophie de conception d'Unix. Les applications d'entreprise spécialisées d'après 2010 ne sont généralement pas aussi étroites et ciblées que les outils Unix. Pourtant, ces applications sont déjà un ou deux ordres de grandeur moins complexes que les ERP. De plus, cette approche ne doit pas être confondue avec les microservices, qui sont une manière d'ingénieriser en interne les apps elles-mêmes.
