Le modèle disparaît. Votre boîte de commandes reste ouverte.
Matías Bonvin· Mis à jour le
Imaginez un email de votre fournisseur de modèle : la version utilisée par votre assistant de traitement des commandes sera retirée à une date précise. Une version de remplacement est disponible.
La modification technique semble limitée. Quelqu'un change un paramètre, envoie une requête d'essai et obtient une réponse cohérente. Pendant ce temps, les clients continuent d'envoyer des pièces jointes avec d'anciennes références et des consignes de livraison dans le mauvais champ.
Le nouveau modèle doit aussi traiter ces cas. Une connexion réussie ne prouve pas que le processus peut s'appuyer sur les réponses.
Retrouvez les processus qui utilisent cette version
Partez de l'identifiant exact du modèle mentionné dans l'avis de retrait. Retrouvez ses utilisations, y compris les tâches planifiées que personne n'ouvre dans un navigateur. Relevez la date d'arrêt dans la documentation actuelle du fournisseur et nommez un responsable de migration.
Pour chaque processus concerné, notez le responsable métier, les personnes qui utilisent le résultat et l'action qui suit. Un assistant rédigeant une synthèse interne et un assistant préparant une commande avant expédition n'exposent pas l'entreprise aux mêmes conséquences.
Vérifiez qui reçoit les prochains avis. Un abonnement rattaché à l'email d'un ancien prestataire peut transformer un retrait annoncé en panne surprise.
Une ligne par processus peut préciser la version, le titulaire du compte, la date de retrait, l'emplacement des tests et la solution de secours. Chargez quelqu'un de l'actualiser.
Confiez vos cas difficiles au remplaçant
Utilisez des exemples historiques autorisés dans un environnement sûr. Retirez les données sensibles si nécessaire, en conservant les détails qui font la difficulté du cas.
Dans notre exemple de commandes, comparez notamment une référence inconnue et une pièce jointe qui contredit l'email. Ajoutez une commande incomplète. Le comportement attendu peut être de demander une vérification humaine plutôt que de deviner.
Fixez les critères d'acceptation avant de regarder les nouvelles réponses. Quels champs doivent être extraits correctement ? Quelle incertitude doit arrêter le processus ? Quelles actions restent soumises à approbation ?
Si l'ancienne version est encore disponible, faites traiter les mêmes cas aux deux modèles. Examinez le résultat qui arrive dans le système métier, au-delà du texte renvoyé. Une réponse correcte dans un format différent peut casser l'étape suivante.
Répétez les cas pour lesquels une variation aurait des conséquences. Relevez les erreurs, le travail de contrôle, le temps de réponse et le coût dans des conditions représentatives. Une moyenne peut masquer une erreur rare que votre activité ne peut pas accepter ; consignez ces échecs séparément.
Prévoyez la suite si le test échoue
Le remplacement peut demander davantage de travail que le délai restant ne le permet. Décidez à l'avance du traitement des nouvelles demandes dans cette situation.
Pour notre processus de commandes fictif, vous pourriez orienter les demandes vers une file manuelle existante et retirer l'assistant du circuit de mise en exécution. Précisez qui surveille cette file, la capacité disponible et le moment où il faudra annoncer un délai différent aux clients. Testez ce circuit avant d'en avoir besoin.
Revenir à l'ancien modèle peut être possible avant son retrait. Après sa suppression par le fournisseur, une procédure de retour arrière qui en dépend ne fonctionnera plus. La solution de secours doit rester disponible après cette date.
Que vous choisissiez un traitement manuel temporaire ou une autre solution testée, nommez une personne autorisée à l'activer. Conservez la trace des commandes traitées pour éviter les doublons au redémarrage.
Commencez par une partie délimitée du travail
Lorsque le remplaçant satisfait les critères convenus, commencez sur un périmètre contrôlé et inspectez les résultats avant de l'élargir. Conservez les validations métier existantes. Changer de modèle ne donne pas de nouvelles permissions à l'assistant.
Ce travail demande un budget et un responsable après la mise en service. Demandez qui surveille les avis, entretient les cas de test et finance une migration imposée. Convenez de ces responsabilités lors de l'achat, tant qu'il est encore possible de les chiffrer et de prévoir les ressources.
Chez Solve IT, le périmètre d'implémentation peut inclure ces dépendances d'exploitation avec la première mise en service. Une Strategy Session peut partir d'un processus, suivre une demande jusqu'au modèle dont elle dépend et identifier comment poursuivre le travail pendant un changement.
Apportez le nom du modèle dont votre boîte de commandes aura besoin lundi.