Analyse des besoins

Pascal Staccini

PARTIE 1
Dveloppement
Cycle chronologique Facteurs de risque
Echec des projets 10 risques majeurs dun projet Incertitude des projets

Consquences des erreurs Cot des corrections Conclusion

Cycle chronologique
Phase de planification

Dfinir le problme Produire le calendrier du projet Confirmer la faisabilit du projet Doter le projet en personnel Lancer le projet

Phase danalyse
Recueillir et rassembler linformation Dfinir les caractristiques du systme Prioriser les caractristiques / spcifications Btir des prototypes pour la faisabilit et la dcouverte des spcifications Produire et valuer des solutions de rechange Examiner les recommandations avec la direction

Cycle chronologique
Phase de conception
Concevoir et intgrer le rseau Concevoir larchitecture dapplication Concevoir les interfaces utilisateur Concevoir les interfaces systme Concevoir et intgrer la base de donnes Faire un prototype des dtails de la conception Concevoir et intgrer les contrles du systme Construire les composantes logicielles Vrifier et tester Convertir les donnes Former les utilisateur et documenter le systme Installer le systme

Phase de mise en uvre

Phase de support
Maintenir le systme Amliorer le systme Soutenir les utilisateurs

Facteurs de risque
replacer dans le contexte dvolution organisationnelle qui simpose dsormais aux tablissements :
rduire les cots ; cibler la qualit de la relation avec le client ; cibler la disponibilit des nouveaux outils, standards et plates-formes ; amliorer lefficacit de la dlivrance des services aux utilisateurs.

Echec des projets

objectifs du projet :
le manque daccord sur un ensemble d'objectifs bien articuls, des projets excessivement ambitieux sont des obstacles internes entranant des risques plus levs et des niveaux de complexit qui peuvent mettre en chec des quipes mme comptentes ;

composition de l'quipe projet :

une quipe faible ou problmatique ;

Echec des projets

gestion et contrle du projet :
la mauvaise gestion du projet, le manque de systme d'valuation pour mesurer la progression et identifier les risques potentiels temps pour les minimiser, et le manque de leadership responsable des prises de dcision diffrentes phases du projet peuvent conduire lchec du projet ;

comptence technique :
le niveau d'expertise, d'exprience et de connaissance du domaine d'application de l'quipe travaillant sur le projet, tous runis, sont insuffisants pour accomplir la tche, et en particulier le manque de connaissance sur le recueil des besoins des utilisateurs et la production de lignes directrices concernant la conduite des activits de dveloppement des nouveaux systmes ;

Echec des projets

infrastructure technologique :
l'actuelle infrastructure technologique l'intrieur de l'organisation n'a pas t value 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 dcisions des moments cls est essentielle, mais elle a t dlgue aux experts techniciens ou diffre ;

augmentation du cot et de la dure d'achvement :

ils sont symptomatiques de problmes srieux sous-jacents et doivent attirer l'attention des seniors.

10 risques majeurs dun projet

Risques encourus et classement Mesures prventives Analyse de lorganisation Analyse des missions Revue Prototypage Rdaction anticipe des manuels utilisateurs Analyse des tches Prototypage Prise en compte de lutilisateur (fonction, comportement, charge de travail) Simulation Essais comparatifs Modlisation Prototypage Instrumentation Rglages Analyse technique Vrification a priori des performances Analyse des cots Risque n3 Dveloppement de logiciels impropres satisfaire les besoins

Ouvrage

Risque n4 Dveloppement de mauvaises interfaces pour les utilisateurs

Risque n9 Dfaillance des performances en temps rel

uvre

Risque n10 Blocage sur les limites technologiques des plates-formes

Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1, 32-41.

10 risques majeurs dun projet

Risques encourus et classement Mesures prventives Structuration de lquipe Redistribution des rles Renforcement de lencadrement Formation, entraide, motivation Recoupement de plusieurs estimations dtailles des charges, des cots et des plannings Remise en cause des demandes Dveloppement incrmental Rutilisation de logiciel Examen critique des spcifications Prototypage Calcul des retours sur investissement Seuil dacceptation des changements Dveloppement incrmental Report des modifications en fin de projet Mise en concurrence Contrle des rfrences Analyse de compatibilit Inspection et recette Contrle des rfrences Audit de qualification Structuration de lquipe Ressources Risque n1 Inaptitude du personnel

Planification

Risque n2 Prvisions trop optimistes, sousestimation des budgets

Risque n5 Perfectionnisme Risque n6 Contrat continu de modifications Suivi Risque n7 Dfaillance des fournitures externes

Risque n8 Dfaillances des travaux sous-traits

Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1, 32-41.

Incertitude des projets

Concevoir un systme dinformation efficace suppose une connaissance prcise 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 systmes dinformation doit donc prendre en compte le contexte dincertitude

Incertitude des projets

Facteurs situationnels, gnrateurs dincertitude dus au systme dinformation final attitude hostile des utilisateurs faible comptence des utilisateurs instabilit de lenvironnement dfaut de formalisation des informations dfaut de formalisation des processus instabilit des informations et des processus caractre trop spcifique du systme incomprhension des spcifications importance stratgique excessive lourdeur des changements organisationnels indisponibilit, confusion, instabilit des exigences importance des changements technologiques nouveaut de la technologie cible innovation technique, indisponibilit technique

dus au systme informatique dus la technologie du projet

dus la planification
dus la structure du projet

nouveaut de ladaptation, dlais trop courts, budget serr

incomptence de lquipe projet dpendance de la sous-traitance dpendance envers dautres adaptations du systme dinformation flou du contexte client-fournisseur

Incertitude des projets

Cinq sources principales dincertitude viennent affecter lefficacit des choix des concepteurs :
les caractristiques de la tche effectuer, son degr de structuration, les prescriptions auxquelles elle est soumise, le degr de complexit que sa ralisation suppose ; lestimation des ressources informatiques ncessaires, lanticipation de la performance utile ; lexprience de lquipe charge de dvelopper le systme par rapport aux tches effectuer, sa stabilit, la possibilit de recours des consultants extrieurs ; la capacit de lentreprise prendre des dcisions, les priorits de la direction ; lexprience des utilisateurs par rapport la ralisation de leur tche lutilisation des systmes dinformation.

Bernier C, Rivard S. Grer lincertitude dans le dveloppement des projets de systmes dinformation. Gestion, 2000, mai, 47-54.

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. Grer lincertitude dans le dveloppement des projets de systmes dinformation. 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.

Consquence des erreurs

Besoins des utilisateurs (phnomnes du monde rel) Expression des besoins Spcifications correctes des besoins Conception Architecture base sur des spcifications errones Spcifications errones des besoins

Architecture correcte

Architecture errone

Implmentation Code correct Erreurs de code Code bas sur une architecture errone Test Code bas sur des spcifications errones

Fonctions correctes

Erreurs corrigibles

Erreurs non corrigibles

Erreurs caches

Systmes logiciels imparfaits

Cot des corrections

Activit Processus Expression des besoins Conception Implmentation Test Exploitation Maintenance Cot relatif de rparation 0,1 0,2 0,5 1 2 5 20

plus une erreur est dtecte tard dans le processus de dveloppement de systmes logiciels, plus les corrections apporter sont coteuses

Boehm BW. Software Engineering. IEEE Transactions on Computers, 1976, 25, 12, 1226-1241.

En conclusion
Les projets russis ont privilgi de faon stratgique :
Une dfinition claire des spcifications du systme Une forte implication des utilisateurs Un appui de la Direction Des plans minutieux et dtaills du projet Un chancier de travail et jalons ralistes

En conclusion
Finalement, cette tude dtaille des risques dchec dun projet de SI laisse une part non ngligeable aux facteurs humains :
mauvaise comprhension de lorganisation par les analystes, implication mdiocre des utilisateurs finaux, mauvaises apprciation et formalisation des besoins des utilisateurs.

Pour un SIH, et plus spcifiquement dans sa partie clinique, les soignants et les mdecins sont les premiers concerns. A la complexit dune organisation telle quun hpital, tant sur le plan structurel que sur le plan fonctionnel, sajoute limbrication, pas forcment complmentaire, de leurs besoins individuels avec ceux des groupes de mdecins et soignants, ceux de lorganisation et ceux des patients. Tous sont des utilisateurs potentiels du systme dinformation clinique, mais ne sont pas forcment reconnus comme tels. Savoir faire le lien entre lorganisation et les utilisateurs semble tre une des conditions de russite de la mise en uvre dun systme dinformation.

Impliquer les utilisateurs

Ds la phase de conception dun SI, du point de vue du dveloppeur, les besoins de tous les utilisateurs potentiels, donc de chaque utilisateur, doivent tre satisfaits. Pour connatre ces besoins, il est ncessaire de disposer :
de mthodes pour dcrire de faon pertinente, utile et utilisable les profils des utilisateurs ; de mthodes pour effectuer lanalyse des tches, lanalyse du systme et des processus, non seulement pour les individus eux-mmes mais aussi pour les organisations dindividus ; de mthodes rapides et faciles pour rcuprer, valuer et valider les donnes fournies par les utilisateurs ; de mthodes fiables pour organiser les fonctions du systme en menus et botes de dialogues selon les donnes des utilisateurs ; dapproches permettant de connatre 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., 1993.- pp. 251-254.

Impliquer les utilisateurs

Il est important de faire en sorte que ltape de design soit participative, de faon ce que les utilisateurs sortent de leur simple rle dobservateurs, de rpertoires de connaissances ou de simples composantes du systme, pour acqurir un rle dexpert co-designers, de copropritaires, 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 dfinit les utilisateurs, ou les donnes gnres par ces utilisateurs, comme les critres avec lesquels un design est valu, ou bien comme la source gnratrice des ides 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, 1996.- pp. 161-162.

Impliquer les utilisateurs

attentes et les besoins des utilisateurs doivent tre apprcies ds les premires phases de conception :
cette difficult est-elle ncessaire ? est souvent la meilleure question possible ; la difficult peut souvent tre contourne pour atteindre simplement le rsultat ; l'environnement ou la relation avec l'environnement peut tre modifi ; une personne ayant une vision globale, un point de vue nouveau, une exprience diffrente peut rvaluer les solutions, au contraire d'une personne plonge dans son problme habituel ; une sdimentation de paperasses, programmes informatiques, procdures, rglements, peut tre remplace par une solution la fois simple et adapte l'volution des besoins ; poser constamment la question pourquoi ? peut dmanteler un problme. 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 acteurs de soins

Si la rgle dimplication des utilisateurs, ds la conception dun systme dinformation, est bien tablie, son application au domaine clinique souffre encore de nombreuses difficults. Pourtant, les contraintes de temps auxquelles sont soumis les acteurs de soins sont connues. Ainsi, une grande partie du travail des mdecins consiste rassembler, trier et classer les informations selon leur importance. Les estimations donnes vont de 20% 70% du temps Un travail du National Health Service (NHS) Information for Health Strategy, a estim quun quart du temps des mdecins et des infirmiers tait utilis pour la collecte des donnes 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, 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 acteurs de soins

Les barrires l'utilisation des nouvelles technologies de l'information au sein des systmes de prestations de soins sont plus sociologiques, culturelles et organisationnelles que technologiques. Deux facteurs freinent l'utilisation des technologies de l'information :
La structure singulire du systme de soins fait que des demandes extrmes sont formules quant aux performances des systmes d'information. L'assurance dune meilleure qualit des donnes, qui pourrait tre la base de toute utilisation des technologies de l'information pour amliorer l'efficacit et le rendement du systme de prestation des soins, est bloque par labsence d'un centrage de l'ensemble du systme sur l'amlioration des rsultats. Ceci a pour corollaire le fait que le recueil des donnes se fasse de faon 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 difficults

Considrations comportementales
Ignorance des bnfices potentiels
Il est une croyance rpandue que les mdecins sont rticents 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 intrinsque des soignants, lanxit gnre par lignorance de cette technologie, labsence dune vision globale de la faon de lutiliser, et labsence de confiance dans la stabilit des technologies de linformation applique aux soins. Limpression dchec enregistre lvocation des projets de SIH, couple au cynisme des cliniciens sur la dfinition des priorits de traitement de linformation sont considrs par le NHS comme la principale difficult au dveloppement et limplantation de stratgies dinformation Les cliniciens apprcient-ils le bnfice potentiel des technologies de linformation ? Il apparat que non, et nous devons nous assurer que cette sensibilisation fait partie intgrante de la conception et de limplmentation dun systme centr sur le patient. Une tude europenne (Eductra) a conclu que les professionnels de soins manquaient gnralement de connaissance quant aux possibilits et aux limites des systmes informatiques.

Origine des difficults

Considrations comportementales
Crainte du partage, de la perte dautonomie et du changement
La technologie est souvent dcrite comme un outil facilitant le partage des soins. Le manque de confiance entre les personnes est un obstacle pour atteindre cet objectif de soins partags. Ceci peut venir du fait que la formation des professionnels ne met pas assez en avant le travail pluriprofessionnel. La crainte des systmes dinformation chez les professionnels de sant est lie un sentiment de perte dautonomie. La crainte de multiples changements sur lesquels les mdecins ont peu de contrle peut tre un facteur de rejet des systmes dinformation. Ainsi, le comportement des cliniciens et leur rsistance limplantation dapplications cliniques pourrait-il expliquer le manque de succs des systmes en routine. Cependant, contrairement une croyance, il ny a pas de rponse fixe et attendue des mdecins, et les chercheurs sintressent particulirement aux dimensions comportementales. La modlisation des processus dentreprise peut faciliter la spcification des aspects structurels et comportementaux au sein dun hpital. Lvolution des cliniciens vers la gestion coordonne des soins et la matrise des cots, peut aussi tre un facteur de progrs.

Origine des difficults

Difficults lies lanalyse des besoins
Incapacit identifier et dfinir les besoins
Problme majeur qui a rarement t trait avec succs. Bien que limportance de limplication des utilisateurs soit reconnue, la collecte et la formalisation des besoins des utilisateurs finaux ne sont pas bien dcrites et souvent mme ngliges dans les projets de dveloppement logiciel. Manque dtudes sur le type de support informatique ncessaire, sur la dtermination des fonctions, dont lautomatisation bnficiera plutt aux mdecins, et sur les raisons de lchec court terme des systmes. Le manque de succs des premiers systmes de saisie de prescriptions ou de retour des rsultats auprs des cliniciens semble d au fait quils avaient dabord t conus pour rpondre des besoins de gestion financire. Ceci a permis de mettre en lumire limportance dune conception guide par la comprhension dtaille des processus de soins du patient, et non dune conception guide par lanalyse spare des tches individuelles par mtier. Une autre raison de lchec des SI tre intgrs dans la pratique mdicale quotidienne est quaucune analyse cible na t faite sur les besoins en information des mdecins. Le dveloppement de linformatique mdicale a t domin par des considrations technologiques. Le personnel mdical est peu outill pour dcrire de tels besoins, alors quil est daccord sur la manire de dlivrer les soins au patient. La tche didentification des besoins des utilisateurs doit tenir compte de cela.

Origine des difficults

Difficults lies lanalyse des besoins
Non prise en compte de lorganisation du travail
Les systmes ne peuvent pas tre dvelopps sans prendre en considration lenvironnement dans lequel ils devront fonctionner. Ceci est particulirement vrai pour les systmes cliniques o la tendance croissante est celle dun environnement de soins partags. Il y a une croyance de plus en plus rpandue selon laquelle la solution au problme dune bonne informatisation de la pratique clinique repose plus sur des ralits politiques que technologiques. Les rsultats dune tude pour dterminer les raisons qui font quun SIC russit ou choue, ont rvl que lexcellence ou non du systme technique informatique navait quune importance relativement faible. Lensemble du SIC doit en effet intresser toutes les structures participant aux processus cliniques, et leurs acteurs.

Origine des difficults

Considrations mthodologiques
Incapacit faire correspondre modles de travail et processus cliniques
Quelles que soient les avances offertes par les systmes dinformation cliniques, ils reprsentent encore un changement dans la faon de travailler en pratique clinique. Aussi le systme ne doit-il pas seulement permettre une meilleure saisie ou une meilleure recherche de donnes mais doit galement correspondre aux processus ou aux situations de soins en cours pour un patient. Lintgration dans les pratiques de travail reste linquitude majeure des cliniciens. Linformatisation des donnes mdicales doit encore progresser pour paratre encore plus naturelle aux cliniciens. Persistance de lopposition entre la saisie contrle de donnes, qui facilite le travail informatique, et lentre de donnes en texte libre, qui correspond mieux lutilisateur.

Origine des difficults

Considrations mthodologiques
Conception du systme, dmarche dimplmentation
Une dmarche de conception et dimplmentation prenant en considration le couple clinicien / patient dtermine le succs ou lchec du projet. le grand dfi pour la prochaine dcennie 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 faon faire quasiment disparatre linterface physique. Cest l que se trouve le secret de la conception des interfaces : les faire disparatre (Ngroponte) Trs peu de systmes rpondent cet idal et il peut tre opportun damliorer les dmarches de conception et dimplmentation. Les stratgies de formation doivent tre centres sur le dveloppement 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 systmes. nous devons concevoir des systmes autour des patients et non autour de la technologie. Nous devons parler de serveurs patients et non de clients serveurs . (Safran)

Origine des difficults

Considrations technologiques
Il existe des preuves qui soutiennent le fait que la technologie, en ellemme, nest pas un facteur limitant prpondrant. Cependant, certains auteurs pensent quil existe un srieux point de divergence, en sant, entre les besoins de lorganisation et les solutions techniques qui les supportent. Les consquences de cet tat de fait sont que :
les technologies de linformation ne sont pas le noyau oprationnel en sant les pressions organisationnelles et les pressions externes laissent la technologie loin derrire 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 dcole et restent abstraites dans la pense des acheteurs et des professionnels ; le profil des affaires ne correspond pas au profil informationnel, et ces deux sont eux-mmes assez diffrents du profil technologique ; le secteur industriel lui-mme est aussi lent au changement.

Reconnatre lacteur de soins

Prrequis limplmentation des systmes centrs sur les patients
Propositions pour amliorer limplication des cliniciens pour arriver finalement une perception relle et gnralise des bnfices des SI :
la reconnaissance par les gestionnaires de soins de limportance dune technologie de linformation centre sur les patient pour le futur des services de soins ; la ncessit de ne pas mconnatre limplication des mdecins, le besoin de traiter les problmes de faon honnte et transparente, dautant que les cliniciens ont la relle volont dutiliser les technologies de linformation pour la dlivrance des soins ; le besoin de faire en sorte que les dveloppeurs comprennent les problmes cls de linformatique mdicale en travaillant troitement avec les cliniciens ; lutilit de former les cliniciens aux avantages et aux inconvnients des techniques informatiques ; le fait de traiter les problmes qui concernent les cliniciens avec eux, comme par exemple la scurit des accs aux donnes confidentielles du patient ; limportance de reconnatre linvestissement des cliniciens participant au dveloppement des projets et de mettre en avant les leaders mdicaux : leur implication aidera promouvoir lappropriation et lengagement dans le processus dimplmentation ; le fait daccepter que la technologie ne soit quun facteur parmi dautres. Les facteurs critiques pour le succs dun systme sont limplication des gens, le fait que lorganisation soit prte accepter le changement et la gestion de ce processus de changement.

Reconnatre lacteur de soins

Analyse des besoins des utilisateurs du domaine de la sant
Le travail dun professionnel de sant est caractris comme :
1) tant un processus dirig par le problme ; 2) impliquant la conduite de multiples tches concurrentes ; 3) ncessitant une interaction avec plusieurs sources et cibles informationnelles (certaines humaines, dautres informatises) ; 4) tant sujet de frquentes modifications, rsultant dactions de surveillance, de changements dobjectifs, ou de rvision de la stratgie.

La plupart des applications ont t cibles pour fournir un support vertical des tches spcifiques, voire isoles. Alors que ces applications ont inclus des fonctions comme linterrogation de donnes cliniques, laide la dcision, lducation et la communication, elles ont gnralement t ralises de faon isole, sans tre relies les unes aux autres, pour satisfaire les situations de rsolution de problme multidisciplinaires et pluriprofessionnelles rencontres dans la pratique mdicale actuelle.

Systme multi-utilisateurs
Problmes rencontrs au cours de la phase de design dun systme multiutilisateurs sont pour lessentiel :
la concurrence : plusieurs personnes ont besoin de la mme information ou ressource (station de travail, par exemple) au mme moment ; la dpendance temps-personne : linformation fournie une personne nest pas disponible quand elle est demande par une autre personne (de faon analogue, une tche effectue par une personne dpend dune autre tche effectue par une autre personne qui ne la pas encore acheve) ; la dpendance temps-lieu : linformation nest pas disponible lendroit souhait, au moment souhait ; la mauvaise diffrenciation des rles : dun point de vue informationnel, les fonctions du systme sont adaptes, mais lorganisation des fonctions en termes de qui ralise des tches particulires nest pas adquate ; lchec dans lidentification de tous les participants dune tche : le design du systme, alors quil accommode les principaux rles dune tche, ne prend pas en compte le rle des autres personnes qui interviennent occasionnellement (gnralement pour apporter de laide) ; le manque danalyse raisonne : aucune analyse des pratiques de travail nest ralise.

Systme multi-utilisateurs
Linformation ncessaire au design dun systme collaboratif doit rpondre aux huit questions suivantes :
quelle est la tche ? identifie le but du travail ; pourquoi est-elle ralise ? permet de distinguer les pratiques de travail critiques pour accomplir lobjectif de celles qui ne le sont pas ; qui effectue cette tche ? facilite la dtermination des rles ; comment est-elle ralise ? spcifie le dtail du travail dun individu ; quand est-elle ralise ? identifie les dpendances dans le temps et les concurrences ; avec quoi est-elle ralise ? identifie linformation et les procdures ncessaires, value la concurrence des ressources ; o est-elle ralise ? identifie les dpendances et les concurrences temps-lieu ; que se passe-t-il ensuite ? identifie les concurrences pour les personnes et linformation.

Systme multi-utilisateurs
Les dtails des pratiques de travail contenus dans les rponses aux questions prcdentes peuvent tre utiliss pour crer des reprsentations, au niveau de lorganisation, qui se rapportent des interactions telles que :
de qui ou de quoi dpend la tche ? qui ou quoi dpend de cette tche ? qui dautre a besoin des ressources utilises pour cette tche, ce moment-l ? comment les pratiques de travail dcrites contribuentelles aux objectifs de lorganisation ?

En conclusion
Une large implication des mdecins dans la slection et limplmentation du systme est essentielle. Les systmes sans rel soutien de la part du personnel mdical sont promis lchec. Une des meilleures stratgies est de sassurer de lassistance de mdecins influents pour encourager dautres membres du personnel mdical utiliser le systme dans leur pratique.

En conclusion
Considrer lavance la faon dont le systme qui va tre introduit va affecter les modes de pratique et les relations professionnelles. Il est important didentifier les bnfices spcifiques que le SI apporte aux individus et aux groupes professionnels. Les mdecins utiliseront le SI sil les aide mieux prendre en charge les patients. Les bnfices pour lorganisation en gnral ne motiveront pas les mdecins changer leurs habitudes de travail.

En conclusion
Les tablissements de sant doivent anticiper et grer les changements de comportements et dorganisation induits par lintroduction dun SIC intgr. Si ces changements, qui ont t montrs comme inhibiteurs de ladoption et de lutilisation des systmes informatiss, sont ignors, on peut sattendre un chec du systme ou des effets fortuits. Ces problmes peuvent tre vits ou diminus en anticipant la faon dont les groupes professionnels vont percevoir un nouveau SI. La communication dans les groupes concerns par limplmentation du systme est un moyen didentifier et de rsoudre des problmes potentiels qui, sils restent non rsolus, peuvent contrarier lacceptation et lutilisation du systme.

Recueillir linformation
Durant la phase danalyse, collecte dune trs grande quantit dinformations
auprs des personnes qui utiliseront le systme
Soit en les interviewant Soit en les regardant travailler

en lisant les documents de planification, les procdures, les exposs de principes, la documentation du systme existant en regardant ce qui a t fait dans dautres entreprises pour rpondre un besoin semblable (benchmarking)

parler toutes les personnes qui se serviront du systme ou ont utilis un systme similaire, lire tout ce qui existe sur le systme actuel

Recueillir linformation
Lanalyste doit devenir un expert du domaine que le systme supportera Lanalyse doit aussi recueillir de linformation technique pour comprendre le systme existant :
En identifiant et en comprenant les activits de tous les utilisateurs prsents et venir En identifiant tous les lieux actuels et futurs o le travail seffectue En identifiant toutes les interfaces dautres systmes lintrieur comme lextrieur de lorganisation

la question essentielle : est-ce que nous avons toute linformation (et la connaissance) dont nous avons besoin pour dfinir ce que le systme doit faire ? Pour qui, pourquoi, quand et comment ?

Prioriser les spcifications

Etablir quelles sont les spcifications fonctionnelles et techniques vitales pour le systme Les utilisateurs proposent beaucoup de fonctionnalits souhaitables / souhaites mais pas essentielles Utilisateurs et analystes doivent se demander ensemble quelles sont les fonctions vitales et celles importances mais non requises La priorisation est ncessaire car les ressources sont limites et un champ de spcifications qui augmente mesure que les utilisateurs font des suggestions devient un risque dchec du projet quelles sont les choses importantes que le systme doit faire

Pour un SIH ?
Un analyste peut-il tre tranger au dispositif mtier ? Sa connaissance ne peut-elle tre quextrieure ? En quoi une expertise mtier est-elle ncessaire ? La plupart des analystes consultants des SIH sont issus des mtiers de lhpital, MAIS

Les intervenants
Dfinition : toutes les personnes qui sont concernes par la russite du nouveau systme Quatre catgories :
Les utilisateurs, soit ceux qui utilisent le systme tous les jours Les clients, soit ceux qui paient pour le systme et en sont propritaires Le personnel technique, soit les personnes qui sont responsables du fonctionnement du systme dans lenvironnement de lorganisation Les entits extrieures, tels les clients de lorganisation

Mthodes de cueillette
Distribuer les questionnaires Interviewer les utilisateurs Etudier la documentation existante Observer les procds administratifs Rechercher des solutions auprs de fournisseurs Comprendre les contraintes du nouveau systme

Comprendre les procdures du nouveau systme

Dvelopper les spcifications et les modles pour le nouveau systme

Comprendre les fonctions du nouveau systme

Thmes de la cueillette
Thme
Quels sont les oprations et les procds administratifs Comment ces oprations doivent-elles seffectuer ?

Questions aux utilisateurs

Que faites-vous ? Comment le faites-vous ? Quelle dmarche suivez-vous ? Quelles informations utilisez-vous ? Quels formulaires ou rapports utilisezvous ?

Quelles informations faut-il pour raliser ces oprations ?

Techniques de cueillette
Examiner les rapports, formulaires et descriptions de procdures existantes Animer des entrevues et des discussion avec les utilisateurs Observer et documenter les procds administratifs Construire des prototypes Distribuer et ramasser des questionnaires Animer des sances de dveloppement conjoint dapplications Etudier des solutions proposes par des fournisseurs

Expression des besoins

processus dexpression des besoins dfinit les trois activits suivantes :
lactivit dacquisition des besoins : cette activit, galement appele identification des besoins, ou analyse du problme, ou bien recueil des besoins, ou encore documentation des besoins, consiste collecter sous forme informelle lensemble des besoins qui permettront datteindre une bonne comprhension du systme. Cest lactivit durant laquelle lingnieur des besoins dcouvre, corrige, articule, et comprend les besoins. lactivit de conceptualisation des besoins : cette activit, galement appele spcification des besoins, ou description du produit, ou bien formalisation des besoins, ou encore expression des besoins, consiste exprimer les besoins acquis lissue de ltape prcdente, laide dun formalisme intgrant un certain nombre de concepts graphiques et/ou mathmatiques. lactivit de validation des besoins : cette activit, galement appele analyse du problme et des besoins, ou analyse et validation des besoins, ou bien validation des besoins, ou encore discussion des besoins, consiste sassurer que les besoins conceptualiss traduisent de manire complte et cohrente les dsirs, les contraintes, et les volonts du client.

Problmatique
des problmes de dimensionnement, pour lesquels les exigences peuvent concerner trop peu ou beaucoup trop dinformation :
les limites du systme sont mal dfinies, des informations non ncessaires pour la conception sont donnes.

des problmes de comprhension aussi bien lintrieur dun groupe quentre groupes dutilisateurs ou de dveloppeurs :
les utilisateurs ont une comprhension incomplte de leurs besoins, les utilisateurs ont peu de connaissance sur les possibilits et les limites des systmes informatiques, les analystes ont une connaissance trs faible du domaine dintrt, utilisateurs et analystes sexpriment dans des langages diffrents, il est facile domettre des informations videntes, il existe des vues conflictuelles entre diffrents utilisateurs, les besoins exprims sont souvent vagues et peu vrifiables.

des problmes dinconstance et dvolution des besoins avec le temps.

Guide
Questions quels documents sont utiliss dans le systme ? Objets document Exemples questionnaires, instructions, rapports, produits intermdiaires, manuel de rfrences, etc.

qui / quoi reoit le document ?

qui / quoi labore le document ? quelles sont les ressources utilises pour laborer le document ? quels sont les vnements lorigine de la cration du document ? Questions quelles sont les diffrentes parties du document ? quels sont les lments de base de lobjet ?

destinataire
crateur ressource vnement

client, membre du personnel, dpartement de lentreprise, organisation extrieure, etc.

employs, fournisseurs, quipement comme les ordinateurs, etc. argent, matire premire, documents de rfrence arrive du moment de la paie mensuelle, arrive dune commande de client Caractristiques dcrites attributs

que fait le crateur ou le destinataire avec les items du document ? comment fait la ressource ou lvnement pour fournir linformation pour crer le document ? que fait le destinataire pour accepter le document ? que fait le crateur pour fournir le document ?

mthodes mthodes

mthodes mthodes

Jeux de rles
Gestion de son compte bancaire par Internet
Quels intervenants ? Quelles questions ?

Gestion de son compte sant par Internet

Quels intervenants ? Quelles questions ?

Question
Lun des problmes les plus ardus de linvestigation des spcifications dun systme est de sassurer quelles sont compltes et dtailles. Que feriez-vous pour vous garantir dobtenir toutes les bonnes informations lors dune entrevue ?

Rponse
Les rponses devraient inclure les points suivants :
Sassurer davoir identifi tous les intervenants et de les avoir inclus dans les activits de dfinition des spcifications. Examiner tous les formulaires et rapports existants pour vrifier que tous les besoins dinformation sont compris. Identifier et comprendre chaque activit de gestion. Sassurer que toutes les procdures administratives ont t discutes. Sassurer que toutes les conditions dexception ont t identifies et leurs champs associs dfinis. Maintenir une liste des articles ouverts et sassurer que tous les lments sont rsolus.

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

Rponse
Une mthode 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 ncessaires peut tre cr en fonction de la porte du systme. Il y a plusieurs faons de vrifier votre liste :
(1) la revoir avec le client principal (le groupe qui assure lapprobation et le financement du projet); (2) la vrifier avec le comit de surveillance du projet; (3) la revoir avec le chef du groupe des systmes dinformation ou avec toute autre personne qui matrise bien les systmes.

Question
Un des problmes communs lors dune investigation est le glissement de la porte du systme, cest--dire des demandes de fonctions additionnelles de la part des utilisateurs. Ce glissement survient parce quil arrive que les utilisateurs aient de nombreux problmes non rsolus et que cette investigation reprsente peut-tre pour eux la premire occasion de se faire entendre. Que devez-vous faire pour empcher que le systme grossisse et comprenne des fonctions qui ne devraient pas en faire partie ?

Rponse

Ce problme est essentiellement une question de gestion de projet. Le chef de projet devrait tablir des lignes directrices pour le contrler. Une mthode prventive consiste sassurer que la dfinition initiale de la porte est convenable et complte. Une dfinition incomplte exacerbera le problme de glissement de la porte. Si la porte du systme a t dfinie adquatement au dpart, une faon de rgler le problme de glissement est de mettre sur pied un comit form de membres de lquipe de projet et dutilisateurs ou de clients qui devra approuver tout nouvel ajout la porte du systme. Avant approbation, il faudra faire une valuation pour dterminer la pertinence et limportance de la demande et son effet sur le calendrier du projet. Demandez la participation des utilisateurs la dcision afin que celle-ci soit une dcision conjointe et non un diktat du chef de projet. Une autre technique consiste commencer une liste des amliorations pour la prochaine version du systme. Certaines demandes peuvent en effet tre reportes une version ultrieure.

Question
Que feriez-vous si deux personnes vous donnaient des rponses contradictoires sur une mme procdure ? Que feriezvous si lune des personnes tait membre du personnel de bureau et que lautre tait son chef de service ?

Rponse
La premire raction serait de considrer lopinion du chef de service comme tant la bonne rponse. Toutefois, il est assez frquent quun chef de service ne soit pas au courant des derniers dtails de certaines procdures de gestion. La meilleure solution, dans ce cas, consiste runir deux personnes et les laisser discuter jusqu ce quelles sentendent sur la bonne procdure. Il importe que la dcision ne vienne pas de lanalyste. Il est aussi important de ne pas essayer de rsoudre les divergences vous-mmes : cela incombe lutilisateur.

Question
On vous a donn la responsabilit de rsoudre plusieurs problmes en suspens et vous prouvez des difficults obtenir des dcision stratgiques de la part de votre contact. Comment pouvez-vous encourager lutilisateur finaliser ces dcisions ?

Rponse
Une question dopinion pineuse qui offre plusieurs rponses. En rgle gnrale, les retards prendre des dcisions stratgiques ont des effets importants sur le calendrier dun projet et il arrive que lutilisateur ne comprenne pas ces impacts. La premire approche devrait donc tre dexpliquer leffet ngatif quune dcision donne peut avoir sur le projet. Si cela ne fonctionne pas, il est possible de prendre des mesures plus radicales, comme suggrer que le comit de surveillance du projet examine la liste des questions en suspens. De plus, si cette liste inclut une indication de la dure pendant laquelle des lment ont t ouverts, il est possible dattribuer une priorit (ou daugmenter la priorit) des lments qui deviennent critiques.