m0m Organisatie Architectuur Architectuur voor Verkeersbeheersing

m0m

Organisatie Architectuur Architectuur voor Verkeersbeheersing

Organisatie Architectuur Architectuur voor Verkeersbeheersing

colofon

Uitgegeven door Ministerie van Verkeer en Waterstaat Directoraat-Generaal Rijkswaterstaat Adviesdienst Verkeer en Vervoer Postbus 1031 3000 BA Rotterdam Meetkundige Dienst Postbus 5023 2600 GA Delft Informatie AVB-bureau

Telefoon: 010-282 5986 Fax: http:

010-282 5842 //www.avb-bureau.nl

Auteur Victor Avontuur (AVV) Opmaak Phoenix & den Oudsten bv Mei 2001

Organisatie Architectuur

Inhoudsopgave

1. De organisatie architectuur binnen het raamwerk van de AVB 7 1.1 Context van de Organisatie Architectuur 1 1.2 Eisen aan de Organisatie Architectuur 3 2. Inleiding 5 2.1 Methodiek voor het Specificeren van de Organisatie Architectuur 5 2.2 Afleiding van de essentiële organisatiestructuur 7 3. Conceptueel niveau: "wat" 9 3.1 Identificatie van Uit te Voeren Activiteiten 9 3.1.1 Methodische Aspecten 9 3.1.2 Activiteiten die samenhangen met de Verkeerskundige Architectuur 10 3.1.3 Activiteiten die samenhangen met de Applicatie Architectuur 10 3.1.4 Activiteiten die samenhangen met de Architectuur van de Technische Infrastructuur 11 3.1.5 Activiteiten die samenhangen met de Informatie Architectuur 12 3.2 Classificatie van Activiteiten 12 3.2.1 Methodische Aspecten 12 3.2.2 Uitwerking van de Classificatie van Activiteiten 13 4. Logisch niveau: "hoe" 19 4.1 Methodische Aspecten 19 4.2 Rollen 79 5. Fysiek niveau: "waarmee" 23 5.1 Methodische Aspecten 23 5.1.1 Besturende Functies en Organisatie-eenheden 23 5.1.2 Het organisatiemodel van Mintzberg 24 5.2 De organisatie voor Verkeersbeheersing 25 5.2.1 Landelijke en regionale verkeersbeheersing 26 5.2.2 Algemene Verkeersbeheersing 28 5.2.3 Bestuur en beleid 30 5.2.4 Positioneren van rollen in de basisstructuur 31 5.3 De Essentiële Organisatiestructuur 33 5.4 Samenwerkingsverbanden 34 5.4.1 Interne samenwerkingsverbanden 34 5.4.2 Externe samenwerkingsverbanden 35 6. Suggesties voor implementatie van de Organisatie Architectuur 37 6.1 Relatie van het model met "Beheren met een Grote B" en "Beheren met een kleine b" 37 6.2 Systeemontwikkeling en -beheer 42


Bijlagen Bijlage 1. Identificeren van activiteiten 45 7.1 Identificatie van activiteiten die samenhangen met de Verkeerskundige Architectuur 45 7.2 Identificatie van activiteiten die samenhangen met de Applicatie Architectuur 57 7.3 Identificatie van activiteiten die samenhangen met de Architectuur van de Technische Infrastructuur 62 Bijlage 2. Het L-paso model 65 Bijlage 3. Clusters van activiteiten 71 Bijlage 4. Het organisatiemodel van Mintzberg 75 Bijlage 5. De relatie tussen het logische en fysieke niveau 77 11.1 Functies en Organisatie-eenhedenx 77 11.2 Functiekenmerken 77 11.3 Kenmerken van Organisatie-eenheden 80 Bijlage 6. Referenties 87 12.1 In de tekst gerefereerde documenten 87 12.2 Overige geraadpleegde documenten 88 Bijlage 7. Woordenlijst 89 Bijlage 8. Lijst met tabellen 97 Bijlage 9. Lijst met figuren 93


1. De Organisatie Architectuur binnen het raamwerk van de AVB

1.1 Context van de Organisatie Architectuur

Het AVB project richt zich op verkeersbeheersing op het rijkswegennet en biedt een overzicht van de elementen van verkeersbeheersing, hun interactie en samenhang. De architectuur van het verkeersbeheersingssysteem kan worden weergegeven in het AVB architectuurraamwerk dat bestaat uit een aantal onderdelen:

Figuur 1 Context diagram van de AVB

Centraal onderdeel van het raamwerk wordt gevormd door een drietal deelarchitecturen (horizontaal gepositioneerd in het raamwerk): - De Verkeerskundige Architectuur vormt het onderdeel 'business architecture' van de AVB architectuur: hierin worden de verkeerskundige aspecten beschreven van hoe men met verkeersbeheersing om wil gaan, welke concepten hierbij een rol spelen en welke relaties deze met elkaar hebben. - De Applicatie Architectuur beschrijft de implementatie van verkeerskundige maatregelen in een onderhoudbaar en bruikbaar geheel, bestaande uit een stelsel van modulaire applicaties, en beschrijft de samenhang tussen de verschillende onderdelen. - De Architectuur van de Technische Infrastructuur beschrijft de generieke ondersteunende ICT-functionaliteit in het verkeersbeheersingssysteem, die transparante services voor ICT communicatie levert aan de verkeersbeheersingsapplicaties. Daarnaast bevat het raamwerk een tweetal deelarchitecturen die betrekking hebben op alle drie de hierboven genoemde deelarchitecturen (en derhalve verticaal zijn gepositioneerd in het raamwerk): - De Informatie Architectuur beschrijft de informatie die benodigd is ten behoeve van verkeersbeheersing op het rijkswegennet - De Organisatie Architectuur geeft een gezichtspunt op de organisatie, die benodigd is om de uitvoering van verkeersbeheersing mogelijk te maken.


Bij elke deelarchitectuur (met uitzondering van de Informatie Architectuur) worden bij de uitwerking drie niveaus onderscheiden: - het conceptuele niveau, waarin de 'wat-aspecten' van de betreffende deelarchitectuur aan de orde komen - het logisch niveau, waarin de 'hoe-aspecten' van de betreffende deelarchitectuur aan de orde komen - het fysiek niveau, waarin de 'waarmee-aspecten' van de betreffende deelarchitectuur aan de orde komen. Hierdoor ontstaat een drie-dimensionale versie van het raamwerk: Figuur 2

Driedimensionaal Context Diagram van de AVB

>ntextmodel

1

VG rkeersbeheersingssysteem

WA

RWN

V

/

/

Verkeerskundige Architectuur

I_

3

1•


y

>

Applicatie Architectuur

y

o

rganisat chitectu

Inforrr Archite

O

-\

ID

J

Architectuur van de Technische Infrastructuur

mm

!

1.2 Eisen aan de Organisatie Architectuur

De organisatie architectuur moet voldoen aan een de volgende eisen: '[.Duidelijke samenhang met andere deelarchitecturen. De organisatie architectuur is een inherent onderdeel van de totale architectuur voor de verkeersbeheersing en als zodanig dient duidelijk te zijn wat de samenhang is tussen de organisatie-architectuur en de overige deelarchitecturen. 2. Alle essentiële activiteiten opgenomen. Zoals bovenstaand gesteld, geeft de organisatie architectuur een gezichtspunt op de organisatie die benodigd is om het uitvoeren van verkeersbeheersing mogelijk te maken. Derhalve moeten in de organisatie architectuur alle uitvoerende, ondersteunende en besturende activiteiten opgenomen worden die in dat kader relevant zijn. 3. Onafhankelijk van bestaande en nieuwe organisatiestructuren. De organisatie architectuur doet op conceptueel, logisch en fysiek niveau een uitspraak over wat nodig is, en hoe en waarmee dat wordt ingevuld. Over de implementatie van deze architectuur in de bestaande of toekomstige organisatie doet de organisatie architectuur geen uitspraken, maar wel moet worden gewaarborgd dat de architectuur flexibel is in deze en dat die inpasbaar is in bestaande en toekomstige organisatie structuren. 4. Past binnen bestuurlijke en organisatorische kaders van dynamisch verkeersmanagement. Een randvoorwaarde bij de start van het AVB project was, dat de architectuur van de verkeersbeheersing is past in de bestuurlijke en organisatorische kaders van het dynamisch verkeersmanagement, zoals weergegeven in het document [RWS-HW-I]1'. Op dit document zijn in een latere fase de documenten over Beheren met een Grote B [Grote B] en beheren met een kleine b [Kleine b] gebaseerd. In Hoofdstuk 2 wordt aangegeven op welke wijze de organisatie architectuur aan deze eisen heeft voldaan.

Noten


1) Voor referenties naar documenten zie hoofdstuk 10. Referenties.


2. Inleiding

De organisatie architectuur is een conceptuele beschrijving van de essentiële elementen van de organisatie voor Verkeersbeheersing. 2.1 Methodiek voor het Specificeren van de Organisatie Architectuur

Uitgangspunt bij het opzetten van alle AVB deelarchitecturen is een indeling naar drie niveaus, te weten conceptueel, logisch en fysiek niveau. Voor de organisatie architectuur zijn deze niveaus als volgt ingevuld:

Niveau

Elementen

Conceptueel (wat) Logisch (hoe) Fysiek (waarmee)

Activiteiten Rollen Essentiële Organisatiestructuur en Samenwerkingsverbanden

Conceptueel niveau ("Wat?")

In de organisatie architectuur geeft deze laag antwoord op de vraag: "Welke activiteiten dienen te worden uitgevoerd door de organisatie teneinde verkeersbeheersing mogelijk te maken?". Dit houdt in dat alle activiteiten ter uitvoering van functies, zoals die zijn geïdentificeerd in de andere deelarchitecturen, hier onder vallen.

Identificatie van Activiteiten Via een analyse van de andere deelarchitecturen zijn deze activiteiten geïdentificeerd. Daarnaast zijn activiteiten opgenomen, die niet rechtstreeks uit de overige deelarchitecturen zijn te identificeren, maar wel tot de activiteiten in het kader van de AVB moeten worden gerekend. Daarvoor is gebruik gemaakt van het ITIL-model [ITIL-CMG] en van het L-PASO model van Dietz [Dietz]. Besturende activiteiten worden in een later stadium toegevoegd (op het fysieke niveau). Hiermee is voldaan aan de eisen genoemd onder 1. en 2. in Hoofdstuk 1. Classificatie van Activiteiten Nadat de activiteiten zijn geïdentificeerd, zijn deze geclassificeerd om clusters van activiteiten te onderkennen, die naar de aard van de te verrichten werkzaamheden bij elkaar horen. Voor de classificatie van activiteiten is ook weer gebruik gemaakt van het L-PASO model. Deze classificatie vormt de basis voor het specificeren van het logisch niveau van de organisatie architectuur.


Logisch niveau ("Hoe")

Deze laag geeft antwoord op de vraag welke rollen en verantwoordelijkheden moeten worden onderkend teneinde te zorgen dat alle activiteiten van de hierboven genoemde laag ook worden toebedeeld. Clustering van activiteiten Daartoe worden de geclassificeerde activiteiten geclusterd in rollen. Fysiek Niveau ("Waarmee")

In de organisatie architectuur wordt op deze laag een mogelijke invulling van een organisatiestructuur gegeven, waarin de rollen worden toebedeeld aan organisatorische eenheden. Tevens worden op dit niveau besturende functies onderkend. Zo ontstaat een model van de organisatie dat de "essentiële organisatiestructuur" wordt genoemd. Dit beeld van de essentie van de organisatie zal bij de implementatie van de organisatie architectuur vertaald moeten worden naar de bestaande of nieuw te vormen organisatie structuren. Bij het opzetten van deze essentiële organisatiestructuur heeft onder meer het organisatiemodel van Mintzberg als leidraad gediend. Op fysiek niveau wordt ook aandacht besteed aan samenwerkingsverbanden. Implementatie

De essentiële organisatiestructuur is te implementeren op verschillende manieren, afhankelijk van de gewenste inpassing in de bestaande en toekomstige organisatie en daarmee is voldaan aan de in Hoofdstuk 1 onder 3. gestelde eis van flexibiliteit. Relatie met "Beheren met een grote en een kleine b"

Tenslotte is nagegaan of de ideeën omtrent de organisatie van het beheer (zoals verwoord in de nota's "Beheren met een Grote B" en "Beheren met een kleine b") toepasbaar zijn op de aldus geformuleerde organisatie structuur en op de rollen, onderkend in de logische laag, waarmee wordt voldaan aan de in Hoofdstuk 1, onder 4. genoemde eis.


2.2 Afleiding van de essentiële organisatiestructuur Figuur 3 Afleiding van de Organisatie Architectuur

De afleiding van de essentiële organisatiestructuur wordt in onderstaande figuur weergegeven.


'Applicatie Architectuur "Architectuur van de Technische Infrastructuur •Informatie Architectuur

functies, processen e.d.

componenten e.d.

1

I

f

Identificatie van activiteiten

uitvoerende activiteiten

Classificatie van activiteiten

uitvoeren/inzetten

Clustering van activiteiten in rollen

uitvoerende rollen

ondersteunende rollen

Combineren van rollen in organisatie-eenheden

uitvoerende organisatie-eenheden

ondersteunende organisatie-eenheden

I

ITIL

ondersteunende activiteiten

I

f

architectureren, beheren, integreren, ontwikkelen, implementeren

,

Besturende functies


besturende functies

L-PASO

Mintzberg

Bestuurlijke en Organisatorische Kaders


3. Conceptueel niveau: "Wat n

3.1 Identificatie van Uit te Voeren Activiteiten 3.1.1 Methodische Aspecten

Verkeerskundige Architectuur (VA) Het uitgangspunt voor het identificeren van de activiteiten die samenhangen met de verkeerskundige architectuur wordt gevormd door een analyse van de volgende rapporten: - De AVB Verkeerskundige Architectuur: Domeinbeschrijving [P-VA-p1]. - De AVB Verkeerskundige Architectuur: Verkeersbeheersingsfuncties regionale operationele verkeersbeheersing [P-VA-p4], - Nadere beschrijving van verkeersbeheersingsfuncties voor het AVB project [HCG 0016]. Activiteiten worden voornamelijk ontleend aan het verkeerskundig lagenmodel [RWS-AVBj. Daarnaast wordt gecheckt of het uitvoeren van (meer gedetailleerde) verkeersbeheersingsfuncties van de regionale operationele verkeersbeheersings in de geïdentificeerde activiteiten is begrepen. Applicatie Architectuur (AA) Het uitgangspunt voor het identificeren van de activiteiten die samenhangen met de applicatie architectuur wordt gevormd door de volgende rapporten: - De AVB Applicatie Architectuur. [P-AA-p1] - Architectuurschema Applicatie Architectuur. [P-AA-p2] Informatie Architectuur (IA) Het uitgangspunt voor het identificeren van de activiteiten die samenhangen met de informatie architectuur wordt gevormd door de activiteiten die zijn geïdentificeerd in het volgende rapport: - De AVB Informatie Architectuur. [P-IA-p1] De rechtstreekse invloed van de informatie architectuur op de organisatie architectuur is gering. Veel informatie-gerelateerde functies worden ontleend aan de applicatie architectuur. Architectuur van de Technische Infrastructuur (TIAV) Het uitgangspunt voor het identificeren van de activiteiten die samenhangen met de architectuur van de technische infrastructuur wordt gevormd door de activiteiten die zijn geïdentificeerd in de volgende rapporten: - Architectuur Technische Infrastructuur Verkeersbeheersing. [P-TA-p1]


Afgeleide Activiteiten Naast de via bovenstaande analyse geïdentificeerde activiteiten, bestaan er ook activiteiten die niet rechtstreeks worden beschreven in de betreffende deelarchitecturen, maar wel tot de activiteiten in het kader van de AVB moeten worden gerekend. Voorbeelden daarvan zijn het architectureren zelf, het ontwikkelen en integreren van applicaties, het beheren en implementeren van de technische infrastructuur. Deze activiteiten zijn geïdentificeerd op indirecte manier, onder andere door toepassing van het L-PASO model van Dietz [Dietz] en door een analyse van standaard processen uit de ITIL library [ITIL-CMG]. Besturende activiteiten worden op dit niveau nog niet geïdentificeerd en worden toegevoegd op het fysieke niveau. 3.1.2 Activiteiten die samenhangen met de Verkeerskundige Architectuur

Uitgangspunt voor het identificeren van activiteiten die samenhangen met de verkeerskundige architectuur is het verkeerskundig lagenmodel. Voor iedere laag van dit model is een analyse gemaakt van de essentiële processen die worden gehanteerd. Aan die processen zijn activiteiten ontleend. Voor de laag Regelscenario's van het verkeerskundig lagenmodel is een gedetailleerde analyse van de regionale operationele verkeersbeheersingsfuncties uitgevoerd (zie [P-VA-p4] en [HCG 0016]). Deze functies en de bijbehorende data stores zijn verder geanalyseerd en voor de daaraan ontleende activiteiten gecheckt of deze gedekt zijn door de uit het lagenmodel geïdentificeerde activiteiten. Het proces wordt beschreven in Bijlage 1 en heeft geleid tot het identificeren van de volgende activiteiten: 1. Architectureren van de Verkeerskundige Architectuur 2. Verzamelen van Beleidsuitgangspunten 3. Opstellen van Regelstrategieën en Referentiekader 4. Opstellen Handboek Regeltactieken 5. Opstellen Integratieregels Regeltactieken 6. Voorbereiden Operationele Verkeersbeheersing 6.1. Off-line Bepalen van Integrale Regelscenario's 6.2. Coördineren van Ondersteuning (van WIU, IM, EM, OB, en LOV) 6.3. Opstellen Handboek Regelscenario's 7. Uitvoeren Operationele Verkeersbeheersing 7.1. Monitoren van de Verkeerssituatie 7.2. Afhandelen Integrale Regelscenario's 7.3. Activeren van Maatregelen en Signalen 8. Ontwikkelen Maatregelen 9. Inwinnen en Beheren van Gegevens 3.1.3 Activiteiten die samenhangen met de Applicatie Architectuur De applicatie architectuur levert services aan de verkeerskundige architectuur door het ter beschikking stellen van applicaties, waarmee verkeerskundige functies efficiënt ondersteund kunnen worden. Voor zover het de functionele inhoud van de applicaties betreft, zijn de activiteiten reeds geïdentificeerd. Het onderhavige deel van de identificatie richt zich op activiteiten die het gevolg zijn van het feit dat sommige verkeersbeheersingsfuncties door systemen worden uitgevoerd.


10

Voor de organisatie architectuur relevante activiteiten zijn ontleend aan de documentatie van de applicatie architectuur, aan het L-PASO model en aan een analyse van IT beheerprocessen, die beschreven zijn in de Information Technology Infrastructure Library (ITIL processen). Het L-PASO model, dat ook een belangrijke rol speelt bij het classificeren van activiteiten, richt zich op technische ondersteuning vanuit het gezichtspunt van informatievoorziening. Het model wordt beschreven in bijlage 2. In het resulterende overzicht van activiteiten die samenhangen met de applicatie architectuur, wordt onderscheid gemaakt tussen de applicatie componenten en applicaties. Daar waar organisatorisch de activiteiten met betrekking tot componenten verschillen van de activiteiten met betrekking tot de applicaties, zijn deze als twee verschillende activiteiten opgenomen. Daar waar het organisatorisch niet verschilt, zijn ze samen als één activiteit benoemd. Ook deze analyse wordt beschreven in Bijlage 1. De activiteiten die samenhangen met de applicatie architectuur zijn: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.

Architectureren van de Applicatie Architectuur Verwerven van Applicatie Componenten Assembleren van Applicaties met behulp van Applicatie Componenten Integreren van Applicaties en Applicatie Componenten Implementeren van Applicatie Componenten Implementeren van Applicaties Waarborgen van de Beschikbaarheid van Applicaties en Applicatie Componenten Waarborgen van de Capaciteit van Applicaties Beheren van de Configuratie van Applicaties en Applicatie Componenten Beheren van de Beveiliging van Applicaties en Applicatie Componenten Beheersen van de Wijzigingen in Applicaties en Applicatie Componenten Onderhouden van Applicaties en Applicatie Componenten Ondersteunen van de Bediening van Applicaties

3.1.4 Activiteiten die samenhangen met de Architectuur van de Technische Infrastructuur

De identificatie van activiteiten heeft plaatsgevonden aan de hand van de documentatie van de architectuur van de technische infrastructuur, die beschreven is als een stapsgewijze benadering om tot de implementatie van de technische infrastructuur te komen. Voorts heeft ook hier de toepassing van het L-PASO model en een analyse van ITIL processen geleid tot het benoemen van activiteiten. De activiteiten lopen grotendeels parallel aan die, welke bij de applicatie architectuur zijn geïdentificeerd. Een en ander is nader beschreven in Bijlage 1. De activiteiten die samenhangen met de architectuur van de technische infrastructuur zijn: 1. 2. 3. 4. 5.


Architectureren van de Architectuur van de Technische Infrastructuur Verwerven van Infrastructuur Componenten Ontwikkelen van de Technische Infrastructuur Integreren van de Technische Infrastructuur Implementeren van Infrastructuur Componenten

11

6. Waarborgen van de Beschikbaarheid van de Technische Infrastructuur en Infrastructuur Componenten 7. Waarborgen van de Capaciteit van de Technische Infrastructuur 8. Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten 9. Beheren van de Beveiliging van de Technische Infrastructuur en Infrastructuur Componenten 10. Beheersen van de Wijzigingen in de Technische Infrastructuur en Infrastructuur Componenten 11. Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten 3.1.5 Activiteiten die samenhangen met de Informatie Architectuur

Veel informatiegerelateerde aspecten worden ontleend aan de applicatie architectuur. In de informatie architectuur wordt één keer expliciet verwezen naar de organisatie architectuur, namelijk waar het gaat om het vaststellen van de naamgevingsstructuur van componenten. De activiteiten die samenhangen met de informatie architectuur zijn: 1. 2. 3. 4.

Vaststellen Naamgevingsstructuur voor Technische Componenten Benoemen van Technische Componenten Ontwikkelen van Gegevensmodellen Beheren van Gegevensdefinities

3.2 Classificatie van Activiteiten 3.2.1 Methodische Aspecten

Een eerste classificatie van activiteiten, die van belang is voor de organisatie architectuur, is een indeling naar: - Uitvoerende - Ondersteunende en - Besturende activiteiten. Uitvoerende activiteiten

De uitvoerende activiteiten in het kader van de verkeersbeheersing zijn de activiteiten die te maken hebben met het primaire proces: de operationele Verkeersbeheersing. Het primaire proces wordt beschreven in de Verkeerskundige Architectuur. Uitvoerende activiteiten kunnen dus alleen ontleend worden aan de Verkeerskundige Architectuur. Deze uitvoerende activiteiten worden door verkeerskundigen ook vaak aangeduid met "inzetten", daarbij doelend op het inzetten van maatregelen. Een verdergaande classificatie van de uitvoerende activiteiten is niet nodig om de uitvoerende rollen te kunnen benoemen. Ondersteunende activiteiten

Ondersteunende activiteiten kunnen worden ontleend aan elke deelarchitectuur. Om zinvol aan deze activiteiten rollen te ontlenen, is een nadere classificatie van deze ondersteunende activiteiten gewenst. Om dit te bewerkstelligen is gebruik gemaakt van het L-PASO model van Dietz (zie [Dietz]). Besturende activiteiten

Aangezien besturende activiteiten pas een rol spelen bij het ontwerpen van de essentiële organisatiestructuur, zijn die activiteiten bij de identificatie achterwege gebleven en zullen ze op het fysieke niveau worden toegevoegd.


12

Het L-PASO model

Het L-PASO model van Dietz is een middel om ondersteunende activiteiten te beschrijven bij informatie-intensieve bedrijfsprocessen, zoals het uitvoeren van verkeersbeheersing. Dit model wordt toegepast bij de classificatie van ondersteunende activiteiten voor verkeersbeheersing. Zie bijlage 2 voor een nadere uitwerking daarvan. 3.2.2 Uitwerking van de Classificatie van Activiteiten Uitvoerende activiteiten

Zoals gezegd in par. 3.2.1 is een verdergaande classificatie van uitvoerende activiteiten niet nodig om de uitvoerende rollen te kunnen benoemen. Ondersteunende activiteiten

Bij de classificatie van de ondersteunende activiteiten is gebruik gemaakt van de combinatie van systeemsoorten en activiteitensoorten zoals schematisch is weergegeven in onderstaande generieke weergave van het L-PASO model, toegepast op het domein van de verkeersbeheersing. Tabel 1 Systeemsoorten en Activiteitensoorten in de AVB

Systeemsoort

Bedrijfsproces: Uitvoeren van verkeersbeheersing

Informatiesysteem: Informatiebewerking voor het uitvoeren van verkeersbeheersing

Infrastructuursysteem: Technische infrastructuur voor de informatiebewerking


Applicatie Architectuur

Architectuur van de technische infrastructuur

Systeemintegratie

Systeemintegratie

Applicatie, applicatiecomponent

Technische infrastructuur, infrastructuurcomponent





Activiteitensoort Architectureren

Informatie Architectuur Organisatie Architectuur21 Integreren

Ontwikkelen

Strategie, tactiek, scenario, maatregel, signaal

Implementeren

Beheren

Strategie, tactiek, scenario, maatregel, signaal

In elk van de cellen van deze tabel - een combinatie van een systeemsoort en - een activiteitensoort - wordt één of meer activiteiten vermeld. Bij de toelichting van het L-PASO model in de vorige paragraaf is reeds opgemerkt, dat voor het uitvoeren van verkeersbeheersing "implementeren" niet apart hoeft te worden onderscheiden. Voor de applicaties en de technische infrastructuur daarentegen is "integreren" toegevoegd.

Noten


2) Informatie- en organisatie architectuur hebben betrekking op alle systeemsoorten.

13

Classificatie van activiteiten die samenhangen met de Verkeerskundige Architectuur

In de onderstaande tabel worden de aan de hand van de verkeerskundige architectuur geïdentificeerde activiteiten geclassificeerd naar activiteitensoort. Zowel uitvoerende activiteiten (het "inzetten") als ondersteunende activiteiten zijn in deze tabel opgenomen. Tabel 2 Classificatie van Activiteiten uit de Verkeerskundige Architectuur

Verkeersgerichte activiteiten:

Uitvoeren/ Inzetten

1. Architectureren van de Verkeerskundige Architectuur 2. Verzamelen van Beleidsuitgangspunten 3. Opstellen van Regelstrategieën en Referentiekader 4. Opstellen Handboek Regeltactieken 5. Opstellen Integratieregels Regeltactieken 6. Voorbereiden Operationele Verkeersbeheersing: 6.1. Off-line Bepalen van Integrale Regelscenario's 6.2. Coördineren van Ondersteuning (van WIU, IM, EM, OB, en LOV) 6.3. Opstellen Handboek Regelscenario's 7. Uitvoeren Operationele Verkeersbeheersing: 7.1. Monitoren van de Verkeerssituatie 7.2. Afhandelen Integrale Regelscenario's 7.3. Activeren van Maatregelen en Signalen 8. Ontwikkelen Maatregelen 9. Inwinnen en Beheren van Gegevens


14

Ondersteunende Activiteitensoorten Architectureren Ontwikkelen Beheren

Classificatie van activiteiten die samenhangen met de Applicatie Architectuur

De applicatie architectuur levert diensten aan de verkeersbeheersing in de vorm van applicaties. Applicatiegerichte activiteiten zijn uitsluitend ondersteunende activiteiten.

Tabel 3 Classificatie van Activiteiten uit de Applicatie Architectuur

Ondersteunende Activiteitensoorten Architectureren Integreren Ontwikkelen

Applicatiegerichte Activiteiten: 1. Architectureren van de Applicatie Architectuur 2. Verwerven van Applicatie Componenten 3. Assembleren van Applicaties met behulp van Applicatie Componenten 4. Integreren van Applicaties en Applicatie Componenten 5. Implementeren van Applicatie Componenten 6. Implementeren van Applicaties 7. Waarborgen van de Beschikbaarheid van Applicaties en Applicatie Componenten 8. Waarborgen van de Capaciteit van Applicaties 9. Beheren van de Configuratie van Applicaties en Applicatie Componenten 10. Beheren van de Beveiliging van Applicaties en Applicatie Componenten 11. Beheersen van de Wijzigingen in Applicaties en Applicatie Componenten 12. Onderhouden van Applicaties en Applicatie Componenten 13. Ondersteunen van de Bediening van Applicaties


15

Implementeren

Beheren

Classificatie van activiteiten die samenhangen met Architectuur van de Technische Infrastructuur

De technische infrastructuur levert diensten aan de applicatie architectuur. Elementen van de technische infrastructuur worden niet rechtstreeks gebruikt door eindgebruikers, maar door applicaties. Derhalve is ook hier geen sprake van uitvoerende activiteiten. Tabel 4 Classificatie van Activiteiten uit de Architectuur van de Technische Infrastructuur

Ondersteunende Activiteitensoorten Architectureren Integreren Ontwikkelen Implementeren

Infrastructuurgerichte Activiteiten:

1. Architectureren van de Architectuur van de Technische Infrastructuur 2. Verwerven van Infrastructuur Componenten 3. Ontwikkelen van de Technische Infrastructuur 4. Integreren van de Technische Infrastructuur 5. Implementeren van Infrastructuur Componenten 6. Waarborgen van de Beschikbaarheid van de Technische Infrastructuur en Infrastructuur Componenten 7. Waarborgen van de Capaciteit van de Technische Infrastructuur 8. Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten 9. Beheren van de Beveiliging van de Technische Infrastructuur en Infrastructuur Componenten 10. Beheersen van de Wijzigingen in de Technische Infrastructuur en Infrastructuur Componenten 11. Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten


16

Beheren

Classificatie van activiteiten die samenhangen met de Informatie Architectuur

In de onderstaande tabel worden de aan de hand van de informatie architectuur geïdentificeerde activiteiten geclassificeerd naar activiteitensoort.

Tabel 5 Classificatie van Activiteiten uit de Informatie Architectuur

Ondersteunende Activiteitensoorten Informatiegerichte

Architectureren

1. Vaststellen Naamgevingsstructuur voor Technische Componenten 2. Benoemen van Technische Componenten 3. Ontwikkelen van Gegevensmodellen 4. Beheren van Gegevensdefinities


Integreren

Ontwikkelen

Implementeren

Beheren

Activiteiten:

17

* * *


18

4. Logisch niveau: "Hoe

11

4.1 Methodische Aspecten

In dit hoofdstuk worden rollen gespecificeerd, die verantwoordelijk zijn voor één of meer activiteiten. De activiteiten waarvoor één rol verantwoordelijk is, worden vastgesteld als clusters van activiteiten die een samenhang vertonen. De basis voor het identificeren van deze clusters van activiteiten is de in het vorig hoofdstuk beschreven classificatie. Naast de classificatie naar systeemsoort en activiteitensoort, wordt ook rekening gehouden met: - Het door een persoon dan wel een systeem uitvoeren van de activiteit (in het geval van verkeerskundige activiteiten) - Aard en niveau van de activiteiten - Pragmatische overwegingen en kennis van "best practices". 4.2 Rollen Uitgaande van de schema's in het vorige hoofdstuk, waarbij activiteiten zijn ingedeeld naar activiteitensoort en rekening houdend met de bovenbeschreven criteria, zijn clusters van activiteiten gevormd, waarvoor één rol in de organisatie de verantwoordelijkheid kan nemen. Dit betekent niet dat ook slechts één persoon die rol uitvoert, maar dat de verantwoordelijkheden van die rol - gedefinieerd in de activiteiten waarvoor de rol verantwoordelijk is - logisch samenhangen. In Bijlage 3 wordt weergegeven hoe de clustering heeft plaats gevonden. Onderstaande tabellen geven een samenvatting van het resultaat, waarbij onderscheid is gemaakt tussen verkeersgerichte en systeemgerichte rollen. Er is veel overeenkomst tussen activiteiten met betrekking tot de applicatie ondersteuning en de ondersteuning met behulp van de technische infrastructuur. Dit is met name het geval voor beheersmatige activiteiten. Daarom zijn de rollen voor deze activiteiten samengevoegd onder de noemer "systeemgerichte rollen". Zodoende kunnen twee soorten rollen worden onderscheiden: verkeersgerichte en systeemgerichte rollen.


19

Tabel 6 Verkeersgerichte rollen en bijbehorende verantwoordelijkheden

Verkeersgerichte rol

Verantwoordelijk voor de activiteiten:

Verkeerskundig Architect

Architectureren van de Verkeerskundige Architectuur

Regelstrategie Opsteller

Verzamelen van Beleidsuitgangspunten Opstellen van Regelstrategieën en Referentiekader

Regeltactieken Opsteller

Opstellen Integratieregels Regeltactieken Opstellen Handboek Regeltactieken

Scenario Voorbereider

Off-line Bepalen van Integrale Regelscenario's Coördineren van Ondersteuning (van WIU, IM, EM, OB, en LOV)

Opmerkingen

Dit houdt ook in het aansturen van de operationele verkeersbeheerser's rol en het ontvangen van aanvragen voor ondersteuning (van WIU, IM, EM, OB, LOV)

Opstellen Handboek Regelscenario's Operationele VerkeersBeheerser

Afhandelen Integrale Regelscenario's

Monitoren van de Verkeerssituatie Activeren van Maatregelen en Signalen


Maatregel Ontwikkelaar

Ontwikkelen Maatregelen

Verkeersgegevens Beheerder

Inwinnen en Beheren van Gegevens

20

Dit houdt ook in het terugkoppelen van informatie over de inzet van scenario's naar derden, zoals de politie, event organisatoren, en dergelijke.

Tabel 7

Systeemgerichte rol

verantwoordelijkheden

Applicatie Architect

Verantwoordelijk voor de activiteiten:

Opmerkingen

Architectureren van de Applicatie Architectuur

Infrastructuur Architect

Architectureren van de Architectuur van de Technische Infrastructuur

Applicatie Componenten Verwerver

Verwerven van Applicatie Componenten Het ontwikkelen van (generieke) applicatie componenten zal zeer waarschijnlijk in de markt plaatsvinden of worden uitbesteed Implementeren van Applicatie Componenten

Applicatie Assembleerder

Assembleren van Applicaties met behulp van Applicatie Componenten Implementeren van Applicaties

Systeem Integrator

Integreren van Applicaties en Applicatie Componenten Integreren van de Technische Infrastructuur

Beschikbaarheids Beheerder

Waarborgen van de Beschikbaarheid van Applicaties en Applicatie Componenten Waarborgen van de Beschikbaarheid van de Technische Infrastructuur en Infrastructuur Componenten

CapaciteitsBeheerder

Waarborgen van de Capaciteit van Applicaties Waarborgen van de Capaciteit van de Technische Infrastructuur

Configuratie Beheerder

Beheren van de Configuratie van Applicaties en Applicatie Componenten Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten

BeveiligingsBeheerder

Beheren van de Beveiliging van Applicaties en Applicatie Componenten

Heeft betrekking op fysieke beveiliging en toegangs beveiliging, alsmede calamiteitenplanning, backup en recovery.

Beheren van de Beveiliging van de Technische Infrastructuur en Infrastructuur Componenten


WijzigingsBeheerder

Beheersen van de Wijzigingen in Applicaties en Applicatie Componenten Beheersen van de Wijzigingen in de Technische Infrastructuur en Infrastructuur Componenten

Applicatie Onderhouder

Onderhouden van Applicaties en Applicatie Componenten

Help Desk

Ondersteunen van de Bediening van Applicaties

Infrastructuur Ontwikkelaar

Verwerven van Infrastructuur Componenten Ontwikkelen van de Technische Infrastructuur Implementeren van de Technische Infrastructuur

Infrastructuur Onderhouder

Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten

Naamgever

Vaststellen Naamgevingsstructuur voor Technische Componenten

Gegevens definitie Beheerder

Benoemen van Technische Componenten Ontwikkelen van Gegevensmodellen Beheren van Gegevensdefinities

21


22

5. Fysiek niveau: "Waarmee

ii

5.1 Methodische Aspecten

Op het fysieke niveau wordt de essentiële organisatiestructuur voor verkeersbeheersing beschreven. Daarvoor wordt het organisatiemodel van Mintzberg als uitgangspunt genomen. 5.1.1 Besturende Functies en Organisatie-eenheden

Waar op voorgaande niveaus de besturende activiteiten buiten beschouwing werden gelaten, worden deze op dit niveau geïntroduceerd. Uitgaande van het Mintzberg model wordt een model beschreven van de "Organisatie voor Verkeersbeheersing". Daarbij is onderscheid gemaakt tussen besturende functies en organisatieeenheden. De op het logische niveau gedefinieerde rollen worden naar aard en niveau van de activiteiten waarvoor ze verantwoordelijk zijn, gegroepeerd in organisatie-eenheden, die worden aangestuurd door een besturende functie. Daarbij zijn de volgende regels gehanteerd: - Een functie kan een andere functie besturen. - Een functie kan een organisatie-eenheid besturen. - Een functie wordt in principe door één persoon uitgeoefend. - Een functie wordt in het model aangeduid met de naam die suggereert dat één persoon die functie uitoefent met uitzondering van de functies op bestuursniveau, die in feite "boven de structuur" liggen. - Een organisatie-eenheid is het laagste niveau dat in de essentiële organisatie structuur wordt gehanteerd. - Een organisatie-eenheid voert een aantal logisch samenhangende activiteiten uit en derhalve worden in het model rollen (en daarmee de verantwoordelijkheid voor activiteiten) toegekend aan organisatieeenheden. - Bij de implementatie van de organisatie architectuur kan ervoor worden gekozen om de rollen van een organisatie-eenheid uit te laten voeren door de besturende functie. - Anderzijds zal bij de implementatie worden bepaald hoe een organisatieeenheid fysiek gestalte zal worden gegeven door de vorming van afdelingen of teams. - Ook kan bij de implementatie gekozen worden voor het combineren van organisatie-eenheden.


23

Aangezien op het logisch niveau de besturende activiteiten buiten beschouwing zijn gelaten, zijn de op dat niveau gedefinieerde rollen verantwoordelijk voor activiteiten die uitvoerend of ondersteunend van aard zijn. Dat betekent dan ook dat rollen in het model van de essentiële organisatiestructuur worden toebedeeld aan organisatie-eenheden en niet aan besturende functies. Aangezien rollen zijn gedefinieerd aan de hand van de (clusters van) activiteiten waarvoor de rol verantwoordelijk is, kan uit deze positionering worden bepaald welke activiteiten elke organisatie-eenheid wordt geacht uit te voeren. Zo ontstaat een organisatiestructuur, met daarin besturende functies en organisatie-eenheden, waaraan rollen zijn toebedeeld. Deze structuur bevat de essentiële organisatorische elementen, die noodzakelijk worden geacht om verkeersbeheersing "onder architectuur" mogelijk te maken. 5.1.2 Het organisatiemodel van Mintzberg

Dit organisatiemodel bestaat al lang (ruim 20 jaar) en is nog steeds goed bruikbaar. Het model is toepasbaar op veel verschillende soorten organisaties. Het vormt met name een goede basis voor het onderkennen van diverse soorten besturende en ondersteunende activiteiten, hetgeen voor verkeersbeheersing van belang is. Zie bijlage 4 voor een nadere toelichting van het model.


24

5.2 De organisatie voor Verkeersbeheersing

Van het organisatiemodel van Mintzberg kan onderstaand model van de organisatie voor Verkeersbeheersing worden afgeleid.

Figuur 4

Organisatie voor verkeersbeheersing

Het primaire productieproces bij verkeersbeheersing is de operationele verkeersbeheersing. Technische ondersteuning bij verkeersbeheersing heeft betrekking op verkeerskundige ondersteuning (VK) of ondersteuning met betrekking tot het technische systeem (TS). Voor de uitwerking van het organisatiemodel laten we de facilitaire ondersteuning (de PIOFAH-taken) verder buiten beschouwing. Deze taken zijn uiteraard van groot belang voor het goed functioneren van de organisatie, maar vormen geen essentieel onderdeel van de AVB, met uitzondering van het architectureren van de organisatie zoals dat is gedaan in dit document31. Het buiten beschouwing laten van het PIOFAH gebied geeft de mogelijkheid om het model iets anders te presenteren.

Links en rechts staan nu de twee vormen van technische ondersteuning. Het zal duidelijk zijn dat deze organisatiestructuur aansluit bij de inzichten die zijn gepresenteerd in het model "Beheren met een kleine b". Verdere detaillering van overeenkomsten en verschillen tussen de organisatie architectuur en het model "Beheren met een kleine b" worden behandeld in Hoofdstuk 6.

Noten


3) De organisatie-architectuur is een onderdeel van AVB, maar het architectureren van de organisatie-architectuur is een activiteit, die hoort bij de PIOFAH-taken (in dit geval de O-taak).

25

Figuur 5

Organisatie voor verkeersbeheersing zonder PIOFAH taken

5.2.1 Landelijke en regionale verkeersbeheersing

Binnen verkeersbeheersing wordt onderscheid gemaakt in landelijke en regionale verkeersbeheersing (RWS-HW-I). Landelijke en regionale verkeersbeheersing zijn hiërarchisch nevengeschikt, maar hebben een aanvullende taakstelling: In essentie wordt landelijke verkeersbeheersing actief bij regio-overstijgende problematiek in de verkeersafwikkeling. Landelijke en regionale verkeersbeheersing kunnen worden beschouwd als afzonderlijke organisatie-eenheden. Er is een landelijke organisatie en er zijn vijf regionale organisaties voor verkeersbeheersing. De structuur daarvan kan in een Mintzberg model worden weergegeven. Landelijke en regionale verkeersbeheersing worden aangestuurd door resp. de landelijke en regionale verkeersmanager. Er is een landelijke verkeersmanagementcentrale en er zijn vijf regionale verkeersmanagementcentrales met elk een hoofd. Uitvoering is in handen van de Wegverkeersleider. Technische ondersteuning wordt aangestuurd door een manager verkeerskunde en een systeemmanager.


26

De organisatiestructuur voor landelijke en regionale verkeersbeheersing is in essentie hetzelfde.

Figuur 6 Landelijke verkeersbeheersing


Afkorting

Naam

LVM LMVK LOVK LSM LOTS HLVMC LWVL

Landelijk Verkeersmanager Landelijk Manager VerkeersKunde Landelijke Ondersteuning VerkeersKunde Landelijk SysteemManager Landelijke Ondersteuning Technische Systeem Hoofd Landelijke VerkeersManagementCentrale Landelijke WegVerkeersLeiding

27

Figuur 7

Regionale verkeersbeheersing

Afkorting

Naam

RVM RMVK ROVK RSM ROTS HRVMC RWVL

Regionaal VerkeersManager Regionaal Manager VerkeersKunde Regionale Ondersteuning VerkeersKunde Regionaal SysteemManager Regionale Ondersteuning Technische Systeem Hoofd Regionale VerkeersManagementCentrale Regionale WegVerkeersLeiding

5.2.2 Algemene Verkeersbeheersing

Zoals gezegd is er een landelijke verkeersmanager en zijn er vijf regionale verkeersmanagers, die in principe hiërarchisch nevengeschikt zijn. Daarboven is een overkoepelend besturingsniveau nodig vanwege de gewenste mate van uniformiteit voor verkeersbeheersing op het HWN in Nederland (landelijk en regionaal). Dat overkoepelende niveau wordt hier aangeduid met "Algemeen Verkeersmanager". Voor het bereiken van de gewenste mate van uniformiteit is op dit overkoepelende niveau algemene technische ondersteuning nodig op verkeerskundig en systeemtechnisch gebied, aangestuurd door een algemeen manager verkeerskunde en een algemeen systeemmanager.


28

Combineren we een en ander in een schema, dan ontstaat een soort divisiestructuur voor de organisatie van verkeersbeheersing. Figuur 8 Organisatie voor verkeersbeheersing

landelijk

N-H

Z-H

Afkorting

Naam

AVM AMVK ASM LVM RVM

Algemeen VerkeersManager Algemeen Manager VerkeersKunde Algemeen SysteemManager Landelijk VerkeersManager Regionaal VerkeersManager

Utrecht

Noord Oost

Zuid

Drie besturende niveaus

In de divisiestructuur kunnen dus drie besturende niveaus worden onderscheiden, die ook kunnen worden aangeduid met de termen strategische, tactische en operationele besturing.

Niveau

Besturende functie

Strategisch

Algemeen VerkeersManager Algemeen Manager VerkeersKunde Algemeen SysteemManager Tactisch Landelijk VerkeersManager Landelijk Manager VerkeersKunde Landelijk SysteemManager Regionaal VerkeersManager Regionaal Manager VerkeersKunde Regionaal SysteemManager Operationeel Hoofd Landelijke VerkeersManagementCentrale Hoofd Regionale VerkeersManagementCentrale


29

5.2.3 Bestuur en beleid

Boven en buiten de organisatie voor verkeersbeheersing staan bestuur en beleid. Voor de volledigheid wordt dat niveau hier ook weergegeven. Men kan onderscheid maken in "algemeen bestuuren beleid" en "landelijk/regionaal bestuur voor verkeersbeheersing". Algemeen Bestuur (Regering, Minister VenW): Besluiten over de mate van verkeersbeheersing die wenselijk is in Nederland en over de wijze waarop die moet worden uitgevoerd (soorten maatregelen, organisatie e.d.). Algemeen Beleid: beleidsvoorbereiding, beleidsinvoering en beleidsevaluatie ter ondersteuning van Algemeen Bestuur. Landelijk/Regionaal Bestuur VB (Minister VenW, Provinciale, Gemeentelijk en andere bestuurders): Besluiten over Landelijke/Regionale prioritering voor verkeersbeheersing. Dit leidt tot bestuurlijke convenanten, op basis waarvan landelijke en regionale regelstrategieën worden opgesteld. Landelijk/Regionaal Beleid VB: beleidsvoorbereiding, beleidsinvoering en beleidsevaluatie ter ondersteuning van Landelijk/Regionaal Bestuur VB. Dit kan als volgt worden weergegeven in onderstaande figuur. Figuur 9

Organisatie voor verkeersbeheersing, met bestuur en beleid

Algemeen Bestuur Algemeen Beleid Algemeen Verkeersmanager Landelijk Bestuur VB

Algemene Ondersteuning VK

Landelijk Beleid VB

Landelijk Verkeersmanager Landelijke Ondersteuning VK

Landelijke Ondersteuning TS

Regionaal Beleid VB

Regionaal Verkeersmanager (5) Regionale Ondersteuning VK

Hoofd Landelijke VMC

Regionale Ondersteuning TS Hoofd Regionale VMC

I

I

Landelijk Wegverkeersleider


Regionaal Bestuur VB

Algemene Ondersteuning TS

Regionaal Wegverkeersleider

30

5.2.4 Positioneren van rollen in de basisstructuur

De volgende stap is het positioneren van de op het logisch niveau onderscheiden rollen in het geschetste model op strategisch, tactisch of operationeel niveau. Deze rollen hebben betrekking op uitvoering verkeersbeheersing en op verkeerskundige en systeemtechnische ondersteuning. Uitvoering verkeersbeheersing wordt in essentie gedaan door de wegverkeersleider. Ondersteuning wordt in essentie gegeven op operationeel, tactisch en strategisch niveau. Op tactisch niveau moet daarbij onderscheid worden gemaakt tussen landelijke en regionale verkeersbeheersing. Operationele en tactische ondersteuning kunnen betrekkelijk eenduidig worden afgeleid van de rollen, die reeds zijn onderscheiden. Deze rollen hebben in hoofdzaak betrekking op dit soort ondersteuning. Strategische ondersteuning

Strategische ondersteuning kan slechts in beperkte mate worden afgeleid van rollen die reeds zijn geïdentificeerd. Op dit niveau zijn een aantal overkoepelende taakgebieden nodig, die voortvloeien uit het functioneren-onder-architectuur. Naast het beheren van de diverse deelarchitecturen zelf zijn dat met name de taakgebieden "Normen en Standaards" en "Methoden en technieken". Deze taakgebieden zijn nodig voor het aansturen van ontwikkeling en beheer van de verkeerskundige elementen (van strategie tot signaal) en de systeemtechnische elementen (van systeem tot component). Aan de systeemtechnische kant is voorts behoefte aan "Systeemintegratie" om daadwerkelijk het bouwen en verbouwen onder architectuur aan te sturen. Mede met dat doel is ook een algemene "Referentie- en Testomgeving" nodig. Tenslotte ligt het voor de hand dat vernieuwende prototype- en pilotprojecten op het overkoepelende niveau worden voorbereid en aangestuurd. "Algemene Verkeerskunde" en "Algemene Systeemkunde" zijn overkoepelende staftaken, die gericht zijn op onderzoek van nieuwe verkeerskundige en systeemtechnische elementen. Ook het uitvoeren van algemene verkeerskundige en systeemtechnische evaluaties behoort tot die taken. Besturende functies en organisatie-eenheden

Dit leidt tot onderstaand overzicht met de besturende functies en de functies of organisatie-eenheden, die zij aansturen. De relatie tussen besturende functies, organisatie-eenheden, rollen en de daaraan gekoppelde activiteiten wordt nader beschreven in bijlage 5: "De Relatie tussen het logische en het fysieke niveau".


31

Strategische besturing Tabel 8 Besturende functies en de functies of organisatie-eenheden die zij aansturen

Bestuurt

Functie

Algemeen VerkeersManager

Algemeen Manager VerkeersKunde

Algemeen SysteemManager

Regionaal en Landelijk VerkeersManager Algemeen Manager VerkeersKunde Algemeen SysteemManager Algemene VerkeersKunde Verkeerskundige Architectuur Normen en Standaards voor VerkeersBeheersing Methoden en Technieken voor VerkeersBeheersing Algemene Systeemkunde SysteemArchitectuur Normen en Standaards voor het Technische Systeem Methoden en Technieken voor het Technische Systeem Prototyping en Pilots Systeemintegratie Referentie- en Testomgeving

Tactische besturing Functie

Bestuurt

Landelijk VerkeersManager

Hoofd Landelijke VerkeersManagementCentrale Landelijk Manager Verkeerskunde Landelijk SysteemManager

Landelijk Manager VerkeersKunde Landelijk SysteemManager

Landelijke VerkeersKunde DienstenBeheer Ontwikkeling en Implementatie SysteemBeheer

Regionaal VerkeersManager

Hoofd Regionale VerkeersManagementCentrale Regionaal Manager VerkeersKunde Regionaal SysteemManager

Regionaal Manager VerkeersKunde

Regionale VerkeersKunde

Regionaal SysteemManager

DienstenBeheer Ontwikkeling en Implementatie SysteemBeheer

Operationele besturing Functie


Bestuurt


Hoofd Landelijke VerkeersManagementCentrale Landelijk Manager Verkeerskunde Landelijk SysteemManager

Landelijk Manager VerkeersKunde

Landelijke VerkeersKunde

Landelijk SysteemManager

DienstenBeheer Ontwikkeling en Implementatie

Hoofd Regionale Verkeersmanagement Centrale

Regionale WegVerkeersLeiding Regionale Coördinatie Ondersteuning Regionaal GegevensBeheer

32

5.3 De essentiële organisatiestructuur

Onderstaand schema geeft een totaal overzicht van de essentiële organisatiestructuur. Bestuur en Beleid zijn in dit schema niet opgenomen. Het schema wordt voorafgegaan door een tabel met de verklaring van de gehanteerde afkortingen. Tabel 9 Gebruikte afkortingen in het overzicht van de essentiële organisatiestructuur

Naam

Functie of Org.-eenh.

Functie Functie Org.-eenh. Org.-eenh. Org.-eenh. Org.-eenh. Functie Org. eenh. Org.-eenh.

MTTS PP SI RTO

Algemeen Verkeersmanager Algemeen Manager VerkeersKunde Algemene VerkeersKunde Verkeerskundige Architectuur Normen en Standaards voor VerkeersBeheersing Methoden en Technieken voor VerkeersBeheersing Algemeen SysteemManager Algemene Systeemkunde SysteemArchitectuur Normen en Standaards voor het Technische Systeem Methoden en Technieken voor het Technische Systeem Prototyping en Pilots Systeem 1 ntegratie Referentie- en Testomgeving

Tactisch Niveau LVM LMVK LVK LSM DB Ol SB RVM RMVK RVK RSM DB Ol SB

Landelijk VerkeersManager Landelijk Manager VerkeersKunde Landelijke VerkeersKunde Landelijk SysteemManager DienstenBeheer Ontwikkeling en Implementatie SysteemBeheer Regionaal VerkeersManager Regionaal Manager VerkeersKunde Regionale VerkeersKunde Regionaal SysteemManager DienstenBeheer Ontwikkeling en Implementatie SysteemBeheer

Functie Functie Org.-eenh. Functie Org.-eenh. Org.-eenh. Org.-eenh. Functie Functie Org.-eenh. Functie Org.-eenh. Org.-eenh. Org.-eenh.

Operationeel Niveau HRVMC RWVL CO RGB HLVMC LWVL LGB

Hoofd Regionale VerkeersManagementCentrale Regionale WegVerkeersLeiding Regionale Coördinatie Ondersteuning Regionaal GegevensBeheer Hoofd Landelijke VerkeersManagementCentrale Landelijke WegVerkeersLeiding Landelijk GegevensBeheer

Functie Org.-eenh. Org.-eenh. Org.-eenh. Functie Org.-eenh. Org.-eenh.

Afkorting

Strategisch Niveau AVM AMVK AVK VA NSVB MTVB ASM ASK SA NSTS


33

Org.-eenh. Org.-eenh. Org.-eenh. Org.-eenh. Org.-eenh.

Figuur 10 De essentiële organisatiestructuur voor verkeersbeheersing

Niveau: Strategisch

--1 ASK I :SA

: MTVB'i I N S V B I [ " V A " ' ; : AVK :

[ I ! ;NSTS : :MTTS: i

[ PP

1 : ;SI

T771

i RTO

Tactisch LSM LMVK [——1 DB H Ol i LVK I

Operationeel

RVK I i DB

|HLVMC

B

SG

i LGB i : LWVL

Legenda:

I

1 = Besturende Functie

Ol

RWVL i ; CO

; RGB

; = Organisatie-Eenheid

5.4 Samenwerkingsverbanden

Samenwerking binnen en buiten de verkeersbeheersing is van belang voor het goed functioneren van verkeersbeheersing. Hierbij maken we onderscheid tussen interne en externe samenwerking. 5.4.1 Interne samenwerkingsverbanden

In essentie kunnen twee interne samenwerkingsverbanden worden onderscheiden: 1. Algemeen Managementteam, bestaande uit: - Algemeen Verkeersmanager - Algemeen Manager Verkeerskunde - Algemeen Systeemmanager - Landelijk en Regionaal Verkeersmanagers - alsmede de Algemeen Manager Facilitaire Zaken, die verder in dit model buiten beschouwing is gebleven. 3. Landelijk of regionaal managementteam, bestaande uit: - Landelijk of Regionaal Verkeersmanager - Landelijk of Regionaal Manager Verkeerskunde - Landelijk of Regionaal Systeemmanager - Hoofd Landelijke of Regionale VerkeersManagement Centrale. Daarnaast is er natuurlijk werkoverleg binnen de diverse organisatieeenheden.


34

5.4.2 Externe samenwerkingsverbanden

Voor verkeersbeheersing is afstemming nodig met aangrenzende gebieden via bepaalde samenwerkingsverbanden. Deze samenwerkingsverbanden zijn doorgaans gewenst op verschillende niveaus (strategisch, tactisch, operationeel) en voor verschillende onderwerpen (algemeen, verkeersgericht, systeemgericht). Dit leidt tot onderstaand schema.

Tabel 10 Onderwerpen voor samenwerking

Niveau

Functie of Organisatieeenheid

Onderwerpen

Algemeen

Verkeersgericht

strategisch overleg

relatie met algemeen bestuur en beleid, strategie, organisatie, architectuur

AVM verkeerssysteembeleid, beheersingsbeleid, systeemarchitectuur, AMVK, ASM verkeerskundige systeemintegratie architectuur

tactisch overleg

relatie met landelijk of regionaal bestuur en beleid, van strategie naar uitvoering, planning, voortgang en verantwoording

regelstrategieën, regeltactieken, integraal regelscenario, overleg en tactische terugkoppeling met WIU, IM, EM, OB en LOV

operationeel overleg uitvoering

scenario's, maatregelen, operationele terugkoppeling naar WIU, IM, EM, OB en LOV

Systeemgericht

systeemplanning, systeemontwikkeling, systeemimplementatie, systeemdienstenbeheer

systeembeheer

Externe actoren, waarmee wordt overlegd zijn ondermeer: -


Andere wegbeheerders Landelijke en Regionale Politiediensten Kamers van Koophandel Event Organisatoren Vertegenwoordigers van Weggebruikers

35

LVM, RVM LMVK, LSM RMVK, RSM

HLVMC, HRVMC, CO, LWVL, RWVL, SB


36

6. Suggesties voor implementatie van de organisatie architectuur

6.1 Relatie van het model met "Beheren met een Grote B" en "Beheren met een kleine b" Beheren met een Grote B

In het model "Beheren met een Grote B " (zie [Grote B]) wordt een drietal organisatorische functies weergegeven in het kader van de dynamische verkeersbeheersing, te weten: - Verkeersmanagement functie; uitgevoerd in de "management lijn" door de landelijk verkeersmanager, de regionale verkeersmanagers en de centrales. - Verkeerskundige functie; is verantwoordelijk voor het beleidsontwikkeldeel van de beleidsuitvoeringscyclus. - IT functie; is verantwoordelijk voor het life-cycle management van DVM systemen. Deze drie functiegebieden zijn duidelijk terug te vinden in de essentiële organisatiestructuur van AVB. Wat in het model "Beheren met een Grote B" centrales genoemd wordt, is in AVB aangeduid als het primaire operationele proces. Beheren met een kleine b

Het model "Beheren met een kleine b" (zie [Kleine b]) geeft een nadere uitwerking van het beheermodel met een Grote B. Over de implementatie van de organisatie architectuur in de bestaande of toekomstige organisatie doet de organisatie architectuur geen uitspraken. Er is meer dan één mogelijke wijze waarop de essentiële organisatie architectuur kan worden geïmplementeerd. Eén daarvan kan een implementatie zijn volgens de opzet die is geschetst in het model "Beheren met een kleine b". Om te bepalen of de essentiële organisatiestructuur kan worden geïmplementeerd via het model "Beheren met een kleine b", wordt hieronder een samenvatting gegeven van dat model en wordt de relatie met de organisatie architectuur aangegeven.


37

Het model "beheren met een kleine b" geeft: 1. Een uitgewerkte invulling van de inhoudelijke taakvelden: - Verkeersmanagement - DVM -VK (Verkeerskunde) - DVM-IT (Informatie Technologie) op de niveaus: - Strategisch - Tactisch - Operationeel 2. Een scheiding van processen in: - Inhoudsprocessen - Coördinatie/besluitvormingsprocessen en de hieruit voortvloeiende rolverdeling tussen opdrachtgever en opdrachtnemer 3. Een voorkeursmodel voor het aanbrengen van organisatorische demarcaties in het DVM-beheer.


38

Schematisch ziet het model "beheren met een kleine b" eruit als in onderstaande figuur is aangegeven.

Figuur 11

Beheermodel Dynamisch Verkeersmanagement ("beheren met een kleine b")

Strategisch

mm

Tactisch

Operationeel: TAAKVELD OPERATIONEEL V M ^ TAAKVELD DVM-VK

TAAKVELD DVM-IT

Invulling van de taakvelden Het model "beheren met een kleine b" onderscheidt drie taakvelden: - Operationeel verkeersmanagement. Dit is in de essentiële organisatiestructuur terug te vinden in het primaire productieproces met de besturende functies en organisatie-eenheden: AVM, RVM/LVM, HRVMC/HLVMC, RWVL/LWVL - Dynamisch Verkeersmanagement - VK: In de essentiële organisatiestructuur zijn dit de ondersteunende verkeerskundige functies en organisatie-eenheden - Dynamisch Verkeersmanagement - IT: In de essentiële organisatiestructuur zijn dit de ondersteunende systeemtechnische functies en organisatie-eenheden


39

In het model "Beheren met een kleine b" is vastgesteld welke beheerproducten/diensten zijn te onderscheiden in het DVM-beheer, die een bijdrage leveren aan het samenhangend DVM-beheer. De volgende producten/diensten worden onderscheiden:

Tabel 11 Taakveld: Operationeel Producten/diensten in model "Kleine b" Beheersniveau: verkeersmanagement

DVM-VK

DVM-IT

Strategisch

Beleidsuitgangspunten: - Convenanten - Bestuurlijke en organisatorische kaders

Landelijke Regelstrategie

ICT en Systeembeleid

Tactisch

- Convenanten - VM-functie -TUC

• Verkeersservices • Maatregelen

-

Operationeel

- Regionale convenanten - Operationele Organisatie - Procedures, afspraken, richtlijnen

-

- Operationeel beheer

Regionale regelstrategie Regeltaktiek Scenario's Maatregelen

Tactisch IT beheer Systeem Modificatie Systeem Ontwikkeling Systeem testen

Om te zien, of een organisatie op basis van het model "Beheren met een kleine b" mogelijk conform is aan de organisatie architectuur, zal aangegeven moeten worden welke functies en organisatie-eenheden van de essentiële organisatiestructuur de producten en diensten, die genoemd zijn in Tabel 11a, zullen leveren. Nevenstaande tabel geeft daarvan een overzicht door functies en bedrijfseenheden te identificeren op basis van het niveau en het taakveld.


40

Tabel 11a Relatie tussen producten van model "Kleine b" en de essentiële organisatiestructuur

Product/service in "kleine b"

Functie/Organisatie-eenheid in de OA

Strategisch niveau: Algemeen VerkeersManager Operationeel VA/I: Beleidsuitgangspunten: - Convenanten - Bestuurlijke en organisatorische kaders DMV-VK: - Landelijke Regelstrategie


DMV-IT: - ICT en Systeembeleid


Tactisch niveau:

Operationeel VA/I. - Convenanten - VM-functie -TUC

Regionaal en Landelijk VerkeersManager

DVM-VK: - Verkeersservices - Maatregelen

Regionaal en Landelijk Manager VerkeersKunde

DMV-IT: - Tactisch IT beheer - Systeem Modificatie - Systeem Ontwikkeling - Systeem testen

Regionaal en Landelijk SysteemManager, Dienstenbeheer, Ontwikkeling en Implementatie

Operationeel niveau:

Operationeel VA/I: - Regionale convenanten - Procedures, afspraken, richtlijnen

Regionaal en Landelijk VerkeersManager

- Operationele Organisatie

Hoofd Regionale en Landelijke VerkeersManagementCentrale

DMV-VK: - Regionale regelstrategie - Regeltactiek - Scenario's - Maatregelen

Regionaal en Landelijk Manager VerkeersKunde

DMV-IT: - Operationeel beheer

Systeembeheer

Coördinatie/besluitvorm ingsvlakken In het model "Beheren met een kleine b" worden op elk niveau coördinatie/besluitvormingsvlakken onderkend, waar management opdrachten verleent aan inhoudelijke deskundigen (opdrachtnemers), die verantwoordelijk zijn voor het invoeren en beheren van de producten in de drie taakgebieden. De besluitvormingsvlakken in het model zijn in de organisatie architectuur opgenomen door middel van lijnverantwoordelijkheden. Bij de implementatie van de organisatie architectuur zal nadere inhoud daaraan moeten worden gegeven. Organisatorische demarcaties

Deze toewijzing van rollen en verantwoordelijkheden aan bestaande organisatie-eenheden valt buiten het bestek van de organisatie architectuur. Aangezien de organisatie architectuur onafhankelijk is van bestaande en toekomstige organisatiestructuren, kan implementatie plaatsvinden op de in model "Beheren met een kleine b" voorgestelde wijze.


41

Conclusie

De conclusie is dat er een goede aansluiting is te onderkennen van de organisatie architectuur bij het model "Beheren met een kleine b" en dat een mogelijke implementatie van de organisatie architectuur plaats zal kunnen vinden volgens het model "Beheren met een kleine b".

6.2 Systeemontwikkeling en -beheer

Verantwoordelijkheid voor systeemontwikkeling en -beheer ligt in de organisatie architectuur bij landelijke en regionale verkeersbeheersing. Dat hoeft niet te betekenen, dat men ook op eigen gelegenheid systemen gaat ontwikkelen of beheren. In essentie bestaan daarvoor drie mogelijkheden. Men doet het lokaal, centraal of via een bepaald samenwerkingsverband (collectief). Systeemontwikkeling

Dat onderscheid is vooral voor systeemontwikkeling van belang. Lokaal Dit betreft in de regel (kleinere) systemen, die slechts binnen een verantwoordelijkheidsgebied vallen (landelijk, een regio, etc). Ook (kleinere) lokale nieuwe toepassingen kunnen daartoe behoren. Centraal Voor (grote) systemen die moeten voldoen aan hoge eisen wat betreft landelijke uniformiteit ligt het voor de hand om die systemen centraal te laten ontwikkelen in een Centrale Ontwikkelingsorganisatie. Collectief Voor (middelgrote) systemen, die binnen twee of meer verantwoordelijkheidsgebieden vallen en/of aan minder hoge eisen hoeven te voldoen wat betreft landelijke uniformiteit kunnen betrokkenen er naar streven om bepaalde zaken collectief aan te pakken via een Collectieve Ontwikkelingsorganisatie. Centrale en Collectieve Ontwikkelingsorganisatie (CCOO) Beide ontwikkelingsorganisaties kunnen in de praktijk waarschijnlijk goed worden gecombineerd. In deze -interne- organisatie is dan (schaarse) systeemontwikkelingsexpertise en capaciteit samengebracht voor centrale en collectieve systeemontwikkeling. SysteemBeheer Collectieve Beheerorganisatie (CBO) Vooral voor het beheren van alle genoemde soorten systemen kan het al snel zinvol zijn gebruik te maken van een Collectieve Beheerorganisatie, omdat zo'n organisatie in de regel goed is toegerust voor het maken van maatwerkafspraken over het te leveren dienstenniveau (service-level agreement).


42

Applicaties en Technische Infrastructuur

In de organisatie architectuur wordt al een duidelijk onderscheid gemaakt in activiteiten die gericht zijn op applicaties en activiteiten die gericht zijn op de technische infrastructuur, waar die applicaties gebruik van maken. Bij het bouwen-onder-architectuur is het vooral van belang dat ontwikkeling en beheer van de technische infrastructuur goed worden aangestuurd. Men kan dit overlaten aan een collectieve ontwikkelings- en beheerorganisatie, maar er is ook goede reden om dit centraal te willen regelen. Implementatiemogelijkheden De genoemde mogelijkheden leiden tot een aantal "meest voor de hand liggende" varianten voor de implementatie van de organisatie architectuur op het gebied van systeemontwikkeling en -beheer.

applicaties

ontwikkeling beheer ontwikkeling beheer

technische infrastructuur


43

lokaal

collectief

centraal

x

x x

x x x


44

Bijlage 1. Identificeren van activiteiten

Deze Bijlage zet uiteen, hoe de identificatie van activiteiten uit de verkeerskundige architectuur, de applicatie architectuur en de architectuur van de technische infrastructuur heeft plaatsgevonden. 7.1 Identificatie van activiteiten die samenhangen met de Verkeerskundige Architectuur Het verkeerskundig lagenmodel

De basis voor de verkeerskundige architectuur wordt gevormd door het verkeerskundig lagenmodel, waarin de volgende lagen worden onderscheiden: - Beleidsdoelstellingen

- Regelstrategieën - Regeltactieken - Regelscenario's

- Maatregelen - Signalen Onderstaand is per laag een korte beschrijving gegeven van de processen die met de lagen samenhangen en de activiteiten die aan de hand daarvan zijn geïdentificeerd.

Tabel 12 Processen en activiteiten gerelateerd aan het verkeerskundige lagenmodel

Laag van het verkeerskundig Beschrijving van het proces

Op strategisch niveau wordt ook de verkeerskundige architectuur opgesteld.

Beleidsdoelstellingen

Het opstellen van beleid valt buiten de verkeerskundige architectuur. Wel moeten beleidsuitgangspunten worden verzameld voor het opstellen van regelstrategieën.


Resulterende activiteit

lagenmodel Architectureren van de Verkeerskundige Architectuur Verzamelen van Beleidsuitgangspunten

Regelstrategieën

Regelstrategieën worden opgesteld, gebaseerd op de beleidsdoelstellingen. Een gekwantificeerde vorm van regelstrategieën is het referentiekader.

Opstellen van Regelstrategieën en Referentiekader

Regeltactieken

Regeltactieken hebben in het algemeen de vorm van "als ... dan....". Ze worden opgesteld in een handboek, waarbij onderscheid gemaakt wordt naar landelijke en regionale tactieken. Integratieregels beschrijven welke combinaties van tactieken wel of niet mogelijk zijn, welke prioriteiten worden gesteld, en dergelijke.

Opstellen Handboek Regeltactieken

45

Opstellen Integratieregels Regeltactieken

Laag van het verkeerskundig Beschrijving van het proces lagenmodel


Resulterende activiteit

Scenario's

Een integraal regelscenario beschrijft de Voorbereiden samenhang van maatregelen, die worden Operationele ingezet in bepaalde situaties. In principe Verkeersbeheersing is het een regeltactiek, die is uitgewerkt voor de locale situatie. Deze scenario's worden vooraf opgesteld teneinde sturing te kunnen geven aan de operationele verkeersbeheersing. De integrale regelscenario's worden Off-line Bepalen van voorbereid wanneer de situatie zich nog Integrale Regelscenario's niet heeft voorgedaan. Aangezien integrale regelscenario's ook Coördineren van uitgewerkt worden voor het reageren op Ondersteuning (van WIU, WIU, IM, EM en dergelijke, is overleg en IM, EM, OB, en LOV) feedback met betrokken partijen, zoals uitvoerders, politie, event organisatoren, noodzakelijk. Een en ander wordt vastgelegd in het Opstellen Handboek handboek regelscenario's. Regelscenario's Wanneer de regelscenario's worden toe- Uitvoeren Operationele gepast spreken we van on-line uitvoeren Verkeersbeheersing van de operationele verkeersbeheersing. Bepaald wordt eerste wat de verkeersMonitoren van de toestand is en het integrale regelscenario Verkeerssituatie wordt bewaakt. Afhandelen Integrale Vervolgens wordt het integrale regelscenario afgehandeld, waarbij ook Regelscenario's relevante derde partijen (politie, event organisatoren, en dergelijke) feedback krijgen en up-to-date worden gehouden.

Maatregelen

Het afhandelen van regelscenario's leidt Activeren van Maatregelen tot het activeren van maatregelen. en Signalen Op strategisch niveau wordt bepaald Ontwikkelen Maatregelen welke maatregelen ingezet zullen worden bij de dynamische verkeersbeheersing. Deze maatregelen worden beschreven en beheerd. De status van elke maatregel wordt bijgehouden (in ontwikkeling, operationeel, en dergelijke).

Signalen

Het activeren van een maatregel, kan inhouden dat een aantal signalen wordt geactiveerd. Een maatregel kan zijn: "afsluiten rijstrook", terwijl de signalen die worden geactiveerd zijn:"verdrijfpijl" plus "rood kruis". Voor het bepalen van de organisatie architectuur is het niet nodig een onderscheid te maken tussen maatregelen en signalen.

Algemeen

Bij het gehele verkeersbeheersingsproces Inwinnen en Beheren van dienen verkeersrelevante gegevens te Gegevens worden verzameld en beheerd.

46

Het Model van de Regionale Operationele Verkeersbeheersing

Voor de laag Scenario's is een gedetailleerde analyse gepleegd van alle functies en data stores, gepresenteerd in het Document Verkeersbeheersingsfuncties. (Zie [HBG 0016]). Om vast te stellen of deze verkeersbeheersingsfuncties worden gedekt door de bovenvermelde activiteiten, is nader onderzoek gedaan. Allereerst zijn alle aan dit model ontleende functies vermeld in de volgende tabel:

Processen en functies in de Verkeerskundige Architectuur 1. Regionale Operationele Verkeersbeheersing 1.1. Sturen en Geleiden 1.1.1. Off-line bepalen integraal regelscenario 1.1.1.1. Kiezen integraal regelscenario 1.1.1.2. Off-line voorspellen 1.1.1.3. Off-line beoordelen integraal regelscenario 1.1.1.4. Off-line bepalen gewenst Sturen & Geleiden Regelscenario 1.1.2. On-line bepalen verkeerstoestand 1.1.2.1. Gegevens verkrijgen 1.1.2.2. On-line historie updaten 1.1.2.4. Schatten actuele toestand 1.1.2.5. On-line bewaken toestand 1.1.3. On-line bewaken integraal regelscenario 1.1.4. On-line afhandelen integraal regelscenario 1.1.4.1. On-line kiezen scenario 1.1.4.2. Scenario uitvoeren 1.1.4.3. On-line aanpassen integraal regelscenario 1.2. Ondersteunen Werk in Uitvoering 1.3. Ondersteunen Incident Management 1.4 Ondersteunen Verkeerskundige Objectbediening 1.5. Ondersteunen Verkeerskundige Objectbewaking 1.6. Ondersteunen Event Management 1.7. Ondersteunen Landelijke Verkeersbeheersing

Naast functies onderkent het model data stores. Van alle data stores is nagegaan, of ze door een functie in het model worden gegenereerd en/of gebruikt. Dit leidt tot het volgende onderscheid in data stores: - INTERNE DATA STORES: data stores, die door de in het model beschreven functies worden gecreëerd, en tevens door (andere) functies worden gebruikt - UITVOER DATA STORES: data stores, die door de in het model beschreven functies worden gecreëerd, maar niet worden gebruikt - INVOER DATA STORES: data stores, die niet door de in het model beschreven functies worden gecreëerd, maar wel gebruikt.


47

Tabel 13

Functies afgeleid uit externe data stores

Voor iedere uitvoer data store is; een functie benoemd, die de data gebruikt. Deze functie valt per definitie buiten het model en behoort niet tot de Regionale Operationele Verkeersbeheersing. Voor iedere invoer data store is een functie benoemd, die de data creëert. Ook deze creërende functie behoort niet tot de Regionale Operationele Verkeersbeheersing. Voor alle aldus geïdentificeerde functies is nagegaan, of ze tot het domein van de AVB behoren. Is dit niet het geval, dan worden die functies niet meegenomen in de verdere analyse. De aan de hand van de data stores geïdentificeerde functies staan vermeld in de volgende tabel, terwijl de daarop volgende tabel voor de compleetheid ook de interne data stores vermeldt.

EXTERNE DATA STORES:

Wordt gebruikt door ROV

Wordt gegenereerd door ROV

2. Functies afgeleid uit Externe Data Stores (voor zover niet al

functie in mode;

functie in model

geïdentificeerd)

Functies worden hier geïdentificeerd door te bepalen

OUTPUT DATA STORES:

welke functie deze data zal gebruiken. Immers, er was geen gebruikende verkeersbeheersingsfunctie in het model aangetroffen.

6. Aanstuurinformatie

x

2 . 1 . Activeer Maatregelen

8. Terugkoppeling WIU

x

Gebruik de teruggekoppelde informatie voor uitvoeren van WIU Gebruik de teruggekoppelde informatie voor uitvoeren van IM Gebruik de teruggekoppelde informatie voor uitvoeren van OB Gebruik de teruggekoppelde informatie voor uitvoeren van EM Gebruik de teruggekoppelde informatie voor uitvoeren van LOV

10. Terugkoppeling Incident Management

x

11. Terugkoppeling Object Bediening en Bewaking

x

15. Terugkoppeling Event Management

x

17. Terugkoppeling Landelijke Operationele Verkeersbeheersing

x

INPUT DATA STORES:

Deze functie zit niet in het model van de ROV, aangezien de ROV zich slechts beweegt op het regelscenario-niveau. Maatregelen zijn van een lager niveau. Geen AVB functie (het genereren van de terugkoppeling wel, maar deze functie is reeds onderkend als "Ondersteunen van W I U " ) . Geen AVB functie (het genereren van de terugkoppeling wel, maar deze functie is reeds onderkend als "Ondersteunen van I M " ) . Geen AVB functie (het genereren van de terugkoppeling wel, maar deze functie is reeds onderkend als "Ondersteunen van OB"). Geen AVB functie (het genereren van de terugkoppeling wel, maar deze functie is reeds onderkend als "Ondersteunen van EM").

LOV is een AVB functie, maar uit de analyse is geconcludeerd dat de functies van LOV vanuit organisatie architectuur oogpunt niet verschillen van ROV functies, die al zijn geïdentificeerd. Functies worden hier geïdentificeerd door te bepalen wat er gedaan moet worden om de data store te genereren. Immers, er was geen genererende verkeersbeheersingsfunctie in het model aangetroffen.

1. Referentiekader 2. Handboek Regelscenario's 3. Integratieregels 4. Verkeersdata 5. Verkeersgerelateerde data 7. Aanvraag WIU

x x

x

Creëer Aanvraag WIU

9. Aanvraag IM

x

Creëer Aanvraag IM

x x

2.2. Creëer referentiekader 2.3. Creëer Handboek Regelscenario's 2.4. Creëer Integratieregels 2.5. Genereer Verkeersdata 2.6. Genereer Verkeersgerelateerde data Geen AVB functie (het ontvangen van de aanvraag voor ondersteuning wel, maar dit is onderdeel van de functie "Ondersteunen van W I U " ) Geen AVB functie (het ontvangen van de aanvraag voor ondersteuning wel, maar dit is onderdeel van de functie "Ondersteunen van I M " )


48

EXTERNE DATA STORES:

Wordt gebruikt door ROV functie in mode;

Wordt gegenereerd door ROV functie in model

2. Functies afgeleid uit Externe Data Stores (voor zover niet al geïdentificeerd)

12. Aanvraag Objectbediening

Creëer Aanvraag Objectbediening

13. Aanvraag Objectbewaking

Creëer Aanvraag Objectbewaking

14. Aanvraag Event Management

Creëer Aanvraag EM

16. Aanvraag Landelijke Operationele Verkeersbeheersing 18. Maatregel Status

2.7. Creëer Aanvraag LOV naar Regio's

Geen AVB functie (het ontvangen van de aanvraag voor ondersteuning wel, maar dit is onderdeel van de functie "Ondersteunen van OB") Geen AVB functie (het ontvangen van de aanvraag voor ondersteuning wel, maar dit is onderdeel van de functie "Ondersteunen van OB") Geen AVB functie (het ontvangen van de aanvraag voor ondersteuning wel, maar dit is onderdeel van de functie "Ondersteunen van EM")

2.8. Genereer Maatregel Status

Aangezien er zowel genererende als gebruikende verkeersbeheersingsfuncties in het model zijn aangetroffen, leiden interne data stores niet de identificatie van nieuwe verkeersbeheersingsfuncties. Tabel14 Functies afgeleid van interne data stores De data stores zijn hier gemeld om de volledigheid te checken.

INTERNE DATA STORES:

Wordt gebruikt door ROV functie in model

1.1. Gewenst WIU Regelscenario 1.1.1.1. Keuze niveau 1.1.1.2. Gewenst S&G regelscenario 1.1.1.3. Voorspelde toestand 1.1.1.4. Beoordeling 1.1.2. Voorspellingsstatus 1.1.2.1. Onbewerkte verkeersgegevens 1.1.2.2. Actuele toestand 1.1.3. Integraal regelscenario 1.1.4. Maatregel state 1.1.4.1. "Geen keuze mogelijk"-trigger 1.1.4.2. Actueel scenario 1.2 Gewenst IM Regelscenario 1.3. Gewenst Object bedienings regelscenario 1.4 Gewenst Event Management Regelscenario 1.5 Gewenst LOV regelscenario 1.6 On-line toestand en afwijking 1.7. Terugkoppeling ondersteuning 1.8. Incident status 1.9. Object status 1.10. Geplande objectbediening 1.11. Historische verkeersgegevens 1.12. Potentiële incidenten 1.13. Geplande evenementen

x x x x x x x x x x x x x x x x x x x x x x x x


Wordt gegenereerd door ROV functie in model

Verkeersbeheersingsfunctie

reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds reeds

49

beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven beschreven

Tabel 15 Verkeerskundige activiteiten afgeleid van verkeersbeheersingsfuncties

Verkeerskundige activiteiten: 1. Architectureren van de Verkeerskundige Architectuur 2. Verzamelen van Beleidsuitgangspunten 3. Opstellen van Regelstrategieën en Referentiekader 4. Opstellen Handboek Regeltactieken 5. Opstellen Integratieregels Regeltactieken

Als check voor de compleetheid van het activiteiten overzicht, gebaseerd op het verkeerskundig lagenmodel, zijn de eerder vermelde verkeersbeheersingsfuncties afgezet tegen de geïdentificeerde activiteiten. Dit wordt getoond in onderstaande tabel.

cross-reference met uit ROV model afgeleide functies:

2.2. Creëer referentiekader 2.4. Creëer Integratieregels

6. Voorbereiden Operationele Verkeersbeheersing 6.1. Off-line Bepalen van Integrale Regelscenario's

1.1.1. Offline bepalen regelscenario 6.2. Coördineren van Ondersteuning 1.2. Onder(van WIU, IM, EM, OB, en LOV) steunen Werk in Uitvoering

6.3. Opstellen Handboek Regelscenario's

1.3. Ondersteunen Incident Management

1.4. Ondersteunen Verkeerskundige Objectbediening

1.5. Ondersteunen Verkeerskundige Objectbewaking

1.6. Ondersteunen Event Management

1.7. Ondersteunen Landelijke Verkeersbeheersing

2.7. Creëer Aanvraag LOV naar Regio's

2.3. Creëer Handboek Regelscenario's

7. Uitvoeren Operationele Verkeersbeheersing 7.1. Monitoren van de Verkeerssituatie 1.1.2. On1.1.3. Online bepalen line bewaken verkeersintegraal toestand regelscenario 7.2. Afhandelen Integrale 1.1.4. On-line Regelscenario's afhandelen regelscenario 7.3. Activeren van Maatregelen 2.1. Activeer en Signalen Maatregelen 8. Ontwikkelen Maatregelen 9. Inwinnen en Beheren van Gegevens 2.8 Genereer 2.5. Genereer 2.6. Genereer Maatregel Verkeersdata VerkeersStatus gerelateerde data

De conclusie is dat alle functies die zijn afgeleid uit de laag Regelscenario's, zijn begrepen in de geïdentificeerde activiteiten.


50

7.2 Identificatie van activiteiten die samenhangen met de Applicatie Architectuur

Uitgangspunt voor de identificatie van deze activiteiten is het overzicht van generieke componenten van de applicatie architectuur, zoals weergegeven in onderstaande tabel. De componenten zijn eerst geclassificeerd naar componenten die functionaliteit van de applicaties beschrijven enerzijds en componenten die een database weergeven anderzijds. Bij iedere component is voorts een omschrijving gezocht, die de activiteit weergeeft, die van de betreffende component gebruik maakt. Voor de volledigheid zijn in de tabel ook de verkeerskundige activiteiten genoemd, die samenhangen met een aantal componenten.


51

Tabel 16 Activiteiten gerelateerd aan componenten uit de Applicatie Architectuur

Generieke Component uit de Applicatie Architectuur

Functie of Database Component

Beschrijving

OperatorlnteractieComp

f

Deze component verzorgt de interactie met een menselijke bedienaar van het VB-systeem.

AuthorisatieBeheerComp

f

Met behulp van deze component kan de configuratie van een OnlineInzetBepaler behorende bij een operatorwerkplek worden ingevuld.

SysteemParametriserenComp

f

Met behulp van deze component kan een tuningparameter in een component worden gewijzigd.

BeheerOnderhoudsstatusComp

f

Met behulp van deze component kan de onderhoudsstatus van een component worden gewijzigd.

VB-systeemPresentatieComp

f

Deze component kan de dynamische toestand van het verkeer in het wegennet presenteren.

SysteemConfigurerenComp

f

Met behulp van deze component kan een systeembeheerder configuratiegegever invoeren voor een component.

SysteemlogRapportageComp

f

Met behulp van deze component kan een systeembeheerder rapportage maken uit de SysteemlogDataBase.

ToestandSchatterComp

f

Een component van dit type is verantwoordelijk voor het schatten van verkeerstoestandgegevens uit verkeersgegevens.

InzetBepalerComponent

f

Is verantwoordelijk voor de bepaling welke maatregelen geactiveerd moeten worden en welke moeten worden gedeactiveerd.

MaatregelActivatorComponent

f

Deze component is verantwoordelijk voor het activeren en deactiveren van maatregelen in het online systeem.

Vbmaatregelcomponent

f

VBmaatregelcomponenten zijn regelaars. Componenten van dit type zijn verantwoordelijk voor het beïnvloeden van het verkeer op een locatie.

Monitorcomponent

f

Componenten van dit type zijn verantwoordelijk voor het inzamelen van verkeersgegevens voor een locatie en het beschikbaarstellen ervan.

SensorComponent

f

Componenten van dit type maken fysiek contact met een voertuigstroom ten behoeve van de inzameling van verkeersgegevens.

ActuatorCoordinatorComponent

f

Deze component is verantwoordelijk voor het doorgeven van verkeersbeheersing informatie uit verschillende verkeersbeheersingsmaatregelen naar het verkeer.

SignaalgeverComponent

f

Deze component is verantwoordelijk voor het daadwerkelijk verspreiden van verkeersbeheersingsinformatie naar het verkeer, met behulp van signaalgevers dit fysiek contact maken met het verkeer.

VerkeersToestandBewakenComp

f

Deze component presenteert voorspelde en historische gegevens ten behoeve va de bewaking op de voortgang van verkeersbeheersing.

ScenarioVergelijkerComp

f

Deze component in het offline systeem kan de geschatte effecten van scenario's met elkaar vergelijken.

ScenarioMakerComponent

f

Met behulp van deze component kan een verkeersoperator een scenario generen

VerkeersVoorspellerComp

f

Deze component berekent voorspelde verkeersgegevens.

GrafischeSystobjectenDataBase

d

Deze database bevat de grafische objecten voor grafische presentatie van dynamische verkeersobjecten.

Wegen kaarten DataBase

d

GrafischeVerkObjectenDatabase

d

Deze database bevat een beschrijving van de topologie van het wegennet en alle objecten om de wegenkaart te kunnen presenteren. Deze database bevat een overzicht van de componenten in het VB-systeem en hun grafische gegevens.


52

Gerelateerde Activiteit (inclusief Verkeerskundige activiteiten)

Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Beheersen van de Beveiliging van Applicaties en Applicatie Componenten

Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Onderhouden van Applicaties en Applicatie Componenten

Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Beheren van de Configuratie van Applicaties en Applicatie Componenten








Verkeersbeheersi ngsf u nctie




Verkeersbeheersingsfunctie Verkeersbeheersingsfunctie

Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten.


53

Generieke Component uit de Applicatie Architectuur

Functie of Database Component

Beschrijving

SysteemlogDatabase

d

Deze database bevat alle status- en foutmeldingen uit de componenten in het online systeem.

SysteemConfiguratieDataBase

d

Deze database bevat alle configuratiegegevens voor de componenten in het online systeem.

ScenarioDataBase

d

Deze data base bevat de scenario's voor het online en het offline deel van het VB-systeem.

VerkeersToestandDataBase

d

Deze database bevat de actuele verkeerstoestandsgegevens, ten behoeve van he uitvoeren van scenario's.

TactiekenDataBase

d

Deze database bevat gegevens over tactieken.

Maatregel DataBase

Deze database bevat gegevens over maatregelen.

VerkeersgegevensDataBase

d

Deze database bevat een overzicht van verkeersgegevens voor en groot aantal locaties in een gebied.

VerkeersVoorspellingenDataBase

d

Deze database bevat gegevens over weersvoorspellingen.

IncidentenDataBase

d

Deze database bevat gegevens over incidenten in het wegennet.

WegbeheerDataBase


Deze database bevat gegevens over wegwerkzaamheden in het wegennet.

54

Gerelateerde Activiteit (inclusief Verkeerskundige activiteiten)


Beheren van de Configuratie van Applicaties en Applicatie Componenten

Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten.


55

Voorts is een aantal aspecten van de applicatie architectuur geanalyseerd, die leiden tot de identificatie van activiteiten. Deze aspecten zijn: - Gebruik van de applicatie architectuur - Kwaliteitskenmerken van systemen - Actoren in het model - Integratie aspecten - Systeem ontwikkeling - Beheer van de applicaties.

Tabel 17

Voor elk van de bovengenoemde aspecten is een activiteit benoemd, die ermee samenhangt. Het resultaat is weergegeven in onderstaande tabel.

Activiteiten afgeleid van overige

aspecten van de Applicatie Architectuur

Activiteiten afgeleid uit overige aspecten van de Applicatie Architectuur (AA)

Gebruik van de AA

Aansturing van ontwikkelingen en realisatie

Aanschaf van componenten

Realisatie van componenten

Gebruiker

Belang

RWS-AVV

afbakening van projecten, afstemming van projecten, eensgezindheid tussen ontwikkelaars, internationale afstemming.

RWS-RD's

eensgezindheid tussen RD's, afbakening van verantwoordelijkheden en vrijheid van handelen tijdens realisatie.

Industrie

goede afbakening van componenten en vrijheid van keuze voor toepassing van specifieke technologie bij realisatie van componenten.

Kwaliteitskenmerken van Systemen

Opmerkingen

Bruikbaarheid

De genoemde aspecten - bedienbaarheid, juistheid (consistentie, correctheid), duidelijkheid, en inzichtelijkheid - hebben te maken met het architectureren van het systeem De genoemde aspecten - operator-presentatie, systeem-evaluatie, beheer onderhoudsstatus, autorisatiebeheer, systeem parametriseren, en operator traininn hebben te maken met het ontwikkelen van het systeem

Onderhoudbaarheid

De genoemde aspecten - flexibiliteit (instelbaarheid), beheersbaarheid, corrigeerbaarheid, testbaarheid, wijzigbaarheid, systeem configureren, storingsbeheer, versiebeheer, kaart-presentatie beheer, database beheer en remote diagnose - hebben te maken met het onderhoud van het systeem

Overige systeemeisen

De genoemde aspecten - bedrijfszekerheid, beschikbaarheid, robuustheid (integriteit, bestendigheid), degradatiemogelijkheid (graceful degradation), herstelbaarheid, veerkracht (herstartbaarheid, recovery) en beveiligbaarheid hebben te maken met het ontwerp van het systeem, wat gezien wordt als onderdeel van het ontwikkelen

Actoren in het Model

Opmerkingen

De in de AA genoemde Actoren met de hieronder vermelde definities, hoeven ni overeen te komen met organisatorische eenheden die in de OA zullen worden onderscheiden. Kaart Leverancier

Een KaartLeverancier is een externe organisatie, die een update toelevert voor et elektronische kaart van het wegennet.

Operator

De operator is een menselijke gebruiker van het systeem, die interacties aangaat middels bedieningskommando's.


56

Gerelateerde Activiteit Dit soort activiteit wordt toegevoegd in het fysieke deel van de OA

Dit soort activiteit wordt toegevoegd in het fysieke deel van de OA

Dit soort activiteit wordt toegevoegd in het fysieke deel van de OA Gerelateerde Activiteit


Assembleren van Applicaties met behulp van Applicatie Componenten


Assembleren van Applicaties met behulp van Applicatie Componenten

Gerelateerde Activiteit


Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten.


57

Activiteiten afgeleid uit overige aspecten van de Applicatie Architectuur (AA) Actoren in het Model

Opmerkingen

Systeembeheerder

Een systeembeheerder communiceert met het systeem voor het gebruik van de technische beheerfuncties.

Verkeersoperator

De verkeersoperator en de Wegverkeersleider communiceren met het systeem voor het gebruik van de VB-functies.

Overige aspecten

Opmerkingen

Integratie

Integratie van applicaties is van groot belang. Wanneer nieuwe applicaties ter beschikking worden gesteld, dienen de integratie aspecten van deze applicaties onderling en met de bestaande applicaties in ogenschouw genomen te worden. Het ontwikkelen van applicatie componenten, hetzij onder eigen beheer, hetzij in de markt. In het laatste geval zal het ontwikkelen van componenten inhouden het verwerven door selectie en koop. Deze activiteiten worden noch in de applicatie architectuur zelf, noch bij het beheer (ITIL) behandeld. Het betreft activiteiten, die wel moeten worden geïdentificeerd.

Componenten Ontwikkeling

Het ontwikkelen van applicaties, inhoudend specificeren, ontwerpen, bouwen en testen, wordt noch in de applicatie architectuur zelf, noch bij het beheer (ITIL) behandeld. Het betreft activiteiten, die wel moeten worden geïdentificeerd.

Systeemontwikkeling

Analyse van ITIL processen

In de tweede helft van de tachtiger jaren werd, door toenemende zelfstandigheid en kostenbewustzijn van rekencentra in Engeland, gestart met de ontwikkeling van een methode voor gestructureerd beheer van automatiseringsmiddelen. Dit heeft geresulteerd in de IT Infrastructure Library, kortweg ITIL. ITIL is ontwikkeld door de Engelse standaardisatie-organisatie CCTA en bestaat uit een reeks boeken, ofwel modulen, waarin de processen in een rekencentrum worden beschreven, leder boek geeft aan hoe één proces moet worden ingericht en wat de relaties met de andere processen zijn. Een en ander is gebaseerd op ervaringen in een groot aantal (overheids-) projecten in en rond rekencentra. ITIL spreekt hierbij van 'best practices'. Deze best practices zijn op de volgende wijze gegroepeerd: -


Management Service delivery (tactische processen) Service support (operationele processen) Computer operations Software support Networks Office environment Environment management Environment strategy

58

Gerelateerde Activiteit Onderhouden van Applicaties en Applicatie Componenten.

Het bedienen van de applicaties is manier van uitvoering van verkeerskundige activiteiten en leidt niet tot de identificatie van applicatie-gerelateerde activiteiten. Gerelateerde Activiteit Integreren van Applicaties en Applicatie Componenten.

Verwerven van Applicatie Componenten.

Assembleren van Applicaties met behulp van Applicatie Componenten.

Het aantal processen en aandachtsgebieden dat inmiddels is beschreven, is opgelopen tot ruim veertig. Alle beschreven processen zijn uiteindelijk terug te brengen tot 10 essentiële ITIL processen op het gebied van Service Delivery (tactisch) en Service Support (operationeel). Voor de organisatie architectuur worden de volgende ITIL processen relevant geacht: - Availability Management (Beschikbaarheidsbeheer) - Capacity Management (Capaciteitsbeheer) - Change Management (Wijzigingsbeheer) - Configuration Management (Configuratiebeheer) - Contingency Planning (Calamiteitenbeheersing) - Help Desk (Incidentbeheer) - Problem Management (Probleembeheer) - Service Level Management (Dienstenniveaubeheer) - Software Control and Distribution (Software Versiebeheer) - Security Management (Beveiligingsbeheer)


59

Deze processen hebben geleid tot het onderkennen van activiteiten die door de organisatie uitgevoerd moeten worden om de technische ondersteuning van de verkeersbeheersing efficiënt te laten verlopen. In de onderstaande tabel zijn deze activiteiten benoemd.

ITIL Proces

Beschrijving

Gerelateerde Activiteit m.b.t. Applicatie Architectuur

Availability Management (Beschikbaarheidsbeheer)

Beschikbaarheidsbeheer is het proces dat, ten behoeve van een met de opdrachtgever overeengekomen optimale beschikbaarheid van IT-diensten, de juiste inzet van middelen, methoden en technieken waarborgt.

Waarborgen van de Beschikbaarheid van Applicaties en Applicatie Componenten

Capacity Management (Capaciteitsbeheer)

Capaciteitsbeheer is het proces dat, ten behoeve van de met de opdrachtgever overeengekomen prestaties, zorg draagt voor een optimale inzet van IT-middelen (nu en in de toekomst).

Waarborgen van de Capaciteit van Applicaties

Change Management (Wijzigingsbeheer)

Het doorvoeren van alle noodzakelijke wijzigingen met minimale of bewust aanvaarde risico's voor de IT-dienstverlening.

Beheersen van de Wijzigingen in Applicaties en Applicatie Componenten

Configuration

Het uitvoeren van beheer van IT componenten ten behoeve van een Beheren van de Configuratie van

Management (Configuratiebeheer)

efficiënte en effectieve IT-dienstverlening.

Applicaties en Applicatie Componenten

Contingency Planning (Calamiteitenbeheersing)

Calamiteitenbeheersing is het proces dat zorg draagt voor afdoende technische, financiële en organisatorische voorzieningen ten behoeve van het waarborgen van de in de DNO overeengekomen continuïteit van de IT-dienstverlening bij calamiteiten.

Waarborgen van de Beschikbaarheid van Applicaties en Applicatie Componenten

Help Desk (Incidentbeheer)

Het bieden van Istelijns ondersteuning bij incidenten en vragen om Ondersteunen van de Bediening van zo spoedig mogelijk de IT-dienstverlening te herstellen en de klanten Applicaties optimaal te ondersteunen bij het gebruik van de IT-dienstverlening.

Problem Management (Probleembeheer)

Het minimaliseren van de impact van problemen op de IT-dienstverlening en het voorkomen van problemen.


Service Level Management Dienstenniveaubeheer is het proces dat, door een goed samenDit soort activiteit wordt toegevoegd (Dienstenniveau beheer) werkingsverband tussen aanbieder en afnemer, zorg draagt voor het in het fysieke deel van de OA overeenkomen en bewaken van een optimaal niveau van IT-dienstverlening. De afspraken worden vastgelegd in een geschreven overeenkomst = contract. Software Control and Distribution (Software Versiebeheer)

Het op effectieve en efficiënte wijze beheren van de programmatuur Waarborgen van de Beschikbaarheid van en de distributie van programmatuur. Applicaties en Applicatie Componenten

Security Management (Beveiligingsbeheer)

Het organiseren en uitvoeren van het management van beveiliging Beheersen van de Beveiliging van van de IT infrastructuur, vanuit het gezichtspunt van een IT manager. Applicaties en Applicatie Componenten

Samenvattend hebben de analyses geleid tot het identificeren van de volgende activiteiten aan de hand van de applicatie architectuur: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13.


Architectureren van de Applicatie Architectuur Verwerven van Applicatie Componenten Assembleren van Applicaties met behulp van Applicatie Componenten Integreren van Applicaties en Applicatie Componenten Implementeren van Applicatie Componenten Implementeren van Applicaties Waarborgen van de Beschikbaarheid van Applicaties en Applicatie Componenten Waarborgen van de Capaciteit van Applicaties Beheren van de Configuratie van Applicaties en Applicatie Componenten Beheren van de Beveiliging van Applicaties en Applicatie Componenten Beheersen van de Wijzigingen in Applicaties en Applicatie Componenten Onderhouden van Applicaties en Applicatie Componenten Ondersteunen van de Bediening van Applicaties

61

7.3 Identificatie van activiteiten die samenhangen met de Architectuur van de Technische Infrastructuur

De identificatie van bovengenoemde activiteiten heeft plaatsgevonden aan de hand van de documentatie van de architectuur van de technische infrastructuur, die beschreven is als een stapsgewijze benadering om tot de implementatie van de technische infrastructuur te komen. Voor elk van deze stappen zijn relevante activiteiten benoemd. Veel van deze activiteiten waren ook reeds geïdentificeerd bij de analyse van de applicatie architectuur en de daar gevonden activiteiten hebben mede als basis gediend voor het bepalen van de uiteindelijke lijst met activiteiten. In onderstaande tabel is een en ander weergegeven:

Omschrijving

Gerelateerde Activiteit

Ontwerp technische infrastructuur: Functioneel ontwerp Technisch ontwerp Kies technologie componenten: Onderzoek markt Set standaards en criteria Maak keuze Implementeer technologie componenten: Configuratie beheer Service Level management Change management Onderhoud technologie componenten: Configuratie beheer Change management Software control en distribution

Ontwerp de Technische Infrastructuur Ontwerp de Technische Infrastructuur Ontwerp de Technische Infrastructuur Ontwerp Technische Infrastructuur Componenten Ontwerp Technische Infrastructuur Componenten Ontwerp Technische Infrastructuur Componenten Ontwerp Technische Infrastructuur Componenten Ontwikkel het Technisch Systeem Beheer de Configuratie van het Technisch Systeem Maak Afspraken over Dienstenniveaus Beheers de Veranderingen in het Technisch Systeem Onderhoud het Technisch Systeem Beheer de Configuratie van het Technisch Systeem Beheers de Veranderingen in het Technisch Systeem Waarborg de Beschikbaarheid van het Technisch Systeem Onderhoud het Technisch Systeem Waarborg de Capaciteit van het Technisch Systeem Gebruik de Technische Infrastructuur Gebruik de Technische Infrastructuur Gebruik de Technische Infrastructuur

Probleembeheer Capaciteitsbeheer Lever services aan AA Computer Operations Netwerk Operations


62

De relatie tussen relevante ITIL processen en activiteiten die zijn ontleend aan de Technische Infrastructuur is in onderstaande tabel weergegeven:

ITIL Proces

Gerelateerde Activiteit m.b.t. Technische Infrastructuur

Availability Management (Beschikbaarheidsbeheer)

Waarborgen van de Beschikbaarheid van de Technische Infrastructuur en Infrastructuur Componenten

Capacity Management (Capaciteitsbeheer)

Waarborgen van de Capaciteit van de Technische Infrastructuur

Change Management (Wijzigingsbeheer)

Beheersen van de Wijzigingen in de Technische Infrastructuur en Infrastructuur Componenten

Configuration Management (Configuratiebeheer)

Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten

Contingency Planning (Calamiteitenbeheersing)


Help Desk (Incidentbeheer) Leidt niet tot activiteiten identificatie"' Problem Management (Probleembeheer) Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten

Service Level Management (Dienstenniveaubeheer)

Dit soort activiteit wordt toegevoegd in het fysieke deel van de OA

Software Control and Distribution (Software Versiebeheer)


Security Management (Beveiligingsbeheer)

Beheersen van de Beveiliging van de Technische Infrastructuur en Infrastructuur Componenten

Samenvattend zijn de volgende activiteiten geïdentificeerd aan de hand van de technische infrastructuur: 1. 2. 3. 4. 5. 6. 7. 8. 9. 10.

Noten


Architectureren van de Architectuur van de Technische Infrastructuur Verwerven van Infrastructuur Componenten Ontwikkelen van de Technische Infrastructuur Integreren van de Technische Infrastructuur Implementeren van de Technische Infrastructuur Waarborgen van de Beschikbaarheid van de Technische Infrastructuur en Infrastructuur Componenten Waarborgen van de Capaciteit van de Technische Infrastructuur Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten Beheren van de Beveiliging van de Technische Infrastructuur en Infrastructuur Componenten Beheersen van de Wijzigingen in de Technische Infrastructuur en Infrastructuur Componenten Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten

4) In het geval van de technische infrastructuur worden de services niet rechtstreeks door eindgebruikers afgenomen, maar door applicaties. Activiteiten op het gebied van incidentbeheer zullen dan ook niet op het vlak liggen van ondersteunen van het gebruik, maar meer op het vlak van systeem onderhoud, beschikbaarheidsbeheer en dergelijke.

63


64

Bijlage 2. Het L-PASO model

Het L-PASO model van Dietz is een middel om ondersteunende activiteiten te beschrijven bij informatie-intensieve bedrijfsprocessen, zoals het uitvoeren van verkeersbeheersing. Het model is geadopteerd door de Vereniging van Register Informatici als standaardmodel voor de beschrijving en professionalisering van het werkgebied informatica. Het L-PASO model onderscheidt een aantal aspecten, waarvan twee voor de classificatie op het logisch niveau van de organisatie architectuur voldoende worden geacht, namelijk systeemsoorten en activiteitensoorten. Systeemsoorten zijn: bedrijfsproces, informatiesysteem en infrastructuursysteem. Activiteitensoorten zijn: architectureren, ontwikkelen, implementeren en beheren. Systeemsoorten

Het L_PASO model onderscheidt de volgende systeemsoorten: - Bedrijfsproces; gedefinieerd als een proces in een organisatie, dat gericht is op het leveren van een bepaald bedrijfsproduct. - Informatiesysteem; gedefinieerd als een systeem voor de inhoudelijke bewerking van gegevens. - Infrastructuursysteem; gedefinieerd als een systeem voor de representatie van gegevens in de vorm van binaire data, alsmede de opslag, het transport en de bewerking daarvan. Deze infrastructuursystemen vormen de bouwstenen voor de ICT-infrastructuur. Activiteitensoorten

Het L-PASO model onderscheidt vier activiteitensoorten, die worden verricht met betrekking tot de drie systeemsoorten: - Architectureren; betreft het concipiëren van (deel)architecturen. Dit is gericht op het stileren van de functie en de constructie van systemen van een bepaalde soort. - Ontwikkelen; inhoudende het specificeren, ontwerpen, bouwen en testen van een systeem. - Implementeren; zijnde het in gebruik stellen van een systeem, met inbegrip van het voorbereiden en het veranderen van de omgeving, waarin het systeem moet gaan fungeren. - Beheren; zijnde het in bedrijf houden van een systeem. Dit betreft is essentie twee soorten activiteiten: - Het werkend en beschikbaar houden van het systeem. - Het veranderen van het systeem, gericht op het verbeteren van de functie of de constructie van het systeem. Om het hele stelsel van systemen voortdurend aan te kunnen passen aan zich wijzigende omstandigheden bestaat er natuurlijk samenhang tussen de activiteitensoorten.


65

Deze samenhang kan als volgt worden weergegeven.

welke activiteiten

Figuur 12

Samenhang van Activiteiten in het L-PASO Model

waarop gericht het systeem

I een | deelsysteem

Elke activiteitensoort heeft een eigen interne dynamiek, weergegeven met de cirkels en de pijlen in de cirkels. Het L PASO model toegepast op verkeersbeheersing

Het bedrijfsproces bij verkeersbeheersing is "uitvoeren verkeersbeheersing". Ondersteuning is gericht op het inrichten en beheren van het bedrijfsproces, het informatiesysteem en het infrastructuursysteem (het "neerzetten"). Voor verkeersbeheersing kunnen nu duidelijk twee verschillende vormen van ondersteuning worden onderkend. De verkeerskundige ondersteuning is gericht op het inrichten en beheren van het bedrijfsproces "uitvoeren verkeersbeheersing". De systeemtechnische ondersteuning is gericht op het inrichten en beheren van het technische systeem, dat bestaat uit applicaties (het informatiesysteem) en technische infrastructuur (het infrastructuursysteem).


66

Verkeerskundige ondersteuning

Verkeerskundige ondersteuning betreft het beschikbaar stellen en beheren van regelstrategieën, regeltaktieken, scenario's, maatregelen en signalen. De produkten van deze ondersteuning betreffen vooral stelsels van afspraken die op papier worden vastgelegd. Er hoeft daarbij niet zo'n duidelijk onderscheid te worden gemaakt in "ontwikkelen" en "implementeren". Zijn de afspraken eenmaal gemaakt en vastgelegd, dan zijn daarmee de scenario's etc. ook geïmplementeerd. Dan zijn de systemen er nog niet om de scenario's e.d. uit te voeren, maar dat valt onder systeemtechnische ondersteuning. Voor verkeerskundige ondersteuning kan zodoende een beperkt model van Dietz volstaan.

welke activiteiten

Figuur 13

Samenhang van Activiteiten voor verkeerskundige ondersteuning

waarop gericht het bedrij fs proces

1 een deel van het bedrij fs proces


67

Systeemtechnische ondersteuning

Bij het "onder architectuur" bouwen en verbouwen van het grote en technisch complexe technische systeem voor verkeersbeheersing vervult "systeemintegratie" een belangrijke rol. Systeemintegratie is gericht op het toevoegen, verwijderen en aanpassen van componenten in het technische systeem, conform de geldende architectuur- en beheereisen. Gezien het belang daarvan wordt een aparte activiteitensoort "integreren" onderscheiden. Dit leidt tot onderstaand schema van activiteiten.

welke activiteiten

Figuur 14

Samenhang van Activiteiten in de systeemtechnische ondersteuning

waarop gericht

een aantal deelsystemen

een deelsysteem

Ontwikkelen en implementeren hebben altijd betrekking op een deelsysteem of component. Er is een natuurlijk een sterke koppeling tussen ontwikkelen en implementeren. Dat geldt ook voor implementeren en beheren. Het nieuwe deelsysteem moet immers na implementatie goed beheerd kunnen worden. Er is ook een sterke koppeling tussen integreren en ontwikkelen; dit is vooral het geval als er reeds een aantal systemen in gebruik is. Nieuwe systemen moeten dan worden geïntegreerd met de bestaande systemen. Aangezien bij integreren ook rekening moet worden gehouden met eisen vanuit de omgeving, waarin systemen moeten functioneren, is er ook een sterke koppeling tussen integreren en implementeren. Integreren van systemen of systeemcomponenten moeten gebeuren op basis van een goed overzicht van het geheel, vandaar dat ook een redelijk sterke koppeling nodig is tussen integreren en architectureren. Dezelfde redenering geldt voor de relatie tussen integreren en beheren. Immers vanuit beheren worden beheereisen geformuleerd voor alle systemen, waarop integreren is gericht.


68

Architectureren wordt voor een belangrijk deel gedaan om systemen goed te kunnen beheren. Vandaar ook een redelijk sterke koppeling tussen deze twee activiteiten. De koppeling tussen architectureren en ontwikkelen loopt in principe via integreren, zodat daar sprake is van een zwakkere koppeling. Bij een behoorlijk omvangrijk en complex stelsel van technische systemen - zoals dat bij verkeersbeheersing het geval is - is integreren de centrale coördinerende activiteit. Andere activiteitensoorten leveren toe of zijn afhankelijk van de beslissingen, die daar worden genomen.


69


70

Bijlage 3. Clusters van activiteiten

Voor het clusteren van activiteiten worden de tabellen met geclassificeerde activiteiten van hoofdstuk 1.2.2. samengevoegd en opnieuw gerangschikt. De basis voor het op deze wijze samenvoegen van activiteiten wordt enerzijds gevormd door de classificatie, anderzijds door de aard van de activiteiten (verkeersgericht of systeemgericht). Verkeersgerichte activiteiten

Voor deze activiteiten worden tevens onderstaande criteria gehanteerd. Lagen in het lagenmodel Activiteiten worden per laag geclusterd, omdat per laag een ander soort activiteiten moet worden uitgevoerd. Ontwikkelen en beheren Voor verkeerskundige elementen als regelstrategie en regeltactiek geldt waarschijnlijk dat voor het ontwikkelen en beheren daarvan dezelfde kennis en vaardigheid nodig is. Vandaar dat ontwikkelen en beheren voor die activiteiten worden geclusterd. Voorbereiden en uitvoeren Voorbereidende activiteiten zijn overwegend anders van aard dan uitvoerende activiteiten. Dat komt tot uitdrukking in verschillende rollen daarvoor. Systeemgerichte activiteiten

Voor systeemgerichte beheeractiviteiten wordt in de tabel geen onderscheid gemaakt tussen applicatie-gerichte en infrastructuur-gerichte activiteiten, omdat de beheerrollen doorgaans met eenzelfde naam kunnen worden aangegeven (zoals "wijzigingsbeheerder" e.d.)5). Deze rollen zijn grotendeels afgeleid van de ITIL beheerprocessen. Het resultaat van de clustering is te zien in onderstaande tabel. Clusters van activiteiten worden in deze tabel omlijnd en van een naam voorzien die een samenvatting geeft van de rol.

Noten


5) Bij de implementatie van de organisatie architectuur in een concrete organisatiestructuur kan het onderscheid in applicatiegerichte en infrastructuurgerichte activiteiten weer wel duidelijk naar voren komen. Zie ook hoofdstuk 6 "Suggesties voor Implementie".

71

De verantwoordelijkheden van de rol wordt beschreven in de vorm van de activiteiten waarvoor de rol verantwoordelijk is.

Tabel 18

Rollen afgeleid van verkeersgerichte activiteiten

Verkeersgerichte Activiteiten

Architectureren Ontwikkelen

Architectureren van de Verkeerskundige Architectuur

Beheren

Verkeerskundig Architect

Ontwikkelen Maatregelen

Maatregel Ontwikkelaar

Verzamelen van Beleidsuitgangspunten

Regel strategie Opsteller

*

Opstellen Handboek Regeltactieken

*

*

*

Opstellen van Regelstrategieën en Referentiekader

*

Regeltactieken Opsteller

Opstellen Integratieregels Regeltactieken Off-line Bepalen van ntegrale Regelscenario's Coördineren van Scenario Ondersteuning (van WIU, Voorbereider IM, EM, OB, en LOV)

*

•

#

Opstellen Handboek Regelscenario's

*

•

Monitoren van de Verkeerssituatie Afhandelen Integrale Regelscenario's

Operationele Verkeers Beheerser

Activeren van Maatregelen en Signalen Beheren van Gegevens


Uitvoeren/ Inzetten

* Verkeers gegevens Beheerder

72

*

Tabel 19 Rollen afgeleid van systeemgerichte activiteiten

Systeemgerichte Activiteiten

Architectureren Integreren


j* :

Architectureren van de •* Architectuur van de Technische Infrastructuur !

Inplementeren Beheren

Applicatie : Architect Infrastructuur Architect i

Verwerven van Applicatie Componenten Implementeren van Applicatie Componenten

; - • *

;

Applicatie * Componenten i Verwerver :

Assembleren van Applicaties met behulp van Applicatie Componenten Implementeren van Applicaties

't

*

| Applicatie * ! Assembleerder

Integreren van Systeem Applicaties en Applicatie Integrator Componenten Integreren van de Technische Infrastructuur


Ontwikkelen

I«

«

!#

Waarborgen van de Beschikbaarheid van Applicaties en Applicatie Componenten Waarborgen van de Beschikbaarheid van de Technische Infrastructuur en Infrastructuur Componenten

Beschikbaarheids Beheerder

Waarborgen van de Capaciteit van Applicaties Waarborgen van de Capaciteit van de Technische Infrastructuur

CapaciteitsBeheerder

Beheren van de Configuratie van Applicaties en Applicatie Componenten Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten

Configuratie Beheerder

Beheren van de Beveiliging van Applicaties en Applicatie Componenten Beheren van de Beveiliging van de Technische Infrastructuur en Infrastructuur Componenten

Beveiligings Beheerder

73

#

* #

*

*

*

Systeemgerichte Activiteiten

Architectureren Integreren

Inplementeren

Beheersen van de Wijzigingen in Applicaties en Applicatie Componenten Beheersen van de Wijzigingen in de Technische Infrastructuur en Infrastructuur Componenten

Wijzigings Beheerder


Applicatie Onderhouder

Ondersteunen van de Bediening van Applicaties

Help Desk

Verwerven van Infrastructuur Componenten Ontwikkelen van de Technische Infrastructuur Implementeren van de Technische Infrastructuur

Infrastructuur Ontwikkelaar

Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten Vaststellen Naamgevingsstructuur voor Technische Componenten

Infrastructuur Onderhouder

Naam gever

Benoemen van Technische Componenten Ontwikkelen van Gegevensmodellen Beheren van Gegevensdefinities


Ontwikkelen

Gegevens : definitie Beheerder

74

Beheren

Bijlage 4. Het organisatiemodel van Mintzberg

Stapsgewijs zal worden aangegeven hoe het model is opgebouwd. Taakverdeling en coördinatie

In een eenmansorganisatie vervult een persoon alle taken, die nodig zijn voor het leveren van het product van de organisatie. Als de taken niet meer door een persoon kunnen worden gedaan, moeten taken worden verdeeld over meerdere personen. Als taken worden verdeeld, moet de taakuitvoering daarna weer worden gecoördineerd, om het gewenste product te kunnen leveren. Dat is het basisprincipe van taakverdeling en coördinatie van de taakuitvoering. Besturing en uitvoering

Bij taakverdeling over meer dan twee personen bestaat al gauw de behoefte om één persoon te belasten met taakverdeling en coördinatie. Zo ontstaan besturende taken naast uitvoerende taken. Primaire productie en ondersteuning

Wordt de organisatie groter dan vindt een verdere taakverdeling plaats in de uitvoerende taken. Naast taken, die direct gericht zijn op de primaire productie, ontstaan taken die gericht zijn op de ondersteuning van zowel de besturende als de productietaken. De driedeling naar besturing, primaire productie en ondersteuning is kenmerkend voor elke organisatie van enige omvang (Zie [Buurma], p. 18). Technische en facilitaire ondersteuning

Vooral als het primaire productieproces technisch complex is, ontstaat een nadere taakverdeling in ondersteunende taken. Ondersteuning kan dan gericht zijn op het primaire productieproces of op de organisatie als geheel. Ondersteuning van het primaire proces is gericht op het beschikbaar stellen van de methoden, technieken en middelen, die nodig zijn voor het uitvoeren van het productieproces. Deze technische ondersteuning is direct gerelateerd aan de aard van het productieproces. De ondersteuning die gericht is op de organisatie als geheel, is meer algemeen van aard en zal doorgaans niet wezenlijk verschillen bij verschillende soorten primaire productieprocessen. Deze facilitaire ondersteuning betreft veelal het verrichten van zogenaamde PIOFAH taken. Dit zijn taken op het gebied van Personeel, Informatievoorziening (de bedrijfsinformatievoorziening wordt hiermee bedoeld), Organisatie, Financiën, Aanschaffingen en Huisvesting.

l


75

Algemene en uitvoeringsgerichte besturing

Bij toenemende omvang van primaire productie en ondersteuning ontstaat behoefte aan afzonderlijke besturing van de productie en van de ondersteuning. Heeft deze taakverdeling eenmaal plaatsgevonden dan zal ook al snel de behoefte ontstaan aan coördinatie van die twee vormen van besturing. Zo ontstaat een soort basis organisatiemodel in drie lagen:

Figuur 15

alger nene bestL ring

Basis Organisatie Model

I

t \

oesturing technische ondersteuning

besturing primaire productie

besturing facilitaire ondersteunin

T technische ondersteuning

primaire productie

facilitaire ondersteunin

Organisatiemodel van Mintzberg

Het basis organisatiemodel kan ook worden weergegeven in het Mintzberg model. Figuur 16

Organisatiemodel van Mintzberg


76

Bijlage 5. De relatie tussen het logische en fysieke niveau

11.1 Functies en Organisatie-eenheden

De essentiële organisatiestructuur is gestructureerd volgens het model van Mintzberg en hanteert de driedeling: - Verkeersmanagement - Verkeerskundige ondersteuning - Systeemtechnische ondersteuning. In de structuur worden besturende functies en organisatie-eenheden onderscheiden. Besturende functies kunnen andere besturende functies of organisatie-eenheden besturen. De organisatie-eenheid is het laagste niveau wat is onderkend in de essentiële organisatiestructuur en wordt weergegeven met een term die een taakgebied omschrijft. Rollen (en daarmee impliciet activiteiten) worden toegekend aan organisatie-eenheden. Onderstaande tabel geeft een overzicht van alle in de structuur genoemde functies en organisatie-eenheden. 11.2 Functiekenmerken Onderstaand is per functie aangegeven wat de hiërarchische relatie is en waar de functie kan worden geplaatst met betrekking tot pijlers en niveaus uit het model "beheren met een kleine b". Algemeen

Tabel 20

Functie:

Algemeen Verkeersmanager

Bestuurt:

Pijler kleine b: Rapporteert aan:

Algemeen Manager VerkeersKunde Algemeen SysteemManager Regionaal VerkeersManager Landelijk VerkeersManager Strategisch VM Bestuur VerkeersManagement

Functie:


Bestuurt:

Algemene VerkeersKunde Verkeerskundige Architectuur Normen en Standaards voor VerkeersBeheersing Methoden en Technieken voor VerkeersBeheersing Strategisch DVM-VK Algemeen Verkeersmanager

Kenmerken van Besturende Functies

Niveau:

Niveau: Pijler kleine b: Rapporteert aan:


77

Functie:


Bestuurt:

Algemene Systeemkunde SysteemArchitectuur Normen en Standaards voor het Technische Systeem Methoden en Technieken voor het Technische Systeem Prototyping en Pilots Systeemintegratie Referentie- en Testomgeving Strategisch DVM-IT Algemeen Verkeersmanager


Landelijk

Functie:


Bestuurt:


Landelijk Manager VerkeersKunde Landelijk SysteemManager Hoofd Landelijke VerkeersmanagementCentrale Tactisch VM Algemeen Verkeersmanager

Functie:


Bestuurt: Niveau: Pijler kleine b: Rapporteert aan:

Landelijke Verkeerskunde Tactisch DVM-VK Landelijk VerkeersManager

Functie:

Landelijk SysteemManager

Bestuurt:


DienstenBeheer Ontwikkeling en Implementatie SysteemBeheer Tactisch DVM-IT Landelijk VerkeersManager

Functie:

Hoofd Landelijke VerkeersmanagementCentrale

Bestuurt:

Landelijke WegVerkeersLeiding Landelijk GegevensBeheer Operationeel VM Landelijk VerkeersManager



78

Regionaal

Functie:

Regionaal VerkeersManager

Bestuurt:


Regionaal Manager VerkeersKunde Regionaal SysteemManager Hoofd Regionale VerkeersmanagementCentrale Tactisch VM Algemeen Verkeersmanager

Functie:

Regionaal Manager VerkeersKunde

Bestuurt: Niveau: Pijler kleine b: Rapporteert aan:

Regionale VerkeersKunde Tactisch DVM-VK Regionaal VerkeersManager

Functie:

Regionaal SysteemManager

Bestuurt:


DienstenBeheer Ontwikkeling en Implementatie SysteemBeheer Tactisch DVM-IT Regionaal VerkeersManager

Functie:

Hoofd Regionale VerkeersmanagementCentrale

Bestuurt:

Regionale WegVerkeersLeiding Regionale Coördinatie Ondersteuning Regionaal GegevensBeheer Operationeel VM Regionaal VerkeersManager



79

11.3 Kenmerken van Organisatie-eenheden

Onderstaand is voor iedere organisatie-eenheid aangegeven door welke functie deze wordt bestuurd, welke rollen moeten worden vervuld en welke activiteiten moeten worden uitgevoerd. Strategisch niveau

Voor organisatie-eenheden op strategisch niveau zijn vaak geen rollen geïdentificeerd (zie par. 5.2.4). In dat geval worden rollen toegevoegd of alleen activiteiten vermeld.

Tabel 2 1

Organisatie-eenheid:

Algemene VerkeersKunde

Wordt bestuurd door: Rolden):

Algemeen Manager VerkeersKunde - Onderzoeker - Maatregel ontwikkelaar - Uitvoeren van verkeerskundig onderzoek - Uitvoeren van verkeerskundige evaluaties - Ontwikkelen maatregelen

Kenmerken van Organisatie-Eenheden

Activiteiten:



Wordt bestuurd door: Rolden): Activiteiten:

Algemeen Manager VerkeersKunde - Verkeerskundig Architect - Architectureren van de Verkeerskundige Architectuur


Normen en Standaards voor VerkeersBeheersing

Wordt bestuurd door: Activiteiten:

Algemeen Manager VerkeersKunde - Gegevens definitie Beheerder - Beheren van Gegevensdefinities voor VerkeersBeheersing - Beheren van de Catalogus voor VerkeersBeheersing


Methoden en Technieken voor VerkeersBeheersing




Algemene SysteemKunde


Algemeen SysteemManager - Onderzoeker - Uitvoeren van systeemtechnisch onderzoek - Uitvoeren van systeemtechnische evaluaties

Rolden):

- Bepalen van methoden en technieken voor ontwikkeling en beheer van de verkeerskundige elementen (van strategie tot signaal)

Activiteiten:


80


SysteemArchitectuur

Wordt bestuurd door:

Algemeen SysteemManager - Applicatie Architect - Infrastructuur Architect - Architectureren van de Applicatie Architectuur - Architectureren van de Architectuur van de Technische Infrastructuur

Rolden): Activiteiten:


Normen en Standaards voor het Technische Systeem

Wordt bestuurd door:

Algemeen SysteemManager - Gegevensdefinitie Beheerder - Naamgever - Beheren van Gegevensdefinities voor het Technische Systeem - Beheren van de Catalogus voor ApplicatieComponenten - Beheren van de Catalogus voor Technische Infrastructuur Componenten - Vaststellen Naamgevingsstructuur voor Technische Componenten - Benoemen van Technische Componenten

Rolden): Activiteiten:



Methoden en Technieken voor het Technische Systeem




Prototyping en Pilots




Systeemintegratie


Algemeen SysteemManager - Systeem Integrator - Integreren van Applicaties en Applicatie Componenten - Integreren van de Technische Infrastructuur


Referentie- en Testomgeving



- Bepalen van methoden en technieken voor ontwikkeling en beheer van het technisch systeem

- Leiden van prototyping en pilot projecten

- Exploiteren van een referentie- en testomgeving - Uitvoeren van systeemtests

81

Tactisch Niveau Landelijk


Landelijke Verkeerskunde


Landelijk Manager VerkeersKunde - Regelstrategieën Opsteller - Regeltactieken Opsteller - Scenario Voorbereider - Verzamelen van Beleidsuitgangspunten - Opstellen regelstrategieën - Opstellen Integratieregels Regeltactieken - Opstellen Handboek Regeltactieken - Off-line bepalen van Integrale Regelscenario's - Opstellen Handboek Regelscenario's

Activiteiten:


DienstenBeheer


Landelijk SysteemManager - Dienstenniveau Beheerder - Wijzigings Beheerder - Beschikbaarheids Beheerder - Capaciteits Beheerder - Beveiligings Beheerder - Dienstenniveau Beheer - Beheersen van de Wijzigingen in het Technisch Systeem - Waarborgen van de Beschikbaarheid van het Technisch Systeem - Waarborgen van de Capaciteit van het Technisch Systeem - Beheren van de Beveiliging van het Technisch Systeem

Activiteiten:


Ontwikkeling en Implementatie


Landelijk SysteemManager - Applicatie Componenten Verwerver - Applicatie Assembleerder - Infrastructuur Ontwikkelaar - Verwerven van Applicatie Componenten - Assembleren van Applicaties met behulp van Applicatie Componenten - Implementeren van Applicatie Componenten - Implementeren van Applicaties - Verwerven van Infrastructuur Componenten - Ontwikkelen van de Technische Infrastructuur

Activiteiten:


82


SysteemBeheer

Wordt bestuurd door: Rol(len):

Landelijk SysteemManager - HelpDesk - Configuratie Beheerder - Onderhouder van Applicaties en Applicatie Componenten - Infrastructuur Onderhouder - Ondersteunen van de Bediening van Applicaties - Beheren van de Configuratie van Applicaties en Applicatie Componenten - Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten - Onderhouden van Applicaties en Applicatie Componenten - Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten

Activiteiten:

Regionaal


Regionale VerkeersKunde

Wordt bestuurd door: Rol(len):

Regionaal Manager VerkeersKunde - Regelstrategie Opsteller - Regeltactieken Opsteller - Scenario Voorbereider - Verzamelen van beleidsuitgangspunten - Opstellen Regelstrategieën - Opstellen Integratieregels Regeltactieken - Opstellen Handboek Regeltactieken - Off-line Bepalen van Integrale Regelscenario's - Coördineren van Ondersteuning (van WIU, IM, EM, OB, en LOV) - Opstellen Handboek Regelscenario's

Activiteiten:


DienstenBeheer


Regionaal SysteemManager - Dienstenniveau Beheerder - Wijzigings Beheerder - Beschikbaarheids Beheerder - Capaciteits Beheerder - Beveiligings Beheerder - Dienstenniveau Beheer - Beheersen van de Wijzigingen in het Technisch Systeem - Waarborgen van de Beschikbaarheid van het Technisch Systeem - Waarborgen van de Capaciteit van het Technisch Systeem - Beheren van de Beveiliging van het Technisch Systeem

Activiteiten:


83


Ontwikkeling en Implementatie


Regionaal SysteemManager - Applicatie Componenten Verwerver - Applicatie Assembleerder - Infrastructuur Ontwikkelaar - Verwerven van Applicatie Componenten - Assembleren van Applicaties met behulp van Applicatie Componenten - Implementeren van Applicatie Componenten - Implementeren van Applicaties - Verwerven van Infrastructuur Componenten - Ontwikkelen van de Technische Infrastructuur

Activiteiten:


SysteemBeheer


Regionaal SysteemManager - HelpDesk - Configuratie Beheerder - Onderhouder van Applicaties en Applicatie Componenten - Infrastructuur Onderhouder - Ondersteunen van de Bediening van Applicaties - Beheren van de Configuratie van Applicaties en Applicatie Componenten - Beheren van de Configuratie van de Technische Infrastructuur en Infrastructuur Componenten - Onderhouden van Applicaties en Applicatie Componenten - Onderhouden van de Technische Infrastructuur en Infrastructuur Componenten

Activiteiten:

Operationeel Niveau Landelijk



Landelijke WegVerkeersLeiding


Hoofd Landelijke VerkeersmanagementCentrale - Operationele Verkeers Beheerser - Monitoren van de Verkeerssituatie - Afhandelen Integrale Regelscenario's


Landelijk GegevensBeheer


Hoofd Landelijke VerkeersmanagementCentrale - Verkeersgegevens Beheerder - Beheren van Verkeersgegevens

84

Regionaal


Regionale WegVerkeersLeiding


Hoofd Regionale VerkeersmanagementCentrale - Operationele Verkeers Beheerser - Monitoren van de Verkeerssituatie - Afhandelen Integrale Regelscenario's - Activeren van Maatregelen en Signalen


Regionale Coördinatie Ondersteuning

Wordt bestuurd door: Activiteiten:

Hoofd Regionale VerkeersmanagementCentrale - Operationele Verkeers Beheerser - Afhandelen Integrale Regelscenario's (voor zover het het geven van feedback naar bijvoorbeeld politie en event organisatoren betreft)


Regionaal GegevensBeheer


Hoofd Regionale VerkeersmanagementCentrale - Verkeersgegevens Beheerder - Beheren van Verkeersgegevens

Rolden):


85


86

Bijlage 6. Referenties

12.1 In de tekst gerefereerde documenten


[Buurma]

"Doeltreffend delegeren", H. Buurma, Kluwer, 1982.

[Dietz]

"L_PASO, The passage to professionalism", J.L.G. Dietz, TU Delft, 1999.

[Grote B]

"Topstructuur DVM. Beheren met een Grote B", Van Meggelen Consultancy, 1998

[HCG 0016]

Verkeersbeheersingsfuncties. Nadere beschrijving van verkeersbeheersingsfuncties voor het AVB project (Concept). Rapport 0016 Hague Consulting Group. Mei 2000

[ITIL-CMG]

Deeldocument Opname van ITIL Elementen in de Organisatie Architectuur. CMG. Juni 2000.

[Kleine b]

"Beheren met de kleine b. Eindrapport", Van Meggelen Consultancy, 1998

[Mintzberg]

"The Structuring of Organisations", H. Mintzberg, Prentice Hall, 1979.

[P_AA_p1]

De AVB Applicatie Architectuur. Product PAA.p1. V 1.6. Werkdocument Maart 2000

[P_AA_p2]

Architectuurschema Applicatie Architectuur. In ontwikkeling. April 2000

[P_IA_p1]

De AVB Informatie Architectuur. Product RIA.p1. V1.3. Werkdocument Juni 2000.

[P_TA_p1]

Architectuur Technische Infrastructuur Verkeersbeheersing Product RTA.p1. V1.1. Nog niet vrijgegeven werkdocument. Juni 2000

[P_VA_p1]

De AVB Verkeerskundige Architectuur: Domeinbeschrijving. AVB Product RVA.p1. V3.0. October1999

[P_VA_p4]

De AVB Verkeerskundige Architectuur: Verkeersbeheersingsfuncties regionale operationele verkeersbeheersing. Product RVA.p4. Eindrapport. Maart 2000

[RWS-AVB]

"Inputdocument Themadag Architectuur voor Verkeersbeheersing", RWS AVB, 1999

[RWS-HW-I]

"Dynamisch VerkeersManagement. Bestuurlijke en Organisatorische Kaders", RWS HW-I, 1976

87

12.2 Overige geraadpleegde documenten

"Analogieën in verkeer en vervoer, met het accent op verkeersbeheersing", M. Westerman, TNO, 1998. AVB deeldocument: Architecture of Technical Infrastructure for traffic Control. Product RTA.p1. V1.0. December 1999 "Informatie Infrastructuur Management", A.A. Uijttenbroek e.a., Lansa, 1998. "Mintzberg over Management", H. Mintzberg, L.J. Veen B.V., 1991. "Operationeel Beheer van Informatiesystemen", Sander Koppens/Bas Meyberg, Kluwer Bedrijfsinformatie, 1993 "Planningen Beheersing van IT-dienstverlening", Dennis Bladergroen, et. al., Kluwer Bedrijfsinformatie, 1995


88

Bijlage 7. Woordenlijst

_:_ Activiteit

Een bepaalde werkzaamheid of verrichting.

Functie

De activiteiten die moeten worden verricht om een doel te bereiken.

Proces

De samenhang van activiteiten in de tijd, gericht op het leveren van een product.

Product

Een goed of een dienst, als resultaat van een productieproces.

Middel

Een entiteit die nodig is voor het uitvoeren van een activiteit.

Personele functie

Een functie die wordt uitgevoerd door een persoon.

Bedrijfsfunctie

Een functie die wordt uitgevoerd door een groep van personen, die samen een organisatie-eenheid vormen (bijv. een afdeling).

Bedrijfsproces

Een proces in een organisatie, dat gericht is op het leveren van een bepaald bedrijfsproduct.

Bedrijfsproduct

Een goed of een dienst, als resultaat van een bedrijfsproces.

Bedrijfsmiddel

Een entiteit, die in een organisatie nodig is voor het uitvoeren van bedrijfsactiviteiten.

Ontleend aan Dietz, 1999. Onderstaande definities worden gehanteerd vanuit het gezichtspunt van de informatievoorziening • in een organisatie. Drie systeemsoorten kunnen worden onderscheiden: Bedrijfsproces; de interactie tussen mensen gericht op het leveren van een bedrijfsproduct, waarbij gebruik wordt gemaakt van een informatiesysteem. Informatiesysteem; een systeem voor de inhoudelijke bewerking van gegevens. Infrastructuursysteem; een systeem voor de representatie van gegevens in de vorm van binaire data, alsmede de opslag, het transport en de bewerking daarvan. Deze infrastructuursystemen vormen de bouwstenen voor de ICT-infrastructuur.

Systeemsoort


89

1


Systeemoriëntatie

Functie-oriëntatie; een oriëntatie, waarbij men is gericht op de functionaliteit of de externe vorm en werking van een systeem. Constructie-oriëntatie: een oriëntatie, waarbij men is gericht op de constructie of de interne bouw en werking van een systeem.

Activiteitensoort

Een van de soorten activiteiten die mensen kunnen verricht met betrekking tot de drie soorten systemen.

Achitectureren

Het concipiëren van architecturen. Dit is gericht op het stileren van de functie en de constructie van systemen van een bepaalde soort.

Ontwikkelen

Het specificeren, ontwerpen, bouwen en testen van een informatiesysteem.

Implementeren

Het in gebruik stellen van een informatiesysteem, met inbegrip van het voorbereiden en het veranderen van de omgeving, waarin het systeem moet gaan fungeren.

Beheren

Het in bedrijf houden van een informatiesysteem. Dit betreft is essentie twee soorten activiteiten: Het werkend en beschikbaar houden van het systeem. Het veranderen van het systeem, gericht op het verbeteren van de functie of de constructie van het systeem.

90

Bijlage 8. Lijst met tabellen

Tabel 1. Tabel 2. Tabel 3. Tabel 4. Tabel 5. Tabel 6. Tabel 7. Tabel 8. Tabel 9. Tabel 10. Tabel 11. Tabel 11a. Tabel 12. Tabel 13. Tabel 14. Tabel 15. Tabel 16. Tabel 17. Tabel Tabel Tabel Tabel


18. 19. 20.

21.

Systeemsoorten en Activiteitensoorten in de AVB 13 Classificatie van Activiteiten uit de Verkeerskundige Architectuur 14 Classificatie van Activiteiten uit de Applicatie Architectuur 15 Classificatie van Activiteiten uit de Architectuur van de Technische Infrastructuur 16 Classificatie van Activiteiten uit de Informatie Architectuur 17 Verkeersgerichte Rollen en Bijbehorende Verantwoordelijkheden 20 Systeemgerichte Rollen en Bijbehorende Verantwoordelijkheden 21 Besturende Functies en de Functies of Organisatie-eenheden die zij aansturen 32 Gebruikte Afkortingen in het Overzicht van de Essentiële Organisatiestructuur 33 Onderwerpen voor Samenwerking 35 Producten/diensten in model "Kleine b" 40 Relatie tussen producten van model "Kleine b en de essentiële organisatiestructuur 41 Processen en activiteiten gerelateerd aan het verkeerskundige lagenmodel 45 Functies afgeleid uit externe data stores 48 Functies afgeleid van interne data stores 49 Verkeerskundige activiteiten afgeleid van verkeersbeheersingsfuncties 50 Activiteiten gerelateerd aan componenten uit de Applicatie Architectuur 52 Activiteiten afgeleid van overige aspecten van de Applicatie Architectuur 56 Rollen afgeleid van verkeersgerichte activiteiten 72 Rollen afgeleid van systeemgerichte activiteiten 73 Kenmerken van Besturende Functies 77 Kenmerken van Organisatie-Eenheden 80

91

1


92

Bijlage 9. Lijst met figuren

Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur Figuur


1. Context diagram van de AVB 7 2. Driedimensionaal Context Diagram van de AVB 2 3. Afleiding van de Organisatie Architectuur 7 4. Organisatie voor Verkeersbeheersing 25 5. Organisatie voor Verkeersbeheersing zonder PIOFAH taken 26 6. Landelijke Verkeersbeheersing 27 7. Regionale Verkeersbeheersing 28 8. Organisatie voor Verkeersbeheersing 29 9. Organisatie voor Verkeersbeheersing, met bestuur en beleid 30 10. De Essentiële Organisatiestructuur voor Verkeersbeheersing 34 11, Beheermodel Dynamisch Verkeersmanagement ("beheren met een kleine b") 39 12. Samenhang van Activiteiten in het L-PASO Model 66 13. Samenhang van Activiteiten voor verkeerskundige ondersteuning 67 14. Samenhang van Activiteiten in de systeemtechnische ondersteuning 68 15. Basis Organisatie Model 76 16. Organisatiemodel van Mintzberg 76

93


94


95


96

-I

m0m Organisatie Architectuur Architectuur voor Verkeersbeheersing

Recommend Documents