Wat u gaat vragen
Deze vragen komen in elk traject langs. Ze komen alleen niet uit dezelfde mond en ze komen zelden allemaal op tafel voordat het besluit valt. Daar lopen projecten later op vast.
Hieronder staan ze, gegroepeerd naar wie ze stelt. Herkent u er vijf en heeft u op geen van de vijf een antwoord van uw huidige leverancier? Dat is een goed moment om te bellen.
Om te beginnen
“Wat is besst.ai?”
besst.ai is de praktijk van Rinaldo Hassell, onder AppTechWorks B.V. Wij bouwen kennisassistenten op uw eigen documenten, met rechten die intact blijven. In uw eigen Azure-tenant of volledig offline op eigen hardware.
“Hoe beginnen we?”
Met een gesprek, en daarna met een verkenning. Daarin kijken wij naar uw documenten, uw rechtenstructuur en de vragen die uw mensen echt stellen. U krijgt een beoordeling: waar het bij u vastloopt, en of een proof of concept de moeite waard is.
Bestuur
“Hoe verschilt dit van een algemene chatbot?”
Een algemene chatbot weet veel en niets van u. Het verschil zit in wat eromheen staat: begeleiding bij de keuzes, inrichting in uw eigen omgeving, controle op welke documenten erin gaan, toetsing voordat het in gebruik gaat, beheer als het draait, en de context van uw organisatie. En het antwoord komt uit uw eigen documenten, met de bron erbij, en alleen voor wie het mag zien.
“Wat levert dit op, en wanneer merken we dat?”
Het eerste dat u merkt is dat zoeken ophoudt. Wie nu een half uur kwijt is aan het terugvinden van een eerdere beslissing, vindt die in een minuut, met de bron erbij. Dat is het eerste wat de proof of concept zichtbaar moet maken. Wat daarna komt is moeilijker te tellen en belangrijker: antwoorden worden consistenter, omdat iedereen uit dezelfde stukken put.
“Wat als we over twee jaar iets anders willen?”
Dan houdt u uw documenten, uw rechten en uw logboeken. De onderdelen die het snelst verouderen zijn in het ontwerp vervangbaar gehouden.
“Zijn we hierna afhankelijk van jullie?”
Nee. Het draait in uw eigen omgeving, op uw eigen documenten, en de opstelling wordt zo opgeleverd dat u hem zelf kunt beheren of laten beheren.
“Wanneer weet ik of dit bij ons werkt?”
Aan het eind van fase 1. Niet eerder, en ook niet later.
“Waarom zouden we dit nu doen en niet wachten tot onze leverancier het levert?”
Soms is wachten de juiste keuze. Weeg dit mee: wat een leverancier levert, levert hij aan al zijn klanten tegelijk, dus generiek, en het werkt op zijn inrichting van rechten en niet op die van u. Voor een algemene kennisbank is dat prima. Voor het moment waarop afdelingen met verschillende rechten uit hetzelfde systeem moeten putten, is het meestal het probleem.
“Waarom zou ik dit bij een klein bureau beleggen en niet bij een grote partij?”
Dat is een terechte vraag en het antwoord is niet altijd in ons voordeel. Bij een grote partij koopt u continuïteit en een contract. Bij ons koopt u dat de persoon die het bedacht heeft ook de persoon is die aan tafel zit. Wat u in beide gevallen moet regelen is wie het beheert als wij er niet meer zijn, en dat is precies waarom de opstelling overdraagbaar wordt opgeleverd aan uw eigen team of uw huisleverancier. Overdraagbaar is niet hetzelfde als overgedragen: wijs die persoon aan voordat u begint.
Privacy en beveiliging
“Moeten we een DPIA doen?”
Waarschijnlijk wel, en dat is geen probleem maar werk. Wij zijn niet uw juridisch adviseur en doen de DPIA niet voor u. Wat wij leveren is de technische beschrijving die uw FG nodig heeft: welke gegevens waar staan, welke bewerkingen erop plaatsvinden, en hoe de toegang is afgeschermd. Begin er vroeg mee. Een DPIA die pas bij de oplevering start is de meest voorspelbare vertraging in dit soort trajecten.
“Kan ik zien wie wat gevraagd heeft?”
Ja. Vragen, antwoorden en geraadpleegde bronnen worden standaard gelogd, want zonder dat kunt u achteraf niets vaststellen en kunt u ook niet aantonen dat de rechtenscheiding heeft gehouden. Hoe lang u bewaart en wie mag inzien is uw keuze en hoort in uw eigen beleid. Let op dat de logging zelf persoonsgegevens bevat en dus onder dezelfde DPIA valt.
“Moet onze data naar de cloud?”
Nee. Dezelfde assistent draait ook volledig offline, zonder internet, op uw eigen hardware.
“Werkt dit ook zonder Microsoft?”
Ja. De offline variant gebruikt open-weight modellen op uw eigen hardware en heeft geen cloudabonnement nodig. De opstelling gebruikt daar geen clouddiensten en geen Microsoft-producten.
“Kan dit on-premise draaien?”
Ja. De offline variant draait op uw eigen hardware, zonder internet, met open-weight modellen. De opstelling gebruikt daar geen clouddiensten en geen Microsoft-producten.
“Kan een medewerker van Sociaal Domein via dit ding bij stukken van P&O?”
Nee, en dat is het eerste wat wordt ingericht, niet het laatste. Ook de bronvermelding niet: geen verwijzing naar een document dat hij niet mag openen. Een autorisatietest is onderdeel van de oplevering.
Informatiemanagement
“Wat als onze documenten een rommeltje zijn?”
Dan bent u normaal; documentbeheer is bij vrijwel elke organisatie achtergebleven bij de groei van het aantal documenten. Het is geen reden om te wachten, want opruimen zonder zichtbaar resultaat houdt niemand vol. Wij beginnen op het deel dat goed genoeg is en maken zichtbaar welke rommel het antwoord echt in de weg zit.
“Wordt dit weer een eiland in ons landschap?”
Het draait in uw eigen omgeving, op uw eigen identiteiten, op de documenten waar ze nu al staan. Wij verplaatsen uw documentbeheer niet en vragen u niet om over te stappen. Dat is een ontwerpregel, geen concessie.
“Wat als het stuk is op maandagochtend?”
Dan is de vraag wie er piket heeft en binnen hoeveel tijd het hersteld moet zijn. Dat is een beheerafspraak en geen technische vraag. Wij noemen daar geen standaardtermijn voor, want die hangt af van wat de assistent bij u doet: een kennisbank die een uur uit de lucht is, is iets anders dan een systeem waar een balie op wacht. U bepaalt wat het moet zijn, wij zeggen wat dat kost en of het haalbaar is. Wij maken die afspraak expliciet voordat u in productie gaat, omdat hij anders per ongeluk bij niemand belandt.
“Wat gebeurt er met een document dat we intrekken?”
Dat hoort mee te verdwijnen uit de assistent, en de termijn waarbinnen dat gebeurt is een afspraak die wij met u vastleggen voordat er iets in productie gaat. Stel deze vraag aan elke leverancier die u spreekt.
“En als het gewoon iets verzint?”
Dan ziet u dat, want er staat altijd een bron bij en die opent met een klik. Een antwoord zonder bron hoort u niet te krijgen, en dat is een van de zes meetpunten voordat iets in productie gaat. Dat is geen garantie dat het model nooit de mist in gaat, het is de reden dat u het merkt voordat iemand ernaar handelt.
“Hoe lossen jullie dat op?”
Dat laten we zien in uw eigen omgeving, op uw eigen documenten. Niet op een website.
Inkoop
“Wat kost het per jaar als het draait?”
De kosten hangen af van waar het draait. In de offline variant zijn er geen verbruikskosten, maar wel hardware en beheer. In de Azure-variant vallen de kosten in drie delen uiteen die verschillend bewegen. Verbruik in Azure, dat meebeweegt met het aantal vragen en de omvang van uw documenten, en dat wij in de proof of concept meetbaar maken zodat u in productie niet voor een verrassing staat. Licenties, die u waarschijnlijk al heeft. En beheer, dat een keuze is en geen gegeven. Wij noemen geen jaarbedrag voordat we uw omvang kennen, omdat elk bedrag dat u nu van iemand krijgt een slag in de lucht is.
“En als het na de proof of concept niet blijkt te werken?”
Dan stopt u, en dan heeft de proof of concept precies gedaan waarvoor hij is. U houdt de uitkomst: welke documenten deugen, waar uw rechten rammelen, en wat een vervolgstap zou kosten. Dat is waarde, ook als er niets wordt gebouwd.
“Hoe koopt een gemeente dit eigenlijk in?”
Verkenning, proof of concept en productie zijn drie losse opdrachten met elk een eigen resultaat. U bent na elke fase vrij om te stoppen. Dat past meestal binnen uw eigen drempelbedragen, en het is ook het enige eerlijke moment om te besluiten of het werkt.
De werkvloer
“Kan een gebruiker zien waar een antwoord vandaan komt?”
Ja. Bij elk antwoord staat de bron: het document en de pagina. Een klik opent de passage waarop het antwoord steunt, zodat de gebruiker zelf kan nalezen wat er staat.
“Wat gebeurt er als het antwoord niet bekend is?”
Dan zegt het systeem dat, in plaats van iets te verzinnen. De gebruiker kan dan de dichtstbijzijnde documenten openen, de vraag doorsturen naar de verantwoordelijke afdeling, of melden dat er kennis ontbreekt.
“Moeten mijn mensen anders gaan werken?”
Zo min mogelijk, en dat is een ontwerpkeuze. De documenten blijven staan waar ze staan. Wat erbij komt is een plek om een vraag te stellen. Wat verdwijnt is het zoeken.
“Gaat dit banen kosten?”
Dat bepalen wij niet, dat bepaalt u. Wat er verandert is dat er tijd vrijkomt bij het opzoeken en het herhaald beantwoorden van dezelfde vraag. Wat u met die tijd doet is een bestuurlijke keuze en geen technisch gevolg, en het is verstandig om die keuze uit te spreken voordat uw mensen hem zelf invullen. Onuitgesproken blijft hij niet onopgemerkt.
“Wat als mijn mensen het gewoon niet gebruiken?”
Dit is de vraag die het vaakst juist is en het minst gesteld wordt. Een systeem dat technisch werkt en niet gebruikt wordt, is het grootste risico van dit soort projecten. Wat helpt: begin bij een groep met een concreet probleem, niet bij de groep die het het handigst vindt. Kies een vraagsoort die vaak terugkomt en nu echt tijd kost. Toon altijd de bron, want vertrouwen ontstaat door het document en niet door het antwoord. En meet het gebruik vanaf dag een, zodat u weet of het wegzakt voordat het al weggezakt is. Wat niet helpt: een brede uitrol met een instructiemiddag.
“Wat gebeurt er als ik bel?”
Geen voorstel en geen presentatie. Wij vragen welk van deze punten bij u het meest knelt en of het op te lossen is binnen wat u al heeft. Soms is het antwoord dat u ons niet nodig heeft. Dat horen wij liever nu dan over drie maanden.
Staat uw vraag er niet bij? Dan is dat de vraag die wij willen horen.
Kom eens praten en we zien waar we uitkomen.
Neem contact op