Transition AMS et état de référence du parc applicatif
Cas d'usage illustratif, pas une étude de cas.
Reprendre des applications que nous n'avons pas construites : inventorier le parc, convenir du périmètre et des sévérités, transférer les connaissances et établir la référence du service avant de l'exploiter.
Le problème
Les applications fonctionnent, mais les personnes qui les comprenaient sont parties ou le prestataire en place s'en va. La documentation est partielle, les personnalisations ne sont pas documentées, et personne ne peut dire quelles intégrations sont critiques. Le support ne peut pas être amélioré tant qu'il n'est pas d'abord compris.
Comment cela fonctionne aujourd'hui
Une nouvelle équipe de support hérite d'une file de tickets et d'un lecteur partagé. Le transfert de connaissances se fait en quelques appels avec l'équipe sortante. Les définitions de sévérité, les heures de service et les chemins d'escalade sont supposés à partir de l'ancien contrat. Les premiers mois sont passés à redécouvrir le parc applicatif au fil des incidents.
Voir le scénario
Flux de travail illustratif. Sous-titré.
Transcription
- Les applications fonctionnent, mais ceux qui les comprenaient sont partis. La documentation est partielle, les personnalisations ne sont pas documentées, et personne ne sait quelles intégrations sont critiques.
- Nous inventorions les applications, convenons périmètre et heures de support, documentons procédures et lacunes, puis établissons l'état de référence du service.
- Rien ne change en production pendant la découverte. Le responsable approuve les définitions avant le démarrage, et les constats alimentent un backlog d'amélioration qu'il priorise.
- Mesuré sur couverture du parc et incidents de composants inconnus. Cas d'usage illustratif. Parlons du vôtre.
Flux de travail proposé
- Inventorier le parc applicatif : modules, intégrations, personnalisations, agents et les environnements dans lesquels ils s'exécutent, avec des preuves recueillies dans les systèmes plutôt que de mémoire
- Convenir par écrit du périmètre, des définitions de sévérité, des heures de service et des responsabilités d'escalade vers l'éditeur avant de prendre le moindre ticket
- Transférer les connaissances dans des procédures et une base de connaissances approuvée, avec les lacunes listées plutôt que cachées
- Établir l'état de référence du service : volumes d'incidents actuels, délais de résolution, cadence des versions et risques connus
- Opérer selon les définitions convenues, consigner les constats et proposer des éléments d'amélioration que le responsable priorise
Où une personne garde le contrôle
- Le périmètre, les sévérités, les heures et les responsabilités d'escalade sont approuvés par le responsable avant le démarrage du service
- Aucun changement n'est apporté à la production pendant la découverte ; les constats sont consignés, pas corrigés sur-le-champ
- Le backlog d'amélioration est priorisé par le responsable, pas par l'équipe de support
Les correspondances de plateformes indiquent les environnements dans lesquels évaluer cette idée. La mise en œuvre réelle dépend de la configuration, des licences, des API, des données et des autorisations. Les bénéfices sont exprimés de manière qualitative ; toute affirmation chiffrée exige une base de référence documentée.