Beheren en beheersen

Beheren en beheersen Het beheer van het Geïntegreerd Meldkamer Systeem bij de brandweer

Rozen verwelken Schepen vergaan Dus zit niet te melken Maar doe er wat aan (Drs. P)

Commandeursscriptie, MCDM 7e leergang Léon Houben

Voorwoord Als 18-jarige ben ik als vrijwillige brandwacht gestart bij Brandweer Susteren. Na de basisbrandweeropleidingen te hebben doorlopen begon de professionaliteit van de opleidingen toe te nemen en daarmee ook het opleidingsniveau. Als fanatieke vrijwilliger ben ik uiteindelijk gestart met de opleiding adjunct hoofdbrandmeester. Na deze opleiding werd ik plaatsvervangend-commandant in Susteren en enige tijd later commandant. In die periode heb ik ook mijn hoofdbrandmeester diploma behaald.

Voor mijn hoofdberoep was ik werkzaam in de ICT, de laatste 10 jaar in management functies. Na een wat moeilijke periode kwam ik eind 2003 tot de conclusie dat het roer drastisch om moest. Het managen van een afdeling van 150 medewerkers in een continu fuserend bedrijf had van mij een “workaholic” gemaakt. Dat in combinatie met het leidinggeven aan een vrijwillige brandweer liet geen plaats meer voor een gezinsleven.

Het in stand houden van twee beroepen bleek in die periode een voordeel te zijn. Brandweer Sittard-Geleen was op zoek naar een hoofd repressie die de ombuiging van de organisatie vorm kon geven. Een uitdagende job, hetgeen voor mij belangrijker was dan een verdere carrière op de maatschappelijke ladder. De keuze was snel gemaakt en op 1 april 2004 ben ik in Sittard-Geleen gestart. Het project is inmiddels uitgebreid tot de fusie van de vier brandweerkorpsen in de Westelijke Mijnstreek en de implementatie van één 24 uurs beroepspost, één 12 uurs beroepspost en de afslanking van 6 vrijwillige posten. De nieuwe organisatie moet 1 januari 2008 starten.

Voorwaarde bij indiensttreding was het volgen van de commandeursopleiding. Zelf heb ik toen besloten de volledige “Master of Crisis and Disaster Management” (MCDM) opleiding te gaan volgen. Het schrijven van voorliggende scriptie is een onderdeel van het 1e jaar. Achteraf blijkt dat het managen van het hierboven omschreven project én het volgen van deze studie een slechte keuze is. Ik ben nagenoeg volledig vervallen in het oude patroon van werken zoals bij mijn vorige werkgever. Echter, er is hoop! In juni 2006 moet de studie zijn afgerond en hoop ik invulling te gaan geven aan mijn leven zoals ik én mijn gezin zich dat wensen.

Gezien mijn achtergrond in de ICT lag het voor de hand een ICT gerelateerd onderwerp voor mijn scriptie te kiezen. In mijn dagelijkse werkzaamheden word ik veelvuldig geconfronteerd met problemen die worden veroorzaakt door het beheer van het

2/49

Versie 1.0 d.d. 14-11-2005

Geïntegreerd Meldkamer Systeem. Vandaar dit onderzoek naar het beheer van dat systeem. Ik hoop dat de uitkomst van mijn onderzoek wordt ingebracht in de besluitvorming omtrent de vervanging van het GMS.

Het schrijven van deze scriptie was voor mij een moeilijke klus. Het grootste probleem was in de avonduren mijn werk loslaten (en tijd er voor vrij maken) en mijn gedachten richten op het scriptieonderwerp. Daarnaast was het een leerzaam proces. Vanuit een theoretisch kader een probleem benaderen draagt zorg voor een gestructureerde aanpak. Daarnaast was het een uitdaging voor mij, als gewezen ICT-professional, een scriptie te schrijven over een ICT-onderwerp op een dusdanig niveau dat minder ingewijden in de ICT-wereld het zouden begrijpen.

Een speciaal woord van dank wil ik richten aan Pim Kwaks. Toen ik vastliep met mijn scriptie heeft hij zich aangeboden als mijn persoonlijke coach. Mede door zijn begeleiding is dit resultaat tot stand gekomen. Zijn ondersteuning en die van de mentoren M. van Duin en H. v.d. Kar zijn zeer waardevol geweest.

Vervolgens wil ik ook nog een woord van dank richten aan de volgende heren die hebben meegewerkt aan het tot stand komen van dit onderzoek: W. Beukelman, ISC T. Borm, regionale brandweer Zuid-Limburg B. v.d. Heuvel, regionale brandweer Zuid-Limburg J.W. Land, regionale brandweer Zaanstreek-Waterland H. Maas, regionale brandweer Zuid-Limburg C. Trines, regionale brandweer Noord- en Midden Limburg Leden commissie repressie Zuid-Limburg: R. Smeets, brandweer Maastricht H. Urlings, regionale brandweer Zuid-Limburg R. v.d. Valk, brandweer Parkstad

Last but not least: mijn gezin. Mirjam, Lars en Kevin, allereerst mijn excuses dat ons gezinsleven wederom een aanslag te verduren heeft gekregen. De belofte van begin 2004 staat en hier wordt vanaf juni 2006 invulling aan gegeven! Bedankt voor het begrip en de steun.

Léon Susteren, november 2005

3/49

Versie 1.0 d.d. 14-11-2005

Inhoudsopgave

Voorwoord

2

Inhoudsopgave

4

1.

Inleiding Aanleiding voor het onderzoek Doel van het onderzoek Beschrijving van het Geïntegreerd Meldkamer Systeem Definities Beperkingen Onderzoeksmethode Opbouw

2.

5 5 5 6 8 9 9 10

2.1 2.2 2.3 2.4 2.5 2.6 2.7

Beheren volgens Looijen Begrippen Drievoudig model van beheer Relatie tussen de beheerdomeinen Gemeenschappelijk belang Samenhang Een analyse van het model van Looijen De 4e dimensie

11 11 13 16 16 16 17 17

3.1 3.2 3.3 3.4

Het beheer van het GMS getoetst aan het model van Looijen Beheer van het GMS op strategisch niveau Beheer van het GMS op tactisch niveau Beheer van het GMS op operationeel niveau De 4e dimensie: klantenrelatie

19 19 20 22 23

4.1 4.2 4.3

Beheersen van de organisatie middels ITIL Inleiding ITIL frontoffice processen Ondersteunende ITIL-processen

26 26 27 31

5.1 5.2 5.3 5.4 5.5 5.6

De beheerprocessen van het GMS Service level management Helpdesk Wijzigingsbeheer Relatiebeheer Beschikbaarheidsbeheer Calamiteitenbeheer

33 33 34 34 37 38 40

6.1 6.2

Conclusies en aanbevelingen Conclusies Aanbevelingen

41 41 44

3.

4.

5.

6.

Literatuurlijst

46

Bijlage: 1: Totaaloverzicht deelconclusies

47

4/49

Versie 1.0 d.d. 14-11-2005

1.

Inleiding

1.1

Aanleiding voor het onderzoek

Sinds 1 april 2004 ben ik beroepsmatig werkzaam bij de brandweer. Hiervoor heb ik 20 jaar gewerkt in de Informatie en Communicatie Technologie (ICT). De laatste jaren was ik manager ICT-beheer bij Essent. Ik gaf leiding aan een afdeling van 150 medewerkers die verantwoordelijk was voor het beheer van de ICT-infrastructuur. In mijn nieuwe baan wordt ik veelvuldig geconfronteerd met problemen met ICThulpmiddelen die wij nodig hebben voor het uitvoeren van één van onze primaire taken: repressie. Met name de (on)mogelijkheden van Geïntegreerd Meldkamer Systeem (GMS) zorgen vaak voor belemmeringen in het uitvoeren van een optimale repressieve brandweerzorg. Vanuit mijn achtergrond en ervaring heb ik mij binnen de regionale brandweer Zuid-Limburg verder verdiept in het beheer van het GMS. Al snel kwam ik tot de conclusie dat het beheer in mijn ogen op een onvoldoende professionele wijze wordt uitgevoerd en dat de ICT-kennis binnen deze regio slechts zeer beperkt aanwezig is. Middels deze scriptie wil ik mij verder verdiepen in deze problematiek en wil ik een bijdrage leveren aan het verder optimaliseren van het beheer van het GMS zodat het goed ondersteunend wordt aan het primaire proces “repressie”.

1.2

Doel van het onderzoek

In Nederland zijn er momenteel 25 regionale brandweren die gebruik maken van het GMS. In dit systeem worden jaarlijks 96.4511 meldingen geregistreerd die binnenkomen via de 112 centrale, de OMS-systemen of via overige meldingen. De primaire functionaliteit van het systeem is het registeren van de meldingsgegevens, het rubriceren van het incident, het genereren van een uitrukvoorstel en tenslotte het voorstel doorzenden naar de computer van C2000, waarna deze voor de daadwerkelijke alarmering zorg draagt. Alle nader berichten worden vervolgens gelogd in het systeem. Ten behoeve van het alarmeren van de eenheden wordt onder andere rekening gehouden met de statussen en posities van de eenheden én de dienstroosters van het personeel.

De centrale vraag van het onderzoek is het bekijken van het beheer van het GMS. Dit leidt tot de volgende probleemstelling:

1

Kerncijfers brandweerstatistiek 2004, Centraal Bureau voor de Statistiek.

5/49

Versie 1.0 d.d. 14-11-2005

Hoe is bij de brandweer het beheer georganiseerd van het Geïntegreerd Meldkamer Systeem (GMS) en welke verbeterpunten zijn er?

Subvragen: -

Wat is het GMS?

-

Wat leert de theorie ons over beheervraagstukken van geautomatiseerde systemen?

-

Wat is beheer en hoe is dat georganiseerd bij het GMS?

-

In hoeverre is er sprake van een discrepantie tussen de theorie en het daadwerkelijk beheer van het GMS?

-

Hoe is de kwaliteit van het beheer van het GMS uitgaande van het theoretisch kader?

-

Is het brandweerpersoneel voldoende opgeleid voor het uitvoeren van het beheer van het GMS?

1.3

Beschrijving van het Geïntegreerd Meldkamer Systeem

Het GMS is het multidisciplinair meldkamersysteem van de brandweer, de Regionale Ambulance Voorzieningen (RAV‘s) en de politie. In het systeem worden alle meldingen verwerkt die op de meldkamers binnenkomen van “rood, wit en blauw”. Met de bouw van het GMS is in 1995 gestart. In 2004 heeft de laatste regionale brandweer het GMS geïmplementeerd. De oorsprong van het GMS is een gevolg van een beleidslijn dat er één meldkamer zou komen voor de drie hulpdiensten. De 25 regionale brandweren gebruiken het GMS voor het uitvoeren van hun wettelijke taak2. De primaire functionaliteit van het GMS is het vastleggen van alle meldingen die binnenkomen bij de meldkamers. Vervolgens genereert het GMS een alarmeringsvoorstel welke eenheden (personeel/materieel) moeten worden gekoppeld aan een incident. Indien er een alarmering plaatsvindt geschiedt dit via C2000. Het systeem van het GMS voedt de computer van C2000 met het alarmeringsvoorstel waarna alarmering plaatsvindt. De firma Siemens is de oorspronkelijke bouwer van het systeem. Tijdens de bouwfase is de opdracht overgenomen door ITO3. Het beheer is uiteindelijk belegd bij de ICT-Service

2 Brandweerwet 1985 artikel 3 lid2 :bij de regeling wordt een openbaar lichaam (regionale brandweer) ingesteld. Het openbaar lichaam is rechtspersoon. Daaraan worden in elk geval de volgende taken opgedragen: zorg te dragen voor het instellen en in stand houden van een regionale brandweeralarmcentrale. 3 Informatie en Communicatie Technologie Organisatie (ITO) een agentschap van het ministerie van BZK.

6/49

Versie 1.0 d.d. 14-11-2005

Coöperatie Politie, Justitie en Veiligheid (ISC). Deze organisatie is ontstaan uit ITO, die weer ontstaan is uit de automatiseringsafdeling van de politie. ISC is voornamelijk “blauw” gekleurd vanwege de geschiedenis van deze organisatie. ISC wordt per 1 januari 2006 een publiekrechtelijk orgaan van het Ministerie van Binnenlandse Zaken en Koninkrijksrelaties (BZK) en zal daardoor minder gelieerd zijn aan de politie.

Interviews met drie regionale brandweren en met vertegenwoordigers van ISC, hebben aangetoond dat er geen eenduidige beschrijving is van de beheerorganisatie. Taken, verantwoordelijkheden en bevoegdheden zijn niet goed vastgelegd. Tijdens de interviews is gebleken dat geen enkele partner in de keten van beheer in staat was een heldere beschrijving te geven van de beheerorganisatie. Onderstaand schets ik mijn beeld van de organen die betrokken zijn bij het beheer, welke rol zij vervullen en wat hun relatie is met de andere organen.

Figuur 1.1: beheerorganisatie van het GMS.

•

De werkgroepen werken monodisciplinair voor de drie disciplines. Zij dragen zorg voor functionele inbreng in de gebruikerscommissie.

•

De gebruikerscommissie is een multidisciplinaire commissie en is verantwoordelijk voor de multidisciplinaire gebruikersinbreng.

7/49

Versie 1.0 d.d. 14-11-2005

•

Het tactisch multidisciplinair overleg is verantwoordelijk voor de tactische multidisciplinaire gebruikersinbreng binnen de taakstelling van de begeleidingscommissie.

•

De begeleidingscommissie begeleidt op strategisch niveau het beheer van het GMS. In deze commissie zitten ook vertegenwoordigers van het ministerie van BZK.

•

Het ministerie van BZK is eigenaar van het GMS en opdrachtgever aan ISC.

In bovengenoemde organen zitten voor de brandweer veelal vertegenwoordigers van de regionale brandweren. Dit zijn voor het overgrote deel geen IT-professionals maar brandweerofficieren die IT voor een gedeelte in hun takenpakket hebben. Dit in tegenstelling tot de politie. De politie beschikt over een professionele IT-organisatie.

1.4

Definities

Gebruikersorganisatie De gebruikersorganisatie wordt gedefinieerd als het geheel van mensen en middelen dat zich bezighoudt met de bedrijfsprocessen4. Een voorbeeld van een gebruiker is een callcenter medewerker die gebruik maakt van een applicatie voor het registreren van de telefoontjes die hij aanneemt en verwerkt. Het systeem ondersteunt hem dus bij het uitvoeren van zijn primaire taak. Bij de brandweer moet de definitie echter breder worden gesteld. Het primaire proces dat ondersteund wordt is het daadwerkelijk repressief optreden. De gebruikers van het systeem zijn tweeledig: 1. De regionale alarmcentrales die het systeem gebruiken bij het verwerken van de 112 meldingen en het alarmeren van de brandweer. 2. De klanten van het systeem, de gemeentelijke brandweren en de bedrijfsbrandweren, die gealarmeerd worden via de alarmcentrale. Zij voeren immers het primaire proces uit. De alarmcentrale, inclusief het geïntegreerde meldkamer systeem, ondersteunen dit proces. De afnemer (repressie) maakt hier gebruik van. In dit onderzoek zijn zowel de gebruikers (centralisten van de alarmcentrale) als de klanten (repressieve brandweerorganisaties) de gebruikersorganisatie. Daar waar verbijzondering van de gebruikersorganisatie vereist is, wordt deze specifiek genoemd. De relatie tussen de alarmcentrale en de brandweerkorpsen (de klant) maakt ook deel uit van dit onderzoek.

4

Prof. dr. D.B.B. Rijsenbrij, Automatisering van de informatievoorziening, sectie III, hoofdstuk 8.

8/49

Versie 1.0 d.d. 14-11-2005

Het GMS is een multidisciplinair systeem, het wordt ook gebruikt door de politie en de regionale ambulance voorziening. Het onderzoek beperkt zich echter tot de brandweerorganisatie.

Beheren en beheersen Een geautomatiseerd systeem en vooral de organisatie eromheen moet worden beheerst en beheerd. Beheren is het dagelijks exploiteren van een IT-toepassing, beheersen staat voor het feilloos kunnen toepassen5. Het beheren is dus meer gericht op het inrichten en onderhouden van het systeem zelf dat het beheer uitvoert, de organisatie. Het beheersen legt meer de nadruk op het organiseren en de inrichting van processen die nodig zijn om een applicatie te laten meegroeien gedurende haar levenscyclus met de veranderende wensen en eisen van de klant.

1.5

Beperkingen

Het onderzoek beperkt zich tot de processen die gerelateerd zijn aan de gebruikersorganisatie van de brandweer. Interne processen bij de beherende partij van het GMS behoren dus niet tot de scope van het onderzoek.

1.6

Onderzoeksmethode

Voor het definiëren van het theoretisch kader is er gebruik gemaakt van literatuuronderzoek. De literatuur die ik hiervoor gebruik heb is afkomstig van de opleiding AMBI6. AMBI is een praktijkgerichte automatiseringsopleiding op HBO-niveau. Eén van de afstudeerrichtingen is het "Exploiteren van informatiesystemen (HX)", in deze richting ben ik zelf ook afgestudeerd. Het Nationaal Exameninstituut voor Informatica, Stichting EXIN7, neemt de landelijke examens af en zorgt voor de examenspecificaties. Voor het daadwerkelijk in kaart brengen van het beheer van het GMS is gebruik gemaakt van observaties bij de Regionale Brandweer Zuid-Limburg, en interviews met hoofden c.q. chefs van de regionale alarmcentrales in Zuid-Limburg, Noord- en Midden-Limburg en Zaanstreek-Waterland. Daarnaast heb ik een medewerker van ISC8 geïnterviewd die het applicatiebeheer verzorgt van het GMS. Het onderzoek beperkt zich tot het in kaart brengen van de hoofdlijnen van het beheer van het GMS.

5

Definities volgens van Dale handwoordenboek van hedendaags Nederlands. Automatisering en Mechanisering van de Bestuurlijke Informatieverwerking. 7 EXIN, het exameninstituut voor ICT'ers, verzekert de ICT-opleidingenmarkt van onafhankelijke, erkende, praktijkgerichte en actuele ICT-examens. EXIN zet de standaard voor (internationale) kwalificaties van ITprofessionals en ontwikkelt hiertoe exameneisen en examens. 8 ICT-Service Coöperatie Politie Justitie en Veiligheid (ISC). 6

9/49

Versie 1.0 d.d. 14-11-2005

1.7

Opbouw

Voor het theoretisch kader is gebruik gemaakt van twee modellen: het drievoudig model van beheer van Looijen en van ITIL. Voor dit onderzoek zijn de twee genoemde modellen gebruikt omdat deze het meest gangbaar zijn in ICT-land. In hoofdstuk 2 wordt het drievoudig model van beheer van Looijen uitgewerkt. Dit model legt het zwaartepunt op het beheren van de organisatie die een applicatie beschikbaar stelt aan een gebruiker. Vervolgens wordt in hoofdstuk 3 het beheer van het GMS getoetst aan het model van Looijen. In hoofdstuk 4 wordt een theoretisch model neergezet voor het beheersen van een systeem: ITIL. ITIL is in Nederland de meest toegepaste beheersmethodiek. Het beoogt een kwaliteitssysteem te zijn voor het beheren van de IT-infrastructuur. ITIL beschrijft processen, die bij een adequate implementatie de kwaliteit van de dienstverlening voor de afnemers zeker stelt. Daarna worden in hoofdstuk 5 de beheerprocessen van het GMS getoetst aan de ITIL-systematiek. In hoofdstuk 6 wordt tenslotte de eindconclusie van dit onderzoek weergegeven.

10/49

Versie 1.0 d.d. 14-11-2005

2.

Beheren volgens Looijen

Maarten Looijen is emeritus hoogleraar informatiestrategie en beheer van informatiesystemen aan de TU in Delft. Hij heeft een rijke ervaring opgedaan in computercentra en in het ontwerpen en bouwen van systemen. Deze praktijkervaring is mede de basis geweest voor zijn theorieën over het beheer van informatiesystemen. In paragraaf 2.2 is het theoretisch model van professor Looijen weergegeven voor het beheer van informatiesystemen.

2.1

Begrippen

Vanuit het beheer van ICT-systemen worden in de praktijk drie soorten beheer onderkend die ook gebruikt worden in het theoretisch model van professor Looijen: •

functioneel beheer (FB)

•

applicatiebeheer (AB)

•

technisch beheer (TB)

Functioneel beheer Het functioneel beheer is verantwoordelijk voor de instandhouding van de functionaliteit van het informatiesysteem, deze staat in het kader van het gebruik centraal. Vanuit deze algemene taakstelling ondersteunt het functioneel beheer het gebruik van de functionaliteiten, het evalueert het gebruik en het reageert op onvolkomenheden en nieuwe wensen die tot wijzigingen kunnen leiden. De directe relatie met het gebruik dwingt af dat het functioneel beheer zich aan de gebruikerszijde bevindt. In de dagelijkse praktijk omvat functioneel beheer onder andere het volgende9: •

het begeleiden en opleiden van gebruikers met betrekking tot het gebruik van informatiesystemen

•

het toekennen van autorisaties

•

het inhoudelijk beheren van gegevensverzamelingen

•

het bewaken van juist gebruik van het informatiesysteem

•

onderhouden van functionele specificaties

•

onderhouden van handmatige procedures

Applicatiebeheer Het applicatiebeheer is verantwoordelijk voor de instandhouding van de applicatieprogrammatuur en de gegevensbanken. Onder applicatieprogrammatuur wordt verstaan alle programmatuur anders dan operating systemen, databasemanagement9

Prof. dr. D.B.B. Rijsenbrij, Automatisering van de informatievoorziening, sectie III, hoofdstuk 8.

11/49

Versie 1.0 d.d. 14-11-2005

programmatuur en programmeermiddelen. Het is de programmatuur die mede met behulp van deze basis- en databasemanagementprogrammatuur en programmeermiddelen als toepassingsprogrammatuur (applicatieprogrammatuur geheten) van het informatiesysteem is ontwikkeld. Een voorbeeld hiervan is de Telefoongids10 die beschikbaar is op het internet. Samen met deze toepassingspakketten en programmatuur die specifiek is voor beveiliging valt deze programmatuur onder het applicatiebeheer. Zodra wijzigingen moeten worden aangebracht voor onderhoud is het applicatiebeheer verantwoordelijk voor het uitvoeren van de wijzigingen en het testen ervan. Dit geldt eveneens voor de gegevensbanken ten aanzien van gegevensmodellering en gegevensbankstructuren.

Technisch beheer Het technisch beheer is verantwoordelijk voor de instandhouding van de operationalisering van het informatiesysteem, bestaande uit apparatuur, programmatuur en gegevensverzamelingen die vanuit het gebruik continu beschikbaar moeten zijn11. Vanuit deze algemene taakstelling richt het technisch beheer zich op alle aspecten van operationalisering. Het bewaakt de overeengekomen niveaus, speelt in op afwijkingen en voert wijzigingen door als gevolg van gebruikerswensen en technologische ontwikkelingen. In dit alles is technisch beheer geen doel op zichzelf, hetgeen impliceert dat veranderingen in de exploitatie nooit los mogen worden gezien van het gebruik. De noodzaak voor verandering, en de consequenties ervan, moeten altijd in relatie met het gebruik worden gebracht. Tot het technisch beheer horen onder andere de volgende zaken12: •

aanbieden van verwerkingscapaciteit

•

aanbieden van opslagcapaciteit

•

onderhouden van de technische infrastructuur

•

een helpdeskfunctie

•

beschikbaar stellen en onderhouden van informatiesystemen voor de ondersteuning van groepswerk

10 11 12

http://www.detelefoongids.nl Looijen, Beheer van Informatiesystemen, 6e herziene druk, pag. 160. Prof. dr. D.B.B. Rijsenbrij, Automatisering van de informatievoorziening, sectie III, hoofdstuk 8.

12/49

Versie 1.0 d.d. 14-11-2005

2.2

Drievoudig model van beheer

Om de drie managementniveaus van beheer binnen elke beheereenheid en de samenhang daartussen weer te geven wordt het model van Mintzberg13 toegepast. Enerzijds is dit een willekeurige keuze maar anderzijds blijkt het logo goed aan te sluiten op de indeling van beheertaken naar taakgebieden/taakvelden en de positionering ervan op strategisch, tactisch en operationeel niveau. Mintzberg drukt met dit logo min of meer elke organisatie in hoofdvorm uit. Die hoofdvorm bestaat uit “strategic apex” (strategische top), “middle line” (midden kader), “techno stucture” (technostructuur), “support staff” (ondersteunende staf) en “operating core” (operationele kern) (zie figuur 2.1). Ze vormen de vijf basiselementen van elke organisatie. Het model laat toe er tekentechnisch mee te “spelen”. Dat wil zeggen dat elk basiselement zodanig te tekenen is dat bijvoorbeeld de omvang en de onderlinge verhoudingen tot uitdrukking komen. Daarbij spelen ook allerlei contingentiefactoren een rol. Hier gaat het er uitsluitend om de taakgebieden en taakvelden van het beheer organisatorisch te positioneren. Daarom is het logo strak getekend zonder bijaspecten, dit in tegenstelling tot situaties waarvoor het logo in eerste instantie is bedoeld.

strategic apex

technostructure

support staff middle line

operating core

Figuur 2.1: Logo van Mintzberg

In figuur 2.2 is het beheer van informatiesystemen als één organieke beheereenheid weergegeven, met een onderscheid in strategisch, tactisch en operationeel niveau. De verbijzondering van deze voorstelling, waarin ook de drie beheereenheden voor het functioneel beheer, het applicatiebeheer, en het technisch beheer vermeld zijn, wordt weergegeven in figuur 2.3. Er wordt op gewezen dat de taakgebieden op tactisch niveau, hoewel met identieke benamingen aangeduid, uiteraard per beheereenheid elk een eigen inhoud hebben, doordat de operationele niveaus ten opzichte van elkaar verschillend zijn.

13 Henry Mintzberg is een generalist op managementgebied. Hij publiceerde onder meer over managementgedrag, organisatiestructuren en verschillende vormen van strategieontwikkeling. Mintzberg werd in 1973 bekend door zijn onderzoek naar het dagelijks gedrag van managers.

13/49

Versie 1.0 d.d. 14-11-2005

Figuur 2.2: Organisatiestructuur van het beheer

In dit model is het beheer van informatiesystemen naar drie dimensies onderscheiden: het functioneel beheer, het applicatiebeheer en het technisch beheer. Het functioneel beheer richt zich op de functionaliteiten, het applicatiebeheer op de toepassingsprogrammatuur en gegevensbankstructuren en het technisch beheer op de apparatuur, basisprogrammatuur en de bijbehorende gegevensverwerkingsprocessen14. Naar analogie van een busbedrijf zou je kunnen stellen dat functioneel beheer zich bezig houdt met de functie “het vervoer van mensen”. Applicatiebeheer is de bus met chauffeur en de dienstregeling en het technisch beheer wordt uitgevoerd door de technische dienst die de bus onderhoudt. De samenhang tussen de drie dimensies wordt weergegeven in het drievoudig model van beheer. Elke vorm van beheer maakt onderscheid tussen beheertaken op managementniveau en operationeel niveau.

14

Looijen, Beheer van Informatiesystemen, 6e herziene druk, pag. 165.

14/49

Versie 1.0 d.d. 14-11-2005

Figuur 2.3: Drievoudig model van beheer

Om een indruk te krijgen wat dit voor de verschillende niveaus in de organisatie betekent, wordt in onderstaand voorbeeld het functioneel beheer kort uitgewerkt.


Strategisch: op dit niveau houdt functioneel beheer zich bezig met de vraag van het waarom van de informatievoorziening. Visie en strategie worden vertaald in een informatiseringbeleid. Functioneel beheer kan zich zelfs inzetten voor het maken van de vertaalslag van informatiseringbeleid naar automatiseringsbeleid.




Tactisch: op het tactische niveau beantwoordt functioneel beheer de vragen wat te informatiseren en hoe te informatiseren. Praktisch betekent dit het vertalen van “business-needs” in termen van informatievoorziening. Ook het coördineren van de acceptatiecriteria van de verschillende partijen, de organisatie en de IT-afdeling, ligt in de handen van functioneel beheer.




Operationeel: dit is het niveau waar functioneel beheer zich bezighoudt met de bewaking van de kwaliteit van de informatievoorziening. Op dit niveau is ook het ondersteunen van de klant te vinden. Deze taak van functioneel beheer is de meest bekende.

Uiteraard zijn we er nog niet als duidelijk is welke taken vervuld dienen te worden in het beheer. Taken moeten ook worden toegewezen aan medewerkers. Relaties tussen beheerdomeinen moeten worden aangegeven. Tevens moet samenwerking tussen de verschillende domeinen geregeld worden.

15/49

Versie 1.0 d.d. 14-11-2005

2.3

De relatie tussen de beheerdomeinen

In een organisatie verandert in de loop der tijd nog wel eens wat: uitbesteding, decentralisatie of juist weer centralisatie, samenvoeging of splitsing. Om te voorkomen dat bij iedere wijziging van de organisatie de hele inrichting van beheer moet veranderen, biedt het grote voordelen om onderscheid te maken in de drie beheervormen. Veelal verandert niet de inrichting van zowel het technische beheer als applicatiebeheer en het functioneel beheer, maar hooguit één van de drie.

2.4 Gemeenschappelijk belang Het functioneel beheer opereert feitelijk als opdrachtgever. Applicatiebeheer en het technische beheer zijn opdrachtnemers. Maar alle beheerdomeinen (technische, applicatie, functioneel beheer) dienen uiteindelijk hetzelfde doel: een optimale ICT-ondersteuning van het bedrijfsproces gedurende de gehele levenscyclus van het bedrijfsproces. Hierbij is de wijze waarop invulling gegeven wordt aan het bedrijfsproces zelden statisch en is zelfs continu in beweging. De markt verandert, de keten waarin de organisatie beweegt verandert, de wet- en regelgeving verandert, er is sprake van groei. Er blijven steeds nieuwe wensen komen over de dienstverlening of de producten die de organisatie levert. Ook de ICT is steeds in beweging: nieuwe technologieën dienen zich aan. Een optimale ondersteuning van het bedrijfsproces zal er dus steeds anders uitzien. Het is van belang om ook van strategisch tot uitvoerend niveau aandacht te besteden aan samenwerking, relaties en veranderingen in de beheersprocessen om die optimale ondersteuning vorm te kunnen geven.

2.5 Samenhang De verschillen tussen de beheervormen worden weliswaar in het model van Looijen benadrukt, maar beheer werkt alleen goed in samenhang. De effectiviteit van het totale beheer is optimaal als de beheerdomeinen samenwerken waar dat nodig is en zelfstandig opereren waar dat kan (Meijer en Meijers15). Het verband tussen de beheerdomeinen wordt enerzijds gevormd, doordat technologische componenten onderling gekoppeld zijn (zoals een applicatie die draait op een netwerk) en anderzijds door een aantal beheersprocessen. Alle vormen van beheer hebben tot doel een bepaald bedrijfsproces zo optimaal mogelijk met ICT te ondersteunen, zij opereren dus in elkaars omgeving. Daarmee is gelijk ook gezegd dat, zowel binnen een beheersdomein als tussen de beheersdomeinen: 15 Meijer M., Meijers (2002), “Effectief IT Beheer: samenwerken waar nodig, zelfstandig opereren waar mogelijk”, IT beheer jaarboek 2002.

16/49

Versie 1.0 d.d. 14-11-2005




beheersprocessen op elkaar moeten aansluiten, en integraal worden gemanaged




mensen uit de verschillende domeinen moeten samenwerken

Activiteiten die in alle drie domeinen spelen en waarbij goede samenwerking vereist is, zijn bijvoorbeeld:


Het dagelijks draaiend houden (dagelijks beheer, exploitatie, gebruik) van informatiesystemen




Servicecall-afhandeling; (het verhelpen van verstoringen, die voor een groot deel worden aangemeld vanuit het functioneel beheer, vereist bijvoorbeeld regelmatig samenwerking tussen applicatiebeheerders en technische beheerders)




Het doen van aanpassingen (van wensen verzamelen, consequenties in kaart brengen en specificaties opstellen tot en met invoer van geteste applicaties en hardware)




Strategievorming / strategic business ICT alignment

2.6

Een analyse van het model van Looijen

De vraag die nu gesteld kan worden is (indien wij het beheer inrichten volgens het model van Looijen) of wij het beheer van een ICT-systeem goed geregeld hebben? Het antwoord hierop is neen. Het model van Looijen maakt onderscheid in drie dimensies: functioneel, technisch en applicatiebeheer. Daarnaast wordt voor elke dimensie conform het logo van Mintzberg een onderscheid gemaakt tussen strategisch, tactisch en operationeel niveau. Het zwaartepunt ligt met name op de inrichting van de organisatie die belast is het met het beheer en is intern gericht.

Een belangrijke tekortkoming in het model van Looijen is het ontbreken van een extra dimensie: de klant van het systeem. In het model wordt de relatie van de beheerorganisatie met de klant van het systeem niet in kaart gebracht. De klant is gebaat bij een goedwerkend systeem. Hij verwacht een goede dienstverlening van de leverancier. De processen van de leverancier moeten vooral afgestemd zijn op de eisen c.q. wensen van de klant. Het systeem moet dus ook extern gericht zijn. Hoe kan deze tekortkoming nu ondervangen worden ?

2.7

De 4e dimensie

Het drievoudige model van beheer van Looijen stamt uit 1995. De werkzaamheden van de ICT-branche waren op dat moment met name intern gericht. Je kunt stellen dat de ontwikkelingsfase volgens het INK-model16 van de ICT midden negentiger jaren in fase 16

INK-management model van het Instituut Nederlandse Kwaliteit (INK).

17/49

Versie 1.0 d.d. 14-11-2005

1 – 2 zat. Het toevoegen van een 4e dimensie, de klant, aan het model van Looijen zal de in 2.6 beschreven tekortkoming opheffen. In figuur 2.4 is de 4e dimensie toegevoegd aan het model van Looijen. Het oorspronkelijke model is weergeven in de matrix.

Figuur 2.4: de 4e dimensie

De matrix in figuur 2.4 is de beherende organisatie van een systeem. Dit is omgeven door de klant. De klant is conform de definitie van het onderzoek de repressieve afdelingen. Input voor de beherende organisatie zijn de eisen en wensen van de klanten, vervat in dienstverleningsovereenkomsten die de gebruikers afsluiten met de beherende organisatie. Deze dienstverleningsovereenkomsten wordt in het vakjargon van de ICT veelal SLA’s17 genoemd. In de SLA komen kwaliteitsattributen als beschikbaarheid, betrouwbaarheid, responsetijd en continuïteit aan de orde. Ook de relatie tussen de gebruikers en leverancier staat helder weergegeven. Over de prestaties die zijn vastgelegd in de SLA’s wordt periodiek gerapporteerd. De SLA kan opgesteld worden als een prestatiecontract. Hoe beter de prestatie van de leverancier, hoe hoger de vergoeding voor de dienstverlening die geleverd wordt. Door het definiëren van een nieuwe entiteit in het model, de klant, wordt geborgd dat de klant een duidelijke rol krijgt in het beheerspectrum en dat het systeem gezien wordt als een ondersteuning voor het uitvoeren van het primaire proces van de klant. Het systeem is géén doel op zich, maar een instrument.

Het model van de 4e dimensie wordt in hoofdstuk 3 gebruikt om het beheer van het GMS te toetsen.

17

Service Level Agreement.

18/49

Versie 1.0 d.d. 14-11-2005

3.

Het beheer van het GMS getoetst aan het model van Looijen

In dit hoofdstuk wordt het beheer van het GMS getoetst aan het model van Looijen.

3.1

Beheer van het GMS op strategisch niveau

Het beheer van het GMS op strategisch niveau verschilt voor de drie dimensies (functioneel, applicatie en technisch beheer).

•

Functioneel beheer Keuzes betreffende de inrichting van het functioneel beheer worden gemaakt door het ministerie van BZK. Er is gekozen voor een gedeconcentreerd en gedecentraliseerd concept. (De)centraliseren heeft te maken met het verdelen van de verantwoordelijkheden en de daarbij behorende beslissingsbevoegdheden. Dit moet niet worden verward met (de)concentreren, hetgeen betrekking heeft op de locatie van de automatiseringsmiddelen18. Het functioneel beheer vindt plaats bij iedere regionale brandweer afzonderlijk. De gevolgen hiervan zijn dat tactische keuzes hieromtrent op individuele basis worden gemaakt en deze verschillen dus van regionale brandweer tot regionale brandweer. Hierdoor is er een grote diversiteit ontstaan tussen de verschillende functionele beheerorganisaties. Er vindt weinig onderlinge afstemming plaats en er zijn dus ook weinig synergievoordelen. Tevens wordt bij keuzes hieromtrent door iedere regio weer het wiel opnieuw uitgevonden.

•

Applicatiebeheer Het applicatiebeheer vindt centraal plaats bij de beheerder van het systeem ISC. ISC heeft één centrale opdrachtgever: het Ministerie van BZK. Jaarlijks worden er onderhandelingen gevoerd tussen ISC en het ministerie. ISC beheert een lijst met wensen en eisen ten aanzien van de functionaliteit van het GMS. Deze onderhandelingen leiden tot een jaarwerkplan waarin wordt vastgesteld welke wensen en eisen worden geïmplementeerd. Vreemd in deze situatie is dat ISC, de uitvoerende beheerpartij, onderhandelingen gaat voeren met het ministerie van BZK en dat de gebruikers van de systemen (politie, brandweer en RAV) hierbij geen partij zijn. Uit de interviews met de drie regionale brandweren blijkt dat men van mening is dat de

18

Tan D.S., “De informatiemanagement-matrix“, pag. 4.

19/49

Versie 1.0 d.d. 14-11-2005

wensen c.q. eisen van de brandweer onvoldoende prioriteit krijgen.

•

Technisch beheer Voor keuzes betreffende het technisch beheer geldt in principe hetzelfde als voor het functioneel beheer. Iedere regio kan hier autonoom in besluiten hoe zij hier invulling aan geeft. De centrale invloed van het ministerie van BZK is hier nog geringer dan bij het functioneel beheer. Wel zal men aan bepaalde eisen moeten voldoen die worden gesteld door ISC met betrekking tot het gebruik van hardware platforms en operating systemen. Er is echter nog een verschil: men kan er voor kiezen het technisch beheer onder te brengen bij ISC. ISC sluit daarvoor met de regionale brandweren die dit wensen een contract af. Keuzes die gemaakt worden met betrekking tot redundantie in systemen die noodzakelijk zijn om een bepaalde beschikbaarheid te realiseren kunnen dus verschillen per regio! Dit betekent concreet dat bij een identieke verstoring in de infrastructuur het kan voorkomen dat de ene regio hier wel voorzieningen voor heeft getroffen en de andere niet. Bij de ene regio blijft het GMS in de lucht en bij de andere leidt dit tot uitval. Je kunt dus stellen dat het ontbreekt aan een centrale visie voor het technisch beheer.

Deelconclusies •

Door de strategische keuze voor decentralisatie en van functioneel en technisch beheer op strategisch niveau worden er weinig tot geen synergievoordelen bereikt.

•

Regionale brandweren kunnen onvoldoende invloed uitoefenen op centrale besluitvorming bij het ministerie van BZK over benodigde applicatiewijzingen in het systeem.

3.2 •

Beheer van het GMS op tactisch niveau

Functioneel beheer Het functioneel beheer houdt in het vertalen van de “business-needs” in termen van informatievoorziening. De business-needs zouden mede bepaald moeten worden door de klanten van het systeem. Deze gebruiken immers het systeem voor ondersteuning van hun primaire proces: brandbestrijding en hulpverlening. Iedere regionale brandweer is autonoom bij het inrichten van deze processen. Uit de interviews is gebleken dat de regio’s hier divers mee omgaan. In Zuid-Limburg zijn de repressieve afdelingen onvoldoende betrokken bij het definiëren van de “businessneeds”. De regionale brandweren hebben wel een gezamenlijke functionele werkgroep. Samenwerking op dit gebied is echter vrijblijvend en laat te wensen over.

20/49

Versie 1.0 d.d. 14-11-2005

De hierboven beschreven diversiteit, verschil in kwaliteit en de vrijblijvende samenwerking veroorzaakt een belangrijk risico: een grotere kans op het maken van fouten.

•

Applicatiebeheer Het applicatiebeheer wordt centraal uitgevoerd door ISC. Het probleem waar ISC mee kampt is dat wijzigingsverzoeken niet centraal multidisciplinair worden ingediend. Vaak worden wijzigingen doorgevoerd op verzoek van één discipline die dan weer als negatief worden ervaren door de andere discipline. Vervolgens moeten er dan extra maatregelen worden getroffen om deze negatieve werking te neutraliseren (bijvoorbeeld door middel van configuratie parameters). Er is immers sprake van een geïntegreerd systeem. Men heeft wel een multidisciplinaire gebruikersgroep met vertegenwoordigers van de RAV’s, politie, brandweer, ISC en een onafhankelijke voorzitter. Wijzigingsverzoeken worden echter door iedere discipline individueel ingediend en voor de brandweer zelfs op regionaal niveau. Deze werkwijze ontkracht weer de meerwaarde van de multidisciplinaire gebruikersgroep. Hoewel de interne activiteiten van ISC geen onderdeel zijn van dit onderzoek, blijkt wel uit interviews dat er door de vele wijzigingen een gedrocht van een systeem is ontstaan. Het kost heel veel moeite om de huidige wensen daar in aan te passen. Dit maakt het uitvoeren van applicatiebeheer tot een moeilijke klus.

•

Technisch beheer Technisch beheer zal voornamelijk gericht moeten zijn op het realiseren van de gewenste beschikbaarheid en performance door de business. De gewenste performance zal met name gevraagd worden door de centrale meldkamers. Deze zijn immers de directe gebruikers van het systeem en zijn voor het behalen van hun performance-indicatoren afhankelijk van het systeem. De beschikbaarheid is een bredere verantwoordelijkheid. De repressieve afdelingen zullen hier vooral eisen aan stellen omdat het in werking stellen van het primaire proces geschiedt middels het GMS. Voor de basisvoorzieningen van het technisch beheer stelt ISC een basispakket van eisen waar de inrichting aan moet voldoen. Dit om te kunnen garanderen dat de applicaties “draaien” op de platforms zoals die ingericht zijn door de meldkamers. De keuzes die de meldkamers daarboven maken m.b.t. beschikbaarheid en performance kunnen van meldkamer tot meldkamer verschillen.

21/49

Versie 1.0 d.d. 14-11-2005

Deelconclusies •

Door onvoldoende samenwerking tussen de regionale brandweren op het gebied van functioneel en technisch beheer op tactisch niveau worden er weinig tot geen synergievoordelen bereikt. De gevolgen hiervan zijn: o

Extra manuren gaan verloren aan dezelfde soorten activiteiten die ook in één keer uitgevoerd kunnen worden voor alle regionale alarmcentrales. Voorbeelden hiervan zijn het opstellen van een klachtenprocedure en het inrichten van een documentatiesystematiek voor het beheer.

o

De foutkans wordt groter en daarmee ook de daarmee samenhangende risico‘s.

•

Het indienen van wijzigingsverzoeken is monodisciplinair geregeld. Binnen de brandweerkolom dient iedere regionale brandweer afzonderlijk wijzigingsverzoeken in. De brandweer treedt dus niet als één eenheid op in het multidisciplinaire speelveld, dit in tegenstelling tot de politie. Dit heeft tot gevolg dat wijzigingsverzoeken van de brandweer onvoldoende prioriteit krijgen en dus niet worden uitgevoerd.

•

De werkgroep GMS brandweer heeft onvoldoende mandaat om de gewenste centrale regierol te kunnen vervullen. Iedere regionale brandweer kan haar individuele prioriteiten stellen.

•

De vele wijzigingen in het GMS hebben het oorspronkelijke concept van het GMS verkracht waardoor een moeilijk te beheren systeem is ontstaan. Het oorspronkelijke ontwerp bestaat nog steeds, maar is inmiddels verouderd. Er is zoveel aan gewijzigd ten opzichte van de oorspronkelijke beoogde eindsituatie dat er op een aantal plaatsen een moeilijk onderhoudbare situatie is ontstaan.

3.3

Beheer van het GMS op operationeel niveau

Het beheer op operationeel niveau houdt zich bezig met het dagelijks gebruik van een systeem.

•

Functioneel beheer Het functioneel beheer richt zich op het op de juiste wijze inzetten van de geboden functionaliteit. Er zijn immers meerdere wegen die naar Rome leiden. Oneigenlijk gebruik van functionaliteiten kan bij het uitbrengen van nieuwe versie van programmatuur leiden tot grote problemen. Het oneigenlijk gebruik is immers niet bekend bij de ”bouwers” van het systeem en dus wordt er ook geen rekening mee gehouden. Het functioneel beheer op operationeel niveau geschiedt ook weer op

22/49

Versie 1.0 d.d. 14-11-2005

individueel niveau bij de 25 regionale brandweren. Onderlinge afstemming is onvoldoende en voor vergelijkbare problemen worden de geboden functionaliteiten verschillend ingezet.

•

Applicatiebeheer Het applicatiebeheer houdt zich met name bezig met het instellen van de parameters binnen de mogelijkheden van het systeem. Dit met als doel de gewenste functionaliteit van de gebruikers te realiseren. Dit wordt wederom per regio uitgevoerd en vindt er weinig afstemming over plaatsen. Het komt dus voor dat voor dezelfde problemen verschillende oplossingen worden geïmplementeerd.

•

Technisch beheer Het technisch beheer is verantwoordelijk voor het dagelijks “in de lucht houden” van het systeem. Dit kan zoals reeds aangeven door de meldkamers zelf uitgevoerd worden of centraal door ISC. Kwaliteit en vorm van uitvoering hiervan is zeer divers. De benodigde procedures zijn ook verschillend van kwaliteit en kwantiteit.

Deelconclusie •

Door decentralisatie op operationeel niveau en onvoldoende onderlinge samenwerking is de kwaliteit en inrichting van het operationele beheer zeer divers voor vergelijkbare problematiek. De diversiteit in inrichting kan bij het implementeren van nieuwe releases leiden tot onvoorspelbare problemen.

3.4

De 4e dimensie: klantenrelatie

In mijn rol als grotere klant van het GMS ben ik van mening dat ik onvoldoende betrokken ben bij het beheer van het GMS. Dit wordt onderstaand verder uitgewerkt.

•

Strategisch niveau Op strategisch niveau worden keuzes gemaakt waarbij de klanten onvoldoende zijn betrokken. Uit de beschrijving van de beheerorganisatie in paragraaf 1.3 zou men de conclusie kunnen trekken dat er een heldere, duidelijke beheerorganisatie is, waarbij taken en bevoegdheden helder zijn toebedeeld. De resultaten van de interviews wijzen echter uit dat men veelal niet bekend is met de totale beheerorganisatie en dat men geen overzicht heeft van wie wat doet. Een logisch gevolg hiervan is dat de regionale brandweren onvoldoende de belangen kunnen behartigen van hun klanten.

23/49

Versie 1.0 d.d. 14-11-2005

Het beheer van het GMS wordt grotendeels betaald door het ministerie van BZK. De regionale brandweren betalen slechts een kleine bijdrage voor het beheer. Het ministerie van BZK is echter niet de klant van het systeem. Dit zijn de brandweren van de gemeenten in Nederland. Deze zijn echter onvoldoende betrokken bij besluitvorming omtrent wijzigingsverzoeken. Hiervoor geldt: “wie betaalt bepaalt”.

•

Tactisch niveau De klant heeft geen invloed op de kosten die gepaard gaan met het beheer van het GMS. Zowel niet in positieve als negatieve zin. Er vinden geen financiële rapportages plaats aan de klanten. De prestaties die geleverd worden door de beheerorganisatie worden niet inzichtelijk gemaakt. De klant beschikt dus niet over kengetallen waarmee hij sturing kan geven aan de beheerorganisatie. De rapportages van regionale brandweren over prestaties van de alarmcentrale zijn ook veelal niet voorhanden of van beperkte omvang. Voorbeelden van dit soort rapportages zijn: verwerkingstijd per melding, aantal foutief verwerkte meldingen, aantallen foutief verwerkte wijzigingsverzoeken etc..

•

Operationeel niveau Het operationele niveau heeft betrekking op de relatie tussen de klant en de regionale brandweer. Een voorbeeld hiervan is: hoe moet de klant handelen bij incidenten, bijvoorbeeld het foutief alarmeren van eenheden? Een ander voorbeeld: hoe moeten verzoeken voor wijzigingen worden ingediend bij de regionale brandweren? In sommige regio’s zijn deze procedures beschikbaar en geïmplementeerd. Bij andere regio’s zijn deze niet of deels beschikbaar. De kwaliteit van de procedures is divers en de inhoud verschilt van regio tot regio.

Voor het verbeteren van genoemde punten is het aan te bevelen een entiteit accountmanagement (relatiebeheer) bij de regionale brandweren te definiëren. Deze heeft vervolgens ook als taak het borgen van voldoende inbreng van de brandweer in de beheerorganisatie van het GMS.

Deelconclusies •

Repressieve organisaties hebben te weinig invloed op, en zijn onvoldoende betrokken bij besluitvorming over de ontwikkelingsrichting van het GMS.

•

De klant van het systeem (repressie) betaalt niet de kosten voor het beheer en kan dus ook niet sturen op de output die geleverd wordt door de GMS-beheerorganisatie.

24/49

Versie 1.0 d.d. 14-11-2005

•

Procedures voor het melden van incidenten en wijzigingsverzoeken zijn niet landelijk uitgewerkt. Dit heeft tot gevolg dat iedere regio deze individueel uitwerkt waarbij de kwaliteit in de drie onderzochte regio’s zeer divers is en in een aantal gevallen onvoldoende.

25/49

Versie 1.0 d.d. 14-11-2005

4.

Beheersen van de organisatie middels ITIL

4.1

Inleiding

ITIL is binnen de Nederlandse ICT één van de meest toegepaste beheersmethodieken. ITIL staat voor Information Technology Infrastructure Library19en vindt zijn oorsprong bij de Britse overheidsinstantie CCTA (Central Computer & Telecommunications Agency). De CCTA heeft in de jaren 80 normen en processen geïnventariseerd en beschreven. Dit heeft geresulteerd in een set beste praktijkoplossingen (de zgn. “best practises”) op het gebied van het beheersen van Informatie Technologie en de organisatie daaromheen. Het beoogt een kwaliteitssysteem te zijn voor het beheren van de IT-infrastructuur.

ITIL beschrijft processen, die bij een adequate implementatie de kwaliteit van de dienstverlening voor de afnemers zeker stelt. Je kunt stellen dat je met ITIL het beheer beheerst. Er moet daarbij echter wel aan de nodige randvoorwaarden worden voldaan:


ITIL beperkt zich uitsluitend tot een beschrijving van de beheerprocessen. Uitvoerende IT-taken (ontwikkeling, onderhoud etc.) worden niet beschreven en ook de beheerprocessen aan de gebruikerskant (functioneel beheer) komen niet aan de orde. Deze zijn echter wel beschreven in hoofdstuk 3 van dit onderzoek, waar het beheer van het GMS wordt getoetst aan het model van Looijen. Bij de implementatie van ITIL dienen de beheerprocessen aan de gebruikerskant wel meegenomen te worden om suboptimalisatie te voorkomen. De beheerprocessen aan de gebruikerskant maken wel deel uit van dit onderzoek.




De meest gebruikte procesbeschrijvingen van ITIL stammen nog uit een periode, dat het IT-beheer nog te kampen had met vele kinderziekten en weinig last had van problematiek, die voortvloeit uit een moderne bedrijfsvoering. Het is de kracht van ITIL, dat de processen ook nu nog zeer bruikbaar zijn, maar de accenten, die binnen de procesbeschrijvingen gezet zijn, verdienen tegenwoordig een aangepaste invulling.

Inrichting van het beheer van de informatievoorziening Aan de hand van een stap voor stap opgebouwd model worden de beheerprocessen toegelicht. Conform het gestelde in 1.5 beperkt dit onderzoek zich tot de processen die gerelateerd zijn aan de gebruikersorganisatie.

19

Looijen, Beheer van Informatiesystemen, 6e herziene druk, pag. 283.

26/49

Versie 1.0 d.d. 14-11-2005

Dit zijn: •

service level management

•

wijzigingsbeheer

•

helpdesk

•

relatiebeheer

•

beschikbaarheidsbeheer

•

calamiteitenbeheer

Voor het goed kunnen begrijpen van de theorie wordt gebruikt gemaakt van een aantal voorbeelden die afkomstig zijn van Nedcar, een bedrijf waar ik vanuit mijn functie regelmatig kom. Nedcar produceert personenauto’s voor Mitsubishi en Smart.

4.2

ITIL frontoffice processen

Service level management © ZBC bv

Gebruikersorganisatie

Diensten

ITorganisatie

Figuur 4.1: Relatie gebruikersorganisatie en IT-organisatie (hoofdlijn)

Het basisprincipe van ITIL is, dat de IT-organisatie diensten verleent aan de afnemer tegen gerechtvaardigde kosten. Dat ITIL geen harde koppeling legt tussen de te verlenen diensten en de vergoeding, die hiervoor gegeven wordt, is in deze tijd naïef. Enerzijds kan het ertoe leiden, dat de ITorganisatie zich bijzonder defensief en star gaat gedragen omdat zij weet, dat het honoreren van additionele wensen van de gebruikersorganisatie tot budgetoverschrijding gaat leiden of tot een niet hanteerbare workload voor de medewerkers. Anderzijds wordt de gebruikersorganisatie op geen enkele manier gemotiveerd om de doelmatigheid van haar verzoeken nadrukkelijk te bekijken. Kortom elk mechanisme om tot een spel van

27/49

Versie 1.0 d.d. 14-11-2005

vraag en aanbod te komen en om (weliswaar ten koste van extra middelen) additionele wensen te realiseren ontbreekt. Daarom is het voor beide partijen van wezenlijk belang, dat tegenover het niveau en de omvang van de dienstverlening betalingen (reëel of administratief met kostenplaatsen) staan. Concreet: een koppeling van vraag en aanbod met de financiële middelen. Hierbij wordt budgetten rechtstreeks beschikbaar gesteld aan de IT-organisatie voor de uitvoering van de standaardtaken. De budgetten om projecten uit te voeren en wijzigingen door te voeren worden echter aan de klanten toegekend. De vastlegging van dit standaardpakket en het daarmee gemoeide budget wordt vastgelegd in de overeenkomst (Service Level Agreement), die wordt gesloten tussen budgethouders in de gebruikersorganisatie en service level management binnen de ITorganisatie. Service level management beheert het dienstenniveau. In het service level management weerspiegelt zich de stelling “afspraak is afspraak” en wat krijg ik voor mijn geld20.

© ZBC bv

Gebruikersorganisatie Opdrachtgever Overeenkomst (SLA)

Budget, betaling

Diensten

Service level mgt

ITorganisatie

Figuur 4.2: Relatie opdrachtgever en service level management.

Voorbeeld: Nedcar produceert een bepaald model Smart voor een vastgestelde prijs. Smart wil het front van het model aanpassen. Voor de ontwikkeling hiervan vraagt Smart aan Nedcar een offerte. Na het akkoord gaan met deze offerte voert Nedcar de vooraf gespecificeerde werkzaamheden uit.

Helpdesk Na het afsluiten van de SLA kunnen er twee soorten verstoringen van deze stabiele situatie ontstaan. Op zeker moment kan geconstateerd worden, dat er een (dreigende) 20

Kisters/van Kollenburg, ITIL en dienstverlening, pag. 19.

28/49

Versie 1.0 d.d. 14-11-2005

verstoring is van de afgesproken dienstverlening. Dit noemen we een incident21 en kan door de gebruikersorganisatie gemeld worden aan de helpdesk. Voorbeeld: de serviceorganisatie van Smart meldt bij Nedcar dat wielmoeren afbreken van het nieuwe model SMART dat onlangs in productie is genomen. Vervolgens dient de helpdesk zo snel mogelijk een “fix” te realiseren, zodat het afgesproken service level weer gehaald wordt en de gebruiker zijn werkzaamheden kan voortzetten. Dit impliceert nadrukkelijk, dat de oorzaak van het probleem nog niet weggenomen hoeft te zijn, maar dat is niet de zorg van de helpdesk. Zij dient afgerekend te worden op het aantal calls, dat ze per uur kan verwerken gecombineerd met het aantal incidenten, dat ze zelfstandig kan afhandelen. Voor helpdesks, die uitsluitend een postbus zijn voor tweedelijns support, bestaat in het algemeen weinig waardering.

Wijzigingsbeheer De tweede soort verstoring van de stabiele situatie kan voorkomen, als de gebruikersorganisatie behoefte heeft aan nieuwe of gewijzigde IT-services. Dit heet een wijzigingsvoorstel en kan worden ingediend bij wijzigingsbeheer. Wijzigingsbeheer zorgt voor het zo verantwoord mogelijk doorvoeren van wijzigingen in de vaak complexe ICT-dienstverlening. Hierbij wordt gestreefd naar een zo klein mogelijke kans op verstoringen als gevolg van wijzigingen. In dit proces manifesteert zich de afweging tussen flexibiliteit en stabiliteit22.

Voorbeeld: het in productie nemen van een gewijzigd model door Nedcar.

Het is van cruciaal belang, dat wijzigingsbeheer wordt gescheiden van incidentbeheer omdat:


De realisatie van wijzigingsvoorstellen ten laste komt van de gebruikersorganisatie.




Er geen min of meer sequentiële afwikkeling plaatsvindt, zoals bij de helpdesk, maar een afwikkeling op basis van een prioritering van de gebruikersorganisatie. De ITorganisatie is slechts adviseur.




De realisatie van wijzigingsvoorstellen kan impact hebben op het afgesproken service level (bijvoorbeeld tijdelijke productieverlaging door Nedcar in verband met aanpassingen in de productielijn).

21 22

Kisters/van Kollenburg, ITIL en dienstverlening, pag. 43. Kisters/van Kollenburg, ITIL en dienstverlening, pag. 19.

29/49

Versie 1.0 d.d. 14-11-2005

© ZBC bv

Gebruikersorganisatie Opdrachtgever Overeenkomst (SLA)

Wijziging

Service level mgt

Oplossing

Incident

Wijzigings beheer

fix

Budget, betaling

Diensten

Help desk

ITorganisatie

Figuur 4.3: Incidentbeheer en wijzigingsbeheer.

Uit mijn jarenlange ervaring als manager van diverse ICT-afdelingen blijkt dat slecht ingericht wijzigingsbeheer leidt tot vergaande frustraties bij zowel de gebruikersorganisatie als bij de IT-organisatie. Alleen bij het leveren van de juiste diensten voor de beschikbaar gestelde budgetten, kan de gebruikersorganisatie ervoor kiezen de IT-organisatie de middelen te verstrekken om eventuele via externe inhuur de gevraagde services te leveren.

Relatiebeheer Tenslotte is er nog één proces, dat in hoge mate kan bijdragen aan de effectieve en soepele samenwerking tussen de gebruikersorganisatie en de IT-organisatie. ITIL noemt dit proces relatiebeheer, maar in de huidige tijd ziet men als belangrijkste taak van relatiebeheer, de advisering van de gebruikersorganisatie.

Voorbeelden, waarover relatiebeheer adviseert zijn o.a.:


Toepassing van IT ter verbetering van bedrijfsprocessen




Mogelijkheden en gebruik van nieuwe technologieën




Opzetten en inrichten van projecten




Toepassing van normen en standaards




Opzet en inrichting functioneel beheer




Ideegeneratie voor het oplossen van knelpunten in het bedrijfsproces

Indien deze diensten worden uitgevoerd op verzoek van de gebruikersorganisatie, komen deze kosten ook voor rekening van de gebruikersorganisatie. Als dit op eigen initiatief

30/49

Versie 1.0 d.d. 14-11-2005

plaatsvindt, komt dit voor rekening van de IT-organisatie. © ZBC bv

Gebruikersorganisatie Opdrachtgever Overeenkomst (SLA)

Wijziging

Service level mgt

Oplossing

Incident

Wijzigings beheer

fix

Help desk

Budget, betaling

Diensten

Relatie beheer

ITorganisatie

Figuur 4.4: de 4 frontoffice processen van de IT-organisatie naar de gebruikersorganisatie.

Met deze vier processen zijn de frontoffice processen van de IT-organisatie naar de gebruikersorganisatie genoemd, die als primair aanspreekpunt gelden voor de gebruikersorganisatie.

4.3

Ondersteunende ITIL-processen

Naast de in 4.2 genoemde zichtbare processen voor de gebruikersorganisatie, bevinden zich in de frontoffice ook nog een aantal ondersteunende processen. Voor service level management zijn dit o.a. de processen als beschikbaarheidsbeheer en calamiteitenbeheer.

Beschikbaarheidsbeheer Het proces beschikbaarheidsbeheer richt zich op het beschikbaar stellen en houden van informatiesystemen en de hiermee in verband staande dienstverlening overeenkomstig afgesproken kwaliteitsniveaus23.

23

Looijen, Beheer van informatiesystemen, 6e herziene druk, pag. 100.

31/49

Versie 1.0 d.d. 14-11-2005

Figuur 4.5: ondersteunende ITIL-processen.

Calamiteitenbeheer Onder calamiteitenbeheer vallen die activiteiten, die gericht zijn op het in stand houden of herstellen van de continuïteit van het functioneren van de ICT-systemen na uitval door bijvoorbeeld brand, natuurrampen en terreuraanslagen. De oorzaak van deze verstoringen ligt buiten de informatiesystemen24.

24

Looijen, Beheer van informatiesystemen, 6e herziene druk, pag. 76.

32/49

Versie 1.0 d.d. 14-11-2005

5.

De beheersprocessen van het GMS

In dit hoofdstuk worden de ITIL beheersprocessen, zoals beschreven in hoofdstuk 4, uitgewerkt voor het GMS. Tevens vindt er een kwaliteitstoets plaats. De opbouw van dit hoofdstuk is analoog aan de opbouw van het theoretisch kader van hoofdstuk 4.

5.1

Service level management

Service level management is het vastleggen van een standaardpakket werkzaamheden in een SLA. Dit SLA wordt afgesloten tussen de budgethouders in de gebruikersorganisatie en de IT-organisatie. Het gaat om een dienstverlening die niet alleen gekenmerkt wordt door een kwantificering van de geformuleerde diensten, maar tevens gekenmerkt wordt door een kwalificering van de diensten25. De SLA’s worden afgesloten tussen ISC en het ministerie van BZK. Het betreft een standaard SLA die voor iedere regio identiek is en het beheer van de software van het GMS behelst. Daarnaast kan iedere regio individueel nog een additioneel SLA afsluiten voor het beheer van de infrastructuur (hardware) die nodig is voor het GMS. De onderhandelingen met ISC over de SLA worden gevoerd door de begeleidingscommissie. Zoals beschreven in paragraaf 1.3 komt de klant in de gedefinieerde beheerorganisatie formeel niet voor. Dit moet iedere regio individueel regelen en borgen. Door de grote gelaagdheid in de beheerorganisatie én het multidisciplinaire karakter is de invloed die de klanten kunnen uitoefenen op de SLA en de inhoud hiervan veel te klein26. Zoals u kunt lezen uit het voorgaande kan het beheer van het GMS opgedragen zijn aan meerdere partners. Voor het beheer van de infrastructuur kunnen de regionale brandweren zelf keuzes maken voor een beherende partij. Zij kunnen dus ook zelf de inhoud van een SLA bepalen die met deze partij wordt afgesloten. Hierdoor kan de kwaliteit van dienstverlening per regio verschillen, daar er landelijk geen minimum niveau is vastgesteld, en dat voor één van de belangrijkste ondersteunende processen bij crisisbeheersing en rampenbestrijding. Bovendien worden hierdoor weinig synergievoordelen behaald door de regio’s gezamenlijk.

Deelconclusies •

De invloed die de klant kan uitoefenen op het tot stand komen van een SLA en de inhoud ervan is in de huidige beheerorganisatie onvoldoende.

25 26

Looijen, Beheer van informatiesystemen, 6e herziene druk, pag. 245. Commissie repressie, regionale brandweer Zuid-Limburg.

33/49

Versie 1.0 d.d. 14-11-2005

•

Er is landelijk géén minimum kwaliteitsniveau van de dienstverlening vastgesteld voor het beheer van het GMS. Dit vormt een potentieel risico voor de beschikbaarheid van de systemen. Het totale niveau van dienstverlening van het GMS kan per regio verschillen door individuele keuzemogelijkheden met betrekking tot beheer.

•

Er worden door de regionale brandweren nagenoeg geen synergievoordelen behaald als gevolg van de individuele keuzemogelijkheden met betrekking tot beheer.

5.2

Helpdesk

De helpdesk is het aanspreekpunt voor de gebruiker wanneer hij problemen ondervindt door te werken met het systeem of de gevolgen van het systeem. De afnemer kan bijvoorbeeld constateren dat er een foutieve alarmering heeft plaatsgevonden bij een calamiteit. Hiervoor dient hij contact op te nemen met de regionale alarmcentrale. Hoewel dit proces voor de 25 regionale brandweren hetzelfde kan zijn, is hier geen landelijke leidraad voor. De drie geïnterviewde regio’s hebben hiervoor hun eigen procedures geïmplementeerd. De kwaliteit van deze procedures is wisselend en laten vaak te wensen over. Op haar beurt kan de regionale brandweer problemen ondervinden met de werking van het GMS. Hiervoor kan men contact opnemen met de helpdesk van ISC. Hier wordt het incident geregistreerd en wordt geanalyseerd of het daadwerkelijk om een incident handelt. Een incident is elke (dreigende) verstoring van de afgesproken dienstverlening27. Indien het een daadwerkelijk incident is, wordt dit in behandeling genomen en zo spoedig mogelijk verholpen. Uit de interviews is gebleken dat men tevreden is over dit proces.

Deelconclusies •

Het ontbreekt aan één uniforme landelijke procedure voor het melden van verstoringen door de klanten aan de regionale alarmcentrales.

•

In de drie onderzochte regio’s is de kwaliteit van de meldingsprocedure voor verstoringen van wisselende kwaliteit en laat te wensen over.

•

De werking van de helpdesk van ISC is naar tevredenheid van de alarmcentrales van de regionale brandweren.

5.3

Wijzigingsbeheer

In deze paragraaf worden twee processen van wijzigingsbeheer bekeken: het proces van het tot stand komen van een goedgekeurd wijzigingsverzoek en het proces van het 27

Kisters/van Kollenburg, ITIL en dienstverlening, pag. 43.

34/49

Versie 1.0 d.d. 14-11-2005

implementeren van een gewijzigde software versie van het GMS bij de regionale alarmcentrale.

Wijzigingsverzoek Wijzigingsverzoeken door de regionale brandweer kunnen op twee manieren geïnitieerd worden: door de regionale brandweer zelf én/of door de klanten van het systeem. Een mogelijk voorbeeld van een wijzigingsverzoek door de regionale brandweer is het op een andere manier presenteren van het uitrukvoorstel op het scherm van de centralist. Een mogelijk wijzigingsverzoek geïnitieerd door repressie is de tekst op de alarmontvangers standaard voorzien van de gealarmeerde eenheden. Er is voor de regionale brandweren geen uniforme procedure beschikbaar hoe de klanten wijzigingsverzoeken moeten indienen. Er zijn zelfs regio’s waar deze procedure niet beschreven is. Daar waar de procedures beschikbaar zijn, verschillen deze veelal van inhoud en kwaliteit. De regionale brandweer dient het wijzigingsverzoek in bij de helpdesk van ISC. De wijzigingsverzoeken worden gebundeld en besproken in de multidisciplinaire gebruikerscommissie. Deze commissie hanteert een puntensysteem voor het toekennen van prioriteiten aan de verschillende wijzigingsverzoeken. Identieke wijzigingsverzoeken die van alle drie de disciplines af komen krijgen volgens het systeem de meeste punten en daarmee de hoogste prioriteit. Na classificatie komen de wijzigingsverzoeken via het tactisch multidisciplinair overleg bij de begeleidingscommissie. Deze voert jaarlijks onderhandelingen met ISC. In deze begeleidingscommissie zitten ook vertegenwoordigers van het ministerie van BZK als gedelegeerd opdrachtgever. Na afronding van de onderhandelingen zijn de gehonoreerde wijzigingsverzoeken bekend en de daarmee gepaard gaande kosten die betaald worden door BZK.

Wijzigingsverzoeken worden dus niet door de “werkgroep GMS brandweer” ingediend, als vertegenwoordigers van de rode kolom. De brandweer treedt bij dit proces niet als één eenheid naar buiten. Vanwege die reden krijgen wijzigingsverzoeken van de regionale brandweren meestal een lage prioriteit van het systeem en zullen zij waarschijnlijk nooit gehonoreerd worden. Het hierboven geschetst proces is voor de klant van het systeem een proces waar hij nagenoeg geen invloed op heeft, mede omdat hij niet betaalt, maar het ministerie van BZK. De vertegenwoordigers van de brandweer zijn veelal geen ICT-professionals maar brandweerofficieren met beperkte ICT-kennis, die ICT als “bijbaantje” hebben naast hun reguliere werk. De politie daarentegen beschikt over een centrale afdeling Concern

35/49

Versie 1.0 d.d. 14-11-2005

Informatiemanagement Politie (CIP) die werkt met ICT-professionals. Dit heeft tot gevolg dat de invloed die de politie kan laten gelden bij dit proces veel groter is dan die van de brandweer.

Implementatie van een wijziging Het gecontroleerd implementeren van een nieuwe software versie geschiedt normaliter in drie stappen. De eerste stap is de nieuwe software implementeren in een testomgeving. In deze omgeving kunnen de gebruikers van het systeem een testprogramma afwerken om te kijken of alle nieuwe functies zoals die beschreven zijn, werken. Na goedkeuring in deze 1e fase wordt de software geïmplementeerd in de acceptatieomgeving. Kenmerk van de acceptatieomgeving is dat deze volledig identiek is aan de productieomgeving (de omgeving waar de daadwerkelijk operationele versie in beschikbaar wordt gesteld). In deze omgeving kan de volledige functionaliteit getest worden. Na het goed doorlopen van deze fase kan de software worden geïmplementeerd in de productieomgeving en wordt het systeem daadwerkelijk gebruikt.

Hoe worden wijzigingen doorgevoerd in het GMS ? Nadat het ministerie van BZK groen licht heeft gegeven voor de gevraagde wijzigingen gaat ISC deze verwerken in veelal een nieuwe versie van het GMS. Indien de nieuwe versie compleet is wordt deze intern getest bij ISC in een testomgeving, waarna deze versie beschikbaar wordt gesteld aan de regionale alarmcentrales. ISC komt vervolgens op afspraak deze implementeren. Bij de alarmcentrales zijn er twee omgevingen beschikbaar. Echter, er is géén acceptatieomgeving die een volledige kopie is van de productieomgeving. Dit betekent dat nieuwe software van het GMS geïmplementeerd moet worden in de productieomgeving zonder dat deze een volledige acceptatietest heeft doorlopen. Het komt voor dat er na implementatie van een nieuwe versie in de productieomgeving fouten optreden. Denk hierbij aan foutieve alarmering van eenheden, géén alarmering etc.. Tevens zijn er geen van tevoren gedefinieerde testprogramma’s beschikbaar bij de regionale brandweer waarmee op een eenduidige en systematische manier nieuwe versies van het GMS worden getest.

Deelconclusies •

Klanten hebben onvoldoende invloed op besluitvorming over wijzigingsverzoeken omdat zij hier niet voor betalen en onvoldoende betrokken zijn bij de besluitvorming hieromtrent.

•

Het ontbreekt aan één uniforme procedure voor de klanten van het GMS om wijzigingsverzoeken in te dienen bij de regionale brandweer.

36/49

Versie 1.0 d.d. 14-11-2005

•

De rode kolom (brandweer) treedt niet op als één entiteit die gezamenlijk namens de gebruikers wijzigingsverzoeken indient.

•

Binnen de drie geïnterviewde regionale brandweren ontbreekt het aan specifieke ICTkennis binnen de beheerorganisatie, waardoor er onvoldoende invloed kan worden uitgeoefend in het wijzigingsproces.

•

Er is bij de regionale alarmcentrales geen acceptatieomgeving beschikbaar die een volledige kopie is van de productieomgeving voor het testen van nieuwe versies van het GMS voordat deze wordt geïmplementeerd in de productieomgeving.

•

Er zijn géén eenduidige testprogramma’s beschikbaar bij de regionale brandweren voor het gecontroleerd implementeren van nieuwe wijzingen in het GMS.

5.4

Relatiebeheer

Relatiebeheer is het gevraagd en ongevraagd adviseren van de gebruikersorganisatie en er voor zorg dragen dat geleverd wordt wat er geleverd moet worden. Dit proces is van grote invloed op de tevredenheid van de gebruikersorganisatie. Zoals reeds aangegeven in paragraaf 2.6, de 4e dimensie, is het belangrijk dat dit proces als een entiteit in de organisatie terug komt. Een voorbeeld hiervan is een afdeling accountmanagement die als primaire proces relatiebeheer heeft. Een voorwaarde om dit proces goed vorm te geven is dat de leverancier goed op de hoogte is van de bedrijfsprocessen van de gebruiker.

Een voorbeeld van het ongevraagd adviseren is bijvoorbeeld een klant adviseren gebruik te maken van een internetapplicatie voor de communicatie tussen het commando rampterrein en het operationeel team.

Wat is nu bepalend voor de tevredenheid van de gebruiker? Je zou heel pragmatisch kunnen stellen: “Als de leverancier uitvoert wat in zijn contract staat”. Echter, niets is minder waar. Contracten zijn vaak moeilijk leesbaar en het is nagenoeg onmogelijk om alle details te beschrijven in een contract. Het kan dus voorkomen dat een leverancier precies levert hetgeen in het contract staat maar dat de gebruiker toch ontevreden is over de dienstverlening. Een relatiebeheerder van een goede leverancier hoeft na het afsluiten van het contract dit nooit meer uit de kast te halen. De grootste uitdaging voor een relatiebeheerder is het verwachtingspatroon van de klant te managen. Bij het voortschrijden van het proces kan

37/49

Versie 1.0 d.d. 14-11-2005

deze verwachting toenemen28. Indien de leverancier beter presteert dan wat de klant verwacht zal deze per definitie tevreden zijn (zie figuur 5.1).

Figuur 5.1: Tevredenheid (T) = Resultaat (R) – Verwachting (V)29

De geïnterviewde regionale brandweren werken niet met relatiebeheerders. Zij hebben elk op hun eigen manier invulling gegeven aan het proces relatiebeheer. Er zijn regio’s waar een actieve relatie bestaat met de klant en er zijn regio’s waar dit onvoldoende is gerealiseerd. Kwantiteit en kwaliteit van dit proces verschillen wederom per regio. In Zuid-Limburg zijn de klanten ontevreden over de invulling van het relatiebeheer en is het resultaat dus kleiner dan de verwachting.

ISC werkt wel met relatiebeheerders voor de regionale brandweren. Het zwaartepunt van deze medewerkers ligt meer op het managen van het contract dan het gevraagd en ongevraagd adviseren van de klant. Het ontbreekt met name aan het meedenken met de klant voor het oplossen van nieuwe en bestaande problemen. De verwachting van de klant is hierbij ook hoger dan het resultaat.

Deelconclusies •

Het proces relatiebeheer is binnen de geïnterviewde regionale brandweren zeer divers geïmplementeerd en verschilt van kwantiteit en kwaliteit. In Zuid-Limburg is de kwaliteit hiervan onvoldoende.

•

Het zwaartepunt van relatiebeheer bij ISC voor de regionale brandweren ligt op het managen van het contract en minder op het adviseren van de klant en het managen van het verwachtingspatroon.

5.5

Beschikbaarheidsbeheer

Het proces beschikbaarheidsbeheer richt zich op het beschikbaar stellen en houden van informatiesystemen en de hiermee in verband staande dienstverlening overeenkomstig afgesproken kwaliteitsniveaus. Hoe hoger de gewenste beschikbaarheid hoe hoger de

28 29

De Bruijn, Ten Heuvelhoff, In ’t Veld, Procesmanagement, pag. 157. Bedrijfsfilosofie Kembit Automatisering, Wijnandsrade.

38/49

Versie 1.0 d.d. 14-11-2005

kosten die in rekening worden gebracht door de opdrachtnemer. Een wens voor een beschikbaarheid van 100% is niet haalbaar en derhalve irreëel. De regionale alarmcentrales zullen dus een keuze moeten maken met betrekking tot de gewenste beschikbaarheid van het GMS. Deze is bij de geïnterviewde regio’s niet gemaakt. Het moge duidelijk zijn dat de totale beschikbaarheid bepaald wordt door een groot aantal ITIL processen zoals beschreven in dit hoofdstuk. Een sprekend voorbeeld hiervan is het proces wijzigingsbeheer. Indien er op een onjuiste wijze een nieuwe versie van het GMS wordt geïnstalleerd op de productieomgeving kan dit leiden tot het geheel of gedeeltelijk uitvallen van het systeem. Het proces beschikbaarheidsbeheer heeft een tweeledige functie. Enerzijds het bewaken van de beschikbaarheid zoals afgesproken in de SLA en anderzijds het rapporteren hierover aan de klant van het systeem. Metingen voorzien de managers van waardevolle en actuele informatie over de prestaties van de onderneming, die ze kunnen gebruiken voor een effectieve besluitvorming en de verbetering van de bedrijfsprestaties30. Belangrijk is wel dat de meetsystemen de juiste gegevens meten. De informatie moet uiteindelijk leiden tot kengetallen waarmee gestuurd kan worden. Kortom, meten leidt niet altijd tot weten31. De klanten van het systeem ontvangen van de regio’s die geïnterviewd zijn voor dit onderzoek géén rapportages over de beschikbaarheid van het GMS (de regionale brandweren ontvangen van ISC wel week- en maandrapportages). Dit komt mede omdat er géén SLA’s zijn afgesloten tussen de klanten van het systeem en de regionale brandweren. De regionale brandweren hebben op hun beurt weer te maken met enerzijds de leverancier en beheerder van de software, ISC, en anderzijds de instantie die de hardware beheert. Dit beheer kan uitgevoerd worden door de regionale brandweren zelf of derden, zij zijn vrij hierin te kiezen. Het integraal bewaken van de beschikbaarheid van het GMS systeem vindt bij de onderzochte regionale brandweren niet plaats.

Deelconclusies •

Er wordt niet gerapporteerd over de beschikbaarheid en de prestaties van het GMS door de regionale brandweren aan hun klanten, bijvoorbeeld het aantal meldingen binnen 1 minuut verwerkt.

•

Het proces beschikbaarheidsbeheer is bij de regio’s die deel uit maken van dit onderzoek niet geïmplementeerd.

30 31

Hammer, De agenda, pag. 97. Hammer, De agenda, pag. 97.

39/49

Versie 1.0 d.d. 14-11-2005

5.6

Calamiteitenbeheer

De grens tussen beschikbaarheidsbeheer en calamiteitenbeheer is een niet helder te definiëren grens. In dit onderzoek richt calamiteitenbeheer zich met name op een grote verstoring in de infrastructuur. Bijvoorbeeld door een terreuraanslag is een regionale alarmcentrale volledig buiten gebruik gesteld. Dit kan zowel door een calamiteit in de alarmcentrale zelf als in de infrastructuur waarop de alarmcentrale is aangesloten. Denk bijvoorbeeld aan de koppeling van het GMS met het C2000 netwerk. Een belangrijk kenmerk van een calamiteit is dat de verwachte tijd die nodig is voor het oplossen van het probleem lang zal zijn. Concreet: de verwachting is dat de alarmcentrale langer dan 1 dag en zelfs weken buiten dienst zal zijn. Voor dit soort calamiteiten zijn er geen landelijke noodprocedures! Iedere alarmcentrale regelt hiervoor zelf een aantal zaken. Deze beperken zich echter meestal tot procedures in het kader van beschikbaarheidsbeheer. Van de drie geïnterviewde regionale brandweren beschikt géén enkele regio over een volledige continuïteitsplanning. Continuïteitsplanning is het van tevoren zeker stellen dat de kritische bedrijfsprocessen binnen een bepaalde tijdsduur weer beschikbaar zijn na een calamiteit32. Onderdeel van een continuïteitsplan kan een uitwijkvoorziening zijn. Uitwijk betekent dat er op een locatie een volledige kopie van de systemen van de alarmcentrale wordt ingericht binnen een van tevoren vastgesteld tijdspad. Deze omgeving neemt dan de oorspronkelijke functie van de alarmcentrale die buiten gebruik is over. Voor de regionale alarmcentrales zijn geen uitwijkvoorzieningen getroffen. Dit betekent dat ten tijde van een hiervoor beschreven calamiteit het niet mogelijk is de hulpverleningsdiensten te alarmeren van de desbetreffende regio! De regionale brandweren vragen zich af waarom er niet is gekozen voor een landelijk ontwerp van alle alarmcentrales gezamenlijk waarbij in het ontwerp zelf er al rekening mee is gehouden dat de ene alarmcentrale ook als volledige back-up kan fungeren voor de andere alarmcentrale. De financiële middelen van iedere regionale brandweer individueel zijn onvoldoende om dit soort voorzieningen te treffen. Gezamenlijk zou dit wel gerealiseerd kunnen worden tegen veel minder meerkosten.

Deelconclusies •

Regionale brandweren beschikken niet over een uitwijkvoorziening voor hun alarmcentrales en zijn niet of onvoldoende voorbereid op een calamiteit.

•

Het ontbreekt aan een landelijk ontwerp voor uitwijkvoorzieningen van de alarmcentrales.

32

Oud E. J., “Noodprocedures en noodzaak tot testen”.

40/49

Versie 1.0 d.d. 14-11-2005

6.

Conclusies en aanbevelingen

Als ik zie tot welke grote gevolgen kleine dingen kunnen leiden, denk ik wel eens.…….. er bestaan helemaal geen kleine dingen. BRUCE BARTON33

In dit hoofdstuk worden de conclusies geformuleerd van dit onderzoek. Daarnaast wordt de centrale vraag beantwoord. Iedere conclusie start met een inleidende vraag. Bij beantwoording wordt rekening gehouden met de theoretische kaders zoals weergegeven in de hoofdstukken 2 en 4. De conclusies en de aanbevelingen komen voort uit de beschrijvingen en analyses van de hoofdstukken 3 en 5.

6.1

Conclusies

Conclusie 1 Uit het onderzoek is gebleken dat er sprake is van deconcentratie. Er zijn 25 regionale brandweren die allen beschikken over een alarmcentrale met het GMS. Wat is de rol van de huidige schaalgrootte van de alarmcentrales op het beheer? Op dit moment zijn er 25 regionale brandweren die beschikken over een eigen of multidisciplinaire meldkamer. Het technisch beheer is een verantwoordelijkheid van iedere regio zelfs. Er worden door onvoldoende samenwerking nagenoeg géén synergievoordelen bereikt: iedere regio vindt voor dezelfde werkzaamheden weer opnieuw het wiel uit. Hetzelfde wordt geconcludeerd voor de noodzakelijke beheerprocedures tussen de klant (repressie) en de regionale alarmcentrales. Uit dit onderzoek is gebleken dat er geen uitwijkfaciliteiten zijn geregeld voor de regionale alarmcentrales. Dit is behoorlijk complex en vergt een kapitaalintensieve investering om dit te realiseren door het grote aantal alarmcentrales. Tijdens mijn stage in Australië heb ik één van de twee alarmcentrales van de staat New South Wales bezocht. Deze staat is 20 x groter dan Nederland qua grondoppervlak en er wonen 6 miljoen mensen. Uit interviews is gebleken dat zij geen nadelige gevolgen ervaren door de gekozen schaalgrootte. Indien de ene alarmcentrale volledig buiten werking wordt gesteld door bijvoorbeeld een terreuraanslag kan de andere alarmcentrale direct de volledige functionaliteit overnemen. De twee alarmcentrales vormen samen één organisatorische eenheid, hetgeen met name in het beheer van de ICT-systemen leidt tot grote synergievoordelen. De gekozen schaalgrootte biedt vele voordelen op het gebied van standaardisatie en professionalisering. 33

Stephen R. Covey, de zeven eigenschappen van effectief leiderschap, pag. 263.

41/49

Versie 1.0 d.d. 14-11-2005

De uitkomsten van dit onderzoek pleiten voor schaalvergroting van de alarmcentrales.

Conclusie 2 Een andere constatering is dat het beheer van het GMS gedeeltelijk is gecentraliseerd en gedeeltelijk gedecentraliseerd. Wat is de invloed van deze combinatie van centralisatie en decentralisatie op het beheer van het GMS? Het applicatiebeheer wordt centraal uitgevoerd door ISC. Alle overige beheeraspecten zijn gedecentraliseerd. Mede om de nadelen van decentralisatie te compenseren is een landelijk concept van een beheerorganisatie opgesteld. De werking van deze beheerorganisatie laat echter te wensen over. Door de decentralisatie wordt het beheer in de onderzochte regio’s zeer divers uitgevoerd met wisselende kwaliteit. Ondanks dat de kosten die gemoeid gaan met het beheer van het GMS niet zijn onderzocht kan gesteld worden dat er aanzienlijke besparingen mogelijk zijn door het centraliseren van het beheer.

Conclusie 3 Is het brandweerpersoneel bij de regionale brandweren voldoende opgeleid voor het uitvoeren van het beheer van het GMS? Het overgrote deel van de medewerkers van de brandweer die betrokken zijn bij het beheer van de ICT-systemen is géén ICT-professional,dit in tegenstelling tot de politie. In de door mij onderzochte regio’s zijn de medewerkers van de brandweer veelal opgeleide brandweerofficieren die als “bijbaantje” ICT in hun pakket hebben. Het GMS is de “aorta” van het meldkamerdomein. Aan een aorta hoort alleen gewerkt te worden door een medisch specialist. Een module hoofdbrandmeester ICT maakt van een brandweerofficier absoluut geen ICT-professional. De geconstateerde tekortkomingen in het beheer van het GMS zijn mede te wijten aan de beperkte “skills” van de betrokken beheermedewerkers.

Conclusie 4 Hebben de klanten (repressieve diensten) voldoende invloed op de beheeraspecten van het GMS zodat het primaire proces afdoende wordt ondersteund door het systeem? Uit dit onderzoek is gebleken dat de invloed van de klanten op het beheer van het GMS als onvoldoende wordt ervaren. Veelal wordt de regionale alarmcentrale als enige gebruiker van het systeem gezien. Dit terwijl zij, samen met een aantal ICT-systemen waaronder het GMS, ondersteunend zijn voor het primaire proces van de repressieve afdelingen: brandbestrijding, hulpverlening en rampenbestrijding.

42/49

Versie 1.0 d.d. 14-11-2005

Wijzigingsverzoeken van klanten dringen door de inrichting en de organisatie van het beheer vaak niet door tot het orgaan waar besluitvorming plaatsvindt.

Conclusie 5 – de centrale vraag Hoe is bij de brandweer het beheer georganiseerd van het geïntegreerd meldkamer systeem en welke verbeterpunten zijn er? De beheerorganisatie van het GMS is behoorlijk complex. Dit wordt mede veroorzaakt doordat het een multidisciplinair systeem is. Er is sprake van een gedeconcentreerd en gedecentraliseerd technisch- en functioneel beheer. Applicatiebeheer is gecentraliseerd en geconcentreerd bij het ministerie van BZK en ISC. Het beheer van het GMS is op dit moment onvoldoende. Uit dit onderzoek blijkt dat er een groot aantal tekortkomingen is in het beheer van het systeem. Een voorbeeld: gezien de recente terreurdreigingen ligt het voor de hand dat een alarmcentrale door criminele organisaties als een potentieel doelwit wordt gezien. Bij een aanslag op een alarmcentrale waarbij de infrastructuur geheel of gedeeltelijk beschadigd raakt is er geen uitwijkvoorziening beschikbaar. Concreet: de brandweer van het verzorgingsgebied waarin de aanslag heeft plaatsgevonden kan niet gealarmeerd worden. De klant, de afdeling repressie, heeft onvoldoende invloed op het beheer van het GMS. Veelal wordt de regionale alarmcentrale gezien als de gebruiker van het systeem. Zij vormen echter een onderdeel van het systeem dat het primaire proces van de brandweer ondersteunt. Relatiebeheer met de klanten is vaak niet of onvoldoende geïmplementeerd. In dit onderzoek zijn met name de klantgerelateerde beheerprocessen onderzocht. Zowel de implementatie als de kwaliteit laten bij de onderzochte regio’s te wensen over. Er zijn onvoldoende landelijke richtlijnen beschikbaar en iedere regionale brandweer werkt deze op haar eigen wijze uit. Vergelijkbare conclusies staan voor de politie in het rapport “Lokaal verankerd, nationaal versterkt”34. Ondanks een gebruikersgroep van de brandweer in de beheerorganisatie wordt er onvoldoende samengewerkt. Dit wordt wellicht mede veroorzaakt door het groot aantal non ICT-professionals in de beheerorganisatie van de brandweer.

Gezien het groot aantal geconstateerde tekortkomingen kan de vraag gesteld worden welk risico de samenleving hiermee loopt? Er zijn een tweetal ramppathogenen van toepassing35:

34 35

Stuurgroep Evaluatie Politieorganisatie (commissie Leemhuis) “Lokaal verankerd, nationaal versterkt”. Crisis Onderzoek Team Universiteit Leiden, Crisis, pag. 22.

43/49

Versie 1.0 d.d. 14-11-2005

•

Rampen hebben te maken met gebreken en slordigheden in de organisatie, die ertoe leiden dat rampzalige ontwikkelingen niet tijdig worden gekeerd36.

•

De verklaring van rampen kan gezocht worden in de risicodragende kenmerken van technologische systemen waarmee de organisaties werken37.

Het uitvallen van een regionale alarmcentrale ten tijde van een crisis mag als een ramp worden betiteld. Het is de vraag of bestuurders dit risico bewust willen lopen in de huidige “zero tolerance maatschappij”38 .

6.2

Aanbevelingen

Aanbeveling 1 Het starten van een onderzoek naar de gewenste schaalgrootte van de alarmcentrales in Nederland. De conclusies uit dit onderzoek vanuit de ICT optiek pleiten voor schaalvergroting van de alarmcentrales.

Aanbeveling 2 Centraliseren van het beheer van het GMS. Door centralisatie kunnen onder andere de volgende synergievoordelen worden geboekt: •

Eenduidige procedures voor beheer voor alle alarmcentrales

•

Kwaliteitsverhoging en borging

•

Kostenbesparingen

Aanbeveling 3 De spilfuncties die bij de brandweer betrokken zijn bij het beheer van het GMS invullen door ICT-professionals.

Aanbeveling 4 Definieer de klant van het GMS als een aparte entiteit van de gebruikersorganisatie en draag zorg voor een uniforme implementatie van de ITIL-processen inclusief de klantrelatie.

36 37 38

Turner, 1976; Turner en Pidgeon 1997. Perrow, 1984. Prof. dr. U. Rosenthal, college MCDM November 2005.

44/49

Versie 1.0 d.d. 14-11-2005

Aanbeveling 5 Richt een acceptatieomgeving in die een volledige kopie is van de productieomgeving voor het gecontroleerd doorvoeren van wijzigingen. De kans op verstoring in de productieomgeving van het GMS wordt hierdoor aanzienlijk verkleind. Met de huidige schaalgrootte is dit een kostbaar proces. Dit pleit wederom voor schaalvergroting.

Aanbeveling 6 Een zeer urgent probleem is het ontbreken van uitwijkfaciliteiten voor de regionale alarmcentrales. Door de toenemende terreurdreiging kan een regionale alarmcentrale worden gekwalificeerd als een risico-object. In Australië zijn recent alle gebouwen van de brandweer geclassificeerd als risico-objecten vanwege de toenemende terreurdreiging. Hier dient acuut een project voor gestart te worden. Een uitwijkvoorziening realiseren voor de 25 regionale alarmcentrales is een kostbare zaak. Dit pleit wederom voor schaalvergroting.

Samenvatting aanbevelingen De uitkomsten van dit onderzoek pleiten voor schaalvergroting, standaardisatie, centralisatie, professionalisering en implementatie van alle benodigde beheerprocessen voor het beheer van het GMS. Middels schaalvergroting zijn standaardisatie, centralisatie en professionalisering eenvoudiger te bereiken dan bij de huidige schaalgrootte. Door standaardisatie kunnen de kosten voor het beheer aanzienlijk worden gereduceerd. Centralisatie zal nodig zijn voor ontwikkeling van de focus op de eigen regio naar het meer en meer over de regiogrenzen heenkijken en samenwerken. Hiermee kan standaardisatie en professionalisering eenvoudiger worden doorgevoerd. Tevens kunnen dwingende voorschriften worden opgelegd voor de implementatie van de beheerprocessen. Last but not least professionalisering van de beheermedewerkers. Dit is dé kritische succesfactor voor het doorvoeren van bovengenoemde aanbevelingen en het volgen van de laatste technologische ontwikkelingen.

45/49

Versie 1.0 d.d. 14-11-2005

Literatuurlijst. Buuren, H., van./Hummel, H./

Onderzoek de basis, 2e druk, Groningen/

Berkhout, J./Slootmaker A.

Houten, 2003.

Bruijn de, H./Heuvelhof ten, E./

Procesmanagement, over procesontwerp en

Veld in ‘t, R.,

besluitvorming, 2e herziene druk, Den Haag, maart 2004.

Crisis Onderzoek Team

Crisis, oorzaken gevolgen, kansen, 1e druk, Leiden

Universiteit (COT) Leiden,

1998.

Covey, Stephen R.,

De zeven eigenschappen van effectief leiderschap, 21e druk, Amsterdam, juni 2002.

Hammer, M.,

De agenda, wat elk bedrijf moet weten om succesvol te blijven, New York, 2001.

Looijen, M.,

Beheer van informatiesystemen, 6e herziene druk, Den Haag, 2004.

Kisters, H./Kollenburg, E. van.,

ITIL en dienstverlening, een belofte voor het MKB en non-profit organisaties, 1e druk, Schoonhoven, 2003.

Meijer, M./ Meijers J.,

Effectief IT beheer: samenwerken waar nodig, zelfstandig opereren waar mogelijk, IT beheer jaarboek 2002, 1e druk, Den Haag, 2002.

Oud, E.J.,

“Noodprocedures en de noodzaak van testen”, lezing tijdens het NGN congres 1998.

Rijsenbrij, D.B.B.,

Stuurgroep Evaluatie Politieorganisatie, Tan, D.S.,

46/49

“Automatisering van de informatievoorziening”, Internet: http://home.hetnet.nl/~daanrijsenbrij/ebi/nl d.d. 29-10-05. “Lokaal verankerd, nationaal versterkt”, Den Haag, juni 2005. “De informatiemanagement-matrix”, I&I 1994, nr. 1.

Versie 1.0 d.d. 14-11-2005

Bijlage 1. Totaaloverzicht deelconclusies. Deelconclusies hoofdstuk 3. 1. Door de strategische keuze voor decentralisatie en van functioneel en technisch beheer op strategisch niveau worden er weinig tot geen synergievoordelen bereikt. 2. Regionale brandweren kunnen onvoldoende invloed uitoefenen op centrale besluitvorming bij het ministerie van BZK over benodigde applicatiewijzingen in het systeem. 3. Door onvoldoende samenwerking tussen de regionale brandweren op het gebied van functioneel en technisch beheer op tactisch niveau worden er weinig tot geen synergievoordelen bereikt. De gevolgen hiervan zijn: a. Extra manuren gaan verloren aan dezelfde soorten activiteiten die ook in één keer uitgevoerd kunnen worden voor alle regionale alarmcentrales. Voorbeelden hiervan zijn het opstellen van een klachtenprocedure en het inrichten van een documentatiesystematiek voor het beheer. b. De foutkans wordt groter en daarmee ook de daarmee samenhangende risico‘s. 4. Het indienen van wijzigingsverzoeken is monodisciplinair geregeld. Binnen de brandweerkolom dient iedere regionale brandweer afzonderlijk wijzigingsverzoeken in. De brandweer treedt dus niet als één eenheid op in het multidisciplinaire speelveld, dit in tegenstelling tot de politie. Dit heeft tot gevolg dat wijzigingsverzoeken van de brandweer onvoldoende prioriteit krijgen en dus niet worden uitgevoerd. 5. De werkgroep GMS brandweer heeft onvoldoende mandaat om de gewenste centrale regierol te kunnen vervullen. Iedere regionale brandweer kan haar individuele prioriteiten stellen. 6. De vele wijzigingen in het GMS hebben het oorspronkelijke concept van het GMS verkracht waardoor een moeilijk te beheren systeem is ontstaan. Het oorspronkelijke ontwerp bestaat nog steeds, maar is inmiddels verouderd. Er is zoveel aan gewijzigd ten opzichte van de oorspronkelijke beoogde eindsituatie dat er op een aantal plaatsen een moeilijk onderhoudbare situatie is ontstaan. 7. Door decentralisatie op operationeel niveau en onvoldoende onderlinge samenwerking is de kwaliteit en inrichting van het operationele beheer zeer divers voor vergelijkbare problematiek. De diversiteit in inrichting kan bij het implementeren van nieuwe releases leiden tot onvoorspelbare problemen. 8. Repressieve organisaties hebben te weinig invloed op, en zijn onvoldoende betrokken bij besluitvorming over de ontwikkelingsrichting van het GMS.

47/49

Versie 1.0 d.d. 14-11-2005

9. De klant van het systeem (repressie) betaald niet de kosten voor het beheer en kan dus ook niet sturen op de output die geleverd wordt door de GMS-beheerorganisatie. 10. Procedures voor het melden van incidenten en wijzigingsverzoeken zijn niet landelijk uitgewerkt. Dit heeft tot gevolg dat iedere regio deze individueel uitwerkt waarbij de kwaliteit in de drie onderzochte regio’s zeer divers is en in een aantal gevallen onvoldoende.

Deelconclusies hoofdstuk 5. 1. De invloed die de klant kan uitoefenen op het tot stand komen van een SLA en de inhoud ervan is in de huidige beheerorganisatie onvoldoende. 2. Er is landelijk géén minimum kwaliteitsniveau van de dienstverlening vastgesteld voor het beheer van het GMS. Dit vormt een potentieel risico voor de beschikbaarheid van de systemen. Het totale niveau van dienstverlening van het GMS kan per regio verschillen door individuele keuzemogelijkheden met betrekking tot beheer. 3. Er worden door de regionale brandweren nagenoeg geen synergievoordelen behaald als gevolg van de individuele keuzemogelijkheden met betrekking tot beheer. 4. Het ontbreekt aan één uniforme landelijke procedure voor het melden van verstoringen door de klanten aan de regionale alarmcentrales. 5. In de drie onderzochte regio’s is de kwaliteit van de meldingsprocedure voor verstoringen van wisselende kwaliteit en laat te wensen over. 6. De werking van de helpdesk van ISC is naar tevredenheid van de alarmcentrales van de regionale brandweren. 7. Klanten hebben onvoldoende invloed op besluitvorming over wijzigingsverzoeken omdat zij hier niet voor betalen en onvoldoende betrokken zijn bij de besluitvorming hieromtrent. 8. Het ontbreekt aan één uniforme procedure voor de klanten van het GMS om wijzigingsverzoeken in te dienen bij de regionale brandweer. 9. De rode kolom (brandweer) treedt niet op als één entiteit die gezamenlijk namens de gebruikers wijzigingsverzoeken indient. 10. Binnen de drie geïnterviewde regionale brandweren ontbreekt het aan specifieke ICT-kennis binnen de beheerorganisatie, waardoor er onvoldoende invloed kan worden uitgeoefend in het wijzigingsproces. 11. Er is bij de regionale alarmcentrales geen acceptatieomgeving beschikbaar die een volledige kopie is van de productieomgeving voor het testen van nieuwe versies van het GMS voordat deze wordt geïmplementeerd in de productieomgeving.

48/49

Versie 1.0 d.d. 14-11-2005

12. Er zijn géén eenduidige testprogramma’s beschikbaar bij de regionale brandweren voor het gecontroleerd implementeren van nieuwe wijzingen in het GMS. 13. Het proces relatiebeheer is binnen de geïnterviewde regionale brandweren zeer divers geïmplementeerd en verschilt van kwantiteit en kwaliteit. In Zuid-Limburg is de kwaliteit hiervan onvoldoende. 14. Het zwaartepunt van relatiebeheer bij ISC voor de regionale brandweren ligt op het managen van het contract en minder op het adviseren van de klant en het managen van het verwachtingspatroon. 15. Er wordt niet gerapporteerd over de beschikbaarheid en de prestaties van het GMS door de regionale brandweren aan hun klanten, bijvoorbeeld het aantal meldingen binnen 1 minuut verwerkt. 16. Het proces beschikbaarheidsbeheer is bij de regio’s die deel uit maken van dit onderzoek niet geïmplementeerd. 17. Regionale brandweren beschikken niet over een uitwijkvoorziening voor hun alarmcentrales en zijn niet of onvoldoende voorbereid op een calamiteit. 18. Het ontbreekt aan een landelijk ontwerp voor uitwijkvoorzieningen van de alarmcentrales.

49/49

Versie 1.0 d.d. 14-11-2005