Un an avant même de pouvoir planifier.

Le fabricant avait pris un nouveau programme d’aéronef. Il est arrivé avec cent vingt mille pièces, chacune portant une description et aucune ne portant de classification de fabrication.

Ça vaut la peine d’être précis sur ce qui était bloqué, parce que ce n’était pas la production. C’était la planification. Une pièce ne peut pas être assignée à une usine tant que quelqu’un ne sait pas de quel genre de pièce il s’agit, et tant que chaque pièce n’est pas assignée il n’y a aucun plan de fabrication à ordonnancer, à chiffrer, à doter ou à promettre à un client. Le programme n’attendait pas d’être construit. Il attendait d’être planifié.

Une équipe avait été assignée à la classification manuelle. Après deux mois, elle en avait réglé entre dix et vingt mille, laissant plus de cent mille à faire. À ce rythme le programme aurait attendu environ un an avant que la planification puisse commencer, et les gens qui classaient étaient ceux-là mêmes dont l’usine avait besoin ailleurs.

Certains problèmes n’exigent pas un système qui reste. Ils exigent un système bâti précisément autour d’une contrainte, lancé une fois sous surveillance, puis retiré parce que le problème n’existe plus. Aucun système à entretenir, à surveiller ou à payer après notre départ.

Le test était le même que nous appliquons à tout : le travail était documenté au sens où une règle de classification existait, il était surtout règles plutôt que jugement, les entrées étaient du texte structuré, et la sortie pouvait être révisée avant d’aller où que ce soit. C’est cette combinaison qui rend un problème de cette forme soluble en jours plutôt qu’en trimestres.

1. Définir ce que veut dire correct

   Nous sommes partis des règles de classification de l’usine et d’un échantillon que l’équipe d’ingénierie avait déjà fait à la main, pour que la norme soit la leur plutôt que la nôtre.

2. Tester avant de toucher aux vraies données

   Le classificateur a été lancé sur l’échantillon fait à la main et ajusté jusqu’à ce que sa sortie corresponde à ce que les ingénieurs auraient produit. C’est seulement ensuite qu’il a été lancé sur l’ensemble complet.

3. Le lancer sous surveillance

   Le lancement complet s’est fait avec des gens qui regardaient la sortie à mesure, pas en lisant un rapport après. Les sorties de faible confiance ont été séparées pour révision plutôt que poussées.

4. Valider, documenter, fermer

   Le résultat a été vérifié par rapport à la contrainte d’origine, la méthode a été écrite, et le mandat s’est terminé. Il n’y avait pas de système à transférer parce qu’il n’y avait plus de problème.

La plupart des opérations portent au moins une contrainte acceptée comme permanente parce que la régler à la main n’allait jamais être abordable. Très souvent ce n’est pas du tout un problème de processus. C’est un problème de données assis en dessous : le même fournisseur entré quatre fois dans l’ERP sous quatre orthographes, des numéros de pièces qui ne se réconcilient pas entre deux systèmes, une liste de clients où personne ne peut dire quels dossiers sont actifs, des champs optionnels pendant une décennie et devenus porteurs. L’équipe n’est pas lente. L’équipe contourne quelque chose.

La question utile n’est pas de savoir si le travail pourrait être automatisé. C’est de savoir si la règle pour le faire correctement peut être écrite, et si quelqu’un peut vérifier la sortie avant qu’on s’y fie. Quand les deux réponses sont oui, c’est habituellement des jours plutôt que des trimestres, et la chose traitée comme une fatalité s’avère avoir été un arriéré.