Vers un nouveau modèle de progiciel appliqué à la finance de marché
L'ERP (Enterprise Resource Planning) a-t-il encore un avenir ? Trop procédural, trop rigide, trop cher....
La volonté d’encadrer les utilisateurs pour répondre à des normes et des procédures a promu le modèle ERP, où le système d’information est unifié. Les promesses d’un PGI sont pléthores : il structure et homogénéise les données, fiabilise et trace les actions, assiste et norme les processus. Ce modèle a-t-il tenu ces promesses ?
L’épreuve des faits parlent d’eux-mêmes. En milieu bancaire, chaque métier a son propre ERP. Le tout en un n’a pas survécu au spécifique et à la personnalisation accrue. Constat et évidence, l’unification des fonctions au sein d’un même outil est écartée : trop normative et procédurale, peu évolutive et réactive. Le spécifique de chaque métier oblige à une individualisation extrême des PGI.
De fait, les données sont parcellaires et dissociées dans une multitude d’outils. La promesse d’homogénéisation des données reste illusion.
La volonté d’intégration et de rendre plus explicite les modes opératoires aboutit à une déresponsabilisation et une perte d’autonomie et d’inventivité. La volonté d’organisation ôte toutes singularités et individualités. Le paradoxe de l’ERP est en captant les singularités du travail de les asservir et de les annihiler. La cohérence est prise à la pertinence. L’implémentation en salle de marchés d’un ERP souligne ses limites et ses failles. L’outil est relégué à une position d’aide à la saisie et rarement au centre de l’activité. Des outils bricolés par les utilisateurs ou par des équipes de développement de proximité prennent le pas sur l’ERP.
De fait, les outils périphériques mettent à mal la traçabilité et fiabilité.
Résultat, des coûts exponentiels d’implémentation et de maintenance par la multiplication des outils installés et de leur personnalisation extrême. Les ERP nécessitent à minima d’intégrer un socle référentiel complet et de reprise de l’ensemble des deals pour restituer la richesse de ses fonctions. Ce prérequis d’intégration met à mal l’argument de la divisibilité et de la modularité de l’innovation pour assurer son succès en permettant un déploiement graduel.
De fait, la gestion des coûts limite les évolutions au minimum obligeant les opérationnels à s’adapter aux fonctionnalités et modes opératoires du système. Dans le passé, nous construisions l’application à partir d’une analyse du fonctionnement opérationnel. Aujourd’hui, nous adaptons le fonctionnement opérationnel aux fonctionnalités et modes opératoires du système.
Ce triple constat nous oblige à nous interroger sur la pertinence du modèle ERP. Un retour sur les fondements d’un outil pour élaborer des pistes d’évolution.
Un outil est une représentation mettant en jeu trois univers : l’objet (le quoi ?, la définition), l’interprétant (le pourquoi ?, la finalité), la représentation (le comment ? la forme).
L’ERP enserre les trois univers : l’interprétant en tant que tiers est exclu. La difficulté naît de cet oubli. Les ERP essaient de pallier en ouvrant le système soit par un paramétrage poussé, soit par la possibilité d’ajout de code s’appuyant sur les fonctions ouvertes. Ces palliatifs ont ouverts la porte à une personnalisation extrême des PGI traditionnels, très coûteuse en maintenance et rarement évolutif.
La solution viendra du découplage. En lieu et place d’un ERP mastodonte, une plateforme protéiforme alimente en flux chaque fonction constitutive de son propre module.
L’architecture en rhizome est substituée à l’architecture traditionnelle en arbre. Les liaisons fortes par arborescence disparaissent au profil de liaisons faibles par rhizome.
Concrètement, l’éditeur assure la couche primaire des données (écriture des données, l’interrogation des données, le transfert des données, l’interopérabilité des données, l’universalité des données) et la couche de représentation. La couche de représentation est la structure permettant d’élaborer la forme. Chaque fonction/module est circonscrit à son rôle propre par un découplage : un usage / une fonction. Au final, la représentation assure une forme de langage, de code, d’encodage, facilitant la mise en œuvre et l’usage de la fonction, mais ouvre chaque fonction à l’interprétant. Ainsi, le déploiement de la stratégie informatique se recentre sur les modalités d’implications opérationnelles concentrées autour de l’usage.