Changer de logiciel ne suffit pas …

source Rooners Toy Photography “Evolution”, licence CC BY-NC-ND 2.0

Dans le « Monde ne suffit pas », James Bond fait cette réponse à une femme qui dit avoir été prête à le lui offrir. Pour y faire référence, nous pourrions dire également que changer de logiciel ne suffit pas à … changer le monde.

Changer de logiciel pour changer le monde? Changer de méthode!

Quelle est l’utilité de changer de logiciel quand vous ne savez pas pour quoi faire? Plus précisément, quand vous n’avez pas défini pour quels bénéfices et pour qui. C’est ce qui peut arriver quand vous n’impliquez pas les parties prenantes pour définir l’objectif du changement, non seulement au début, mais tout au long du projet. Il faut arrêter de chercher des solutions avant d’avoir posé le problème correctement.

Dire qu’il faut changer de logiciel est devenu populaire, pour exprimer la nécessité d’en finir avec un système inefficient. Ainsi on devrait changer de logiciel dans la politique, ou dans l’agriculture, dans la santé, dans la culture managériale … Cependant, cette comparaison présente des risques, au vu du nombre d’échecs de changement de logiciel dans les entreprises. Il serait utile d’en tirer des enseignements.
Le besoin de changer naît d’une situation insatisfaisante. La questionner avec méthode, en impliquant les parties prenantes concernées pour qu’elles s’expriment sur les finalités, les objectifs et les données factuelles, est une étape préalable indispensable au changement. L’informatique n’est pas plus magique que la mécanique de précision. Si on se trompe sur les dimensions en entrée, le résultat n’est jamais satisfaisant.

Les humains ne fonctionnent pas comme des logiciels.

Seldom logical, Perter Renshaw, seldom logical, licence CC BY-NC-ND 2.0

Credit image : Perter Renshaw, seldom logical, licence CC BY-NC-ND 2.0

Si vous n’êtes pas satisfait d’un système de mesure du temps, allez-vous dire : « il faut changer de montre » ? Un logiciel tout seul n’est rien. Il faut une vision de son utilité, un projet pour le mettre en place dans une organisation, des gens qui utilisent l’application qui en résulte, et d’autres qui l’exploitent et la maintiennent …

Mettre en place une application d’entreprise, c’est être confronté à un système complexe. Les interactions sont multiples entre stratégie, marché, acteurs, informations, processus, ressources et capacités, dans des environnements mouvants, avec des contraintes et des incertitudes. Ce n’est pas un problème qui peut se résoudre « mécaniquement » par juxtaposition de vision d’experts en silos. Il faut une approche systémique, transverse à l’organisation.

Le logiciel n’a pas d’autre intelligence que celle qu’on lui donne par conception et n’a d’intérêt que dans son utilisation. Tandis que la pensée humaine n’est pas un ensemble d’algorithmes à optimiser. Les humains ne fonctionnent pas comme des logiciels.

L’impact organisationnel du logiciel est à gérer pour et par l’humain

Si une entreprise, qu’elle soit publique ou privée, a recours à un progiciel, ou développe un logiciel, c’est pour répondre à des besoins : automatiser tout ou partie de certaines tâches, faire des choses autrement … En l’utilisant, la façon dont les collaborateurs vont travailler sera obligatoirement modifiée. Ne pas réfléchir à l’impact organisationnel, ni impliquer les collaborateurs pour vérifier qu’effectivement, on peut modifier l’existant pour créer de la valeur dans la balance entre couverture des besoins et consommation de ressources, ne peut conduire qu’à des déconvenues.

Pouvoir explorer différentes solutions exige de disposer d’un ensemble de critères qui permettent un choix rationnel. Il y a des priorités de besoins à définir, des contraintes et des risques à identifier, pour une évaluation correcte. Les solutions seront plus ou moins adaptées selon l’échelle des priorités. Sans analyser correctement la situation existante avec les parties prenantes, vous ne pourrez pas cibler les bénéfices du changement. Sans accompagner les utilisateurs pour qu’ils aient les comportements désirés dans l’usage du logiciel, vous n’aurez pas les bénéfices escomptés.

Tout cela relève du simple bon sens ? Certes, mais le constat de beaucoup d’échecs de « changement de logiciel » est sans appel : ce bon sens n’est pas partagé.

Il n’y a pas de meilleur logiciel

Tax credits wasting money

Tax credits wasting money – taxcredits.net, https://creativecommons.org/licenses/by/2.0/

Trop souvent, des solutions imposées suite à des décisions hâtives, deviennent le filtre des besoins à considérer. Ceux des parties prenantes clés, non impliquées dans le processus décisionnel, sont oubliées, comme sont oubliés les enjeux de l’organisation. Ou on ne prend pas non plus la peine de réactualiser régulièrement les données d’une décision, au risque de travailler sur une vision obsolète, alors même que l’environnement est par définition mouvant.

Partir de solutions techniques retenues a priori empêche d’office de considérer toutes les options permettant de maximiser la création de valeur. Surtout quand il s’agit de solutions dites éprouvées, qui ne le sont en réalité que pour certains processus standards, dans certains périmètres, sectoriels ou géographiques et pour certains type d’organisations.

Or les organisations n’ont jamais les mêmes activités, jamais les mêmes priorités quant aux besoins, et jamais les mêmes ressources.

Avoir identifié le meilleur logiciel en termes de part de marché, de visibilité, d’installations existantes, ne veut pas dire qu’il sera le meilleur pour vous. Pour faire un parallèle, certaines mesures politiques peuvent fonctionner dans un pays donné et pas dans un autre, quand l’historique, les institutions, la culture, ne sont pas les mêmes.
De plus, changer de logiciel sans accompagnement organisationnel conduit rarement aux résultats escomptés dans l’usage dudit logiciel. Pire, cela peut être la cause d’échecs importants qui se soldent en pertes de millions d’investissement, voire en faillite d’entreprises.

changer de logiciel implique des problématiques humaines

changer de logiciel, des problématiques humaines

Les temps modernes, Charlie Chaplin

Dans les grands projets de l’Etat, on pourrait évoquer l’abandon, après des centaines de millions dépensés, du programme autour du SI-paye de l’ONP en 2014. Les audits menés en 2012 sur le projet, relevaient au titre des constats : « un niveau d’ambition trop élevé, un abandon problématique dès l’origine de la convergence des SIRH, la rigidité du modèle cible de l’ONP, une stratégie de déploiement insuffisamment crédible, l’absence d’une direction de programme transverse et d’un pilotage stratégique effectif. » (cf le rapport sur la refondation du programme). Il s’agit plus là de problèmes organisationnels que logiciels.
Evoquons également le projet Andromède du « cloud souverain », imaginé en 2009, lancé en 2012, enterré en 2016. Un projet qui a ignoré les acteurs existants pour fournir des investissements sur fonds publics à des entreprises à « taille critique », considérées comme des « locomotives ». L’ennui, c’est que les locomotives n’ont jamais rejoint les hébergeurs déjà présents sur le marché français. Ovh, Ikoula, Gandi … ce sont eux désormais le « cloud souverain » (cf. <a href= »http://« >cet article archivé des échos). Il est dommageable qu’ils n’aient pas été considérés dès l’origine dans les parties prenantes du projet …

Côté privé, la gestion des grands projets informatiques n’est pas forcément meilleure, loin de là. La faillite de Target Canada en 2014 (mise en place de l’ERP SAP dans le retail pour l’ouverture de centaines de boutiques au Canada), est un cas d’exemple extrêmement riche en enseignements. Manque d’implication des parties prenantes, dont les fournisseurs, manque de formation des consultants et des utilisateurs, solution inadaptée aux besoins, planning irréaliste ….

Des échecs techniques ou humains?

Les nombreux échecs de projets CRM (progiciels qui servent à supporter la gestion de la relation client) interrogent également les capacités des organisations à piloter la transition vers les nouveaux modes de travail liés au fait de changer de logiciel. Selon l’enquête de 2016 de Kate Legget, analyste au Forrester, pour 414 responsables impliqués dans des échecs de ce type de projet, la cause principale était : à 38%, des problématiques humaines de non adoption par les utilisateurs et de non alignement de l’organisation au changement culturel que l’outil était censé supporter ; et à 33% l’absence d’objectifs clairement définis pour la mise en place de la solution.

En octobre 2018, le site developpez.com se faisait le relais d’une étude d’IDG (International Data Groupe) qui relevait qu’aux Etats-Unis et en Europe, 50 % de toutes les nouvelles demandes de développement d’applications se soldent par un échec. 15 % de ces projets ne sont jamais lancés, 15 % ne sont jamais terminés et 20 % sont livrés, mais ne répondent pas aux besoins de l’entreprise.
Le rapport désigne plus ou moins un responsable : la « dette technique ». Donc on pourrait croire à première vue qu’il s’agit d’un problème technique. Mais non.

La dette technique : un héritage d’une vision court-terme

Car le problème technique, d’obsolescence ou de manque de flexibilité des applications à faire évoluer, est essentiellement lié à la vision court-terme qui a présidée aux changements successifs de logiciels. En d’autres termes, les choix de solutions n’intégraient nul critère d’évolutivité pour le futur. Or le développement durable est une question préoccupante pour l’IT, comme pour la Terre entière.
Selon le rapport, les sources de la dette technique, sont, aux États-Unis, les décisions IT (47 %) et la pression de livrer les applications (43 %) et en Europe, la mauvaise documentation des exigences des projets (42 %). Mais comme « ce que l’on conçoit bien s’énonce clairement » … On est probablement à nouveau dans le péché originel : si les objectifs et les bénéfices recherchés ne sont pas clarifiés avec toutes les parties prenantes, ce qui sera conçu, ne sera pas bon. De même, changer le logiciel dans la précipitation n’est pas non plus l’idée du siècle.

Observer, écouter, comprendre, évaluer … avant de construire

Observer - Ecouter - Comprendre - Construire

Source samandel.com “conversation” – licence (CC BY-NC-ND 2.0)

Avant de changer de logiciel, il est utile de questionner les parties prenantes et clarifier les besoins de changement, les objectifs, ainsi que le contexte et les hypothèses de départ. Mais il faut aussi comprendre les typologies de solutions logicielles d’entreprise et ce qu’elles impliquent, pour piloter efficacement le changement.

En matière de solutions d’entreprise, Il y a des axes d’analyse incontournables avant décision. On évoquera : couverture fonctionnelle, analyse économique, architecture, écosystème, usage, retour d’expérience, support.

Par conséquent, il est surprenant que souvent les décisions ne prennent ni en compte toutes les parties prenantes, ni tous ces axes. Sachant que les critères de choix sont à adapter selon les besoins des organisations. Prendre le temps de le faire, au juste nécessaire, éviterait de perdre beaucoup de temps pour arriver à des situations insatisfaisantes.

Parce que changer de logiciel n’est pas le cœur du problème, ni la solution.
C’est juste un glissement sémantique qui pourrait en dire beaucoup sur notre interprétation du monde, comme évoqué dans cet article.

Tags

Laisser un commentaire

Your email address will not be published.

top