Phase : Lancer Etape : Cadrage du projet

Présentation au sujet: "Phase : Lancer Etape : Cadrage du projet"— Transcription de la présentation:

1 Phase : Lancer Etape : Cadrage du projet
Lancer, mettre en œuvre, animer un projet de SI décisionnel au sein d’un établissement de santé Phase : Lancer Etape : Cadrage du projet AT4 : Périmètre et trajectoire du SID Version 1.0 05/07/07

2 AT4 : Périmètre et trajectoire du SID
Définir la cible, choisir le contenu fonctionnel des lots, identifier les outils et le socle technique, et formaliser la trajectoire vers la cible

3 Mode d’emploi et points d’attention
Ce document contient des commentaires qui viennent compléter et étoffer les textes des diapositives La lecture de ces derniers est permise par la fonction Affichage\Page de Commentaires ou le mode d’affichage « Normal » Il est donc conseillé de l’imprimer avec les commentaires.

4 Lotir le projet en phase de cadrage
Lors de la phase de cadrage, on définit un périmètre pour le projet (cible technique et fonctionnelle) et une trajectoire pour couvrir progressivement ce périmètre. Lotir le projet consiste à définir cette trajectoire en découpant le périmètre en ensembles cohérents fonctionnellement et techniquement, qui seront réalisés et déployés les uns après les autres, suivant un calendrier précis. On décrira donc ci-après une proposition pour : Définir le périmètre fonctionnel cible du projet Choisir la solution technique et les outils qui la composent en fonction de la cible retenue Etablir les lots du projet et définir une trajectoire pour l’ensemble du projet Le lotissement est l’aboutissement de cette double démarche de description du besoin fonctionnel (dans quelle direction aller, comment s’assurer que l’on reste sur la même trajectoire) impliquant la description des indicateurs et fonctionnalités décisionnelles souhaitées ou attendues, et de la capacité (technique, financière, humaine) de l’établissement à se lancer dans un projet de SI décisionnel. Le lotissement est donc indissociable des autres activités de l’étape de cadrage, la définition du besoin fonctionnel et le choix de l’outil, c’est pourquoi cette annexe technique aborde ces trois aspects.

5 Travaux à mener Définir et hiérarchiser le périmètre fonctionnel cible du projet Choisir la solution technique et les outils qui la composent en fonction de la cible retenue Etablir les lots du projet et définir une trajectoire pour l’ensemble du projet

6 Définir le périmètre fonctionnel cible du projet
Prioriser les attentes sachant que le SID ne les couvrira pas toutes, sur 2 axes Fixer l’ensemble des attentes Quels indicateurs? Quelles fonctionnalités? Quels utilisateurs du SID? Cohérence avec les orientations stratégiques de l’établissement Accessibilité des données Résultat Périmètre global des attentes

7 1. Fixer l’ensemble des attentes
Consulter les principaux responsables des pôles, directions et services utilisateurs du SID afin de recueillir leurs besoins : Indicateurs, classés par domaine d’information, avec éventuellement une indication de leur importance aux yeux du responsable en question, identification des axes d’analyse habituels Besoins exprimés « bruts » par domaine d’information Domaine d’information + Importance de l’indicateur pour son utilisateur - PMSI RH Compta Activité Patients Achats … L’étape de cadrage peut entraîner, selon la démarche de performance existant dans l’établissement, une expression de besoin plus ou moins riche, appuyée sur un existant qui peut s’avérer important, constitué de tableaux de bord et d’indicateurs sélectionnés, tirés des applications métier. Toutefois, on veillera à ce que les besoins exprimés en étape de cadrage découlent d’une vraie réflexion sur la performance et ses leviers et ne soient pas un simple récapitulatif des indicateurs déjà existants. On établit la liste des fonctionnalités nécessaires en fonction du service attendu par chaque type d’utilisateur : tableaux de bord, rapports, requêtes ad-hoc, analyses plus ou moins poussées,… On identifie les utilisateurs cibles. Fonctionnalités attendues : tableaux pré-formatés, requêtes ad hoc, fonctionnalités avancées… Utilisateurs cibles, classés par typologie.

8 2. Prioriser les attentes
Hiérarchiser les attentes en se fondant sur deux critères principaux : La cohérence avec les orientations stratégiques de l’ES: Elles peuvent rendre nécessaires de suivre plus particulièrement certains indicateurs, qui doivent être outillés prioritairement. En responsabilisant certains acteurs, elles font d’eux des utilisateurs privilégiés du SID L’accessibilité des données : Evaluer le niveau de complexité (calcul, mono ou multi-source) et de faisabilité (composants accessibles dans les applications sources) des indicateurs attendus, ainsi que la qualité générale des données Besoins exprimés « bruts » par domaine d’information Domaine + Importance de l’indicateur - PMSI RH Compta Activité Patients Achats … Besoins exprimés « bruts » Ce besoin macroscopique sera ensuite examiné à la lumière de deux critères : l’accessibilité des données et la cohérence avec les orientations stratégiques. 1- Identification et hiérarchisation des orientations stratégiques, des utilisateurs cibles et des fonctionnalités attendues. Il est nécessaire de mener cette démarche de hiérarchisation des besoins pour identifier ce qui, pour l’établissement et aux yeux des futurs utilisateurs, est primordial, de ce qui revêt une moindre importance. Par exemple, le directeur de l’établissement peut avoir priorisé les orientations stratégiques de l’établissement, mais vouloir suivre particulièrement un indicateur précis. Il paraît légitime dans ce cas d’attribuer un poids plus important à ce besoin précis. 2- Accessibilité des données Il est particulièrement conseillé, dans le cadre d’un projet de SI décisionnel d’examiner de près les applications source des données utilisées par les indicateurs. C’est pourquoi il est nécessaire de comprendre comment sont construits ces indicateurs que l’on souhaite outiller, et les applications dans lesquelles on trouvera les données qui les constituent. En effet l’accessibilité des données dans les applications sources est un critère important de sélection et de dimensionnement du périmètre puis des lots (les difficultés pour obtenir les données impactant sérieusement le budget). De cette hiérarchie, combinée à l’accessibilité des données, on tirera un périmètre du SID. La taille du périmètre est bien évidemment au choix de l’établissement. Il peut simplement être conseillé de modérer le périmètre pour rendre le projet plus facile à gérer (moins d’indicateurs, moins de domaines métiers et moins d’utilisateurs réduisent la complexité du projet). Attention, la définition de son périmètre est un moment fort du projet : tout ce qui sort du périmètre ne sera pas traité, sinon dans le cadre d’un autre projet. Les choix de renoncer à certains indicateurs et à certaines fonctionnalités sont souvent douloureux; ils sont facilités par le travail de hiérarchisation des besoins effectués préalablement. Orientations stratégiques - ++++ +++ + + + ++ +++++ + + + + + + + + + + + + + + + Hiérarchisation des besoins exprimés sur les axes orientations stratégiques et accessibilité des données + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Accessibilité des données - Périmètre global exprimé du projet de SID

9 Travaux à mener Définir et hiérarchiser le périmètre fonctionnel cible du projet Choisir la solution technique et les outils qui la composent en fonction de la cible retenue Etablir les lots du projet et définir une trajectoire pour l’ensemble du projet

10 Choisir la solution et les outils en fonction de la cible retenue
1. Trois groupes de solutions 2. Les critères de choix  SID multi-sources avec données intégrées Des indicateurs très variés sur des sources métier croisées Intégration des données inter-applicatives Périmètre fonctionnel à couvrir Maturité de gestion Budget Evolutivité  Infocentre spécifique par applicatif métier Des indicateurs très variés sur la source métier concernée Définition des indicateurs, des tableaux de bord et modélisation Le marché des outils décisionnels est large, c’est pourquoi nous proposons de le segmenter en trois grands sous-ensembles. Chaque sous-ensemble correspond à un type de solution du marché : Solution fondée sur un outil pré-packagé. Il s’agit de solutions « clé en mains » proposées par des éditeurs, dédiées au domaine de la santé, et comprenant un choix de tableaux de bord, un ensemble d’indicateurs pré-formatés, et des fonctionnalités diverses (attention, ces fonctionnalités comme le périmètre d’analyse qu’elles recouvrent, peuvent être très variables d’un éditeur à l’autre). Ces solutions sont déjà modélisées selon une logique choisie par l’éditeur, il reste à les paramétrer et à les « brancher » sur le SIH. Solution qui s’appuie sur les outils décisionnels classiques (extraction, stockage, restitution) du marché, mais dont le périmètre est limité à une application métier ciblée. Cette solution est le résultat d’une approche verticale d’un établissement, qui s’intéresse à ses domaines métier indépendamment les uns des autres (s’il existe plusieurs infocentres, les données qu’ils contiennent sont issues d’applications sources différentes et non intégrées, et ne peuvent donc pas être comparées). Certains éditeurs, souvent spécialisés dans les domaines support (RH, finance, etc.), plus rarement dans le secteur santé, peuvent proposer des infocentres déjà assemblés. Attention, des infocentres non modélisés (la base de données est une copie historisée de la base de production) peuvent exister dans l’établissement : ils demandent une pratique avancée des outils de restitution. Solution décisionnelle intégrée : elle s’appuie sur les outils décisionnels classiques (extraction, stockage, restitution) du marché et une modélisation décisionnelle, qui implique une intégration des données issues de sources distinctes, et implique donc également l’existence ou la création d’un référentiel commun aux applications concernées. Vous trouverez dans la page suivante une présentation des avantages et inconvénients de chacune des solutions.  Outil pré-packagé Par applicatif métier Des indicateurs « classiques » Alimentation application par application Résultat Choix d’une solution cible pour couvrir le périmètre du projet

11 Solution 1 : Architecture des outils pré-packagés
La couverture fonctionnelle est variable, mais contrainte (liste d’indicateurs et restitutions limitées). Architecture technique semblable à la solution d’infocentre par applicatif métier. L’éditeur est propriétaire du modèle, il peut choisir de donner accès aux informations ou pas. Chaque applicatif a son propre référentiel. Les offres pré-packagées présentent l’avantage d’être définies pour les établissements de santé, et d’être relativement faciles à installer (une partie du travail d’interfaçage a déjà été réalisée, et aucun investissement n’est nécessaire pour définir finement le besoin, limité par les listes d’indicateurs proposés en standard). La complexité de mise en œuvre augmente si les utilisateurs réclament des fonctionnalités ou des restitutions qui ne sont pas présentes dans l’outil proposé par l’éditeur, car leur développement devra ensuite se faire en bonne intelligence avec ce dernier. Le niveau de difficulté dans l’intégration dépend du nombre d’applicatifs concernés par la solution, et varie donc d’un éditeur à l’autre, en fonction du périmètre adressé par chaque solution. Par exemple, le cas le plus simple est une solution qui s’appuie sur PMSI seul (c’est une application standard, commune à tous les établissements). Les applications de production sont dupliquées dans des infocentres métiers par applicatif, Le modèle de données est au « format » SID ou non (cela dépend des éditeurs), c’est-à-dire que le modèle de données peut contenir des axes d’analyse, s’appuyer sur des référentiels communs entre les applicatifs concernés par la solution ou propre à chaque applicatif. La situation est variable d’un éditeur à l’autre L’éditeur est propriétaire du modèle de données L’éditeur propose un certain nombre de fonctionnalités, accessibles potentiellement à travers un portail L’accès à une analyse multidimensionnelle dépend de la modélisation, elle n’est pas garantie Le périmètre (indicateurs, restitutions, fonctionnalités) est figé Flexibilité faible : Le défaut majeur de ces offres réside dans leur faible flexibilité induite par la protection de son modèle de données par l’éditeur. En effet, comme l’ensemble des restitutions est prédéfini, toute demande d’évolution nécessite un développement, nécessairement réalisé par l’éditeur, à un certain coût et dans un certain délai. De même, si la solution ne couvre pas la totalité des applications du SIH, il sera parfois très difficile d’y faire inclure une application supplémentaire.  Attention : la présence d’indicateurs diversifiés dans un même portail quand celui-ci n’est qu’un portail de publication, ne signifie pas que les données sont intégrées, analysables selon les mêmes axes d’analyse et que l’on peut effectuer des analyses croisées de ces données.

12 Solution 2 : Architecture des infocentres spécifiques par applicatif métier
Les données sont regroupées dans des infocentres (un par applicatif métier couvert) ayant chacun son propre référentiel. Au sein des infocentres, les données sont modélisées ou non. Le modèle de données est maîtrisé par l’établissement. Il peut donc : Enrichir le reporting (nouveaux indicateurs, nouvelles restitutions) dans le cadre des infocentres existants Ajouter de nouveaux infocentres liés à de nouvelles applications source Les outils de restitution utilisés sont des outils classiques de SID. La différence entre cette solution et la solution 3 (SID intégré) tient en l’absence d’une modélisation décisionnelle unique et de référentiels communs. Les applications de production sont dupliquées dans des infocentres métiers par applicatif, Le modèle de données est au « format » SID ou non (cela dépend du choix de l’établissement), sans modélisation, l’infocentre est alors une copie de la base de production de l’applicatif métier. Le modèle de données est propriété de l’établissement ou, dans le cas d’infocentres métiers particuliers (RH, Finance..), d’un éditeur, Avantages et inconvénients de modéliser les infocentres métier : Avantages : la richesse fonctionnelle (possibilité de requêtes ad hoc notamment) et l’évolutivité des restitutions (création de nouveaux tableaux de bord dans le périmètre de l’infocentre) est plus forte. En effet, si l’infocentre n’est pas modélisé, l’organisation des données pour obtenir des indicateurs doit se faire dans les outils de restitution, ce qui dégrade leurs performance et alourdit toute évolution en vie courante. Inconvénients : La modélisation des données de l’infocentre implique des choix qui seront peut être incompatibles avec l’intégration des données dans le cadre de l’évolution vers un SID intégré (solution 3). La richesse fonctionnelle peut être important, et des analyses multidimensionnelles possibles (si la modélisation le permet, et uniquement dans le périmètre métier de l’infocentre) Flexibilité variable : Cette architecture, intrinsèquement flexible car l’établissement possède le modèle de données, nécessite tout de même de prendre quelques précautions pour que l’évolution vers la cible SID (au sens strict, permettant une analyse multidimensionnelle sur des indicateurs construits à partir de plusieurs applicatifs) se passe sans heurt : Si l’on modélise les données des infocentres, s’efforcer de rendre la modélisation compatible avec ce que pourrait être le modèle de données global de l’ES dans l’optique d’un SID intégré (solution 3) Mener un projet de référentiel commun soit à l’établissement, soit limité aux premiers applicatifs métier du périmètre Cette architecture mettra en évidence, applicatif par applicatif, les problèmes de qualité des données utilisées, et permettra par ce biais de mener un projet d’amélioration de la qualité des données en parallèle du projet de SID.

13 Solution 3 : Architecture d’un SID (DataWarehouse)
Le SID intègre dans un seul entrepôt les données issues de plusieurs applications Un modèle de données unique (tables de faits et axes d’analyses) Pour chaque domaine (structure, patient…) un référentiel unique dans le SID Les outils de restitution utilisés sont des outils classiques de SID. Cette solution ne nécessite pas forcément un périmètre large, mais elle permet d’obtenir immédiatement des analyses de grande qualité. Les données des applications de production sont chargées après traitement dans un datawarehouse Le modèle de données est au « format » SID, L’établissement est propriétaire du modèle, Toutes les fonctionnalités choisies/souhaitées par l’établissement sont accessibles à travers un portail. L’accès à une analyse dimensionnelle et à des analyses croisées est rendu possible par l’unicité du modèle de données et les axes d’analyse communs Ce type de solution présente une grande flexibilité : Le périmètre (indicateurs, restitutions, fonctionnalités) est modulable indéfiniment : Selon la maturité de l’établissement en gestion et en management de projets de SI, on pourra partir sur une base modeste ; peu d’indicateurs, peu d’applications sources. Le périmètre du projet initial peut être limité volontairement, car la complexité des choix de référentiels communs et la potentiellement faible accessibilité des données dans les applicatifs nécessitent de se donner le temps de régler ces problèmes avec des utilisateurs peu nombreux. Un nouveau projet peut être lancé dans la continuité du projet sans perturbation particulière, et en enrichissant le socle initial (par des indicateur, des fonctionnalités, des outils métier sources)

14 Choix des outils : analyse technique comparée
Aspects techniques Avantages Inconvénients Forte évolutivité Le projet peut concerner qu’un périmètre très restreint; on pourra toujours mener un nouveau projet pour compléter ce périmètre La conception d’un modèle multidimensionnel sur des sources croisées donne accès à des restitutions relativement faciles à enrichir par la définition d’indicateurs complémentaires La complexité du projet est accrue si les référentiels sont hétérogènes Risque d’effet tunnel car l’intégration des données est obligatoire Budget élevé (investissement disproportionné si le périmètre du projet est trop restreint) Facilité relative de mise en œuvre Mise en place ‘rapide’, effet tunnel limité Permet d’améliorer la qualité des données Budget modéré Difficulté à créer des rapports différents de ceux prédéfinis si l’infocentre n’est pas modélisé  Flexibilité variable, le passage à un décisionnel intégré est possible, mais coûteux (temps, €) Facilité de mise en œuvre Mise en place ‘rapide’, faible effet tunnel Budget limité Difficulté à créer des rapports différents de ceux prédéfinis (nouveaux développements – coût+délai) Risque de statu quo (voie ‘sans issue’ SID)  Flexibilité très réduite Attention, pour certains produits pré-packagés, la récupération des données sources reste une problématique complexe  SID multi-sources avec données intégrées Des indicateurs très variés sur des sources métier croisées Intégration des données inter-applicatives  Infocentre spécifique par applicatif métier Des indicateurs très variés sur la source métier concernée Définition des indicateurs, des tableaux de bord et modélisation De l’analyse technique des différents types de solutions, on tirera l’enseignement suivant : plus la solution est riche fonctionnellement, plus les efforts à faire pour la mettre en œuvre dans de bonnes conditions sont importants, mais plus elle est évolutive et à même de répondre à l’évolution des besoins des établissements. Les difficultés techniques potentielles sont issues de : L’intégration des données, qui nécessite l’utilisation ou la création de référentiels communs (référentiels maîtres dans le SID, avec des règles de transcodification pour les données en provenance des applications sources utilisant d’autres référentiels) L’élaboration des interfaces avec les applications sources, dépendante de l’accessibilité des données dans ces applications Choisir une solution pré-packagée n’exonère pas de travailler sur l’intégration des données. Les points d’attention communs sont : l’initialisation du SID la reprise des données d’historique la qualité des données des applications sources Note : pour certains produits paré-packagés, la complexité de récupération des données sources n’est pas diminuée par rapport aux autres solutions.  Outil pré-packagé Par applicatif métier Des indicateurs « classiques » Alimentation application par application

15 Choix des outils : analyse fonctionnelle comparée
Aspects fonctionnels Avantages Inconvénients Réponse aux besoins métier ‘multi-applications’ élaborés par des analyses multidimensionnelles sur des données croisées Expression des besoins large, sur toute l’activité de l’ES Lourdeur de mise en œuvre, difficulté d’obtention d’un consensus Conduite de changement et gestion de projet importante Réponse élaborée aux besoins métier ‘mono-application’ Présentation de données hétérogènes dans un même tableau Au sein d’un domaine métier donné, possibilité d’accéder à la même richesse fonctionnelle que le SID Impossibilité de croiser des données issues de sources différentes bien qu’elles soient présentes dans le même tableau Difficulté de créer des rapports nouveaux si l’infocentre n’est pas modélisé Réponse standard aux besoins métier ‘mono-application’ Permet d’acquérir une culture de gestion Impossibilité de croiser des données présentes dans le même tableau mais issues de sources différentes Difficulté à créer des rapports différents de ceux prédéfinis (nécessite des développements qui impliquent des coûts et des délais) L’accès à des fonctionnalités supplémentaires (requêtes, rapports, simulations) n’est pas garanti ou pas possible  SID multi-sources avec données intégrées Des indicateurs très variés sur des sources métier croisées Intégration des données inter-applicatives  Infocentre spécifique par applicatif métier Des indicateurs très variés sur la source métier concernée Définition des indicateurs, des tableaux de bord et modélisation L’analyse des différents types de solution a pour objectif de bien mettre en évidence les avantages et les limites ou inconvénients de chacune. Il ne s’agit pas de présenter l’une comme étant meilleure que l’autre, mais de donner des clés d’analyse avant de choisir l’une ou l’autre. L’avantage majeur, commun à l’ensemble de ces solutions, est de permettre de faire évoluer la culture de gestion de l’établissement, car c’est l’instauration et l’animation du dialogue de gestion qui pourront servir de moteur à l’évolution et à la maturation du besoin de suivi et d’analyse. Les inconvénients fonctionnels majeurs mis en évidence portent sur la difficulté de mise en œuvre attenante aux solutions les plus complexes, et sur les possibilités d’analyse croisées et poussées que permettent ces solutions. Il est nécessaire de comprendre ici que, si le besoin pour les 3 à 5 prochaines années se résume à des analyses au sein des métiers, et si l’établissement est encore en cours de première élaboration d’un dialogue de gestion, alors la mise en œuvre d’un SID de type 3 n’est ni nécessaire ni réaliste. Le choix d’investir en 2 temps (partir sur première une solution « jetable » pour mûrir la culture de gestion, et passer, dans un projet suivant, à une solution plus complète fonctionnellement) pourra parfaitement être défendu, notamment au regard de l’investissement consenti. A noter cependant : passer d’un type de solution à l’autre entraîne un changement d’ergonomie et de manipulation des outils qui nécessite un accompagnement particulier des utilisateurs  Outil pré-packagé Par applicatif métier Des indicateurs « classiques » Alimentation application par application

16 Prendre en compte les besoins d’évolutivité
Un SID, quel que soit le type de solution déployé, favorise l’émergence de besoins nouveaux, qui se traduisent par des demandes d’évolution. Il est alors nécessaire d’évaluer la capacité du SID à couvrir ces demandes. Si ce n’est pas le cas, identifier le type de solution sur lequel investir pour répondre à ces nouveaux besoins. Quelles sont les options ? Abandonner l’existant, et repartir sur un nouveau socle technique et fonctionnel Faire évoluer la base technique vers une solution de type SID Lancer un lot supplémentaire sur la même base technique et fonctionnelle Tenir compte de ces possibilités d’évolution, c’est inscrire le projet dans une trajectoire vers une cible : le SID tel que décrit en solution 3.

17 Infocentre métier modélisé Décision de créer un nouveau SID
En fonction du périmètre fonctionnel global, avoir en tête la solution cible attendue Solution 3 DataWarehouse Couverture du périmètre Fonctionnalités Indicateurs (fonction de la qualité des donnés sources) Utilisateurs Intégration possible sous réserves de certaines précautions (axes d’analyse, référentiels,..) Solution 2 Infocentre métier modélisé On peut considérer qu’il existe une cible à long terme commune à tous les établissements : c’est le SID décrit en solution 3, qui permet de mener des analyses croisées et multidimensionnelles, parce qu’il utilise des données issues de sources diverses, intégrées grâce à la définition de référentiels communs. Cette cible à long terme peut être atteinte dès le premier projet ou après une succession de projets. On distingue d’une part l’identification des trajectoires vers la cible et le temps nécessaire pour obtenir des résultats avec chacune des solutions, et d’autre part la mise en évidence des difficultés de passage d’une solution à l’autre. Ce schéma illustre les possibles évolutions vers cette cible à long terme : directe (adoption de la solution 3 dès le premier projet), en passant lors du premier projet par un ou des infocentres métier (solution 2), ou en commençant par un premier projet fondé sur une solution pré-packagée (solution 1). L’axe temps illustre la rapidité de mise en place de ces solutions les unes par rapport aux autres, sans tenir compte de l’existant (qualité des données sources, accessibilité des données, définition de référentiels communs). Il illustre les difficultés que l’on peut rencontrer lors du passage d’une étape à une autre, à cause de l’éventuelle absence d’évolutivité des solutions envisagées. Le choix initial de la solution 1 est potentiellement le plus contraint, car l’éditeur n’aura pas forcément laissé de libertés aux utilisateurs pour créer des tableaux de bords ou générer de nouveaux indicateurs. De même, l’ajout d’un domaine métier situé hors du périmètre initial de l’outil ne sera pas systématiquement possible. Le passage vers une solution de type 2 sera plus difficile voire impossible si l’éditeur a protégé sa source, et refuse de l’ouvrir. L’établissement, s’il veut développer les fonctionnalités de son SID, a de grandes chances de devoir reprendre à zéro après un premier projet qui lui aura permis de mûrir son besoin. Le choix initial de la solution 2, plus évolutif, doit tout de même s’appuyer sur un véritable projet de définition de référentiels communs (partagés, donc) pour permettre une évolution vers un SID (la définition de référentiels communs étant la condition sans laquelle des données issues de sources différentes ne peuvent être mises en relation directe dans les tables de faits). La solution 2 autorise l’ajout de fonctionnalités, d’indicateurs, de restitutions sur le périmètre de données couvert (facilement si les infocentres sont modélisés, plus difficilement dans le cas contraire) Le choix de la solution 3 est par essence le plus évolutif. La gestion d’un tel projet présente cependant un niveau de difficulté supérieur, avec la nécessité d’obtenir un consensus des acteurs sur le dictionnaire métier, et la création d’un référentiel commun à l’ensemble des applicatifs pour permettre ensuite la modélisation propre au SI décisionnel Projet de référentiel commun à mener en parallèle Décision de créer un nouveau SID Intégration possible, fonction de la solution Solution 1 : pré-packagée Temps

18 Passer d’un type de SID à l’autre (1)
Comment évoluer à partir d’un SID de type 1 « pré-packagé »? Les acquis d’un SID de type 1 Des indicateurs et des restitutions effectivement utilisés (expression de besoins bien avancée) Des interfaces maîtrisées avec certains applicatifs du SIH qui respectent les contraintes et les règles imposées par l’éditeur du prépackagé Les utilisateurs ont pu exprimer des demandes sur des indicateurs non disponibles dans l’outil, ou sur des domaines non couverts (ils ont acquis une certaine maturité d’utilisation) Les points à creuser dans l’optique d’une évolution du SID Le complément de l’expression de besoins, Pour les domaines couverts par le pré-packagé, identifier et définir les indicateurs attendus, et compléter le dictionnaire des données (s’il existe), Pour les domaines à couvrir, définir les indicateurs attendus, et enrichir (ou créer) le dictionnaire des données La définition de référentiels et la transcodification La définition d’un modèle de données qui intègre les données de toutes les sources identifiées, permette une véritable analyse multidimensionnelle, et prépare l’évolution vers un SID de type 3 Passer d’une solution pré-packagée à un infocentre, nécessite de faire le choix suivant : 1 – Soit reprendre la maîtrise du modèle de données, et acquérir la possibilité de faire évoluer les tableaux de bord au gré des besoins des utilisateurs, sans limite autre que le périmètre de l’applicatif métier concerné par l’infocentre. Ce qui implique l’abandon de la solution pré-packagée au profit d’un infocentre dont il est alors nécessaire de définir le modèle de données. Ceci revient à mener le projet de SID sur autant de métiers (et de sources applicatives) que ce que couvrait la solution pré-packagée. Sauf contrainte technique forte, cela revient également à intégrer les éléments qui permettront d’évoluer ultérieurement vers une solution de type 3 et un référentiel commun aux applicatifs couverts par le SID, ainsi que des données issues des diverses sources et intégrées. 2 – Conserver la solution pré-packagée actuelle, mais la compléter avec un infocentre portant sur un autre domaine métier. Pour les domaines métiers concernés, cela consiste à mener un projet de type 3 allégé, sans les difficultés de définition d’un référentiel commun, sans l’intégration de l’ensemble des données issues des différents applicatifs.

19 Passer d’un type de SID à l’autre (2)
Comment évoluer à partir d’infocentres métier non modélisés? Les acquis des infocentres métier non modélisés Les données disponibles sont bien identifiées, A travers les requêtes les plus usuelles émergent l’expression des besoins Des utilisateurs avertis de l’infocentre ont pu également exprimer leur besoin au travers de demandes d’évolution. Les points à creuser dans l’optique d’une évolution du SID Evolution vers un modèle de type 2 : sur la base des données disponibles dans ces infocentres, compléter l’expression de besoins en rassemblant davantage d’utilisateurs potentiels, pour définir des indicateurs, des axes d’analyse, afin de modéliser l’infocentre dans ‘les règles de l’art’ Evolution vers un modèle de type 3 : idem + définir des référentiels et la transcodification qui va bien + définir un modèle de données Attention, passer d’un (ou plusieurs) infocentre à une solution pré-packagée peut constituer une régression par rapport à l’objectif de SID Comment évoluer à partir d’infocentres métier modélisés? Attention à la nécessaire intégration des données issues d’applications différentes Cette intégration s’accompagne de travaux de mise en convergence des référentiels pour tendre vers des référentiels communs à tout le SIH De nombreux établissements possèdent déjà des infocentres, qui sont des duplications des bases de données des applications de production dans lesquelles des utilisateurs avancés (type DIM ou contrôleur de gestion) peuvent faire des requêtes. Ces infocentres constituent des éléments de SID dont il faut profiter. Néanmoins les informations y sont rarement structurées de manière à être utilisables par des utilisateurs moins experts.

20 Les critères de choix de la solution et des outils
Périmètre fonctionnel à couvrir (fonctionnalités et services attendus) Il a été défini au cours de l’étape de cadrage mais peut encore évoluer en fonction du budget La maturité de gestion Si l’établissement manque de culture de gestion, on privilégiera un projet simple à mettre en œuvre, au détriment du périmètre et de l’évolutivité Le budget Des rencontres éditeurs/intégrateurs sont essentielles pour fixer son idée du budget du projet et de la capacité de réponse L’évolutivité de la solution choisie : dans le cadre de son utilisation en vie courante, la solution permet-elle de répondre à des questions qui peuvent se poser dans le futur ? Indicateurs qui croisent plusieurs sources de données Navigation multi- dimensionnelle…. L’établissement décide seul de la pondération de ses critères de choix Le choix d’outils doit prendre en compte les besoins de restitutions exprimés par les utilisateurs et retenus dans le périmètre du projet mais aussi la maturité de gestion de l’établissement. Compte tenu du coût de mise en œuvre des fonctionnalités (tableau de bord figé ou évolutif, outil d’élaboration de requêtes sur les indicateurs, pour constituer un nouveau tableau de bord, outil de simulation, outil d’analyse statistique), elles seront analysées à la lumière de la maturité de gestion de l’établissement. Le budget nécessaire est notamment fonction de la complexité de mise en œuvre (la taille du projet, le délai nécessaire pour que les utilisateurs aient accès au SID) et des coûts des outils constitutifs du SID. Il peut amener à diminuer l’ambition du projet, ce qui implique une réduction du périmètre, soit une nouvelle étape de renoncement. L’évolutivité du SID s’évalue selon deux approches : Au sein du périmètre de l’application, par l’accroissement des restitutions, du nombre d’indicateurs, l’éventuelle addition de fonctionnalités en raison de l’augmentation de la demande. Lorsque l’on prend en compte les changements à moyen terme dans les besoins de pilotage de l’établissement : compte tenu de ces changements qui nécessiteront un nouvel outil de SID distinct de celui qui nous occupe (sources d’alimentation plus importantes, besoin d’analyse multidimensionnelle plus poussé…), celui-ci pourra-t-il être développé sur la base (notamment technique) du projet en cours ou faudra-t-il tout reprendre à zéro, avec toutes les contraintes (temps, coût) que cela implique? NB : Dans le cadre d’un même projet, tous les lots sont construits sur la même base d'outillage (notamment pour le stockage), même si certains lots se caractérisent par l'ajout d'une fonctionnalité nécessitant peut être un outil de restitution différent. Corollaire : quand on passe des solutions 1 (pré-packagé) à 2 ou 2 à 3, on change de projet.

21 Travaux à mener Définir et hiérarchiser le périmètre fonctionnel cible du projet Choisir la solution technique et les outils qui la composent en fonction de la cible retenue Etablir les lots du projet et définir une trajectoire pour l’ensemble du projet

22 Définir le lotissement fonctionnel du projet
Périmètre du projet Découpage en ensembles cohérents Indicateurs Fonctionnalités assurées par l’outil retenu Sources d’informations Réponse aux orientations stratégiques Services rendus priorisés Accessibilité des données Sur la base du périmètre défini, on détermine des sous-ensembles qui, traités successivement, permettront de couvrir le périmètre dans le temps. L’idéal est de créer des sous-ensembles fonctionnels cohérents en combinant l’importance des indicateurs (selon l’importance de l’orientation stratégique ou la nécessité/l’urgence de les obtenir pour des utilisateurs cibles) et l’accessibilité des données, tout en s’efforçant de rendre cohérent le contenu des lots pour que chaque lot soit parlant pour les utilisateurs. Chaque sous-ensemble fonctionnel doit se traduire par un niveau de service rendu suffisant pour (au moins) un groupe identifié d’utilisateurs. L’importance stratégique et la cohérence fonctionnelle de son contenu constituent donc les critères prioritaires pour délimiter un sous-ensemble (lot). On s’efforcera donc de choisir des éléments qui auront du sens pour des groupes d’utilisateurs définis. L’accessibilité des données doit, quant à elle, servir de régulateur à l’ambition, car la difficulté d’obtention de données utiles pour un indicateur augmentera le délai de mise à disposition de cet indicateur dans les restitutions. Cette situation ne doit pas représenter un frein au développement d’un tel sous-ensemble, mais il s’agira peut-être de diminuer l’ambition du lot pour se donner la possibilité lors de l’étape d’expression de besoin d’étudier des solutions d’obtention des indicateurs bruts concernés, voire éventuellement d’identifier des solutions de contournement. Résultat Lotissement du projet

23 Définir le lotissement fonctionnel du projet Illustration (1)
Au sein de la solution cible (périmètre fonctionnel et choix d’outil), constituer des sous-ensembles, les lots fonctionnels, en fonction des critères suivants : L’importance du contenu fonctionnel du lot pour piloter la performance, notamment au regard de la stratégie de l’établissement, ou des attentes spécifiques de certaines populations La cohérence du service rendu : il doit être clairement identifiable pour les utilisateurs L’accessibilité des données : données aisément récupérables ou pas, données de qualité ou pas ? Exemples : Exemple 1 : les 5 indicateurs clés pour les pôles de services cliniques (nombre d’entrées total, DMS, taux d’exhaustivité des RUM, montant des charges directes, taux d’absentéisme du personnel) présentés sous forme de tableaux de bord pré-formatés mensuels et accessibles aux responsables de pôle, référents de gestion et cadres de santé, pôle par pôle, depuis l’intranet. Exemple 2 : simuler sur base de 3 hypothèses (niveau d’activité par pôle clinique, taux d’évolution des recettes, taux d’évolution des dépenses) un EPRD, en effectuant tous les 4 mois une reprojection à fin d’année.

24 Définir le lotissement fonctionnel du projet Illustration (2)
Lots fonctionnels hiérarchisés Orientations stratégiques Accessibilité des données Périmètre    + -  Indicateurs nécessaires tout de suite °°°°°°  Indicateurs importants °°°°°°  Structuration et couverture du périmètre en lots fonctionnels Tab 1 Tab 4 La notion de difficulté d’obtention d’un indicateur peut se traduire en coût (en temps, en euros) d’obtention d’un indicateur. C’est en effet un temps d’étude qui sera requis, pour un indicateur donné, pour analyser l’application source, son modèle de données, pour identifier et sélectionner une méthode d’obtention des informations, voire de contournement de fonctionnalités d’émission (par exemple, pour capter un flux envoyé à une imprimante virtuelle) de l’applicatif concerné. Cette complexité d’acquisition, rapprochée de l’importance de l’indicateur dans le suivi de l’objectif, pourra jouer sur le positionnement de l’indicateur en question dans le premier, le second ou le nième lot. La taille du périmètre, et donc des lots, donne également le rythme du projet ; il y a donc un choix « stratégique » à faire entre des lots très riches, mais mis tardivement à disposition des utilisateurs (effet tunnel important et temps d’attente entre 2 lots plus long), et des lots plus rapidement mis à disposition, mais fonctionnellement plus pauvres (avec un moindre service rendu, donc), qui pourraient entraîner une déception des utilisateurs malgré le faible temps d’attente entre deux lots. Tab 2 Tab 5 Tab 3 Tab 6

25 Exemple : Trajectoire progressive, mais diversifiée (1)
On décide d’implémenter tout le champ de la performance, mais en l’implémentant progressivement Éventuellement parce que les données nécessaires sont relativement peu accessibles dans les applications sources, Sinon parce que seules quelques données par application sont de qualité suffisante Ou encore, parce que le besoin exprimé hiérarchisé requiert des données issues de différents applicatifs

26 Exemple : Trajectoire progressive, mais diversifiée (2)
Dans tous les cas, cette approche facilite la prise en charge de demandes utilisateurs portant sur des domaines métiers différents, et permet de toucher lors du déploiement de chaque lot une famille d’utilisateurs différente. Elle permet également de ne s’intéresser qu’aux données les plus « propres » de chaque domaine métier concerné. Pour la solution 3, ce mode de fonctionnement oblige à s’appuyer sur des référentiels communs, et à intégrer immédiatement des données issues d’applications sources différentes. Deux cas possible : On peut commencer sur un noyau constitué d’indicateurs issus de sources différentes (un lot 1 multi-sources, par exemple), et agréger au fur et à mesure les indicateurs les plus faciles d’accès ou les plus important pour les utilisateurs, domaine métier après domaine métier. On peut également traiter les indicateurs d’un domaine métier, et les intégrer lot après lot en s’appuyant sur des référentiels communs

27 Exemple : Trajectoire thématique (1)
On décide de couvrir le champ de façon incrémentale, source de données par source de données, et on ajoute des fonctionnalités au fur et à mesure Ce choix peut être induit par une qualité de données homogène dans chaque application Ou bien parce que certaines applications sont plus facilement accessibles que d’autres Ou encore parce que les besoins hiérarchisés correspondent à des applicatifs précis

28 Exemple : Trajectoire thématique
Couverture du périmètre Fonctionnalités Indicateurs (fonction de la qualité des donnés sources) Utilisateurs nième groupe d’utilisateurs Lot n Fonctionnalités les plus complexes Cette approche permet de traiter en premier lieu les applications dans lesquelles les données sont le plus accessibles et de meilleure qualité En traitant globalement les applications, on règle définitivement les problématiques d’alimentation du SID pour une application donnée. Cette approche permet donc de délivrer, domaine métier après domaine métier, les informations les plus riches (indicateurs, restitutions et fonctionnalités) aux utilisateurs concernés par le métier. Cela permet également de cibler les utilisateurs lors du déploiement. 3ème groupe d’utilisateurs Lot 3 Données RH 2ème groupe d’utilisateurs Lot 2 Données activités 1er groupe d’utilisateurs Lot 1 Données PMSI Fonctionnalités les plus simples Temps