- Inleiding
- Kaders
- Ontwikkelingen
- Thema's en Architectuurprincipes
- Tabel Principes en doelen
- Kaders en Architectuurprincipes in documentvorm
Bedrijfsprocessen
Inleiding
Een belangrijk, zo niet het belangrijkste onderdeel van de bedrijfsarchitectuur zijn de bedrijfsprocessen. In het metamodel van de bedrijfsarchitectuur staan ze dan ook helemaal centraal.
Hoe een ketenpartner zijn processen inricht of uitvoert, is de eigen verantwoordelijkheid van de ketenpartner. Voor de samenwerking in de keten is het wel essentiëel om:
- te weten welke bedrijfsprocessen er bestaan in de keten en wie deze uitvoert;
- een uniform begripskader te hebben van hoe we in de keten naar bedrijfsprocessen kijken;
- een gedeeld beeld te hebben van hoe processen kunnen samenhangen
Het eerste punt wordt uitgewerkt op de pagina met het processenlandschap. De uitwerking van de twee andere punten volgt hieronder.
Kaders voor Bedrijfsprocessen
Het in kaart brengen en modelleren van processen binnen een bepaald domein is altijd enigszins subjectief. Je kunt op verschillende manieren naar processen kijken. Hieronder introduceren we een conventie die het mogelijk maakt om het beschrijven van processen binnen de keten enigszins te uniformeren. Dit is een gangbare conventie die bijvoorbeeld ook binnen de GEMMA Procesarchitectuur en destijds (voor de scope-wijziging) binnen de NORA 2.0 wordt gebruikt.
Beschouwingsniveaus van processen
Processen kunnen op meerdere niveaus uitgewerkt en beschreven worden. Welk niveau gekozen wordt is afhankelijk van het gewenste inzicht dat de procesbeschrijving moet geven. Onderstaande figuur laat zien welke niveaus we binnen de procesarchitectuur onderscheiden.
We hanteren de volgende definities voor de niveaus[1]:
Niveau | Definitie | Voorbeeld |
---|---|---|
Bedrijfsproces | Een bedrijfsproces (ook wel genoemd klant-tot-klantproces) is een onder verantwoordelijkheid van één ketenpartner uitgevoerde, geordende reeks deelprocessen, gerelateerd aan een interne of externe klant en gericht op het leveren van een dienst aan die klant. | Het proces "Behandelen aanvraag verblijfsvergunning". |
Deelproces | Een deelproces is een onder verantwoordelijkheid van één bedrijfsfunctie uitgevoerde, geordende reeks processtappen, gericht op het leveren van een deeldienst die een noodzakelijke of gewenste bijdrage levert aan een uiteindelijk aan de klant te leveren dienst. | Het deelproces "Beslissen op een aanvraag". |
Processtap | Een processtap is een onder verantwoordelijkheid van één persoon (rol) handmatig of geautomatiseerd uitgevoerde, geordende reeks handelingen gericht op het bijdragen aan de levering van een deeldienst. | De processtap "Uitvoeren nader gehoor". |
Handeling | Kleinst mogelijke eenheid van werk, uitgevoerd door één persoon of machine op één plek op één moment. | De handeling "Vreemdeling opvoeren in de BVV". |
De MIRA bedrijfsarchitectuur is vooral het niveau van de bedrijfsprocessen belangrijk. Hieruit valt op te maken "wat" de ketenpartners doen. Er is op dit niveau een duidelijke relatie met de externe bedrijfsdiensten, dwz. de diensten die geleverd worden aan de externe klant. Bij ons in de Migratieketen is dit voor de primaire processen meestal de vreemdeling of de samenleving. Voor de secundaire of ondersteunende processen kunnen ook de andere ketenpartners de klant zijn.
De andere niveau's zijn voor de MIRA bedrijfsarchitectuur minder van belang. Hoe een ketenpartner zijn of haar processen inricht, is immers de verantwoordelijkheid van die ketenpartner. Wel kan het voor de samenhang nuttig zijn om enigszins op de hoogte te zijn van de deelprocessen van de andere ketenpartners. Dit niveau is echter in de MIRA Bedrijfsarchitectuur niet uitgewerkt.
Deze beschouwingsniveau's zijn bedoeld als hulpmiddel. De ervaring leert dat het fijn is om zo'n raamwerk te hebben omdat het structuur brengt, en de analist zich beter kan focussen op de inhoud en het optimaliseren van het proces. Het is echter geen wet van meden en perzen. Soms kan een extra niveau handig blijken te zijn. Soms om heel praktische redenen ('het papier is vol'), of omdat een iets fijnmaziger indeling beter aansluit bij hoe het proces in de praktijk bij een bepaalde ketenpartner wordt herkend. Probeer echter, wanneer er sprake is van afstemming met andere ketenpartners over het proces, wel zoveel als mogelijk deze structuur herkenbaar te houden, zodat de modellen in de keten ook onderling beter vergelijkbaar worden.
Definitie en afbakening van bedrijfsprocessen
Een bedrijfsproces is gedefinieerd als ‘’een geordende reeks van onder verantwoordelijkheid van één ketenpartner uitgevoerde deelprocessen, gericht op het leveren van een dienst aan een klant’’.
Vier elementen zijn essentieel in het definiëren en beschrijven van een bedrijfsproces:
- De externe gebeurtenis die aanleiding vormt tot het starten van het bedrijfsproces. Dit kan heel tastbaar zijn (zoals het ontvangen van een visumaanvraag), maar ook indirect (zoals het houden toezicht volgt op het onder voorwaarden toelaten van een vreemdeling).
- Het helder afgebakende resultaat dat voor de ‘klant’ betekenis heeft (waarde levert). Het resultaat kan door de klant gevraagd zijn (zoals een visum) of juist niet (een afwijzing). In geval van de migratieketen is de klant veelal de vreemdeling die naar Nederland komt, maar in een aantal processen zoals bij toezicht en bewaring is niet de vreemdeling de klant maar ‘de samenleving’.
- De organisatie (ketenpartner) die verantwoordelijk is voor uitvoering en resultaat van het proces. In principe is bij een bedrijfsproces altijd één ketenpartner verantwoordelijk.
- De procesgang in termen (en op het niveau) van deelprocessen. Er moet sprake zijn van een zekere vaste ordening van de activiteiten, anders is er geen proces.
Onderstaande figuur geeft dit schematisch weer:
Sturende, primaire en ondersteunende bedrijfsprocessen
Binnen de procesarchitectuur maken we onderscheid tussen sturende, primaire en ondersteunende bedrijfsprocessen.
- Primaire bedrijfsprocessen vormen de kernactiviteiten van de organisatie. Een primair bedrijfsproces heeft altijd een dienst aan een klant als resultaat. In de Migratieketen is dit meestal de vreemdeling of de samenleving.
- Ondersteunende bedrijfsprocessen leveren diensten aan interne klanten. Deze kunnen ofwel deel uitmaken van de uiteindelijk aan de klant te leveren dienst, ofwel ten behoeve van de bedrijfsvoering staan.
- Sturende bedrijfsprocessen zorgen voor continuïteit in de uitvoering van de primaire processen op korte (operationele sturing) en lange (strategische sturing) termijn. Klant is indirect de organisatie zelf.
Relatie Bedrijfsprocessen en andere onderdelen uit de Bedrijfsarchitectuur
Een bedrijfsproces heeft altijd één actor die verantwoordelijk is voor het uitvoeren ervan. Dat is de proceseigenaar. Het kan zo zijn dat twee of meer ketenpartners eenzelfde proces kúnnen uitvoeren (bijvoorbeeld een visum kort verblijf; dat kan afhankelijk van de omstandigheden bij IND, BZ, KMar en de Politie aangevraagd worden). Voor één instantie van het proces is echter altijd één van deze ketenpartners proceseigenaar. Dit sluit echter niet uit dan andere ketenpartners betrokken kunnen zijn in de uitvoering van dit proces, bijvoorbeeld door het leveren van een deeldienst die bijdraagt aan het resultaat van dit bedrijfsproces.
In enkele processen is er naast de klant (meestal de vreemdeling) en de ketenpartner/proceseigenaar nog een derde betrokken. Bijvoorbeeld bij de processen behandelen beroep en hoger beroep. Proceseigenaar hiervan zijn respectievelijk de Raad voor de Rechtspraak en de Raad van State. Maar de IND zal hier het verweer voeren. Dan zijn ze naast de klant een derde betrokkene in het proces, geen proceseigenaar. Ook geen onderaannemer van de Rvs of de RvdR.
Een bedrijfsproces heeft één of meerdere bedrijfsdiensten als resultaat. Er is dus een sterke relatie tussen de bedrijfsprocessen en de bedrijfsdiensten. Deze relatie hebben we in het onderliggende architectuurmodel van de MIRA bedrijfsarchitectuur dan ook gelegd.
Een bedrijfsdienstenmodel richt zich vooral op de buitenwereld in termen van wat aan klanten geleverd wordt. Een bedrijfsprocesmodel richt zich meer op hoe die diensten in de interne organisatie tot stand gebracht worden. Je zou het kunnen vergelijken met een externe versus interne blik op dienstverlening.
Naast de bedrijfsdiensten is er ook nog een belangrijke link met gebeurtenissen. Hierboven werd al geschreven dat een bedrijfsproces altijd start met een externe gebeurtenis. Andersom kunnen gebeurtenissen uit een bedrijfsproces ook het verloop van andere bedrijfsprocessen beïnvloeden, of andere bedrijfsprocessen starten. Zie hiervoor verder de pagina notificeren over gebeurtenissen.
Samenhang van bedrijfsprocessen in procesketens
In een keten staan bedrijfsprocessen niet op zichzelf maar hangen met elkaar samen. Binnen de procesarchitectuur spreken we liever van ‘procesketen’ (of nog juister: 'keten van bedrijfsprocessen') dan van ‘ketenproces’ omdat het laatstgenoemde suggereert dat de ketenpartners samen één bedrijfsproces uitvoeren en daarmee één dienst realiseren. Maar kenmerkend voor een bedrijfsproces is er één ketenpartner verantwoordelijk is en dat deze vrij is om het proces naar eigen inzicht in te richten. Al zijn in onze keten de meeste taken van de ketenpartners wettelijk vastgelegd en is er van vrije inrichting minder sprake.
Door uit te gaan van bedrijfsprocessen, met duidelijke aanleiding en goed gedefinieerd resultaat (een bedrijfsdienst), kan ook beter gestuurd worden op deze processen. Omdat het duidelijk is wie verantwoordelijk is voor de uitvoering, is het ook duidelijk wie verantwoordelijk is voor het sturen op de doorlooptijd en het optimaliseren van het proces. Op het beschouwingsniveau van een "procesketen" is dit allemaal minder duidelijk afgebakend. Iedere klant doorloopt namelijk altijd een eigen pad ('klantreis') doorheen de keten en komt in aanraking met andere processen op andere momenten. Zie hiervoor onderstaande figuur.
De vreemdeling in bovenstaande figuur (de onderlegger is het processenlandschap) informeert zich eerst over de mogelijkheden voor een verblijf in Nederland, vraagt vervolgens een verblijfsvergunning regulier aan; komt aan een grensdoorlaatpost het land binnen; wordt na verloop van tijd gecontroleerd en blijkt de voorwaarden niet na te leven; wordt in bewaring gesteld in afwachting van uitzetting; dient een WOO-verzoek in over enkele gegevens; dient een aanvraag tot verlenging verblijfsvergunning in; gaat in bezwaar tegen de afwijzing hierop; gaat in beroep tegen dit afgewezen bezwaar; krijgt gelijk en gaat uiteindelijk na enige tijd de naturalisatieprocedure in.
De vreemdeling is in dit fictieve voorbeeld in aanraking gekomen met maar liefst 10 bedrijfsprocessen in de keten. En in werkelijkheid komen er nog veel complexere gevallen voor, bijvoorbeeld asielzoekers met meerdere asielaanvragen, bezwaren en (hoger) beroepen tegelijkertijd. Deze processen lopen in werkelijkheid ook niet zo mooi sequentieel als het plaatje suggereert. Het is onmogelijk om in zo'n situatie goed te kunnen afbakenen wat de scope van een "ketenproces" zou zijn. Ook is er niemand die op het integrale verloop kan sturen.
Daarom gaan we in de bedrijfsarchitectuur uit van bedrijfsprocessen. Met heldere aanleiding en verantwoordelijke en duidelijk resultaat. De bedrijfsprocessen in de keten staan echter niet los van elkaar, Ze hangen samen. Dus naast het sturen op de bedrijfsprocessen, wat een verantwoordelijkheid van de ketenpartner zelf is, is er een gezamenlijke verantwoordelijkheid op het sturen op de samenhang hiertussen. Dit komt overeen met MIRA principe 2B: Het beheersen van de wederzijdse afhankelijkheid is een gezamenlijke plicht.
Samenhang tussen (bedrijfs)processen
In essentie zijn er vier manieren waarop bedrijfsprocessen kunnen samenhangen:
- Initiëren
Hierbij is sprake van een signaal van de ene ketenpartner aan de andere, waarna de ontvangende ketenpartner naar aanleiding van het signaal kan besluiten een proces op te starten of de loop ervan te wijzigen, zonder dat de afzender van het signaal daar verder bij betrokken is. Het proces van de afzender loopt gewoon door (of eindigt) zonder rekening te houden met de acties van de ontvanger. Beide processen zijn van elkaar ontkoppeld. Zie verder het hoofdstuk notificeren over gebeurtenissen. - Dienst afnemen
Hierbij is sprake van een voorgedefinieerde opdracht van de afnemer aan de leverancier van de dienst. De leverancier levert de dienst en bepaalt zelf hoe het proces om tot het te leveren product te komen verloopt. Van belang is dat opdracht en resultaat vooraf afgestemd en helder beschreven zijn, zodat de leverancier zijn proces kan optimaliseren (bijvoorbeeld door de dienst voor meerdere afnemers geschikt te maken). Zie verder het hoofdstuk over bedrijfsdiensten (interne diensten). - Samen werken
Hierbij is sprake van een gezamenlijk product dat door beide ketenpartners in samenwerking wordt gerealiseerd. Er is hierbij niet alleen sprake van samenwerken maar ook van samen werken. - Delegeren
Hierbij is sprake van een opdracht van de ene ketenpartner aan de andere, waarbij de opdrachtgevende ketenpartner eindverantwoordelijk blijft voor het resultaat en daarom ook bemoeienis zal willen hebben met de uitvoering.
De eerste twee patronen komen overeen met twee van de 4 samenwerkpatronen die we eerder hebben benoemd (notificeren en verzoeken om dienst). De andere 2 (samen werken en delegeren) zijn patronen waarbij er op niveau van deze bedrijfsarchitectuur geen afspraken gemaakt hoeven te worden.
In onderstaande tabel zijn de verschillen tussen de vier typen nader uitgewerkt:
Aspect | 1 (initiëren) | 2 (dienst afnemen) | 3 (samen werken) | 4 (delegeren) |
Verantwoordelijkheid en aansturing | A en B zijn verantwoordelijk voor hun eigen bedrijfsprocessen. | A is verantwoordelijk voor het bedrijfsproces; B voor het eigen bedrijfsproces achter de dienst. | A en B zijn gezamenlijk verantwoordelijk voor het deelproces waarin ze samenwerken. | A is verantwoordelijk voor alle activiteiten in het bedrijfsproces. |
Afhankelijkheid | A is niet afhankelijk van B; B is afhankelijk van een signaal vanuit A. | A is afhankelijk van B voor levering van de dienst. | A en B zijn van elkaar afhankelijk. | A is afhankelijk van B voor de uitvoering van het deelproces. |
Afspraken | Geen, of convenant met afspraken over signaleren van relevante gebeurtenissen. | SLA, met afspraken over doorlooptijd, statusinfo, aantallen, kwaliteit etc. | Convenant, met afspraken over inzet en beschikbaarheid, wijze van samenwerken, communicatie etc. | Contract, inhoudelijk vergelijkbaar met (2) |
Inzicht in procesinrichting en uitvoering | A en B hebben inzicht in (alleen) hun eigen bedrijfsproces. | A en B hebben inzicht in (alleen) hun eigen bedrijfsproces. | A en B hebben inzicht in (alleen) hun eigen bedrijfs-proces, en daarmee ook in het gezamenlijke deelproces. | A heeft inzicht in het gehele bedrijfsproces; B heeft alleen inzicht in het gedelegeerde deelproces. |
Samenwerking | Geen, of alleen delen van gebeurtenissen. | Weinig; A levert input aan B, B levert resultaat. Tussentijds wel delen statusinformatie. | Samenwerken fysiek of digitaal aan documenten e.d., samenwerkingsfunctie gewenst. | Vergelijkbaar met (2) |
Bij elke samenwerking in de Migratieketen is het van belang goed te typeren over welk soort samenhang dit gaat.
Referenties
- ↑ aangepast van Gemma Online
Deze pagina is voor het laatst bewerkt op 1 okt 2024 om 14:50.