La présentation est en train de télécharger. S'il vous plaît, attendez

La présentation est en train de télécharger. S'il vous plaît, attendez

ANALYSE DES BESOINS Pascal Staccini, MD, PhD LabSTIC Santé - UFR Médecine de Nice - Université Nice-Sophia Antipolis 28 avenue de Valombrose - 06107 Nice.

Présentations similaires


Présentation au sujet: "ANALYSE DES BESOINS Pascal Staccini, MD, PhD LabSTIC Santé - UFR Médecine de Nice - Université Nice-Sophia Antipolis 28 avenue de Valombrose - 06107 Nice."— Transcription de la présentation:

1 ANALYSE DES BESOINS Pascal Staccini, MD, PhD LabSTIC Santé - UFR Médecine de Nice - Université Nice-Sophia Antipolis 28 avenue de Valombrose Nice cedex 2

2 Plan Analyse de léchec des projets Impliquer les utilisateurs Recueillir les besoins

3 Analyse de léchec des projets

4 Cycle chronologique Planification Analyse Conception Mise en œuvre Support

5 Cycle chronologique Phase de planification Définir le problème Produire le calendrier du projet Confirmer la faisabilité du projet Doter le projet en personnel Lancer le projet Phase danalyse Recueillir et rassembler linformation Définir les caractéristiques du système Prioriser les caractéristiques / spécifications Bâtir des prototypes pour la faisabilité et la découverte des spécifications Produire et évaluer des solutions de rechange Examiner les recommandations avec la direction

6 Cycle chronologique Phase de conception Concevoir et intégrer le réseau Concevoir larchitecture dapplication Concevoir les interfaces utilisateur Concevoir les interfaces système Concevoir et intégrer la base de données Faire un prototype des détails de la conception Concevoir et intégrer les contrôles du système

7 Cycle chronologique Phase de mise en œuvre Construire les composantes logicielles Vérifier et tester Convertir les données Former les utilisateur et documenter le système Installer le système Phase de support Maintenir le système Améliorer le système Soutenir les utilisateurs

8 Facteurs de risque à replacer dans le contexte dévolution organisationnelle qui simpose désormais aux établissements : réduire les coûts ; cibler la qualité de la relation avec le client ; cibler la disponibilité des nouveaux outils, standards et plates- formes ; améliorer lefficacité de la délivrance des services aux utilisateurs.

9 Echec des projets objectifs du projet : le manque daccord sur un ensemble d'objectifs bien articulés, des projets excessivement ambitieux sont des obstacles internes entraînant des risques plus élevés et des niveaux de complexité qui peuvent mettre en échec des équipes même compétentes ; composition de l'équipe projet : une équipe faible ou problématique ;

10 Echec des projets gestion et contrôle du projet : la mauvaise gestion du projet, le manque de système d'évaluation pour mesurer la progression et identifier les risques potentiels à temps pour les minimiser, et le manque de leadership responsable des prises de décision à différentes phases du projet peuvent conduire à léchec du projet ; compétence technique : le niveau d'expertise, d'expérience et de connaissance du domaine d'application de l'équipe travaillant sur le projet, tous réunis, sont insuffisants pour accomplir la tâche, et en particulier le manque de connaissance sur le recueil des besoins des utilisateurs et la production de lignes directrices concernant la conduite des activités de développement des nouveaux systèmes ;

11 Echec des projets infrastructure technologique : l'actuelle infrastructure technologique à l'intérieur de l'organisation n'a pas été évaluée avant d'entreprendre le projet ; implication des seniors : la participation active de la direction dans la surveillance de la progression du projet et dans la prise de décisions à des moments clés est essentielle, mais elle a été déléguée aux experts techniciens ou différée ; augmentation du coût et de la durée d'achèvement : ils sont symptomatiques de problèmes sérieux sous-jacents et doivent attirer l'attention des seniors.

12 10 risques majeurs Risques encourus et classement Mesures préventives Ouvrage Risque n°3 Développement de logiciels impropres à satisfaire les besoins Analyse de lorganisation Analyse des missions Revue Prototypage Rédaction anticipée des manuels utilisateurs Risque n°4 Développement de mauvaises interfaces pour les utilisateurs Analyse des tâches Prototypage Prise en compte de lutilisateur (fonction, comportement, charge de travail) Risque n°9 Défaillance des performances en temps réel Simulation Essais comparatifs Modélisation Prototypage Instrumentation Réglages Œuvre Risque n°10 Blocage sur les limites technologiques des plates- formes Analyse technique Vérification a priori des performances Analyse des coûts Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1,

13 10 risques majeurs Risques encourus et classement Mesures préventives Ressources Risque n°1 Inaptitude du personnel Structuration de léquipe Redistribution des rôles Renforcement de lencadrement Formation, entraide, motivation Planification Risque n°2 Prévisions trop optimistes, sous- estimation des budgets Recoupement de plusieurs estimations détaillées des charges, des coûts et des plannings Remise en cause des demandes Développement incrémental Réutilisation de logiciel Suivi Risque n°5 Perfectionnisme Examen critique des spécifications Prototypage Calcul des retours sur investissement Risque n°6 Contrat continu de modifications Seuil dacceptation des changements Développement incrémental Report des modifications en fin de projet Risque n°7 Défaillance des fournitures externes Mise en concurrence Contrôle des références Analyse de compatibilité Inspection et recette Risque n°8 Défaillances des travaux sous- traités Contrôle des références Audit de qualification Structuration de léquipe

14 Incertitude des projets Concevoir un système dinformation efficace suppose une connaissance précise des modes organisationnels des futurs utilisateurs, de leurs besoins dinformation et des sources disponibles. Sur tous ces points, il ne peut y avoir ni certitude ni exhaustivité. La conception des systèmes dinformation doit donc prendre en compte le contexte dincertitude

15 Incertitude des projets Facteurs situationnels, générateurs dincertitude dus au système dinformation final attitude hostile des utilisateurs faible compétence des utilisateurs instabilité de lenvironnement défaut de formalisation des informations défaut de formalisation des processus instabilité des informations et des processus caractère trop spécifique du système incompréhension des spécifications importance stratégique excessive lourdeur des changements organisationnels indisponibilité, confusion, instabilité des exigences dus au système informatique importance des changements technologiques nouveauté de la technologie cible dus à la technologie du projetinnovation technique, indisponibilité technique dus à la planification nouveauté de ladaptation, délais trop courts, budget serré dus à la structure du projet incompétence de léquipe projet dépendance de la sous-traitance dépendance envers dautres adaptations du système dinformation flou du contexte client-fournisseur

16 Incertitude des projets Cinq sources principales dincertitude viennent affecter lefficacité des choix des concepteurs : les caractéristiques de la tâche à effectuer, son degré de structuration, les prescriptions auxquelles elle est soumise, le degré de complexité que sa réalisation suppose ; lestimation des ressources informatiques nécessaires, lanticipation de la performance utile ; lexpérience de léquipe chargée de développer le système par rapport aux tâches à effectuer, sa stabilité, la possibilité de recours à des consultants extérieurs ; la capacité de lentreprise à prendre des décisions, les priorités de la direction ; lexpérience des utilisateurs par rapport à la réalisation de leur tâche à lutilisation des systèmes dinformation. Bernier C, Rivard S. Gérer lincertitude dans le développement des projets de systèmes dinformation. Gestion, 2000, mai,

17 Incertitude des projets Limportance et le nombre de ces incertitudes expliquent à la fois le nombre élevé des échecs, de 20 à 50% selon les sources et celui des insatisfactions des utilisateurs, qui est au moins de 30%. Bernier C, Rivard S. Gérer lincertitude dans le développement des projets de systèmes dinformation. Gestion, 2000, mai, Earl MJ. Experiences in strategic information systems planning, MIS Quarterly, 1993, 17, 1, Preedy D. The theory and practical use of executive information systems. International Journal of Information Management, 1990, 10, 2,

18 Conséquence des erreurs

19 Coût des corrections Activité – ProcessusCoût relatif de réparation Expression des besoins0,1 – 0,2 Conception0,5 Implémentation1 Test2 Exploitation5 Maintenance20 « plus une erreur est détectée tard dans le processus de développement de systèmes logiciels, plus les corrections à apporter sont coûteuses » Boehm BW. Software Engineering. IEEE Transactions on Computers, 1976, 25, 12,

20 En conclusion Les projets réussis ont privilégié de façon stratégique : Une définition claire des spécifications du système Une forte implication des utilisateurs Un appui de la Direction Des plans minutieux et détaillés du projet Un échéancier de travail et jalons réalistes

21 En conclusion… Finalement, cette étude détaillée des risques déchec dun projet de SI laisse une part non négligeable aux facteurs humains : mauvaise compréhension de lorganisation par les analystes, implication médiocre des utilisateurs finaux, mauvaises appréciation et formalisation des besoins des utilisateurs. Pour un SIH, et plus spécifiquement dans sa partie clinique, les soignants et les médecins sont les premiers concernés. A la complexité dune organisation telle quun hôpital, tant sur le plan structurel que sur le plan fonctionnel, sajoute limbrication, pas forcément complémentaire, de leurs besoins individuels avec ceux des groupes de médecins et soignants, ceux de lorganisation et ceux des patients. Tous sont des utilisateurs potentiels du système dinformation clinique, mais ne sont pas forcément reconnus comme tels. Savoir faire le lien entre lorganisation et les utilisateurs semble être une des conditions de réussite de la mise en œuvre dun système dinformation.

22 Impliquer les utilisateurs

23 Dès la phase de conception dun SI, du point de vue du développeur, les besoins de tous les utilisateurs potentiels, donc de chaque utilisateur, doivent être satisfaits. Pour connaître ces besoins, il est nécessaire de disposer : de méthodes pour décrire de façon pertinente, utile et utilisable les profils des utilisateurs ; de méthodes pour effectuer lanalyse des tâches, lanalyse du système et des processus, non seulement pour les individus eux-mêmes mais aussi pour les organisations dindividus ; de méthodes rapides et faciles pour récupérer, évaluer et valider les données fournies par les utilisateurs ; de méthodes fiables pour organiser les fonctions du système en menus et boîtes de dialogues selon les données des utilisateurs ; dapproches permettant de connaître et de comprendre le vocabulaire des utilisateurs. Allen CD, Ballman D, Begg V, et al. User involvement in the design process : why, when and how ? In : Conference proceedings on Human factors in computing systems. CHI93. Boston, MA: Addison-Wesley Longman Publishing Co., Inc., pp

24 Impliquer les utilisateurs Il est important de faire en sorte que létape de design soit participative, de façon à ce que les utilisateurs sortent de leur simple rôle dobservateurs, de « répertoires de connaissances » ou de simples composantes du système, pour acquérir un rôle dexpert co-designers, de copropriétaires, de contributeurs et dauto-souteneurs. Comprendre les relations entre designers et utilisateurs, cest donc savoir ce quon entend par design centré sur lutilisateur (« user centered design »). Cest une forme de design qui définit les utilisateurs, ou les données générées par ces utilisateurs, comme les critères avec lesquels un design est évalué, ou bien comme la source génératrice des idées de design. Karat J, Atwood ME, Dray SM, et al. User Centered Design: Quality or Quackery? Conference proceedings on Human factors in computing systems. CHI96. New York, NY: ACM Press, pp

25 Impliquer les utilisateurs attentes et les besoins des utilisateurs doivent être appréciées dès les premières phases de conception : « cette difficulté est-elle nécessaire ? » est souvent la meilleure question possible ; la difficulté peut souvent être contournée pour atteindre simplement le résultat ; l'environnement ou la relation avec l'environnement peut être modifié ; une personne ayant une vision globale, un point de vue nouveau, une expérience différente peut réévaluer les solutions, au contraire d'une personne plongée dans son problème habituel ; une sédimentation de paperasses, programmes informatiques, procédures, règlements, peut être remplacée par une solution à la fois simple et adaptée à l'évolution des besoins ; poser constamment la question « pourquoi ? » peut démanteler un problème. Et surtout, il est possible de reculer d'un pas, et encore d'un pas, pour repenser en amont la difficulté, la recadrer. Gallivan MJ. Changes in the management of the information systems organization: an exploratory study. In: Proceedings of the computer personnel research conference on Reinventing IS: managing information technology in changing organizations. SIGCPR. New York, NY: ACM Press, p

26 Impliquer les soignants Si la règle dimplication des utilisateurs, dès la conception dun système dinformation, est bien établie, son application au domaine clinique souffre encore de nombreuses difficultés. Pourtant, les contraintes de temps auxquelles sont soumis les acteurs de soins sont connues. Ainsi, une grande partie du travail des médecins consiste à rassembler, à trier et à classer les informations selon leur importance. Les estimations données vont de 20% à 70% du temps Un travail du National Health Service (NHS) Information for Health Strategy, a estimé quun quart du temps des médecins et des infirmiers était utilisé pour la collecte des données et la recherche dinformations. Metzger JB, Teich JM. Designing Acceptable Patient Care Information Systems. In: Patient Care Information Systems - Successful Design and Implementation. New-York, NY: Springer-Verlag, pp Burns F. Information for Health. An Information Strategy for the Modern NHS Department of Health Publications, Wetherby Disponible sur : (consulté le ).

27 Impliquer les soignants Les barrières à l'utilisation des nouvelles technologies de l'information au sein des systèmes de prestations de soins sont plus sociologiques, culturelles et organisationnelles que technologiques. Deux facteurs freinent l'utilisation des technologies de l'information : La structure singulière du système de soins fait que des demandes extrêmes sont formulées quant aux performances des systèmes d'information. L'assurance dune meilleure qualité des données, qui pourrait être la base de toute utilisation des technologies de l'information pour améliorer l'efficacité et le rendement du système de prestation des soins, est bloquée par labsence d'un centrage de l'ensemble du système sur l'amélioration des résultats. Ceci a pour corollaire le fait que le recueil des données se fasse de façon inconsistante et disjointe. Anderson JG. Clearing the way for physician's use of clinical information systems. Communications of the ACM, 1997, 40, 8, Collen MF. Health Care Information Systems: A Personal Historial Review. In: B.I. Blum, K. Duncan, (Eds.). A History of Medical Informatics. New-York, NJ: ACM Press, pp Hodges MH. History of the TDS Medical Information System. In: B.I. Blum, K. Duncan, (Eds). A History of Medical Informatics. New-York, NY: ACM Press, pp

28 Origine des difficultés Considérations comportementales – Ignorance des bénéfices potentiels Il est une croyance répandue que les médecins sont réticents à lutilisation de loutil informatique Comme raison de cette crainte, les changements de pratique induits par les nouvelles technologies. Les facteurs qui pourraient expliquer cette position sont le conservatisme intrinsèque des soignants, lanxiété générée par lignorance de cette technologie, labsence dune vision globale de la façon de lutiliser, et labsence de confiance dans la stabilité des technologies de linformation appliquée aux soins. Limpression déchec enregistrée à lévocation des projets de SIH, couplée au cynisme des cliniciens sur la définition des priorités de traitement de linformation sont considérés par le NHS comme la principale difficulté au développement et à limplantation de stratégies dinformation Les cliniciens apprécient-ils le bénéfice potentiel des technologies de linformation ? Il apparaît que non, et nous devons nous assurer que cette sensibilisation fait partie intégrante de la conception et de limplémentation dun système centré sur le patient. Une étude européenne (Eductra) a conclu que les professionnels de soins manquaient généralement de connaissance quant aux possibilités et aux limites des systèmes informatiques.

29 Origine des difficultés Considérations comportementales – Crainte du partage, de la perte dautonomie et du changement La technologie est souvent décrite comme un outil facilitant le partage des soins. Le manque de confiance entre les personnes est un obstacle pour atteindre cet objectif de soins partagés. Ceci peut venir du fait que la formation des professionnels ne met pas assez en avant le travail pluriprofessionnel. La crainte des systèmes dinformation chez les professionnels de santé est liée à un sentiment de perte dautonomie. La crainte de multiples changements sur lesquels les médecins ont peu de contrôle peut être un facteur de rejet des systèmes dinformation. Ainsi, le comportement des cliniciens et leur résistance à limplantation dapplications cliniques pourrait-il expliquer le manque de succès des systèmes en routine. Cependant, contrairement à une croyance, il ny a pas de réponse fixée et attendue des médecins, et les chercheurs sintéressent particulièrement aux dimensions comportementales. La modélisation des processus dentreprise peut faciliter la spécification des aspects structurels et comportementaux au sein dun hôpital. Lévolution des cliniciens vers la gestion coordonnée des soins et la maîtrise des coûts, peut aussi être un facteur de progrès.

30 Origine des difficultés Difficultés liées à lanalyse des besoins – Incapacité à identifier et à définir les besoins Problème majeur qui a rarement été traité avec succès. Bien que limportance de limplication des utilisateurs soit reconnue, la collecte et la formalisation des besoins des utilisateurs finaux ne sont pas bien décrites et souvent même négligées dans les projets de développement logiciel. Manque détudes sur le type de support informatique nécessaire, sur la détermination des fonctions, dont lautomatisation bénéficiera plutôt aux médecins, et sur les raisons de léchec à court terme des systèmes. Le manque de succès des premiers systèmes de saisie de prescriptions ou de retour des résultats auprès des cliniciens semble dû au fait quils avaient dabord été conçus pour répondre à des besoins de gestion financière. Ceci a permis de mettre en lumière limportance dune conception guidée par la compréhension détaillée des processus de soins du patient, et non dune conception guidée par lanalyse séparée des tâches individuelles par métier. Une autre raison de léchec des SI à être intégrés dans la pratique médicale quotidienne est quaucune analyse ciblée na été faite sur les besoins en information des médecins. Le développement de linformatique médicale a été dominé par des considérations technologiques. Le personnel médical est peu outillé pour décrire de tels besoins, alors quil est daccord sur la manière de délivrer les soins au patient. La tâche didentification des besoins des utilisateurs doit tenir compte de cela.

31 Origine des difficultés Difficultés liées à lanalyse des besoins – Non prise en compte de lorganisation du travail Les systèmes ne peuvent pas être développés sans prendre en considération lenvironnement dans lequel ils devront fonctionner. Ceci est particulièrement vrai pour les systèmes cliniques où la tendance croissante est celle dun environnement de soins partagés. Il y a une croyance de plus en plus répandue selon laquelle la solution au problème dune bonne informatisation de la pratique clinique repose plus sur des réalités politiques que technologiques. Les résultats dune étude pour déterminer les raisons qui font quun SIC réussit ou échoue, ont révélé que lexcellence ou non du système technique informatique navait quune importance relativement faible. Lensemble du SIC doit en effet intéresser toutes les structures participant aux processus cliniques, et leurs acteurs.

32 Origine des difficultés Considérations méthodologiques – Incapacité à faire correspondre modèles de travail et processus cliniques Quelles que soient les avancées offertes par les systèmes dinformation cliniques, ils représentent encore un changement dans la façon de travailler en pratique clinique. Aussi le système ne doit-il pas seulement permettre une meilleure saisie ou une meilleure recherche de données mais doit également correspondre aux processus ou aux situations de soins en cours pour un patient. Lintégration dans les pratiques de travail reste linquiétude majeure des cliniciens. Linformatisation des données médicales doit encore progresser pour paraître encore plus naturelle aux cliniciens. Persistance de lopposition entre la saisie contrôlée de données, qui facilite le travail informatique, et lentrée de données en texte libre, qui correspond mieux à lutilisateur.

33 Origine des difficultés Considérations méthodologiques – Conception du système, démarche dimplémentation Une démarche de conception et dimplémentation prenant en considération le couple clinicien / patient détermine le succès ou léchec du projet. « le grand défi pour la prochaine décennie est de construire des ordinateurs qui vous connaissent, qui apprennent vos besoins, qui comprennent la langue orale et écrite… [Nous avons besoin dordinateurs qui] ont une intelligence de telle façon à faire quasiment disparaître linterface physique. Cest là que se trouve le secret de la conception des interfaces : les faire disparaître » (Négroponte) Très peu de systèmes répondent à cet idéal et il peut être opportun daméliorer les démarches de conception et dimplémentation. Les stratégies de formation doivent être centrées sur le développement à long terme dune culture de linformation, et non, comme par le passé, sur la formation à court terme faite simplement pour permettre aux gens dutiliser les systèmes. « nous devons concevoir des systèmes autour des patients et non autour de la technologie. Nous devons parler de serveurs patients et non de clients serveurs ». (Safran)

34 Origine des difficultés Considérations technologiques Il existe des preuves qui soutiennent le fait que la technologie, en elle-même, nest pas un facteur limitant prépondérant. Cependant, certains auteurs pensent quil existe un sérieux point de divergence, en santé, entre les besoins de lorganisation et les solutions techniques qui les supportent. Les conséquences de cet état de fait sont que : les technologies de linformation ne sont pas le noyau opérationnel en santé – les pressions organisationnelles et les pressions externes laissent la technologie loin derrière elles ; la refonte des processus dentreprise devient plus courante, mais ninclut pas toujours les technologies de linformation ; les technologies de linformation en santé sont encore des cas décole et restent « abstraites » dans la pensée des acheteurs et des professionnels ; le profil des affaires ne correspond pas au profil informationnel, et ces deux sont eux-mêmes assez différents du profil technologique ; le secteur industriel lui-même est aussi lent au changement.

35 Reconnaître lacteur de soins Prérequis à limplémentation des systèmes centrés sur les patients Propositions pour améliorer limplication des cliniciens pour arriver finalement à une perception réelle et généralisée des bénéfices des SI : la reconnaissance par les gestionnaires de soins de limportance dune technologie de linformation centrée sur les patient pour le futur des services de soins ; la nécessité de ne pas méconnaître limplication des médecins, le besoin de traiter les problèmes de façon honnête et transparente, dautant que les cliniciens ont la réelle volonté dutiliser les technologies de linformation pour la délivrance des soins ; le besoin de faire en sorte que les développeurs comprennent les problèmes clés de linformatique médicale en travaillant étroitement avec les cliniciens ; lutilité de former les cliniciens aux avantages et aux inconvénients des techniques informatiques ; le fait de traiter les problèmes qui concernent les cliniciens avec eux, comme par exemple la sécurité des accès aux données confidentielles du patient ; limportance de reconnaître linvestissement des cliniciens participant au développement des projets et de mettre en avant les leaders médicaux : leur implication aidera à promouvoir lappropriation et lengagement dans le processus dimplémentation ; le fait daccepter que la technologie ne soit quun facteur parmi dautres. Les facteurs critiques pour le succès dun système sont limplication des gens, le fait que lorganisation soit prête à accepter le changement et la gestion de ce processus de changement.

36 Reconnaître lacteur de soins Analyse des besoins des utilisateurs du domaine de la santé Le travail dun professionnel de santé est caractérisé comme : 1) étant un processus dirigé par le problème ; 2) impliquant la conduite de multiples tâches concurrentes ; 3) nécessitant une interaction avec plusieurs sources et cibles informationnelles (certaines humaines, dautres informatisées) ; 4) étant sujet à de fréquentes modifications, résultant dactions de surveillance, de changements dobjectifs, ou de révision de la stratégie. La plupart des applications ont été ciblées pour fournir un support vertical à des tâches spécifiques, voire isolées. Alors que ces applications ont inclus des fonctions comme linterrogation de données cliniques, laide à la décision, léducation et la communication, elles ont généralement été réalisées de façon isolée, sans être reliées les unes aux autres, pour satisfaire les situations de résolution de problème multidisciplinaires et pluriprofessionnelles rencontrées dans la pratique médicale actuelle.

37 Système multi- utilisateurs Problèmes rencontrés au cours de la phase de design dun système multi- utilisateurs sont pour lessentiel : – la concurrence : plusieurs personnes ont besoin de la même information ou ressource (station de travail, par exemple) au même moment ; – la dépendance temps-personne : linformation fournie à une personne nest pas disponible quand elle est demandée par une autre personne (de façon analogue, une tâche effectuée par une personne dépend dune autre tâche effectuée par une autre personne qui ne la pas encore achevée) ; – la dépendance temps-lieu : linformation nest pas disponible à lendroit souhaité, au moment souhaité ; – la mauvaise différenciation des rôles : dun point de vue informationnel, les fonctions du système sont adaptées, mais lorganisation des fonctions en termes de « qui réalise des tâches particulières » nest pas adéquate ; – léchec dans lidentification de tous les participants dune tâche : le design du système, alors quil accommode les principaux rôles dune tâche, ne prend pas en compte le rôle des autres personnes qui interviennent occasionnellement (généralement pour apporter de laide) ; – le manque danalyse raisonnée : aucune analyse des pratiques de travail nest réalisée.

38 Système multi- utilisateurs Linformation nécessaire au design dun système collaboratif doit répondre aux huit questions suivantes : « quelle est la tâche ? » identifie le but du travail ; « pourquoi est-elle réalisée ? » permet de distinguer les pratiques de travail critiques pour accomplir lobjectif de celles qui ne le sont pas ; « qui effectue cette tâche ? » facilite la détermination des rôles ; « comment est-elle réalisée ? » spécifie le détail du travail dun individu ; « quand est-elle réalisée ? » identifie les dépendances dans le temps et les concurrences ; « avec quoi est-elle réalisée ? » identifie linformation et les procédures nécessaires, évalue la concurrence des ressources ; « où est-elle réalisée ? » identifie les dépendances et les concurrences temps-lieu ; « que se passe-t-il ensuite ? » identifie les concurrences pour les personnes et linformation.

39 Système multi- utilisateurs Les détails des pratiques de travail contenus dans les réponses aux questions précédentes peuvent être utilisés pour créer des représentations, au niveau de lorganisation, qui se rapportent à des interactions telles que : de qui ou de quoi dépend la tâche ? qui ou quoi dépend de cette tâche ? qui dautre a besoin des ressources utilisées pour cette tâche, à ce moment-là ? comment les pratiques de travail décrites contribuent-elles aux objectifs de lorganisation ?

40 En conclusion… Une large implication des médecins dans la sélection et limplémentation du système est essentielle. Les systèmes sans réel soutien de la part du personnel médical sont promis à léchec. Une des meilleures stratégies est de sassurer de lassistance de médecins influents pour encourager dautres membres du personnel médical à utiliser le système dans leur pratique.

41 En conclusion… Considérer à lavance la façon dont le système qui va être introduit va affecter les modes de pratique et les relations professionnelles. Il est important didentifier les bénéfices spécifiques que le SI apporte aux individus et aux groupes professionnels. Les médecins utiliseront le SI sil les aide à mieux prendre en charge les patients. Les bénéfices pour lorganisation en général ne motiveront pas les médecins à changer leurs habitudes de travail.

42 En conclusion Les établissements de santé doivent anticiper et gérer les changements de comportements et dorganisation induits par lintroduction dun SIC intégré. Si ces changements, qui ont été montrés comme inhibiteurs de ladoption et de lutilisation des systèmes informatisés, sont ignorés, on peut sattendre à un échec du système ou à des effets fortuits. Ces problèmes peuvent être évités ou diminués en anticipant la façon dont les groupes professionnels vont percevoir un nouveau SI. La communication dans les groupes concernés par limplémentation du système est un moyen didentifier et de résoudre des problèmes potentiels qui, sils restent non résolus, peuvent contrarier lacceptation et lutilisation du système.

43 Recueillir linformation

44 Durant la phase danalyse, collecte dune très grande quantité dinformations auprès des personnes qui utiliseront le système Soit en les interviewant Soit en les regardant travailler en lisant les documents de planification, les procédures, les exposés de principes, la documentation du système existant en regardant ce qui a été fait dans dautres entreprises pour répondre à un besoin semblable (benchmarking) parler à toutes les personnes qui se serviront du système ou ont utilisé un système similaire, lire tout ce qui existe sur le système actuel

45 Recueillir linformation Lanalyste doit devenir un expert du domaine que le système supportera Lanalyse doit aussi recueillir de linformation technique pour comprendre le système existant : En identifiant et en comprenant les activités de tous les utilisateurs présents et à venir En identifiant tous les lieux actuels et futurs où le travail seffectue En identifiant toutes les interfaces à dautres systèmes à lintérieur comme à lextérieur de lorganisation la question essentielle : est-ce que nous avons toute linformation (et la connaissance) dont nous avons besoin pour définir ce que le système doit faire ? Pour qui, pourquoi, quand et comment ?

46 Prioriser les spécifications Etablir quelles sont les spécifications fonctionnelles et techniques vitales pour le système Les utilisateurs proposent beaucoup de fonctionnalités souhaitables / souhaitées mais pas essentielles Utilisateurs et analystes doivent se demander ensemble quelles sont les fonctions vitales et celles importances mais non requises La priorisation est nécessaire car les ressources sont limitées et un champ de spécifications qui augmente à mesure que les utilisateurs font des suggestions devient un risque déchec du projet quelles sont les choses importantes que le système doit faire…

47 Pour un SIH ? Un analyste peut-il être étranger au dispositif « métier » ? Sa connaissance ne peut-elle être quextérieure ? En quoi une expertise métier est-elle nécessaire ? La plupart des analystes consultants des SIH sont issus des métiers de lhôpital, MAIS…

48 Les intervenants Définition : toutes les personnes qui sont concernées par la réussite du nouveau système… Quatre catégories : Les utilisateurs, soit ceux qui utilisent le système tous les jours Les clients, soit ceux qui paient pour le système et en sont propriétaires Le personnel technique, soit les personnes qui sont responsables du fonctionnement du système dans lenvironnement de lorganisation Les entités extérieures, tels les clients de lorganisation

49 Méthodes de cueillette Distribuer les questionnaires Interviewer les utilisateurs Etudier la documentation existante Observer les procédés administratifs Rechercher des solutions auprès de fournisseurs Comprendre les contraintes du nouveau système Comprendre les procédures du nouveau système Comprendre les fonctions du nouveau système Développer les spécifications et les modèles pour le nouveau système

50 Thèmes de la cueillette ThèmeQuestions aux utilisateurs Quels sont les opérations et les procédés administratifs Que faites-vous ? Comment ces opérations doivent-elles seffectuer ? Comment le faites-vous ? Quelle démarche suivez-vous ? Quelles informations faut-il pour réaliser ces opérations ? Quelles informations utilisez-vous ? Quels formulaires ou rapports utilisez- vous ?

51 Techniques de cueillette Examiner les rapports, formulaires et descriptions de procédures existantes Animer des entrevues et des discussion avec les utilisateurs Observer et documenter les procédés administratifs Construire des prototypes Distribuer et ramasser des questionnaires Animer des séances de développement conjoint dapplications Etudier des solutions proposées par des fournisseurs

52 Expression des besoins processus dexpression des besoins définit les trois activités suivantes : lactivité « dacquisition des besoins » : cette activité, également appelée identification des besoins, ou analyse du problème, ou bien recueil des besoins, ou encore documentation des besoins, consiste à collecter sous forme informelle lensemble des besoins qui permettront datteindre une bonne compréhension du système. Cest lactivité durant laquelle lingénieur des besoins découvre, corrige, articule, et comprend les besoins. lactivité « de conceptualisation des besoins » : cette activité, également appelée spécification des besoins, ou description du produit, ou bien formalisation des besoins, ou encore expression des besoins, consiste à exprimer les besoins acquis à lissue de létape précédente, à laide dun formalisme intégrant un certain nombre de concepts graphiques et/ou mathématiques. lactivité « de validation des besoins » : cette activité, également appelée analyse du problème et des besoins, ou analyse et validation des besoins, ou bien validation des besoins, ou encore discussion des besoins, consiste à sassurer que les besoins conceptualisés traduisent de manière complète et cohérente les désirs, les contraintes, et les volontés du client.

53 Problématique des problèmes de dimensionnement, pour lesquels les exigences peuvent concerner trop peu ou beaucoup trop dinformation : les limites du système sont mal définies, des informations non nécessaires pour la conception sont données. des problèmes de compréhension aussi bien à lintérieur dun groupe quentre groupes dutilisateurs ou de développeurs : les utilisateurs ont une compréhension incomplète de leurs besoins, les utilisateurs ont peu de connaissance sur les possibilités et les limites des systèmes informatiques, les analystes ont une connaissance très faible du domaine dintérêt, utilisateurs et analystes sexpriment dans des langages différents, il est facile domettre des informations évidentes, il existe des vues conflictuelles entre différents utilisateurs, les besoins exprimés sont souvent vagues et peu vérifiables. des problèmes dinconstance et dévolution des besoins avec le temps.

54 Guide QuestionsObjetsExemples quels documents sont utilisés dans le système ?document questionnaires, instructions, rapports, produits intermédiaires, manuel de références, etc. qui / quoi reçoit le document ?destinataire client, membre du personnel, département de lentreprise, organisation extérieure, etc. qui / quoi élabore le document ?créateuremployés, fournisseurs, équipement comme les ordinateurs, etc. quelles sont les ressources utilisées pour élaborer le document ? ressourceargent, matière première, documents de référence quels sont les événements à lorigine de la création du document ? événement arrivée du moment de la paie mensuelle, arrivée dune commande de client QuestionsCaractéristiques décrites quelles sont les différentes parties du document ? quels sont les éléments de base de lobjet ? attributs que fait le créateur ou le destinataire avec les items du document ?méthodes comment fait la ressource ou lévénement pour fournir linformation pour créer le document ? méthodes que fait le destinataire pour accepter le document ?méthodes que fait le créateur pour fournir le document ?méthodes

55 Quelques situations…

56 Question Lun des problèmes les plus ardus de linvestigation des spécifications dun système est de sassurer quelles sont complètes et détaillées. Que feriez-vous pour vous garantir dobtenir toutes les bonnes informations lors dune entrevue ?

57 Réponse Les réponses devraient inclure les points suivants : Sassurer davoir identifié tous les intervenants et de les avoir inclus dans les activités de définition des spécifications. Examiner tous les formulaires et rapports existants pour vérifier que tous les besoins dinformation sont compris. Identifier et comprendre chaque activité de gestion. Sassurer que toutes les procédures administratives ont été discutées. Sassurer que toutes les conditions dexception ont été identifiées et leurs champs associés définis. Maintenir une liste des articles ouverts et sassurer que tous les éléments sont résolus.

58 Question Que pouvez-vous faire pour être certain davoir inclus tous les bons intervenants sur votre liste de personnes à interroger ?

59 Réponse Une méthode consiste à obtenir, ou au besoin construire, un organigramme de lentreprise. Cela facilitera lidentification de tous les intervenants potentiels. Le sous-ensemble de lorganigramme qui contient les intervenants nécessaires peut être créé en fonction de la portée du système. Il y a plusieurs façons de vérifier votre liste : (1) la revoir avec le client principal (le groupe qui assure lapprobation et le financement du projet); (2) la vérifier avec le comité de surveillance du projet; (3) la revoir avec le chef du groupe des systèmes dinformation ou avec toute autre personne qui maîtrise bien les systèmes.

60 Question Un des problèmes communs lors dune investigation est le « glissement » de la portée du système, cest-à-dire des demandes de fonctions additionnelles de la part des utilisateurs. Ce glissement survient parce quil arrive que les utilisateurs aient de nombreux problèmes non résolus et que cette investigation représente peut-être pour eux la première occasion de se faire entendre. Que devez-vous faire pour empêcher que le système grossisse et comprenne des fonctions qui ne devraient pas en faire partie ?

61 Réponse Ce problème est essentiellement une question de gestion de projet. Le chef de projet devrait établir des lignes directrices pour le contrôler. Une méthode préventive consiste à sassurer que la définition initiale de la portée est convenable et complète. Une définition incomplète exacerbera le problème de glissement de la portée. Si la portée du système a été définie adéquatement au départ, une façon de régler le problème de glissement est de mettre sur pied un comité formé de membres de léquipe de projet et dutilisateurs ou de clients qui devra approuver tout nouvel ajout à la portée du système. Avant approbation, il faudra faire une évaluation pour déterminer la pertinence et limportance de la demande et son effet sur le calendrier du projet. Demandez la participation des utilisateurs à la décision afin que celle-ci soit une décision conjointe et non un diktat du chef de projet. Une autre technique consiste à commencer une liste des améliorations pour la prochaine version du système. Certaines demandes peuvent en effet être reportées à une version ultérieure.

62 Question Que feriez-vous si deux personnes vous donnaient des réponses contradictoires sur une même procédure ? Que feriez-vous si lune des personnes était membre du personnel de bureau et que lautre était son chef de service ?

63 Réponse La première réaction serait de considérer lopinion du chef de service comme étant la bonne réponse. Toutefois, il est assez fréquent quun chef de service ne soit pas au courant des derniers détails de certaines procédures de gestion. La meilleure solution, dans ce cas, consiste à réunir deux personnes et les laisser discuter jusquà ce quelles sentendent sur la bonne procédure. Il importe que la décision ne vienne pas de lanalyste. Il est aussi important de ne pas essayer de résoudre les divergences vous-mêmes : cela incombe à lutilisateur.

64 Question On vous a donné la responsabilité de résoudre plusieurs problèmes en suspens et vous éprouvez des difficultés à obtenir des décision stratégiques de la part de votre contact. Comment pouvez-vous encourager lutilisateur à finaliser ces décisions ?

65 Réponse Une question dopinion épineuse qui offre plusieurs réponses. En règle générale, les retards à prendre des décisions stratégiques ont des effets importants sur le calendrier dun projet et il arrive que lutilisateur ne comprenne pas ces impacts. La première approche devrait donc être dexpliquer leffet négatif quune décision donnée peut avoir sur le projet. Si cela ne fonctionne pas, il est possible de prendre des mesures plus radicales, comme suggérer que le comité de surveillance du projet examine la liste des questions en suspens. De plus, si cette liste inclut une indication de la durée pendant laquelle des élément ont été ouverts, il est possible dattribuer une priorité (ou daugmenter la priorité) des éléments qui deviennent critiques.


Télécharger ppt "ANALYSE DES BESOINS Pascal Staccini, MD, PhD LabSTIC Santé - UFR Médecine de Nice - Université Nice-Sophia Antipolis 28 avenue de Valombrose - 06107 Nice."

Présentations similaires


Annonces Google