La plupart des entreprises ont au moins un système dont tout le monde se plaint. Il est vieux, il semble daté, et seules une ou deux personnes le comprennent vraiment. La réaction naturelle est de vouloir s'en débarrasser. Parfois, c'est la bonne décision. Souvent, ce n'est pas le cas, ou du moins pas encore.
La question à laquelle j'essaie de répondre n'est pas « ce système est-il vieux ? » C'est « ce système fait-il toujours son travail à un coût que l'entreprise peut supporter ? »
Commencer par ce qui ne va pas réellement
J'aime commencer par les problèmes que les gens peuvent décrire avec leurs propres mots. Un changement simple prend des semaines. Les rapports ne correspondent pas à ce qu'il y a sur l'étagère. Tout s'arrête lorsqu'une personne en particulier est en vacances, car elle est la seule à savoir comment fonctionne la clôture mensuelle. Le système est tombé en panne deux fois le trimestre dernier et les commandes se sont accumulées.
Ce sont des éléments utiles, car ils lient le logiciel au temps réel et à l'argent réel. « C'est vieux » ne figure pas sur cette liste. Un système vieux de dix ans qui nécessite rarement des changements peut être moins cher à conserver qu'à remplacer. Et un système construit il y a deux ans peut déjà être un problème si l'entreprise a changé autour de lui.
Additionner ce qu'il coûte réellement à conserver
Le coût d'un vieux système est bien plus élevé que la facture d'hébergement. Il inclut :
- les heures que les gens passent sur des solutions de contournement et à saisir la même chose deux fois
- les projets retardés parce que le système est difficile à modifier
- les temps d'arrêt, et la panique qui les accompagne
- le risque de sécurité si le système ne peut plus être mis à jour
- la difficulté à trouver quelqu'un qui puisse s'en occuper
Ces coûts sont généralement répartis entre plusieurs départements, donc personne ne voit le total complet. Une courte revue règle cela. Listez les tâches les plus importantes que le système effectue, qui en dépend, ce qui casse souvent, et ce dont l'entreprise pense avoir besoin au cours des deux ou trois prochaines années. Des chiffres approximatifs suffisent. Soyez juste honnête sur ceux qui sont des estimations.
Vous avez plus de deux options
Il est rare d'avoir le choix entre ne rien faire et tout reconstruire. Entre les deux, vous pourriez :
- réparer la partie qui cause le plus de douleur
- remplacer une seule pièce, comme les rapports ou le lien avec votre logiciel de comptabilité
- mettre une couche propre et moderne autour de la partie difficile à changer pour que les nouveaux outils puissent travailler avec
Les petites étapes ne sont pas toujours la réponse, cependant. Si les données à l'intérieur du système ne sont pas fiables, ou si le système ne peut tout simplement pas faire ce dont l'entreprise a besoin ensuite, le patcher peut simplement prolonger le problème. L'essentiel est de choisir délibérément plutôt que par habitude.
Les règles non écrites sont la partie difficile
Lorsque vous remplacez un système, reconstruire les écrans est la partie facile. La partie difficile, ce sont toutes les petites règles que personne n'a écrites : le client qui bénéficie d'un prix spécial, la commande autorisée à sauter une étape, l'export sur lequel quelqu'un en comptabilité compte chaque vendredi. Ces détails sont souvent le véritable cœur du système.
Avant de passer à quelque chose de nouveau, je veux savoir où vivent les données fiables, comment les doublons et les vieux dossiers seront gérés, et comment nous prouverons que le nouveau système donne les mêmes bonnes réponses. Il est également utile de planifier comment revenir en arrière si quelque chose tourne mal, et s'il faut faire fonctionner les anciens et nouveaux systèmes côte à côte pendant un certain temps. Un bon plan explique comment vous saurez que les données sont correctes, pas seulement comment elles sont copiées.
Cinq questions avant de décider
Avant de recommander quoi que ce soit, je veux des réponses à cinq questions :
- Quel problème spécifique résolvons-nous ?
- Quel est le coût, et quel est le risque, si nous laissons les choses telles quelles ?
- Quelles limites sont vraiment fixes, comme le budget, les délais ou les réglementations ?
- Comment vérifierons-nous que la nouvelle approche fonctionne correctement ?
- Quelle est la plus petite étape utile qui réduit le risque sans nous enfermer plus tard ?
Si ces réponses sont floues, la prochaine étape appropriée est généralement une courte revue avec une date de fin fixe, plutôt qu'un grand projet. Vous devriez en ressortir avec une carte claire de vos systèmes, les principaux risques par ordre d'importance, des options réalistes et un ordre sensé pour les aborder.
Le résultat
Mettre à jour un vieux logiciel ne consiste pas à courir après la nouvelle technologie. Il s'agit de s'assurer que le système peut continuer à soutenir l'entreprise. Parfois, cela signifie une reconstruction. Plus souvent, cela signifie quelques réparations ciblées, une meilleure visibilité et une voie plus sûre pour l'avenir.