La voie de la modernisation de l’informatique passe par la rationalisation des applications

Elle occupe le poste de directrice de compte senior chez Quoris et possède plus d’une décennie d’expérience dans l’accompagnement des systèmes de santé lors de transitions technologiques complexes. Elle connaît parfaitement les environnements de dossiers médicaux électroniques (DME) ainsi que les dynamiques organisationnelles qui déterminent la réussite ou l’échec d’une initiative technologique. Chez Quoris, elle pilote les partenariats avec les clients, de la prise de contact initiale jusqu’à la mise en œuvre, en veillant à ce que le travail reste ancré dans les réalités opérationnelles et les priorités stratégiques de chaque organisation.
Kaitlin Traft a vu la conversation sur la modernisation se dérouler des deux côtés : les organisations qui la poursuivent et celles qui, discrètement, font d’abord le travail de rationalisation le plus difficile. Son argument est simple et va à l’encontre d’une grande partie de la pensée actuelle. Vous ne pouvez pas moderniser ce que vous n’avez pas rationalisé. Voici pourquoi cet ordre est important.
Une conversation est en cours dans le domaine de l’informatique de santé, et je pense que nous n’utilisons pas le bon mot.
Modernisation et rationalisation ne sont pas la même chose. Le secteur des soins de santé ne cesse d’utiliser le terme ”modernisation” alors que le vrai mot (le vrai besoin) est ”rationalisation”. La modernisation consiste à améliorer la technologie existante. La rationalisation consiste à décider ce qui doit être conservé ou supprimé.
Et cette distinction est plus importante que la plupart des gens ne le pensent.
Vous ne modernisez pas 400 applications. Vous examinez les 400 et vous décidez : peut-être que 300 restent, mais que 100 disparaissent. Car il y a parfois des doublons dans ces applications. Vous rationalisez le déclassement, vous vous débarrassez des choses dont vous n’avez plus besoin et vous modernisez ce qui reste.
Pensez-y de la manière la plus simple qui soit. Vous modernisez votre DSE pour y intégrer des outils d’IA. Mais vous n’avez pas nécessairement besoin de ces autres outils d’IA qui fonctionnent en parallèle, parce que vous modernisez le DSE lui-même. Vous vous débarrassez des outils dont vous n’avez pas besoin pour faire ce que vous voulez vraiment faire. L’objectif peut être la modernisation, mais vous devez d’abord regarder ce qu’il y a sous le capot.
C’est dans cette séquence (rationaliser, puis moderniser) que beaucoup d’organisations s’enlisent.
Les gens se disent qu’ils veulent se moderniser. Mais ils ne pensent pas toujours à ce qui se passe avant la modernisation. Et ceux qui avancent le plus vite en ce moment ne se contentent pas de mettre en œuvre une nouvelle technologie. Elles simplifient agressivement l’environnement sous-jacent afin de pouvoir aller de l’avant avec l’IA, ou Epic, ou quelle que soit la prochaine initiative. Ils font les deux et comprennent l’ordre.
Il s’agit d’un problème de main-d’œuvre, pas seulement d’un problème de technologie
Je pense que l’on ne le dit pas assez : la rationalisation des applications est une stratégie de main-d’œuvre.
Les équipes informatiques du secteur de la santé sont généralement épuisées parce qu’elles gèrent ou prennent en charge un trop grand nombre de systèmes. Vous ne pouvez pas résoudre ce type d’épuisement en demandant aux gens de maintenir 15 ans de dette technique que l’organisation a absorbée au fil du temps et qu’elle ne peut plus expliquer. Au fil du temps, les raisons sont de plus en plus difficiles à retracer. Les systèmes sont absorbés, les contrats sont renouvelés en mode automatique et il devient difficile d’avoir une vue d’ensemble de l’intérieur.
Et c’est là le problème : pour rationaliser les applications, il faut d’abord aligner les gens à travers l’organisation. Vous devez réunir tout le monde dans la salle et dire : ” D’accord, ça ne marche pas. Où pouvons-nous nous concentrer ? À quoi ressemble notre pile technologique complète ? Ce n’est qu’ensuite que vous pourrez examiner les applications et commencer à prendre de vraies décisions.
Ce processus commence par un inventaire, et j’entends par là un véritable inventaire. Oui, il y a une feuille de calcul. Mais surtout, vous vous asseyez avec les parties prenantes de l’ensemble de l’organisation : les équipes chargées des applications commerciales, les RH, les responsables cliniques, tous ceux qui ont un droit de regard sur ce que leur service utilise et sur les raisons de cette utilisation. Vous les interrogez. Vous leur demandez ce qu’ils utilisent, comment ils l’utilisent et ce qui se passerait si cela disparaissait. C’est là que vous trouvez la duplicité. Prenez quelque chose de simple, comme une application de scribe d’IA. Une équipe utilise Abridge, une autre Nuance. D’un point de vue fonctionnel, elles font la même chose. Alors, laquelle est la meilleure ? Quel est le coût ? Quand la licence expire-t-elle ? Vous examinez tout cela, puis la question devient :quels sont ceux que nous retirons, et pourquoi ?
Le coût réel n’est jamais uniquement celui de la licence
Une chose que j’entends constamment, c’est que les organisations utilisent le coût des licences comme principal critère de décision en matière de retraite. Je comprends, c’est le chiffre qui apparaît sur la facture. Mais le coût des licences est presque toujours la plus petite partie du problème.
Le coût réel est celui de l’infrastructure sur laquelle repose la licence. Il s’agit des interfaces, des mises à jour, des analystes, des tickets d’assistance, des frais généraux de gouvernance, du risque de temps d’arrêt. Il y a tellement de couches au-delà de cet élément d’une ligne. Et la plupart des organisations le sous-estiment massivement.
Il y a quelques autres questions auxquelles je pense lorsque nous établissons les priorités en matière de retraite. Votre DSE fait-il déjà cela ? Si vous êtes une organisation axée sur le DSE, c’est souvent le premier filtre. Si votre DSE peut reproduire le flux de travail, vous centralisez les données et les intégrez. La question n’est plus de savoir s’il faut conserver cette application, mais plutôt de savoir pourquoi nous payons pour quelque chose que notre DSE peut déjà faire.
Il y a ensuite l’aspect du flux de travail clinique. Si un clinicien doit quitter le DSE, se connecter à quelque chose d’autre, faire quelque chose et revenir… c’est une déconnexion. C’est une friction au chevet du patient. Une infirmière qui s’occupe de 15 patients n’a pas le temps d’entrer et de sortir des systèmes pour obtenir ce dont elle a besoin. L’application simplifie-t-elle leur flux de travail ou l’interrompt-elle ? Cette réponse est importante.
Et puis il y a la question de l’avenir : cette application accélère-t-elle l’adoption de l’IA ou la bloque-t-elle ? Car si les données sont cloisonnées, si les résultats sont incohérents, si l’application ne peut pas se connecter à l’évolution de l’organisation, elle ne vaut pas la peine d’être maintenue. Débarrassez-vous-en.
La question que je pose toujours
La question la plus importante dans toute conversation de rationalisation n’est pas ”devons-nous garder ceci ?”. C’est : que se passera-t-il si nous ne le mettons pas à la retraite ?
Parce que ne rien faire est la partie la plus coûteuse. Si vous ne vous en occupez pas, vous pouvez avoir une application qui fonctionne depuis des années (c’est-à-dire que vous continuez à la payer, à la doter en personnel, à la gérer) sans que personne ne sache exactement ce qu’elle fait ou si elle en valait la peine. C’est de la dette technique qui s’accumule tranquillement. C’est une charge opérationnelle que personne n’a budgétisée. Ce sont des flux de travail fragmentés que personne n’a conçus.
La rationalisation des applications n’est plus une initiative de nettoyage informatique. C’est une condition préalable à l’efficacité opérationnelle, à la préparation à l’IA, à toute stratégie de DSE à long terme que vous essayez de mettre en œuvre. Les organisations qui y parviennent ne la considèrent pas comme un projet secondaire. Elles en font le fondement.
Vous ne pouvez pas construire sur un portefeuille gonflé. Vous devez savoir ce que vous avez avant de décider ce que vous allez devenir.
Share this