Onder meer als gevolg van de 6^e staatshervorming zijn in België een aanzienlijk aantal processen binnen de gezondheidszorg herzien. Dit heeft vaak tot gevolg gehad dat het aantal actoren dat deelneemt aan een proces toegenomen is.  Een voorbeeld is de verwerking van de factuur van een woonzorgcentrum. Een factuur wordt door een Vlaams woonzorgcentrum elektronisch verstuurd. Het versturen van de factuur zet een gans mechanisme van controles en informatiestromen in gang. In de achtergrond wordt gecontroleerd of de bewoner van het woonzorgcentrum verzekerd is, informatiestromen tussen de zorgkas van de bewoner en zijn mutualiteit worden opgezet om kortingen te bepalen, er wordt nagegaan of er geen sprake is van een dubbele facturatie, enz. Dit voorbeeld is nog relatief eenvoudig omdat de communicatie asynchroon verloopt. Complexer wordt het als de gebruiker van een dienst onmiddellijk een antwoord verwacht.

In alle situaties is het echter belangrijk om een goed overzicht te behouden van wie verantwoordelijk is voor het aanbieden van welke functies. Dit is vaak niet zo eenvoudig omdat een aanbieder van een functie zelf ook nog met “onderaannemers” kan werken. Het geheel wordt dan zeer complex en vaak heeft niemand nog een zicht op alle componenten waaruit een dienst is opgebouwd.

Een recente discipline, system of systems engineering, richt zich specifiek op dergelijke complexe systemen. Een system of systems wordt door wikipedia omschreven als: “System of systems is a collection of task-oriented or dedicated systems that pool their resources and capabilities together to create a new, more complex system which offers more functionality and performance than simply the sum of the constituent systems.” 

Typisch voor dergelijke systemen is het feit dat er geen partij is die verantwoordelijk kan gesteld worden voor het geheel. Elke partij is verantwoordelijk voor zijn specifiek onderdeel. Zeker bij diensten waar de gebruiker onmiddellijk een antwoord verwacht, wordt het een grote uitdaging om steeds te kunnen garanderen dat elke component beschikbaar zal zijn en snel zal kunnen antwoorden. Een formeel overlegmodel tussen alle betrokken actoren waarbij problemen en evoluties afgestemd worden is hierbij een absolute noodzaak.

Modelleren

Een voorwaarde om dit mogelijk te maken is natuurlijk dat er eerst een duidelijk zicht is op wie er betrokken is en welke rol elke actor speelt. Binnen Smals Research werd nagegaan welke methodologie gevolgd zou kunnen worden voor het modelleren van een system of systems. Volgende stappen werden tot nu toe onderscheiden:

1. Definiëring problem space: vastleggen van wat men wil bereiken met de modelleringsoefening: welke vragen wil men kunnen beantwoorden? Deze eerste stap legt het kader vast waarbinnen het model zal uitgewerkt worden. Op basis hiervan wordt bepaald wie gecontacteerd zal worden en wat de prioriteiten zullen zijn.
2. Identificatie van actoren: wie gecontacteerd moet worden, wordt volledig bepaald door de in de voorgaande stap vastgelegde problem space. Op basis van het gedefinieerde domein wordt vastgelegd wie betrokken wordt. Dit is een iteratief proces. Op basis van de gevoerde discussies worden bijkomende actoren opgenomen in de modelleringsoefening.
3. Clusteren van actoren: actoren worden gegroepeerd volgens de functies die aangeboden worden. Een cluster staat in voor het aanbieden van een of meer functies.
4. Identificatie van de relaties tussen individuele actoren of clusters: diverse relatietypes zijn mogelijk: financieel, uitwisseling van informatie, uitwisseling van fysieke stukken, “beïnvloedend” en “regulerend”. Typisch wordt gestart met het in kaart brengen van de eerste drie relatietypes.
5. Verrijken model: In functie van de gedefinieerde problem space wordt het model verrijkt met bijkomende elementen zoals: de rol die elke actor speelt, bottlenecks, single points of failure, …

Proefproject

Vanuit de afdeling Onderzoek zal de komende tijd nagegaan worden of er, binnen de sectoren waarin Smals actief is, interesse bestaat om een proefproject rond System of Systems engineering op te zetten.

______________________

Dit is een ingezonden bijdrage van Renzo Lylon, business consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Totaaloplossingen hebben als voordeel dat men onmiddellijk beschikt over een werkend systeem dat alle nodige componenten bevat. In proefprojecten en in een eerste fase zijn totaaloplossingen dus zeker een goede benadering om snel resultaten te kunnen boeken.

Hoe meer van dergelijke totaaloplossingen er naast elkaar gebruikt beginnen te worden hoe meer de problemen van deze systemen echter naar boven zullen beginnen komen. De problemen die kenmerkend zijn voor totaaloplossingen zijn onder meer:

• Als de patiënt een tweede opinie wil dan kan de tweede arts de parameterwaarden niet analyseren indien hij niet hetzelfde systeem gebruikt.
• Een gelijkaardig probleem doet zich voor indien een patiënt van arts wenst te veranderen. Indien deze een ander systeem gebruikt, dan moet de patiënt leren werken met een nieuw toestel. Dit is niet voor alle patiënten evident.
• Omgekeerd kan een arts ook niet gemakkelijk beslissen om een andere analysesoftware te gebruiken. Andere softwareleveranciers zullen vaak geen toegang hebben tot het gesloten systeem, waardoor de arts nagenoeg verplicht is om dezelfde software te blijven gebruiken. Volledig veranderen van systeem is bij een gesloten omgeving niet evident omdat alle patiënten van de arts dan ook een ander registratietoestel dienen te gebruiken.
• Als de systemen worden aangeboden door een ziekenhuis dan zal de huisarts van de patiënt niet altijd een licentie hebben van de gebruikte analysesoftware. Het is voor een huisarts ondoenbaar om over verschillende softwarelicenties te beschikken.

Zoals eerder gezegd zijn in proefprojecten of in een eerste fase totaaloplossingen de snelste manier om resultaten te kunnen behalen. Voordat er echter een wildgroei ontstaat van oplossingen die naast elkaar gebruikt worden zou het misschien goed zijn om na te gaan of er geen oplossing gevonden kan worden voor bovenstaande problemen. In deze blogpost wordt een aanzet gegeven van een mogelijke oplossingspiste.

Oplossingsvoorstel

Ideaal gezien zou dus zowel de patiënt als de arts / ziekenhuis de vrijheid moeten hebben om zelf te bepalen welke registratietoestellen of software zij respectievelijk gebruiken. Een volledige loskoppeling tussen de systemen die instaan voor de registratie van de gegevens en de software die instaat voor de verdere verwerking zou tegemoetkomen aan een groot deel van de eerder opgelijste problemen.

Een volledige ontkoppeling is echter maar mogelijk wanneer een onafhankelijke partij instaat voor een centraal beheer van de medische parameters. Over wie de onafhankelijke partij zou moeten zijn die verantwoordelijk zou worden voor het registratieplatform wordt in deze blogpost geen uitspraak gedaan. Diverse pistes zijn hiervoor mogelijk.

Het centrale register houdt de waarde van de gemeten parameters bij en stelt deze ter beschikking van de hiertoe gemachtigde gebruikers. De onderstaande afbeelding stelt deze manier van werken schematisch voor.

Het grote voordeel van een volledige loskoppeling is dat er een gelijk speelveld wordt gecreëerd voor alle partners. Spelers kunnen zich specialiseren in een unieke functie zonder dat ze ook moeten voorzien in de andere componenten van een gesloten systeem. Verder in deze blogpost wordt er dieper ingegaan op het feit dat de creatie van een gelijk speelveld kansen kan bieden aan nieuwe innovatieve spelers.

Patiënt

De patiënt zou over de vrijheid moeten beschikken om zelf te bepalen welk toestel hij wenst te gebruiken. Deze vrijheid is natuurlijk enigszins beperkt omdat het toestel in staat moet zijn om met het platform dat de medische parameters beheert te communiceren. Het lijkt aangewezen om deze communicatie zoveel mogelijk te baseren op internationale standaarden. De Continua standaard van de Personal Connected Health Alliance (http://www.pchalliance.org/) is bijvoorbeeld een internationale standaard voor medische registratietoestellen. Deze standaard beschrijft onder meer de interface tussen de meettoestellen en de gateway die instaat voor het verzenden van de waardes naar een centraal platform. De website van de organisatie die verantwoordelijk is voor deze standaard bevat een lijst met alle registratietoestellen die momenteel al voldoen aan hun standaard.

Arts

Indien een arts niet langer gebruik moet maken van specifieke software dan kan de functionaliteit om de parameterwaarden te visualiseren en analyseren ingebouwd worden in de eigen EMD software. Dit zou als voordeel hebben dat de parameterwaarden gekoppeld kunnen worden aan de al beschikbare informatie over de patiënt. Door deze koppeling zou dus een vollediger beeld ontstaan van de patiënt binnen de eigen EMD-software.

Anonimisatie van parameterwaarden

Medische parameters zijn gevoelige informatie en moeten dus maximaal beschermd worden. Anderzijds kan het onder voorwaarden beschikbaar stellen van deze parameters aan derden het ontstaan van een volledig nieuwe dienstverlening tot gevolg hebben. Het lijkt daarom aangewezen om de parameters in een afzonderlijke omgeving op te slaan met een eigen technische identificatiesleutel. De relatie met de burger zou dan bijgehouden kunnen worden in bijvoorbeeld een van de bestaande kluizen (Vitalink, RSW of BGN). De zorgverstrekker die toegang heeft tot de informatie in een van de kluizen beschikt over alle identificatiesleutels om de parameters van een specifiek persoon op te halen. Enkel wie toegang heeft tot het parameterplatform krijgt geanonimiseerde gegevens te zien.

Ontstaan van nieuwe innovatieve dienstverlening

Zoals in voorgaande paragraaf aangegeven kan overwogen worden om de geanonimiseerde parameterwaarden ter beschikking te stellen voor verdere verwerking. Deze gegevens kunnen aanleiding geven tot het ontstaan van een nieuwe dienstverlening. Organisaties kunnen bijvoorbeeld de gegevens gebruiken om continu de ingegeven waarden te bewaken. Geavanceerde data analyse technieken of AI detectiemechanismes kunnen ontwikkeld en toegepast worden op de gegevens uit het parameterplatform om eventuele problemen te signaleren. Deze start ups kunnen hun business model bouwen op een toegang tot deze gegevens en hierrond een dienstenaanbod creëren. Het eenvoudig toegankelijk maken van deze gegevens verlaagt de drempel om een nieuwe dienstverlening op te starten. De initiële opstartkosten worden sterk verlaagd indien er geen end-to-end oplossing gerealiseerd moet worden.

Anderzijds kunnen nieuwe spelers ook nieuwe registratietoestellen of apps ontwikkelen en deze aansluiten op het registratieplatform. De enige voorwaarde hierbij is dat deze voldoen aan de gebruikte standaarden. Om deze spelers toe te laten hun toestellen internationaal te vermarkten is het terug belangrijk dat de door het parameterplatform gebruikte standaarden internationale standaarden zijn.

Algemene opmerking over deze blogpost: deze post ging voornamelijk uit van de arts als verwerker van de gezondheidszorgparameters. Evengoed zou een gelijkaardig verhaal geschreven kunnen worden voor de andere gezondheidszorgverstrekkers.

Daarnaast spreekt het voor zich dat bovenstaande enkel mogelijk is indien een oplossing wordt gevonden voor de diverse problemen die er nu zijn bij de invoering van telecare oplossingen (terugbetalingsmodel, juridische aansprakelijkheid,… ) en dat er bij de uitwerking van een oplossing rekening moet gehouden worden met de GDPR regelgeving.

______________________

Dit is een ingezonden bijdrage van Renzo Lylon, business consultant bij Smals Research.  Dit artikel werd geschreven in eigen naam en neemt geen standpunt in namens Smals.

Nieuwe bevoegdheden incorporeren heeft grote gevolgen op organisatorisch, juridisch en ICT-vlak. Het brengt grote uitdagingen met zich mee, maar hierop gaan we niet dieper in. Dit artikel gaat over nieuwe informatieproblemen die ontstaan als gevolg van de herschikking. Het is niet de bedoeling om hier een oplossingsvoorstel aan te reiken, wel enkele minimale eigenschappen.

1: Moet u als burger zelf achterhalen wie verantwoordelijk is voor welke bevoegdheid?

Als een bevoegdheid niet volledig is overgedragen, dan zijn zowel de G&G als het federale niveau verantwoordelijk voor onderdelen van het proces. Wie als huisarts wil werken, bijvoorbeeld, moet zijn diploma laten erkennen door de G&G, een visum bekomen bij de FOD Volksgezondheid en een RIZIV-nummer bij… het RIZIV.

Idealiter zijn zulke processen volledig transparant voor de burger en hoeft deze geen rekening te houden met alle achterliggende complexiteit. Voor dit specifieke geval wordt trouwens in het kader van het project Cobrha+ gewerkt aan een volledige procesondersteuning. Het afleveren van een verblijfs- en werkvergunning (Single Permit) is een ander voorbeeld van een proces waarbij zowel de G&G als het federale niveau betrokken zullen zijn.

Procesondersteuning is nog maar de eerste stap van een oplossing. De burger moet ook kunnen achterhalen wie op welk moment zijn dossier behandelt. Een online statusopvolging voor de burger zou dus een deel van de oplossing moeten zijn.

2: U verhuist naar een ander landsdeel?

Wanneer een burger of een onderneming verhuist naar een ander landsdeel, kan het gevolg zijn dat lopende procedures worden stopgezet in het ene landsdeel, en eventueel herstart in het andere. Het zal daarbij wenselijk zijn dat de ‘oude gegevens’ worden overgemaakt aan de nieuwe instantie die zal instaan voor de opvolging van het dossier, of dat ze consulteerbaar worden gesteld. Het is zeer wenselijk om daarbij de continuïteit en de meeneembaarheid van rechten te garanderen.

3: U woont in Brussel?

Als inwoner van Brussel beslist u bijvoorbeeld zelf of u aansluit bij de Vlaamse Sociale Bescherming. Indien er vergelijkbare beschermingsmechanismes op vrijwillige basis ontstaan bij de overige G&G, dan is het risico reëel dat sommige personen helemaal nergens aangesloten zullen zijn, en dus geen enkele bescherming genieten. Typisch zullen dit niet de sterkste personen binnen de samenleving zijn.

Omgekeerd bestaat het risico dat inwoners van Brussel aansluiten bij meerdere beschermingsmechanismes. De kans is dan reëel dat deze personen meerdere tegemoetkomingen zullen ontvangen.

Doordat het overnemen van een bevoegdheid nu al grote uitdagingen met zich meebrengt, kunnen de voorgaande drie problemen typisch nog niet meteen aangepakt worden. Dit betekent ook dat het dus nog niet te laat is om generieke oplossingen uit te werken. Hierbij is het belangrijk dat burgers en ondernemingen géén hogere administratieve lasten moeten dragen. En dat zoveel mogelijk gestreefd wordt naar een geïntegreerde dienstverlening over de verschillende bestuursniveaus heen.

Een generieke oplossing kan de totale beheerskosten beperken. Tegelijk biedt een generieke oplossing meer garanties op de meeneembaarheid van de opgebouwde rechten. Dit vraagt loyauteit van alle betrokken instellingen. En het kan nooit de bedoeling zijn dat een generieke oplossing de mogelijkheid tot het voeren van een eigen beleid door de diverse overheden ook maar enigszins beperkt.

Op weg naar een oplossing?

Een oplossing moet hoe dan ook beslist en afgestemd worden door de vertegenwoordigers van alle betrokken bestuursniveaus. Hun voorstel zal volledig rekening moeten houden met de bevoegdheden en verantwoordelijkheden die nu aan elk bestuursniveau zijn toegekend.

Beheersprincipes: Wie zal er toezien op het beheer van de informatie-uitwisseling? Wordt er gewerkt met een beheerscomité? Wie wordt daarin vertegenwoordigd en wie zit het voor? Wat zijn de taken? Denk aan het bepalen van wie toegang krijgt tot welke informatie. Wie bewaakt de evolutie van het uitwisselingsplatform? Wie staat in voor de operationele werking? Deze vragen moeten een antwoord krijgen, wil men komen tot een goed functionerend samenwerkingsmodel. Principes kunnen worden vastgelegd in een samenwerkingsakkoord tussen alle betrokken partijen. Het kan niet de bedoeling zijn om een wildgroei aan beheerscomités te laten ontstaan. Wil men onnodige kosten vermijden en de garantie op een uniforme dienstverlening bieden, dan dient hun aantal beperkt te worden – bijvoorbeeld één comité per sector.

Principes over dossierbeheer en opvolging: Hoe verloopt de identificatie van dossiers? Organisaties kunnen fusioneren, zodat de hoofdzetel opeens in een ander landsdeel kan liggen. Dit zal een invloed hebben op de identificatie van oude en nieuwe dossiers.

Wanneer en hoe worden de ketenpartners op de hoogte gebracht van een nieuw dossier? Welke informatie moet centraal bijgehouden en decentraal ontsloten worden? Bij zoveel vragen is het belangrijk dat er één keer een referentie-oplossing wordt uitgewerkt, waarbij deze oplossing voor elke nieuwe informatiestroom wordt hergebruikt.

Een referentie-oplossing moet alle scenario’s in overweging nemen. Het is bijvoorbeeld niet voldoende om de genomen beslissingen consulteerbaar te stellen, maar ook de feitelijke gegevens die aan de basis lagen van de genomen beslissing. Het uitwisselen van feitelijke gegevens vermijdt – volgens het only once-principe – dat burgers of ondernemingen bij een verhuis naar een ander landsdeel eerder verstrekte informatie opnieuw moeten doorgeven.

Om de gegevensstromen te organiseren lijkt een centraal verwijzingsrepertorium een noodzaak. Zo weten we welke overheidsinstantie informatie heeft over welke persoon of organisatie. Het zal ook een rol spelen bij het actualiseren van de gegevens. Via het repertorium kan worden nagegaan wie er een melding moet krijgen van nieuwe informatie. Daarnaast is een verwijzingsrepertorium van groot belang bij een vrijwillige aansluiting, om na te gaan of iedere burger op zijn minst ergens verzekerd is, en eventueel dubbel verzekerd is.

De status van een dossier lijkt een gegeven dat best centraal wordt bijgehouden. Dit zou het gemakkelijker maken om onmiddellijk een zicht te hebben op de actuele situatie. Waar kan de burger terecht met vragen? Zeker voor processen over meerdere organisaties, lijkt het aangewezen om te voorzien in één aanspreekpunt.

Technische principes : Wat is de referentie-architectuur voor het uitwisselingsplatform? Welke basisdiensten worden door het uitwisselingsplatform ter beschikking gesteld? Minimaal is dit een publicatie-, consultatie-, notificatie- en subscriptiefunctie (subscriptie: aangeven voor welke wijzigingen men een notificatie wenst te ontvangen). Welk technisch formaat krijgen de uit te wisselen berichten? Het lijkt aangewezen om te vertrekken vanuit bestaande systemen en standaarden, die met een minimale aanpassing kunnen worden hergebruikt.

Dit lijstje is slechts een eerste, erg onvolledige aanzet. Voorstellen formuleren, is een oefening die in samenwerking met alle betrokken bestuursniveaus hoort te gebeuren. Het is geen eenvoudige oefening, maar ze kan vermijden dat voor elk project afzonderlijk een oplossing wordt uitgewerkt. Telkens een nieuwe oplossing uitwerken kost niet alleen veel tijd en geld, maar heeft ook als risico dat er sterk van elkaar afwijkende gegevensstromen ontstaan die de complexiteit enkel doen toenemen.

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.

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?”

De eerste vraag die we ons moeten stellen is: wanneer biedt binnen de overheidssector business analyse een toegevoegde waarde ? Er blijken in de praktijk een drietal veel voorkomende situaties te zijn: domeinoptimalisatie, impactanalyse en procesoptimalisatie. Zoals zal blijken bij de bespreking van elk opdrachttype worden er enkel bij de procesoptimalisatie systematisch processchema’s uitgewerkt. Maar ook bij deze opdrachten vormt het uittekenen van processen slechts een beperkt deel van de uit te voeren taken.

Domeinoptimalisatie

Bij domeinoptimalisatie opdrachten heeft de business analist als taak om samen met alle betrokken partijen te zoeken naar scenario’s die de werking binnen een bepaald domein kunnen verbeteren. Concrete voorbeelden van dergelijke opdrachten zijn: “hoe kunnen de hulpdiensten sneller over informatie beschikken tijdens een incident?” of “hoe kan ICT ingezet worden om de eerstelijnsgezondheidszorg te optimaliseren?”

Bij dergelijke opdrachten dient de business analist bij alle betrokken partijen de behoeften en aandachtspunten na te gaan. Samen met hen wordt er dan gezocht naar een consensus die een oplossing biedt voor het gestelde probleem.

Typisch zijn deze opdrachten eerder high level opdrachten waarbij enkel de algemene principes worden vastgelegd. Bij dergelijke opdrachten heeft het dan ook geen zin om gedetailleerde processchema’s uit te werken. Een schema met enkel de grote componenten van het oplossingsvoorstel volstaat. Links ziet u een voorbeeld van een dergelijk schema.

Impactanalye

Een impactanalyse wordt voornamelijk uitgevoerd wanneer de gevolgen van een nieuwe wetgeving nagegaan moeten worden. Bij alle partijen die betrokken zijn bij de nieuwe wetgeving moet geverifieerd worden wat de gevolgen zijn van de nieuwe situatie. In een volgende fase dient dan bepaald te worden hoe de nieuwe wetgeving kan geïmplementeerd worden rekening houdend met de specifieke situatie van alle betrokkenen. Een dergelijke business analyse heeft tot doel een zo efficiënt mogelijke implementatie van de nieuwe wetgeving te bekomen.

Dergelijke opdrachten kunnen soms vereisen dat processen worden uitgetekend. Zij kunnen een hulpmiddel vormen bij het vastleggen van de verantwoordelijkheden van elke betrokken partij. Processchema’s zijn echter niet steeds noodzakelijk. Bij de meeste opdrachten volstaat terug een eenvoudig schema. Enkel wanneer een groot aantal partijen betrokken is, elk met specifieke verantwoordelijkheden, is het meestal aangewezen om processchema’s te gebruiken.

Procesoptimalisatie

Zoals de naam al doet uitschijnen staan bij deze opdrachten processen centraal. In eerste instantie dienen de huidige processen in kaart te worden gebracht (as is) en in een latere fase de toekomstige processen (to be). Dergelijke opdrachten vragen zo goed als altijd dat processen worden uitgetekend. Toch blijft het uittekenen van processen ook bij deze opdrachten maar een deel van het werk. Interviews dienen afgenomen te worden, workshops georganiseerd, rapporten geschreven, resultaten gecommuniceerd, …

Zoals blijkt uit de beschrijving van elk opdrachttype zijn processchema’s zeker een belangrijk hulpmiddel bij de uitvoering van bepaalde business analyses. Alleen zou het foutief zijn om business analyse te verengen tot enkel en alleen het uitwerken van processen. Business analyse is veel meer dan dat!

Afhankelijk van de specifieke situatie zal de ene functie zwaarder doorwegen dan de andere. Dit heeft tot gevolg dat verschillende softwaretypes gebruikt kunnen worden om een case management omgeving te realiseren. In deze blog wordt dieper ingegaan op de drie belangrijkste types software die gebruikt kunnen worden bij de realisatie van een case management omgeving.

Gezien de termen case management en dossierbeheer hetzelfde betekenen worden beide termen door elkaar gebruikt.

Documentmanagementsoftware

Binnen een administratieve omgeving zoals de overheid zijn zeer veel processen documentgestuurd. Een aanvraag wordt verstuurd naar de organisatie en op basis van de aanvraag wordt een dossier (= case) geopend. Vervolgens wordt de originele aanvraag, eventueel na inscanning, toegevoegd aan het dossier.

Bij de verdere behandeling van het dossier wordt de aanvraag geanalyseerd en een document met de beslissing wordt gecreëerd. Veelal dient er nog een verantwoordelijke zijn goedkeuring te geven voordat het document met de beslissing verstuurd kan worden.

Vaak zal het bij een dergelijk proces ook voorkomen dat andere diensten binnen de organisatie betrokken dienen te worden. Ze dienen geïnformeerd te worden over de aanvraag, dienen zelf ook een (deel)beslissing te nemen, … Dit alles resulteert in een aantal documenten of zelfs subdossiers die onderdeel vormen van het hoofdossier.

Binnen dit type van dossierbehandeling ligt de nadruk dus op het beheren van documentstromen. De stromen hoeven niet op voorhand volledig gedefinieerd te worden, maar de mogelijke stappen dienen wel ondersteund te worden.

Customer / Citizen Relationship Management (CRM)

Wanneer de behandeling van het dossier een sterke communicatie vraagt met diverse partijen dan kan het aanwezen zijn om een CRM pakket als basis voor het case management systeem te gebruiken. Traditioneel bestaat CRM uit drie grote subdomeinen: customer support, marketing en sales support. Binnen een overheidscontext zijn voor het beheren van dossiers vooral de customer support module relevant. Typisch zijn dit ook de modules die gebruikt worden binnen een contact center.

Op zich is het logisch dat de contact center modules gebruikt worden voor dossierbeheer gezien de functionaliteit die noodzakelijk is om een complexe vraag te beantwoorden veelal dezelfde is als de functionaliteit die nodig is om een dossier te behandelen. In beide situaties dienen diverse partijen informatie aan te leveren om de vraag / dossier tot een goed einde te brengen. In beide gevallen is er ook een verantwoordelijke die instaat voor het opvolgen van de taken en agenda die gerelateerd zijn aan de vraag / dossier, …

Veelal biedt een CRM platform de mogelijkheid aan derden om, mits deze over de nodige toegangsrechten beschikken, online dossierstukken te consulteren of toe te voegen.

Business Process Management Systems (BPMS)

Wanneer de dossierverwerking eerder gebaseerd is op formele processen of wanneer een aanzienlijk aantal processtappen bestaat uit het aanspreken van systemen dan kan een BPMS een goede basis vormen voor een case management systeem. Binnen formele processen kan een BPMS op basis van de beschikbare informatie vaak zelf beslissen wat de volgende stap zal zijn binnen een proces. De menselijke tussenkomst beperkt zich bij dergelijke processen vaak tot het uitvoeren van punctuele taken. Deze taken worden door het BPMS systeem toegekend aan personen.

Typisch beschikt een BPMS over uitgebreide mogelijkheden om een integratie op te zetten met externe systemen. De resultaten die ontvangen worden door de externe systemen worden opgenomen binnen het dossier en mee verstuurd naar de volgende stap binnen het proces.

Wat als de situatie niet zo eenduidig is?

Elk van besproken softwaretypes legt de focus op een bepaald type van dossierbehandeling. Dit type wordt dan telkens zeer goed ondersteund en meestal wordt er door het softwarepakket dan een basisondersteuning geleverd voor de overige types. Soms kan zich echter ook de situatie voordoen dat meerdere types zeer goed ondersteund dienen te worden. In deze gevallen kan het noodzakelijk zijn om twee of meer softwaresystemen met elkaar te integreren om tot een volwaardige case management oplossing te komen.

Bij een combinatie van systemen is het vooral belangrijk om duidelijk te bepalen waarvoor elk systeem gebruikt zal worden. Wordt dit niet eenduidig vastgelegd dan ontstaat het risico dat binnen de organisatie de afdelingen eigen werkprocedures gaan ontwikkelen. Wat natuurlijk zoveel mogelijk vermeden dient te worden wil men een consistente dossierbehandeling behouden.