Pourquoi les projets d'automatisation échouent en soins à domicile (et comment y remédier)

La plupart des projets d'automatisation en soins à domicile n'échouent pas avec fracas. Ils échouent en silence. Le projet est approuvé. Le fournisseur bâtit quelque chose. Un courriel de lancement est envoyé. Pendant quelques semaines, le flux de travail fonctionne de la nouvelle façon. Puis un payeur change une règle, un code de service évolue, ou quelqu'un découvre le cas limite que personne n'avait signalé à la conception. Le flux de travail se brise. Personne ne sait comment le réparer. L'équipe revient au processus manuel. Trois mois plus tard, l'automatisation est morte, et la seule preuve qu'elle a existé est le poste budgétaire du trimestre précédent.

Si vous êtes dans les soins à domicile depuis assez longtemps, vous l'avez vu arriver. Peut-être plus d'une fois. Voici pourquoi cela arrive, et ce qui fonctionne vraiment.

Raison 1 : automatiser un processus défaillant

La façon la plus rapide de tuer un projet d'automatisation, c'est de sauter l'étape de refonte. La plupart des agences ont des flux de travail qui se sont développés au fil des ans, de façon organique. Des morceaux de ces flux sont ancrés dans la façon dont certaines personnes font leur travail. Le flux de travail n'est documenté nulle part ; il vit dans la tête des gens qui l'exécutent.

Quand vous automatisez ce flux de travail tel qu'il existe, vous encodez les mauvais côtés avec les bons. Les incohérences, les cas limites dont personne ne parle, les exceptions qui n'existent que parce que Sarah s'en souvient. L'automatisation exécute le flux de travail exactement comme avant, sauf qu'elle le fait maintenant plus vite, plus fort et en pilote automatique. Se tromper plus vite n'est pas mieux. Il fallait d'abord repenser le flux de travail. L'automatisation est le levier, pas la réponse.

Raison 2 : bâtie en vase clos, loin des opérations

Deuxième scénario le plus courant : un fournisseur ou une équipe interne bâtit l'automatisation en vase clos, puis la remet aux opérations. L'équipe des opérations la voit pour la première fois à la formation. Elle remarque tout de suite que l'outil ne tient pas compte de la façon dont elle travaille réellement, seulement de la façon dont quelqu'un l'a décrite.

Il y a cinq cas limites dont l'automatisation n'a pas tenu compte. Il y a deux règles que le payeur a ajoutées le mois dernier et que personne n'a intégrées au devis. Il y a un écran qui demande à l'utilisateur de faire une chose qu'il n'a jamais faite. L'adoption piétine. L'équipe contourne l'automatisation au lieu de travailler avec elle. Elle finit par cesser de l'utiliser. Une automatisation bâtie loin de l'équipe des opérations est une automatisation bâtie sur des suppositions. Et les suppositions ne survivent pas au contact de la réalité.

Raison 3 : aucun responsable après le lancement

La plupart des projets d'automatisation sont définis comme des projets. Il y a une phase de développement, une phase de lancement et une passation. Le fournisseur ou le consultant passe à autre chose. Trois semaines plus tard, quelque chose change. AlayaCare déploie une mise à jour. Un payeur change un code. Un champ est renommé. L'automatisation qui fonctionnait hier affiche une erreur aujourd'hui.

Plus aucun développeur n'est affecté au flux de travail. L'équipe des opérations n'a pas les compétences techniques pour le déboguer. Elle ouvre un billet. Le billet attend. En un mois, le flux de travail est jugé peu fiable. En un trimestre, il est contourné. Une automatisation en production n'est pas un projet. C'est un service. Un logiciel qui tourne sans surveillance dans un environnement de production a besoin de quelqu'un qui en est responsable après le courriel de lancement.

Raison 4 : corriger la mauvaise couche

Parfois, le diagnostic est erroné. L'agence remarque que les refus augmentent, alors elle automatise le flux de réponse aux refus. La réponse aux refus s'accélère. Mais les refus continuent d'augmenter. L'automatisation était dans la mauvaise couche. Les refus étaient causés par des problèmes en amont : une autorisation mal saisie, une vérification d'admissibilité qui n'a pas été faite, un code de service qui ne correspondait pas.

Automatiser la réponse, c'était agir en aval du vrai problème. Accélérer le travail à refaire ne règle pas la cause profonde ; cela rend seulement ce travail moins coûteux pendant que la cause continue d'en produire. On n'automatise pas la réponse aux refus pour régler un problème de refus. On corrige, en amont, le flux de travail qui produit les refus.

Raison 5 : un outil générique utilisé comme un outil sur mesure

Le marché des soins à domicile regorge d'outils de flux de travail génériques qui promettent l'automatisation. La plupart sont tout à fait compétents pour ce qu'ils sont censés faire. Ce pour quoi ils ne sont pas conçus, c'est la réalité précise d'une agence de soins à domicile sur AlayaCare, avec une composition de payeurs particulière, un ensemble particulier de règlements de l'État et un ensemble particulier d'intégrations avec la paie et la comptabilité.

Quand vous utilisez un outil générique pour modéliser un flux de travail précis, vous êtes satisfait le premier mois et vous vous battez contre l'outil pendant l'année qui suit. Les cas limites de vos opérations ne cadrent pas avec les gabarits de l'outil. Vous commencez à contourner l'outil. Le contournement devient le nouveau processus manuel, simplement sous une autre forme. Les outils génériques peuvent régler des problèmes génériques. Les flux de travail qui comptent le plus en soins à domicile ne sont pas génériques.

Ce qui fonctionne vraiment

• S'intégrer aux opérations : le développeur qui conçoit l'automatisation doit voir le flux de travail réel, pas la version documentée ; être déployé chez le client, c'est être dans la pièce à observer comment le travail se fait vraiment
• Repenser d'abord le flux de travail : décider de ce à quoi il devrait ressembler, pas seulement de ce à quoi il ressemble aujourd'hui ; éliminer les étapes qui n'existent qu'à cause d'outils hérités ; définir explicitement les exceptions ; puis automatiser
• Bâtir sur les systèmes que vous avez déjà : AlayaCare comme système de référence, votre paie et votre comptabilité existantes ; le but n'est pas d'ajouter une nouvelle plateforme, mais de faire fonctionner celles que vous payez déjà comme un environnement opérationnel unique
• Rester responsable après le lancement : le développeur qui a bâti le flux de travail en reste proche ; quand AlayaCare change, il met à jour l'intégration ; une automatisation en production est une relation, pas une livraison
• Mesurer ce qui compte : heures administratives économisées, refus évités, délai d'encaissement, vieillissement des comptes clients ; « nous avons livré l'automatisation » n'est pas l'indicateur de réussite ; le résultat opérationnel, si

C'est le modèle opérationnel que nous appliquons chez Daya Labs. Nous nous intégrons à votre équipe des opérations. Nous repensons le flux de travail avant de l'automatiser. Nous bâtissons par-dessus AlayaCare et les autres systèmes que vous utilisez déjà. Nous restons responsables du flux de travail après le lancement. Et nous nous mesurons au changement opérationnel, pas au plan de projet.

Si vous vous êtes déjà brûlé avec un projet d'automatisation, vous n'êtes pas seul. La plupart des agences avec qui nous travaillons ont au moins un cimetière d'automatisations dans leur histoire récente. La solution, ce n'est pas plus de fournisseurs ni plus de logiciels. C'est un modèle opérationnel différent autour du travail.