La "Note méthodologique sur les pièces justificatives", version 1.0 du 30 juin dernier, indique pour le D5.2 que "Un tableau Excel ne peut être alimenté des données de production (D5.1) et ne sera pas accepté."Quel est le sens de cette phrase ?Il semble a priori naturel d'exporter dans un tableur les différents type de données extraites des bases concernées (activité, RH, qualité, ...) et de les réunir dans un outil facile d'accès et d'utilisation pour n'importe quel manager, au besoin par un copier-coller des tableaux.En effet, les données provenant de différentes sources, certains ES mettent en oeuvre des solutions dépendantes des éditeurs pour extraire les informations pertinentes et bâtir directement leurs indicateurs de pilotage, sans passer par un info-centre. Il n'est donc pas simple de produire un tableau de bord totalement unifié, sauf à utiliser un outil spécifique de plus, ce qui implique des coûts supplémentaires.­

La mise en place d'une feuille de calcul (excel ou autre…) alimentée par des copiés-collés est un moyen intéressant de consolidation des données. Elle permet certainement d'approcher les besoins en pilotage médico-économiques avec une souplesse intéressante.

Mais le caractère artisanal de cette méthode génère régulièrement des erreurs parfois massives ou non dépistées. Dans l'idéal, cela nécessite des procédures de contrôles qui peuvent s'avérer fastidieuses et consommatrices de ressources.

C'est pourquoi une évolution vers une solution industrielle est souvent bénéfique.

Le surcout éventuel (mais il ne faut pas imaginer qu'une solution manuelle bien contrôlée ne consomme aucune ressource) justifie la subvention du programme HN.­

J'ajoute un argumentaire, issu de l'excellente étude du GMSIH "Gérer un projet désionnel" (Livrable "­Convaincre un conseil exécutif du bien fondé d'un projet de SID­", page 26, pour être précis) :

­Des solutions type analyse dans un tableur ou recherche manuelle dans des bases de données présentent des ­difficultés fonctionnelles­

• Définition des indicateurs hétérogène dans les différents domaines, donc pas de partage des résultats et remise en cause toujours possible­
• Pas de gestion d’un historique, notamment pas d’historisation des évolutions de périmètre (ex : changement du fichier de structure) ne sont pas conservées­
• Temps d’analyse de données élevés dû à la masse importante d’information et des divergences dans les chiffres­
• Toutes les personnes ayant besoin de l’information ne sont pas forcément capables de réaliser les requêtes nécessaires pour travailler­
• Pas de fonctionnalités avancées type simulation ou projection possible de manière standard, tout est à créer­

­Et ­techniques­

• Incapacité à assumer un nombre croissant d’utilisateurs et d’utilisations (notamment risque sur l’utilisation trop importante des outils de production pour leur performance)­
• Données disséminées dans des sources très différentes : fichiers, bases hétérogènes, serveurs différents, donc pas forcément toujours la capacité à récupérer ces informations­
• Pas de moyen de tracer la qualité des données­

Je précise qu'il n'y a pas d'intervention humaine ou manuelle dans la production.



Le processus de création du tableau de bord est le suivant :

- Export automatique des données des indicateurs par chaque appli dans leur propre format.

- Traitement automatique des données par un programme développé en interne qui réintègre et met en forme toutes les informations dans un document Excel unique consultable ou modifiable selon les personnes autorisées à y accéder.



Donc aucune intervention humaine en dehors du lancement des traitements automatiques des applications métiers puis du logiciel de retraitement et la mise à disposition du tableau de bord unique final.



Du coup, je m'interroge : Acheter un outil complet pour ces seules opérations : n'est-ce pas quelque peu sur-dimensionné ?­

Christian,



Dans l'architecture que vous décrivez, Microsoft Excel ne sert, d'après ce que je comprends, que de logiciel de présentation. Si je comprends bien, on a donc :

- Un export des données par les applications (équivalent à la fonction extract d'un ­ETL­)

- Un programme interne qui transforme les données (équivalent à la fonction transform d'un ETL)

- Un import dans un logiciel de présentation (équivalent à la fonction load d'un ETL)

- Un logiciel de présentation, en l'espèce Microsfoft Excel (équivalent à la fonction de présentation d'un SID)



Du point de vue de la conformité aux indicateurs HN, ça mérite discussion, dans la mesure où les différents traitements sont automatisés -> c'est une discussion de fond à avoir avec l'ARS (Anne-Briac, es-tu là ?).



Sur le fond, le cas que vous remontez est intéressant à creuser :

- De quel type d'établissement s'agit-il ? MCO ? SSR ? Psy ? Quelle taille (en lits et place, par exemple) ?

- Comment rapproche-il les données d'activité et les données RH, par exemple ? Les données financières (ex. recettes d'activité) et les données d'activité ?

- Quelle forme a le "logiciel de retraitement" : un script VBA intégré dans un classeur Excel ? Une application autonome ?

- Comment maintent-il les ­référentiels­ (ex. FICOM...) ? Les indicateurs ? Et, par voie de conséquence, l'application de traitement ?



Cela pose aussi la question de l'­offre progicielle­ pour les petits établissements non MCO, mais ce point mérite un autre fil de discussion.­

Bonjour,



n'hésitez pas à consulter l­a partie dédiée à l'indicateur D5.2 ­de la publication des experts HN.



Découvrez la publication ­"Produire efficacement les indicateurs d'usage HN" ici­ !



L'équipe ANAP­

J'ai déjà pu participer dans la mise en place de nombreux projets de tableaux de bord et Excel est effectivement une solution de départ mais cela va très vite poser des problèmes de :



- Maintenance (évolution des versions de produit)

- Sécurité des accès et données (confidentialité des accès et traçabilité de la consultation et de la saisie des données ...)

- Personnalisation des informations (un tableau de bord unique avec une multitude de données ne sera pas percutant et par ailleurs chaque utilisateur n'aura pas besoin les mêmes informations et la même profondeur au niveau des données. Ex : un chef de service serait plus intéressé par des données agrégées tandis qu'un administratif serait plus intéressé par le détail ..) -> travail manuel !

- Intégration et croisement d'une multitude de flux de données des établissements (ça devient technique voir ingérable dans Excel).

- Degré d'appropriation de l'outil par les utilisateurs (qui va pouvoir faire les modifications ? Informatique ? Prestataire ... ?)

- ...



Il existe des solutions standards sur le marché capable d'offrir la simplicité d'un Excel mais tout en sécurisant l'aspect technique afin que les données produites soient fiables !



Dans la notion de coût, il faudrait effectivement intégrer le coût de ce type de produit et du montant d'intégration. Mais il faudrait également prendre en compte dans le TCO, le coût humain (temps dédié pour réaliser et pour contrôler les chiffres), les anticipations et les alertes remontées par la solution ...­

J'ai consulté avec intérêt votre discussion et le livrable sur le projet de système d'information décisionnel. Je travaille comme référent qualité avec une plateforme internet sécurisé qui recense des items de pratiques jusqu'aux actions d'amélioration dans un EHPAD. Basé sur les référentiels ANAP, ANESM, HAS, cela permet un pilotage, une économie sur les actes chronophages, et des actions d'amélioration plus adaptées. Actuellement dans différents établissements, les outils utilisés couramment dans les établissements consistent à utiliser des fichiers excel ou word partagés à l’intérieur de très nombreux dossiers imbriqués. Pardonnez moi de ce post décalé, mais c'est le sujet qui se rapproche le plus de mes réflexions.­