Les limites des voies traditionnelles pour bâtir une organisation numérique
Affirmation n°1 : on ne peut pas échapper à la programmation
La diversité des organisations, même au niveau d'un même secteur d'activité, est beaucoup trop grande pour que des solutions purement paramétriques puissent être efficientes. Ceci est d'autant plus vrai qu'il existe dans toute organisation un besoin de réadaption permanent, soit pour s'adapter à l'évolution des besoins clients, soit pour s'adapter aux changements de personnes. Choisir une solution clé en main, c'est de fait dire que ce sont les process que l'on adaptera au logiciel, et c'est désormais archaïque du point de vue management.
Affirmation n°2 : la complexité doit rester maîtrisée
Pour que l'évolution perpétuelle de l'organisation soit réellement possible, la nécessaire programmation doit rester suffisamment simple pour qu'elle devienne l'outil des cadres et non l'affaire de spécialistes. Pour répondre à cette contrainte de simplicité, le code doit être efficient (ou minimaliste) et local.
•
|
Efficient : quand dans les programmes actuels on a 90% de lignes servant à faire fonctionner l'interface utilisateur, et 10% servant à la "core logic", on est à coté de la cible.
|
•
|
Local : il faut pouvoir assurer l'isolation entre les activités réelles. La bonne propriété que l'on demande au système informatique, c'est que quand on étudie une activité réelle, on peut retrouver et comprendre tout le code qui s'y rapport en quelques minutes.
|
Storga satisfait ces exigences, contrairement aux derniers langages (tels Java ou Swift), aux bases de données relationnelles, aux bases de données non relationnelles autres que Storga, aux nouvelles plateformes smartphone, ou encore aux simples migrations des services vers le Cloud¹.
Dans la suite de cet article, nous allons passer en revue les différentes statégies traditionnelles pour bâtir un système d'organisation numérique et montrer pourquoi leurs limites ne sont pas liées au défaut du logiciel particulier choisi, mais au fait que la structure sous jacente ne répond pas au cahier des charges ci-dessus.
¹ À l'inverse, lorsque la partie numérique d'une organisation est supportée par Storga, on peut la déployer sur des serveurs d'entreprise, dans le Cloud et sur smartphones.
La bureautique
C'est souvent par là qu'une organisation commence aujourd'hui, car c'est la voie la plus facile à démarrer.
Un autre élément qui favorise cette voie, est l'illusion de contrôle qu'elle amène à chaque utilisateur du système. Il n'a pas besoin de s'adresser au service informatique pour mettre en place la partie informatique correspondant à un nouveau projet ou une nouvelle activité.
Ceci étant, les multiples problèmes associés apparaissent assez vite :
•
|
Gérer un grand volume de données avec de la bureautique est problématique parce que la concentration pour obtenir le reporting est largement manuelle.
|
•
|
Plus on l'intègre et on essaye de l'automatiser via des macros, plus le système tend à devenir instable. L'explication, est double: D'une part les applications de bureautique sont beaucoup trop compliquées pour pouvoir être stables en terme de tenue en charge et d'évolution dans le temps. Comparativement, un serveur de bases de données est quelque chose de très simple. D'autre part, construire du reporting à partir de document bureautique est beaucoup plus compliqué que construire le même reporting à partir de données dans une base de donnée.
|
•
|
Enfin une telle infrastructure favorise un comportement où chacun se 'fait' son organisation dans son coin, et y recopie toutes les données qui l'intéresse, au détriment de l'optimisation collective. C'est la contrepartie de liberté individuelle d'organisation qui trop souvent, qui faute de concertation et réflexion suffisante, se traduit globalement par de la médiocrité.
|
Très simplement, le traitement de texte a été créé pour faire du secrétariat, et le tableur de la modélisation financière. Croire que l'on peut les détourner et les utiliser en outils d'organisation est une illusion. Je m'explique. Contruire une organisation sur la base d'outils bureautique, c'est plus difficile que la construire sur la base de d'outils pensés au départ pour l'organisation. Or la grande motivation pas toujours avouée de certains utilisateurs pour conserver leur organisation à base de bureautique, c'est de ne pas avoir à apprendre quelque chose de nouveau, donc s'économiser de l'effort, ce qui n'est ni idiot ni répréhensible en soi. Cependant, croire que ces même utilisateurs vont produire l'effort supplémentaire nécessaire pour porter efficacement un tel système, c'est juste se voiler la face. Le réel, c'est qu'ils se contenteront de la médiocrité.
La grande erreur à ce niveau, c'est de croire qu'il suffit de mettre une ou des béquilles au système, par exemple via un partage dans le Cloud, pour que le système devienne performant. Cela permet d'appliquer la bureautique sur un espace de travail commun, exactement comme les serveurs dans les années 1990, mais cela ne résoud en rien les problèmes liés au reporting et à la difficulté d'automatisation sur une telle base.
En résumé, et très brutalement, une organisation sur la base d'outils bureautique ne peut être que médiocre.
L'assemblage de solutions existantes
Pour comprendre la problématique, il convient de changer d'angle de vue, et se mettre à la place d'un développeur. Pour créer et vendre une solution métier, on commence par regarder comment fonctionnent un certain nombre d'organisation, et en déterminer les éléments communs ou largement commun. On élabore de fait une entreprise virtuelle, qui serait un peu la médiane de ce que l'on a vu, et on développe un logiciel pour répondre aux besoins de cette entreprise virtuelle. Au passage, on essaie de rendre le plus de choses possibles paramétrables, adaptables. Ensuite, on commence à vendre aux premiers clients, et l'on constate très souvent un décalage entre l'entreprise virtuelle de départ et le besoin réel du nouveau prospect, donc on ajoute des fonctions, et on généralise des fonctions existantes. Le problème, c'est qu'à ce petit jeu, la complexité générale du code explose très rapidement, donc au bout de pas longtemps, on est confronté au dilemme suivant :
•
|
Soit on continue à enrichir le logiciel commun, et alors d'une part son coût de développement augmente très rapidement, et de plus le coût de démarrage (paramétrage) pour chaque nouveau client augmente.
|
•
|
Soit on fige plus ou moins l'ensemble, et dans ce cas on arrive rapidement à un logiciel qui répond assez mal aux besoins réels du client, et le taux de rejet (le logiciel est abandonné quelques mois après sa mise en service) augmente, en même temps que la productivité globale dans les cas de non rejet diminue.
|
Donc la manière classique de sortir de ce dilemne qui se pose très rapidement, c'est de permettre des développements spécifiques à un client, qui ne feront pas partie du code général. Cependant, on tombe de fait immédiatement dans un second dilemme:
•
|
Si le code commun est limité, alors chaque nouveau client aura beaucoup d'adaptations à faire, et cela rend la démarche commerciale difficile.
|
•
|
Si le code commun est étendu, c'est la maintenance des modifications spécifiques qui va poser problème, car à chaque nouvelle version du code commun, on devra adapter le code spécifique à un système commun inutilement complexe du point de vue de l'organisation cible, puisqu'elle n'en utilise qu'une partie.
|
Ensuite, un troisième dilemme se pose : Est-ce que l'on base son organisation sur un seul super logiciel (ERP) sensé gérer toutes les activités de l'entreprise, ou est-ce que l'on utilise de multiples logiciels ?
•
|
Dans le cas d'un seul logiciel, le dilemme précédent de soit le logiciel est très complexe, donc très coûteux à maintenir, soit il est mal adapté au fonctionnement effectif de l'entreprise cible va se poser avec plus de sévérité encore.
|
•
|
Dans le cas de multiples logiciels, ce sont les problèmes d'interconnection qui vont s'avérer rédhibitoires. En effet, on aura tout d'abord une difficulté technique pour faire circuler l'information entre de multiples bases de données pas forcément identiques, en particulier quand la circulation doit être bidirectionnelle, mais ce n'est encore là que la partie visible de l'ice berg : le problème insoluble vient de l'écart de la modélisation, de l'organisation même de l'activité qui ne va pas correspondre dans les différents logiciels. En gros, à une case dans le logiciel A ne vas pas forcément correspondre une case dans le logiciel B. Un humain, grâce à la souplesse de ses capacités cognitives, arrivera plus ou moins à faire le lien, à établir les équivalences approximatives, mais certainement pas un automate. Au final, on va retrouver le syndrome de la bureautique: un déficit d'automatisation qui annihile le gain de productivité et de confort de travail qu'aurait dû apporter l'informatisation.
|
Le développement spécifique classique
Le développement spécifique, c'est la promesse de pouvoir mettre en place une organisation qui corresponde bien aux besoins de l'entreprise cible. Oui mais ...
Le premier problème, c'est que pour lancer un développement classique, il faut établir un cahier des charges. Or dans la pratique, on ne sait vraiment ce que l'on veut que quand on a expérimenté un minimum, donc pas au moment d'établir le cahier des charges.
Ensuite, un développement spécifique, cela suppose de maintenir le code dans le temps, et on constate dans la pratique qu'au bout d'assez peu de temps, la maintenance des activités de base de l'entreprise (flux de commandes) consomme toutes les ressources allouées à l'informatique, au détriment des activités annexes, insignifiantes une à une, mais nombreuses, si bien que la médiocrité de l'organisation informatisée de ces activités nuit très significativement à la productivité d'ensemble. Dit autrement, une organisation basée sur du développement spécifique n'est jamais complète.
Enfin, et c'est là le plus problématique, les développements spécifiques resistent mal dans le temps à trois types de changements:
•
|
L'activité change pour mieux répondre aux nouvelles attentes des clients. En gros, le développement spécifique va pousser de fait l'entreprise à s'auto centrer au détriment de la relation client.
|
•
|
Les personnes qui exercent les activités changent. C'est le point qui est souvent le plus mal compris et négligé. Quand on remplace un humain par un autre à un poste donné, la nouvelle personne n'a pas exactement les mêmes capacités et limites que la précédentes, donc il convient de réajuster, réoptimiser le périmètre de son activité. En ne le faisant pas, on cumule des pertes : perte de qualité quand la personne n'a pas toutes les compétences nécessaires, perte de motivation quand on ignore certaines de ses capacités pourtant pertinentes au regard des activités qui lui sont confiées. Bref, on sous utilise le capital humain, et ensuite, on se plaint à tord et de bonne foi que le coût du travail est trop élevé, que les personnes ne sont pas motivées, etc, etc, sans bien comprendre que l'origine réelle du problème est largement au niveau de la nature des outils numériques d'organisation.
|
•
|
Le rapprochement de plusieurs unités de production. Il n'y a pas de bonne solution dans cette configuration : On peut choisir de laisser chaque entité continuer avec son propre système, mais alors on limite drastiquement les effets positifs de la synergie, on ne fait pas d'économie d'échelle, etc. On peut choisir l'un des systèmes et le généraliser, mais on plombe la productivité du site sur lequel on parachute le changement et on augmente le risque d'échec de la fusion. On peut lancer une nouvelle application commune, mais il y a fort a parier que la migration des données existantes sera insatisfaisante à cause des équarts de représentation de l'activité (à un champ dans le logiciel A ne correspond pas de champ dans le logiciel B, ou le logiciel A impliquait une certaine manière de dérouler telle activité, alors que le logiciel B supposait une approche complètement différente, exactement comme dans le cas de l'assemblage de solutions existantes évoqué plus haut dans ce document) Ce qu'il faut bien comprendre à ce niveau, c'est que la source du problème est liée à la nature même du modèle relationnel qui sert de support à tous ces développements. Une base de donnée relationnelle est par nature la modélisation fixe d'une organisation, donc le reflet d'un monde homogène, immuable, et clos. Par opposition, Storga a été conçu pour établir des automatismes entre des entités hétérogènes.
|
Une cause supplémentaire de la difficulté à maintenir le code est la séparation entre le programme et les données que l'on retrouve dans tous les systèmes de développement classique, par opposition à un tableur par exemple.
|