GEMMA Basisprocessen

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[bewerken]

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[bewerken]

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[bewerken]

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.

Scope basisprocessen


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?[bewerken]

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[bewerken]

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?[bewerken]

  • 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[bewerken]

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.

De 5 aspecten in het ontwerpen van (basis)processen


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[bewerken]

Voor de basisprocessen is een aantal principes uitgewerkt. Aanvullend aan die principes wordt ook een aantal algemeen geldende principes gehanteerd.

Algemeen[bewerken]

GEMMA

Gemeenten hanteren de GEMMA principes
Gemeentes hanteren het GEMMA Bedrijfsfunctiemodel

GEMMA Gegevenslandschap Gemeenten hanteren de GEMMA Gegevenslandschap informatiearchitectuur principes
Common Ground Gemeenten hanteren de Common Ground realisatieprincipes
Open Standaarden Gemeenten hanteren de Open Standaarden ICT-standaarden

Basisprocessen[bewerken]

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
  • Het basisproces bevat een beperkt aantal handelingen
  • Het basisproces is door elke gemeente te gebruiken
  • Aanpassingen in het basisproces gelden voor elke gemeente
  • Handelingen zijn gestandaardiseerd
  • Een basisproces is kanaal-, tijd-, plaats- en vormonafhankelijk
  • Processen worden in BPMN versie 2.0 of hoger gemodelleerd
  • Beslisregels worden in DMN versie 1.3 of hoger gemodelleerd
# 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
  • Handelingen zijn uitwisselbaar en vervangbaar
# 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
  • Handelingen hebben zo weinig mogelijke onderlinge afhankelijkheden
  • Een vaste samenstelling van handelingen kan gegroepeerd worden tot één handeling
# 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
  • Voor het beheer van het basisproces moet een community worden ingericht zodat aansluiting met de markt behouden wordt
  • Gemeenten voeren de regie op en beheren de community
# 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
  • Daar waar architecturen gekozen wordt voor het scheiden van componenten dient de code (en daaruit volgend codebases, repositories en containers ook te zijn gescheiden
  • Voor het beheer van de architectuur moeten architectuur-boards worden ingericht zodat regie kan worden gehouden
# 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
  • Procesmodelleurs hebben kennis van BPMN
  • Er is geen softwarespecifieke aanvulling op de BPMN standaard toegestaan

Principes proceslogica - laag 4[bewerken]

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.

Principes laag 4 en 5 in relatie tot basisprocessen


Typen processen[bewerken]

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[bewerken]

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
  • Een verdere opsplitsing van een handeling is niet mogelijk als er geen toegevoegde waarde meer geleverd wordt
  • Handelingen zijn procesonafhankelijk
# 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
  • Een handeling kan een interactie starten met de gebruiker
  • Een handeling kan gegevens via laag 2 ophalen, bewerken of bewaren
# 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
  • Vanuit een interactie met de gebruiker kan een handeling gestart worden
# 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
  • Handelingen zijn open
  • Handelingen worden zo ontworpen dat ze technologie-onafhankelijk zijn
  • De (internationale) standaarden worden gevolgd, zoals BPMN
  • De gebruikte tooling voor het ontwikkelen en executeren van handelingen is open en beschikbaar
  • Handelingen kunnen met andere handelingen en andere componenten interacteren
  • Handelingen kunnen onderdeel zijn van een grotere samenstelling
  • Handelingen zijn makkelijk uitwisselbaar en inwisselbaar
# 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
  • De modellen zijn open
  • Procesmodelleurs hebben kennis van DMN
  • Beslissingen worden niet in BPMN gemodelleerd
# 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
  • Handelingen kunnen hergebruikt worden
  • De samengestelde handeling stuurt de onderliggende handelingen aan
# 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
  • Handelingen zijn niet ontworpen voor één specifiek proces
  • Handelingen zijn niet ontworpen voor één specifieke organisatie
  • Generieke handelingen worden hergebruikt in andere processen


Principes aansturing interactie[bewerken]

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
  • Een interactie kan een handeling aanroepen voor verder afhandeling
  • Een interactie kan API’s bevragen om gegevens op te halen of te bewaren
# 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
  • Een interactie kan aangeroepen worden vanuit een handeling voor interactie met de gebruiker
# 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
  • Pagina’s kunnen elkaar opvolgen
  • Pagina’s kunnen in volgorde aangepast worden als er geen dwingende relatie is met een voorgaande of opvolgende pagina
  • Pagina’s bevatten velden waarin gegevens getoond of gevraagd worden
# 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
  • Velden in een interactie kunnen in volgorde aangepast worden als er geen directie relatie is met een voorgaand of opvolgende veld
  • Velden worden logisch gegroepeerd op een pagina
  • Het uitbreiden van pagina's met extra velden door gebruikers, maakt dat de pagina geen standaard meer is. Zie hiervoor ook de definitie Basisproces en het principe BP-02
Deze pagina is het laatst bewerkt op 6 okt 2023 om 01:34.