Préface
La rationalisation des applications est un aspect crucial du cycle de vie des affaires et des TI, et un sujet que nous avons déjà abordé.
Ferroque Systems s’est associé à Stephen O’Grady; un collègue de confiance pour notre équipe, expert en rationalisation d’applications et vétéran de la gestion informatique du Royaume-Uni pour une série d’articles invités. Ces articles traitent de la rationalisation des applications et de son importance pour l’organisation moderne.
Dans le billet précédent de cette série (Partie 1), nous avons fait un bref parcours en arrière-plan pour comprendre pourquoi nous avons fini par avoir à réfléchir à la rationalisation des applications. Il a exposé certains des défis courants concernant pourquoi on fait généralement peu pour remédier aux problèmes, et dans ce billet, nous allons approfondir ces défis.
« Le changement, c’est mauvais »
Il y a un problème bien connu que nous avons tous rencontrés en TI à plusieurs reprises : les gestionnaires ne veulent pas de changement parce qu’ils ne veulent pas de changement.
Le changement est inconfortable et inconnu, et la plupart des gens feront presque n’importe quoi pour maintenir le statu quo. Comme quelqu’un me l’a déjà dit, les bébés sont souvent assez à l’aise dans une couche sale parce qu’elle est chaude, confortable et familière – c’est un problème seulement pour tout le monde.
Vous pouvez rationaliser les avantages du changement, démontrer comment l’entreprise peut être améliorée et comment tout ira mieux une fois le changement effectué (quel qu’il soit), et pourtant, les gens résistent au changement avec beaucoup de force. Si j’avais la solution parfaite à ce problème, j’écrirais ce texte sur mon île privée dans les Caraïbes; Cependant, les gens peuvent être « emmenés sur le chemin » vers le changement.
Ce n’est peut-être ni simple ni confortable, et il n’existe pas de solution universelle. Cependant, si un sentiment de propriété peut être encouragé, où les gens sentent que le changement est leur choix et leur décision, peut-être même leur idée, le changement peut être fait et fait pour le mieux.
En général, les gens comprennent où sont les faiblesses dans leur entreprise et sont désireux de changer, mais il faut que ce soit leur changement. Le changement ne peut pas être imposé; Il faut que ça donne l’impression de venir de l’intérieur. Mais ça, c’est pour un autre chapitre!
« Trop cher »
Probablement la raison la plus souvent entendue pour ne pas mettre à niveau ou rationaliser les systèmes est le coût. Pour être peu charitaire, c’est un argument fallacieux, car les coûts augmentent avec le temps, et le coût élevé est souvent le résultat de changements ou de mises à niveau qui sont retardés à plusieurs reprises.
Pour être plus juste, avec des budgets et des ressources limités, il y aura toujours la tentation de saisir les économies annuelles dès que possible. Malheureusement, cela ignore les problèmes à plus long terme qui peuvent en découler, ainsi que la hausse des coûts ou même la viabilité de futures rationalisations ou améliorations. C’est pourquoi il est crucial de comprendre le TCO global d’une application, afin de s’assurer que les coûts de possession durs et souples sont pris en compte (peut-être un sujet pour une autre fois).
Il est, bien sûr, dans l’intérêt des fournisseurs de logiciels d’engager les clients dans des ententes de maintenance et de support, et c’est toujours une option attrayante pour les clients afin d’y réaliser des économies. Après tout, les logiciels n’ont pas besoin d’être huilés, n’est-ce pas? Alors, comment cela pourrait-il mal tourner?
Cependant, en réalisant cette prétendue économie, la nécessité de pouvoir maintenir la monnaie est trop facilement négligée. Surtout dans ce monde moderne du « Evergreening » (un terme qui ne semble pas avoir continué d’être utilisé, mais qui existe toujours en pratique), il y a une hypothèse inhérente que tous les composants seront maintenus à jour. Comme les différents composants de la plateforme peuvent évoluer au fil du temps, rien ne garantit qu’une application non maintenue continuera de fonctionner comme prévu sur la plateforme, car il pourrait y avoir une dépendance qui n’est plus satisfaite.
Maintenant, à court terme, cela ne fera probablement pas une grande différence, car il est dans l’intérêt des fournisseurs de plateformes de maintenir un certain degré de rétrocompatibilité afin de ne pas aliéner les clients ou de rendre la vie inutilement difficile. Cependant, à plus long terme, cela pourrait limiter le développement de la plateforme, donc une compatibilité continue ne peut jamais être supposée.
Si un client possède une application qui a été mise à jour pour la dernière fois il y a plus de dix ans et qui est utilisée dans plusieurs instances comme systèmes clés dans une organisation, cela pourrait être considéré comme une menace. Il se peut qu’il n’y ait aucun support pour l’application, encore moins sur la plateforme qui doit être retenue pour héberger cette application.
Dans ce cas, l’option de passer directement à une version plus récente aura depuis longtemps disparu. La possibilité de migrer vers le produit d’un concurrent en utilisant des outils fournis conçus pour aider cela vous fera aussi signe dans le rétroviseur. C’est, soit dit en passant, un exemple tout à fait réel que j’ai vu dans plus d’une organisation, qui reste à ce jour non résolu pour aucune d’entre elles.
La seule option ici est de lancer un projet coûteux et chronophage qui implique beaucoup d’analyses et de code personnalisé pour migrer des données d’une application héritée vers une nouvelle, tout cela grâce à la « capture d’économies ». Inutile de dire que cela n’arrive que lorsque la situation devient critique, que le problème est jugé urgent par la haute direction, et qu’on reproche beaucoup de responsabilités pour expliquer pourquoi il n’a pas été réglé plus tôt. Ce jeu de blâme peut souvent durer un certain temps, alors que le problème reste non résolu et que les enjeux continuent de s’aggraver, mais à quelle fréquence voit-on cette simple leçon oubliée dans la même organisation pour le prochain système critique pour l’entreprise dans le même État?
De manière flagrante, ce report des mises à jour et ce manque de maintien de la monnaie contribuent à la « dette technique »; Je suis certain que beaucoup d’entre nous connaissent ce terme et les conséquences des « intérêts accumulés ». La plupart des organisations ignorent cela; cependant, je connais des organisations où les gestionnaires TI maintiennent un « registre technique de la dette », un simple tableur des applications et de leur état de mise à jour, et chaque fois qu’une décision est prise d’imposer une solution de contournement, d’ajouter un nouveau composant (plutôt que d’appliquer un changement bien conçu), etc., une nouvelle entrée est faite dans le registre, et ce registre est périodiquement examiné pour voir combien d'« intérêts » ont accumulé.
Choix des départements
Je comprends que la prochaine déclaration me fera passer pour un dinosaure obsédé par les mainframes, mais laisser les décisions d’approvisionnement TI aux départements sans référence aux TI d’entreprise ou à la haute direction était et reste une recette pour le désastre.
Cela peut être le cas même lorsqu’il y a une véritable expertise en TI dans le département, si la stratégie d’entreprise n’est pas claire et appliquée, ou si les experts locaux en TI ont une revendication pour une meilleure façon de faire, ou une préférence ou une aversion personnelle pour certaines solutions techniques.
Ce sera toujours attirant et inspirant de « faire ce que tu veux ». Qui n’a jamais pensé « je pourrais faire un meilleur travail qu’eux », c’est-à-dire l’informatique d’entreprise, la haute direction ou qui que ce soit? Et, pour être juste, ça peut être le cas; Vous pourriez bien être en mesure de prendre de meilleures décisions localement, car vous connaissez probablement mieux votre entreprise. Un autre défi courant est le temps : les ressources TI sont limitées, donc certains départements peuvent ne pas vouloir attendre les ressources informatiques appropriées pour leur projet favori, et peuvent donc prendre sur eux de gérer leur propre projet avec peu de considération des conséquences plus larges.
Cependant, et c’est un énorme « cependant », en ne connaissant pas la situation dans son ensemble, il est très facile de prendre une mauvaise décision involontaire. Par exemple, au niveau local, il peut y avoir une connaissance limitée des accords de licence corporatifs. J’ai vu des cas où des départements ont dépensé leur propre budget pour des licences logicielles, ce qui a dupliqué des fonctionnalités déjà payées sur une base corporative et a effectivement mené à deux paiements sans possibilité de se retirer de l’accord global. Cela ne semble peut-être pas être un problème au niveau local, mais cela a un impact direct sur les résultats globaux.
Je ne dis pas que les départements ne devraient pas avoir leur mot à dire dans leur propre TI, loin de là. Ce sont souvent les seules personnes à vraiment comprendre le métier du « charbon face », et ils devraient à juste titre être considérés comme les experts en ce qui concerne les exigences. Dans les cas où ils ont une exigence vraiment unique, cela peut être mieux répondu au niveau local. Cependant, cela devrait toujours être visible au niveau de l’entreprise, car cette exigence pourrait ne pas être unique éternellement, et cette capacité locale pourrait devoir être réutilisée ailleurs.
Le corollaire à cela est l’exigence locale « unique » qui est en fait courante. Une vérité que les fournisseurs de logiciels préfèrent ne pas aborder est qu’il y a remarquablement peu de variations de fonctionnalités entre plusieurs systèmes. Après tout, tous les produits des concurrents existent dans les mêmes cadres réglementaires et doivent se conformer à des exigences identiques en matière de fonctionnalités et de rapports. La façon dont ils se font concurrence est à travers les « bons à avoir », qui peuvent être plus ou moins pertinents pour les besoins des départements et/ou des utilisateurs individuels.
Astuce d’expert : envisagez d’utiliser un modèle MoSCoW pour saisir les exigences d’affaires en organisant en « Indispensables », « Devraient avoir », « Pourraient avoir » et « Ne veulent pas avoir » (cette fois), afin de permettre la priorisation d’apporter les meilleurs et immédiats bénéfices dès le début.
Cela nécessite un engagement adéquat entre les utilisateurs au niveau départemental et les TI de l’entreprise, afin que les besoins des utilisateurs soient satisfaits, mais que toutes les fonctionnalités soient connues et comprises. Ainsi, lorsque de « nouvelles » exigences apparaissent (qui ne sont peut-être pas du tout nouvelles), l’inventaire complet de ce qui est disponible est connu. Il arrive souvent que ces exigences puissent être satisfaites à partir de quelque chose déjà disponible ailleurs dans l’entreprise, et ces applications existantes peuvent être déployées pour de nouveaux utilisateurs à faible coût ou sans coût et avec un minimum de délai.
La fragilité croissante des systèmes
Bien sûr, comme je l’ai dit plus haut, les logiciels ne s’usent pas. Il n’y a pas besoin d’entretien régulier sur une application elle-même, car elle ne changera pas du tout à moins que quelqu’un ne fasse quelque chose.
Malheureusement, ce « quelque chose » sera soit des changements imposés de l’extérieur, par exemple des mises à jour réglementaires dans les systèmes RH ou comptables, soit des modifications à la plateforme sur laquelle il se trouve. Ces changements imposés peuvent, avec le temps, causer des problèmes.
Il n’y a pas d’option concernant les changements réglementaires, mais les applications recevant ce type de mises à jour seront normalement entièrement supportées, bien qu’elles ne soient peut-être pas sur une version actuelle. Il existe cependant une option pour les changements de plateforme, bien que mauvaise : vous pouvez choisir de ne pas accepter de modifications pour que l’application puisse continuer à fonctionner telle quelle sans avoir besoin de mises à jour.
Cela semble être une option attrayante puisqu’elle signifie des économies maintenant, mais cela ignore le fait qu’à un certain moment cela cessera de viabilité, et que le coût de mise à niveau sera probablement plus élevé que le coût total de maintien de la devise. Il est aussi probable que la perturbation d’une mise à niveau majeure ou d’un changement majeur ne sera plus significative que ce qu’aurait été un changement progressif. Comme mentionné plus haut, il s’agit d’un exemple d'« intérêts » qui s’accumulent en raison de la « dette technique ».
Départements réticents à investir
Qui parmi nous n’a jamais utilisé l’expression « Si ce n’est pas cassé, ne le répare pas »? C’est un sentiment admirable, et très pertinent dans un monde assez statique et mécanique.
En TI, notre situation est un peu différente. Bien que le « ça » en question – l’application – ne soit pas « cassé », il existe dans un environnement en perpétuel changement. Au niveau des affaires, les exigences évolueront, tant en interne que celles imposées de l’extérieur, et au niveau technique, la plateforme sur laquelle elle repose, tant matérielle que logicielle, continuera d’évoluer.
Les départements hésitent souvent à investir dans des changements TI ou même dans un soutien continu, car selon eux, l’application est correcte telle quelle, alors pourquoi dépenser de l’argent?
À court terme, c’est compréhensible, car il y a toujours d’autres choses à faire avec l’argent, ou simplement des économies à faire. Mais avec le temps, alors que les TI évoluent dans le monde en général, le moment viendra presque certainement où quelque chose se produira qui forcera un changement, et pour lequel l’entreprise pourrait ne pas être préparée.
Par exemple, de nombreuses entreprises se sont accrochées à Windows XP, utilisant des applications qui n’étaient prises en charge que sur XP, après la fin de vie de XP. C’était souvent pour économiser des coûts, car les entreprises avaient des dépenses prioritaires plus élevées à gérer.
Nous nous souvenons tous du virus WannaCry, qui a eu d’énormes répercussions sur certaines entreprises qui s’étaient exposées en restant sur des systèmes d’exploitation vieux et non patchés. Ils faisaient cela pour diverses raisons, mais les plus souvent discutées étaient d’économiser de l’argent en ne payant pas pour les mises à jour vers Windows, et la nécessité de continuer à utiliser d’anciennes applications qui ne fonctionnaient pas sur les versions plus récentes de Windows.
Ces économies apparentes sont devenues un coût plus élevé pour beaucoup lorsque le virus a frappé, car les coûts liés à l’élimination du virus et à la mise à niveau des systèmes pour prévenir d’autres attaques étaient presque certainement supérieurs au coût du soutien continu et de la mise à niveau pour maintenir la monnaie. Et cela sans compter le coût du paiement de la rançon, que certaines entreprises ont aussi fait avant qu’un remède ne soit trouvé.
Alors, qu’est-ce qu’on fait?
C’est le gros truc!
Les TI et les affaires doivent travailler ensemble là-dessus, et encore une fois, la communication est la clé.
L’informatique doit bien comprendre à l’entreprise quels sont les risques liés au fait de ne pas maintenir l’application à jour, et de conserver de nombreuses applications répondant au même besoin d’entreprise et/ou à plusieurs versions de la même application (y compris les versions héritées qui ne sont plus prises en charge par le fournisseur). Même s’il peut y avoir un risque de « mettre tous vos œufs dans le même panier » (c’est-à-dire de garder une seule version d’application), au moins vous savez où et où se trouve le panier, et vous avez probablement une bonne idée des forces et faiblesses du panier. Avec un éventail limité d’applications à supporter, votre personnel TI ou fournisseur de soutien devrait développer des niveaux d’expertise beaucoup plus élevés dans les spécificités de chaque application, car ils seront moins dispersés.
Les entreprises doivent exprimer clairement leurs besoins en termes d’exigences plutôt que de solutions. Trop souvent, l’entreprise prend une décision sur une application TI qui peut sembler être la solution idéale à ses besoins, sans tenir compte de l’environnement dans lequel elle doit exister ni des autres applications dans l’entreprise avec lesquelles elle doit interagir.
À mon avis, les points clés simples ici doivent être :
- L’entreprise exprime clairement ses exigences, sans passer directement à une solution.
- TI définissant une architecture d’application pour servir de cadre approuvé dans lequel toutes les applications (et tous les autres composants) doivent exister.
- Un inventaire clair est produit pour toutes les applications et infrastructures de soutien (y compris les propriétaires désignés pour toutes les applications).
- Une feuille de route en cours de définition conjointe entre l’informatique et l’entreprise pour passer de la situation actuelle aux hautes terres ensoleillées, avec un portefeuille rationalisé d’applications sur une infrastructure bien soutenue.
