Automatisering is een belangrijk wapen om het Mattheus-effect tegen te gaan. Het automatisch toekennen van bepaalde voordelen aan de hand van objectieve criteria zorgt idealiter voor een gelijke behandeling van alle burgers ongeacht stand en rang. Daarnaast zorgt automatisering ook voor tijdswinst, minder papier, en lagere kosten op lange termijn. Veel projecten waar Smals bij betrokken is, dragen daar aanzienlijk toe bij: ze besparen de overheid, burgers en bedrijven jaarlijks miljarden euro’s, om niet te zeggen tonnen papier, inkt en postzegels.

We schreven al uitvoerig over de talloze randvoorwaarden die opduiken als men Artificiële Intelligentie correct wil inzetten ([1], [2], [3], [4], [5], [6]), maar ook een gewone procesautomatisering, zelfs digitalisering, is niet zomaar vrijblijvend, en al zeker niet bij overheden. Automatisering is niet gelijk aan artificiële intelligentie, maar men geeft nog steeds een deel van de controle uit handen aan een machine. Naast winsten in snelheid en kostprijs, kan dat ook allerlei beperkingen introduceren. Door de schaalvergroting loopt het, als het fout loopt, ook ineens heel erg fout. Reden genoeg om reeds vanaf de planningsfase nauwgezet aandacht te besteden aan de bredere effecten van een automatiseringsproject.

Wil een geautomatiseerd proces goed werken, dan is het belangrijk dat het actief en “als een goede huisvader” wordt beheerd. Permanente monitoring is nodig zodat problemen snel gedetecteerd en opgelost kunnen worden. Manueel ingrijpen moet mogelijk blijven, het moet duidelijk zijn wie waarvoor verantwoordelijk is, en alles moet mee evolueren wanneer nodig. In het Engels wordt dat al eens aangeduid met (corporate) “governance“, vrij vertaald “deugdelijk bestuur”. Het is een vaag begrip, maar in dit artikel hoop ik het belang ervan te kunnen illustreren aan de hand van enkele spraakmakende voorbeelden uit het buitenland.

(afbeelding: “corporate governance”, (c) Asmi-corporatereporting.com, 2017, Licensed CC BY-SA 4.0 https://creativecommons.org/licenses/by-sa/4.0, via Wikimedia Commons)

Wat kan er zoal misgaan?

Frankrijk

De Franse Caisse des Allocations Familiale (CAF) nam in 2021 een nieuw systeem in gebruik voor de berekening van huisvestingstoelagen. Helaas was het systeem niet volledig compatibel met een ander systeem voor de registratie van sommige arbeidsprestaties, nodig om de hoogte van die uitkering te bepalen. Als gevolg kregen minstens 120.000 mensen een foutieve schuldvordering in de bus, automatisch aangemaakt, voor zogezegd teveel ontvangen uitkeringen. De toevloed aan reacties, en alle correcties die vaak manueel aangebracht moesten worden, zorgden voor veel extra werklast bij de dienst die al met veel vertragingen te kampen had, wat op zijn beurt aanleiding gaf tot stakingen. Negen maanden later wachtten nog steeds 32.000 mensen op de correctie van hun dossier.

Verenigd Koninkrijk

Het Verenigd Koninkrijk heeft geen rijksregister zoals België. Mensen moeten hun identiteit op een andere manier bewijzen: met een rijbewijs, bankrekening, telefooncontract of een internationaal paspoort. Dat zorgt al voor een eerste probleem, omdat net de meest kwetsbaren die het meeste belang hebben bij die diensten, door hun kleinere administratieve/digitale voetafdruk niet geauthenticeerd geraken. Daarnaast is identiteitsfraude een groot probleem.

Universal Credit is een geautomatiseerd sociaal vangnet voor de laagste inkomens, dat bestaat uit de fusie van 6 aparte uitkeringen. Hun doel om de zaken te vereenvoudigen hebben ze echter ook doorgetrokken in de berekeningswijze: die neemt enkel het inkomen van een vorige maand in rekening. Dat zorgt voor grote problemen bij mensen die onregelmatig betaald krijgen, of wanneer loon plots vervroegd uitbetaald wordt omwille van feestdagen: zij hebben in sommige maanden plots een hoger inkomen, in andere maanden geen, en krijgen daardoor heel erg fluctuerende uitkeringen. Het perverse effect daarvan is dat twee mensen met dezelfde job, gezinssamenstelling en jaarinkomen, toch verschillende uitkeringen kunnen krijgen, enkel en alleen omdat hun salaris op een ander moment wordt uitbetaald.

Een rechtszaak daarover werd door de Britse overheid verloren. Het maken van de opgedragen aanpassingen zal de kost van het geplaagde systeem, nu reeds lopend in de miljarden pond, alleen nog maar verder doen toenemen. Let wel dat het probleem hier niet zozeer bij de automatisering ligt, wel bij het ontwerp: de regering had expliciet besloten tot deze berekeningswijze, omdat ze gemakkelijker en efficiënter te implementeren was.

(afbeelding: Wordmark for Universal Credit, (c) UK Government, licensed under the Open Government Licence version 1.0 (OGL v1.0).

Australië

In Australië deed de RoboDebt affaire veel stof opwaaien. Frauduleus betaalde uitkeringen terugvorderen deden ze al langer, maar in 2015 maakten ze een cruciale verandering: het verifiëren van een “match” tussen de databanken sociale zekerheid (DHS) en financiën (ATO), werd geautomatiseerd. Dat nam effectief een stap van menselijke controle in de ketting weg. Het hoofddoel was om elke “match” op te volgen, daar waar ze vroeger slechts de meest flagrante inbreuken konden najagen omwille van het manuele werk. Dat leidde in het eerste jaar al tot een 40 keer hoger volume.

Helaas was niet elke “match” ook terecht. De uitkeringen werden immers in perioden van 14 dagen toegekend, terwijl de belastingdienst gegevens had per fiscaal jaar. Bij gebrek aan inkomstengegevens per 14 dagen werd een gemiddelde van het jaarinkomen toegepast, maar net zoals in het voorbeeld van UK, leidde dat tot ongewenste neveneffecten, en moesten burgers plots schulden gaan terugbetalen die ze nooit gemaakt hadden. In 2019 werd het systeem door de rechtbank onwettelijk verklaard, en in 2021 moest de overheid een schikking ter waarde van $1.8 miljard Australische dollar treffen met de bijna 500.000 gedupeerden. Ook hier lag de fout bij de wetgever, die niet voldoende had nagedacht over de aannames en mogelijke neveneffecten bij het opstellen van de berekeningswijze van het systeem.

USA

In de Verenigde Staten doken problemen op bij de automatisering van RAI. Dit Resident Assessment Instrument is een lange vragenlijst voor zwaar zorgbehoevenden. Aan de hand van het resultaat wordt o.a. berekend op hoeveel thuiszorg iemand een beroep mag doen. Ook in België wordt een variant ervan gebruikt die BelRAI heet. Het automatiseren daarvan moet heel omzichtig gebeuren. Als bijvoorbeeld de vraag of iemand voetproblemen heeft beantwoord wordt met “nee”, kan dat zijn omdat die gezond is, maar even goed omdat die geamputeerde voeten heeft – en die laatste behoeft uiteraard meer zorg.

In Arkansas liep het fout bij onderaannemers die een verkeerde versie van de vragenlijst hadden gebruikt, en daarnaast bepaalde ziektebeelden, zoals hersenverlamming, niet correct hadden verwerkt. Pas tijdens de rechtszaak werd duidelijk waar de fouten precies lagen, o.a. doordat de rechter verplichtte om de resultaten eens manueel na te rekenen. Het systeem bleek dermate complex, en de code werd zodanig afgeschermd, dat ook de bevoegde ambtenaren niet in staat waren geweest om de fout te ontdekken. Zo was het voor eindgebruikers nooit duidelijk waarom de evaluatie tot een bepaald resultaat leidde, wat het op zijn beurt erg moeilijk maakte een evaluatie aan te vechten of te overreden. Het gebruik van RAI op zich werd door de rechtbank wel als wettig beschouwd.

India

India heeft hetzelfde probleem als het Verenigd Koninkrijk, nl. dat het lange tijd geen eengemaakt burgerregister had en dat andere systemen (rijbewijzen, stembiljetten, geboorteaktes) onderling incompatibel zijn. Het bijhouden van gegevens op kaartjes en papieren is er ook geen sinecure voor de armeren en ongeletterden onder hun bevolking. In een ambitieus programma om iedere Indiër een sociaal identiteitsnummer te geven (zoals onze vroegere SIS-kaart), startte India het Aadhaar project, dat ook biometrische authenticatie op basis van de vingerafdruk omvat.

(afbeelding: “A sample of Aadhaar card”, by Pagelmp, licensed under the Creative Commons Attribution-Share Alike 4.0 International license. Source Wikimedia Commons.)

De praktijk blijkt echter weerbarstiger. Er zijn technologische vereisten om het te kunnen toepassen: een vingerafdruklezer en een stabiele internetverbinding. Bovendien zijn de vingerafdrukken niet altijd meer herkenbaar bij wie een leven lang handenarbeid heeft verricht. Ook fouten bij de manuele data-entry, wat tijd en geld kost om te laten corrigeren, zorgen voor problemen. Er duiken dan ook veel rapporten op van grote aantallen kwetsbaren die de toegang tot sociale diensten, onderwijs, vergunningen, kindergeld of voedselrantsoenen wordt ontzegd omdat ze door de mazen van het Aadhaar-systeem vallen.

Nederland

In Nederland viel de regering over de toeslagenaffaire. Vele duizenden gezinnen kwamen in grote problemen door onterechte beschuldigingen van subsidiefraude. De affaire is complex, maar aan de basis ligt de opsporingsdienst voor belastingfraude die zich danig heeft vergaloppeerd. Het probleem lag hier o.a. bij een gebrekkige training en validatie van een machine-learning model, dat een risicoclassificatie moest geven aan dossiers en daarbij zonder veel nadenken steunde op parameters zoals nationaliteit, die erg gevoelig zijn voor discriminatie. Daarnaast was de inhoud van verschillende onderliggende databanken, o.a. de Fraude Signalerings Voorziening, onoordeelkundig verzameld: een telefoontje naar de belastingdienst kon voldoende zijn om erin opgenomen te zijn als potentieel fraudeur. De opsporingsdienst vertrouwde echter quasi blindelings op de gegevens en risicoscores, en gebruikte ze als rechtvaardiging om drastisch te werk te gaan bij terugvorderingen, weigeringen van afbetalingsplannen, enz. Daarbij ontbrak het aan een richtinggevend kader van bovenaf, interne monitoring of audit, en mogelijkheden tot aantekenen van beroep. De databank werd op basis van inbreuken op de privacywetgeving stopgezet en de belastingdienst kreeg een stevige boete.

Conclusie

De bovenstaande verhalen hebben meestal 1 ding gemeen: alles gaat goed totdat op een bepaald moment ergens een bocht teveel wordt afgesneden zonder dat er tijdig wordt ingegrepen. Dat moet ons niet tegenhouden om te automatiseren, want er zijn ook duidelijke voordelen: voor de overheid qua schaalbaarheid, voor de burger o.a. door vermindering van administratie. Met dit artikel willen we vooral aandacht vestigen op de noodzaak om daarbij voldoende te investeren in planning en opvolging, om een goede grip te houden. Dat omvat ook een realistische blik, aandacht voor user experience en duidelijke adoptie van waarden en principes (transparantie, accountability, …).

Het grote verschil tussen een ambtenaar in persoon en een geautomatiseerd systeem, is dat een ambtenaar aanpassingen kan maken en verfijningen kan toebrengen nog voordat een beslissing genomen wordt, terwijl een algoritme enkel maar gecorrigeerd kan worden nadat het al een beslissing heeft gemaakt. Dat laatste veroorzaakt frustratie en een nood aan ingrijpen achteraf. Er is een risico dat bepaalde doelgroepen onevenredig het slachtoffer zijn van zulke fouten. Ook kan bij de gebruikers van geautomatiseerde systemen, een zekere verblinding, laksheid, of neiging tot het afschuiven van verantwoordelijkheid ontstaan: “de computer zegt het dus het zal wel zo zijn”. Er moeten dus toegankelijke procedures zijn om beroep aan te tekenen tegen een beslissing en correcties moeten eenvoudig doorgevoerd kunnen worden.

Daarnaast blijft het altijd mogelijk dat programmeurs de regels onvolledig of foutief inbrengen in een programma, of dat ze andere interpretaties en aannames hanteren dan de regelgevers. Er is dus nood aan een zekere waakzaamheid, transparantie en inspraak in het hele implementatieproces, zeg maar “project governance“. Ook de uitvoerende ambtenaren moeten blijven begrijpen wat er gebeurt en waarom. Daarbij hoort ook een goede methode om feedback te verwerken die vanop de werkvloer aangebracht wordt.

Er bestaat vooralsnog geen vaste manier om compliance of governance ontegensprekelijk te garanderen. Het zijn nog steeds vage begrippen, en ook nogal wat wetgeving blijft vaag: zo staat het woord “redelijk” maar liefst 38 keer in de GDPR, en het woord “passend” zelfs 125 keer, zonder verdere specificatie van wat we daar nu concreet onder moeten verstaan. In de VS worden basisregels voor bedrijfsbeheer opgelegd door de Sarbanes-Oxley Act. In België bestaan er de Code Lippens voor beursgenoteerde, en Code Buysse voor niet-beursgenoteerde ondernemingen. Ondertussen wordt in Europa verder gewerkt aan o.a. een Data Governance Act om een kader te scheppen voor verantwoord (her)gebruik van gegevens.

Deze en andere regulatorische raamwerken zijn misschien niet perfect sluitend. Ze adopteren, eventueel certifiëren, en regelmatig eraan toetsen, zorgt op korte termijn wel voor extra overhead en kosten, maar het legt de lat ook hoger en kan zo op lange termijn veel zorgen voorkomen. Het is ook meestal goede reclame. Uit alle aangehaalde voorbeelden blijkt natuurlijk ook dat daarvoor de nodige wil moet bestaan bij, en middelen ter beschikking gesteld moeten worden door, de bevoegde beleidsmakers.

______________________

Dit is een ingezonden bijdrage van Joachim Ganseman, IT consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Robotic Process Automation (RPA) kan soms verlossing brengen in een dringende situatie: dit merkten we in het voorjaar, toen de Hulpkas Voor Werkloosheidsuitkeringen (HVW) onze hulp inschakelde tijdens de eerste grote piek van de Coronacrisis.

Bij Smals Research hebben we reeds enige tijd ervaring met het gebruik van RPA om snel automatisaties te ontwikkelen bovenop bestaande toepassingen. Eind 2018 publiceerden we hier reeds over in deze blog: ons besluit was toen gemengd. We stelden dat men goed moet oppassen met RPA oplossingen en deze technologie zeker niet als totaaloplossing kan gebruiken, maar dat er weldegelijk gevallen te vinden zijn waar men heel snel een grote business value kan bereiken met een grote ROI.

In mei van dit jaar hebben we, dankzij de vraag van HVW, een heel goed voorbeeld van een dergelijke case gevonden. De regering had toen, als deel van de maatregelen om met Covid-19 om te gaan, immers een nieuwe vorm van tijdelijke werkloosheid mogelijk gemaakt, voor wanneer deze was gerelateerd aan Corona. Hier werd toen massaal gebruik van gemaakt, waardoor HVW duizenden extra dossiers te verwerken kreeg. Op het einde van de maand mei werden toen zowat 371.000 dossiers extra verwacht in vergelijking met de maand mei van 2019.

Een groot deel van dit proces is uiteraard reeds geïnformatiseerd, maar op het einde, wanneer de nodige controles zijn gebeurd en er groen licht is gegeven, dient er nog een manuele actie te gebeuren, pér dossier, om de betaling te laten doorgaan. Een simpele handeling, die 3000 keer met één mandag werk kan worden uitgevoerd. De piek in mei zou dus bijna honderd mandagen extra werk hebben gekost en weekendwerk hebben vereist van een aantal mensen binnen HVW.

Daarnaast is dit ook behoorlijk saai en repetitief werk: de laatste nodige handeling om tot betaling over te gaan, betreft het klikken op een knop in een lijst in een webtoepassing, om daarna even te wachten tot de desbetreffende lijn in de lijst verwerkt is en over te gaan tot exact hetzelfde op de volgende lijn. “Saai en repetitief werk“: dit is natuurlijk een eerste sterke indicatie dat RPA een goede oplossing kan zijn om dit te automatiseren. Voor het gebruiksgemak zal de robot echter iets meer moeten kunnen dan enkel dit aanklikken in de lijst: eerst moet er worden ingelogd in de toepassing, daarna wordt doorheen de lijst van HVW-kantoren gegaan, en voor elk van deze kantoren moet er een zoekopdracht worden ingegeven om de uit te betalen dossiers te vinden.

Om te zien of dit een goede kandidaat is voor RPA, kunnen we dan snel enkele andere criteria aftoetsen. Ten eerste moeten we nagaan of het probleem niet eenvoudig op een andere manier is op te lossen, door b.v. de toepassing zélf aan te passen om de nodige acties intern te automatiseren, waardoor ze niet meer door een eindgebruiker dienen te worden uitgevoerd. Na overleg met de verantwoordelijken voor het onderhoud van deze toepassing, bleek dat geen optie.

Het tweede criterium betreft het volume: is het enerzijds de moeite waard om te doen qua opbrengst (want het bouwen van het RPA script vergt toch ook een bepaalde effort), en is het anderzijds mogelijk om het werk te volbrengen met een niet al te groot aantal robots? Het eerste bleek vanzelfsprekend, gezien de hoeveelheid manueel werk die we konden uitsparen. Voor het tweede punt hebben we ingeschat dat dit mogelijk moest zijn, en dat konden we verifiëren na een eerste testrun wanneer een eerste, ruwe versie van de robot gemaakt zou zijn.

Als laatste criterium moeten we overgaan tot een aantal snelle tests, waarbij we reeds het te volgen script grofweg implementeren in een robot en kijken of dit zonder al te grote problemen mogelijk is. Met deze oefening zijn we gestart op 18 mei en al snel bleek dat de onderliggende webtoepassing zich voldoende goed kon lenen voor een automatisatie via robots. We gingen dus verder met de implementatie.

Gezien de hoogdringendheid hebben we hier dan volledig prioriteit aan gegeven en zijn we erin geslaagd om een werkende robot in productie te hebben tegen 27 mei. Om alle dossiers te kunnen verwerken hebben we dan snel het aantal robots opgevoerd tot 10, waardoor deze op enkele dagen tijd de nodige betalingen voor de maand mei konden uitvoeren. Missie geslaagd!

Het toeval wou ook dat de leverancier van het RPA-product dat wij gebruiken – UiPath – vanwege de Corona-crisis een speciale actie deed: alle gebruik van hun software i.v.m. Covid-19 zou gratis zijn tot en met de maand september. Dit was mooi meegenomen, want op die manier konden we het licentie-aspect van ons project heel snel afhandelen. In normale omstandigheden zou dit waarschijnlijk langer hebben geduurd. We zijn ook niet de enigen die vanwege de Corona-crisis een RPA-oplossing bouwden. In België deden b.v. ook VLAIO en DXC ons dit na.

De gratis licenties lieten ons bovendien toe om de robots voldoende lang in productie te houden om de dossiers van de latere maanden ook nog te verwerken. We voegden in de maanden die volgden ook nog extra functionaliteit toe aan het robot-script, waardoor het parametriseerbaarder werd en zich tot een nuttige tool kon ontpoppen. Hierdoor zou HVW uiteindelijk toch licenties gaan aanschaffen om 2 robots permanent in productie te houden, ook na september 2020. Tot op heden wordt onze RPA “betaalrobot” nog steeds gebruikt.

HVW was erg tevreden met de resultaten, en besloot ons project in te dienen voor de Agoria eGov awards. We behaalden twee nominaties: deze voor “beste rendabiliteit” en deze voor “beste project”. Binnenkort weten we of we ook effectief één van deze nominaties kunnen verzilveren (in beide categorieën moeten we echter opboksen tegen het befaamde Coronalert – ook al een sterk project dat mede dankzij Smals werd gerealiseerd, en zeker te installeren op je smartphone) !

Update december 2020 – Ondertussen zijn de winnaars van de Agoria Awards bekend, en onze case won de prijs voor de categorie “Rendabiliteit”! De prijs voor beste project ging naar Coronalert. Daarnaast merkt Agoria terecht op dat RPA als technologie meer en meer ingang vindt.

Besluit

We zijn blij dat we zo’n goed voorbeeld van een ideale case voor RPA mochten ontwikkelen. De dringendheid was hier de doorslaggevende factor om snel de knoop door te hakken en dit probleem met RPA op te lossen, ook al is dringendheid voor ons geen absolute factor die de keuze dient te bepalen (het speelt natuurlijk wel een zekere rol). Zoals we reeds eerder aanhaalden: geen makkelijk haalbare alternatieven, een geschikt volume en de compatibiliteit van de onderliggende toepassing zijn vuistregels om te zien of RPA een goede keuze is of niet.

Mogelijks zijn er nog veel goede, doch “slapende” RPA cases te vinden binnen onze sector. Doordat iedereen gewend is dingen op een bepaalde manier te doen, en er geen dringende nood is aan verandering, komen deze cases misschien niet altijd aan het licht.

Daarnaast moeten we toch ook blijven oppassen met ons enthousiasme voor deze technologie. We moeten rekening blijven houden met de lessen uit de eerste blog: governance is heel belangrijk om het overzicht te blijven bewaren, zeker wanneer men binnen eenzelfde organisatie méér dan een handvol robots gaat ontwikkelen. Daarnaast blijft het belangrijk dat RPA eerder een middel is om technical debt te helpen aanpakken, en niet om deze te verdoezelen.

Meer uitleg over dit project verscheen reeds eerder op het Intranext van Smals.

Wat is RPA?

Robotic Process Automation (RPA) is een manier om (elektronische) processen te automatiseren op basis van de gebruikersinterface van bestaande toepassingen. Het is een volledig softwarematige manier van werken (er komen dus geen echte, fysieke robots bij kijken), waarbij een toepassing (de RPA oplossing) zal instaan voor het bedienen van andere, onderliggende applicaties. Een software robot, of kortweg “bot”, simuleert daarbij de muisclicks en toetsenbordaanslagen van een eindgebruiker. Je ziet dus als het ware het scherm vanzelf bediend worden en veranderen, alsof er een onzichtbare gebruiker aan het werk is met de muis en het toetsenbord.

RPA wordt vaak beschouwd als een onderdeel van het bredere AI. Of dit daadwerkelijk zo is, laten we in het midden, maar alleszins kunnen we zeggen dat de technologie in principe geen “echte” artificiële intelligentie bevat (in zoverre men deze kan definiëren). RPA is gebaseerd op regels en procedurele logica, typisch door de mens geprogrammeerd en zeker niet door de computer “uitgevonden” of op basis van heel veel data “geleerd“. Het is wel zo dat RPA vaak in combinatie met AI wordt gebruikt, doordat er b.v. in een bepaalde stap van het process een AI wordt aangeroepen om een bepaalde beslissing te nemen, of anderzijds omdat er b.v. een RPA bot wordt aangeroepen nadat een intelligente chatbot geconcludeerd heeft dat een klant een bepaalde procedure wenst te laten uitvoeren.

We kunnen dan nog het onderscheid maken op basis van wáár dit werk precies gebeurt. Enerzijds is het mogelijk de bot te installeren op een machine bij een eindgebruiker. Dit kan dan worden gebruikt om op bepaalde momenten een aantal acties automatisch en snel uit te voeren, tussen de bezigheden van de gebruiker door. Op die manier kan er bijvoorbeeld worden gezorgd dat moeilijk te automatiseren werk, waarbij de eindgebruiker bepaalde overdachte beslissingen moet nemen, manueel blijft, terwijl rechttoe rechtaan taken (die door de gebruiker als repetitief en vervelend kunnen worden bestempeld) door de robot worden overgenomen. Deze manier van werken wordt soms ook “attended RPA” genoemd.

Anderzijds hebben we dan “unattended RPA”. Hier zal de bot op een aparte pc worden geïnstalleerd (b.v. een virtuele machine op een server) om een aantal taken volledig automatisch, zonder supervisie, uit te voeren. Het zal dan gaan om taken die een zekere tijd in beslag nemen (of waarvan er grote hoeveelheden herhalingen moeten worden uitgevoerd) en die geen tussenkomst vergen van de eindgebruiker.

Hoe?

Hoe bouwt men zo een RPA bot precies? Typisch kunnen we aan de hand van een grafische notatie een sequentie van handelingen definiëren, waarbij we aangeven, aan de hand van bepaalde filtercriteria, welk schermelement we precies willen aansturen, en wat we er precies mee willen doen (via de muis of het toetsenbord). Ook flowcharts zijn daarbij een voorbeeldnotatie. Sommige RPA tools laten ook toe om een soort van opnamefunctionaliteit te gebruiken: de computer zal dan a.h.w. proberen na te bootsen wat je hem eerst manueel hebt voorgedaan.

Geschiedenis en Gelijkaardige zaken

RPA kan eigenlijk gezien worden als spirituele opvolger van “Integration at the Glass“. Ook deze technologie diende immers om zaken te automatiseren op UI niveau. De focus lag hierbij evenwel iets anders: men was meer op het integreren van onafhankelijke toepassingen gericht, onder toezicht van de eindgebruiker. Desalniettemin waren automatisaties reeds mogelijk. De huidige RPA tools zijn uiteraard wel geëvolueerd: men legt sterk de focus op automatisatie via een gebruiksvriendelijke tool en met ondersteuning voor meerdere soorten diagrammen, aan de hand waarvan het proces grafisch kan worden voorgesteld.

Daarnaast bestaan er reeds lange tijd allerlei scripting talen waarmee men taken kan automatiseren. Deze komen voor in verschillende vormen. Vooreerst zijn er de typische macro’s, zoals b.v. in Ms Excel, waarmee men binnen één toepassing zaken kan gaan automatiseren. Daarnaast zijn er echter ook meer algemene talen, waarmee men generische toepassingen kan bedienen. Een voorbeeld hier is AutoIt voor Windows, of de open source tool Selenium (waarin men met verschillende programmeer-talen kan werken), die zich vooral focust op het testen van webtoepassingen. RPA zal typisch zaken verenigen uit al deze soorten software: men biedt een zeer brede ondersteuning (zowel desktop als web), met opnamefunctionaliteit en een grafische manier om het proces weer te geven.

En de Toekomst?

RPA is verwant met Business Process Management (BPM). De P in beide acroniemen staat dan ook telkens voor “Process”. Het valt dus te verwachten dat beide soorten technologieën stilaan naar elkaar zullen toegroeien. Men zal dan totaaloplossingen krijgen voor het beheer van processen, waarin ruimte is om zowel de menselijke taken op te vangen, als om zaken op een automatische manier te doen, en dit in een ruimer kader, met inbegrip van beheer en orkestratie.

Daarnaast komt er ook steeds meer AI aan te pas in deze software suites. Ook dit zal dus meer en meer ‘normaal’ worden. Steeds vaker zal men “slimme” suggesties kunnen krijgen voor de volgende stap in een proces, of sterker nog: volledige processen zullen door het AI a.h.w. “ontdekt” en eventueel ook gestroomlijnd kunnen worden.

Voor- en Nadelen

Snelle ROI

Het grote voordeel van RPA is dat men zaken kan automatiseren zonder bestaande systemen te moeten aanpassen of integreren, wat typisch een moeilijke oefening is. Bovendien is de technologie vrij gebruiksvriendelijk en leidt ze snel tot resultaten. Men kan dus snel een goede Return on investment (ROI) bekomen. Daarnaast is het ook zo dat, eens een process door een robot wordt uitgevoerd, het steevast op dezelfde manier zal worden uitgevoerd. De consistentie zal hoger liggen dan bij uitvoering door menselijke werkers. Die laatste zijn trouwens typisch ook erg tevreden, want RPA neemt de “domme”, repetitieve taken van hen over, zodat ze zich kunnen focussen op het interessantere deel van hun takenpakket. Zogenaamde “power users”, op hun beurt, zijn soms ook in staat om zélf een RPA bot te ontwikkelen, dus de technologie zorgt zeker voor opportuniteiten. Ten slotte, indien een RPA robot faalt, kan er meestal worden overgeschakeld op een manuele uitvoering van het werk. De taak kan dus nog steeds worden uitgevoerd, zij het typisch trager. Dit kan men zien als een vorm van graceful degradation.

Nood aan Governance

Nadelen zijn er echter ook: RPA oplossingen zijn dikwijls slechts een tijdelijke stoplap, totdat er een oplossing ten gronde kan worden gevonden. Dit laatste zal inhouden dat men bestaande systemen beter zal integreren en gebruiksvriendelijker zal maken, waardoor bepaalde taken sowieso door de applicatie kunnen worden opgevangen. Het gebruik van RPA mag trouwens ook geen excuus worden om de software die ermee wordt aangestuurd, daarna niet meer te verbeteren. Sterk in verband hiermee is er bovendien nog een ander nadeel: de RPA robot is gevoelig voor veranderingen in de gebruikersinterface van onderliggende toepassingen: meestal zal hij niet meer functioneren en dus onderhoud nodig hebben, wanneer men in meer of mindere mate wijzigingen aanbrengt aan de gebruikte toepassingen. Daarnaast moet men ervoor uitkijken dat een wildgroei van RPA bots geen onoverzichtelijk kluwen wordt. Enterprise versies van RPA software, die orkestratie toelaten, zijn dan zeker geen overbodige luxe.

Besluit

RPA technologie kan in bepaalde gevallen soelaas brengen aan eindgebruikers die zich overstelpt zien met repetitief werk. De ROI is vaak sterk en de software om de robots mee te bouwen is matuur. Tegelijk moet men ook kritisch zijn in de keuze van use case. Het beste is om RPA enkel toe te passen daar waar men nog geen andere, meer fundamentele plannen heeft, op relatief korte termijn, om zaken te integreren of vervangen. Men moet er bovendien goed op letten RPA eerder chirurgisch in te zetten om de grootste pijnpunten aan te pakken, en geen wirwar van tientallen of honderden bots te creëren, die voor hun eígen onderhoudsproblematiek zorgen. Een goede tip kan zijn om reeds bij het invoeren van een RPA-oplossing ook al aan de zogenaamde phase-out te denken.

RPA zal tegenwoordig geregeld worden voorgesteld door externe consultancy bedrijven. Voor deze ondernemingen is de technologie namelijk ideaal: de ontwikkeling kan snel gebeuren en al gauw is een sterke ROI aan te tonen. Tegelijk moet men geen moeilijke integratieoefeningen oplossen en hoeft men zich in het algemeen geen grote zorgen te maken over reeds bestaande toepassingen (die men zelf niet heeft ontwikkeld). Deze hoeven enkel aangestuurd en niet aangepast te worden. Het is belangrijk dat de klant zich bewust is van het onderhoudsvraagstuk. Consultancy om RPA in te voeren kan zeker nuttig zijn, maar ook hier geldt: drinken met gezond verstand, (en met mate) !

Quick Review

Van UiPath, één van de marktleiders wat betreft RPA technologie, maakten we een Product Quick Review, die vind je hier. In de review bespreken we ook een tweetal voorbeelden van wat we er zoal mee kunnen automatiseren.

Bij het opstellen van de vragenlijst is het uitgangspunt telkens “wat moet ik na het gesprek minimaal weten”. Dit kan betrekking hebben op: het verduidelijken van eerder bekomen informatie, het verduidelijken van de huidige manier van werken, knelpunten detecteren, …

Het verduidelijken van eerder bekomen informatie.

Via een interview wenst men meer informatie te bekomen over bepaalde begrippen, de werking van systemen, …. In deze situatie is het vaak handig om voorbeelden mee te brengen: een kopie van een formulier, grafieken, screenshots. Op basis van deze voorbeelden kunnen dan concrete vragen gesteld worden aan de gesprekspartner.

Het verduidelijken van de huidige manier van werken & knelpunten

Minimaal omvat dit voor het As Is proces vragen over volgende punten:

1) Wie doet wat wanneer?

Meestal kan men deze vraag stellen onder de vorm van “Een aanvraag komt binnen en wat doe je dan?”. Via een dergelijke vraag begint de gesprekspartner het volledige proces te doorlopen. Vaak is dit de ideale openingsvraag omdat deze betrekking heeft op het dagelijks werk van de gesprekspartner. Hij kent de materie door en door en deze vraag zal de gesprekspartner dan ook sneller op zijn gemak stellen. Dit zal er voor zorgen dat de rest van het gesprek vlotter zal verlopen.

2) Over welke ”volumes”, “frequenties”, “doorlooptijden” spreken we?

Typisch worden deze vragen gesteld tijdens het doorlopen van het volledige proces (zie voorgaande). Deze informatie zal in een later stadium belangrijk zijn om prioriteiten te stellen of bij het opstellen van de niet-functionele requirements.

3) Welke knelpunten ziet de gesprekspartner?

• Afhankelijk van de situatie kan deze vraag op het einde van de bespreking van het As Is proces gesteld worden of tussenin. Ik persoonlijk zal deze vraag eerder op het einde stellen omdat zo vermeden kan worden dat As Is informatie vermengd wordt met To Be discussies. Het risico bestaat immers dat er dan voor het As Is proces zaken vergeten worden.
• Bij het stellen van deze vraag is het ook steeds belangrijk om voorbeelden te vragen. Dit is vooral noodzakelijk om de ernst van het probleem na te gaan. Het komt voor dat een gesprekspartner problemen opsomt terwijl er eigenlijk geen of zeer weinig voorbeelden gegeven kunnen worden. Ook als er geen voorbeelden gegeven kunnen worden is het belangrijk om tijdens het gesprek nog geen waardeoordeel te geven. Bij een negatief waardeoordeel zou de gesprekspartner kunnen dichtklappen en geen verdere problemen meer naar voor brengen.
• Tegelijk met de vraag naar knelpunten kan ook gevraagd worden welke oplossingspistes de gesprekspartner zelf ziet. De kans bestaat natuurlijk dat de voorgestelde oplossing onvoldoende rekening zal houden met alle aspecten van het probleem. Niettemin bevat de voorgestelde oplossing vaak elementen die toch overgenomen kunnen worden in het uiteindelijke oplossingsvoorstel.
• Na voorgaande vraag kan ook gevraagd worden of er in het verleden al initiatieven werden genomen om het probleem op te lossen. Belangrijk hierbij is te weten te komen waarom deze initiatieven niet succesvol waren. De kans is reëel dat dezelfde risico’s zich ook nu zullen voordoen. Voor deze risico’s zal dus bepaald moeten worden hoe deze nu aangepakt zullen worden.

Tijdens het gesprek is het belangrijk om regelmatig na te gaan of men alles wel goed heeft begrepen. Door bijvoorbeeld beknopt het proces te herhalen en bevestiging te vragen of dit goed begrepen werd heb je als interviewer de zekerheid dat alles goed werd genoteerd en dat er door de geïnterviewde geen stappen werden overgeslagen. Een bijkomend voordeel is ook dat het herhalen van informatie de geïnterviewde de bevestiging geeft dat er effectief naar hem / haar geluisterd wordt.

De techniek van het herhalen van wat er gezegd werd is ook belangrijk wanneer er opsommingen worden gemaakt. Zeker als er na elk punt uit de opsomming een vrij lange bespreking volgt. Door op het einde van de bespreking de voorgaande punten te herhalen zal de geïnterviewde onmiddellijk weten welke punten nog niet werden besproken. Het herhalen garandeert dus dat er geen punten worden vergeten.

Op het einde van elk gesprek is het belangrijk om steeds te vragen of er zaken zijn die nog niet besproken werden tijdens het gesprek. Dit geeft aan de geïnterviewde de kans om elementen naar voor te brengen waaraan de business analist nog niet heeft gedacht.

Indien er meerdere interviews over een gelijkaardige materie werden voorzien dan is het belangrijk dat in functie van de eerder bekomen informatie de vragenlijst telkens wordt aangepast. Het heeft meestal geen zin om te doen alsof elk gesprek het eerste gesprek is. Tijdens een volgend gesprek kan de eerder bekomen informatie verder uitgediept worden of kan er bevestiging gezocht worden voor bijvoorbeeld de aangehaalde problemen.

Deze blog gaat iets dieper in op de complexiteit van een business analyse die opgestart wordt in het kader van een domeinoptimalisatie. Tijdens een domeinoptimalisatie moet er nagegaan hoe de efficiëntie binnen een volledig domein (vb. eerstelijnsgezondheidszorg, hulpverleningsdiensten, …) verhoogd zou kunnen worden. Dergelijke business analyses zijn dus vaak vrij high level analyses. Voor heel wat betrokkenen, en in het bijzonder de actoren “uit het veld”, zijn deze analyses vaak te abstract. Voor hen is niet duidelijk wat de impact zal zijn op hun manier van werken. Wat de voor- en nadelen zullen zijn. Zolang het voor een betrokkene niet duidelijk is wat de impact zal zijn, kan er ook niet verwacht worden dat deze persoon voluit de ideeën die naar voor gebracht worden tijdens de business analyse zal ondersteunen. Veelal nemen deze personen dan, in het beste geval, een afwachtende houding aan. Dit helpt de realisatie van ideeën natuurlijk niet vooruit!

Het komt er dus op aan om tijdens de business analyse de globale voorstellen en principes voor iedereen zo concreet mogelijk te maken. Een mogelijke techniek die hierbij gebruikt kan worden is het gebruik van scenario’s. Scenario’s moeten hierbij aanzien worden als processen of situaties die zich zowel in de huidige als toekomstige situatie voordoen. Een scenario laat toe om te simuleren wat de gevolgen zullen zijn van de nieuwe situatie voor alle betrokken partijen. Bij de beschrijving van het scenario is het vooral belangrijk om aan te geven wat de verschilpunten zullen zijn tegenover de huidige situatie. Dit zowel in positieve als negatieve zin. Wat niet verandert moet niet uitgebreid beschreven worden.

Om te garanderen dat elke actor ziet wat de impact op hem zal zijn kan het dus noodzakelijk zijn om meerdere scenario’s uit te werken. Hierbij is het natuurlijk niet de bedoeling om te overdrijven met het aantal scenario’s. Te veel scenario’s worden weer verwarrend voor de betrokkenen. Een paar scenario’s die duidelijk van elkaar verschillen volstaan.

Het simuleren van de gevolgen voor elke partner is de hoofreden voor het gebruik van scenario’s. Uit de praktijk blijkt echter ook dat eens voor iedereen de gevolgen concreet werden gemaakt er vanuit de business ook meer nagedacht wordt over welke impact men eerst gerealiseerd wenst te zien. De creatie van scenario’s heeft dus ook gevolgen voor de fasering van de domeinoptimalisatie. Met als belangrijk voordeel dat het nu de business zelf is die de fasering kan aansturen. Door vanuit de business bepaalde scenario-onderdelen naar voor te schuiven wordt dus bepaald welke onderliggende systemen of processen in eerste instantie voorzien moeten worden.

Voor alle duidelijkheid hierbij ga ik er van uit dat een interview georganiseerd wordt met een zeer beperkt aantal personen terwijl voor een workshop een groot aantal deelnemers wordt uitgenodigd.

Interviews

Voordelen van interviews

• Tijdens een interview kan je als analist gemakkelijk doorvragen op de bekomen informatie. Er ontstaat een echt gesprek tussen de business analist en de geïnterviewde. Er zijn geen derden aanwezig die het gesprek kunnen onderbreken of een andere richting uitduwen.
• Het gesprek kan plaatsvinden in de eigen omgeving van de geïnterviewde. Dit maakt het gemakkelijker om zaken die besproken worden tijdens het interview ook effectief te tonen. Dit kan gaan om het demonstreren van de werking van een softwaretoepassing, besproken documenten of forumlieren, de specifieke inrichting van een ruimte, …
• Tijdens een persoonlijk gesprek zal de geïnterviewde vaak ook off-the-record informatie meegeven. Deze informatie is dan niet bedoeld voor het verslag maar kan wel essentiële informatie zijn voor de business analist. De specifieke gevoeligheden of de echte redenen waarom bepaalde zaken gedaan worden, worden vaak enkel tijdens een persoonlijk gesprek meegedeeld.

Nadelen van interviews

• Het belangrijkste nadeel van interviews is dat ze veel tijd vragen van de business analist. Met elke gesprekspartner dient een interview georganiseerd te worden en er is de tijd die elk gesprek afzonderlijk inneemt. Als de interviews dan ook nog eens op verschillende locaties worden georganiseerd dan moeten ook de verplaatsingstijden in rekening worden gebracht.

Het organiseren van interviews kan dus een aanzienlijk groter budget vragen dan het organiseren van workshops.

Wanneer toe te passen?

• Wanneer detailinformatie nodig is over een specifiek domein, proces, toepassing,… dan zijn interviews vaak de meest aangewezen techniek. Vooral de mogelijkheid tot het doorvragen en tonen van zaken is zeer belangrijk wanneer gedetailleerde informatie noodzakelijk is.
• Het bespreken van problemen of oplossingen met hiërarchisch hoog geplaatste personen verloopt beter via een persoonlijk gesprek. Omdat dergelijke besprekingen gevoelig kunnen liggen is het daarom beter om, zeker bij een eerste aftoetsing, deze gesprekken onder vier ogen te organiseren.

Workshops

Voordelen van workshops

• Workshops hebben als belangrijk voordeel dat er een interactie kan ontstaan tussen de deelnemers. Een probleem of oplossing wordt door de groep besproken en door de wisselwerking tussen de deelnemers kan men komen tot conclusies die niet mogelijk waren indien de gesprekken werden gevoerd met de individuele deelnemers afzonderlijk.
• Door de hoeveelheid aan opinies die in een sessie verzameld kunnen worden verloopt de informatie inzameling efficiënter dan via interviews.

Nadelen van workshops

• Workshops vragen een strikte moderatie. Zeker voor een beginnende business analist is het niet steeds eenvoudig om die rol op zich te nemen. Indien de moderator zijn rol niet voldoende opneemt dan bestaat het risico dat diverse discussies door elkaar worden gevoerd, thema’s niet besproken worden, ideeën niet uitgediept worden, …
• De aanwezigheid van hiërarchisch hoog geplaatste personen kan een rem vormen voor de overige deelnemers om effectief deel te nemen aan de workshop. Vrij vaak komt het dan voor dat deelnemers enkel nog de mening van de verantwoordelijke herhalen. Dergelijke workshops leveren slechts een beperkte toegevoegde waarde op.

Wanneer toe te passen?

• Workshops werken zeer goed wanneer oplossingspistes besproken moeten worden. Zeker wanneer er zeer diverse partijen betrokken zijn bij de uiteindelijke oplossing kunnen workshops een grote meerwaarde bieden.
• In het algemeen werken workshops beter wanneer er geen hiërarchische band bestaat tussen de betrokken partijen. Het nadeel waarbij de aanwezigen enkel de mening van de hoogstgeplaatste herhalen speelt dan niet en elke deelnemer zal sneller voor zijn eigen mening durven uitkomen.

De keuze voor interviews of workshops is natuurlijk ook geen alles of niets keuze. In realiteit zal tijdens een opdracht vaak gekozen worden voor een combinatie van beide. Vaak start de business analist met een aantal interviews, dit om voeling te krijgen met de materie, waarna een of meerdere workshops kunnen volgen.

Nous avons insister sur le fait que ces deux fonctions doivent être vues comme étant des rôles, une même personne pouvant, selon la phase du ou des projets en cours, occuper tantôt un de ces deux rôles et tantôt l’autre. La taille de l’organisation est le déteminant principal quant à la distribution ou non de ces deux fonctions sur des personnes distinctes .

Par rapport au processus RUP, nous avons situé les interventions du business analyst dans les phases d’inception et d’elaboration.

Une fois arrivé le temps de la construction phase, il est temps de changer de casquette (ou de faire intervenir les functional analysts, qui agissent alors dans la continuité des business analysts): place à l’analyse fonctionnelle, dont le but est d’entrer dans le détail de ce qui a été fait dans les phases précédentes. Vous l’aurez compris, la phase précédente correspond à une préoccupation de cadrage / définition soignée du projet pour garantir l’alignement business case / projet, au juste niveau de détail.

On entre ici, et selon moi seulement ici, dans le vrai pré carré de l’approche agile, avec la souplesse et la réactivité aux adaptations sur les requirements qui la caractérise.

Il s’agit maintenant de détailler les use cases, de définir les layouts et contenus d’écrans, les règles métiers relatives aux calculs (via langage naturel ou tables de décision), les modèles de données logiques, d’établir les scénarios de test détaillés. Le détail des use cases pourra être élaboré en s’appuyant sur la notion de user stories (voir Visual Paradigm par exemple), concept propre aux méthodes agile, et qui serviront à alimenter le product backlog selon la méthode Scrum.

C’est aussi maintenant que sont spécifiés dans le détail tous les éléments réutilisables (services [called] et librairies [embedded]).

A ce stade la collaboration entre le business analyst et l’enterprise architect est maximale : il s’agit pour ces deux rôles de définir précisément l’architecture SOA à mettre en place , en faisant intervenir les notions de taxonomie et de typologie de services (nous n’entrerons pas dans l’explication de ces notions ici – un autre blog peut-être). J’insiste sur ce point : la réussite de la mise en oeuvre d’une architecture orientée service est d’abord le résultat d’une collaboration réussie entre business analyst(s) et enterprise architect(s).

Au delà de l’architecture de services, business analyst(s) et entreprise architect(s) doivent aussi veiller à établir et à maintenir la cartographie applicative et des données (relevé des applications et des services, alimentation du data dictionnary, …).

Point d’attention : des découvertes effectuées pendant la construction phase peuvent devoir être remontées au niveau des documents produits par la business analysis.

Je voudrais aussi insister dans ce blog sur le parallèle suivant : de la même manière que l’on attribue aujourd’hui, de plus en plus, toute l’importance qu’elle mérite à la gestion du code (naming and coding conventions, structuration des projets, gestion de version, visualisation des différences entre versions, quality metrics, peer review, …) il convient d’en faire autant avec les délivrables de l’analyse (la recommandation n ‘est pas nouvelle !). De ce point de vue, je suis amené à constater que les approches agile tentent à un certain laxisme, pour ne pas dire plus, sur la gestion de la qualité de la documentation.

Les mêmes concepts doivent être d’application pour l’analyse : la documentation doit être standardisée, maintenable, pérenne, comprise par ses destinataires, aujourd’hui et demain aussi. La documentation du niveau business en particulier est LE pilier du transfert et donc du maintien de la connaissance métier dans l’organisation. Le passage de témoin entre les générations de collaborateurs l’exige.

Ceci est d’autant plus important lors de la présence d’intervenants extérieurs : trop nombreux sont ceux qui pratiquent le “freestyle” (à chacun sa(ses) manière(s) de faire), attitude entretenue par la mode agile, quand cela ne correspond pas à un objectif caché de verrouillage sur les connaissances nécessaires pour être à même de piloter les développements IT et se rendre indispensables sur le long terme dans l’organisation.

Au sujet du repository pour les documents d’analyse, les offres cloud permettent de ne pas s’encombrer avec la gestion technique de ceux-ci. Mais il convient alors de prendre les précautions nécessaires en matière de sécurité des données, tous aspects confondus. Et sans oublier que placer dans le cloud des savoir-faire métiers qui offrent des avantages concurrentiels n’est jamais une bonne idée.

Une comparaison pour aider à la compréhension sur la distinction entre les deux rôles de business analyst et de functional analyst : le binôme business analyst / functional analyst est comparable au binôme enterprise architect / application architect. La différence entre ces deux niveaux de fonction relève de l’importance du scope à balayer et consécutivement du niveau de détail moins élevé attendu des deux premières. Business analyst et enterprise architect sont les garants de la prise en compte globale et donc, par extension, de l’optimisation globale et de la réutilisation, sur les données et sur le code.

En conclusion : la prise en considération des distinctions entre ces deux rôles de business analyst et functional analyst est une assurance pour un équilibre judicieux entre l’approche plutôt Waterfall (cadrage et préparation) et l’approche résolument  Agile (réactivité aux changements en cours de développement).

Et dernière réflexion : lors de l’élaboration d’un plan directeur informatique, qui se doit d’avoir pour tout premier objectif l’alignement de l’IT sur le business, les business analysts sont à l’évidence des fournisseurs d’information de tout premier plan. Au même titre que les enterprise architects.

Een eerste probleem is dus het presenteren van processen. Bij de projectie van het volledige schema is de tekst op het schema meestal onleesbaar. Wanneer echter een gedeelte van het proces wordt uitvergroot dan verliezen de aanwezigen het zicht op het geheel. Een oplossing die in de praktijk vaak blijkt te werken is de volgende:

• Op het scherm wordt het globale proces geprojecteerd.
• De geprojecteerde tekst is niet leesbaar, daarom wordt het proces voor de aanwezigen ook afgedrukt. Liefst op A3-formaat zodat er nog genoeg ruimte is om notities toe te voegen.
• Om het voor de deelnemers gemakkelijker te maken om de bespreking te volgen wordt op het geprojecteerde proces telkens aangegeven welk onderdeel besproken wordt. In volgende paragraaf van deze blog wordt besproken hoe men dit kan realiseren. Het grote voordeel hierbij is dat een aanwezige steeds opnieuw kan inpikken tijdens de bespreking van het schema, ook als hij bijvoorbeeld even werd weggeroepen.

 Een tool zoals PowerPoint (of een andere presentatietool) biedt een aantal eenvoudige technieken die gebruikt kunnen worden bij het presenteren van processen. Via transparante rechthoeken kunnen onderdelen van het schema geaccentueerd worden (zie afbeelding links).  Een bijkomend voordeel hierbij is dat de analist de schema’s niet sequentieel hoeft te bespreken. Hij kan steeds die onderdelen accentueren die noodzakelijk zijn voor zijn verhaal.

Het creëren van dergelijke transparante rechthoeken is vrij eenvoudig in PowerPoint.  Het volstaat een rechthoek te tekenen bovenop het schema, deze op te vullen met een kleur en de transparantie aan te passen naar bijvoorbeeld 70% (zie afbeelding links). Via de animatiemogelijkheden van PowerPoint kan men dan bij elke klik de gewenste rechthoeken laten verschijnen of weer verdwijnen.

Zoals gezegd in de inleiding vormt het verwijzen naar het schema tijdens een discussie een ander probleem. Een vrij eenvoudige oplossing, maar die in de praktijk goed werkt, is het nummeren van alle symbolen op het schema. Via deze nummers kunnen deelnemers aan de vergadering dan vragen stellen zoals “waarom is er een pijl van stap 7 naar 15”, “wat gebeurt er precies in stap 13”, … Zonder dergelijke nummers is het voor de aanwezigen moeilijk om exact aan te geven welk onderdeel van het schema ze wensen te bespreken. Nadeel aan deze techniek is dat het voor de analist vrij veel werk vraagt om nummers toe te voegen. Zeker als er veelvuldig wijzigingen worden aangebracht aan het schema. Gelukkig bieden toepassingen zoals Visio een aantal hulpmiddelen die helpen bij het nummeren en hernummeren van symbolen. In Visio 2010 kan men deze terugvinden onder “View”  – “Add-Ons”  –  “Visio Extra” – “Number Shapes”.

De in deze blog besproken technieken zijn natuurlijk voornamelijk van toepassing wanneer processchema’s aan grotere groepen gepresenteerd dienen te worden. Vooral in die situaties is het belangrijk dat men de nodige middelen voorziet zodat alle aanwezigen begrijpen waarover het schema gaat en er een echte discussie kan volgen.

Toch is het ook relatief eenvoudig om op basis van de BPMN-standaard schema’s te creëren die onbegrijpbaar zijn voor business users. Wanneer de BPMN standaard rigoureus wordt gevolgd dan ontstaan schema’s met symbolen die totaal niet intuïtief zijn voor business users. Ik denk hierbij onder meer aan volgende symbolen:

Slechts weinig business users kennen de betekenis van deze symbolen (klik op de afbeelding voor een beter leesbare versie van de twee activiteiten links). Komt daar nog bij dat deze symbolen slechts enkele voorbeelden zijn van een nog veel ruimere set. De betekenis die men via deze symbolen wil toevoegen aan een schema zal dus helemaal niet begrepen worden door business users.  Dit is natuurlijk bijzonder jammer omdat een processchema nu net een instrument is dat gebruikt wordt om overeenstemming te bereiken tussen alle partijen. Als een deel van het schema niet begrepen wordt hoe kan men dan zeker zijn dat alle partijen akkoord zijn over hetzelfde?

Pogingen om de betekenis van symbolen dan maar via een legende toe te voegen aan een schema halen helaas ook niet veel uit. De meeste business users hebben gewoon niet de tijd om de legende grondig door te nemen of de, vaak subtiele, verschillen worden gewoonweg niet begrepen.

Voor het uittekenen van processen is het als business analist daarom beter om het aantal verschillende symbolen zo beperkt mogelijk te houden. Uit mijn eigen ervaring heb ik ondervonden dat voor nagenoeg elke type schema dat besproken moet worden met business users volgende symbolen volstaan:

Door enkel deze symbolen te gebruiken zal niet elk schema volledig voldoen aan de BPMN-standaard. Maar de vraag is natuurlijk “Wat is er het belangrijkst: de standaard of de leesbaarheid?”

Si la nécessité de la fonction d’analyste fonctionnel (functional analyst) est universellement reconnue dans la sphère IT, la fonction de business analyst est plus méconnue et la distinction entre les deux fonctions souvent mal comprise.

Je vais tenter ici de la clarifier. Bien entendu, dans le cadre d’un blog, je ne peux que survoler le sujet.

La vision dégagée ici est celle mise en place dans le cadre d’une institution de Sécurité Sociale occupée à refondre son système IT et qui a mis en place une équipe de 6 business analysts. Elle est donc propre à cette organisation.  Je suis actuellement responsable du coaching de cette équipe.

Tout d’abord, il convient d’insister sur le fait que ces deux fonctions doivent être vues comme étant des rôles, une même personne pouvant, selon la phase du ou des projets en cours, occuper tantôt un de ces deux rôles et tantôt l’autre. La taille de l’organisation et donc souvent, par voie de conséquences, l’étendue des domaines fonctionnels,  est évidemment déterminante quant à la distribution ou non de ces deux fonctions sur des personnes distinctes .

Mais en tous les cas, elles doivent veiller, selon moi, à ne porter qu’une seule de ces deux casquettes à un moment donné. La raison principale est que les deux rôles ont des publics cibles prioritaires  différents.

Dans le cadre d’un premier blog sur le sujet, intéressons-nous d’abord aux responsabilités et aux outils nécessaires au business analyst. Un second blog , à paraître plus tard, explicitera davantage la distinction entre les deux rôles.

Le business analyst est responsable:

• De travailler sur les business case avec le(s) chef(s) de projet
• Une fois un projet identifié, d’établir le scope document correspondant en collaboration avec le chef de projet désigné
• Sur ce point l’établissement d’un diagramme de contexte (context diagram) est un must.
• D’identifier et formaliser  les processus métiers à haut niveau de manière transverse, internes et externes (B2B), en ce compris les traitements des exceptions (!)
• L’un de ses outils privilégié sera donc un process modeler, idéalement basé sur le langage de formalisation BPMN (dont l’utilisation sera limitée aux fonctionnalités de base). Il devra être attentif à bien identifier/distinguer les sous-processus d’un processus principal, ce afin  de préserver une vue holistique permettant la maîtrise du tout par une approche drill-down (du général vers le détail).
• Au sein des processus et sous-processus il identifiera les tâches à accomplir (un processus n’est jamais qu’une succession de tâches), soit les high level use cases. L’identification de ces tâches lui permettra de découvrir la “matière première” des traitements  à effectuer, à savoir les données.
• Sur les tâches et les données, en tant que business analyst, son rôle se limite à établir une définition high level (comprenez sans excès de détails). Ainsi, il se doit :
  • D’établir le modèle de données conceptuel
  • D’établir un glossaire des termes métiers en vue de normaliser le vocabulaire employé lors des communications entre les différents acteurs (je reviens un peu plus loin sur ce point)
  • D’identifier les acteurs, rôles et responsabilités (indispensable pour la définition de la sécurité applicative)
  • D’identifier les évènements déclencheurs des processus, les données en entrée et en sortie, les règles métiers de transition entre les tâches
• De challenger les solutions actuelles et en particulier de relever toutes les possibilités de simplification – the business analyst must be a no added value killer (lean approach) !
• De relever les opportunités de réutilisation sur base de la connaissance métier (à l’inverse des architectes qui le font plutôt sur base de la connaissance des assets techniques).
• D’établir le glossaire métier en vue de mettre en place un vocabulaire partagé entre tous les acteurs – cette activité a toute son importance : à elle seule la non standardisation du vocabulaire employé dans les discussions peut être la cause  d’opportunités de réutilisation manquées. Et, faut-il le dire, de réunions inefficaces, suite à des incompréhensions dont le plus regrettable est qu’elles ne sont que rarement avouées (sur ce point, faut-il le dire, les responsables hiérarchiques ont un rôle d’exemple à jouer).
• D’alimenter le data dictionnary (cette activité est indissociable de la précédente) – le maintien d’un data dictionnary est à mes yeux une tâche essentielle des business analysts.
• De détecter les mesures à même d’augmenter la qualité et la cohérence des données (unicité).

Le business analyst joue un rôle clé en matière d’élaboration des scénarios de test : il est responsable de vérifier que les UATs (User Acceptance Tests) garantissent le bon alignement de la solution développée sur les besoins exprimés dans la  business analysis.

La formalisation des business process, des use cases et du modèle de données conceptuel requière idéalement un outil de design BPMN/UML accompagné d’un repository permettant la gestion de version et la centralisation de tous les artefacts produits. L’outil devra permettre la génération de documents Word sur base de templates customizables. Point d’attention : la facilité de mise en oeuvre de ces templates est fort variable d’un outil à l’autre – il  s’agit là d’un différentiateur important en termes de  productivité et d’efficacité dans la communication avec les autres parties.

Le business analyst doit être capable d’élaborer tout à la fois:

• D’une part, les documents nécessaires à la validation par les expert métiers : mind maps (très utiles à la capture et la première organisation des idées), documents Word agrémentés de schémas, présentations PowerPoint,  tableaux Excels, … bref une démarche que je qualifierai de “low tech”;
• D’autre part, les documents servant à préparer le travail du functional analyst – ceux-ci font un usage plus important du formalisme UML – la démarche sera ici de type “mid tech”.

Il convient d’insister sur la nécessité des échanges fréquents entre les business analysts travaillant sur des domaines fonctionnels différents. Les optimisations doivent en effet être globales et non pas locales aux domaines fonctionnels. Un rôle de coordinateur est à prévoir (espérer ne suffit pas – il faut provoquer ce que l’on veut obtenir).

Le business analyst se doit encore d’être :

• L’aiguillon du business pour entretenir une démarche de progrès permanent dans la maintenance des processus métier et des modèles de données ;
• L’avocat du business vi-à-vis de l’IT, par l’intermédiaire de l’enterprise architect et du(des) chef(s) de projet(s).

Enfin, le business analyst doit être le bibliothécaire de la connaissance métier : il est responsable de la qualité de la documentation métier et de sa bonne gestion. Il veillera donc à la fois à la standardisation et à la qualité des documents d’analyse, de même qu’à la standardisation et à la qualité de son organisation au sein d’un (ou de plusieurs) repository. La règle en or : un artefact quel qu’il soit doit être facilement localisable et interprétable par quiconque dans l’organisation.

Dans le cadre du processus RUP (que je me refuse personnellement à oublier malgré une forme de déferlante au tout à Scrum – les deux sont en fait complémentaires), le business analyst intervient donc en amont, sur les phases d’inception et d’elaboration.