Professional Documents
Culture Documents
Pascal Staccini
PARTIE 1
Dveloppement
Cycle chronologique Facteurs de risque
Echec des projets 10 risques majeurs dun projet Incertitude des projets
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 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.
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 ;
Ouvrage
uvre
Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1, 32-41.
Planification
Risque n5 Perfectionnisme Risque n6 Contrat continu de modifications Suivi Risque n7 Dfaillance des fournitures externes
Boehm BW. Software risk management: principles and practices. IEEE Software, 1991, 8, 1, 32-41.
dus la planification
dus la structure du projet
Bernier C, Rivard S. Grer lincertitude dans le dveloppement des projets de systmes dinformation. Gestion, 2000, mai, 47-54.
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.
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 caches
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.
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.
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.
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.
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 ?
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
Thmes de la cueillette
Thme
Quels sont les oprations et les procds administratifs Comment ces oprations doivent-elles seffectuer ?
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
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.
Guide
Questions quels documents sont utiliss dans le systme ? Objets document Exemples questionnaires, instructions, rapports, produits intermdiaires, manuel de rfrences, etc.
destinataire
crateur ressource vnement
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 ?
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.