Goede systemen worden vaak ongemerkt omzeild

Drie weken nadat een matchingsysteem live was gegaan, zagen de cijfers er goed uit, maar de werkdruk van het team was niet gedaald. We zaten een ochtend bij het team om uit te zoeken hoe dat kon. Een van de meest ervaren medewerkers had naast het systeem een spreadsheet openstaan. Elke match die het systeem voorstelde, typte ze over en controleerde ze met de hand voordat ze hem accepteerde.

Ze had niets tegen verandering. Ze deed dit werk al jaren, ze was verantwoordelijk voor de juistheid ervan, en niets in het systeem liet haar zien wanneer het te vertrouwen was. Dus vertrouwde ze het nooit en controleerde ze alles. Het systeem werkte. In de praktijk werd het omzeild.

We noemen dit geen adoptieprobleem meer. Het gaat om vertrouwen dat past bij wat het systeem werkelijk presteert, en dat is, anders dan adoptie, te meten en via het ontwerp te sturen.

Het doel is vertrouwen dat past bij het bewijs

Het doel is niet dat mensen het systeem vertrouwen. Het doel is dat ze het precies zoveel vertrouwen als het verdient, per geval. Te veel vertrouwen leidt tot blind aftekenen, en de oplossing daarvoor ligt in het goedkeuringsscherm. Te weinig vertrouwen leidt tot de spreadsheet naast het scherm en een team dat het werk dubbel doet. Dat is een kwestie van de organisatie eromheen, en daar gaat dit stuk over. Training lost geen van beide op. Mensen bouwen vertrouwen op met bewijs uit hun eigen gevallen, niet met uitleg over hoe het systeem werkt.

Twee cijfers laten zien waar vertrouwen ontbreekt

Vanaf de eerste dag na de livegang volgen we twee cijfers, per werksoort en per team, nooit per persoon.

Controlepercentage. Hoe vaak mensen het brondocument, het record in het ERP of een eigen bestand openen voordat ze een voorstel accepteren dat ze direct hadden kunnen accepteren. Een hoog controlepercentage bij een werksoort waar het systeem betrouwbaar gelijk heeft, betekent dat het vertrouwen achterloopt op het bewijs. Dat is waardevolle informatie, geen gedrag dat moet worden afgeleerd: het wijst precies aan welke werksoorten in de ogen van het team nog geen vertrouwen hebben verdiend.

Correctietijd. De tijd tussen het moment dat een medewerker het systeem corrigeert en het moment dat het systeem zich voor dat soort gevallen anders gaat gedragen. Dit cijfer is het belangrijkste, en bijna geen project meet het. Als een expert dezelfde fout drie keer corrigeert en er verandert niets, concludeert ze terecht dat haar correcties niet tellen, en controleert ze alles. Verandert de regel binnen een paar dagen en ziet ze de fout verdwijnen, dan groeit het vertrouwen sneller dan met welke demonstratie ook.

Shadow mode stopt op criteria die het team mee heeft bepaald

Voordat een systeem zelf iets doet, draait het in shadow mode: het verwerkt dezelfde gevallen als het team, de voorstellen worden vastgelegd en het team werkt zoals altijd. Elke dag worden de voorstellen vergeleken met wat de medewerkers werkelijk deden.

Shadow mode is gangbaar. Of het werkt, hangt af van hoe het stopt. De exitcriteria worden vooraf met het team en de proceseigenaar afgesproken: een minimumaantal gevallen per werksoort, geen enkele afwijking waarbij het systeem ongelijk had in een veld dat geld beweegt, en elke afwijking beoordeeld. Werksoorten gaan één voor één uit shadow mode, zodra ze aan de criteria voldoen, en de oude werkwijze wordt op dezelfde manier afgebouwd, werksoort voor werksoort en nooit op een vaste datum. Het team ziet het bewijs groeien tegen een norm die het zelf mee heeft vastgesteld, in plaats van een livedatum opgelegd te krijgen.

Elke afwijking eindigt in een van vier uitkomsten

In de eerste maanden bespreken het team en een engineer elke week alle gevallen waarin het systeem en een medewerker tot een ander oordeel kwamen. Elk geval wordt afgesloten met één vastgelegde uitkomst.

• Het systeem had ongelijk. Een regel of mapping wordt aangepast, binnen dagen en niet binnen weken. Hier wordt de correctietijd gewonnen of verloren.
• De medewerker had ongelijk. Meestal een gewoonte die in de loop der tijd van het beleid is afgeweken. De proceseigenaar beslist of de gewoonte of het beleid verandert, en laat het team dat weten.
• Beide waren te verdedigen. De proceseigenaar beslist, en dat besluit wordt een geschreven regel. Dit zijn de ongeschreven beleidsregels die alleen in de hoofden van mensen bestonden, en ze zijn waardevoller dan alle andere.
• De invoer was het probleem. Een document van een leverancier of een fout in de stamgegevens was de oorzaak. Het gaat terug naar de bron en wordt daar opgelost.

Uit de verhouding tussen die vier blijkt hoe ver het systeem is. In het begin zijn de meeste afwijkingen fouten van het systeem, later gaan ze vooral over beleid. Komen afwijkingen nog maar zelden voor en gaan ze vooral over beleid, dan heeft het systeem het vertrouwen van het team verdiend.

De experts worden eigenaar van de regels

De diepste oorzaak van omzeilen is een rolwisseling die niemand heeft benoemd. Voor de komst van het systeem was de ervaren medewerker degene die wist hoe een lastige betaling moest worden gematcht. Daarna was ze gebruiker van een tool die haar oude werk deed, met een vage plicht om het te controleren. Dat voelt als een degradatie, hoe het projectplan het ook noemt.

Daarom veranderen de rollen uitdrukkelijk. De meest ervaren mensen worden eigenaar van de regels en uitzonderingsoorzaken in hun domein. Zij keuren wijzigingen in toleranties goed, zij bepalen hoe nieuwe documentformaten van leveranciers worden verwerkt, en hun namen staan bij de regels. De nauwkeurigheid van het systeem wordt hun verantwoordelijkheid en hun prestatie, en kennis die in één hoofd zat, wordt vastgelegd in regels die het hele team kan lezen.

De sponsor zet het doel op papier

Elk operationeel team vraagt zich af of een nieuw systeem bedoeld is om hen te vervangen. Als niemand die vraag beantwoordt, vult het team het antwoord zelf in. Voordat shadow mode begint, vragen we de sponsor drie dingen op te schrijven en met het team te delen: waar het team meer tijd aan gaat besteden, waar minder, en wat het bedrijf met de vrijgekomen capaciteit wil doen. In het werk dat wij aannemen, is dat doel capaciteit voor groei. Een systeem dat afhankelijk is van correcties door mensen die zich erdoor bedreigd voelen, krijgt die correcties niet.

We vragen ook om productiviteitsdoelen tijdens de overgang tijdelijk los te laten. Wie wordt afgerekend op gevallen per uur, negeert heel verstandig een systeem dat hem vertraagt zolang hij het nog leert kennen.

Vertrouwen volgt de snelheid van correctie

De spreadsheet naast het scherm was het nuttigste wat we in die opdracht tegenkwamen. Hij liet zien welke gevallen het systeem nog niet had verdiend, en hij vertelde ons dat het te lang duurde voordat haar correcties effect hadden. Zodra een correctie het systeem binnen een paar dagen veranderde, opende ze hem niet meer. Niemand hoefde het haar te vragen.