Un processus de décision
The Kanso Filter.
Six questions avant qu'un changement soit livré.
Nous appliquons ce filtre avant de recommander tout changement à une équipe de service. La plupart des changements qui échouent n'échouent pas lors du développement. Ils sont livrés sans réponse claire à l'une de ces six questions. Le filtre fait émerger ces réponses avant que le travail commence, pendant qu'il est encore peu coûteux d'agir. Utilisez-le pour vos propres décisions, pour les propositions d'éditeurs, et pour les nôtres.
Pourquoi ce filtre existe
Tout a commencé comme un bilan de travaux qui n'ont mené nulle part.
Nous avons vu se succéder des changements livrés qui ajoutaient un workflow, une intégration, un écran. Et six mois plus tard, les chiffres sur lesquels l'équipe était jugée n'avaient pas bougé. L'effort était réel. Le résultat ne l'était pas. Nous avons donc consigné les questions qui, avec le recul, auraient stoppé chacun de ces changements avant que quiconque ne les développe. Cette liste, c'est le filtre. Il est délibérément direct : si un changement ne peut pas répondre à ces questions, la décision honnête est de ne pas le faire.
Chacune identifie un mode d'échec avant qu'il ne se produise.
01
Est-ce que ça supprime une étape ?
Les étapes sont des clics, des champs de formulaire, des recherches, des transferts, des décisions que l'équipe doit prendre.
02
Est-ce que ça fait bouger un indicateur que vous possédez ?
Temps de traitement, effort client, CSAT, résolution au premier contact, valeur à vie. Choisissez celui sur lequel l'équipe est jugée, pas le plus facile à mesurer.
03
Est-ce que ça améliore la précision ou la qualité ?
Mesurable. Nommez l'indicateur avant le déploiement.
04
Est-ce que ça réduit la charge de maintenance ?
Pesez la charge de maintenance continue, les points de défaillance uniques et la dette technique que l'équipe porte ensuite, pas seulement le temps économisé.
05
Le natif fait-il mieux que le sur-mesure ?
Les feuilles de route des plateformes évoluent plus vite que le code sur mesure.
06
Pouvez-vous nommer l'indicateur qu'il devrait faire évoluer, et comment vous le mesurerez ?
Nommez la mesure et la fenêtre avant de commencer, afin de pouvoir dire ensuite si cela a fonctionné.
Que faire ensuite
Décidez sur la base d'une amélioration substantielle, pas du coût économisé.
Un changement mérite sa place quand il fait évoluer un indicateur que vous possédez de façon perceptible. Le coût économisé est une entrée parmi d'autres, pas le critère. Si vous ne pouvez pas nommer l'indicateur, la cible et la fenêtre de mesure avant de commencer, vous ne pourrez pas dire ensuite si le changement a fonctionné. C'est ainsi qu'un changement échoue silencieusement : personne n'a fixé la mesure qui l'aurait montré. Échouez vite. Éliminez l'idée faible au stade des questions, quand cela coûte une après-midi, et non après le développement, quand cela coûte un trimestre. L'intérêt du filtre, c'est de passer cette après-midi.
Testez-le maintenant
Évaluez votre changement.
Répondez à chaque question pour le changement que vous étudiez. Le verdict se met à jour au fur et à mesure. Rien de ce que vous saisissez ne quitte votre navigateur.
01
Est-ce que ça supprime une étape ?
02
Est-ce que ça fait bouger un indicateur que vous possédez ?
03
Est-ce que ça améliore la précision ou la qualité ?
04
Est-ce que ça réduit la charge de maintenance ?
05
Le natif fait-il mieux que le sur-mesure ?
06
Pouvez-vous nommer l'indicateur qu'il devrait faire évoluer, et comment vous le mesurerez ?
Verdict en cours
0 sur 6 réponses oui
Cela fonctionne entièrement dans votre navigateur. Nous ne voyons pas vos réponses et ne les stockons pas.
Comment l'utiliser
Parcourez les six questions dans l'ordre. Puis décidez.
- Six oui sur sixLivrez.
- Quatre ou cinqLivrez avec des notes explicites sur les lacunes.
- Moins de quatreNe livrez pas. Le périmètre n'est pas bon, ou le changement ne génèrera pas assez de valeur pour justifier la maintenance.
Pourquoi les changements échouent
Un changement échoue rarement parce qu'il a été mal développé.
Il échoue parce que personne n'a nommé l'indicateur qu'il était censé faire bouger, personne ne pouvait donc dire ensuite s'il l'avait fait. Ou parce que la charge de maintenance a silencieusement dépassé la valeur apportée. Ou parce que la plateforme a livré la même chose nativement trois mois plus tard et que le développement sur mesure est devenu un passif.
La solution n'est pas plus de discipline au moment du développement. C'est de bien décider avant le développement. Choisissez l'indicateur que vous possédez, convenez de la cible et de la fenêtre, et vérifiez d'abord si le natif vous amène la majeure partie du chemin. Si un changement ne peut pas montrer une amélioration significative, la bonne décision est généralement de ne pas le faire.
Exemple concret
Déploiement d'une IA d'auto-tagging sur Zendesk.
Le filtre appliqué, question par question, à une décision réelle.
| N° | Question | Verdict | Notes |
|---|---|---|---|
| 01 | Est-ce que ça supprime une étape ? | Oui | Élimine le tagging manuel sur 80 % des tickets. |
| 02 | Est-ce que ça fait bouger un indicateur que vous possédez ? | Oui | Un routage plus rapide réduit le délai avant première réponse ; ~45 sec × 30 000 tickets/mois = 375 heures rendues à la file d'attente. |
| 03 | Est-ce que ça améliore la précision ? | Peut-être | Une comparaison avec la base de référence est nécessaire avant le lancement. |
| 04 | Est-ce que ça réduit la charge de maintenance ? | Peut-être | Réentraînement trimestriel du modèle (faible), sans nouveau point de défaillance unique, mais il doit mériter sa place. |
| 05 | Le natif fait-il mieux que le sur-mesure ? | Peut-être | Vérifiez d'abord l'auto-tagging natif de Zendesk. |
| 06 | Pouvez-vous nommer l'indicateur qu'il devrait faire évoluer, et comment vous le mesurerez ? | Oui | Précision du tagging et du routage nommée d'emblée, suivie chaque semaine par rapport à une base de référence. |
| Résultat du filtre | Livrez si le natif ne couvre pas la taxonomie. Sinon, utilisez le natif. | ||
Vous évaluez un changement ?
Nous finançons un nombre limité d'évaluations Maturity Mapping pour les équipes confrontées à un problème de service concret. Postulez avec l'indicateur que vous souhaitez faire évoluer, et si votre situation ne correspond pas, nous vous le dirons.