Een besluitvormingsproces
The Kanso Filter.
Zes vragen voordat een wijziging wordt opgeleverd.
Wij doorlopen dit voordat wij een wijziging aan een serviceteam aanbevelen. De meeste wijzigingen die mislukken, mislukken niet in de bouw. Ze worden opgeleverd zonder een duidelijk antwoord op één van deze zes vragen. The filter dwingt die antwoorden af voordat het werk begint, terwijl het nog goedkoop is om op te handelen. Gebruik het op uw eigen beslissingen, op voorstellen van leveranciers, en op de onze.
Waarom dit bestaat
Het begon als een opsomming van werk dat nergens toe leidde.
Wij bleven wijzigingen zien die werden opgeleverd en een workflow, een integratie of een scherm toevoegden, en zes maanden later waren de cijfers waarop het team werd beoordeeld niet bewogen. De inspanning was reëel. Het resultaat niet. Dus schreven wij de vragen op die, achteraf bezien, elk van die wijzigingen zouden hebben tegengehouden voordat iemand ze had gebouwd. Die lijst is the filter. Hij is bewust direct: als een wijziging deze vragen niet kan beantwoorden, is de eerlijke keuze om die niet door te voeren.
Elk onderdeel vangt een faalpatroon af voordat het wordt opgeleverd.
01
Verwijdert het een stap?
Stappen zijn klikken, formuliervelden, opzoekacties, overdrachten, beslissingen die het team moet nemen.
02
Beweegt het een meetwaarde die u bezit?
Afhandeltijd, klanteninspanning, CSAT, first-contact resolution, lifetime value. Kies degene waarop het team wordt beoordeeld, niet de makkelijkste om te tellen.
03
Verbetert het de nauwkeurigheid of kwaliteit?
Meetbaar. Benoem de meetwaarde vóór implementatie.
04
Beperkt het de onderhoudslast tot een minimum?
Weeg het doorlopende onderhoud, de single points of failure en de technische schuld die het team daarna draagt, niet alleen de tijdsbesparing.
05
Verslaat native de maatwerkaanpak?
Platform-roadmaps bewegen sneller dan maatwerksoftware.
06
Kunt u de meetwaarde benoemen die het moet bewegen, en hoe u die gaat meten?
Benoem de meetwaarde en het venster voordat u begint, zodat u achteraf kunt zien of het heeft gewerkt.
Wat nu te doen
Beslis op basis van materiële verbetering, niet op besparing.
Een wijziging verdient zijn plek wanneer het een meetwaarde die u bezit genoeg beweegt om op te vallen. Besparing is één input, niet de toets. Als u de meetwaarde, de doelstelling en het venster niet kunt benoemen voordat u begint, kunt u achteraf niet zeggen of de wijziging heeft gewerkt, en zo mislukt een wijziging stilletjes: niemand heeft de meetwaarde vastgesteld die het zou hebben aangetoond. Laat het dus snel mislukken. Elimineer het zwakke idee in de vraagfase, waar het een middag kost, niet na de bouw, waar het een kwartaal kost. Het punt van the filter is die middag te benutten.
Voer het nu uit
Scoor uw wijziging.
Beantwoord elke vraag voor de wijziging die u overweegt. Het oordeel wordt bijgewerkt terwijl u doorgaat. Niets wat u typt verlaat uw browser.
01
Verwijdert het een stap?
02
Beweegt het een meetwaarde die u bezit?
03
Verbetert het de nauwkeurigheid of kwaliteit?
04
Beperkt het de onderhoudslast tot een minimum?
05
Verslaat native de maatwerkaanpak?
06
Kunt u de meetwaarde benoemen die het moet bewegen, en hoe u die gaat meten?
Lopend oordeel
0 van 6 met ja beantwoord
Dit werkt volledig in uw browser. Wij zien uw antwoorden niet en slaan ze niet op.
Hoe te gebruiken
Loop de zes vragen in volgorde door. Beslis dan.
- Alle zes jaOpleveren.
- Vier of vijfOpleveren met expliciete notities over de hiaten.
- Minder dan vierNiet opleveren. De scope klopt niet, of de wijziging levert niet genoeg op om het onderhoud te rechtvaardigen.
Waarom wijzigingen mislukken
Een wijziging mislukt zelden omdat die slecht gebouwd was.
Ze mislukt omdat niemand de meetwaarde heeft benoemd die die moest verbeteren, waardoor achteraf niemand kon zeggen of dat ook was gebeurd. Of omdat het onderhoud stilletjes groter werd dan de waarde. Of omdat het platform hetzelfde drie maanden later native heeft opgeleverd en de maatwerkaanpak een last was geworden.
De oplossing is niet meer discipline tijdens de bouw. Het is goed beslissen vóór de bouw. Kies de meetwaarde die u bezit, spreek de doelstelling en het venster af, en controleer eerst of native u al het meeste bereikt. Als een wijziging geen materiële verbetering kan aantonen, is de juiste keuze meestal om die niet door te voeren.
Uitgewerkt voorbeeld
Auto-tagging AI deployen op Zendesk.
The filter toegepast, regel voor regel, op een echte beslissing.
| # | Vraag | Oordeel | Notities |
|---|---|---|---|
| 01 | Verwijdert het een stap? | Ja | Elimineert handmatige tagging bij 80% van de tickets. |
| 02 | Beweegt het een meetwaarde die u bezit? | Ja | Snellere routering verlaagt time-to-first-response; ~45 sec × 30.000 tickets/maand = 375 uur terug naar de wachtrij. |
| 03 | Verbetert het de nauwkeurigheid? | Misschien | Basisvergelijking nodig vóór go-live. |
| 04 | Beperkt het de onderhoudslast tot een minimum? | Misschien | Kwartaallijkse modelhertraining (klein), zonder nieuw single point of failure, maar het moet zijn plek verdienen. |
| 05 | Verslaat native de maatwerkaanpak? | Misschien | Controleer eerst de native auto-tagging van Zendesk. |
| 06 | Kunt u de meetwaarde benoemen die het moet bewegen, en hoe u die gaat meten? | Ja | Tagging- en routeringsnauwkeurigheid vooraf benoemd, wekelijks gevolgd ten opzichte van een basislijn. |
| Filterresultaat | Opleveren als native de taxonomie niet dekt. Anders native gebruiken. | ||
Overweegt u een wijziging?
Wij financieren een beperkt aantal Maturity Mapping-assessments voor teams met een actueel serviceprobleem. Dien uw aanvraag in met de meetwaarde die u wilt verbeteren, en als het niet past, zeggen wij dat.