De midoffice ontrafeld

De term ‘midoffice’ speelt een belangrijke rol in de discussie over de modernisering van de gemeentelijke dienstverlening. De midoffice koppelt klantcontacten op slimme wijze met de verschillende gemeentelijke organisatieonderdelen. Maar hoe doe je dat precies, en welke mogelijkheden zijn er allemaal? Een analyse van het fenomeen midoffice verschaft helderheid.

Volgens goede traditie gaan we eerst op zoek naar een breed geaccepteerde definitie van de term ‘midoffice’. Wat blijkt: De term is niet te vinden in Van Dale’s woordenboek van de Nederlandse taal, niet in de Encyclopedia Brittanica en ook niet in Wikipedia. Als laatste redmiddel: Google. Resultaat: nauwelijks hits. De meeste hits verwijzen naar de promotie van de term binnen het Nederlandse gemeentelijke domein. Ondanks het Engels, wijst alles erop dat de term een Nederlandse uitvinding is. Die eer lijkt toe te komen aan Wouter Keller, waarna het programma Elektronische Gemeenten (EGEM), dat binnen ICTU wordt uitgevoerd, het begrip heeft geadopteerd. Zie bijvoorbeeld het artikel van Adrie Spruit, programma-architect van EGEM, in ‘Informatie’ van december jongstleden (Spruit, 2007).

In dit artikel zullen we ons dan ook richten op de betekenis die in deze gemeentelijke context veelal wordt gegeven aan het begrip midoffice. Roovers, Kuiper en Keller (2007) geven daarvoor de volgende definitie: “Een dun midoffice is dan ook vooral een technische voorziening die door middel van elektronisch berichtenverkeer uitwisseling van gegevens tussen frontoffice- en backofficesystemen faciliteert.” Later heeft Keller het begrip omschreven als “slechts een onderdeel van een hele suite van applicaties voor elektronische dienstverlening” (Keller, 2007).

Deze midoffice lijkt vooral in het leven geroepen te zijn om de weinig wendbare, verkokerde backoffice-afdelingen en -systemen van gemeenten te kunnen koppelen aan een moderne, geïntegreerde frontoffice waarin de burger centraal staat, zonder dat aan de ‘achterkant’ moeilijke organisatorische en technische veranderingen nodig zijn. Zoals in de architectuurnotitie van de EGEM Werkgroep Midoffice (2006, p.7) wordt beschreven: “Zodra de overheid aan de slag gaat met de herinrichting van haar frontoffice ontstaat al gauw zicht op het probleem om dit nieuwe frontoffice afgestemd te krijgen op de bestaande backoffices.

Dit probleem is als volgt inzichtelijk te maken:
1. De frontoffice wordt heringericht volgens een werkwijze, die zo goed mogelijk aansluit bij de belevingswereld van de klant;
2. De backoffice is nog steeds georganiseerd rondom de vakkennis van de bestaande reeks diensten, zoals Burgerzaken, Sociale Zaken enz. Er ontstaat hierdoor een afstemmingsprobleem tussen de ene wereld en de andere.”

De gemeentelijke bedrijfsarchitectuur
Het begrip midoffice is bedoeld om bij te dragen aan een heldere bedrijfsarchitectuur van een gemeente. Onder bedrijfsarchitectuur verstaan we de gehele inrichting van een bedrijf of overheidsorganisatie: producten, diensten, organisatie, besturing, processen, applicaties en IT-infrastructuur. Om het begrip midoffice een plaats te kunnen geven, gaan we daarom nu eerst in op de gemeentelijke bedrijfsarchitectuur.

De basis van een samenhangende bedrijfsarchitectuur berust op een heldere analyse van de bedrijfsfuncties. De doelen van een organisatie kunnen worden vertaald in meerdere bedrijfsfuncties. Bijvoorbeeld: Een fietsenfabriek kent onder meer de volgende bedrijfsfuncties: Marketing, verkoop, inkoop, productie, logistiek, aangevuld met ondersteunende functies als financiën, personeel en faciliteiten. Het geheel wordt vanuit directie en managers bestuurd. Michael Porter heeft ons geleerd op een dergelijke wijze naar bedrijven te kijken.

Als we naar een Nederlandse overheidsorganisatie kijken, gaan we uit van de Nederlandse Overheid Referentie Architectuur (NORA). Daarin is een abstract en daardoor algemeen toepasbaar model te vinden van een overheidsorganisatie:

Figuur 1 Architectuur van één overheidsorganisatie (bron: NORA)

In dit model zijn drie bedrijfsfuncties te zien: de klantcontactfunctie, de (verzameling van) besturende, primaire en secundaire functies en de data-opslagfunctie. Toegespitst op een gemeente, kunnen we deze hoofdindeling verder verfijnen. In de onderstaande figuren wordt dit in drie stappen gedaan.

Figuur 2 Stap 1: Onderverdeling bedrijfsfuncties in besturing, productie en ondersteuning

Het College van Burgemeester en Wethouders wordt beschouwd als een ‘interne’ klant van het ambtelijk apparaat. Ambtenaren van andere overheidsorganen kunnen uiteraard ook gebruik maken van de diverse dienstverleningskanalen die de gemeente gebruikt, maar zij krijgen, zoals we nog zullen zien, ook een meer rechtstreekse ingang naar de gemeente. In de volgende stap vindt een nadere verdieping plaats van de getoonde functies.

Figuur 3 Stap 2: Nadere detaillering van gemeentelijke bedrijfsfuncties

Figuur 3 toont een aantal bedrijfsfuncties van een gemeente. Ook zichtbaar is de functie ‘klant/zaakmanagement’. Deze functie zorgt voor het coördineren van de dienstverlening over de diverse media (‘kanalen’) heen en zorgt tevens voor de verbinding met de vele functies die kunnen worden aangesproken bij het verlenen van de gevraagde diensten. In de praktijk wordt deze functie meer en meer ingevuld door een directeur dienstverlening. Ook de geleidelijke overgang van documentsturing naar zaaksturing wordt mogelijk door deze bedrijfsbrede functie. Overigens is deze ontwikkeling niet nieuw of specifiek voor de overheid; veel dienstverlenende bedrijven in de particuliere sector hanteren dit model. In figuur 4 is te zien dat de getoonde bedrijfsfuncties nog verder gedetailleerd kunnen worden. Voor enkele functies is dit in de figuur zichtbaar gemaakt.

Figuur 4 Stap 3: Decompositie van enkele hoofdfuncties

Processen
Wanneer een klant zich via één van de kanalen meldt, is dit de start van een dienstverleningsproces. De klant/zaakmanagementfunctie maakt een zaak aan. Laten we zeggen de zaak ‘woonvergunning’. Essentiële zaakgegevens worden vastgelegd in een database, het zaakregister. Ook zou in het managementinformatiesysteem vastgelegd kunnen worden dat er een nieuwe zaak gestart is. De klant/zaakfunctie doet vervolgens een beroep op de functie ‘wonen en milieu’ om de zaak in behandeling te nemen. Deze functie doet op zijn beurt een beroep op de data-opslagfunctie. Als de nodige werkzaamheden (processtappen) door de functie ‘wonen en milieu’ zijn afgerond, wordt de zaak teruggelegd bij de klant/zaakmanagementfunctie. Deze doet vervolgens een beroep op de financiële functie, waardoor een leges-factuur aan de vergunning wordt toegevoegd. Ten slotte stuurt de klant/zaakmanagementfunctie het resultaat door naar de scan/printkamer, de voormalige postkamer, zodat de benodigde documenten kunnen worden geprint en verzonden naar de aanvrager.

De klant/zaakmanagementfunctie meldt het MIS dat de zaak is afgerond. Aan het eind van een periode kan vanuit het MIS een rapport samengesteld worden dat een overzicht biedt van het aantal afgehandelde zaken en de gemiddelde doorlooptijd ervan. Kortom: Door bedrijfsfuncties via de behandeling van aan zaak aaneen te rijgen, wordt het bedrijfsproces, van klant-tot-klant, zichtbaar.

Gegevens en services
Er is een tijd geweest dat we al tevreden waren als de gegevens tussen verschillende organisatieonderdelen en databases goed konden worden uitgewisseld. Architecturen werden vooral vanuit die gegevens en hun stromen opgezet, en de term ‘informatiearchitectuur’ was dan ook overkoepelend voor het vakgebied. Applicaties van verschillende afdelingen werden op database-niveau met elkaar uitgewisseld met behulp van message brokers.

Deze gegevensgerichte insteek miskende echter dat die gegevens feitelijk niet meer zijn dan een productiefactor. De structuur van de eigenlijke werkzaamheden werd vaak verwaarloosd. In het bijzonder zag men over het hoofd dat het uiteindelijk draait om de resultaten die voor de klant geboekt worden. Dit leidde begin jaren negentig tot de golf van het procesdenken, onder benamingen als business process redesign of business process engineering. Hierin staan bedrijfsprocessen centraal: een serie activiteiten die start bij een klantvraag en eindigt met een resultaat voor die klant. Optimalisatie van die bedrijfsprocessen, bijvoorbeeld om doorlooptijden terug te dringen en foutkansen te verkleinen, leidde tot een sterke verbetering in de dienstverlening van veel bedrijven en gemeenten.

Toch bleven er ook hier nog een aantal problemen. Als we voor elk product of elke dienst van een organisatie vooraf een aparte werkstroom definiëren, zien we niet dat er binnen die processen allerlei onderdelen gemeenschappelijk zijn. Dat geldt in het bijzonder voor allerlei deels of geheel geautomatiseerde functies zoals het ophalen van klantgegevens, het aanmaken van brieven, et cetera. Met andere woorden: er werd nog niet voldoende gebruik gemaakt van een indeling op basis van multi-inzetbare bedrijfsfuncties. Deze komen in beeld wanneer wordt uitgegaan van een service-georiënteerde architectuur of SOA.

Eén van de essenties: laat elke bedrijfsfunctie (of elke organisatie) doen waar deze goed in is en rijg verschillende functies aaneen tot een proces waarmee de klanten optimaal kunnen worden bediend. Die functies worden aangeboden in de vorm van services, zelfstandige eenheden die met standaard-protocollen kunnen worden aangeroepen. Omdat die services niet van elkaar afhankelijk zijn, kunnnen zij op allerlei manieren met elkaar gecombineerd worden om aan de vraag van de klant te voldoen. Zo kunnen tientallen tot honderden verschillende processen worden samengesteld. De onderstaande afbeelding geeft een voorbeeld binnen het gemeentelijk domein.

Figuur 5 Proces Vergunningverlening

Te zien is hoe een aantal bedrijfsfuncties, zowel besturende, als primaire en secundaire worden gebruikt om een vergunning te leveren aan het bedrijf. Het Business Proces Management Systeem zorgt voor de orkestratie van allerlei services. Specifieke informatie over de lopende aanvraag, wordt bijgehouden in het zakenregister.

Business Process Management
In het getoonde voorbeeld is te zien dat de BPM-functie van groot belang is. Deze opvolger van de vroegere ‘bedrijfsleider’ zorgt ervoor dat bij een order de juiste bedrijfsfuncties worden aangesproken en dat zij allen de afgesproken deel-diensten (lees: services) leveren. Door een juiste assemblage van services kan de order definitief worden afgewerkt: het bedrijf krijgt de gevraagde vergunning en een factuur om leges te betalen.

De afhandeling van de getoonde services verloopt uiteraard via het bedrijfsnetwerk. In meer complexe organisaties kan dit netwerk voorzien worden van een extra applicatie, die enkele veelgevraagde functies centraal aanbiedt. Een dergelijke applicatie heet Enterprise Service Bus. De belangrijkste functies zijn: routering van services, een ‘postkantoorfunctie’ (store and forward), een transformatiefunctie en beveiligingsfuncties. Inmiddels zien we tal van suites op de markt waarin een ESB en BPM worden gecombineerd. Het gaat om leveranciers als IBM, Oracle (incl. BEA), Microsoft, JBoss, Cordys, Sun en vele anderen. Een ESB kan gezien worden als de centrale verkeersdienst bij de aanroep en beantwoording van services via het bedrijfsnetwerk.

Overheidorganisaties leken in het papieren tijdperk te draaien om het afhandelen van documenten: formulieren, brieven, rapporten, vergunningen stonden centraal. Zo zeer centraal dat de besturing van de dagelijkse operatie op de beheersing van deze documenten werd gericht. Kortom: het te besturen object was het document. De bijbehorende systemen: documentmanagementsystemen, later tevens voorzien van vormen van workflow.

Binnen de moderne overheid staat het afhandelen van het verzoek van de klant centraal: de zaak. En dus gaan we over op zaaksturing. En natuurlijk horen bij een zaak de nodige (elektronische) documenten en data, die in verschillende databases zijn vastgelegd. Vanwege de keuze om voortaan zaakgericht te sturen, moet er ook wat zaakinformatie worden vastgehouden. Dit geschiedt vanuit de BPM-applicatie. En dus verschijnt op het niveau van de data-opslag ook een zakenregister, naast het personen-register, het bedrijvenregister, het percelen-register, het adressenregister, etc.

Het besturen van documenten kan dus geleidelijk aan vervangen worden door het besturen van zaken. Wat we overhouden aan de documenten-zijde is een register van documenten, voorzien van ontsluitingskenmerken. Leidend wordt de BPM-applicatie en daar waar sprake is van volumineuze en routinematige zaken kan workflow helpen de processtappen die ambtenaren zetten te ondersteunen en in goede banen te leiden.

In een op SOA gebaseerde gemeentelijke architectuur zou een applicatielandschap er als onderstaand kunnen uit zien:

Figuur 6 Applicatielandschap van een SOA-gemeente

De figuur maakt duidelijk dat alle applicaties waarmee klantcontacten worden onderhouden, een servicerelatie kennen met het BPM-systeem. Zoals we gezien hebben zorgt het BPM-systeem voor de georkestreerde afhandeling van verschillende werkprocessen. De pijlen tussen de applicaties symboliseren de services die worden aangeroepen en beantwoord. Services maken gebruik van berichten, die via het bedrijfsnetwerk worden uitgewisseld, mogelijk met ondersteuning van een enterprise service bus.

De figuur laat ook zien dat andere overheidsorganen vooral via services samenwerken met de getoonde gemeente. Deze services komen via een ‘gateway-server’ binnen bij de gemeente. Deze gateway-server stuurt de ontvangen berichten door naar het BPM-systeem en omgekeerd: serviceverzoeken van de gemeente worden door het BPM-systeem via de gateway verzonden naar andere overheidsorganen.

De aangegeven materiesystemen in de figuur, vaak te denigrerend aangeduid met ‘legacy’, kunnen uitgebreid worden met moderne services Dit maakt ruimte voor een minder silo-gerichte en flexibeler inzet van applicaties, zonder deze allemaal te moeten vervangen.

De dikke en de dunne
De laatste jaren worden de bovenstaande functionaliteiten in de Nederlandse overheidsmarkt vaak gebundeld verkocht onder het al genoemde label ‘midoffice’. Deze term werd oorspronkelijk gebruikt voor een organisatorische oplossing om de kloof tussen klantgerichte frontoffice-afdelingen en de inhoudelijke backoffice-afdelingen te overbruggen, in het bijzonder in de financiële sector, maar ook in de gemeentewereld: “Binnen het gedachtegoed van OL2000 ontstond het besef van een midoffice. Een specifiek organisatie onderdeel, dat zorg moet dragen voor het afstemmen van de frontoffice op de backoffice.” (EGEM Werkgroep Midoffice, 2006, p.7).

Wanneer we die midoffice als ‘product’ in technische zin beschouwen, zien we dat dit eigenlijk geen product is, maar een architectuurpatroon. Verschillende, in beginsel onafhankelijke functionaliteiten worden gecombineerd om de typische integratieproblemen van bijvoorbeeld gemeenten aan te pakken.

De zogenaamde ‘dunne midoffice’ is in feite een combinatie van een BPM-systeem, een zakenregister en een ESB. Omdat veel bestaande applicaties nog geen services kunnen leveren en omdat deze ook niet altijd 7×24 uur beschikbaar zijn, wordt in de midoffice-benadering het applicatielandschap aangevuld met een ‘gegevensmagazijn’ of Operational Data Store (ODS). Dit dient een tijdelijke oplossing te zijn: zodra de bestaande applicaties via gestandaardiseerde services en gegevens en ruime beschikbaarheidstijden te benaderen zijn, is een ODS niet meer noodzakelijk.

In een ODS worden gegevens redundant opgeslagen, met alle problematiek van dien rond consistentie en actualiteit. De syntactische en semantische harmonisatie van gegevens vindt daardoor niet plaats bij de bron, waar het zou behoren te gebeuren. Andere gebruikers van diezelfde gegevens, die deze niet via het ODS benaderen (bijvoorbeeld andere materie-systemen), hebben hier dus geen baat bij. Daarmee werkt het de modularisering en flexibilisering van de backoffice (zowel systemen als organisatie!) tegen. Daarmee geeft een ODS de organisatie een excuus om de noodzakelijke modernisering van bestaande systemen uit te stellen. Een veel betere oplossing, in ieder geval op termijn, is het migreren naar een architectuur met interne basisregistraties voor de diverse gegevenssoorten, waarvan alle andere applicaties gebruik maken.

Big bang
De ‘dikke midoffice’ is de dunne, aangevuld met Customer Relationship Management (CRM), een Document Management System (DMS) om in- en uitgaande post, email en dergelijke in te registreren, en een Workflow Management Systeem (WFM) voor de besturing van handmatige processen: een totaal-bouwdoos met zo’n beetje de belangrijkste componenten van een moderne SOA. Hierbij moet echter niet vergeten worden dat de onderdelen van de dikke en de dunne midoffice ook heel goed afzonderlijk aangeschaft en geïmplementeerd kunnen worden. Een big bang scenario voor het invoeren van een dikke midoffice kan dan worden vermeden. Veel gemeenten, maar ook provincies, waterschappen en uitvoeringsorganisaties volgen dan ook een dergelijke, geleidelijke, stap-voor-stap strategie. Zij hebben het concept van de dunne en de dikke midoffice niet nodig gehad. Zij hebben deze termen ontrafeld in de afzonderlijke componenten en deze stuk voor stuk geleidelijk ingevoerd.

Het concept van de dikke midoffice omvat een groot aantal belangrijke generieke applicaties voor een moderne SOA. Wouter Keller stelde: “De toekomst is dus aan het dikke midoffice (ofwel het KCC-systeem), waarbij de afdelingen (en applicaties) van de backoffice allemaal geheel overbodig zijn geworden” (Keller, 2007). In dezelfde column benoemde hij ook zaken als webintake en ondersteuning van KCC-medewerkers, dus typische de frontoffice-functionaliteiten, als onderdeel van de dikke midoffice. Daarmee omvat de dikke midoffice dus zowel de front- als de backofficefunctionaliteit, en de coördinatie daartussen, met andere woorden de complete dienstverleningsarchitectuur (een term die Keller ook hanteert). Als het eenmaal zo ver is, is het dan ook niet langer nodig om te werken met het begrip midoffice. Met andere woorden: het midoffice-begrip zal in de wereld van de Nederlandse gemeenten over enige tijd vanzelf weer verdwijnen. We gaan spreken over een transparante architectuur van gemeenten, die bestaat uit een logische samenhang van de in dit artikel genoemde componenten. De door EGEM aangekondigde ontwikkeling van de Gemeentelijke Model Architectuur (GEMMA) zal waarschijnlijk een belangrijke stap in die richting zijn.

Referenties

EGEM werkgroep Midoffice, Architectuur Model Gemeentelijke E-Dienstverlening: Project Referentiemodel Midoffice ten behoeve van Gemeenten . ICTU programma EGEM, 2006.
W. Keller, Dikke midoffice maakt backoffice overbodig. Proces & Document, nummer 2, juni 2007. Sdu Uitgevers.
M. Roovers, F.J. Kuiper en W.J. Keller, Het Midoffice: Elektronische dienstverlening tussen frontoffice en backoffice. Sdu Uitgevers, 2007.
A. Spruit, De gemeentelijke midoffice en het KlantContactCentrum, Informatie, december 2007.

Over de auteurs

Drs G.I.H.M. Bayens MBA is Principal bij Novius Business & Information Management. Hij wordt beschouwd als de grondlegger van de Nederlandse Overheid Referentie Architectuur. Verder is hij betrokken bij de ontwikkeling van afgeleide architecturen, zoals de Model Architectuur Rijksdienst (MARIJ) en referentie-architecturen voor Overijssel en Flevoland. Voor zijn bijdragen aan de architectuur-ontwikkeling binnen en buiten de overheid werd hij in 2007 onderscheiden met de Legpenning van het Nederlands Architectuur Forum.

Dr Ir M. Lankhorst is verbonden aan het Telematica Instituut als senior wetenschappelijk onderzoeker en manager van de expertisegroep Service Architectures. Zijn expertise betreft enterprise- en ICT-architectuur, softwareontwikkeling en bedrijfsprocesontwerp, in het bijzonder in de context van de elektronische overheid. Als projectmanager is hij verantwoordelijk geweest voor verschillende grote multi-party onderzoeksprojecten, waaronder het ArchiMate-project, over modellering, visualisatie en analyse van enterprise-architecturen. Op dit moment geeft hij leiding aan B-dossier (http://b-dossier.telin.nl), een project rond geïntegreerde, vraaggestuurde elektronische dienstverlening, waarin verschillende overheidspartijen en kennisinstellingen deelnemen.