Hoe goede systemen het vertrouwen van hun gebruikers winnen

Drie weken nadat in het magazijn van een fabrikant van medische producten een systeem voor goederenontvangst 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. De meest ervaren magazijnleider had naast het systeem een uitgeprinte lijst op haar bureau liggen. Elke ontvangst die het systeem bevestigde, controleerde ze nog eens met de hand tegen de levering: lotnummers, houdbaarheidsdata, aantallen.

Ze had niets tegen verandering. Ze deed dit werk al jaren, ze was verantwoordelijk voor wat er in de voorraad kwam, 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 behandelen dit nu als een kwestie van vertrouwen dat past bij wat het systeem werkelijk presteert, omdat zulk vertrouwen te meten en via het ontwerp te sturen is. Het is ook een probleem van beheersing. De beheersmaatregel in de procesdocumentatie was niet de maatregel die werkelijk werkte: de auditor toetst de bevestigingen van het systeem, en de controle die telde, gebeurde op een uitgeprinte lijst die niemand archiveert.

Het doel is vertrouwen dat past bij het bewijs

Het doel is dat mensen het systeem 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 uitgeprinte lijst en een team dat het werk dubbel doet. Dat is een kwestie van de organisatie rond het systeem, en daar gaat dit stuk over. Training lost dat zelden 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. In die opdracht hadden we alleen naar de eigen cijfers van het systeem gekeken, en daarom kostte het drie weken en een ochtend op de werkvloer om de uitgeprinte lijst te vinden. Elk van deze twee cijfers had het in de eerste dagen laten zien.

Controlepercentage. Hoe vaak mensen de pakbon, het record in het ERP of een eigen lijst openen voordat ze een voorstel accepteren dat ze direct hadden kunnen accepteren. Het meeste komt uit gegevens die het systeem al heeft: geopende onderbouwingen, gemaakte exports, de tijd tussen het verschijnen van een voorstel en de acceptatie ervan, en wijzigingen die rechtstreeks in het ERP zijn gedaan in plaats van via de workflow. 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.

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. Van de twee is dit het cijfer dat we het nauwst volgen. 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 een demonstratie.

Het onderzoek wijst dezelfde kant op. Dietvorst, Simmons en Massey lieten in 2015 zien dat mensen sneller het vertrouwen in een algoritme verliezen dan in een mens als ze beide dezelfde fout zien maken, en het algoritme zelfs mijden als ze hebben gezien dat het beter presteert dan een mens. Hun vervolgstudie in Management Science (2018) liet zien dat mensen een onvolmaakt algoritme veel eerder gebruiken als ze de uitkomst kunnen aanpassen, al is het maar een beetje. In een lab is dat een schuifregelaar. In een operatie is het een correctie die blijft.

Het correctielogboek legt beide datums vast, en elke correctie die langer dan een week openstaat, gaat naar de wekelijkse bespreking, met de naam van de eigenaar van de oplossing.

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: hoeveel gevallen elke werksoort moet doorlopen, welke afwijkingen een werksoort uitsluiten, en een beoordeling van elke afwijking. Werksoorten gaan één voor één uit shadow mode, zodra ze aan de criteria voldoen, en de oude werkwijze wordt op dezelfde manier afgebouwd. De eerste werksoorten die live gaan, zijn die waarin het systeem het sterkst is, en de moeilijke volgen zodra het team heeft gezien dat het een tijd lang gelijk heeft. 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 lopen het team en een engineer elke week alle gevallen door waarin het systeem en een medewerker tot een ander oordeel kwamen, en sluiten ze elk af met één vastgelegde uitkomst.

• Het systeem had ongelijk. Een regel of mapping wordt aangepast, binnen dagen en niet binnen weken.
• 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 vaak het nuttigst om vast te leggen.
• 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 doorgaans 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 voor die werksoort het vertrouwen van het team verdiend.

De experts worden eigenaar van de regels

Een diepere oorzaak van omzeilen is vaak een rolwisseling die niemand heeft benoemd. Voor de komst van het systeem was de ervaren magazijnleider degene die wist hoe een lastige levering moest worden geboekt. 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 etiketformaten 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

De meeste operationele teams vragen 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.

We vragen ook om productiviteitsdoelen tijdens de overgang tijdelijk los te laten. Wie wordt afgerekend op ontvangsten per uur, heeft goede redenen om een systeem te mijden dat hem vertraagt zolang hij het nog leert kennen.

Vertrouwen volgt de snelheid van correctie

Uiteindelijk was de uitgeprinte lijst een van de nuttigste dingen in dat magazijn. Hij liet zien welke gevallen het systeem nog niet had verdiend, en hij maakte duidelijk dat het te lang duurde voordat haar correcties effect hadden. Zodra een correctie het systeem binnen een paar dagen veranderde, printte ze hem niet meer. Meet de correctietijd vanaf de eerste week na de livegang, en houd hem onder een week.