Modèle de diagramme de Gantt de validation de système informatisé
Un diagramme de Gantt de validation de système informatisé modifiable : plan, exigences, risques, configuration, scripts IQ/OQ/PQ écrits pendant la mise en place, écarts, traçabilité, rapport et mise en service.
Qu'est-ce que le processus modèle de diagramme de gantt de validation de système informatisé ?
Valider un système informatisé est rarement lent à cause des tests eux-mêmes. C'est lent parce que les scripts sont écrits après la mise en place, qu'une étape en échec ouvre un écart que personne n'a le temps de traiter, et que la vérification de traçabilité finale trouve une exigence qu'aucun test ne couvre. Une frise ne peut pas y remédier, mais elle montre où se trouvent ces attentes avant que le projet y arrive.
Ce modèle compte quatre groupes : Planification et risques, Spécifications et mise en place, Scripts de test et exécution et Rapport et mise en service. Il comporte 20 tâches et quatre jalons : « Plan de validation approuvé », « Exécution terminée », « Rapport de validation approuvé » et « Mettre le système en service ». « Rédiger le plan de validation » (5 jours ouvrés) et « Rédiger les exigences utilisateur » (6) sont les deux tâches de départ. « Évaluer le risque pour les patients et les données » (4) démarre 2 jours après le début des exigences : l'évaluation des risques voit donc le premier jet au lieu d'attendre la version finale, et les deux alimentent « Plan de validation approuvé ».
Le plan est un verrou pour la mise en place, pas pour les scripts. « Rédiger la spécification fonctionnelle » (6) attend « Plan de validation approuvé ». « Configurer le système » (10) démarre 3 jours après le début de la spécification, et « Rédiger les procédures d'exploitation » (5) démarre 4 jours après le début de la configuration. Les scripts s'écrivent pendant ce travail : « Rédiger le script de qualification d'installation » (3) et « Rédiger le script de qualification opérationnelle » (5) attendent la spécification, et « Rédiger le script de qualification de performance » (5) n'attend que l'évaluation des risques, si bien qu'il peut être écrit face aux exigences avant que le système soit prêt.
L'ordre compte à l'exécution. « Exécuter la qualification d'installation » (3) a besoin du système configuré et de son script. « Exécuter la qualification opérationnelle » (8) la suit et attend son propre script. « Résoudre les écarts de test » (5) démarre 3 jours après le début de l'exécution opérationnelle, car les étapes en échec apparaissent tôt, et « Exécuter la qualification de performance » (8) attend les écarts autant que son script. « Revoir la traçabilité des exigences » (3) démarre après l'exécution opérationnelle et s'achève 1 jour après l'exécution de la performance, puis « Rédiger le rapport de synthèse de validation » (4) et « Rapport de validation approuvé » suivent. « Mettre le système en service » attend cette approbation et « Former les utilisateurs aux procédures approuvées » (3). Toutes les durées sont indicatives.
Une frise planifie le travail. Elle ne rend pas un système validé, conforme ou approuvé, et ne remplace ni votre procédure de validation, ni les décisions de votre unité qualité, ni les enregistrements que vous conservez. Pour les plans voisins, voyez le modèle de diagramme de Gantt de mise en œuvre d'un SMQ pour le système qualité qui l'entoure, celui de mise en production logicielle pour le volet publication d'un changement logiciel, et le processus de maîtrise des modifications pour la façon dont un changement d'un système validé est décidé. Pour la méthode de planification, voyez le guide sur les dépendances d'un diagramme de Gantt.
Ce que couvre cet organigramme
Dans ce modèle
- Quatre groupes, Planification et risques, Spécifications et mise en place, Scripts de test et exécution et Rapport et mise en service, avec 20 tâches et quatre jalons : « Plan de validation approuvé », « Exécution terminée », « Rapport de validation approuvé » et « Mettre le système en service ».
- Un risque qui démarre tôt : « Évaluer le risque pour les patients et les données » démarre 2 jours après le début de « Rédiger les exigences utilisateur », et « Plan de validation approuvé » attend cette tâche et « Rédiger le plan de validation ».
- Des scripts écrits à côté de la mise en place : « Rédiger le script de qualification d'installation », « Rédiger le script de qualification opérationnelle » et « Rédiger le script de qualification de performance » se déroulent pendant que « Configurer le système » est en cours.
- Une boucle d'écarts dans la fenêtre de test : « Résoudre les écarts de test » démarre 3 jours après le début de « Exécuter la qualification opérationnelle », et « Exécuter la qualification de performance » l'attend.
- Une revue finale avec chevauchement : « Revoir la traçabilité des exigences » s'achève 1 jour après la fin de « Exécuter la qualification de performance », et « Mettre le système en service » attend « Rapport de validation approuvé » et « Former les utilisateurs aux procédures approuvées ».
Quand utiliser ce modèle
- Vous validez un système nouveau ou mis à niveau et devez convenir de dates entre le responsable métier, l'informatique, la qualité et le fournisseur.
- Vous voulez voir quelle part du calendrier dépend de l'écriture précoce des scripts, et ce qu'un long écart fait à la date de mise en service.
- Une date de mise en production est fixée et vous voulez comparer la date de fin du diagramme avec la date voulue.
- Vous voulez un squelette reproductible pour les projets de validation que chaque équipe système peut adapter à sa procédure.
Le plan, tâche par tâche
Toutes les tâches du diagramme avec leur durée en jours ouvrés et ce qu'elles attendent. Une dépendance est un numéro d'étape ; SS signifie début à début, FF fin à fin et +n un décalage en jours ouvrés.
| # | Tâche | Groupe | Jours ouvrés | Dépend de |
|---|---|---|---|---|
| 1 | Rédiger le plan de validation | Planification et risques | 5 | |
| 2 | Rédiger les exigences utilisateur | Planification et risques | 6 | |
| 3 | Évaluer le risque pour les patients et les données | Planification et risques | 4 | 2SS+2 |
| 4 | Plan de validation approuvé | Planification et risques | Jalon | 1, 3 |
| 5 | Rédiger la spécification fonctionnelle | Spécifications et mise en place | 6 | 4 |
| 6 | Configurer le système | Spécifications et mise en place | 10 | 5SS+3 |
| 7 | Rédiger les procédures d'exploitation | Spécifications et mise en place | 5 | 6SS+4 |
| 8 | Rédiger le script de qualification d'installation | Scripts de test et exécution | 3 | 5 |
| 9 | Rédiger le script de qualification opérationnelle | Scripts de test et exécution | 5 | 5 |
| 10 | Rédiger le script de qualification de performance | Scripts de test et exécution | 5 | 3 |
| 11 | Exécuter la qualification d'installation | Scripts de test et exécution | 3 | 6, 8 |
| 12 | Exécuter la qualification opérationnelle | Scripts de test et exécution | 8 | 9, 11 |
| 13 | Résoudre les écarts de test | Scripts de test et exécution | 5 | 12SS+3 |
| 14 | Exécuter la qualification de performance | Scripts de test et exécution | 8 | 10, 13 |
| 15 | Exécution terminée | Scripts de test et exécution | Jalon | 14 |
| 16 | Revoir la traçabilité des exigences | Rapport et mise en service | 3 | 12, 14FF+1 |
| 17 | Rédiger le rapport de synthèse de validation | Rapport et mise en service | 4 | 15, 16 |
| 18 | Rapport de validation approuvé | Rapport et mise en service | Jalon | 17 |
| 19 | Former les utilisateurs aux procédures approuvées | Rapport et mise en service | 3 | 7, 15 |
| 20 | Mettre le système en service | Rapport et mise en service | Jalon | 18, 19 |
Comment cela fonctionne
Lancer ensemble le plan et les exigences
Gardez « Rédiger le plan de validation » et « Rédiger les exigences utilisateur » comme tâches de départ distinctes, et remplacez les durées par le temps que prennent vraiment vos approbateurs.
Laisser le risque démarrer sur un brouillon
« Évaluer le risque pour les patients et les données » est reliée en début-début, avec un décalage de 2 jours, aux exigences. Modifiez le décalage si vos évaluateurs ont besoin de plus d'exigences au départ.
Subordonner la mise en place au plan
« Rédiger la spécification fonctionnelle » attend « Plan de validation approuvé ». Déplacez ce lien si votre procédure permet de commencer la conception plus tôt, et ajoutez vos propres tâches, comme l'évaluation du fournisseur ou la migration des données.
Écrire les scripts pendant la mise en place
Gardez les trois tâches de script à côté de « Configurer le système » pour qu'ils soient prêts au début de l'exécution. Si vos scripts exigent un système configuré pour être écrits, reliez-les à lui.
Laisser de la place aux écarts
« Résoudre les écarts de test » dure 5 jours ouvrés et démarre pendant l'exécution opérationnelle. Allongez-la si des retests sont probables, et regardez comment bouge la date de fin de « Exécuter la qualification de performance ».
Ajouter les responsables, partager et exporter
Indiquez le responsable dans Personnes, partagez le diagramme avec l'informatique, la qualité et le responsable métier, et exportez un PDF ou un CSV pour le dossier du projet quand il vous en faut une copie.
Questions fréquentes
Combien de temps dure la validation d'un système informatisé ?
Cela dépend du système, de son niveau de risque et de votre procédure. Avec des durées indicatives, le modèle représente un plan de quelques mois de jours ouvrés. Remplacez-les par les vôtres et lisez la date de fin dans le diagramme.
Le diagramme valide-t-il le système ou prouve-t-il la conformité ?
Non. Il planifie le travail. La validation, ce sont les preuves que vous produisez et les décisions de votre unité qualité. Le diagramme montre quand chaque partie doit avoir lieu.
Pourquoi les scripts de test sont-ils écrits en parallèle de la mise en place ?
Parce qu'ils dépendent de la spécification et des exigences, pas du système terminé. Les écrire tôt les retire de l'attente critique avant l'exécution. Si vos scripts exigent le système configuré, modifiez les liens.
Puis-je l'utiliser pour un système cloud ou hébergé par un fournisseur ?
Oui, avec des changements. Remplacez « Configurer le système » par vos propres tâches de configuration et d'évaluation du fournisseur, et gardez les verrous du plan, des risques, de l'exécution et du rapport.
Comment planifier une revalidation après un changement ?
Copiez le diagramme et réduisez-le aux tâches que le changement touche. Pour la façon dont le changement lui-même est décidé, voyez le processus de maîtrise des modifications, et pour le travail qui se chevauche dans un plan, le guide sur les tâches qui se chevauchent dans un diagramme de Gantt.