Embed Size (px)
Citation preview
ANALYSEDES BESOINS
Pascal Staccini, MD, PhDLabSTIC Santé - UFR Médecine de Nice - Université Nice-Sophia Antipolis28 avenue de Valombrose - 06107 Nice cedex [email protected]
Plan
•Analyse de l’échec des projets
• Impliquer les utilisateurs•Recueillir les besoins
Analyse de l’échecdes projets
Cycle chronologique
• Planification
• Analyse
• Conception
• Mise en œuvre
• Support
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 d’analyse
Recueillir et rassembler l’information
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
Cycle chronologique
• Phase de conceptionConcevoir et intégrer le réseauConcevoir l’architecture d’applicationConcevoir les interfaces utilisateurConcevoir les interfaces systèmeConcevoir et intégrer la base de donnéesFaire un prototype des détails de la conceptionConcevoir et intégrer les contrôles du système
Cycle chronologique
• Phase de mise en œuvreConstruire 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 supportMaintenir le système
Améliorer le système
Soutenir les utilisateurs
Facteurs de risque
à replacer dans le contexte d’évolution organisationnelle qui s’impose 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 l’efficacité de la délivrance des services aux utilisateurs.
Echec des projets
objectifs du projet :le manque d’accord 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 ;
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 ;
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.
10 risques majeursRisques encourus
et classementMesures préventives
Ouvrage
Risque n°3Développement de logiciels impropres à satisfaire les
besoins
Analyse de l’organisationAnalyse des missionsRevuePrototypageRédaction anticipée des manuels utilisateurs
Risque n°4Développement de
mauvaises interfaces pour les utilisateurs
Analyse des tâchesPrototypagePrise en compte de l’utilisateur (fonction, comportement, charge de travail)
Risque n°9Défaillance des
performances en temps réel
SimulationEssais comparatifsModélisationPrototypageInstrumentationRéglages
Œuvre
Risque n°10Blocage sur les limites
technologiques des plates-formes
Analyse techniqueVérification a priori des performancesAnalyse des coûts
Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1, 32-41.
10 risques majeursRisques encourus
et classementMesures préventives
RessourcesRisque n°1
Inaptitude du personnel
Structuration de l’équipeRedistribution des rôlesRenforcement de l’encadrementFormation, entraide, motivation
PlanificationRisque n°2
Prévisions trop optimistes, sous- estimation des budgets
Recoupement de plusieurs estimations détaillées des charges, des coûts et des planningsRemise en cause des demandesDéveloppement incrémentalRéutilisation de logiciel
Suivi
Risque n°5Perfectionnisme
Examen critique des spécificationsPrototypageCalcul des retours sur investissement
Risque n°6Contrat continu de
modifications
Seuil d’acceptation des changementsDéveloppement incrémentalReport des modifications en fin de projet
Risque n°7Défaillance des fournitures
externes
Mise en concurrenceContrôle des référencesAnalyse de compatibilitéInspection et recette
Risque n°8Défaillances des travaux
sous-traités
Contrôle des référencesAudit de qualificationStructuration de l’équipe
Incertitude des projets
Concevoir un système d’information efficace suppose une connaissance précise des modes organisationnels des futurs utilisateurs, de leurs besoins d’information et des sources disponibles.
Sur tous ces points, il ne peut y avoir ni certitude ni exhaustivité. La conception des systèmes d’information doit donc prendre en compte le contexte d’incertitude
Incertitude des projets
Facteurs situationnels, générateurs d’incertitude
dus au système d’information final
attitude hostile des utilisateursfaible compétence des utilisateursinstabilité de l’environnementdéfaut de formalisation des informationsdéfaut de formalisation des processusinstabilité des informations et des processuscaractère trop spécifique du systèmeincompréhension des spécificationsimportance stratégique excessivelourdeur des changements organisationnelsindisponibilité, confusion, instabilité des exigences
dus au système informatiqueimportance des changements technologiquesnouveauté de la technologie cible
dus à la technologie du projet innovation technique, indisponibilité technique
dus à la planificationnouveauté de l’adaptation, délais trop courts,budget serré
dus à la structure du projet
incompétence de l’équipe projetdépendance de la sous-traitancedépendance envers d’autres adaptations du système d’informationflou du contexte client-fournisseur
Incertitude des projets
Cinq sources principales d’incertitude viennent affecter l’efficacité 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 ;
l’estimation des ressources informatiques nécessaires, l’anticipation de la performance utile ;
l’expé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 l’entreprise à prendre des décisions, les priorités de la direction ;
l’expérience des utilisateurs par rapport à la réalisation de leur tâche à l’utilisation des systèmes d’information.Bernier C, Rivard S. Gérer l’incertitude dans le développement des projets de systèmes d’information. Gestion, 2000, mai, 47-54.
Incertitude des projets
L’importance 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 l’incertitude dans le développement des projets de systèmes d’information. Gestion, 2000, mai, 47-54.Earl MJ. Experiences in strategic information systems planning, MIS Quarterly, 1993, 17, 1, 1-24.Preedy D. The theory and practical use of executive information systems. International Journal of Information Management, 1990, 10, 2, 96-104.
Conséquence des erreurs
Coût des correctionsActivité – Processus Coût relatif de réparation
Expression des besoins 0,1 – 0,2
Conception 0,5
Implémentation 1
Test 2
Exploitation 5
Maintenance 20« 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, 1226-1241.
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
En conclusion…Finalement, cette étude détaillée des risques d’échec d’un projet de SI laisse une part non négligeable aux facteurs humains :
mauvaise compréhension de l’organisation 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é d’une organisation telle qu’un hôpital, tant sur le plan structurel que sur le plan fonctionnel, s’ajoute l’imbrication, pas forcément complémentaire, de leurs besoins individuels avec ceux des groupes de médecins et soignants, ceux de l’organisation et ceux des patients.
Tous sont des utilisateurs potentiels du système d’information clinique, mais ne sont pas forcément reconnus comme tels.
Savoir faire le lien entre l’organisation et les utilisateurs semble être une des conditions de réussite de la mise en œuvre d’un système d’information.
Impliquerles utilisateurs
Impliquer les utilisateurs
Dès la phase de conception d’un 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 l’analyse des tâches, l’analyse du système et des processus, non seulement pour les individus eux-mêmes mais aussi pour les organisations d’individus ;
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 ;
d’approches 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. CHI’93. Boston, MA: Addison-Wesley Longman Publishing Co., Inc., 1993.- pp. 251-254.
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 d’observateurs, de « répertoires de connaissances » ou de simples composantes du système, pour acquérir un rôle d’expert co-designers, de copropriétaires, de contributeurs et d’auto-souteneurs.Comprendre les relations entre designers et utilisateurs, c’est donc savoir ce qu’on entend par design centré sur l’utilisateur (« user centered design »). C’est 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. CHI’96. New York, NY: ACM Press, 1996.- pp. 161-162.
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, 1994.- p. 65-77.
Impliquer les soignants
Si la règle d’implication des utilisateurs, dès la conception d’un système d’information, 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é qu’un quart du temps des médecins et des infirmiers était utilisé pour la collecte des données et la recherche d’informations.
Metzger JB, Teich JM. Designing Acceptable Patient Care Information Systems. In: Patient Care Information Systems - Successful Design and Implementation. New-York, NY: Springer-Verlag, 1996.- pp. 84-132.Burns F. Information for Health. An Information Strategy for the Modern NHS 1998-2005. Department of Health Publications, Wetherby 1998. Disponible sur : < http://www.doh.gov.uk/ipu/ strategy/full/imt.pdf> (consulté le 15.08.2002).
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 d’une 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 l’absence 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, 83-90.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, 1990.- pp. 290-307.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, 1990.- pp. 328-356.
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 à l’utilisation de l’outil 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, l’anxiété générée par l’ignorance de cette technologie, l’absence d’une vision globale de la façon de l’utiliser, et l’absence de confiance dans la stabilité des technologies de l’information appliquée aux soins.
L’impression 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 l’information sont considérés par le NHS comme la principale difficulté au développement et à l’implantation de stratégies d’information
Les cliniciens apprécient-ils le bénéfice potentiel des technologies de l’information ? Il apparaît que non, et nous devons nous assurer que cette sensibilisation fait partie intégrante de la conception et de l’implémentation d’un 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.
Origine des difficultés• Considérations comportementales
– Crainte du partage, de la perte d’autonomie 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 d’information chez les professionnels de santé est liée à un sentiment de perte d’autonomie.
La crainte de multiples changements sur lesquels les médecins ont peu de contrôle peut être un facteur de rejet des systèmes d’information. Ainsi, le comportement des cliniciens et leur résistance à l’implantation d’applications cliniques pourrait-il expliquer le manque de succès des systèmes en routine.
Cependant, contrairement à une croyance, il n’y a pas de réponse fixée et attendue des médecins, et les chercheurs s’intéressent particulièrement aux dimensions comportementales.
La modélisation des processus d’entreprise peut faciliter la spécification des aspects structurels et comportementaux au sein d’un 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.
Origine des difficultés• Difficultés liées à l’analyse des besoins
– Incapacité à identifier et à définir les besoins
Problème majeur qui a rarement été traité avec succès.
Bien que l’importance de l’implication 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 l’automatisation 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 qu’ils avaient d’abord été conçus pour répondre à des besoins de gestion financière.
Ceci a permis de mettre en lumière l’importance d’une conception guidée par la compréhension détaillée des processus de soins du patient, et non d’une conception guidée par l’analyse 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 qu’aucune analyse ciblée n’a été faite sur les besoins en information des médecins.
Le développement de l’informatique médicale a été dominé par des considérations technologiques. Le personnel médical est peu outillé pour décrire de tels besoins, alors qu’il est d’accord sur la manière de délivrer les soins au patient. La tâche d’identification des besoins des utilisateurs doit tenir compte de cela.
Origine des difficultés
• Difficultés liées à l’analyse des besoins– Non prise en compte de l’organisation du travail
Les systèmes ne peuvent pas être développés sans prendre en considération l’environnement dans lequel ils devront fonctionner. Ceci est particulièrement vrai pour les systèmes cliniques où la tendance croissante est celle d’un environnement de soins partagés.
Il y a une croyance de plus en plus répandue selon laquelle la solution au problème d’une bonne informatisation de la pratique clinique repose plus sur des réalités politiques que technologiques.
Les résultats d’une étude pour déterminer les raisons qui font qu’un SIC réussit ou échoue, ont révélé que l’excellence ou non du système technique informatique n’avait qu’une importance relativement faible. L’ensemble du SIC doit en effet intéresser toutes les structures participant aux processus cliniques, et leurs acteurs.
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 d’information 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.
L’intégration dans les pratiques de travail reste l’inquiétude majeure des cliniciens.
L’informatisation des données médicales doit encore progresser pour paraître encore plus naturelle aux cliniciens.
Persistance de l’opposition entre la saisie contrôlée de données, qui facilite le travail informatique, et l’entrée de données en texte libre, qui correspond mieux à l’utilisateur.
Origine des difficultés• Considérations méthodologiques
– Conception du système, démarche d’implémentation
Une démarche de conception et d’implé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 d’ordinateurs qui] ont une intelligence de telle façon à faire quasiment disparaître l’interface physique. C’est 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 d’améliorer les démarches de conception et d’implémentation.
Les stratégies de formation doivent être centrées sur le développement à long terme d’une culture de l’information, et non, comme par le passé, sur la formation à court terme faite simplement pour permettre aux gens d’utiliser 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)
Origine des difficultés• Considérations technologiques
Il existe des preuves qui soutiennent le fait que la technologie, en elle-même, n’est pas un facteur limitant prépondérant. Cependant, certains auteurs pensent qu’il existe un sérieux point de divergence, en santé, entre les besoins de l’organisation et les solutions techniques qui les supportent.
Les conséquences de cet état de fait sont que :
les technologies de l’information 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 d’entreprise devient plus courante, mais n’inclut pas toujours les technologies de l’information ;
• les technologies de l’information 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.
Reconnaître l’acteur de soins• Prérequis à l’implémentation des systèmes centrés sur les patients
• Propositions pour améliorer l’implication 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 l’importance d’une technologie de l’information centrée sur les patient pour le futur des services de soins ;
• la nécessité de ne pas méconnaître l’implication des médecins, le besoin de traiter les problèmes de façon honnête et transparente, d’autant que les cliniciens ont la réelle volonté d’utiliser les technologies de l’information pour la délivrance des soins ;
• le besoin de faire en sorte que les développeurs comprennent les problèmes clés de l’informatique médicale en travaillant étroitement avec les cliniciens ;
• l’utilité 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 ;
• l’importance de reconnaître l’investissement des cliniciens participant au développement des projets et de mettre en avant les leaders médicaux : leur implication aidera à promouvoir l’appropriation et l’engagement dans le processus d’implémentation ;
• le fait d’accepter que la technologie ne soit qu’un facteur parmi d’autres. Les facteurs critiques pour le succès d’un système sont l’implication des gens, le fait que l’organisation soit prête à accepter le changement et la gestion de ce processus de changement.
Reconnaître l’acteur de soins• Analyse des besoins des utilisateurs du domaine de la santé
• Le travail d’un 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, d’autres informatisées) ;
• 4) étant sujet à de fréquentes modifications, résultant d’actions de surveillance, de changements d’objectifs, 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 l’interrogation de données cliniques, l’aide à 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.
Système multi-utilisateurs• Problèmes rencontrés au cours de la phase de design d’un système multi-
utilisateurs sont pour l’essentiel :– 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 : l’information fournie à une personne n’est 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 d’une autre tâche effectuée par une autre personne qui ne l’a pas encore achevée) ;
– la dépendance temps-lieu : l’information n’est pas disponible à l’endroit souhaité, au moment souhaité ;
– la mauvaise différenciation des rôles : d’un point de vue informationnel, les fonctions du système sont adaptées, mais l’organisation des fonctions en termes de « qui réalise des tâches particulières » n’est pas adéquate ;
– l’échec dans l’identification de tous les participants d’une tâche : le design du système, alors qu’il accommode les principaux rôles d’une tâche, ne prend pas en compte le rôle des autres personnes qui interviennent occasionnellement (généralement pour apporter de l’aide) ;
– le manque d’analyse raisonnée : aucune analyse des pratiques de travail n’est réalisée.
Système multi-utilisateurs• L’information nécessaire au design d’un 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 l’objectif 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 d’un 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 l’information 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 l’information.
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 l’organisation, 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 d’autre 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 l’organisation ?
En conclusion…
• Une large implication des médecins dans la sélection et l’implé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 s’assurer de l’assistance de médecins influents pour encourager d’autres membres du personnel médical à utiliser le système dans leur pratique.
En conclusion…
• Considérer à l’avance la façon dont le système qui va être introduit va affecter les modes de pratique et les relations professionnelles. Il est important d’identifier les bénéfices spécifiques que le SI apporte aux individus et aux groupes professionnels. Les médecins utiliseront le SI s’il les aide à mieux prendre en charge les patients. Les bénéfices pour l’organisation en général ne motiveront pas les médecins à changer leurs habitudes de travail.
En conclusion
• Les établissements de santé doivent anticiper et gérer les changements de comportements et d’organisation induits par l’introduction d’un SIC intégré. Si ces changements, qui ont été montrés comme inhibiteurs de l’adoption et de l’utilisation des systèmes informatisés, sont ignorés, on peut s’attendre à 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 l’implémentation du système est un moyen d’identifier et de résoudre des problèmes potentiels qui, s’ils restent non résolus, peuvent contrarier l’acceptation et l’utilisation du système.
Recueillir l’information
Recueillir l’information
• Durant la phase d’analyse, collecte d’une très grande quantité d’informations• 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 d’autres 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
Recueillir l’information
• L’analyste doit devenir un expert du domaine que le système supportera
• L’analyse doit aussi recueillir de l’information 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
s’effectue• En identifiant toutes les interfaces à d’autres systèmes à
l’intérieur comme à l’extérieur de l’organisation
la question essentielle : est-ce que nous avons toute l’information (et la connaissance) dont nous avons besoin pour définir ce que le système doit faire ? Pour qui, pourquoi, quand et comment ?
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…
Pour un SIH ?
• Un analyste peut-il être étranger au dispositif « métier » ?
• Sa connaissance ne peut-elle être qu’extérieure ?
• En quoi une expertise métier est-elle nécessaire ?
• La plupart des analystes consultants des SIH sont issus des métiers de l’hôpital, MAIS…
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 l’environnement de l’organisation
• Les entités extérieures, tels les clients de l’organisation
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
Thèmes de la cueillette
Thème Questions aux utilisateurs
Quels sont les opérations et les procédés administratifs
Que faites-vous ?
Comment ces opérations doivent-elles s’effectuer ?
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 ?
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
d’applications• Etudier des solutions proposées par des fournisseurs
Expression des besoins• processus d’expression des besoins définit les trois activités suivantes :
• l’activité « d’acquisition 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 l’ensemble des besoins qui permettront d’atteindre une bonne compréhension du système. C’est l’activité durant laquelle l’ingénieur des besoins découvre, corrige, articule, et comprend les besoins.
• l’activité « 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 à l’issue de l’étape précédente, à l’aide d’un formalisme intégrant un certain nombre de concepts graphiques et/ou mathématiques.
• l’activité « 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 à s’assurer 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.
Problématique• des problèmes de dimensionnement, pour lesquels les exigences peuvent
concerner trop peu ou beaucoup trop d’information :• 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 à l’intérieur d’un groupe qu’entre groupes d’utilisateurs 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 d’intérêt,
• utilisateurs et analystes s’expriment dans des langages différents,
• il est facile d’omettre 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 d’inconstance et d’évolution des besoins avec le temps.
GuideQuestions Objets Exemples
quels documents sont utilisés dans le système ? documentquestionnaires, instructions, rapports, produits
intermédiaires, manuel de références, etc.
qui / quoi reçoit le document ? destinataireclient, membre du personnel, département de l’entreprise,
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 ?
ressource argent, matière première, documents de référence
quels sont les événements à l’origine de la création du document ?
événementarrivée du moment de la paie mensuelle, arrivée d’une
commande de client
Questions Caractéristiques décrites
quelles sont les différentes parties du document ?quels sont les éléments de base de l’objet ?
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 l’information 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
Quelques situations…
Question
• L’un des problèmes les plus ardus de l’investigation des spécifications d’un système est de s’assurer qu’elles sont complètes et détaillées. Que feriez-vous pour vous garantir d’obtenir toutes les bonnes informations lors d’une entrevue ?
Réponse
• Les réponses devraient inclure les points suivants :• S’assurer d’avoir 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 d’information sont compris.
• Identifier et comprendre chaque activité de gestion. S’assurer que toutes les procédures administratives ont été discutées.
• S’assurer que toutes les conditions d’exception ont été identifiées et leurs champs associés définis.
• Maintenir une liste des articles ouverts et s’assurer que tous les éléments sont résolus.
Question
• Que pouvez-vous faire pour être certain d’avoir inclus tous les bons intervenants sur votre liste de personnes à interroger ?
Réponse
• Une méthode consiste à obtenir, ou au besoin construire, un organigramme de l’entreprise.
• Cela facilitera l’identification de tous les intervenants potentiels. Le sous-ensemble de l’organigramme 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
l’approbation 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 d’information ou avec toute autre personne qui maîtrise bien les systèmes.
Question
• Un des problèmes communs lors d’une investigation est le « glissement » de la portée du système, c’est-à-dire des demandes de fonctions additionnelles de la part des utilisateurs. Ce glissement survient parce qu’il 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 ?
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 à s’assurer 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 d’utilisateurs 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 l’importance 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.
Question
• Que feriez-vous si deux personnes vous donnaient des réponses contradictoires sur une même procédure ? Que feriez-vous si l’une des personnes était membre du personnel de bureau et que l’autre était son chef de service ?
Réponse
• La première réaction serait de considérer l’opinion du chef de service comme étant la bonne réponse.
• Toutefois, il est assez fréquent qu’un 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 qu’elles s’entendent sur la bonne procédure.
• Il importe que la décision ne vienne pas de l’analyste.• Il est aussi important de ne pas essayer de résoudre les
divergences vous-mêmes : cela incombe à l’utilisateur.
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 l’utilisateur à finaliser ces décisions ?
Réponse• Une question d’opinion é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 d’un projet et il arrive que l’utilisateur ne comprenne pas ces impacts.
• La première approche devrait donc être d’expliquer l’effet négatif qu’une 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 d’attribuer une priorité (ou d’augmenter la priorité) des éléments qui deviennent critiques.
