Van referentiearchitectuur naar procesarchitectuur in 6 stappen
- Met NORA heeft de publieke sector een zeer bruikbare referentiearchitectuur
- Een voor de business herkenbare procesarchitectuur ontbreekt echter nogal eens
- Tips om een procesarchitectuur te ontwikkelen
- Lees ook: Overheidsorganisaties gebaat bij referentie-architecturen
Nederland is een van de weinige landen die haar publieke sector faciliteert met de NORA, een referentiearchitectuur met architectuurafspraken, bouwstenen en andere kaders. Het belang van werken onder architectuur wordt dan ook vaak wel erkend. Suzie Joku ziet dat het voor veel publieke organisaties lastig is om op basis van NORA-dochters als GEMMA of HORA te komen tot een herkenbare en bruikbare procesarchitectuur.
Een belangrijke oorzaak is dat verreweg de meeste BPM-teams zich voornamelijk bezighouden met het beschrijven en continu verbeteren van operationele processen. Procesarchitectuur krijgt dan geen prioriteit en het team ontwikkelt daarin geen expertise. Die expertise zit misschien wel in het architectenteam, maar veel architectenteams zijn technisch georiënteerd, waardoor de ontwikkeling van een voor de business begrijpelijke en herkenbare procesarchitectuur daar ook nauwelijks prioriteit krijgt.
Desondanks is een totaaloverzicht van je processen en inzicht in de samenhang cruciaal. Het geeft een beeld van de wijze waarop de organisatie haar processen heeft ingericht om haar doelen te behalen. Het totaaloverzicht vormt bovendien de basis voor het inrichten van procesgovernance, waarbij voor alle hoofdprocessen ook de strategische proceseigenaren geïdentificeerd kunnen worden. Ook de impact van grote en kleine (verander)projecten op de processen kan hiermee snel en eenvoudig inzichtelijk gemaakt worden. Daarnaast wordt ook duidelijk in hoeverre de processen op elkaar zijn afgestemd en de medewerkers daarin efficiënt met elkaar samenwerken.
Kapstok
Deze architectuur is daarmee niet een typische ICT-architectuur, maar meer een kapstok voor procesgericht werken sturen en verbeteren en voor het inrichten van procesgovernance, waarin veel gebruik wordt gemaakt van de elementen uit de typische ICT-architecturen. Het is een overzicht dat herkenbaar en bruikbaar moet zijn buiten ICT.
De BPM-Lifecycle (Dumas et al 2018 ) laat zien dat het ontwikkelen van de procesarchitectuur de eerste stap is bij het inrichten van procesmanagement. BPM-teams en architectenteams zouden daarom deze eerste stap gezamenlijk moeten uitvoeren.
BPM LifeCycle
Ook Davalla de Padua ziet procesarchitectuur als een belangrijke BPM-succesfactor (2014), zij benoemt vijf relevante aspecten bij het ontwikkelen van een procesarchitectuur:
1. Hiërarchie: processen kennen verschillende niveaus, vanaf de hoogover waardeketen, naar bedrijfs- en werkprocessen tot aan werkinstructies.
2. Samenhang tussen processen: processen zijn geen losstaande entiteiten, maar ontvangen elkaars output en leveren elkaar input en hebben zo effect op elkaar.
3. Samenhang tussen processen en strategie: de strategie formuleert de WAT, processen maken de HOE concreet.
4. Samenhang tussen processen en middelen: denk daarbij aan mensen, beleid, maar ook aan informatie en applicaties.
5. Meet- en verbetermechanisme: door procesprestaties te meten kunnen processen continu verbeterd worden.
Figuur 1 BPM Lifecycle
De onderstaande aanpak is gebaseerd op ervaringen bij verschillende hogescholen en gemeenten. Door samen een procesarchitectuur te ontwikkelen krijgen de architecten een procesarchitectuurplaat waarmee zij met de business kunnen communiceren en het BPM-team krijgt inzicht in elementen uit andere architecturen die voorkomen in de processen.
Stap 1: stel een multidisciplinair team samen
Input
Wens om procesarchitectuur te ontwikkelen
Omschrijving
In feite maakt het niet uit wie het initiatief neemt. Het team dat een procesarchitectuur gaat ontwikkelen, dient in elk geval te bestaan uit minimaal een procesadviseur en een architect. Het team kan aangevuld worden met medewerkers voor wie integraliteit onderdeel is van hun werk. Denk aan business analisten, verandermanagers, kwaliteitsmanagers, riskmanagers en business controllers, maar ook collega’s uit de primaire processen. Maak het team niet te groot, maximaal 7 á 8 mensen.
Output
Multidisciplinair team
Stap 2: maak een werklijst van procesbeschrijvingen
Input
Wens om procesarchitectuur te ontwikkelen
Omschrijving
Het team verzamelt procesbeschrijvingen uit de organisatie. Bronnen kunnen tools zijn waarin al dan niet actuele processen zijn benoemd of beschreven, maar het kunnen losse procesbeschrijvingen zijn, die medewerkers hebben opgesteld.
Loop met het team de lijsten na. Filter er alles uit wat geen proces is, zoals gedetailleerde werkprocessen, werkinstructies of andersoortige teksten zodat je een lijst overhoudt van processen die op hetzelfde abstractieniveau zijn en over afdelingen heen lopen.
Let wel, processen die wel uitgevoerd worden, maar waarvan de gedetailleerde uitwerking niet meer actueel is, worden ook op de werklijst gezet.
Dit vraagt twee of drie intensieve workshops, maar de kennis over elkaar processen en de aansluiting op elkaars processen in het team wordt enorm versterkt.
Output
Werklijst van actuele processen uit de organisatie
Versterkte interne proceskennis
Stap 3: Check of de processen de bedrijfsfuncties dekken
Input
Bedrijfsfunctiemodel en werklijst
Omschrijving
Bestudeer het bedrijfsfunctiemodel dat relevant is voor je organisatie, GEMMA, HORA of een andere.
Ga met het team aan de slag en check in hoeverre de processen van de werklijst alle bedrijfsfuncties afdekken.
Zijn er bedrijfsfuncties die niet ingevuld zijn door een proces, dan kan het BPM-team dat proces of die processen als daar behoefte aan is, op hun agenda zetten en later uitwerken.
Zijn er processen die geen bedrijfsfunctie invullen, beslis dan met het team of die wel of niet op de werklijst opgenomen dienen te worden.
Output
Aangepaste werklijst
Actielijst van processen die later uitgewerkt zullen worden en buiten de scope van dit project vallen
Stap 4: Categoriseer je bedrijfsprocessen per type
Input
Aangepaste werklijst
Omschrijving
In deze stap worden de processen vertaald naar de PlanDoCheckAct-cyclus.
De PDCA-cyclus is van belang omdat alle processen daarin een plek krijgen; de samenhang tussen processen om continu kwaliteit te verbeteren wordt zo helder. Deze aanduiding echter, zegt niets over het procestype. Formuleer daarom aanvullend procestypen die de PDCA-cyclus concreet maken, bijvoorbeeld:
- Strategische processen: processen waarvan de output langetermijn-beleid is en input is voor de tactische processen. (Plan)
- Tactische processen: processen waarin het langetermijn-beleid en ontwikkelingen uit de organisatie wordt verwerkt naar kortetermijn-beleid. Dit kortetermijn-beleid vormt kaders voor de overige processen. (Plan)
- Primaire processen: processen waaraan de organisatie haar bestaansrecht ontleent. (Do)
- Ondersteunende processen: processen die andere processen ondersteunen (Do)
- Meetprocessen: processen die de kwaliteit van andere processen meten (Check)
- Veranderprocessen: processen die andere processen veranderen (Act)
Deze combinatie van PCDA-cyclus en procestypen helpt om een indeling te maken waarin alle processen een logische en herkenbare plek krijgen.
Ga met het hele team van elk proces na bij welk procestype het proces hoort.
Output
Eerste versie van procesarchitectuur
Inzicht in de mate waarin de organisatie haar processen ingericht heeft om de kwaliteitscyclus uit te voeren.
Stap 5: Vul aan
Input
Eerste versie van procesarchitectuur
Omschrijving
Vul benoemde processen aan met proceskenmerken als procesdoel, kpi’s, beleidskaders, input, output, ondersteunende tooling, leverende en ontvangende processen en onderliggende deelprocessen.
Output
Tweede versie procesarchitectuur
Stap 6: Valideer
Input
Tweede versie procesarchitectuur
Omschrijving
Ga in gesprek met belangrijke stakeholders om de herkenbaarheid en bruikbaarheid te toetsen:
- Ga na of proceseigenaren en andere stakeholders hun proces in de PDCA-cyclus herkennen;
- Toets met risicomanager en risico-eigenaren of de procesarchitectuur bij het identificeren van risico’s voldoende inzicht geeft in de organisatiebrede impact van het probleem en van de maatregelen;
- Bepaal met business analisten en projectmanagers bij de start van veranderprojecten welke processen geraakt worden door het project;
- Onderzoek met lijnmanagers in hoeverre processen geharmoniseerd moeten worden om organisatiedoelen te behalen;
- Etc.
Output
Gevalideerde procesarchitectuur
Tot slot
Maak goede beheerafspraken die aansluiten bij zowel het beheer van architectuurmodellen als bij die van procesmodellen.
Referenties:
Fundamentals of Business Process Management, Dumas, La Rosa, Mendling, Reijers (2018)
Process Architecture as a BPM critical successs factor: a bibliographic review – Dallavalle de Padua (2014)
Reacties
Om een reactie achter te laten is een account vereist.
Inloggen Word abonneeMooie beschrijving. In een procesmodel zullen strategische, tactische en operationele processen herkenbaar en gerelateerd aanwezig moeten zijn.
Wat ik in dit schrijven wel mis is de toetsing van de waarde van de procesarchitectuur en de processen t.o.v. het ondersteunen van het realiseren van de organisatiedoelen. En met name mis ik daarin de toetsing op toepasbaarheid en de betrokkenheid van de mensen die de procesactiviteiten uitvoeren. Het gegeven dat bijvoorbeeld in de IT processen onbekend, onbemind en veel genegeerd worden komt grotendeels voort uit de nadruk op volledigheid en control, en niet op het faciliteren van de uitvoerenden.
Vaak zie ik dat bij het beschrijven van processen de operationele ervaring amper wordt ingezet. Processen zijn dan ook vaker gericht op besturing dan op realisatie van de bedrijsdoelen en toepasbaarheid door de professionals.
De kwaliteit en waarde van de architectuur en de processen wordt m.i. vooral bepaald door de mate waarin ze bijdragen aan de bedrijfsdoelen.
Dank voor je reactie, Wim!
De kwaliteit en waarde van architectuur en processen wordt imho ook sterk bepaald door de mate waarin mensen voelen dat ze een zinvolle bijdrage leveren aan de bedrijfsdoelen.
De beschrijving in het artikel is gericht op één onderdeel van het inrichten van procesmanagement, de eerste stap die je gezamenlijk maakt. Uiteindelijk ga je met dit model de organisatie in en dus moet er ook een herkenbare gelaagdheid in zitten.
De hoofdprocessen op dit niveau beschrijf je op hoofdlijnen, waarbij je met strategische proceseigenaren per hoofdproces niet zozeer heel smart procesdoelen formuleert, maar je met name richt op De Bedoeling.
De onderliggende deelprocessen zijn dan ingekaderd vanuit De Bedoeling en van daaruit kun je die gaan uitwerken met de mensen die die processen in de dagelijkse operatie daadwerkelijk uitvoeren en smart procesdoelen en kpi's formuleren.
Ik ben het met je eens dat deze operationele ervaring vaak wordt overgeslagen. Echt een gemiste kans. Zelf ben ik van mening dat je processen nooit vanachter je bureau beschrijft en toetst, maar altijd in workshops met relevante actoren uit het proces. Dat geeft focus, energie en zoveel inzichten over de grenzen van afdelingen heen. Juist dan ontstaan waardevolle gesprekken over waarvoor we het met elkaar doen en hoe je het beste kunt faciliteren.