Het hebben van een enigszins pseudo-intelligente, Q&A-achtige interactie met een softwaretoepassing is iets wat we al een tijdje doen. Denk aan virtuele agenten die je tegenkomt op verschillende e-commerceplatforms, meer geavanceerde bots op samenwerkingsplatforms, zoals Slackbot, en nog geavanceerdere die je helpen om echte transacties te maken, worden steeds populairder.
In zekere zin delen alle bots hetzelfde DNA (de bouwstenen van wat over het algemeen een conversationele bot maakt):
Zoals je kunt zien, is het belangrijkste doel van de bot "het gesprek voeren". De belangrijkste componenten van het "conversationele continuüm" zijn gewoonlijk opgebouwd rond interactie, interpretatie en distributie. Dit ontwerp maakt de fundamentele communicatiemechanismen voor ons mensen mogelijk om met bots te praten. Het element van interpretatie - dat punt in de conversiestroom waar de bot de echte "sense-making" doet - is momenteel een zeer hot topic, omdat dit een van de belangrijkste speelvelden voor kunstmatige intelligentie (AI) en machine learning is.
Het is erg interessant om te onderzoeken hoe een conversationele bot ons kan helpen met ons dagelijkse werk en het vervelende, niet-waarde toevoegende werk voor ons kan doen. We hebben allemaal een hekel aan het zoeken en ophalen van documenten op dat immense bedrijfsintranet, het boeken van onze uitgaven of het aanvragen van verlof op de HR-selfserviceportal, of het toevoegen van een nieuwe klant aan het tijdrovende CRM-systeem. Stel je het volgende scenario voor:
We hebben misschien geen geavanceerde AI of machine learning nodig om dit te realiseren, omdat het kan worden bereikt met de fundamentele bouwstenen die we al beschikbaar hebben. Met andere woorden, onmiddellijke bedrijfswaarde is klaar om te worden geoogst.
Laten we eens kijken hoe de meeste bots nu min of meer zinnige antwoorden op uw vragen vinden:
*Mens: 'Hallo Bot, mag ik vragen hoeveel uur ik deze week aan project X heb gewerkt?'
*Bot:
Bericht bevat: vragen, uren, gewerkt, project.
Best matching response: haal het aantal gewerkte uren in project X op in de agenda van de gebruiker.
Resultaat retourneren.
Stel antwoord Doe vraag.
Dus in feite zit een bot op een enorme index (mapping) van mogelijke acties naar sets (arrays) van vragen (let op: dit is heel anders dan NLP-aangedreven chatbots, omdat dit soort agenten meer mensachtige discussies kunnen hebben).
In plaats van de persoon te voorzien van de URL voor de selfserviceportal (het gescripte antwoord op mijn "vraag") waar hij of zij uren kan registreren, om uitvoeringsgesprekken op te bouwen, zou de bot me eigenlijk kunnen vragen: "Hoeveel uur zou je willen boeken?" (of zelfs automatisch mijn agenda checken, zoals in ons voorbeeld) en dan de uren boeken. De technische complexiteit om dit te realiseren is misschien niet zo uitdagend.
Denk hierbij aan de volgende mapping:
Dat is vrij eenvoudig. Dus welke echte nieuwe mogelijkheden moeten we toevoegen aan de architectuur van de bot om dit te laten werken? Kortom, we moeten de bot in staat stellen om met een stuk middleware te praten, in het geval dat een bedrijfsstroomuitvoering moet worden uitgevoerd. Deze middleware houdt, net als een algemene service bus met een servicecatalogus, een lijst bij met proceseindpunten die bedrijfsstromen activeren. We koppelen de gerelateerde eindpunten aan de conversatielogica, zoals te zien is in de bovenstaande tabel.
Dit concept gaat ervan uit dat er idealiter een procesautomatiseringsmogelijkheid is, die de taak van de daadwerkelijke procesuitvoering oppakt en tegelijkertijd reageert op de verzoekende partij (de middleware die namens de bot optreedt). Deze mogelijkheid kan worden geïmplementeerd door een BPMS-platform.
Wat van cruciaal belang is bij de realisatie van het bovenstaande concept, is het principe dat moet worden bestuurd om de procesuitvoering niet op botniveau te bouwen of door middel van het toevoegen van op maat gemaakte technologie ergens aan de bot-oplossingsarchitectuur (volgens de belangrijke vangrails van "Scheiding van zorgen").
Laten we samenvatten met behulp van ons basismodel:
Men zou zich kunnen voorstellen dat zodra het executional not-concept wordt gevolgd door zijn gebruikers, de vraag naar meer uitvoeringsscenario's snel zal volgen omdat het een belangrijk probleem oplost met een sterke business case:
Hoeveelheid tijd besteed aan het boeken van uren per persoon per week: 25 minuten.
Aantal personen boekingsuren: 250.
Geschatte besparing per week (250 x 25): 6.250 minuten/ 104 uur per week.
Per jaar (van 40 weken): 4.167 uur tegen gemiddelde kosten van 25 EUR = 104.166 EUR.
Wanneer dit gebeurt, moet u ervoor zorgen dat u over een flexibele capaciteit beschikt (bijvoorbeeld BPMS, optioneel verbeterd door RPA-systemen om de legacy-integratie-uitdaging te overwinnen, zie dit artikel) om de vraag te kunnen volgen en snel meer functionaliteit te leveren. De toegevoegde waarde zou indrukwekkend zijn, omdat het veel mensen zou bevrijden van de repetitieve, niet-kerntaken en irrelevante taken die ze dagelijks moeten doen, waardoor ze vrijkomen voor kernactiviteiten.