Loi de santé 2015 : fusionner les SI oui, mais par où commencer ?

Sur le plan strictement juridique (réglementation RH) il faut au moins 5 agents pour assurer les astreintes informatiques, et encore sans couvrir la période nocturne. Si l'on rajoute la plage horaire de nuit, il faut 8 à 9 agents, et encore ce chiffre est théorique puisqu'il suppose qu'aucun d'entre eux ne soit malade, en congé maternité, en formation ou que sais-je. La fusion des DSI a donc pour premier objectif de faire atteindre une masse critique à ces services. En dessous de 10 agents c'est cuit, et dans 3 à 5 ans ce chiffre passera certainement à 15.

Mais ensuite, lorsque l'on parle de fusion du SI, par où commencer ? L'expérience de Danielle Portal (Mulhouse) relatée lors des Salons Santé Autonomie 2015, démontre que sans fusion des processus métier pas ou peu de gain. Ok, mais dans ce cas la question devient : par quel processus métier commencer, à la fois pour la fusion de son SI puis du processus lui-même ?

Dans l'esprit, la loi de santé 2015 semble pousser vers une fusion des SI relatifs au cœur de métier : le soin. Selon nous, c'est clairement une mauvaise option. Si l'on regarde ce qui se passe dans le privé lorsque deux entreprises fusionnent, ce n'est certainement pas par le cœur de métier qu'elles commencent mais par les processus support et tout d'abord les DAF et les DRH. La raison est simple : d'une part il est beaucoup plus facile de fusionner les DRH (à la fois les services et les logiciels qu'elles utilisent) mais en sus il y a des gains économiques immédiats. Certes l'abandon d'un des deux logiciels RH au profit de l'autre a un coût (licence, déploiement, etc.) mais quand deux DRH de 100 agents chacune fusionnent, à l'arrivée il n'y aura pas besoin de 200 agents. Les premiers gains dans la fusion des processus concernent la masse salariale, et ne pas le dire revient à faire l'autruche.

Le même raisonnement peut être appliqué à la DSI. Le premier élément à fusionner entre deux DSI sont leur propres processus support : le réseau, l'hébergement technique, le système, etc. On finira par la couche applicative et par les équipes AMOA, ce n'est certainement pas par l'AMOA que l'on doit commencer.

En bref, la fusion est le sens de l'histoire, mais à condition de commencer par le bas : les processus support. Où, comme me le disait une de mes grands-mères, travail organisé est à moitié fait.