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.
Articles de la série :
- Partie 1 – Fragmentation
- Partie 2 – Résistance au changement
- Partie 3 – Réorganisations, fusions et acquisitions et migrations
- Partie 4 – Justification et approches
Au cours des dernières semaines, nous avons examiné les promesses et les pièges de la rationalisation des applications, pourquoi elle est importante, comment elle peut fonctionner, et comment elle peut très mal tourner.
Je ne m’excuse pas d’avoir commencé cette dernière partie en répétant que la communication est essentielle; Les entreprises doivent communiquer correctement leurs besoins, et les TI doivent articuler l’art du possible pour répondre à ces besoins, et les deux parties (même si tout le monde devrait être du même côté) doivent arriver à une position convenue mutuellement.
Le facteur Population
Pour trouver ce terrain d’entente, le rôle de l’analyste d’affaires, aujourd’hui moins courant, devrait être considéré comme vital. Un bon BA maîtrise à la fois le jargon des affaires et de l’informatique, pas que vous voudriez nécessairement qu’il traite des transactions financières ou code en C++, c’est plutôt un traducteur hautement qualifié avec un œil pour le détail et une compréhension approfondie des processus, des données, et surtout des personnes.
Il est aussi important de considérer toute forme de rationalisation comme un projet d’affaires, pas comme un projet TI. Pour rationaliser, il sera nécessaire que l’entreprise et les TI apportent des changements, qui seront :
- Modifications du processus
- Changements dans les arrangements de gouvernance
- Modifications des applications, de l’hébergement, du stockage de données ou des réseaux de communication
… et presque certainement une combinaison de la plupart, sinon de toutes. Le point crucial est que c’est un changement pour l’entreprise, en particulier un changement dans les modes de travail, donc il faut l’aborder du point de vue du changement d’affaires, avec le changement TI en soutien, et non l’inverse.
Bien sûr, on peut penser que les TI doivent évoluer pour des raisons de conformité, de licences, de contraintes techniques émergentes ou d’autres facteurs similaires, mais cela entraînera un changement pour l’entreprise. Et comme on l’a vu plus tôt, les gens n’aiment pas le changement parce qu’ils n’aiment pas le changement. Il est donc bien préférable d’aborder le côté affaires du projet et de faire en sorte que les TI correspondent à l’exigence, même si la raison du projet d’affaires est que les TI doivent changer, plutôt que de gérer un projet TI et de demander à l’entreprise de se conformer (et je pense que nous connaissons tous la réaction probable à cette dernière approche). Après tout, les TI existent pour soutenir l’entreprise et répondre à ses besoins en mettant en œuvre et en gérant la technologie nécessaire.
À ce stade, il vaut la peine de faire une brève digression dans le monde du BA et le coût de la qualité. Il existe des outils et des approches, comme Lean Six Sigma, qui se concentrent sur l’amélioration des affaires et la réduction du coût de la qualité, et ces approches peuvent jouer un rôle important dans la rationalisation, car le changement d’affaires résultant de ce type d’analyse peut servir de levier pour soutenir le changement en TI. En adoptant ce type d’approche, où le changement est initié et exprimé dans le langage des affaires plutôt que dans le langage des TI, il est au moins plus probable que l’entreprise comprenne ce qui est nécessaire, et il est même possible que, si elle est abordée de cette façon, elle devienne la défenseure du changement plutôt que de s’y opposer.
En apportant des changements, nous ne devons jamais perdre de vue que, quelle que soit la raison du changement, il présente toujours une opportunité.
La rationalisation devrait toujours être une considération instinctive en TI moderne. Comme discuté plus tôt, la grande majorité des entreprises ont maintenant un paysage informatique fragmenté, et rationaliser pour réduire les coûts, augmenter l’efficacité et (pour les TI) augmenter la soutenabilité devrait toujours être l’objectif, et il n’y aura jamais de meilleur moment pour rationaliser que lorsqu’un autre changement sera nécessaire.
Et il sera toujours préférable de s’engager avec l’entreprise, de susciter un esprit de participation et d’appropriation, et de travailler ensemble pour provoquer le meilleur changement possible. Cette approche a beaucoup plus de chances de succès que de chercher à imposer un changement pour ce qui peut sembler être un changement technique abstrait à une entreprise réticente, qui est susceptible de considérer que rien ne va mal et qu’il n’y a pas besoin d’un tel changement.
Encore une fois, le rôle de la BA prend de l’avant-plan, car ce sont eux qui devraient exprimer les avantages commerciaux du changement et, ce faisant, mettre l’entreprise de côté.
Supportabilité
Un moteur clé du changement côté TI devrait être la soutenabilité, car le coût de support d’une application peut, avec le temps, largement dépasser l’achat initial.
C’est là que disposer d’une architecture d’application bien articulée, superposée à une architecture d’infrastructure technique entièrement développée, devient d’une importance vitale. L’architecture applicative ne peut pas exister en isolation splendide, mais doit toujours être un élément de soutien de l’architecture d’entreprise et agir en appui au modèle opérationnel de l’entreprise.
À mon avis, les considérations clés pour le soutien informatique sont l’utilisabilité, la disponibilité, la conformité (à tous égards) et l’interopérabilité.
Comme je l’ai déjà dit, la capacité de maximiser la supportabilité en maintenant l’utilisabilité et la conformité offre une meilleure probabilité d’une bonne interopérabilité et, de façon cruciale, donne le contrôle technique aux professionnels informatiques chargés de s’assurer que le système fonctionne comme prévu.
C’est là qu’un autre élément doit entrer en jeu : l’approvisionnement.
L’approvisionnement en TI pour toute nouvelle application doit tenir compte de la supportabilité, de l’interopérabilité et de la capacité à évoluer et à se conformer au fil du temps pour toute solution proposée. Il est trop facile d’acheter une solution « best of breed », pour découvrir qu’elle convient parfaitement à une partie de l’entreprise, mais qu’elle est médiocre du point de vue de l’interopérabilité et donc une solution sous-optimale vue du point de vue de l’architecture d’entreprise.
Alors, comment on y arrive?
Personne ne dit que ce sera facile, mais si un boulot vaut la peine d’être fait...
La première chose à reconnaître, c’est que la rationalisation a peu de chances de fonctionner comme un « big bang ». Tout tourne autour de la convergence, de la mise en place du cadre dans lequel l’entreprise peut opérer un changement convergent pour évoluer et maintenir un paysage d’applications rationalisé. Ce changement ne peut se produire qu’avec le temps, à un rythme que l’entreprise et les TI peuvent gérer, mais cela peut s’étendre de plusieurs semaines à des mois; Si cela semble prendre plusieurs années, il se peut qu’une analyse supplémentaire soit nécessaire, car tout plan qui dépasse 12 à 18 mois sera toujours tellement susceptible de changer qu’il ne vaut guère la peine de s’y intéresser.
Dans ce contexte, il y a un vieux dicton en gestion de projet (enfin, un que j’ai entendu et utilisé en tout cas), « pour manger l’éléphant, il faut d’abord le couper en morceaux de la taille d’une bouchée ». Si un plan de rationalisation semble exiger qu’une entreprise mange un éléphant entier et sans mâcher, ce n’est pas un plan, mais une recette pour un échec certain.
Un bon plan aura suffisamment de détails pour que tout le monde comprenne ce qui est attendu, qui livrera quoi, dans quel ordre, et en particulier où les dépendances – internes et externes – peuvent être trouvées, mais il ne devrait pas s’agir d’un calendrier d’activités de plusieurs années au niveau des tâches, presque impossible à gérer, et donc impossible à livrer aussi.
Comment pouvons-nous changer cet état d’esprit?
L’essence même de la rationalisation, en fait presque tout projet de changement d’affaires financé par les TI, est que tout repose sur la recherche d’un terrain d’entente, ce qui est plus facile à dire qu’à faire.
Il est difficile pour le personnel local de prendre en compte la vision d’ensemble des défis informatiques auxquels fait face la haute direction, et il est difficile pour la haute direction de ne pas minimiser les besoins bien réels des équipes au niveau local.
Comme mentionné précédemment (plusieurs fois!), la clé du succès est une communication claire, mais apprendre ces compétences essentielles prend du temps, surtout chez les personnes habituées à faire leur propre truc.
Ce qui peut accélérer ce processus d’apprentissage, c’est la fixation d’objectifs réalistes et l’introduction d’incitatifs financiers pour les atteindre, car c’est le langage que tout le monde comprend!
Les milieux des affaires et des TI doivent se retrouver sur de nombreux facteurs, tels que :
- Ce que l’on entend par « monnaie » dans les applications – par exemple, défini comme étant au plus d’une version derrière le courant et avec pour objectif d’être toujours à jour;
- Les procédures pour choisir la méthode de maintien à jour – par exemple, la conteneurisation (même si ce n’est pas possible!), la migration, la rationalisation, etc.;
- Les incitatifs financiers pour le service local – par exemple, le montant économisé en ne devant pas avoir à soutenir l’ancien système;
- Les pénalités pour le service local en cas de non-conformité – par exemple, devenant responsable de tous les frais de pension alimentaire de l’ancienne demande, y compris les coûts de personnel pertinents dans tous les domaines;
- Comment s’assurer que la haute direction puisse allouer un budget suffisant pour l’équipement, les logiciels et la formation afin d’atteindre ces objectifs.
Espérons que cela aidera grandement votre entreprise à rester à jour, en sécurité et à prospérer dans un monde en constante évolution.
En conclusion
J’ai probablement fait paraître la situation pire que dans bien des organisations.
Cela dit, j’ai probablement aussi un peu édulcoré la carte pour d’autres.
Si j’ai déclenché des signaux d’alarme et causé de la panique, je m’excuse pour la panique, mais pas pour les signaux d’alarme.
Trop d’organisations ont laissé leur paysage applicatif se fragmenter vers l’ingérabilité, augmentant énormément leur risque d’affaires en conséquence. Ce n’est presque certainement pas une action intentionnelle, mais plutôt un « péché d’omission, non de commission », pour être un peu théologique un instant.
Fait intéressant, les comportements à risque impliquent souvent de ne rien faire pour ne pas faire un faux pas, et en conséquence involontaire, augmenter le risque, ce qui est un exemple de ce type de comportement (ou plus précisément de son absence), mais cela sera probablement pour un autre article une autre fois.
La bonne nouvelle, c’est qu’aucune de ces fragmentations n’est irrécupérable. Comme l’a chanté D :Ream (avec le professeur Brian Cox aux claviers) « Things Can Only Get Better ».
Avec une analyse adéquate des besoins de l’entreprise, une architecture d’application bien articulée et un plan convergent de rationalisation, toute organisation peut, avec le temps, s’installer dans les hautes terres ensoleillées d’un paysage applicatif pleinement rationalisé, avec tous les gains d’efficacité que cela implique.
J’ai vu des exemples réels de tous les pièges que j’ai décrits dans cette série, ou peut-être des exemples réels de morts seraient une façon plus précise de le dire, mais j’ai aussi vu de bons travaux à divers endroits qui ont connu de réelles améliorations.
Mes collègues professionnels chez Ferroque Systems ont aussi déjà vu tout cela, et possèdent une véritable expertise pour aider n’importe quel client à planifier et migrer hors du marais fragmenté pour s’aventurer dans les champs élysés des applications rationalisées, et un véritable enthousiasme à le faire.
Enfin, souvenez-vous toujours : la communication est la clé!
