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

Avis d'experts

Comprendre comment gérer les évolutions régulières du DPI

 2983 vues

Cet avis d'expert a été rédigé par Patrick BLANCHET, Michelle DANIEL et Pierre CHAMPSAUR.

 

Dans le projet de déploiement puis de maintenance d'un DPI la gestion des évolutions régulières est un travail récurrent, consommateur plus ou moins permanent de ressources. De fait c'est un point essentiel qu'il faut analyser le plus tôt possible, dans le but pour l'ES de mettre en place une organisation mais aussi de contractualiser certains points avec l'éditeur pour que ces évolutions nécessaires ne deviennent pas des sources d’incidents ou de mécontentement des utilisateurs finaux.

Cette réponse vous propose donc une analyse et des pistes d'organisation.

Différents types d’évolution font partie des cycles de vie des logiciels de DPI :

  • Les évolutions intégrées dans le cadre de « la maintenance logicielle » : elles sont organisées en fonction de la roadmap de l’éditeur, lequel, dans le cadre d’une stratégie industrielle tient compte à sa discrétion des retours des clients et des clubs utilisateurs.
  • Les évolutions qui concernent des modifications structurelles : elles ont pour but la modification du logiciel pour répondre à des logiques de standardisation informatique, de modification du modèle conceptuel des données. Elles peuvent être motivées par l’amélioration des performances. Elles peuvent n’être en rapport ni avec la résolution de bug, ni l’évolution directe des fonctionnalités.
  • Les évolutions correctives ou adaptatives : elles ont pour but la résolution de bugs ou encore l’ajout/modification de fonctionnalités fonctionnelles ou adaptatives souhaitées par l’établissement.

Non traitées ici : certaines demandes d’évolutions souhaitées par l’ES ne font pas l’objet de demandes auprès de l’éditeur. Ces demandes concernent le paramétrage. Les évolutions de paramétrage sont des modifications gérées en internes et ont leur cycle de vie propre. Leur mise en production se fait soit au fil de l’eau, soit avec un temps très court d’interruption de production lors de leur activation.

 

La recette : étape indispensable avant la mise en production mais des possibilités variables selon l’éditeur du DPI :

Les livraisons par l’éditeur d’évolutions du DPI feront toutes l’objet d’une phase de tests préalable (recette) par l’équipe projet DPI de l’établissement, qui pourra ainsi valider celles-ci avant leur mise en production.

  • Les objectifs : étude d'impact, recherche de régressions dans le contexte de l’ES, négociation de l'indisponibilité du DPI, rédaction des notes descriptives et livrets destinés aux utilisateurs finaux.
  • Les contraintes : l’étude d’impact et la recherche de régression est rendue difficile si l’éditeur ne met pas à disposition de l’ES une copie de la base de production pour réaliser les tests et faire les copies d’écran nécessaires aux livrets utilisateurs.
  • Les limites : même si l’ES dispose d’une copie de la base de production il est plus difficile de dupliquer les liens d’interopérabilité avec les autres logiciels éventuels de l’ES (Gestion des Lits, des blocs, GAP…). Des difficultés peuvent n’être découvertes alors que après la mise en production.

 

Quelques points d’attention en pratique :

Il faut adapter la gestion de l’évolution à son type et à son origine, mais aussi au contexte de l’ES

  • L'évolution est à la demande de l'ES : il faudra vérifier la réponse à la demande.
  • La demande vient d'un autre ES : il faudra vérifier la cohérence avec le fonctionnement de l’ES, et préparer les livrets et les formations nécessaires.
  • L'évolution est faite par l'éditeur après un retour d'expérience d'un utilisateur : même comportement.
  • Une nouvelle contrainte règlementaire impose l'évolution : préparer les livrets et les formations nécessaires.
  • L'éditeur a décidé d'une modification d'architecture (nouvelle opportunité, amélioration ergonomique, amélioration des performances) : vérifier la cohérence avec le fonctionnement de l’ES*, et préparer les livrets et les formations nécessaires.
  • Correction d'un bugg : vérifier la correction.
  • L'application de l'évolution est-elle paramétrable par ES ou non? C'est rarement le cas pour les évolutions liées à des contraintes règlementaires ou à une modification d'architecture du DPI. Par contre les autres types d'évolution pourraient être "activées" ou "non activées", selon le choix de l'ES, par paramétrage interne. C'est rarement le cas en pratique, les éditeurs préférant souvent conserver un "master" à large diffusion pour faciliter leur maintenance et les évolutions futures.

 

La mise en production de l’évolution :

  • Le mode opératoire doit être négocié entre l’ES et l’éditeur et ensuite contractualisé sur les points suivants :
    • Délais entre l’annonce et la mise en production.
    • Eloignement d’une période de fragilité de l’ES : évolution de la structure, période de congé annuel, évènement (visite de certification, nouveaux internes, congrès…). Cet engagement est complémentaire de la définition du nombre acceptable d’évolutions par an.
    • Temps d’indisponibilité.
    • Heure de début et heure de fin d’indisponibilité, en conciliant faible niveau d’activité, disponibilité des équipes.
    • Engagement de retour sans délai à la version précédente en cas de régression grave non décelée lors de la recette.
  • Au sein de l’ES plusieurs actions sont nécessaires :
    • Déclencher la Cellule de Crise prévue dans le PRA/PCA selon l’importance de l’évolution et le temps d’indisponibilité prévu puis observé.
    • Déclencher la procédure dégradée telle que décrite dans le PCA.
    • Accompagner la Continuité des Soins en Procédure Dégradée.
    • Distribuer les nouveaux livrets, mettre à jour des outils de e-learning…
    • Vérifier le niveau de connaissance des utilisateurs et assurer si besoin de nouvelles formations.
    • Vérifier le fonctionnement des interfaces.
    • Enfin repasser en mode production et être en veille vis-à-vis des éventuels EI.
    • Arrêter la procédure dégradée, accompagner la reprise des soins appuyés sur le DPI, la reprise des données.
    • Assurer que l’archivage des données produites lors de la procédure dégradée et non reprises se déroule conformément au PRA

 

Tableau des ressources à mobiliser pour gérerles évolutions régulières

Attention: le tableau ci-dessous est une proposition à personnaliser par chaque ES, dans tous les composants.

 

tache

détail

ressource

temps

   

S.I.

soignant

médecin

pharmacien

Equipe projet

PMSI

administration

 

Evolutions du DPI

 
 

+/-

++

++

++

++

+

+/-

 

Evaluation impact fonctionnel

+

++

++

++

++

+

+/-

 

Vérifier correction de bugg

+

++

++

++

++

+

+/-

 

Recherche de régression

+

+

+

+

++

+

+/-

 

Echanges avec éditeur

+/-

+/-

+/-

+/-

++

+/-

+/-

 

 Rédaction des livrets

 +

 ++

 ++

 ++

 ++

+

 +/-

 

 Gestion e-learning

 +

 ++

 ++

 ++

 ++

 +

 +/-

 

 Application PCA et PRA

 ++

 ++

++ 

 ++

 ++

 ++

 +

 

 Formations Utilisateurs

 +/-

 +/-

 +/-

 +/-

 ++

 +/-

 +/-

 

 Chercher régression à la reprise

 

 

 

 

 

 

 

 

 Vérifier interfaces

 ++

 +/-

 +/-

 +/-

  ++

+/- 

 +/-

 

  

Retrouvez le catalogue des productions des experts HN.

Cette réponse vous paraît-elle utile ?
Date de parution : 02/01/2016

Commentaires - Soyez le premier à déposer un commentaire

Pour ajouter un commentaire vous devez vous identifier

Vous êtes actuellement sur la page consacrée à Comprendre comment gérer les évolutions régulières du DPI (Avis d'experts).

Vous êtes perdu ?

Haut de page

Vous êtes actuellement sur la page consacrée à Comprendre comment gérer les évolutions régulières du DPI (Avis d'experts).

Vous êtes perdu ?