Logo ANAP
Ce site requiert l'activation de javascript pour être utilisé, merci de l'activer.
S'abonner

Méthode

 11320 vues

L'objectif de cette phase est d'identifier, à partir de l'existant analysé et décrit au début de la démarche, les évolutions nécessaires pour disposer d'un système d'information qui soutiendrait au mieux la stratégie de l'établissement. Elle prend en compte les contraintes de performance liées à l'activité de l'établissement et à son environnement (contexte réglementaire, rôle et caractéristiques des partenaires, etc.).

Cette phase comprend 3 étapes :

  • Etape 1 : Définition de l'architecture métier cible :
    • Comment doit évoluer le fonctionnement de l'établissement pour répondre au mieux à ses objectifs opérationnels en tenant compte des besoins des utilisateurs, des opportunités et des contraintes contextuelles ?
    • Quelle(s) amélioration(s) doit(vent) être apportée(s) aux activités métier concernées (cf. architecture métier)
    • Quelle(s) fonction(s) du système d'information a-t-on besoin de développer ?
  • Etape 2A : Identification des principes directeurs d'urbanisation
    • Compte tenu de l'existant en matière d'applications et d'infrastructure technique (matérielle) et pour répondre aux objectifs fixés en matière d'évolution et d'exploitation du système informatique (évolutivité, niveau de sécurité, coûts de maintenance, interopérabilité, etc.) quelles règles doit-on définir pour cadrer au mieux les évolutions du système d'information ?
  • Etape 2B : Définition de l'architecture fonctionnelle cible :
    • Compte tenu de l'existant, des besoins fonctionnels exprimés par l'analyse métier, et des principes directeurs du système d'information, vers quelle architecture fonctionnelle le système d'information existant (décrit au cours de l'étape 2 de la phase 1) doit-il évoluer ?

Sous-chapitres :

  • 7.1.

     

    Pré requis

    Disposer d'une description de l'architecture métier existante (cf. Phase 1 - Etape 1 : Analyse de l'architecture métier existante)

    Avoir identifié les facteurs d'évolution stratégique de l'architecture métier (cf. Phase 2 : Prise en compte des objectifs de l'établissement)

    Objectifs

    Prendre en compte l'ensemble des facteurs d'évolution des processus métier pour construire la vision métier du système d'information cible.

    Identifier les besoins fonctionnels associés aux besoins d'évolution et d'amélioration des processus métier.

    Acteurs

    Responsables métier (porteurs des objectifs opérationnels et exprimant les besoins) :

    • Responsables de pôle ou de service, utilisateurs médicaux, soignants et paramédicaux ;
    • Acteurs en charge de l'évolution SI (maîtrisant les possibilités de la technologie) : membres de la DSIO, cellule urbanisation.

    Démarche

    Traduire l'impact des objectifs opérationnels sur chaque tâche en identifiant avec les responsables métiers :

    • Les éléments de contexte liés à la tâche et propres à induire une évolution de cette tâche (contrainte ou évolution réglementaire, nouveau partenaire, nouvelle compétence, réorganisation, etc.) ;
    • Les thèmes de progrès de chaque tâche en cohérence avec les objectifs opérationnels, les besoins des utilisateurs et les éléments de contexte associés à cette tâche : Comment doit évoluer cette tâche pour répondre aux objectifs opérationnels en tenant compte du contexte ?

    Traduire chacun des thèmes de progrès par des évolutions de l'architecture métier (une tâche peut être supprimée, ajoutée, réalisée par un acteur différent, réalisée différemment, etc.) et/ou par des besoins fonctionnels.

    Pour chaque tâche, les fonctions susceptibles de répondre aux thèmes de progrès identifiés sont :

    • Des fonctions qui aident l'utilisateur à obtenir les informations nécessaires à la tâche (C'est-à-dire les informations identifiées dans l'architecture métier sous la forme de messages entrants de la tâche) ?
    • Des fonctions qui aident l'utilisateur à produire et/ou communiquer les informations résultats (C'est-à-dire les informations identifiées dans l'architecture métier sous la forme de messages sortant de la tâche) ?

    Exemples :

    • Besoin d'une fonction d'accès personnalisé au dossier patient pour la tâche « examiner le patient » ;
    • Besoin d'une fonction de transmission électronique de l'ordonnance à la pharmacie pour automatiser la tâche « transmettre » ;
    • Besoin d'une fonction d'authentification du prescripteur pour la tâche « prescrire ».

    Documents produits

    Modélisation des processus métier cible.

    Besoins fonctionnels (identifiés dans le tableau de recensement et de description de l'architecture métier cible).

    Clôture de l'étape

    Fiches descriptives métier complétées et validées.

    Cartographie métier validée.

    Facteurs de succès et risques

    Travailler dans la continuité de l'étude de l'existant en utilisant comme base de travail les résultats de l'étape 1.1 (Phase 1 - Etape 1 :Analyse de l'architecture métier existante)

    Savoir adapter le niveau de détail de l'analyse :

    Les besoins fonctionnels doivent être décrits de façon suffisamment synthétique et claire pour permettre leur identification, leur compréhension et leur analyse au plus haut niveau de lecture (c'est à dire la vision du système étudié dans son ensemble).

    • Il faut pour cela savoir identifier les caractéristiques essentielles d'un besoin fonctionnel (de façon à permettre notamment son rapprochement avec un besoin similaire exprimé dans un autre contexte) ;
    • Etablir au préalable une typologie limitative des fonctions identifiables dans le cadre de l'architecture peut être utile (exemples de types de fonction : Création, mise à jour, consultation, recherche, édition, etc.).

    Références

    [2] Exemple d'architecture métier d'un système de prise en charge du patient en unité clinique SI35MOD

    [5] Tableau de description des éléments d'un système d'information SI35MFAP

    [11] Guide méthodologique pour l'Alignement Stratégique du Système d'Information SI32MEG (cf. méthode d'évaluation du niveau de priorité d'un besoin fonctionnel)

  • 7.2.

    Pré requis

    La stratégie de l'établissement a été définie et s'est déclinée notamment au niveau de la Direction des Systèmes d'Information (les axes stratégiques ont été identifiés et traduits en objectifs opérationnels).

    Objectifs

    Il s'agit de prendre en compte les objectifs opérationnels propres au métier de la gestion du système d'information. L'objectif de cette étape est de traduire ces objectifs sous la forme de principes directeurs de l'urbanisation du système d'information.

    Les objectifs à prendre en compte à ce niveau peuvent être très variés et dépendent directement la stratégie de l'établissement ; ce pourrait être, par exemple :

    • Améliorer l'interopérabilité des systèmes ;
    • Ouvrir le système d'information sur l'extérieur ;
    • Unifier les référentiels d'informations ;
    • Améliorer la sécurité du système d'information;
    • Unifier le poste de travail ;
    • Améliorer la qualité de service;
    • etc.

    Acteurs

    • Direction Générale ;
    • DSI, DSIO, DIM, cellule urbanisation ;
    • Responsables d'applications (au sein de la DSI/DSIO), responsable architecture technique, responsable intégration ;
    • Acteurs du service informatique : Exploitants (applicatifs, réseaux), service bureautique, gestionnaire de parc (matériel, applicatif), etc.

    Démarche

    Cette étape doit être initialisée lors des travaux d'élaboration du projet d'établissement (réflexion stratégique). De la même façon que cela a été fait par chacune des directions métier (cf. §6 Phase 2 : Prise en compte des objectifs de l'établissement), il s'agit ici de traduire les axes stratégiques de l'établissement en objectifs opérationnels pour la gestion du système d'information.

    Les impacts de chacun de ces objectifs opérationnels sont ensuite décrits sous la forme de règles ou principes d'urbanisation.

    Les objectifs opérationnels suivants, par exemple, peuvent être déclinés ainsi :

    Améliorer l'interopérabilité des systèmes :

    La prise en compte de l'interopérabilité doit amener à définir de nombreux principes d'urbanisation tels que, par exemple :

    • La définition d'un cadre d'interopérabilité ;
    • Le choix d'une architecture d'intégration.

    Les conséquences de l'application de ces principes directeurs sur la démarche d'urbanisation concerneront essentiellement l'évaluation de l'existant et la définition de la trajectoire de migration :

    • Une application existante peut par exemple être considérée comme obsolète si elle n'est pas en mesure de proposer facilement une interface respectant les principes d'interopérabilité (standards d'échanges, etc.) ;
    • Lors de la phase de définition de la trajectoire de migration (cf. paragraphe « 8. Phase 4 : Trajectoire de migration »), un projet de mise en place d'une solution d'intégration, par exemple, peut être identifié.

    La prise en compte de l'interopérabilité est décrite de façon plus complète dans le guide d'interopérabilité joint à l'étude (cf. [7] ).

    Ouvrir le système d'information sur l'extérieur :

    Evoluer vers un système d'information ouvert est un objectif général qui peut se décliner ainsi :

    • Améliorer l'interopérabilité (cf. objectif ci-dessus) afin de favoriser les échanges avec les systèmes partenaires externes ;
    • Favoriser une architecture de services (cf. [7] Interopérabilité et urbanisation Eléments de définition SI35INT § 3.2.3) lors des choix d'évolution du système d'information afin de faciliter à la fois l'utilisation de services externes proposés par un système partenaire (exemple : Service de commandes automatisées proposés par un fournisseur) et l'utilisation par un système partenaire de services offert par le système de l'établissement (exemple : Service de publication d'informations à destination des réseaux de santé) ;
    • Améliorer la sécurité du système d'information de l'établissement (cf. objectif ci-dessous) afin de permettre à des éléments externes d'accéder aux informations et aux services de ce système sans compromettre ni la qualité de service, ni l'intégrité des données, ni le niveau de confidentialité des informations.

    Les principes directeurs établis sur cette base, pourront être nombreux et divers. Ils impacteront la démarche d'urbanisation à trois niveaux :

    • Lors de l'identification des besoins fonctionnels (des fonctionnalités améliorant la sécurité devront être prévues telles que l'authentification, la gestion d'un annuaire des utilisateurs, la gestion des droits et habilitations, etc.) ;
    • Lors de l'évaluation de l'existant applicatif ;
    • Lors de l'identification des projets d'évolution du système d'information (trajectoire de migration).

    Unifier les référentiels d'informations :

    Le besoin d'unification des référentiels est souvent déjà la traduction d'un objectif plus général d'amélioration de la cohérence et de la fiabilité des données du système d'information. Cet objectif peut se traduire plus précisément par quelques principes :

    • Identifier les principaux objets métier du système d'information et définir leur périmètre d'utilisation et de responsabilité au sein de ce système ;
    • Garantir l'unicité de référence de chaque objet sur son périmètre.

    Ces principes ont des impacts variés sur la démarche d'urbanisation :

    • Lors de l'identification des projets d'évolution du système et de la trajectoire de migration, il faut s'assurer au cours de chaque étape de l'unicité de la référence des objets métier et arbitrer entre les solutions permettant de la garantir : maîtrise du stockage ou maîtrise des flux.

    Améliorer la sécurité du système d'information :

    Les principes directeurs d'urbanisation découlant d'une politique de sécurité dépendent essentiellement de l'analyse du niveau de risque encouru par le système de l'établissement confronté à ses objectifs en la matière (cf. [15] Sécurité des systèmes d'information des établissements de santé – Juin 2004). Ce peut être, par exemple :

     

    • Mettre en place des services de chiffrement des flux d'informations ;
    • Mettre en place des services de chiffrement du stockage d'informations ;
    • Mettre en place des services d'authentification en amont de l'utilisation des fonctions du système ;
    • Favoriser le cloisonnement de l'information selon son niveau de sensibilité ;
    • etc.

     

    Les principes liés à la sécurité du système d'information ont des impacts variés sur la démarche d'urbanisation :

    • Des besoins fonctionnels spécifiques doivent être identifiés (fonctions de gestion des droits et profils d'accès, de gestion d'un annuaire des utilisateurs, etc.) lors de la définition de l'architecture fonctionnelle cible.
    • Des services spécifiques doivent être pris en compte par l'ensemble des projets d'évolution du système d'information (services de chiffrement, d'authentification, etc.).
    • La mise en oeuvre d'infrastructures spécifiques (pare-feu, support d'authentification, etc.) doit être prévue lors de l'identification des projets d'évolution et de la trajectoire de migration.
    • La construction de l'architecture fonctionnelle doit également tenir compte des différents niveaux de sensibilité de l'information (cf. règles de regroupement fonctionnel mises en oeuvre au cours de l'étape suivante)

    Unifier le poste de travail :

    Unifier le poste de travail utilisateur est un objectif général qui peut, par exemple, se décliner de la façon suivante :

    • Permettre à un utilisateur de réaliser les processus et/ou activités métier qui le concernent de la manière la plus continue et la plus fluide possible, quels que soient la diversité et le nombre des applications mises en oeuvre :
      • N'avoir qu'un et un seul point d'accès à ces applications;
      • Ne s'authentifier qu'une seule fois pour toutes les applications ;
      • Pouvoir conserver le contexte de travail (utilisateur, patient, etc.) lors du changement d'application (utilisation de standard) ;
      • Présenter à l'utilisateur uniquement les applications auxquelles il est habilité ;
      • Promouvoir au maximum une ergonomie constante quelle que soit l'application qu'il utilise.
    • Favoriser une architecture de services lors des choix d'évolution du système d'information.

    Ces principes directeurs, pouvant être nombreux et couvrir des champs d'action divers, influenceront la démarche d'urbanisation à trois niveaux :

    • Au niveau des processus métier et des fonctions : Identifier le contexte à conserver favorisant la fluidité des activités ;
    • Au niveau applicatif : Lors de l'évaluation de l'existant applicatif, toute application n'est pas spontanément ou facilement intégrable dans une architecture de type service. La possibilité ou la difficulté de cette intégration dépendent de sa technologie d'implémentation ;
    • Au niveau de la trajectoire de migration : Lors de l'identification des projets d'évolution du système d'information (trajectoire de migration), la capacité d'une solution à s'intégrer à une architecture de service pourrait constituer un critère de choix.

    Documents produits

    Document décrivant les principes directeurs d'urbanisation. Ce document prévoit pour chaque principe énoncé, des chapitres décrivant :

     Les objectifs opérationnels qui ont conduit à sa définition ;

    • Ses conséquences sur la définition de l'architecture cible du système d'information ;
    • La façon de le prendre en compte dans la définition des projets d'évolution du système d'information ;
    • La façon de le prendre en compte lors la préparation d'une consultation (rédaction d'un cahier des charges) et lors du choix d'une solution (éléments évaluation associés au principe).

     

    Clôture de l'étape

    Principes directeurs du système d'information validés.

    Facteurs de succès et risques

    • Savoir énoncer des principes réalistes au regard aussi bien l'existant informatique de l'établissement que de l'état de l'art.
      • Risque : Etablir une liste de voeux pieux.
    • Enoncer des principes d'urbanisation les plus concrets et opérationnels possible en précisant bien la façon de les mettre en oeuvre à chaque étape de l'évolution et de l'exploitation du système d'information.
      • Risque : Constituer une liste de « grands principes » trop généraux pour être appliqués au quotidien.
    • Savoir limiter en nombre et prioriser les différents principes en fonction de leur niveau d'alignement stratégique, de leur facilité de mise en oeuvre, du bénéfice attendu, etc. Objectif : être en mesure d'arbitrer rapidement lorsque, par exemple, une solution d'évolution favorise un principe au détriment d'un autre.
      • Risque : Constituer une liste pléthorique de règles inapplicable en pratique.

    Références

    [7] Interopérabilité et urbanisation Eléments de définition SI35INT

    [15] Sécurité des systèmes d'information des établissements de santé – Juin 2004

     

     

  • 7.3.

     

    Pré requis

    • L'architecture métier cible a été décrite et les besoins fonctionnels identifiés sur cette base.
    • Les principes directeurs d'urbanisation ont été établis.

    Objectifs

    L'objectif est de cadrer le plus précisément possible – étant donné le caractère global et amont de la réflexion – l'architecture du système d'information vers laquelle il faut tendre. Ce cadre précis, c'est l'architecture fonctionnelle du système.

    Acteurs

    • DSI, DSIO, DIM ;
    • Architecte, urbaniste ;
    • Responsables d'applications (au sein de la DSI/DSIO), responsable architecture technique, responsable intégration ;
    • Acteurs du service informatique : Exploitants (applicatifs, réseaux), service bureautique, gestionnaire de parc (matériel, applicatif), etc. ;
    • Utilisateurs des applications.

    Démarche

    Évaluer l'existant applicatif sur la base des analyses précédentes :

    • Evaluer le niveau de réponse de l'existant aux besoins fonctionnels identifiés au cours de l'étape 1. Par exemple :
      • L'application utilisée aujourd'hui pour la réalisation de cette tâche permet-elle de mettre en oeuvre les besoins fonctionnels identifiés ?
      • Le fait-elle de façon satisfaisante (du point de vue de l'utilisateur et des thèmes de progrès) ?
    • Evaluer le niveau d'adéquation de l'existant aux principes directeurs d'urbanisation et aux objectifs opérationnels de la gestion du SI. Par exemple :
      • Cette application répond-elle aux nouvelles exigences du système en matière d'interopérabilité ?
      • Le coût de maintenance de cette application est-il acceptable compte tenu des objectifs opérationnels (ce coût dépend des technologies mises en oeuvre, du nombres d'interfaces à gérer, de la fréquences des pannes, etc.) ?
    • Identifier les applications qui devront être remplacées.

    Organiser l'architecture fonctionnelle cible :

    • En s'appuyant sur l'existant pérenne : positionner les fonctions cible sur la carte applicative existante (utilisée comme fond de carte et ne présentant que les applications à conserver) ;
    • Identifier et qualifier les principaux flux d'informations interfonctionnels en mettant en évidence essentiellement :
      • Le contenu de l'information (l'objet métier principal) ;
      • La dimension du flux d'information (volume et fréquence) ;
      • La criticité du flux d'information (en fonction de la nature de l'information transmise, des contraintes en termes de délai, de qualité de la transmission, etc.).
    • Constituer les blocs fonctionnels cible (Regrouper les fonctions en blocs fonctionnels ; regrouper les blocs fonctionnels euxmêmes en blocs de plus haut niveau, etc.) :
      • En assurant autant que possible une cohérence avec l'organisation de l'architecture métier et en caractérisant l'utilisation des fonctions par rapport à cette architecture (utilisation transversale ou utilisation spécifique) ;
      • En tenant compte des contraintes de l'existant (fonctions déjà regroupées au sein d'une application ou d'un système qui doit être conservé) ;
      • En tenant compte surtout de la nature de l'information manipulée et des flux inter-fonctionnels, l'objectif étant de limiter au maximum le nombre, la dimension et la criticité des flux d'informations inter-blocs ;
      • De façon à ce que l'organisation fonctionnelle du SI soit cohérente avec les principes directeurs d'urbanisation (et avec les objectifs de l'établissement).

    Le regroupement fonctionnel peut aller jusqu'à la fusion de plusieurs fonctions en une seule répondant aux besoins de toutes si leurs caractéristiques sont suffisamment similaires et si la prise en compte des éléments d'analyse cités ci-dessus le justifie. Par exemple :

      • Identification d'une fonction de prescription unique pour répondre aux besoins de la demande d'acte, de la prescription de médicaments, etc.
    • Réévaluer l'existant applicatif sur la base des regroupements fonctionnels décidés et des éventuelles nouvelles fonctions identifiées : Identifier notamment les éléments applicatifs redondants (plusieurs applications informatisant une même fonction) et réévaluer la nécessité de les conserver

    Documents produits

    Documents descriptifs de l'architecture fonctionnelle cible :

    • Cartographie fonctionnelle ;
    • Mise à jour du tableau de description assurant la continuité entre les différents niveaux d'analyse de l'architecture (cf. [5] Tableau de description des éléments d'un système d'information SI35MFAP) :
      • Description des processus (architecture métier) ;
      • Identification des applications existantes (architecture applicative existante) ;
      • Identification des thèmes de progrès et description des besoins fonctionnels (fonctions SI) associés ;
      • Evaluation des applications existantes (niveau de réponse aux besoins fonctionnels et principes directeurs).

    Clôture de l'étape

    Architecture fonctionnelle cible validée

    Facteurs de succès et risques

    • Comme pour chaque étape de la démarche d'urbanisation, le risque de noyer l'analyse dans le détail est ici important : Une analyse trop détaillée des flux donne un résultat inexploitable. Autant l'analyse détaillée se justifie pour les besoins d'un projet ou de l'exploitation du SI, autant l'analyse de l'urbaniste doit se limiter aux flux les plus importants (en terme de volume, de criticité ou d'importance stratégique, etc.). Cela suppose une bonne connaissance a priori du système.

    Références

    [3] Exemple d'architecture métier d'un système de prise en charge du patient en unité clinique SI35MOD

    [5] Tableau de description des éléments d'un système d'information SI35MFAP

    [7] Interopérabilité et urbanisation Eléments de définition SI35INT

Cette réponse vous paraît-elle utile ?
Date de parution : 07/05/2014

Commentaires - Soyez le premier à déposer un commentaire

Pour ajouter un commentaire vous devez vous identifier

Vous êtes actuellement sur la page consacrée à Conduire un projet d'urbanisation des SI (Méthode).

Vous êtes perdu ?

Haut de page

Vous êtes actuellement sur la page consacrée à Conduire un projet d'urbanisation des SI (Méthode).

Vous êtes perdu ?