Wat betaalt deze klant voor deze vier artikelen, en welke leveranciers
hebben ze allemaal?
Dat is een vraag van een paar seconden en toch een half uur werk. Iemand klikt in het boekhoudpakket van klant naar prijslijst naar artikel, vier keer achter elkaar, en typt het antwoord over in een mail. Wij bouwden voor een klant een koppeling die dezelfde vraag in gewone taal laat stellen, rechtstreeks in een gesprek met Claude. Dit is wat we daarbij hebben geleerd, en wat je ervan kunt overnemen als je iets vergelijkbaars wil.
De klant blijft anoniem en er staan hier geen bedragen, prijzen of marges. Het gaat over de bouw.
Niet de boekhouding zelf, maar een kopie
De eerste keuze was de belangrijkste: de assistent praat niet met het boekhoudpakket, hij praat met een eigen kopie van de gegevens die wij 's nachts bijwerken. Daar zijn drie redenen voor.
Snelheid. Een vraag over klantprijzen raakt in het pakket zelf een handvol aparte opvragingen achter elkaar. Op een eigen kopie is het één zoekopdracht.
Grenzen. Het boekhoudpakket houdt een limiet aan op het aantal aanroepen per minuut en per dag. Een assistent die nieuwsgierig is, haalt die limiet verrassend snel. Op een kopie maakt een nieuwsgierige vraag niemand iets uit.
Rust. Bij het eerst vullen van die kopie ging het om duizenden regels prijsafspraken, verdeeld over tientallen prijslijsten. Dat wil je één keer doen en daarna alleen nog de wijzigingen ophalen. Dat is precies wat er nu gebeurt.
Alleen lezen, en dat ook kunnen bewijzen
De koppeling kan niets wijzigen. Niet omdat we het niet konden bouwen, maar omdat de eigenaar van een administratie geen assistent wil die per ongeluk een prijs aanpast.
Alleen-lezen is makkelijk gezegd. Wij hebben het op drie manieren vastgelegd. De koppeling bestaat alleen in de productieomgeving; de ontwikkelomgeving werkt op een kopie zonder enige verbinding met het pakket. Er staat een test in het project die faalt zodra er code bij komt die zou kunnen schrijven. En het account waarmee we koppelen heeft zelf alleen leesrechten.
Dat laatste punt is er een om te onthouden als je dit zelf gaat doen: in veel boekhoudpakketten krijgt een koppeling de rechten van de persoon die hem aanzet. Koppelt de eigenaar, dan mag de koppeling alles wat de eigenaar mag. Maak dus een aparte gebruiker met alleen de rechten die nodig zijn, en koppel met die gebruiker.
Inloggen zonder sleutels uit te delen
De assistent komt binnen via de standaard die daarvoor bestaat, met een inlogstap in de browser en een toegangsbewijs dat verloopt. Geen vaste sleutel in een instellingenbestand, geen wachtwoord dat door een chat gaat. Per administratie een eigen toegang, zodat iemand die aan de ene administratie mag werken niet in de andere kan kijken.
Een valkuil die ons een middag kostte, en die in geen enkele handleiding stond: het pakket weigerde een vernieuwing van het toegangsbewijs zolang het oude nog ruim geldig was. Vernieuw je te vroeg, dan krijg je een foutmelding die eruitziet als een rechtenprobleem. De oplossing is vernieuwen vlak voor het verloopt, met een kleine marge. En: zet er een wekelijkse taak op, zodat het bewijs zelf niet verloopt in een stille week.
De les die we niet verwachtten
Toen de eerste gebruiker ging testen, keken we mee in het logboek. Hij vroeg naar de prijs van vier artikelen voor één klant. De assistent deed daar zeven aparte opvragingen voor, netjes een voor een.
Technisch klopte dat. Hij had de functie "prijs van artikel X voor klant Y" en gebruikte die zo vaak als nodig. Maar het was langzaam en het was slecht leesbaar. De fix zat niet in de assistent en niet in het model: wij hadden de verkeerde functie aangeboden. Er kwam een functie bij die meerdere artikelen in één keer afhandelt, en de vraag werd één opvraging.
Dat is de belangrijkste les van dit project. Een koppeling voor een assistent ontwerp je niet zoals een koppeling voor een programma. Je kijkt naar de vragen die mensen stellen, en je maakt daar één functie van. Zeven keer het goede antwoord is nog steeds het verkeerde ontwerp.
Wat het nu kan
Vijf dingen, en dat is bewust weinig: een artikel zoeken, de prijs van een of meer artikelen voor een bepaalde klant, de beste klanten over een periode, bestellingen opzoeken, en de leveranciers van een artikel. Elk daarvan is een vraag die voorheen klikwerk was.
Wat het niet kan is minstens zo belangrijk: boeken, factureren, prijzen aanpassen. Dat blijft handwerk in het pakket zelf, met een mens die op verzenden drukt.
Veelgemaakte fouten
Koppelen met het account van de eigenaar. Dan mag de koppeling alles. Maak een aparte gebruiker met alleen leesrechten.
De koppeling ook in je ontwikkelomgeving aanzetten. Dan is het een kwestie van tijd voordat een test iets in de echte administratie zet. Laat de ontwikkelomgeving op een kopie werken.
Een functie per veld bouwen. Je krijgt dan een assistent die tien keer achter elkaar iets opvraagt. Bouw de functie die de vraag beantwoordt, niet de functie die bij je database past.
Vertrouwen dat de handleiding klopt. Bij ons week het gedrag van het pakket op meerdere punten af van de documentatie. Log de antwoorden die je terugkrijgt, zeker in de eerste week.
Geen limiet inbouwen. Een assistent die mag doorvragen, vraagt door. Zet een eigen bovengrens op het aantal opvragingen per gesprek, voordat het pakket dat voor je doet.
Zoiets bouwen voor je eigen administratie of pakket: dat valt onder maatwerk. Twijfel je of het bij je past, dan kijken we eerst mee zonder dat je iets bouwt; zie AI-consultancy.