L'analyse métier, fondement d'une validation efficace des systèmes informatisés
Écrit par Steffen Reuter
Introduction
Les projets de numérisation et d’automatisation menés dans un environnement réglementé constituent des initiatives complexes et à forts enjeux. La qualité de la Business Analysis (BA) réalisée en amont est souvent le facteur déterminant entre un déploiement fluide et conforme, et un projet coûteux et semé d’embûches. Cet article examine comment une Business Analysis rigoureuse constitue le fondement d’une validation des systèmes informatisés (CSV) efficace, basée sur les risques et efficiente, en s’appuyant sur des expériences concrètes de projets et sur les meilleures pratiques réglementaires.
Mise en œuvre d'un LIMS – Le coût d’une Business Analysis insuffisante
Au cours de nos missions de conseil, nous sommes fréquemment confrontés à des projets dans lesquels les activités clés de Business Analysis n’ont pas été menées suffisamment tôt ou n’ont pas reçu l’attention nécessaire. Le projet de mise en œuvre d’un système LIMS présenté ci-dessous, fictif mais réaliste, pour un groupe de laboratoires multi-sites, regroupe des problématiques fréquemment observées dans de nombreux projets et illustre comment une Business Analysis insuffisante peut affecter la réussite de la mise en œuvre, les efforts de validation, la conformité et l’adhésion des utilisateurs.
Le système existant était fortement personnalisé et instable, ce qui a rendu nécessaire la mise en place d’une nouvelle solution. Cependant, la phase préparatoire du projet a été marquée par plusieurs lacunes importantes :
- Absence de processus métier documentés de bout en bout
- Fonctionnement des laboratoires et gestion des données en silos, avec une harmonisation limitée des processus
- Responsabilités liées aux processus mal définies et disponibilité limitée des experts métier (SME)
- Une spécification des exigences utilisateur (URS) qui constituait essentiellement une « liste de souhaits » des utilisateurs, dépourvue de critères d’acceptation, d’une base d’analyse des risques et d’une démarche formelle d’ingénierie des exigences
- Pas de preuve de concept ni de modèle de configuration transparent
Au fur et à mesure que le projet avançait, ces lacunes ont entraîné des problèmes majeurs.
Au début du projet, une grande incertitude régnait quant aux fonctionnalités prévues du système. Les parties prenantes interprétaient les exigences de manière différente, ce qui a donné lieu à des discussions pour déterminer quelles fonctionnalités étaient indispensables pour la première version.
On ne savait pas non plus si les exigences documentées couvraient intégralement toutes les étapes critiques du processus ni si des activités manuelles supplémentaires seraient nécessaires pour soutenir le flux de travail.
L’évaluation fonctionnelle des risques a donné lieu à de longues discussions au sein de l’équipe de projet, qui ont abouti à plusieurs ajustements du calendrier du projet. Au final, l’équipe a considéré que l’identification et l’évaluation d’au moins un risque par exigence étaient suffisantes. L’engagement pris par l’éditeur du logiciel de tester de manière approfondie toutes les fonctions lors de la qualification opérationnelle (OQ) a rassuré l’équipe, contribuant à confirmer que les risques identifiés avaient été traités de manière adéquate. Toutefois, il ne s’agissait pas de l’approche de test basée sur les risques initialement prévue.
Au cours des tests d'acceptation par les utilisateurs (UAT), il est apparu clairement que plusieurs processus métier établis ne pouvaient pas être exécutés comme prévu dans le nouveau système. En conséquence, des exigences supplémentaires ont été identifiées, ce qui a conduit à la mise en place de solutions de contournement et à des modifications de dernière minute.
Les analyses de traçabilité ont mis en évidence des difficultés à maintenir un lien clair entre les processus, les exigences, les risques et les cas de test. De plus, l'impact des modifications sur les fonctionnalités précédemment testées n'était pas toujours détectable, ce qui imposait d'importants tests de régression et des cycles de révision supplémentaires. Ces activités ont alourdi la charge de travail du projet et soumis l'équipe projet à une pression considérable.
Lors du déploiement de la solution dans l'environnement de production, il est apparu que certaines activités essentielles à la mise en production, notamment l'élaboration des procédures opérationnelles standard (SOP) et la formation des utilisateurs finaux, n'avaient pas encore été menées à bien.
En conséquence, l'adoption par les utilisateurs a été limitée et le mécontentement s'est accru parmi le personnel de laboratoire. De nombreux utilisateurs ont estimé que la solution fournie ne répondait pas suffisamment à leurs méthodes de travail, alors qu'ils s'attendaient à ce qu'elle leur offre un système moderne et efficace, adapté à leurs besoins opérationnels.
L'impact d'une Business Analysis insuffisante sur la validation des systèmes informatisés (CSV)
Une Business Analysis (BA) insuffisante peut avoir des conséquences considérables sur la validation des systèmes informatisés (CSV). Des exigences ambiguës, incomplètes ou inexactes augmentent les risques de non-conformité et peuvent compromettre les efforts de validation. L’absence d’exigences ou une compréhension floue de l’usage prévu surviennent souvent à un stade avancé du cycle de vie du projet, ce qui entraîne la frustration des utilisateurs, des retouches coûteuses, des activités de revalidation, des retards de projet et une faible adhésion des utilisateurs. De plus, une documentation inadéquate et une traçabilité insuffisante augmentent le risque d’observations lors d’audits et de constatations lors d’inspections. Une Business Analysis (BA) insuffisante alourdit les efforts de validation, augmente la charge documentaire, accroît la complexité du projet et fait grimper les coûts globaux.
Une cause fréquente réside dans une définition insuffisante de l’usage prévu, qui se traduit souvent par une spécification des exigences utilisateur (URS) insuffisante ou incomplète. Lorsque l’usage prévu ne découle pas clairement des processus métier et des flux de travail des utilisateurs, il devient difficile de démontrer que le système est adapté à l’usage auquel il est destiné. Il en résulte un ensemble d’exigences qui ne répond pas pleinement aux besoins métier, des activités de validation mal alignées sur les risques réels, ainsi qu’un risque accru de problèmes de conformité ou d’inefficacités opérationnelles.
Un autre défi se pose lorsque l'évaluation des risques est lancée trop tard dans le projet et se concentre uniquement sur les fonctionnalités du système après que la solution a déjà été sélectionnée. Une évaluation efficace des risques doit débuter au niveau des processus, où les étapes critiques et les risques associés peuvent être identifiés avant que les décisions relatives à la conception de la solution ne soient prises. Sans cette base, il devient difficile de déterminer quels contrôles, quelles fonctionnalités et quelles activités de validation sont réellement nécessaires pour atténuer efficacement les risques.
Dans de nombreux cas, la cause profonde tient à une communication inefficace et à un manque d’alignement entre les parties prenantes. Lorsque les besoins métier ne sont pas clairement distingués des fonctionnalités souhaitées, et lorsque les hypothèses, les contraintes et les attentes ne sont pas suffisamment comprises et documentées, une ambiguïté s’installe dans le projet. Si cette ambiguïté peut sembler mineure aux premières étapes, elle se traduit souvent par un effort de validation important, des retouches coûteuses et un risque accru de non-conformité à un stade ultérieur du cycle de vie du projet.
Enfin, l'adhésion des utilisateurs joue un rôle central. L'adhésion à un système ne commence pas seulement au moment de la mise en service. Elle se construit dès les premières phases du projet. Les utilisateurs s'attendent à ce que leurs processus soient compris et à ce que leur mode de travail soit pris en compte dans la future solution. Si les utilisateurs ne sont pas suffisamment impliqués ou si les avantages des nouveaux processus restent flous, cela suscitera de la résistance et de la frustration. Une Business Analysis efficace contribue donc non seulement à la conformité et à la qualité du projet, mais pose également les bases d’une adhésion durable et d’une utilisation réussie du système.
Concepts clés de la Business Analysis au service de la validation des systèmes informatisés (CSV)
La Business Analysis (BA) est souvent associée à l’analyse des processus, mais son champ d’application est bien plus large. Une Business Analysis efficace englobe toute une série de disciplines, notamment la gestion des exigences, l’implication des parties prenantes, l’évaluation des risques, l’évaluation des solutions et l’accompagnement du changement. En veillant à ce que les organisations comprennent leurs besoins, prennent des décisions éclairées et mettent en œuvre les solutions adaptées, la Business Analysis apporte de la valeur tout au long du cycle de vie du système. Ensemble, ces activités de Business Analysis contribuent à une approche CSV plus efficace, conforme et basée sur les risques.
Planification de la Business Analysis
La planification de la Business Analysis (BA) constitue le fondement de toutes les activités ultérieures du projet et contribue à rendre les efforts de validation plus prévisibles. Elle définit le périmètre, les objectifs et l’approche de la Business Analysis, garantissant ainsi un alignement précoce sur l’usage prévu, les limites du système et la stratégie de validation. En impliquant les parties prenantes adéquates aux étapes appropriées, il est possible d’identifier très tôt les attentes réglementaires, tout en recensant, documentant et gérant de manière transparente les risques, les hypothèses et les décisions clés.
Une planification efficace permet également d'aligner les activités de validation sur la méthodologie de développement choisie. De plus, les workflows de révision et de validation peuvent être rationalisés grâce à des processus clairement définis et à l'utilisation d'outils adaptés, ce qui améliore à la fois l'efficacité et la traçabilité tout au long du cycle de vie du projet.
Gestion des parties prenantes
La gestion des parties prenantes permet de s'assurer que les bonnes personnes sont impliquées tout au long du projet et que leurs besoins, leurs préoccupations et leurs attentes sont bien compris. Grâce à une communication active, la Business Analysis contribue à concilier les différents intérêts, à instaurer la confiance, à créer un sentiment d'appropriation collective et à garantir la transparence concernant les hypothèses, les limites et les contraintes.
Dans le cadre du CSV, une gestion efficace des parties prenantes améliore l'acceptation de la solution et favorise une plus grande participation aux évaluations des risques, aux tests et aux activités de mise en production. Un alignement précoce permet d'identifier les contraintes avant qu'elles ne deviennent des problèmes, réduit la résistance au changement et minimise le recours à des solutions de contournement. L'implication des parties prenantes tout au long du cycle de vie du projet augmente les chances que la solution livrée réponde aux besoins métier et évite les situations coûteuses du type « Ce n'est pas ce dont nous avions besoin » lors des tests d'acceptation utilisateur (UAT) ou de la mise en production.
Analyse des processus
L'analyse des processus permet de comprendre de manière structurée comment le travail est effectué aujourd'hui et comment il devrait l'être à l'avenir. En examinant les processus actuels, les points faibles, les contrôles manuels et les risques associés, l'analyse des processus aide à définir les processus cibles, à identifier les opportunités d'amélioration et à mettre en place des contrôles et des mesures d'atténuation des risques adaptés.
L'analyse des processus jette les bases d'une solution adaptée aux besoins de l'entreprise. Elle permet d'identifier les étapes du processus pouvant être simplifiées, standardisées ou automatisées, ainsi que celles qui nécessitent une intervention manuelle. Les lacunes en matière de contrôle apparaissent au grand jour, et il devient possible d'identifier à un stade précoce les risques opérationnels et de conformité. En comprenant les processus avant de définir les exigences, les activités de validation peuvent se concentrer sur ce qui est véritablement essentiel. De plus, les problèmes potentiels et les faiblesses cachées des processus sont identifiés avant la mise en œuvre, ce qui permet une prise de décision plus éclairée et réduit le recours aux hypothèses et aux solutions de contournement. Une analyse efficace des processus garantit que les exigences, les contrôles et les activités de validation sont alignés sur les processus métier réels, ce qui se traduit par des solutions plus robustes et des systèmes adaptés à l'usage prévu.
Analyse des risques liés aux processus
L'analyse des risques liés aux processus permet d'identifier et d'évaluer les risques au sein des processus métier avant même que les exigences et les activités de validation ne soient définies. En évaluant des facteurs tels que l'impact GxP, la criticité métier, le degré d'automatisation, les interventions manuelles et le soutien apporté par les systèmes, la Business Analysis (BA) aide à déterminer où les contrôles et les mesures d'atténuation sont les plus nécessaires.
L’identification précoce des risques permet d’intégrer dès le départ des mesures d’atténuation dans la planification du projet. Les risques liés aux processus constituent une base pour définir des exigences fondées sur les risques, en distinguant les fonctions relevant des normes GxP de celles qui sont essentielles à l’activité. Ils aident à déterminer le juste équilibre entre les contrôles techniques, qui débouchent sur des exigences relatives au système, et les contrôles procéduraux, qui se reflètent dans les procédures opérationnelles standard (SOP) et les manuels d’utilisation. Une fois que la pertinence GxP et la catégorie GAMP ont été évaluées au niveau du système lors de l’analyse des risques (RA) initiale, l’évaluation précoce de l’impact GxP et métier des processus et des différentes étapes de processus contribue à optimiser les efforts de conformité et à maîtriser les coûts de validation. L’identification des processus ou étapes non critiques devant être exécutés sans support système, avant la sélection d’une solution ou l’approbation d’une spécification des exigences utilisateur (URS), peut réduire considérablement les efforts d’alignement, de mise en œuvre, d’évaluation des risques fonctionnels et de tests. La portée des tests d’acceptation utilisateur (UAT) et des procédures opérationnelles standard (SOP) peut être centrée sur les processus et fonctionnalités critiques, ce qui permet leur développement précoce et favorise une transition en douceur vers l’exploitation. Comprendre quelles étapes de processus sont les plus critiques facilite la réalisation de tests UAT basés sur les risques et contribue à garantir que les tests effectués par les utilisateurs clés restent efficaces et axés sur la valeur métier.
L'analyse des risques liés aux processus favorise une stratégie de validation fondée sur les risques, améliore la conformité et contribue à garantir que les mesures de contrôle soient mises en œuvre là où elles ont le plus d'impact.
Ingénierie des exigences
L'ingénierie des exigences consiste à traduire les besoins métier, les attentes des utilisateurs, les obligations réglementaires et les objectifs du système en un ensemble structuré d'exigences. La Business Analysis veille à ce que les exigences soient définies au niveau approprié, depuis les exigences métier et utilisateur jusqu'aux exigences liées à la solution, à la transition, aux aspects non fonctionnels et à la conformité.
Une ingénierie des exigences efficace établit une base claire et solide pour la validation. Les exigences reflètent fidèlement l’usage prévu du système, sont définies selon les critères SMART (spécifiques, mesurables, atteignables, pertinentes et limitées dans le temps), sont testables et restent indépendantes des conceptions de solutions spécifiques lorsque cela est approprié. La hiérarchisation des priorités et la définition de critères d’acceptation permettent de concentrer les efforts de mise en œuvre et de validation sur ce qui apporte le plus de valeur métier et de conformité. De plus, les activités de validation et les revues réalisées par les parties prenantes garantissent que les exigences restent sans ambiguïté et alignées sur les besoins métier et les attentes réglementaires tout au long du cycle de vie du projet.
Des exigences bien définies permettent une traçabilité complète, depuis les besoins métier jusqu'aux tests et à la mise en production, ce qui renforce à la fois la conformité et la confiance dans l'état validé du système.
Réglementations, lignes directrices et nécessité de la traçabilité
La Business Analysis (BA) n'est pas explicitement exigée par la réglementation ; toutefois, bon nombre des attentes fondamentales définies dans les normes sectorielles et les directives réglementaires ne peuvent être satisfaites que grâce à des activités efficaces de Business Analysis.
L’annexe 11 des BPF de l’UE [1] exige que les spécifications des exigences utilisateur (URS) décrivent les fonctions requises d’un système informatisé et que ces exigences reposent sur des évaluations des risques documentées et sur l’impact sur les BPF. De plus, les exigences doivent rester traçables tout au long du cycle de vie du système. Cela signifie que chaque exigence doit avoir une justification métier claire et un lien identifiable avec les risques de processus qu’elle est censée traiter. Sans processus structuré de Business Analysis (BA), le maintien de ce niveau de traçabilité peut s’avérer difficile et nécessiter d’importantes ressources.
Les lignes directrices de la FDA relatives à la Computer Software Assurance (CSA) [2] accordent une importance similaire à l’usage prévu et à l’assurance fondée sur les risques. Ces lignes directrices reconnaissent qu’un logiciel peut avoir plusieurs usages prévus en fonction de ses caractéristiques et fonctions spécifiques, et recommandent d’évaluer les risques à ce niveau afin de déterminer les activités d’assurance appropriées. Pour soutenir une telle approche, les organisations doivent d’abord comprendre comment les utilisateurs interagissent avec le système, quelles fonctions sont critiques et comment ces fonctions soutiennent les processus métier. Ce sont là autant de résultats clés d’une Business Analysis (BA) efficace.
La deuxième édition de la norme ISPE GAMP® 5 [3] renforce cette perspective en recommandant que les activités de gestion des risques liés à la qualité commencent au niveau des processus métier avant de se concentrer sur les fonctions spécifiques du système. La norme GAMP souligne que les organisations doivent comprendre le processus, identifier les étapes critiques et les risques associés, et définir les contrôles appropriés avant de définir les exigences du système. Cela garantit que les exigences, les évaluations des risques, les activités de test et les contrôles procéduraux restent en adéquation avec les besoins réels de l'entreprise.
[1] EudraLex, volume 4, Bonnes pratiques de fabrication – Annexe 11 : Systèmes informatisés
Les avantages de la Business Analysis pour le CSV
Une bonne Business Analysis (BA) est un élément clé pour garantir une validation des systèmes informatisés réussie, efficace et basée sur les risques. En définissant l’usage prévu, en comprenant les processus métier, en identifiant les risques et en alignant les attentes des parties prenantes, la Business Analysis jette des bases solides tant pour la réussite du projet que pour la conformité.
Une Business Analysis (BA) rigoureuse permet de réduire le gaspillage en évitant les retouches coûteuses, les personnalisations superflues et les solutions qui ne répondent pas aux besoins réels de l'entreprise. Elle garantit que les projets se concentrent sur la résolution des bons problèmes plutôt que sur la simple mise en œuvre des fonctionnalités demandées. En établissant un lien entre les objectifs métier, les exigences réglementaires et la mise en œuvre technique, la Business Analysis aide les organisations à prendre des décisions éclairées, fondées sur des faits plutôt que sur des hypothèses.
Dans le cadre du CSV, ces avantages sont particulièrement importants. Une compréhension claire des processus, des évaluations des risques et des exigences bien définies garantissent une traçabilité de bout en bout, du processus métier jusqu’à l’exigence, au contrôle et au test. Cela permet d’adopter une approche de validation efficiente et basée sur les risques, grâce à laquelle les efforts de validation se concentrent sur ce qui est véritablement essentiel, tout en réduisant la documentation superflue, les tests et les cycles de révision. En conséquence, les solutions ont davantage de chances de répondre aux besoins des utilisateurs, d’être acceptées par les parties prenantes et de favoriser une transition en douceur vers la mise en production.
La Business Analysis permet de réduire les ambiguïtés, d’aligner les attentes des parties prenantes et de jeter les bases d’une validation des systèmes informatisés efficiente, conforme et basée sur les risques.
Comment wega peut vous aider
wega Informatik AG propose une gamme complète de services destinés à aider ses clients à mettre en œuvre un CSV efficace, conforme et rentable grâce à une Business Analysis rigoureuse. Ces services comprennent :
- Planification et stratégie BA et CSV
- Gestion des parties prenantes et animation
- Analyse de bout en bout des processus et évaluation des risques
- Ingénierie des exigences et cadres de traçabilité
- Élaboration de la stratégie de validation et mise en œuvre du projet
- Formation, accompagnement et transfert de connaissances
Forte de plusieurs décennies d'expérience dans les sciences de la vie, l'informatique de laboratoire et les environnements réglementés, wega est votre partenaire de choix pour jeter les bases d'un CSV réussi.
Pour plus d'informations ou pour discuter de vos défis spécifiques, contactez wega Informatik AG.