Bedrijfsarchitectuur: verschil tussen versies

(27 tussenliggende versies door dezelfde gebruiker niet weergegeven)
Regel 1: Regel 1:
 +
[[Bestand:Figuur 3.1. Samenhang functies, processen en organisatie (Uit- “Bedrijfsarchitectuur, werken aan een samenhangende bedrijfsinrichting”, G. Bayens e.a.).jpg|miniatuur|Figuur 3.1. Samenhang functies, processen en organisatie (Uit: “Bedrijfsarchitectuur, werken aan een samenhangende bedrijfsinrichting”, G. Bayens e.a.)]]
 +
 
Dit hoofdstuk gaat in op de bedrijfsarchitectuur van de Veiligheidsregio’s zoals die is vastgelegd in de VeRA. De bedrijfsarchitectuur wordt beschreven vanuit drie verschillende perspectieven, te weten: Producten en Diensten, Bedrijfsfuncties en Bedrijfsprocessen.  
 
Dit hoofdstuk gaat in op de bedrijfsarchitectuur van de Veiligheidsregio’s zoals die is vastgelegd in de VeRA. De bedrijfsarchitectuur wordt beschreven vanuit drie verschillende perspectieven, te weten: Producten en Diensten, Bedrijfsfuncties en Bedrijfsprocessen.  
  
Regel 7: Regel 9:
 
In figuur 3.1 is grafisch weergegeven hoe processen en bedrijfsfuncties aan elkaar gerelateerd zijn. De essentie is dat een bedrijfsproces één of meerdere bedrijfsfuncties aanroept om een product of dienst te leveren. Tevens wordt duidelijk wat de gelaagdheid is van een procesmodel. Ook wordt de samenhang tussen het organisatiemodel en het functiehuis aangegeven. Kortom, dit is een metamodel van organisaties.
 
In figuur 3.1 is grafisch weergegeven hoe processen en bedrijfsfuncties aan elkaar gerelateerd zijn. De essentie is dat een bedrijfsproces één of meerdere bedrijfsfuncties aanroept om een product of dienst te leveren. Tevens wordt duidelijk wat de gelaagdheid is van een procesmodel. Ook wordt de samenhang tussen het organisatiemodel en het functiehuis aangegeven. Kortom, dit is een metamodel van organisaties.
  
FIGUUR 3 INVOEGEN
 
  
 
== Producten en diensten ==
 
== Producten en diensten ==
Regel 20: Regel 21:
 
'''Producten en diensten van een veiligheidsregio  
 
'''Producten en diensten van een veiligheidsregio  
  
Zie view producten en diensten links in de sidebar
+
Klik op de link voor een [[Overzicht_producten_en_diensten]] van de Veiligheidsregio.
  
 
== Bedrijfsprocessen==
 
== Bedrijfsprocessen==
Regel 31: Regel 32:
 
   Een bedrijfsproces is een geordende reeks werkprocessen die binnen één organisatie wordt uitgevoerd met als doel om een (combinatie van) dienst(en) te leveren aan een burger, bedrijf of andere organisatie.   
 
   Een bedrijfsproces is een geordende reeks werkprocessen die binnen één organisatie wordt uitgevoerd met als doel om een (combinatie van) dienst(en) te leveren aan een burger, bedrijf of andere organisatie.   
  
Voor het leveren van producten en diensten zijn processen nodig. Processen zijn een samenhangende set van activiteiten die op basis van een trigger (input) een product en/of dienst (output) leveren. Vaak zijn er meerdere competenties (bedrijfsfuncties) nodig om in één proces te komen tot een product of dienst. Ook is er sprake van processen op verschillende abstractieniveaus (zie figuur 3.2). Op het hoogste niveau kan er sprake zijn van ketenprocessen waarbij meerdere organisaties samenwerken om één product of dienst te leveren. Binnen organisaties zijn bedrijfsprocessen het hoogste niveau van definitie (zie ook paragraaf 3.1. voor de definitie van een bedrijfsproces). Op het niveau van werkprocessen zal er veel meer sprake zijn van lokale verschillen in scope, werkwijze, etc. Om die reden zullen in deze referentiearchitectuur enkel de bedrijfsprocessen worden beschreven. Zoals in figuur 3.3 is weergegeven worden processen vaak in een hiërarchie beschreven.
+
[[Bestand:Figuur 3.3. Definities van een proces hierarchie. Bron- Bayens & Tonissen.png|miniatuur|Figuur 3.3. Definities van een proces hierarchie. Bron: Bayens & Tonissen]]
Invoegen figuur 3.3.
 
  
 +
Voor het leveren van producten en diensten zijn processen nodig. Processen zijn een samenhangende set van activiteiten die op basis van een trigger (input) een product en/of dienst (output) leveren. Vaak zijn er meerdere competenties (bedrijfsfuncties) nodig om in één proces te komen tot een product of dienst. Ook is er sprake van processen op verschillende abstractieniveaus [[Overzicht_producten_en_diensten]]. Op het hoogste niveau kan er sprake zijn van ketenprocessen waarbij meerdere organisaties samenwerken om één product of dienst te leveren. Binnen organisaties zijn bedrijfsprocessen het hoogste niveau van definitie (zie ook paragraaf 3.1. voor de definitie van een bedrijfsproces). Op het niveau van werkprocessen zal er veel meer sprake zijn van lokale verschillen in scope, werkwijze, etc. Om die reden zullen in deze referentiearchitectuur enkel de bedrijfsprocessen worden beschreven. Zoals in figuur 3.3 is weergegeven worden processen vaak in een hiërarchie beschreven.
  
 
'''Relaties met andere (procesgerichte) kaders
 
'''Relaties met andere (procesgerichte) kaders
Regel 39: Regel 40:
  
 
Binnen zowel Brandweer NL als GHOR NL zijn al eerder kaders beschreven die betrekking hebben op processen. Dit betreft zowel procesdefinities als indicatoren (normen) die verwijzen naar mogelijke processen. Om recht te doen aan deze kaders is er in de bijlage een verwijzing opgenomen naar het referentiemodel brandweer processen, Aristoteles en de HKZ-norm (Harmonisatie Kwaliteitsbeoordeling in de Zorgsector).
 
Binnen zowel Brandweer NL als GHOR NL zijn al eerder kaders beschreven die betrekking hebben op processen. Dit betreft zowel procesdefinities als indicatoren (normen) die verwijzen naar mogelijke processen. Om recht te doen aan deze kaders is er in de bijlage een verwijzing opgenomen naar het referentiemodel brandweer processen, Aristoteles en de HKZ-norm (Harmonisatie Kwaliteitsbeoordeling in de Zorgsector).
 +
 +
'''Bedrijfsprocessen van een veiligheidsregio
 +
'''
 +
 +
Klik op de link voor een [[Overzicht_bedrijfsprocessen]]  van een veiligheidsregio.
  
 
== Bedrijfsfuncties==
 
== Bedrijfsfuncties==
Regel 45: Regel 51:
 
'''
 
'''
  
Bedrijfsfuncties geven inzicht in wat een veiligheidsregio doet (wat de kerntaken zijn), onafhankelijk van de organisatorische inrichting ervan. Het bedrijfsfunctiemodel toont de bedrijfsfuncties in relatie tot elkaar en biedt daarmee een uitgangspunt voor andere modellen in de VeRA.  
+
Bedrijfsfuncties geven inzicht in wat een veiligheidsregio doet (wat de kerntaken zijn), onafhankelijk van de organisatorische inrichting ervan. Het bedrijfsfunctiemodel toont de bedrijfsfuncties in relatie tot elkaar en biedt daarmee een uitgangspunt voor andere modellen in de VeRA.
 +
 
 +
De definitie van een bedrijfsfunctie is als volgt (Bron:NORA2.0):
  
De definitie van een bedrijfsfunctie is als volgt:
+
  Een bedrijfsfunctie is een aandachtsgebied waaraan het bedrijf structureel aandacht wil besteden (= energie in wil stoppen, structureel middelen voor wil inzetten) om zijn bedrijfsdoelstelling te realiseren. Een bedrijfsfunctie kan daarom ook gezien worden als een groepering van intern gedrag op basis van een bepaald criterium (bijvoorbeeld plaats (dezelfde afdeling), communicatie, benodigde competenties, gedeelde bronnen en gedeelde kennis). Een bedrijfsfunctie representeert een stuk toegevoegde waarde van de organisatie.
  
  Een bedrijfsfunctie is een aandachtsgebied waaraan het bedrijf structureel aandacht wil besteden (= energie in wil stoppen, structureel middelen voor wil inzetten) om zijn bedrijfsdoelstelling te realiseren. Een bedrijfsfunctie kan daarom ook gezien worden als een groepering van intern gedrag op basis van een bepaald criterium (bijvoorbeeld plaats (dezelfde afdeling), communicatie, benodigde competenties, gedeelde bronnen en gedeelde kennis). Een bedrijfsfunctie representeert een stuk toegevoegde waarde van de organisatie (Bron:NORA2.0).
+
[[Bestand:Figuur 3.4 Figuur 3.4. Bedrijfsfunctiemodel als spin in het web. Bron- G. Bayens, "Bedrijfsarchitectuur, werken aan een samenhangende bedrijfsinrichting" (2009)..png|miniatuur|Figuur 3.4. Bedrijfsfunctiemodel als spin in het web. Bron: G. Bayens, "Bedrijfsarchitectuur, werken aan een samenhangende bedrijfsinrichting" (2009).]]
  
 
Het bedrijfsfunctiemodel is een inrichting-onafhankelijke beschrijving van de taakgebieden (bedrijfsfuncties) van een veiligheidsregio die toegevoegde waarde leveren aan de omgeving en intern aan de onderdelen van de veiligheidsregio zelf. Het geeft de kernactiviteiten van de veiligheidsregio weer. Hierdoor is het bedrijfsfunctiemodel een behoorlijk stabiele afspiegeling van de organisatie. Organisaties wijzigen met grote regelmaat en daarmee wijzigt ook hun organogram; bedrijfsfuncties zijn over het algemeen stabiel, ongeacht de verandering in de organisatiestructuur.  
 
Het bedrijfsfunctiemodel is een inrichting-onafhankelijke beschrijving van de taakgebieden (bedrijfsfuncties) van een veiligheidsregio die toegevoegde waarde leveren aan de omgeving en intern aan de onderdelen van de veiligheidsregio zelf. Het geeft de kernactiviteiten van de veiligheidsregio weer. Hierdoor is het bedrijfsfunctiemodel een behoorlijk stabiele afspiegeling van de organisatie. Organisaties wijzigen met grote regelmaat en daarmee wijzigt ook hun organogram; bedrijfsfuncties zijn over het algemeen stabiel, ongeacht de verandering in de organisatiestructuur.  
  
Het bedrijfsfunctiemodel is een soort ondergrond waar vervolgens andere aspecten opgelegd worden, zoals processen, applicaties en projecten. Figuur 3.4 toont het bedrijfsfunctiemodel als spin in het web voor andere architectuurproducten.
+
Het bedrijfsfunctiemodel is een soort ondergrond waar vervolgens andere aspecten opgelegd worden, zoals processen, applicaties en projecten.  
 
+
Bedrijfsfuncties zorgen voor een logische opdeling van activiteiten binnen een organisatie, waarbij zij zichzelf kunnen inrichten zonder daarbij afhankelijk te zijn van andere bedrijfsfuncties. Bedrijfsfuncties zijn ontkoppelbaar waardoor er flexibiliteit ontstaat in de inrichting van de organisatie. Hierbij is het belangrijk dat de verantwoordelijkheden per bedrijfsfunctie eenduidig belegd worden en ‘applicaties niet over de grenzen van bedrijfsfuncties heen werken’² . Bedrijfsfuncties kunnen door hun eigenschap dat ze ontkoppelbaar zijn, ook helpen bij het beantwoorden van in- en outsourcingsvraagstukken.
Figuur 3.4 invoegen?
 
 
 
Bedrijfsfuncties zorgen voor een logische opdeling van activiteiten binnen een organisatie, waarbij zij zichzelf kunnen inrichten zonder daarbij afhankelijk te zijn van andere bedrijfsfuncties. Bedrijfsfuncties zijn ontkoppelbaar waardoor er flexibiliteit ontstaat in de inrichting van de organisatie. Hierbij is het belangrijk dat de verantwoordelijkheden per bedrijfsfunctie eenduidig belegd worden en ‘applicaties niet over de grenzen van bedrijfsfuncties heen werken’2 . Bedrijfsfuncties kunnen door hun eigenschap dat ze ontkoppelbaar zijn, ook helpen bij het beantwoorden van in- en outsourcingsvraagstukken.
 
  
 
De zuster-referentiearchitectuur van de waterschappen, WILMA, beschrijft ook nog het volgende belangrijke aspect van bedrijfsfuncties:
 
De zuster-referentiearchitectuur van de waterschappen, WILMA, beschrijft ook nog het volgende belangrijke aspect van bedrijfsfuncties:
Regel 65: Regel 70:
 
Bedrijfsfuncties leggen de basis voor het maken van afspraken over gegevensuitwisseling o.a. ten behoeve van de ketens. De bedrijfsfuncties zijn verantwoordelijk voor het inzichtelijk maken van hun koppelvlakken voor zowel de eigen organisatie als andere organisaties. Via deze koppelvlakken kan de bedrijfsfunctie gestandaardiseerd gegevens uitwisselen. In toenemende mate zien we de gebiedsgerichte aanpak opkomen: de diverse ketenpartners leveren geo-gerelateerde gegevens aan omtrent een bepaald onderwerp (bv fysieke veiligheid) en hiervan wordt een gecombineerd beeld getoond. Hierdoor wordt informatie steeds minder per kolom (brandweer, GHOR) ontsloten; in toenemende mate is informatie multi-disciplinair. Hierdoor wordt het belang van afspraken over eigenaarschap van gegevens en het conformeren aan standaarden nog prominenter. Standaardisatie maakt de samenwerking binnen en tussen veiligheidsregio’s mogelijk. Zo draagt de VeRA bij aan één van de belangrijkste speerpunten van de veiligheidsregio’s: gegevens delen.
 
Bedrijfsfuncties leggen de basis voor het maken van afspraken over gegevensuitwisseling o.a. ten behoeve van de ketens. De bedrijfsfuncties zijn verantwoordelijk voor het inzichtelijk maken van hun koppelvlakken voor zowel de eigen organisatie als andere organisaties. Via deze koppelvlakken kan de bedrijfsfunctie gestandaardiseerd gegevens uitwisselen. In toenemende mate zien we de gebiedsgerichte aanpak opkomen: de diverse ketenpartners leveren geo-gerelateerde gegevens aan omtrent een bepaald onderwerp (bv fysieke veiligheid) en hiervan wordt een gecombineerd beeld getoond. Hierdoor wordt informatie steeds minder per kolom (brandweer, GHOR) ontsloten; in toenemende mate is informatie multi-disciplinair. Hierdoor wordt het belang van afspraken over eigenaarschap van gegevens en het conformeren aan standaarden nog prominenter. Standaardisatie maakt de samenwerking binnen en tussen veiligheidsregio’s mogelijk. Zo draagt de VeRA bij aan één van de belangrijkste speerpunten van de veiligheidsregio’s: gegevens delen.
  
 +
² Functionaliteit moet modulair opgebouwd zijn. Overigens geldt ook hier: ‘comply or explain’
  
 
'''Beschrijving bedrijfsfuncties van een veiligheidsregio
 
'''Beschrijving bedrijfsfuncties van een veiligheidsregio
 
'''
 
'''
  
De bedrijfsfuncties worden in figuur 3.3 per genoemd domein gevisualiseerd in het bedrijfsfunctiemodel.  
+
De bedrijfsfuncties worden in [[Overzicht_bedrijfsfuncties]] per genoemd domein gevisualiseerd in het bedrijfsfunctiemodel.  
  
 
Binnen het bedrijfsfunctiemodel van de VeRA zijn de functies van de Veiligheidsketen (van koud naar warm, met terugkoppeling) opgenomen. Binnen de koude fase Risicobeheersing zijn de schakels Proactie en Preventie samengevoegd. Hiervoor is gekozen omdat het onderscheid tussen Proactie en Preventie veel meer inhoudelijk is (advies over c.q. handhaving van de brandveiligheid in de ruimtelijke ontwikkeling of van fysieke objecten) dan in de bedrijfsfunctie. Bovendien kan gesteld worden dat alle functies binnen Risicobeheersing de risico’s en het minimaliseren ervan centraal stellen. Binnen de warme fase Incidentbeheersing zijn de schakels preparatie, repressie en nazorg opgenomen. De reden hiervoor is dat alle bedrijfsfuncties binnen incidentbeheersing het incident centraal stellen.  
 
Binnen het bedrijfsfunctiemodel van de VeRA zijn de functies van de Veiligheidsketen (van koud naar warm, met terugkoppeling) opgenomen. Binnen de koude fase Risicobeheersing zijn de schakels Proactie en Preventie samengevoegd. Hiervoor is gekozen omdat het onderscheid tussen Proactie en Preventie veel meer inhoudelijk is (advies over c.q. handhaving van de brandveiligheid in de ruimtelijke ontwikkeling of van fysieke objecten) dan in de bedrijfsfunctie. Bovendien kan gesteld worden dat alle functies binnen Risicobeheersing de risico’s en het minimaliseren ervan centraal stellen. Binnen de warme fase Incidentbeheersing zijn de schakels preparatie, repressie en nazorg opgenomen. De reden hiervoor is dat alle bedrijfsfuncties binnen incidentbeheersing het incident centraal stellen.  
  
Daarnaast is er nog een aparte groepering gemaakt van bedrijfsfuncties die zich richten op de klantcontactfunctie. Uiteraard staat bij deze functies het contact met de klant centraal.  
+
Daarnaast is er nog een aparte groepering gemaakt van bedrijfsfuncties die zich richten op de klantcontactfunctie. Uiteraard staat bij deze functies het contact met de klant centraal. In de volgende paragrafen worden de definities gegeven van de bedrijfsfuncties. Zij staan uiteraard gegroepeerd per domein conform de Basisarchitectuur overheidsorganisaties.
 
 
In de volgende paragrafen worden de definities gegeven van de bedrijfsfuncties. Zij staan uiteraard gegroepeerd per domein conform de Basisarchitectuur overheidsorganisaties.
 
 
 
==Ketensamenwerking==
 
De Veiligheidsregio is in het eerste hoofdstuk omschreven als een organisatie die in het merendeel van de tijd preparatief in ketens en netwerken binnen en buiten de regio samenwerkt. Er wordt veelvuldig en in veel verschillende vormen samengewerkt met diverse partijen. Primair wordt samengewerkt met Politie, GGD en gemeente. Naar gelang de aard van de ramp of crisis worden hier ook andere partijen bij betrokken (waterschappen, defensie, Rijkswaterstaat, ProRail, etc.). Een andere zeer nadrukkelijke samenwerking is die met de Landelijke Meldkamer Organisatie (LMO). Specifieke ketens waarin wordt samengewerkt zijn bijvoorbeeld de VTH-keten (vergunning, toezicht en handhaving in het kader van de WABO) met organisaties als de RUD en andere toezichthouders1.
 
 
 
Ketensamenwerking kenmerkt zich onder meer door het ontbreken van eenduidige regie, het ontbreken van eenduidige financiering, en de veelheid aan probleemeigenaren. Alle betrokkenen delen eenzelfde (maatschappelijk) belang maar hebben tegelijkertijd ook hun eigen belangen.
 
 
 
Op organisatieniveau kan er worden samengewerkt doordat bedrijfsprocessen die bij verschillende organisaties zijn ondergebracht samen een ketenproces vormen. Op het informatieniveau is er vooral sprake van uitwisseling van gegevens. Dit kan plaatsvinden zonder dat er sprake is van samenwerking op organisatieniveau (bijvoorbeeld bij het gebruik van gegevens uit basisregistraties). Echter, bij iedere vorm van samenwerking op het organisatieniveau zal er ook sprake zijn van uitwisseling van gegevens en dit is ook mogelijk tussen organisaties. Binnen Service Gerichte Architectuur, die de NORA en de VeRA als principe hanteren, is er sprake van services (diensten) waarbij op netwerkniveau actuele gegevens (inclusief hun betekenis) opgehaald kunnen worden bij bekende en in sommige gevallen bij onbekende bronnen. In het laatste geval spreekt men van ‘linked open data‘.
 
 
Daarnaast kan er sprake zijn van samenwerking met ketenpartners waarbij in dezelfde applicatie wordt gewerkt. Op dat moment is er sprake van verregaande integratie op het niveau van de IT infrastructuur. Door gemeenschappelijk gebruik van een applicatie door verschillende applicatieve functies van verschillende organisaties wordt de onderlinge afhankelijkheid van de ketenpartners groot. Vanuit het concept van servicegerichte architectuur heeft dit dan ook niet de voorkeur en sluit daarmee ook niet aan op het VeRA principe S.1 (zie voor toelichting op de applicatieve functies hoofdstuk 4).
 
 
 
Figuur 3.7 geeft de ketenverbanden weer die voor de meeste Veiligheidsregio’s relevant zijn. Het niet noemen van een keten wil dus niet zeggen dat deze niet bestaat. Het is een gecomprimeerde weergave. Figuur 3.7 schetst acht ketensamenwerkingen. Ketens waar intensief mee gewerkt wordt, staan in de tekening dichter bij de Veiligheidsregio. Ketens waar minder intensief mee gewerkt wordt, staan meer op afstand. Sommige ketenpartners komen in meerdere ketentypen voor, zoals de gemeenten, politie en de GGD.
 
 
Voor de ketenpartners GGD en Politie is er een nadere analyse gedaan naar de bedrijfsfuncties waar samengewerkt wordt: zijn dit slechts enkele bedrijfsfuncties waar intensief samengewerkt wordt, of wordt er juist over de brede linie samengewerkt? Voor de gemeenten is deze analyse niet uitgevoerd; door de vele ontwikkelingen die tijdens het schrijven van het document plaats vinden bij de gemeenten, waaronder de stichting van de Regionale Uitvoerings Diensten (RUD’s of Omgevingsdiensten) was het niet mogelijk om dit samen met vertegenwoordiging van de gemeenten te doen.
 
 
 
Invoegen figuur 3.7
 
 
 
'''De veiligheidsregio’s en de politie
 
'''
 
 
 
Figuur 3.8 toont de samenwerking met de Politie, waar bij zowel de besturende, de primaire, als de secundaire functies wordt samengewerkt.
 
 
 
Bij de besturende functies wordt vooral samengewerkt in landelijke governance overleggen zoals het Veiligheidsberaad en CIO-overleggen. Binnen de Veiligheidsregio’s zelf vindt dit plaats in de Veiligheidsdirecties.
 
 
 
Op het gebied van klantcontacten wordt er bij alle bedrijfsfuncties samengewerkt: binnen de meldkamer wordt samengewerkt bij zowel melding intake als melding uitgifte. Bij adviesaanvragen zien we vooral samenwerking bij bijvoorbeeld de voorbereiding op grote evenementen. Deze aanvragen komen binnen bij de gemeente, die vervolgens advies kan vragen bij de Veiligheidsregio of Politie. Tevens wordt er veel samengewerkt bij het actueel houden van de evenementenkalender.
 
 
 
Invoegen figuur 3.8
 
  
Op het gebied van risicobeheersing zien we samenwerking bij advisering, dit gebeurt vaak tussen het Staf Grootschalig Bijzonder Optreden (SGBO) van de Politie en het Veiligheidsbureau. Gegevens die worden uitgewisseld hebben voornamelijk betrekking op de locatie/ route van het evenement, de afzettingen en tijdelijke parkeerplaatsen. Bij samenwerking op het gebied van netwerkmanagement kan gedacht worden aan het gezamenlijk afsluiten van convenanten.
+
'''Bedrijfsfuncties van een veiligheidsregio'''
  
Bij incidentbeheersing zien we vooral samenwerking in geval van een opgeschaalde situatie (GRIP) en de gezamenlijke voorbereiding hierop. Er worden vaak gezamenlijk multidisciplinaire oefeningen uitgevoerd, zoals CoPI- en ROT-trainingen, waar bijvoorbeeld de netcentrische werkwijze beoefend wordt. Informatie die vergaard wordt in de bedrijfsfunctie ‘planvorming’ van de Veiligheidsregio, kan tijdens een incident opgehaald worden door alle crisispartners zoals benoemd in het regionaal crisisplan (brandweer, GHOR, politie, gemeente, defensie). De Politie wisselt tijdens opgeschaalde incidenten ook de informatie uit die zij binnen hun ‘gedeeld veiligheidsbeeld’ vergaard hebben en die van belang kan zijn voor andere crisispartners.
+
Klik op de link voor een [[Overzicht_bedrijfsfuncties]] van een veiligheidsregio.
Met betrekking tot de secundaire functies wordt er vooral samengewerkt tussen de Veiligheidsregio en de politie op het gebied van informatiemanagement. De Veiligheidsregio en de Politie werken vooral samen op het gebied van het beheren van gemeenschappelijke voorzieningen zoals de WAS-sirenes en C2000 infrastructuur en gemeenschappelijke applicaties zoals het GMS.
 
  
Met betrekking tot gegevens is geconstateerd dat er definitieverschillen bestaan tussen de kolommen in de Veiligheidsregio en de politie voor bepaalde kernregistraties. Bijvoorbeeld bij de kernregistratie personen, gebruiken de GHOR en GGD het Elektronisch Patiënten Dossier (EPD).
+
== Bedrijfsobjecten ==
en de Politie heeft een verdachtenregistratie. De brandweer stuurt nauwelijks op een kernregistratie personen, maar is vooral objectgeoriënteerd. De basisregistratie voor deze objecten, de Basisregistratie Adressen en Gebouwen (BAG) bevat alleen adresseerbare objecten. De brandweer heeft ook behoefte aan niet-adresseerbare objecten zoals terreinen. De Politie hanteert een bredere definitie van objecten: auto’s kunnen ook objecten zijn. Hieruit blijkt dat het belangrijk is om op dataniveau afspraken te maken om te komen tot een gemeenschappelijke vocabulaire
 
  
'''De Veiligheidsregio en de GGD
+
'''Wat zijn Bedrijfsobjecten?
 
'''
 
'''
  
Figuur 3.9 toont de samenwerking met de GGD, waar bij zowel de besturende, de primaire, als de secundaire functies wordt samengewerkt.
+
Volgens GEMMA is een bedrijfsobject (Bron: GEMMA Online):
De GHOR en de GGD werken in toenemende mate samen. Het gezamenlijk sturen van de GHOR en GGD begint met de aanstelling van één directeur Publieke Gezondheidszorg (DPG) per veiligheidsregio. Deze stuurt op geneeskundige hulpverlening in zowel de preparatieve als repressieve fase. De DPG heeft vaak zitting in de Veiligheidsdirecties. Bij de besturende functies wordt ook veel samengewerkt in landelijke governance overleggen zoals het Veiligheidsberaad en CIO overleggen. De GHOR en de GGD stellen samen ook vaak strategische plannen op.
 
 
 
De GHOR en de GGD werken bij een groot aantal primaire bedrijfsfuncties samen. In de risicobeheersing levert de GGD bijvoorbeeld de risico’s met betrekking tot Medische Milieukunde en Infectieziektebestrijding aan, die door de Veiligheidsregio verwerkt worden in het regionaal risicoprofiel. Ook wordt bij de advisering van evenementen samengewerkt tussen de GGD en de GHOR.
 
 
 
Invoegen figuur 3.9
 
  
Op het gebied van incidentbeheersing wordt vooral samengewerkt in geval van een opgeschaalde situatie (GRIP) en bij de gezamenlijke voorbereiding hierop. De opschaling van de GGD (GGD rampen opvangplan) sluit aan bij de GRIP-structuur van de Veiligheidsregio’s. De preparatieve gegevens zoals vergaard binnen de Veiligheidsregio’s worden tijdens een incident gedeeld met de GGD door de backoffice GHOR. De GGD maakt planvorming ten aanzien van bijvoorbeeld infectieziektebestrijding en deelt dit weer met de Veiligheidsregio. Tijdens de hulpverlening wordt informatie vaak mondeling uitgewisseld.
+
Een bedrijfsobject is een passief element dat vanuit bedrijfsperspectief relevantie heeft.
  
Met betrekking tot de secundaire functies wordt er vooral samengewerkt tussen de Veiligheidsregio en de GGD op het gebied van informatiemanagement. We zien regelmatige dat de ICT-technische infrastructuur gedeeld wordt, of dat één van de twee partijen de kantoorautomatisering voor de andere partij beheert.
+
Een bedrijfsobjectmodel beschrijft de objecten waarmee organisaties te maken hebben. Het gaat met name over de objecten waarover ook gegevens worden vastgelegd. Het wordt ook wel een conceptueel gegevensmodel genoemd. Het is nadrukkelijk nog geen logisch gegevensmodel. Het model beschrijft de grotere eenheden van gegevens in een taal die breed in de organisatie herkenbaar is en geeft dus nog geen details over de precieze gegevensstructuur. Het legt focus op grotere verzamelingen van gestructureerde gegevens die breed worden gedeeld in de organisatie. Het model lijkt op het bedrijfsfunctiemodel in de zin dat het ook onafhankelijk is van de inrichting van organisatie en IT en daardoor ook een stabiel referentiekader biedt. Nog meer dan het bedrijfsfunctiemodel creëert het een gemeenschappelijke taal voor de meest gebruikte objecten waar instellingen mee werken. De toepassing van het bedrijfsobjectmodel ligt vooral in het ondersteunen van organisatiebrede discussies over verantwoordelijkheden voor het beheren van gegevens. In veel organisaties zijn het bronsysteem en het eigenaarschap van gegevens onvoldoende helder aangewezen. Deze onduidelijkheden veroorzaken een lagere kwaliteit van gegevens waardoor het lastig is een consistent en integraal beeld te krijgen. In het kader van verantwoording is dit onacceptabel. Van elk bedrijfsobject zou duidelijk moeten zijn wie eindverantwoordelijk is en wie de gegevens functioneel beheert. Een andere belangrijke toepassing is het bepalen van de applicatie die kan worden beschouwd als bron voor de bij het bedrijfsobject behorende gegevens (ook wel: “system of record”). Andere applicaties worden voorzien van gegevens uit de bronapplicatie. Het model is ook een hulpmiddel bij het classificeren van gegevens ten behoeve van informatiebeveiliging. Voor elk object zou helder moeten zijn welk niveau van beschikbaarheid, integriteit en vertrouwelijkheden gewenst is.
  
'''Impact van de brede samenwerking met Politie en GGD op de informatie uitwisseling
+
'''Bedrijfsobjecten van een veiligheidsregio
 
'''
 
'''
  
In de vorige paragrafen is beschreven dat de Veiligheidsregio een brede samenwerking heeft met de Politie en de GGD, waarbij er op meerdere bedrijfsfuncties samengewerkt wordt. Om goed samen te kunnen werken, maar ook om de eigen organisatie te kunnen blijven ontwikkelen, is het belangrijk dat er op modulaire wijze samengewerkt wordt: hierdoor zal een wijziging in een bepaald gebied niet direct leiden tot een ‘domino-effect’ aan wijzigingen in andere bedrijfsfuncties. Het creëren van één ‘supercloud’ waarin alle functionaliteit aanwezig is waardoor Veiligheidsregio’s kunnen samenwerken met alle ketens, lijkt hierdoor onmogelijk. Samenwerking dient vooral te geschieden door het uitwisselen van gegevens; het delen van applicatieve functies heeft niet de voorkeur.
+
Klik op de link voor een [[Overzicht Bedrijfsobjecten]] van een veiligheidsregio.
 
 
Voor het opzetten van samenwerkingsverbanden met de in fig. 3.7 genoemde ketenpartners t.b.v. het uitwisselen van gegevens voor een gezamenlijk maatschappelijk doel (“keteninformatisering”), is het verstandig om gelijk in te zetten op een cyclisch proces voor opzet en continue verbetering:
 
 
 
1. Ketenanalyse, zowel qua doel (“dominant ketenprobleem”), als bedrijfsprocessen, als gegevensstromen tussen de betrokken partijen.
 
 
 
2. Keten–ontwerp;
 
 
 
3. Keten casus opvolging, het toetsen in de praktijk waarbij een casus of een dienst als onderdeel van het bedrijfsproces geanalyseerd wordt om te onderzoeken of de informatieoverdracht goed verlopen is;
 
 
 
4. Ketenherontwerp.
 
 
 
De strategie van Veiligheidsregio’s is dat we:
 
 
 
1. hier aan willen haken bij de wettelijk verplichte ‘terugmelding’ van gegevens waar ‘gerede twijfel’ bestaat over de juistheid ervan;
 
 
 
2. dit in samenwerking willen doen met onze ketenpartners;
 
 
 
3. dat we dit doen op de ‘zogenaamde pluslagen’ van de basisregistraties. Dit zijn sectorspecifieke aanvullingen op de set van basisregistraties.
 

Versie van 16 jan 2020 21:10

Figuur 3.1. Samenhang functies, processen en organisatie (Uit: “Bedrijfsarchitectuur, werken aan een samenhangende bedrijfsinrichting”, G. Bayens e.a.)

Dit hoofdstuk gaat in op de bedrijfsarchitectuur van de Veiligheidsregio’s zoals die is vastgelegd in de VeRA. De bedrijfsarchitectuur wordt beschreven vanuit drie verschillende perspectieven, te weten: Producten en Diensten, Bedrijfsfuncties en Bedrijfsprocessen.

In zijn algemeenheid kunnen organisaties enerzijds beschreven worden in termen van bepalende bedrijfsfuncties (inkoop, productie, verkoop) en anderzijds in bedrijfsprocessen gericht op de levering van een product of dienst. Om een product te kunnen leveren wordt allereerst de bedrijfsfunctie inkoop aangeroepen, vervolgens worden de aangekochte grondstoffen door de functie productie omgezet in een product. Het product wordt vervolgens verkocht door de functie verkoop.

Een bedrijfsproces (‘het hoe’) leidt tot de productie van een product of dienst (het ‘wat’) en roept hierbij meerdere bedrijfsfuncties aan. Anders gezegd; welke bedrijfsfuncties worden in welke volgorde (bedrijfsprocessen) ondernomen om een product of dienst te leveren.

In figuur 3.1 is grafisch weergegeven hoe processen en bedrijfsfuncties aan elkaar gerelateerd zijn. De essentie is dat een bedrijfsproces één of meerdere bedrijfsfuncties aanroept om een product of dienst te leveren. Tevens wordt duidelijk wat de gelaagdheid is van een procesmodel. Ook wordt de samenhang tussen het organisatiemodel en het functiehuis aangegeven. Kortom, dit is een metamodel van organisaties.


Producten en diensten[bewerken]

Wat zijn producten en diensten?

Producten en diensten zijn feitelijk de bestaansreden van een organisatie. Zonder een duidelijke behoefte aan de geleverde producten en diensten zal een private onderneming geen inkomsten kunnen genereren. Voor overheidsorganisaties ligt dit anders. Vaak leveren zij producten en diensten waar een wettelijke taak aan ten grondslag ligt. Maar ook hier geldt dat zodra deze wettelijke taak wegvalt, de noodzaak voor het leveren van de producten en diensten ook wegvalt.

Voor veiligheidsregio’s zal er een bestaansreden zijn zolang er sprake is van de kans op fysieke onveiligheid. Wat wel aan verandering onderhevig is (onder andere als gevolg van gewijzigde wetgeving), is welke producten en diensten zij leveren om de maatschappelijk gewenste fysieke veiligheid zo goed mogelijk te borgen. Veiligheidsregio’s kunnen producten en diensten bijvoorbeeld gebruiken om op eenduidige wijze de productbegroting op te stellen, alle documenten te beheren rond een bepaald product of ten behoeve van business intelligence (analyse t.b.v. bedrijfsontwikkeling).

Producten en diensten van een veiligheidsregio

Klik op de link voor een Overzicht_producten_en_diensten van de Veiligheidsregio.

Bedrijfsprocessen[bewerken]

Wat zijn de bedrijfsprocessen?

Bedrijfsprocessen verbinden de bedrijfsfuncties aan elkaar om een product of een dienst te leveren. Zij vormen daarmee een logisch geheel van activiteiten van begin tot eind die moeten worden uitgevoerd om het gewenste resultaat (product of dienst) te bereiken. De definitie van een bedrijfsproces is:

 Een bedrijfsproces is een geordende reeks werkprocessen die binnen één organisatie wordt uitgevoerd met als doel om een (combinatie van) dienst(en) te leveren aan een burger, bedrijf of andere organisatie.  
Figuur 3.3. Definities van een proces hierarchie. Bron: Bayens & Tonissen

Voor het leveren van producten en diensten zijn processen nodig. Processen zijn een samenhangende set van activiteiten die op basis van een trigger (input) een product en/of dienst (output) leveren. Vaak zijn er meerdere competenties (bedrijfsfuncties) nodig om in één proces te komen tot een product of dienst. Ook is er sprake van processen op verschillende abstractieniveaus Overzicht_producten_en_diensten. Op het hoogste niveau kan er sprake zijn van ketenprocessen waarbij meerdere organisaties samenwerken om één product of dienst te leveren. Binnen organisaties zijn bedrijfsprocessen het hoogste niveau van definitie (zie ook paragraaf 3.1. voor de definitie van een bedrijfsproces). Op het niveau van werkprocessen zal er veel meer sprake zijn van lokale verschillen in scope, werkwijze, etc. Om die reden zullen in deze referentiearchitectuur enkel de bedrijfsprocessen worden beschreven. Zoals in figuur 3.3 is weergegeven worden processen vaak in een hiërarchie beschreven.

Relaties met andere (procesgerichte) kaders

Binnen zowel Brandweer NL als GHOR NL zijn al eerder kaders beschreven die betrekking hebben op processen. Dit betreft zowel procesdefinities als indicatoren (normen) die verwijzen naar mogelijke processen. Om recht te doen aan deze kaders is er in de bijlage een verwijzing opgenomen naar het referentiemodel brandweer processen, Aristoteles en de HKZ-norm (Harmonisatie Kwaliteitsbeoordeling in de Zorgsector).

Bedrijfsprocessen van een veiligheidsregio

Klik op de link voor een Overzicht_bedrijfsprocessen van een veiligheidsregio.

Bedrijfsfuncties[bewerken]

Wat zijn bedrijfsfuncties?

Bedrijfsfuncties geven inzicht in wat een veiligheidsregio doet (wat de kerntaken zijn), onafhankelijk van de organisatorische inrichting ervan. Het bedrijfsfunctiemodel toont de bedrijfsfuncties in relatie tot elkaar en biedt daarmee een uitgangspunt voor andere modellen in de VeRA.

De definitie van een bedrijfsfunctie is als volgt (Bron:NORA2.0):

 Een bedrijfsfunctie is een aandachtsgebied waaraan het bedrijf structureel aandacht wil besteden (= energie in wil stoppen, structureel middelen voor wil inzetten) om zijn bedrijfsdoelstelling te realiseren. Een bedrijfsfunctie kan daarom ook gezien worden als een groepering van intern gedrag op basis van een bepaald criterium (bijvoorbeeld plaats (dezelfde afdeling), communicatie, benodigde competenties, gedeelde bronnen en gedeelde kennis). Een bedrijfsfunctie representeert een stuk toegevoegde waarde van de organisatie.
Figuur 3.4. Bedrijfsfunctiemodel als spin in het web. Bron: G. Bayens, "Bedrijfsarchitectuur, werken aan een samenhangende bedrijfsinrichting" (2009).

Het bedrijfsfunctiemodel is een inrichting-onafhankelijke beschrijving van de taakgebieden (bedrijfsfuncties) van een veiligheidsregio die toegevoegde waarde leveren aan de omgeving en intern aan de onderdelen van de veiligheidsregio zelf. Het geeft de kernactiviteiten van de veiligheidsregio weer. Hierdoor is het bedrijfsfunctiemodel een behoorlijk stabiele afspiegeling van de organisatie. Organisaties wijzigen met grote regelmaat en daarmee wijzigt ook hun organogram; bedrijfsfuncties zijn over het algemeen stabiel, ongeacht de verandering in de organisatiestructuur.

Het bedrijfsfunctiemodel is een soort ondergrond waar vervolgens andere aspecten opgelegd worden, zoals processen, applicaties en projecten. Bedrijfsfuncties zorgen voor een logische opdeling van activiteiten binnen een organisatie, waarbij zij zichzelf kunnen inrichten zonder daarbij afhankelijk te zijn van andere bedrijfsfuncties. Bedrijfsfuncties zijn ontkoppelbaar waardoor er flexibiliteit ontstaat in de inrichting van de organisatie. Hierbij is het belangrijk dat de verantwoordelijkheden per bedrijfsfunctie eenduidig belegd worden en ‘applicaties niet over de grenzen van bedrijfsfuncties heen werken’² . Bedrijfsfuncties kunnen door hun eigenschap dat ze ontkoppelbaar zijn, ook helpen bij het beantwoorden van in- en outsourcingsvraagstukken.

De zuster-referentiearchitectuur van de waterschappen, WILMA, beschrijft ook nog het volgende belangrijke aspect van bedrijfsfuncties:

Door in kaart te brengen welke gegevens bedrijfsfuncties van elkaar nodig hebben, is het mogelijk om goede afspraken te maken over gegevensuitwisseling en wordt inzichtelijk wat kerngegevens zijn. De koppelvlakken tussen de bedrijfsfuncties geven aan welke gegevens functie overschrijdend zijn en waarover dus afspraken gemaakt moeten worden rond het delen van gegevens. Zo geeft het bedrijfsfunctiemodel focus aan de discussies over gegevensuitwisseling en kernregistraties.

Bedrijfsfuncties leggen de basis voor het maken van afspraken over gegevensuitwisseling o.a. ten behoeve van de ketens. De bedrijfsfuncties zijn verantwoordelijk voor het inzichtelijk maken van hun koppelvlakken voor zowel de eigen organisatie als andere organisaties. Via deze koppelvlakken kan de bedrijfsfunctie gestandaardiseerd gegevens uitwisselen. In toenemende mate zien we de gebiedsgerichte aanpak opkomen: de diverse ketenpartners leveren geo-gerelateerde gegevens aan omtrent een bepaald onderwerp (bv fysieke veiligheid) en hiervan wordt een gecombineerd beeld getoond. Hierdoor wordt informatie steeds minder per kolom (brandweer, GHOR) ontsloten; in toenemende mate is informatie multi-disciplinair. Hierdoor wordt het belang van afspraken over eigenaarschap van gegevens en het conformeren aan standaarden nog prominenter. Standaardisatie maakt de samenwerking binnen en tussen veiligheidsregio’s mogelijk. Zo draagt de VeRA bij aan één van de belangrijkste speerpunten van de veiligheidsregio’s: gegevens delen.

² Functionaliteit moet modulair opgebouwd zijn. Overigens geldt ook hier: ‘comply or explain’

Beschrijving bedrijfsfuncties van een veiligheidsregio

De bedrijfsfuncties worden in Overzicht_bedrijfsfuncties per genoemd domein gevisualiseerd in het bedrijfsfunctiemodel.

Binnen het bedrijfsfunctiemodel van de VeRA zijn de functies van de Veiligheidsketen (van koud naar warm, met terugkoppeling) opgenomen. Binnen de koude fase Risicobeheersing zijn de schakels Proactie en Preventie samengevoegd. Hiervoor is gekozen omdat het onderscheid tussen Proactie en Preventie veel meer inhoudelijk is (advies over c.q. handhaving van de brandveiligheid in de ruimtelijke ontwikkeling of van fysieke objecten) dan in de bedrijfsfunctie. Bovendien kan gesteld worden dat alle functies binnen Risicobeheersing de risico’s en het minimaliseren ervan centraal stellen. Binnen de warme fase Incidentbeheersing zijn de schakels preparatie, repressie en nazorg opgenomen. De reden hiervoor is dat alle bedrijfsfuncties binnen incidentbeheersing het incident centraal stellen.

Daarnaast is er nog een aparte groepering gemaakt van bedrijfsfuncties die zich richten op de klantcontactfunctie. Uiteraard staat bij deze functies het contact met de klant centraal. In de volgende paragrafen worden de definities gegeven van de bedrijfsfuncties. Zij staan uiteraard gegroepeerd per domein conform de Basisarchitectuur overheidsorganisaties.

Bedrijfsfuncties van een veiligheidsregio

Klik op de link voor een Overzicht_bedrijfsfuncties van een veiligheidsregio.

Bedrijfsobjecten[bewerken]

Wat zijn Bedrijfsobjecten?

Volgens GEMMA is een bedrijfsobject (Bron: GEMMA Online):

Een bedrijfsobject is een passief element dat vanuit bedrijfsperspectief relevantie heeft.  

Een bedrijfsobjectmodel beschrijft de objecten waarmee organisaties te maken hebben. Het gaat met name over de objecten waarover ook gegevens worden vastgelegd. Het wordt ook wel een conceptueel gegevensmodel genoemd. Het is nadrukkelijk nog geen logisch gegevensmodel. Het model beschrijft de grotere eenheden van gegevens in een taal die breed in de organisatie herkenbaar is en geeft dus nog geen details over de precieze gegevensstructuur. Het legt focus op grotere verzamelingen van gestructureerde gegevens die breed worden gedeeld in de organisatie. Het model lijkt op het bedrijfsfunctiemodel in de zin dat het ook onafhankelijk is van de inrichting van organisatie en IT en daardoor ook een stabiel referentiekader biedt. Nog meer dan het bedrijfsfunctiemodel creëert het een gemeenschappelijke taal voor de meest gebruikte objecten waar instellingen mee werken. De toepassing van het bedrijfsobjectmodel ligt vooral in het ondersteunen van organisatiebrede discussies over verantwoordelijkheden voor het beheren van gegevens. In veel organisaties zijn het bronsysteem en het eigenaarschap van gegevens onvoldoende helder aangewezen. Deze onduidelijkheden veroorzaken een lagere kwaliteit van gegevens waardoor het lastig is een consistent en integraal beeld te krijgen. In het kader van verantwoording is dit onacceptabel. Van elk bedrijfsobject zou duidelijk moeten zijn wie eindverantwoordelijk is en wie de gegevens functioneel beheert. Een andere belangrijke toepassing is het bepalen van de applicatie die kan worden beschouwd als bron voor de bij het bedrijfsobject behorende gegevens (ook wel: “system of record”). Andere applicaties worden voorzien van gegevens uit de bronapplicatie. Het model is ook een hulpmiddel bij het classificeren van gegevens ten behoeve van informatiebeveiliging. Voor elk object zou helder moeten zijn welk niveau van beschikbaarheid, integriteit en vertrouwelijkheden gewenst is.

Bedrijfsobjecten van een veiligheidsregio

Klik op de link voor een Overzicht Bedrijfsobjecten van een veiligheidsregio.

Deze pagina is voor het laatst bewerkt op 16 jan 2020 om 21:10.