Vous êtes-vous retrouvé dans la situation où le logiciel central à votre organisation arrivait en fin de vie ?
La plupart des projets que nous menons avec nos clients nécessitent de remplacer un existant. Lorsqu’il s’agit de suppléer un processus de travail manuel pour gagner en productivité, la mise en place se fait en parallèle de la production. Et cela même si les ressources internes doivent faire face à une surcharge de travail (par exemple, pour assurer une double production permettant de tester la nouvelle solution). Le projet de remplacement suit un planning sans trop de contraintes.
En revanche, lorsqu’il s’agit de remplacer un logiciel utilisé de façon intensive par de nombreux utilisateurs, les étapes se multiplient, et les risques aussi.
Enjeu de périmètre
Lorsqu’un logiciel central dans une organisation est en fin de vie, son remplacement est l’occasion de faire différemment. L’entreprise peut revoir ses processus internes pour profiter pleinement du nouveau logiciel.
Généralement, le logiciel est utilisé par un service principal avec des contributeurs issus de services annexes. Les flux de données en place depuis des années, l’alimentent.
La question se pose alors de savoir comment piloter le projet : va-t-on revoir l’ensemble de l’urbanisation dès le départ ? Va-t-on se concentrer, dans un premier temps, sur un remplacement quasi isofonctionnel pour les utilisateurs ?
En général, les contraintes de planning du projet répondent à cette question. Pour faire simple et se donner les moyens de déployer rapidement le projet, il est logique d’en limiter le périmètre initial. C’est surtout le cas si le logiciel en place montre de plus en plus régulièrement des signes de défaillance.
Cela veut dire conserver les flux entrants, tenir compte de la structure des données en place. Parfois, il s’agira de devoir composer avec des processus exécutés en dehors du logiciel qu’il serait plus logique d’effectuer dans la solution.
À cela s’ajoute le fait qu’il faut que l’organisation et son partenaire éditeur apprennent à se connaître pour éclairer progressivement le chemin.
Le changement
Les utilisateurs sont habitués à suivre un processus en place depuis des années. Au départ de la réflexion, la plupart des utilisateurs se projettent sur ce que le nouveau logiciel permet d’améliorer par rapport à leur existant. Si l’éditeur a fait son travail, les démos d’avant-vente ont mis en valeur les bénéfices de la nouvelle solution.
Arrivent ensuite les premiers ateliers qui mettent en évidence le rôle du management : le changement, c’est bien, mais uniquement quand cela concerne les autres. Il est loin d’être évident de convaincre toutes les parties prenantes que le gain se fera au plan global.
Certains utilisateurs voudraient bénéficier des nouveautés, mais quand même continuer à fonctionner comme avant. L’arrivée du nouveau logiciel va donc changer les habitudes et il faut accompagner ce changement pour éviter le fameux « c’était mieux avant ».
Une implémentation nécessairement itérative
Le succès de la mise en place d’un projet d’envergure s’appuie sur la confiance entre toutes les parties prenantes. Nous avons déjà évoqué les enjeux de communication pour bien comprendre le besoin (cf. Comment bien comprendre le besoin et Si on parlait de linguistique).
De l’autre côté, l’éditeur s’efforcera d’aider le client à s’approprier les concepts de la solution le plus rapidement possible. L’objectif est de lui permettre de remettre en perspective, voire de challenger, la réponse aux besoins telle qu’il l’avait imaginée. Puis, au fil du projet, les équipes vont monter en compétence, découvrir de nouvelles façons de faire, envisager d’autres usages. De nouvelles études vont être lancées pour élargir le périmètre initial.
À ce stade, le projet est réussi : la solution est devenue la leur !
Si vous avez un logiciel de production à remplacer, n’hésitez pas à nous contacter !
Article rédigé par
Richard Loubéjac
Cofondateur de J2S
