Le problème de la transition : ce que votre équipe doit maîtriser avant le départ des consultants

Ce que signifie réellement la propriété

La propriété n'est pas un dossier de documents remis à la fin du projet. C'est la possession de quatre capacités pratiques au sein de votre entreprise.

Vous pouvez l'exploiter : quelqu'un sait vérifier si le système fonctionne aujourd'hui et est averti en cas de dysfonctionnement. Vous pouvez le modifier : quelqu'un peut ajuster une règle, ajouter une source de document ou mettre à jour un prompt sans ouvrir un ticket de support. Vous pouvez l'évaluer : quelqu'un peut distinguer une bonne sortie d'une mauvaise, avec des preuves plutôt que des impressions. Et vous pouvez le remplacer : vous connaissez les dépendances du système, le coût d'un déménagement et qui d'autre pourrait effectuer le travail.

La plupart des transferts ne fournissent que la première capacité et omettent les trois autres. C'est pourquoi les systèmes dérivent.

La documentation qui compte

La documentation est rédigée pour satisfaire une clause contractuelle, elle décrit donc une architecture que personne ne touchera jamais et omet les choses dont les gens ont réellement besoin. Gardez la liste courte et insistez sur ces éléments :

• Un manuel de dépannage pour les pannes. Les cinq problèmes les plus susceptibles de survenir, leur apparence depuis l'extérieur et les trois premières étapes pour chacun. Écrit pour la personne de service, pas pour un ingénieur.
• Un ensemble d'évaluation. Cent à deux cents cas réels avec la bonne réponse pour chacun, approuvés par les personnes qui effectuent le travail. C'est l'artefact le plus précieux de tout le projet.
• Un journal des modifications avec des raisons. Non seulement ce qui a été configuré, mais pourquoi une règle existe. Les règles sans raisonnement sont supprimées par la personne suivante.
• Une feuille de suivi des dépendances et des coûts. Chaque modèle, API et fournisseur ; le coût mensuel ; les dates de renouvellement du contrat ; ce qui casse si cela disparaît.
• Une carte des données. Où va les données, qui peut y accéder, combien de temps elle est conservée. Vos équipes juridiques et de sécurité auront besoin de cela sans préavis.

Tout le reste est facultatif. Si un document n'aide personne à exploiter, modifier, évaluer ou remplacer le système, c'est de la décoration.

Les trois personnes dont vous avez besoin

Vous n'avez pas besoin d'embaucher une équipe d'apprentissage automatique. Vous avez besoin de trois individus nommés, et vous devez les nommer avant le début du projet, pas pendant le dernier mois.

Un propriétaire commercial qui décide ce que le système doit faire et gère le budget. Ils approuvent les modifications et disent non à l'extension des délais. Ce n'est pas un rôle technique.

Un gardien technique qui peut lire la configuration, apporter une modification contrôlée, la tester et la mettre en production. Souvent un développeur existant ou un ingénieur IT avec de la capacité dégagée. Ils n'ont pas à construire de modèles ; ils doivent être capables de modifier et de déployer ce qui existe.

Un propriétaire qualité du département que le système sert - le gestionnaire de réclamations principal, l'infirmière en chef, le responsable du support. Ils maintiennent l'ensemble d'évaluation et décident ce qui signifie "bon". Sans ce rôle, la qualité devient une question d'opinion en quelques semaines.

Le coût total interne : généralement une fraction d'un poste à temps plein pour chacun, une fois le système stable. Le mode d'échec n'est pas les dépenses. C'est que personne n'a été nommé.

Testez le transfert pendant que vous pouvez encore vous plaindre

N'acceptez pas la documentation comme preuve du transfert. Effectuez un test en direct pendant les dernières semaines de l'engagement, tandis que les consultants sont toujours sous contrat.

Choisissez un changement réel - ajoutez un nouveau produit à la base de connaissances, resserrez une règle sur ce que le système refuse de répondre, remplacez une table des prix mise à jour. Demandez à votre propre équipe de le faire, avec les consultants dans la salle mais silencieux. Mesurez le temps qu'il faut. Ensuite, faites passer l'ensemble d'évaluation par votre propriétaire qualité pour confirmer rien d'autre ne s'est brisé.

Si votre équipe termine cela en une journée, vous possédez le système. Si cela prend une semaine et trois questions, vous avez trouvé exactement les lacunes à combler avant la fin des factures. Quel que soit le résultat, il vaut bien plus qu'un formulaire de transfert signé.

Insistez pour inclure cela dans le contrat dès le début. Les jalons de transfert, une équipe de réception nommée et un test de changement supervisé sont tous plus faciles à négocier avant le début des travaux qu'après.

C'est ainsi que nous construisons chez Hercules A, et cela signifie que nos engagements se terminent. C'est le but. La mesure d'un bon projet d'IA n'est pas la profondeur de l'implication des consultants un an plus tard - c'est la confiance avec laquelle vos propres personnes modifient le système sans appeler personne.