GEMMA Basisprocessen
Inhoud
Let op: deze pagina is gearchiveerd
In de GEMMA Procesarchitectuur wordt een hiërarchie beschreven van de processen. Daarin wordt de samenstelling van processen in 4 lagen ingedeeld. Het gebruik van deze indeling maakt het mogelijk om processen onderling tussen organisaties te vergelijken of om bijvoorbeeld organisaties in te richten.
Introductie
Kort samengevat bestaat een Bedrijfsproces uit meerdere Deelprocessen, bestaat een Deelproces uit meerdere Processtappen en bestaat een Processtap uit meerdere Handelingen. Kenmerkend voor een bedrijfsproces is dat het wordt uitgevoerd door één organisatie. Voor het leveren van een dienst kunnen organisaties samenwerken. Elke organisatie heeft dan een eigen Bedrijfsproces. Bedrijfsprocessen die samen een dienst leveren, noemen we een Ketenproces. Kenmerkend voor een Ketenproces is dat het zich over organisatiegrenzen heen afspeelt. Ook een inwoner kan een taak uitvoeren in een Ketenproces, als onderdeel van een Bedrijfsproces.
Het ketenproces (waarin verschillende organisaties samenwerken met ieder hun eigen bedrijfsproces) wordt de nieuwe norm. Dit ketenproces is ook op te bouwen uit handelingen. De klant ervaart één overheid daarin en heeft geen weet van de achterliggende handelingen die door verschillende organisaties worden uitgevoerd. Een ketenproces kan ook binnen een organisatie gezien worden als afdelingen samen aan een product voor de klant moeten werken. De verdeling deelproces en processtap gaan vervallen; deze worden vervangen door een reeks van API-handelingen.
Processen digitaliseren
In de GEMMA procesarchitectuur is de onderverdeling in processen benaderd vanuit een business perspectief. De verschillende niveaus representeren een bepaalde taak die door een bedrijf, afdeling, ambtenaar of burger wordt uitgevoerd – het menselijk handelen. Veel processen zijn van buitenaf gezien digitaal en geautomatiseerd. Bij de verwerking van gegevens in processen (in de backoffice) gebeurt dit echter nog veel door menselijke handelingen dat niet direct zichtbaar is.
In de GEMMA is het principe opgenomen dat we als gemeente onze diensten en processen digitaliseren. Waar het menselijk handelen niet of moeizaam vervangen kan worden door een geautomatiseerde vorm, blijft het menselijk handelen gehandhaafd.
De vertaling van het menselijk handelen naar een geautomatiseerde afhandeling vindt zijn weerslag in software. Voorheen werden taken gestuurd door applicaties waarin een persoon handmatige handelingen moest uitvoeren om een volgende stap in het proces (workflow) te starten. In de Common Ground architectuur worden applicaties uiteengelegd in gegevens, services en is een aparte laag ontstaan waarin de geautomatiseerde handelingen worden vormgegeven en het menselijke handeling ingepast wordt in het digitale proces. Vanuit Common Ground noemen we dit laag 4: de (applicatie)proceslaag.
Een groot deel van de handelingen die voorheen door mensen werd uitgevoerd, wordt nu door software uitgevoerd. Daarmee verschuiven de handelingen uitgevoerd door mensen naar geautomatiseerde handelingen uitgevoerd door software. Mensen zijn in staat om bepaalde handelingen op basis van een beknopte beschrijving uit te voeren. Software daarentegen moet exact weten welke handeling uitgevoerd moet worden en in welke volgorde. Dit betekent dat de beschrijving van de software-handelingen die nodig is voor de uitvoering van een taak meer detail bevat.
Geautomatiseerde handelingen dragen er toe bij dat taken steeds op dezelfde manier worden uitgevoerd. Daar waar menselijk handelen nog vrijheid kent in uitvoering, is die in een geautomatiseerde omgeving sterk ingeperkt. Dit biedt kansen aan standaardisering van uitvoering van taken. Common Ground zorgt ervoor dat standaardisering van taken niet alleen binnen organisaties kan worden toegepast maar dat de geautomatiseerde taken ook door andere organisaties kunnen worden uitgevoerd. Om dat ook waar te kunnen maken zijn afspraken nodig over hoe de geautomatiseerde processen met behulp van services bij 352 gemeenten kunnen worden toegepast. In deze notitie wordt specifiek ingegaan op deze afspraken voor proceslaag 4 van Common Ground.
Scope
De informatiekundige visie van Common Ground heeft als uitgangspunt dat een applicatie niet meer als silo wordt gebouwd (de ‘silo’) maar in 5 lagen wordt verdeeld. Elke laag heeft een eigen functionaliteit. Eén van de uitgangspunten is dat processen gescheiden worden van gegevens en dat bevragen en muteren van gegevens bij de bron gebeurt. Als we een voorbeeld intekenen op deze 5 lagen dan ontstaat onderstaande afbeelding. Een aantal handelingen bevindt zich dan op laag 4, wat uitgevoerd wordt door software.
De rode ellips met de doorgetrokken lijn vormt de scope voor de samenhang van alle handelingen in een compleet proces waarover afspraken gemaakt moeten worden. De rode ellips met de gestippelde lijn gaat over de relatie tussen de handeling en de andere lagen waarover afspraken gemaakt moeten worden. De afspraken over de rode ellips met doorgetrokken lijn staan verwoord in dit document.
Waarom basisprocessen?
Door de toenemende decentralisatie van overheidstaken, veranderingen in de samenleving en de groei van technologische mogelijkheden worden meer en andere eisen aan gemeentelijke dienstverlening en bedrijfsvoering gesteld. Om hier in mee te kunnen veranderen is een flexibele proces- en informatiehuishouding nodig.
Tegelijk willen we met Samen Organiseren gezamenlijk ontwikkelen, keuzes maken en meervoudig gebruiken. De visie van basisprocessen is dat juist door standaardisatie van dat deel van de processen die gemeenten met elkaar delen en door standaardisatie van de wijze waarop we aanpassingen doen om de processen lokaal passend te maken, we de wendbaarheid kunnen vergroten en bedrijfsvoering kunnen verbeteren. Voordelen die we voorzien zijn:
- We maken makkelijker hergebruik maken van elkaars goede ideeën;
- We hebben regie op het proces in gemeentelijke handen;
- Samenwerking met markt en mede-overheden wordt makkelijker (als we allemaal de standaarden hanteren);
- Het wordt goedkoper en makkelijker om IT oplossingen maken;
- We spreken één taal naar burger, organisaties en ambtenaren;
- We kunnen lokale invulling duidelijker zien en kijken of dat gestandaardiseerd kan worden.
Definitie basisproces
De term Basisprocessen roept veel verschillende beelden op. Moeten alle gemeenten op dezelfde wijze gaan werken? Is er nog maatwerk bij gemeenten mogelijk? VNG Realisatie hanteert de volgende definitie van een basisproces.
Definitie basisproces
Een basisproces is de set maximaal gestandaardiseerde handelingen, benodigde gegevens en beslisregels voor de uitvoering van een publiek(e) of privaat(rechtelijke) taak van gemeenten zodanig vormgegeven dat deze taak zoveel mogelijk geautomatiseerd kan worden uitgevoerd.
Aanvullend op deze set standaarden ontwikkelt een gemeentelijke werkgroep een set direct bruikbare adviesproducten waaronder :
- een adviesproces (=volgorde van handelingen en is eigenlijk het ‘oude’ bedrijfsproces),
- een interactieproces (content voor uitvragen van benodigde gegevens) en
- een advies over te gebruiken API’s en Services (benodigde koppelingen en toepassingen om gegevens te verzamelen, bewerken en registreren)
Gemeente kunnen zelf aanvullingen op de standaard ontwikkelen om aan te sluiten op lokale wet- en regelgeving en/of hun eigen dienstverleningsvisie. Deze aanvullingen betekenen voor deze gemeente dat er wijzigingen ten opzichte van de set adviesproducten optreden.
Waar moet een basisproces minimaal aan voldoen?
- Een basisproces is voor alle gemeenten toepasbaar: Er worden standaarden opgesteld voor de uitvoering van de landelijk geldende wet(ten) inclusief de aanvullende handelingen die nodig zijn om die wetten uit te voeren;
- Een basisproces is direct in de praktijk bruikbaar: Bij elk basisproces wordt met gemeenten de benodigde informatievoorziening op Common Ground gerealiseerd (o.a. API’s Services, ontsluiting landelijke databronnen);
- Een basisproces is aan lokale vereisten aanpasbaar: Elk basisproces kan aangevuld worden om aan te sluiten bij lokale wet- en regelgeving en dienstverleningsvisies;
- Een basisproces is makkelijk herbruikbaar: Zowel de standaarden als informatiekundige componenten worden beschikbaar gesteld via het Common Ground componentenregister, inclusief documentatie voor lokale implementatie.
De 5 ontwerpaspecten
Onderstaande figuur schetst de samenhang van de 5 ontwerpaspecten van basisprocessen. Ook niet-basisprocessen kunnen gebruikmaken van onderstaande aspecten. Het biedt een raamwerk om een proces (op) te bouwen waarbij alle relevante aspecten aandacht krijgen en worden meegenomen.
Standaard: Processpecificaties
- De procesdefinities bevatten één of meerdere handelingen in BPMN. We streven ernaar de BPMN maximaal automatisch uitvoerbaar (executable) te maken. Een handeling levert een concreet (deel)resultaat aan het basisproces en is herbruikbaar in andere basisprocessen.
- Elk basisproces bevat één of meerdere handeling. Een handeling kan uit meerdere gestandaardiseerde, geautomatiseerde en/of menselijke handelingen bestaan.
- De set wettelijk vereiste handelingen worden gestandaardiseerd. De volgorde van handelingen ligt niet vast, maar wordt als adviesproces opgeleverd.
Standaard: Functionele beschrijving gegevens
- Overzicht van de benodigde gegevens om het proces uit te voeren. Deze kunnen worden vastgelegd in verzoeken, zaken of anderszins maar worden altijd bij de bron gehaald.
- Hiervoor wordt gemaakt van het Metamodel InformatieModellen (MIM).
Standaard: Beslis- en rekenregels specificatie
- Indien mogelijk besturen beslisregels het proces op basis van beschikbare data (routering, keuzes, besluiten).
- Beslisregels worden gestandaardiseerd vastgelegd in DMN.
Advies: Interactie specificaties
- Definitie van de manier waarop gegevens van inwoners, ondernemers en/of ambtenaren aan het proces worden toegevoegd via digitale kanalen.
- Deze kanalen worden in voor gebruikers logische wijze modulair opgebouwd (rendering) uit een gestandaardiseerde bibliotheek met invoer- of informatie-elementen.
Advies: Functionele beschrijving API’s
- Specificatie van benodigde en beschikbare API’s voor koppeling met gebruikersinterface(s), services en/of gegevensbronnen.
Principes basisprocessen
Voor de basisprocessen is een aantal principes uitgewerkt. Aanvullend aan die principes wordt ook een aantal algemeen geldende principes gehanteerd.
Algemeen
Basisprocessen
Bij het ontwerpen of toepassen van basisprocessen gelden de onderstaande principes.
| # | BP-01 |
|---|---|
| Principe | Een basisproces is de set maximaal gestandaardiseerde handelingen, benodigde gegevens en beslisregels voor de uitvoering van een publiek(e) of privaat(rechtelijke) taak van gemeenten zodanig vormgegeven dat deze taak zoveel mogelijk geautomatiseerd kan worden uitgevoerd. |
| Omschrijving | Een basisproces is een samenstelling van een minimaal aantal handelingen waarmee de wet kan worden uitgevoerd. Door alleen die handelingen op te nemen in het basisproces, is het bruikbaar voor alle 352 gemeenten. Omdat de samenstelling van alleen de wettelijke handelingen door alle gemeenten gebruikt wordt, is het betreffende basisproces daarmee verheven tot standaard. |
| Implicatie |
|
| # | BP-02 |
|---|---|
| Principe | Een basisproces kan uitgebreid worden met optionele handelingen. |
| Omschrijving | Een basisproces bevat alleen handelingen voor de wettelijke taakuitvoering. Lokale regelgeving en dienstverleningsvisie is specifiek voor (een) bepaalde gemeente(n). Het basisproces kan uitgebreid worden met niet-wettelijke handelingen om tegemoet te komen aan deze lokale vereisten. Daarmee is het geen basisproces meer. |
| Implicatie |
|
| # | BP-03 |
|---|---|
| Principe | Handelingen in een basisproces kunnen in volgorde aangepast worden als er geen dwingende relatie is met een voorgaande of opvolgende handeling. |
| Omschrijving | Binnen een basisproces is er geen verplichte volgorde van handelingen indien er geen afhankelijkheid is met een voorgaande of opvolgende handeling. Gemeenten kunnen hierdoor zelf de gewenste volgorde van handelingen uitvoeren, zodat beter aangesloten wordt bij de uitgangspunten van hun dienstverlening. |
| Implicatie |
|
| # | BP-04 |
|---|---|
| Principe | Basisprocessen en hun onderdelen worden gezamenlijk beheerd en ontsloten via registers. |
| Omschrijving | Wijzigingen in wetten moeten worden doorgevoerd in de basisprocessen. Dit betekent dat de componenten waaruit het basisproces bestaat, moeten kunnen worden aangepast om in de uitvoering van de nieuwe wet te kunnen voorzien. Handelingen en API’s moeten derhalve worden beheerd. |
| Implicatie |
|
| # | BP-05 |
|---|---|
| Principe | Basisprocessen worden ontwikkeld onder architectuur. |
| Omschrijving | Waardetoevoeging van handelingen, interacties en API’s kunnen worden aangepast om redenen van architectuurontwerpen. Bv vanwege vereiste van een een specifieke domein architectuur. |
| Implicatie |
|
| # | BP-06 |
|---|---|
| Principe | Basisprocessen zijn gemodelleerd volgens de BPMN versie 2 standaard. |
| Omschrijving | Door processen te modelleren in een Open Standaard kan iedere gemeente de procesmodellen lezen en eventueel zelf aanpassen. De laatste versie die door de Object Management Group is gepubliceerd, wordt toegepast. |
| Implicatie |
|
Principes proceslogica - laag 4
De informatiekundige visie van Common Ground heeft als uitgangspunt dat een applicatie niet meer als silo wordt gebouwd (de ‘silo’) maar in 5 lagen wordt verdeeld. Elke laag heeft een eigen functionaliteit. In de onderste laag (laag 1) bevinden zich dat gegevens, de laag erboven (laag 2) bevatten de services die de gegevens uit de laag eronder ontsluiten. Daar bovenop volgt het integratiemechanisme (laag 3). Deze laag verbindt de onderste 2 lagen met de bovenste 2 lagen. Het is het mechanisme om gegevens tussen organisaties te kunnen ontsluiten. Dan volgen de procesinrichting (laag 4) en uiteindelijk is er de interactie (laag 5) met de eindgebruiker.
Voor elke laag worden functionele componenten ontwikkeld. Om ervoor te zorgen dat deze goed op elkaar aansluiten binnen een laag én goed aansluiten op componenten uit de andere lagen, moeten er afspraken gemaakt worden waaraan een component moet voldoen. Deze afspraken worden op hoofdlijnen beschreven door principes. Elke laag heeft een eigen set principes.
Ontwikkelingen volgens de visie van Common Ground zijn begonnen bij de onderste 3 lagen (gegevens, services en integratie). Voor die lagen zijn al principes beschreven. Services op laag 2, bijvoorbeeld, worden ontwikkeld volgens de API-strategie. In deze landelijke strategie staan principes benoemd waaraan een API moet voldoen.
Nu de ontwikkelingen meer opschuiven naar laag 4 en laag 5 ontstaat de behoefte om ook voor deze lagen principes op te stellen en toe te passen. VNG Realisatie heeft samen met een aantal gemeenten principes uitgewerkt die gelden voor de processen op laag 4. Deze principes vindt u terug in dit document.
Typen processen
In laag 4 wordt de proceslogica vormgegeven. De term ‘business rules’ wordt ook vaak gebruikt om aan te geven welke logica gevolgd wordt. In feite komt het er op neer dat bepaalde handelingen in een bepaalde volgorde worden afgehandeld. Op basis van ingevoerde of opgehaalde gegevens wordt een beslissing genomen óf en wélke volgende handeling uitgevoerd kan worden. We onderscheiden hierin 2 verschillende type logica: om processen aan te sturen en om interactie met gebruikers aan te sturen.
Aansturing proces
Bij het aansturen van het proces gaat het om de volgorde waarin geautomatiseerd handelingen met informatiesystemen kunnen worden afgehandeld. Denk hierbij aan het automatisch ophalen van gegevens uit een bronregister of het aflopen van een accorderingsproces waarbij meerdere personen in een bepaalde volgorde een akkoord moeten geven.
Aansturing interactie
Als er interactie met een gebruiker plaatsvindt, gebeurt dat in één handeling. Binnen de handeling kan de gebruiker een aantal stappen en verschillende (invoer)schermen doorlopen. In een proces kunnen meerdere "interactie"-handelingen voorkomen. Om de logica in de interactie te kunnen vormgeven, is een aansturing in interactie ook noodzakelijk. Dit is echter fijnmaziger en vindt plaats binnen één “proces”-handeling. De onderliggende techniek is hierbij anders dan de techniek die gebruikt wordt bij de aansturing van processen.
Principes aansturing proces
Deze aanvullende principes hebben betrekking op het aansturen van het verloop van de handelingen die moeten worden uitgevoerd.
| # | PP-01 |
|---|---|
| Principe | Een handeling is de kleinst mogelijke activiteit waarbij toevoeging van waarde plaatsvindt. |
| Omschrijving | Een handeling wordt zo ontworpen dat er bij de kleinst mogelijke activiteit nog een waarde wordt toegevoegd. |
| Implicatie |
|
| # | PP-02 |
|---|---|
| Principe | Vanuit een handeling kan een API worden aanroepen. |
| Omschrijving | Ten behoeve van de integratie met de andere Common Ground lagen, kan vanuit een handeling een API worden aanroepen die zich in een andere laag bevindt. Dit komt bijvoorbeeld voor als er voor een handeling gegevens nodig zijn uit een register (laag 1). Vanuit de handeling wordt dan een API (laag 2) aangeroepen om de gegevens op te halen. Maar vanuit een handeling kan ook een interactie gestart worden, zodat via de interactielaag gegevens getoond dan wel opgevraagd kunnen worden aan de gebruiker. |
| Implicatie |
|
| # | PP-03 |
|---|---|
| Principe | Een handeling kan via een API worden aangeroepen. |
| Omschrijving | Ten behoeve van de integratie met de andere Common Ground lagen, kan een handeling via een API aangeroepen worden uit een andere laag. Dit kan bijvoorbeeld voorkomen als vanuit de interactielaag een handeling wordt gestart. |
| Implicatie |
|
| # | PP-04 |
|---|---|
| Principe | Een handeling wordt zo ontworpen dat deze technologie-onafhankelijk is en de (internationale) standaard volgt. |
| Omschrijving | Een samenstelling van handelingen vormt een proces. Door de handelingen zo te ontwerpen dat deze technologie-onafhankelijk zijn en de (internationale) standaarden volgen, hebben de handelingen een open karakter en zijn ze makkelijk toe te passen in een samenwerkend systeem van verschillende componenten. |
| Implicatie |
|
| # | PP-05 |
|---|---|
| Principe | Beslisregels worden in DMN versie 1.3 gemodelleerd. |
| Omschrijving | Decision Model and Notation is een standaard voor het beschrijven en modelleren van beslissingen in een organisatie. Door het gebruik van deze standaard zijn de modellen tussen gemeenten uitwisselbaar en aanpasbaar. |
| Implicatie |
|
| # | PP-06 |
|---|---|
| Principe | Handelingen mogen worden verzameld in (geaggregeerde) handelingen. |
| Omschrijving | Als handelingen altijd in een bepaalde samenstelling voorkomen, dan mogen deze worden geaggregeerd naar een samengestelde handeling. Deze samengestelde handeling kan dan worden aangeroepen, waarbij de onderliggende handelingen de daadwerkelijke handelingen verrichten. |
| Implicatie |
|
| # | PP-07 |
|---|---|
| Principe | Handelingen worden zo ontworpen dat hergebruik mogelijk is. |
| Omschrijving | Het heeft de voorkeur dat handelingen in andere processen gebruikt kunnen worden. Hierdoor ontstaat standaardisatie van handelingen en kunnen processen sneller ontworpen en geïmplementeerd worden. |
| Implicatie |
|
Principes aansturing interactie
Deze aanvullende principes hebben betrekking op het aansturen van het verloop van de interactie die moeten worden uitgevoerd.
| # | PI-01 |
|---|---|
| Principe | Vanuit een interactie kan een API worden aanroepen. |
| Omschrijving | Vanuit de interactie die via software met een gebruiker wordt gevoerd, kan een API worden aanroepen. Dit kan nodig zijn om een volgende handeling in het proces aan te roepen. Het kan ook nodig zijn om gegevens uit een (basis- of kern)register op te halen en te tonen in de interface of gegevens die de gebruiker via de interface heeft ingevuld op te slaan in de daarvoor bestemde registers. |
| Implicatie |
|
| # | PI-02 |
|---|---|
| Principe | Een interactie kan via een API worden aangeroepen. |
| Omschrijving | Een interactie vindt plaats vanuit een handeling. Als de handeling een bepaalde interactie met een gebruiker nodig heeft, dan wordt vanuit de handeling een interactie gestart. Dit kan via een aanroep van een API gebeuren. Er kunnen ook verschillende interacties gebruikt worden die elkaar kunnen aanroepen via een API. |
| Implicatie |
|
| # | PI-03 |
|---|---|
| Principe | Een interactie bestaat uit één of meerdere pagina’s. |
| Omschrijving | Interacties zijn bedoeld om gegevens of informatie met gebruikers uit te wisselen. Per interactie kunnen in verschillende stappen gegevens getoond of gevraagd worden. Deze kunnen op één of meerdere pagina’s getoond worden. Per pagina worden dan de velden getoond die bij de betreffende stap in de interactie horen. |
| Implicatie |
|
| # | PI-04 |
|---|---|
| Principe | Een pagina kan uitgebreid worden met optionele gegevensvelden. |
| Omschrijving | Interacties zijn bedoeld om gegevens of informatie met gebruikers uit te wisselen. De verschillende pagina’s bevatten hiervoor een aantal standaard velden. Om aan te sluiten bij de wensen en eisen van de lokale regelgeving en dienstverleningsconcepten kunnen gemeenten zelf extra pagina's met velden toevoegen. |
| Implicatie |
|