Après le go‑live : donner au support le contexte qui lui manque

Recueillir assez d’informations pour orienter la demande

Demandez quelle activité était en cours, quel résultat était attendu et ce qui a été observé. Ajoutez l’impact pour l’équipe et les vérifications déjà réalisées. Ces éléments permettent de qualifier le sujet sans conclure trop vite à un défaut logiciel ou à une règle qu’il faudrait modifier.

Le circuit de prise en charge doit distinguer les questions d’utilisation, les incidents et les demandes d’évolution. Selon le site, l’équipe locale, un support central, l’intégrateur ou l’éditeur interviennent à différents niveaux. Les événements qualité suivent les procédures applicables.

Définir le rôle de Business System Owner et l’administration

Lorsqu’un site utilise l’intitulé Business System Owner (BSO), les responsabilités associées doivent être explicites. Pour le MES, précisez qui représente les besoins de production, qui priorise les demandes et qui suit les évolutions avec l’IT et la qualité. Les décisions et les validations doivent avoir des interlocuteurs identifiés.

L’administration porte sur les opérations autorisées dans le système : par exemple, gérer les données de référence ou préparer une évolution de configuration. Le rôle métier et les tâches d’administration peuvent être répartis entre plusieurs personnes. La répartition choisie doit permettre de savoir qui demande, qui décide, qui réalise et qui vérifie.

Référence : ISPE · GAMP : cycle de vie et clarification des responsabilités

Organiser les astreintes au rythme de la production

En 5×8, quelqu’un est au poste avec les équipes. En astreinte, quelqu’un répond quand on l’appelle. Les deux ne s’organisent pas de la même façon. Pour une astreinte, définissez les plages couvertes, les situations qui justifient un appel et le canal à utiliser. La disponibilité et les modalités de prise en charge se conviennent avec le site.

La personne sollicitée doit retrouver le contexte de l’opération et les consignes de diagnostic. Son périmètre précise les actions qu’elle peut réaliser et les situations à transmettre à l’IT, à l’automatisme, à l’intégrateur ou à l’éditeur. Les décisions relatives à la qualité restent dans le circuit du site.

À la fin de l’intervention, consignez le diagnostic, les actions et les sujets encore ouverts pour l’équipe qui prend le relais. Les sollicitations répétées alimentent ensuite les améliorations du système, de la documentation ou de la formation.

Organiser une passation que l’on peut réellement utiliser

Une passation se vérifie. Faites retrouver à l’équipe support une décision de conception, un propriétaire de données et un cas déjà rencontré. C’est une manière concrète de vérifier que les connaissances sont accessibles.

La documentation utile rassemble les raisons des choix, les limites connues et les circuits de contact. Chaque contenu doit avoir un responsable de mise à jour et rester cohérent avec la version du système concernée. Une réponse exacte avant une évolution peut devenir trompeuse après celle-ci.

Pour les informations sensibles, utilisez les outils et les canaux autorisés par le site. Une base de connaissances n’a pas vocation à recopier sans contrôle les données d’un dossier de lot.

Relier les demandes répétées aux évolutions du système

Plusieurs demandes similaires méritent d’être rapprochées. Elles peuvent révéler un support de formation incomplet, une donnée mal comprise ou une difficulté de conception. Le traitement peut alors porter sur la cause commune.

Avant de retenir une modification, décrivez le besoin et les utilisateurs concernés. Une petite évolution d’écran peut toucher une recette, une interface ou la revue du dossier. Son impact sur les essais, la validation et les supports de formation s’examine dans le processus de changement du site.

Conservez le lien entre la demande initiale, la décision et la version livrée. La prochaine personne qui reprendra le sujet pourra comprendre ce qui a changé et pourquoi, sans devoir reconstituer les échanges du projet.