Alles laten nakijken klinkt degelijk. In de praktijk wordt er bij een wijzigingenlijst nu eenmaal gescand. Een conceptrapport heeft zo veertig wijzigingen, bijna allemaal onschuldig: een komma, een kortere zin, een ander woord voor "implementeren". Wie ze allemaal even grondig leest, leest de vier die ertoe doen net zo vluchtig als de rest. En wie ze allemaal even vluchtig leest, mist die vier.
De oplossing is dus niet meer controle. Het is vooraf beslissen welke wijzigingen een oordeel vragen, zodat de aandacht daar zit waar ze nodig is.
Welke fase dit is
SEAL beschrijft de vier fasen die kenniswerk doorloopt: Source, Edit, Approve, Launch. In elke fase kan de herleidbaarheid van een bron verloren gaan, en de zwakste fase bepaalt wat het werk waard is.
Dit is een kwestie van Approve. De vraag van die fase is: wie heeft de inhoud getoetst, met welke vakkennis, en waarop?
Approve gaat meestal mis doordat niemand heeft vastgelegd wat er getoetst moet worden. Dan zijn er twee uitkomsten, en beide deugen niet. Of alles gaat langs een vakinhoudelijk oordeel, waardoor het toezicht in een drukke week vanzelf verdampt. Of niets gaat erlangs, omdat "het is maar een kleine aanpassing". De fase werkt andersom: niet meer ogen, maar minder momenten. Alleen de risicovolle wijzigingen vragen een oordeel, en dan wel een echt oordeel, met de bron ernaast en de uitkomst vastgelegd.
De oorzaak: grootte is niet het risico
Het ligt voor de hand om wijzigingen te sorteren op omvang. Een alinea herschrijven voelt zwaarder dan een woord vervangen. Maar het risico zit in wat een wijziging met de bewering doet.
Het kleinste woord dat er bestaat is "niet". Eén cijfer verschuiven, "de meeste" in "alle" veranderen of "kan" in "zal": het zijn wijzigingen van één woord die de tekst iets anders laten beweren. Een hele alinea herschrijven om de zinsbouw te verbeteren kan inhoudelijk niets veranderen.
De scheidslijn is daarom deze: een wijziging vraagt een oordeel als ze verandert wat de tekst beweert, niet als ze verandert hoe de tekst klinkt.
De toets: drie bakken
Loop de wijzigingenlijst langs en gooi elke wijziging in een van drie bakken.
1. Meelezen. Spelling, opmaak, interpunctie, een andere volgorde van alinea's waarbij de betekenis niet verschuift. Eén blik is genoeg. Er hoeft geen vinkje bij.
2. Naast de bron leggen. Een zin met een bewering is anders geformuleerd, maar zou hetzelfde moeten zeggen. Wie de wijziging maakt of nakijkt, legt de zin naast de bronpassage en ziet of er nog hetzelfde staat. Dat kost een minuut en vraagt geen specialist.
3. Oordeel. De wijziging verandert wat er beweerd wordt. Denk aan:
- een getal, naam, datum of bedrag;
- een hoeveelheid of bereik ("een deel van", "de meeste", "alle");
- de stelligheid ("kan", "lijkt", "zal");
- een conclusie of aanbeveling;
- een juridische of financiële passage;
- alles wat een AI-systeem heeft geschreven of herschreven zonder dat er een bron bij staat.
Bij een oordeel kijkt iemand met de vakkennis om te beslissen, met de bron naast de zin, en de uitkomst wordt vastgelegd. De goedkeuring hangt aan de passage: wordt die later opnieuw gewijzigd, dan vervalt ze. Dat is de kern van Edit en daarom werkt Approve alleen als de twee fasen op elkaar aansluiten.
Twijfel je over de bak, kies dan de zwaardere. Dat kost af en toe een minuut. De andere kant op kost een fout onder je naam.
Een voorbeeld
Een verzonnen voorbeeld, om de bakken in werking te zien. Een conceptadvies telt veertien wijzigingen:
- Negen zijn meelezen: drie spelfouten, twee kopjes, vier komma's.
- Drie gaan naar de bron: zinnen die korter zijn gemaakt, waarbij de bronpassage laat zien dat er niets is weggevallen.
- Twee vragen een oordeel. In de eerste is "circa zes weken" veranderd in "zes weken", waarmee de marge uit de planning is verdwenen. In de tweede is "wordt aanbevolen" veranderd in "is noodzakelijk", waarmee een advies een eis wordt.
Dat is twee oordelen van veertien, en dat is precies het punt. Iemand met vakkennis besteedt een kwartier aan wat die kennis nodig heeft, en de rest van de lijst kost vijf minuten.
Wat je van een systeem mag vragen
Gebruik je een tool voor het schrijven of redigeren, dan komt dezelfde vraag terug in TRACES, bij de laag Approval: bevestigt een mens de inhoud, gedifferentieerd naar het soort wijziging, en wordt die bevestiging vastgelegd?
TRACES zijn de zes lagen waarop je een AI-systeem toetst: Trail, Retrieval, Approval, Constraints, Expertise, Storage. Ontbreekt een laag, dan zit daar een risico.
Een systeem dat elke wijziging gelijk behandelt, doet het niet. Bij alles om goedkeuring vragen leidt tot doorklikken. Bij niets vragen houdt het op. Een bruikbaar systeem toont per wijziging welke bak het is, laat de bronpassage zien bij een oordeel en bewaart wie wat wanneer heeft goedgekeurd.
Wat je deze week kunt doen
- Pak het laatste document dat jullie hebben herzien, liefst met zichtbare wijzigingen of een eerdere versie ernaast. Een stuk dat met AI is herschreven werkt ook.
- Sorteer elke wijziging in een van de drie bakken. Tel ze.
- Kijk per bak wat er in de praktijk is gebeurd. Heeft iemand de wijzigingen uit bak 3 met de bron ernaast bekeken, of zijn ze meegelezen?
- Schrijf op één pagina op wat bij jullie een oordeel vraagt: vijf tot zeven regels, in jullie eigen woorden, naar het lijstje hierboven. Hang het aan het werkproces, niet aan een map die niemand opent.
Het verschil tussen bak 3 en wat er werkelijk is nagekeken, is jullie lek bij Approve.