Elk project dat Blueriq doet, zal minstens één van bovenstaande elementen bevatten en daar zijn we gek op. Samen met de business zetten we een oplossing neer waar je wat in stopt en waar iets uitrolt. Wat er uitrolt, een taak, een status, een berekend bedrag, een goedkeuring of afwijzing, daar is goed over nagedacht. Gegeven een bepaalde situatie laten wij er logica op los en komen we met een mooi resultaat.
Het resultaat klopt, mits de logica klopt. En als het niet klopt, dan kunnen we het model doorlopen aan de hand van die logica. Echter, de gebruiker ziet dan vaak alleen dit laatste, het resultaat. Bij een bepaalde situatie heeft de gebruiker vaak ook een verwachting. "Ik had echt verwacht dat deze aanvraag werd goedgekeurd" of "Als ik deze waarde selecteer, verwacht ik dat het berekende bedrag zoveel omhooggaat". Wanneer het resultaat dat wij afleiden niet voldoet aan deze verwachting, dan is ofwel de afleiding waar het op gebaseerd is fout, ofwel de verwachting klopt niet. Tenminste, zo wordt het ervaren door de gebruiker.
Vraagtekens bij bestaande berekening
Laatst kreeg het team waarin ik zat een vraag over een berekening die al twee jaar niet meer aangepast was. Er worden gegevens in gestopt van een bestaande situatie, het één en ander wordt berekend en het uiteindelijke resultaat zegt of wel of niet kan. Is er geld over dan past het, is er een tekort, dan past het niet. De berekening werkte al jaren zo. Echter, het team dat gebruik maakt van deze berekening is inmiddels van samenstelling gewijzigd en in de afgelopen jaren is de kennis van "wat het systeem doet" vervaagd. Er werden vraagtekens gesteld bij het resultaat: "Volgens ons klopt dit niet!". Tijd om het na te gaan rekenen.
Stap voor stap hebben we gerekend en opgeschreven wat er gebeurt en onder welke aannames dit gebeurt. We namen de gebruiker mee door deze berekening tot we - tot op de cent nauwkeurig - op het tekort kwamen dat uit het systeem rolde. "Oooh... als je het zo zegt... ja, dit klopt!". Met nog een beetje argwaan kwamen ze met een nieuwe casus: "Leuk die uitleg, maar deze klopt ook niet!". Opnieuw rekenden we de situatie na, hier waren wat andere uitgangspunten, met een ander pad door de berekening. "Ja... dit klopt ook, bedankt!". En met deze uitleg is er een sessie georganiseerd om de medewerkers van het systeem opnieuw uit te leggen hoe de berekening in elkaar steekt. De escalatie die op de loer lag was niet meer nodig, want de berekening was gewoon goed.
Een (extra) verklaring is soms gewoon nodig
Wanneer je werkt met interne medewerkers die werken met deze applicatie is zo’n situatie gemakkelijk op te lossen. Het zijn slimme mensen die gewoon een ticket kunnen inschieten of ons kunnen bereiken via diverse kanalen en het willen begrijpen. Lastiger is het wanneer de "onbekende" consument online gebruik maakt van een complexe bepaling. Wanneer een applicatie dan een resultaat geeft dat onbegrip oplevert, horen wij dat niet meteen. In het geval van een openbaar beschikbare berekening zal diegene wellicht gewoon naar de concurrent stappen.
Waar voorheen het resultaat genoeg was, is er tegenwoordig steeds meer behoefte aan een verklaring bij een resultaat. Men wil niet alleen weten wat eruit komt, maar ook waarom dat eruit komt. Zodat ze dit kunnen toelichten aan hun klant, zodat ze dit kunnen narekenen en vergelijken, zodat ze dit kunnen toetsen tegen wet- en regelgeving of gewoon zodat ze er een goed gevoel bij hebben dat wat er gebeurd is, juist is. Heel begrijpelijk.
De kunst zit dan in het maken van een goede verklaring. Het maken van een goede verklaring, onderbouwing, uitleg, explainable AI, geef het een naam, is niet triviaal. Het is niet iets dat zomaar automatisch volgt uit alle afleidingen die er razendsnel hebben plaatsgevonden. Immers, er gebeurt onder water vaak véél meer dan wat een gebruiker wil weten. Een gebruiker is vaak geïnteresseerd in net genoeg, met soms wat extra. Hier en daar tekst en uitleg met waarom een bepaalde berekening heeft plaatsgevonden, wat daar de parameters van zijn en welke uitgangspunten belangrijk waren om tot dit resultaat te komen. Een verklaring hoeft dus niet helemaal compleet te zijn, maar wel goed genoeg en met net genoeg informatie voor de gebruiker. Net genoeg om te snappen wat er is gebeurd, zonder meteen alles prijs te geven.
Het maken van een goede verklaring is dus net als het maken van goede logica, best complex. Maar ach, daar zijn we bij Blueriq gek op!
