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 :
Dans le billet précédent (Partie 2) de cette série, nous avons abordé certaines causes courantes pour créer ou ne pas traiter la fragmentation des applications. Dans cet article, nous passerons en revue les pièges de fragmentation souvent causés par les réorganisations et les fusions et acquisitions (F&A).
Les conséquences des réorganisations et des fusions et acquisitions
Une fois que l’informatique s’est retrouvée dans le nouveau monde des applications départementales fragmentées, le plaisir supplémentaire des réorganisations et des fusions et acquisitions a commencé à jouer un rôle.
Il y avait, et il y a, toujours un dilemme lorsqu’une entreprise est réorganisée, ou qu’une nouvelle entreprise est ajoutée à une entreprise existante : faut-il forcer ce nouvel élément à migrer toutes leurs applications vers des plateformes existantes au sein de leur nouvelle activité, ou les laisser intactes et interagir avec elles comme s’il s’agissait d’une filiale?
Je l’ai vu faire des deux façons, et au début, cela finit souvent par des larmes et des démissions alors que la nouvelle entreprise est dépouillée de son identité et forcée à entrer dans le nouveau monolithe corporatif. Ce n’est pas seulement dû à la fusion des systèmes informatiques, mais cela joue certainement un rôle majeur. Dans le deuxième cas, on finit par se demander ce que « fusion » est censé signifier, puisque la nouvelle entreprise continue simplement comme avant, et adopte une sorte d’existence parallèle avec l’entreprise dont elle est censée faire partie.
Aucune des deux options ne fonctionne!
L’approche « sans intervention » dans les réorganisations et fusions peut présenter des défis supplémentaires. Si vous me permettez une brève anecdote à ce stade, j’ai observé un cas où la décision initiale a été prise de ne pas forcer l’entreprise acquise à entrer dans l’entreprise existante; ils ont plutôt été laissés gérer leurs propres systèmes. En ignorant les coûts liés à la double licence de pratiquement tout et à la maintenance de jeux parallèles de matériel, cela a introduit d’autres défis difficiles à surmonter.
Par exemple, il y avait un problème sérieux d’aussi banal que les numéros de série : les numéros de série utilisés par la nouvelle entreprise étaient trop longs pour être pris en charge par les systèmes d’entreprise existants, qui seraient nécessaires pour assurer le soutien une fois les produits vendus. Une fois analysée, la différence de longueur s’expliquait par le fait que dans chaque numéro de série figurait le numéro d’usine auquel chaque dispositif était produit. Cependant, il n’y avait qu’une seule usine impliquée dans l’acquisition, donc ces données étaient redondantes, mais ils insistaient néanmoins pour qu’elles soient conservées. Les autres usines, bien sûr, sont restées avec l’entreprise d’origine et étaient à ce moment-là complètement indépendantes.
Malheureusement, au sein de la nouvelle organisation mère, il y avait eu une autre acquisition récemment qui utilisait une approche « pratique ». Cette autre entreprise avait été forcée dans la camisole corporative, causant d’énormes retombées alors que les gens partaient en masse, et la nouvelle entreprise devenait presque sans valeur.
Pour cette raison, il était perçu comme préférable de traiter cette acquisition ultérieure avec prudence et de les laisser presque intactes comme une unité autonome, ce qui avait l’effet inverse mais presque aussi dommageable. L’entreprise avançait d’une manière presque ingérable, et du point de vue informatique, cela signifiait en fait doubler les coûts pour tout. Cette deuxième fusion a été moins un échec que la première, mais elle était loin d’être une façon optimale de faire.
Alors, y a-t-il une meilleure façon?
Il y en a, et c’est relativement simple : il faut reconnaître que, pour que l’ensemble de l’entreprise fonctionne efficacement et garde les coûts nets sous contrôle, un niveau minimum d’intégration est requis lors d’une réorganisation ou d’une fusion.
Il y a un besoin impérieux de rationaliser sur un ensemble central d’applications pouvant fonctionner à travers toute l’organisation, offrant une fonctionnalité uniforme et supportable au prix le plus réalisable.
Cela ne signifie pas que la nouvelle entreprise doit être forcée à intégrer la nouvelle organisation sous tous les aspects. Dans le cadre de ce changement, les duplications et chevauchements doivent être pris en compte, et la solution la plus pragmatique doit être trouvée pour chacun. Cela peut signifier conserver certaines fonctionnalités héritées qui remplissent un objectif précis, dans le cas de fonctionnalités apparemment similaires mais suffisamment différentes dans l’entreprise acquéreuse. Cela peut même signifier que l’entreprise adopte des demandes provenant de l’élément nouvellement acquis à travers l’entreprise héritée si ce qui est présenté à la partie est meilleur que ce qu’elle avait.
L’essentiel est que cela doit être analysé et planifié dans le cadre du changement, et non après l’événement, et que des décisions sensées et fondées sur des faits doivent être prises tôt.
Rationalisation lors de la migration
Il est souvent considéré comme une mauvaise idée de rationaliser les applications lors de la migration, par exemple lors du transfert de services de soutien entre départements ou fournisseurs, ou lorsqu’on réunit deux entreprises ou parties différentes d’une même entreprise.
Il peut sembler plus confortable de soulever et déplacer des applications telles quelles, car ainsi l’investissement dans l’application héritée n’est pas perdu, et le transfert de connaissances semble (en apparence) plus facile. Les migrations ont souvent des contraintes de temps, de sorte qu’on met l’accent sur la réalisation de la migration le plus rapidement possible (c’est-à-dire tel quel) et sur le « nettoyage » une fois le nouveau système en place; malheureusement, la plupart du temps (si je suis généreux), le « nettoyage » n’a jamais lieu.
Je dirais que le lift-and-shift n’est pas toujours plus facile. Dans le changement d’applications héritées, il y a une opportunité claire de passer à une plateforme actuelle et de rationaliser vers un ensemble plus mince d’applications.
Pour prendre un exemple très simple, si l’on migre plusieurs départements vers une nouvelle plateforme unique, il se peut qu’il existe de nombreux services publics identiques qui font exactement le même travail. C’est donc le moment idéal pour se réduire à une seule instance. J’ai vu cela dans plusieurs environnements très différents pour, de toutes choses, des clients FTP. Dans chaque cas, il y avait une culture où différentes parties de chacune de ces entreprises choisissaient leur propre client FTP, parfois face à une norme d’entreprise qu’elles choisissaient soit d’ignorer, soit dont elles n’avaient pas connaissance.
Au moment de la migration, des débats ont eu lieu sur la raison pour laquelle ils avaient besoin de ce client FTP spécifique, ce qui se résumait toujours à une question de confort, puisqu’ils faisaient tous EXACTEMENT la même chose. Dans ces cas, l’informatique d’entreprise a réussi à l’emporter, car c’était un argument si simple avec une économie évidente.
Pourtant, dans d’autres cas, cela n’a pas été perçu comme aussi simple. Dans un autre exemple, il existait de nombreux systèmes financiers hérités, principalement plusieurs instances de la même application mais exécutées séparément pour différentes parties de l’entreprise. Les choix étaient le lift-and-shift, ou une migration progressive vers une plateforme unique, nouvelle et à jour. Le transfert de transfert était le choix évident pour l’entreprise, car cela semblait être un transfert de connaissances plus facile, car le personnel partant pouvait le faire avant de partir et de passer au nouveau service de soutien.
Cependant, comme c’est si souvent le cas, cela a ignoré le facteur humain : les personnes qui perdent leur emploi ne sont peut-être pas très coopératives, et il y a peu de choses à faire pour qu’elles y parviennent. En mettant de côté ce facteur humain (tout comme l’entreprise l’a fait), il y a, selon moi, une erreur logique ici.
Les deux options étaient :
- Transférer tout tel quel vers un nouveau groupe d’utilisateurs, qui devront tout apprendre à partir de zéro, puis composer indéfiniment avec un ensemble décousu d’applications héritées hors support.
- Migrez chacune de ces applications héritées vers une plateforme unique, correctement maintenue et à jour, que le nouveau groupe d’utilisateurs devra apprendre à partir de zéro.
Vous verrez que le thème commun ici est que les nouveaux utilisateurs devront tout apprendre de toute façon, et le changement de vitesse préserve tous les problèmes hérités, alors que la rationalisation progressive de l’application sur une seule plateforme moderne peut être un peu plus difficile à assimiler pour les utilisateurs, à cause de l’absence supposée d’experts pour aider (qui ne pourraient probablement pas aider puisqu’ils perdent leur emploi). Mais ce sera beaucoup plus facile à l’avenir. Le seul véritable effort dans cet exemple est donc la migration des données, car il y a déjà beaucoup d’utilisateurs de la nouvelle plateforme qui pourront aider les nouveaux arrivants à transférer leurs connaissances.
Bien sûr, cela n’aurait probablement pas été aussi simple en réalité, mais il aurait certainement été plus simple de passer à une nouvelle plateforme avec quelques problèmes initiaux que de préserver l’héritage à tout prix.
Donc, la rationalisation pendant la migration ne devrait pas être vue comme un non-non. Tant que c’est bien planifié et exécuté, et que suffisamment de temps et de ressources sont alloués, cela peut être un moyen très efficace de simplifier le nombre de demandes. Pour ce faire, un inventaire est requis non seulement des candidatures, mais aussi :
- Les exigences que chaque candidature remplit.
- L’ensemble complet des fonctionnalités de chaque application (même si certaines ne sont pas actuellement utilisées).
- Une liste complète de tous les utilisateurs (jamais faite et toujours un problème après l’événement, car les utilisateurs et les exigences fonctionnelles seront manquées)
- Les fonctions commerciales que les utilisateurs remplissent (c’est-à-dire les rôles et responsabilités des utilisateurs).
- Les arrangements de support des applications.
- Les modalités de licence d’application, et ce que chaque licence couvre en termes de qui peut l’utiliser, où et comment.
- La plateforme sur laquelle se trouve l’application (et les plateformes couvertes par chaque licence).
- Des plans pour l’avenir de l’application?
- Besoins de soutien/gestion des applications, comme la fréquence des mises à jour.
Cela doit ensuite être pris en compte au niveau de l’entreprise, afin d’évaluer à quoi ressemble la couverture globale des applications et où il existe des lacunes, des chevauchements ou des doublons. Certains chevauchements et duplications peuvent être valides, comme lorsqu’il existe de véritables exigences spéciales, mais chacun doit être pris en compte afin d’atteindre un niveau approprié de convergence des applications tout en tenant compte d’exigences uniques.
Alors, où cela nous laisse-t-il?
Vous verrez d’après ce que j’ai dit plus haut (et auparavant) que les fusions et acquisitions, les réorganisations d’affaires et les migrations partagent des thèmes communs, et encore une fois, la clé est la communication.
L’entreprise doit exprimer ses exigences et, bien sûr, avoir le dernier mot, mais les TI doivent être autorisées à définir l’approche optimale en termes technologiques et doivent résister lorsqu’il est suggéré de suivre une voie sous-optimale.
S’assurer que quelqu’un est en place au milieu, qui agit comme intermédiaire, qui comprend à la fois les affaires et les TI, et peut agir comme arbitre lorsque des décisions difficiles doivent être prises, est crucial pour le succès de n’importe lequel de ces projets (ou même de N’importe quel projet TI, mais c’est un autre thème).
Ce n’est pas comme si les outils n’existaient pas pour soutenir tout cela, ni que ces problèmes n’avaient jamais été observés auparavant, mais je vous laisse réfléchir au fait qu’un produit courant pour un projet TI est les « Leçons apprises »; J’ai souvent vu les leçons entièrement documentées et soigneusement classées, mais beaucoup moins souvent elles semblent avoir été apprises...
