Bijlage I:
Stappenplan
Stap 0
CIO-Vraagkantproject stemt in met de onderzoeksstappen zoals die door Werkgroep Nulmeting worden uitgezet.
Stap 1
Uitgangssituatie is dat er totaal geen dienstverlening meer is bij een dienst, doordat er zich een calamiteit heeft voorgedaan. Over de kans (risico) op zulk mogelijke calamiteiten en de verschillende soorten calamiteiten wordt dus niet gesproken. Risico-analyse is namelijk een zeer tijdrovende bezigheid. En een klein risico houdt nog niet in dat een calamiteit nooit kan gebeuren. Deze vorm van “schijnzekerheid” wordt daarom vermeden voor dit onderzoek.
Om het onderzoek af te kunnen bakenen wordt er in de uitgangssituatie vanuit gegaan dat na een calamiteit de nutsvoorzieningen nog werken. En dat de duur van uitval maximaal één week is.
Stap 2 (bespreken met de algemeen directeur van de desbetreffende dienst)
Wat zijn de mogelijke gevolgen door het uitvallen van de totale dienstverlening van een dienst? In het onderzoek naar de Millenniumlijst zijn de gevolgen van het uitvallen van bedrijfsprocessen omschreven in volgorde van belang. Deze criteria zijn in overleg met de algemeen directeuren in 1998 vastgesteld. Bij de toelichting zijn de gevolgen omschreven zoals die in het onderzoek worden geïnterpreteerd.
1= Levensbedreigend
Wanneer het proces staakt, bedreigt dat levens.
2= Voorwaardelijk voor andere processen
De ongestoorde voortgang van het proces is voorwaarde voor de ongestoorde
voortgang van de belangrijkste processen binnen de eigen dienst of bij andere diensten.
3= Sociaal afbreukrisico
Wanneer het proces staakt, brengt dat een groot sociaal afbreukrisico met zich mee.
Het gaat hier om schade aan het imago van de gemeente Groningen.
4= Financiële schade
Wanneer het proces staakt, veroorzaakt dat grote financiële schade.
5= Maatschappelijke ontregeling
Wanneer het proces staakt, veroorzaakt dat maatschappelijke ontwrichting door bijvoorbeeld uitwerking op andere maatschappelijke functies zoals orde en veiligheid.
6= Urgentie
De gemeente kan niet lang leven met de gevolgen wanneer het bedrijfsproces zou staken, met andere woorden het betreft de urgentie van het proces.
7= Geen alternatief
Wanneer het proces staakt is er geen (eenvoudig) alternatief.
Stap 3 (bespreken met de algemeen directeur van de desbetreffende dienst)
Uitval van welke bedrijfsprocessen hebben, in volgorde van belang, de “grootste” gevolgen voor de dienst. Het vaststellen van wat de “grootste” gevolgen zijn, is aan de algemeen directeur van de dienst. Hierbij wordt echter gebruik gemaakt van de in stap 2 omschreven volgorde van mogelijke gevolgen.
De algemeen directeur bepaalt welke beperkte hoeveelheid bedrijfsprocessen nader onderzocht worden. Deze bedrijfsprocessen vormen de belangrijkste dienstverlening van de dienst.
Stap 4 (in samenwerking met de informatiemanager van de desbetreffende dienst)
Welke computertoepassingen (applicaties) worden gebruikt om de bedrijfsprocessen bij stap 3 te kunnen uitvoeren? Welke daarvan zijn noodzakelijk? Voor vaststelling van de noodzakelijkheid zal de applicatie aan de volgende voorwaarden moeten voldoen:
1 de applicatie is onmisbaar om tot een verantwoord eindresultaat van het bedrijfsproces te komen;
2 er zijn geen direct beschikbare alternatieven (digitaal en/of analoog) voor de applicatie.
Vervolgens welke ICT-componenten moet operationeel zijn om de noodzakelijke applicaties te laten functioneren? En wat zijn de organisatorische omstandigheden rond het proces en de noodzakelijke applicatie(s)?
N.B. Als er nog geen idee is bij de dienst over een toekomstige informatiemanager, wordt voor deze dienst het bij de dienst passende lid van het CIO-Vraagkantproject gevraagd.
Stap 5 (in samenwerking met de informatiemanager van de desbetreffende dienst)
Bij meerdere noodzakelijke applicaties per proces wordt de samenhang/startvolgorde van de applicaties bepaald.
Stap 6 (in samenwerking met de concerninformatiemanager en informatiemanagers)
Workshop met de concerninformatiemanager en alle informatiemanagers (cq. leden CIO- Vraagkantproject) om een voorstel te maken hoe van alle afzonderlijke prioriteitenlijsten van de diensten één prioriteitenlijst gemaakt kan worden voor het hele concern.
Bijlage II:
Vragenlijst voor procesuitdieping van de processen met prioriteit
A Procesverdieping (per proces apart)
Algemeen
1. Wie is de verantwoordelijke proceseigenaar (b.v. directielid of afdelingschef)?
2. Welke afdelingen zijn bij dit proces betrokken? Hoeveel werkplekken betreft het totaal ongeveer?
3. Wat zorgt ervoor dat het proces start (“trigger”)? In één korte zin samengevat.
4. Wat is het uiteindelijke doel van het proces? In één korte zin samengevat.
5. Wat zijn de gevolgen als het proces uitvalt?
Gevolgen: Criteria:
Levensbedreigend Binnen een dag/week?
Voorwaardelijk Voor welk proces(sen) met prioriteit binnen eigen dienst / andere dienst en op welke termijn: dag/week?
Sociaal afbreukrisico Bij welke groepen (+ aantallen) burgers wordt imago geschaad en op welke termijn dag/week?
Financiële schade Hoeveel euro per dag/week?
Maatschappelijke ontregeling
Welke groepen (+ aantallen) burgers betreft het en op welke termijn: dag/week?
Geen alternatief Het proces kan niet (in welke mate) op analoge wijze doorgang vinden?
Procesinhoudelijk
6. a) Wat zijn de opvolgende (maximaal 5) stappen (onderdelen) in het proces om van start tot doel te komen in een normale bedrijfssituatie?
b) Worden in een noodsituatie een aantal processtappen achterwege gelaten en/of loopt het proces anders dan in een normale bedrijfssituatie?
7. Welke noodzakelijke/kritische applicatie(s) en/of bestand(en) worden gebruikt in het proces en onder welke processtap is/zijn deze applicatie(s) en/of bestand(en) onder te brengen?
De noodzakelijke/kritische applicaties/bestanden worden in onderdeel B apart verder uitgewerkt.
Aanvullende informatie over het proces
8 Als er een bestand onder 6 genoemde bestand(en) is. Voor welk doel is dit dan:
gegevensraadpleging en/of gegevensmutatie?
9 Als ICT uitvalt moet de applicaties/bestanden dan ook in volgorde in het proces werkzaam zijn?
tabel 7: gevolgen bij calamiteit nader bekeken
10 Zijn er nog bijzonderheden aan het proces? Bijvoorbeeld:
- Buiten de kantooruren moet het proces ook lopen? 24 uur per dag?
- Is de rol van telecommunicatie essentieel voor het proces? Zo ja, welke telefoonverbinding(en)?
- Er wordt gebruik gemaakt van gegevens op papier die essentieel zijn voor het proces komen deze gegevens van een papieren uitdraai uit een bestand/applicatie? Als hier sprake van is, wordt deze applicatie of dit bestand ook onder vraag 6 behandeld.
B (ICT-)Ondersteuning van de applicatie/bestand (per applicatie/bestand apart)
1 Op welke locatie (afdeling(en)) wordt de applicatie/bestand gebruikt?
2 Draait de applicatie/bestand stand-alone of op een server?
3 Wat zijn de desktopgegevens (platform, besturingssysteem) waarop de applicatie/bestand draait? En om hoeveel desktops gaat het?
4 Wat zijn de eventuele servergegevens (locatie, platform, besturingssysteem) waar de applicatie/bestand op draait?
5 Uit welke ICT-objecten (database) haalt de applicatie/bestand zijn gegevens (input)?
6 Naar welke ICT-objecten (database) stuurt de applicatie/bestand zijn gegevens (output)?
7 Is de applicatie/bestand modulair opgebouwd?
8 Welke taken moet de (toekomstige) CIO verrichten voor de (ondersteuning van de) applicatie/bestand? Is hier nog onderscheid tussen taken in een gewone
bedrijfssituatie en taken in een calamiteitsituatie?
9 Zijn er nog bijzonderheden aan de applicatie/bestand? Bijvoorbeeld:
- Voor de werking van de applicatie/bestand in het proces is een GRONET2- aansluiting nodig?
- Wanneer moet de applicatie/bestand operationeel zijn voor het proces (b.v. ook ’s avonds, 24 uur)?
- Voor de werking van de applicatie/bestand in het proces is een deskundige (b.v.
fiunctioneel beheerder) vereist?
- Voor de werking van de applicatie/bestand in het proces is een telecommunicatieverbinding vereist?
Bijlage III:
Pilot
De doelen van de pilot waren als volgt:
1. Eén of meerdere processen uit de voorgestelde concern top-10 van processen met prioriteit volledig uitgewerkt in een procesoverzicht en bijbehorende toelichting opleveren.
2. Nagaan of de opgestelde vragenlijst voor procesuitdieping de antwoorden kan opleveren en of op deze manier (eventueel met aanpassingen) de andere processen met prioriteit ook uitgediept moeten worden.
3. Inzicht krijgen in de tijdsinspanning (zowel bij onderzoeker als ondervraagde dienst) die nodig is om de antwoorden te verkrijgen en hoe dit doorvertaald kan worden qua tijdsinspanning voor een volledige procesuitdieping van de andere processen met prioriteit.
De volgende processen waren geselecteerd voor de pilot:
• "meldkamer" (HVD) contactpersoon: Johan Hamming;
• "verstrekken uitkeringen" (SoZaWe) contactpersoon: Albert Jeuring;
• "begraafplaatsen" (ROEZ) contactpersoon: Hans Sluis.
De uitvoering werd via de contactpersoon van het proces uitgevoerd. Deze contactpersonen zijn benoemd in de eerste interviewronde met de directie van de verschillende diensten. De contactpersoon wees de personen aan die de vragen op de lijst konden beantwoorden voor het te onderzoeken proces en/of applicatie/bestand. De contactpersoon bij de dienst was er verantwoordelijk voor dat de uiteindelijke antwoorden (goedgekeurd) werden opgeleverd binnen de gestelde termijn van drie weken.
Resultaat doel 1:
Een tweetal processen uit de voorgestelde top-10 van processen en volgens de voorgestelde methode (vragenlijst) zijn volledig uitgediept in een procesoverzicht en toelichting volgens de vragenlijst binnen de gestelde termijn. De uitgediepte processen zijn:
“meldkamer” (HVD), “begraafplaatsen” (ROEZ/Stadsbeheer). Echter het proces
“begraafplaatsen” is niet binnen de gestelde termijn goedgekeurd door de contactpersoon.
Het proces “verstrekken van uitkeringen” (SoZaWe) is qua tijdgebrek bij de dienst niet tot volledige uitdieping gekomen. Het procesoverzicht “meldkamer” (HVD) en bijbehorende toelichting zijn op de volgende bladzijden terug te vinden.
Resultaat doel 2:
De vragenlijst (zie bijlage) levert de antwoorden voor de procesuitdieping uiteindelijk op een goede manier op met de volgende kanttekeningen:
- De vraag over de gevolgen bij uitval van het proces behoeft een vrijere motivatie dan in de vragenlijst staat, omdat is gebleken dat het zeer moeilijk is de gevolgen nader te specificeren. De vastgestelde objectieve maatstaven over het soort gevolg (b.v.
levensbedreigend of sociaal afbreukrisico) tezamen met een motivatie is wel haalbaar.
- Er is niet een volledige volgorde qua belangrijkheid gemaakt van de kritische applicaties/bestanden. Wel is aangegeven welke applicaties/bestanden prioriteit hebben binnen de kritische applicaties/bestanden.
- De vraag over welke alternatieven/beveiliging van een applicatie/bestand met prioriteit er op dit moment zijn, is een nuttige aanvulling op het onderdeel B van de vragenlijst.
Resultaat doel 3:
De pilot levert een aantal inzichten op qua tijdsinspanning, zowel bij de onderzoeker (uitvoerende) als ondervraagde dienst. Onderstaande tabel laat een schatting zien van de maximale tijd die het kost om per proces procesuitdieping toe te passen.
Urenoverzicht voor procesuitdieping per proces*
Uitvoerende Dienst Voorbereiding (afspraken regelen, inlezen,
etc.)
1,5 uur 1 uur Uitvoering: - eerste afspraak 2 uur 2 uur - eventuele vervolgafspra(a)k(en) 2 uur 2 uur
Rapportage: 3,5 uur
Controle/aanpassing rapportage: 1 uur 1 uur
Niet toerekenbare tijd: 2 uur 2 uur
Totale tijd: 12 uur 8 uur
* De tijd die hier genoemd wordt, gaat uit van de (mogelijk) maximale tijd die nodig is. Deze tijd kan verkort worden als één of meerdere van de volgende voorwaarden gelden:
• uitgevoerd wordt door een bekende persoon van de dienst en bekend is met de (ICT-)dienstverlening van de dienst (b.v. informatiemanager v/d dienst);
• uitgevoerd wordt door iemand die gewend is procesbeschrijvingen te maken;
• de dienst gewend is te denken in procesbeschrijvingen (zoals bij AO-handboeken);
• binnen de dienst de functionarissen die verantwoordelijk zijn en/of deskundig over het proces en (in relatie tot) de applicatie/bestand duidelijk aanwijsbaar zijn;
• de complexiteit van het proces en/of (in relatie tot) de applicatie/bestand relatief laag is.
Op de volgende bladzijden is het proces met prioriteit ‘meldkamer’ van de Hulpverleningsdienst te zien in een procesoverzicht met aansluitend de toelichtingen erop.
tabel 8: benodigde uren om procesoverzicht en toelichtingen te realiseren uitgesplitst naar activiteiten
Procesnaam: Meldkamer.
Proceseigenaar:
Niek van Leijsen, hoofd meldkamer AB (ambulance);
Thomas Faber, Brandweer Commandant.
Afdeling:
WVD (Waarschuwings Verkennings Dienst) regionale brandweer: Johan Hamming;
Centrale (meldkamer);
Beheer meldkamer.
Aantal werkplekken: 9.
Bijzonderheden:
onderscheid meldkamer: brandweer (BRW), ambulance (CPA);
24 uurs proces;
essentiële telecomverbindingen.
Start:
hulpvraag komt binnen vanuit:
politie (vaste lijn)
Driebergen (mobiele net)
OMS/UGM (openbaar
brandmeldsysteem)
bepalen inzet
(2)
informeren/
begeleiden hulpeenheden (4) alarmeren
melding (3)
Applicatie(bestand)
• GMS
• BUMICON
• RAVIS (CPA)
• FAX
• BRIO
Gebruikte applicatie(s)
crisismana- gement (of GHOR)
Applicatie(bestand)
• GMS
• CityGIS
Applicatie(bestand)
• GMS
• RDCS2000 (BRW en CPA apart)
• Diafraan
• Communicator
Applicatie(bestand)
• ARBI
• OMS (BRW)
• GMS
• RDCS2000
Applicatie(bestand)
ARBI
• GMS
• WAS (BRW)
• Diafraan
• Communicator Applicatie(bestand)
• ARBI
• OMS (BRW)
Gegevenstoevoeging en/of mutatie in applicatie(s)
Applicatie(bestand)
• GMS
• BUMICON
• RAVIS (CPA)
• BRIO meten
radioactieve straling Applicatie(bestand)
• ARBI
• OMS (BRW)
• IDCS
Applicatie(bestand)
• GMS
• GASMAL (BRW)
• CityGIS
• BIG
• Chemie- kaarten
Applicatie(bestand)
• GMS
• RDCS2000 (BRW en CPA apart)
• Omroepsysteem
• Communicator (ook bij crisis- management(/G HOR)
• Diafraan
• BMNI-systeem
Applicatie(bestand)
• ARBI
• OMS (BRW)
• GMS
• RDCS2000
• CityGIS
• BIG
• Chemie- kaarten
Applicatie(bestand):
• ARBI
• GMS
• WAS (BRW)
• GASMAL (BRW)
• PABX
• Diafraan
• Communicator
• Telefoongids
Doel:
- alarmeren, uitzenden en begeleiden van hulpeenheden van ambulance en brandweer bij incidenten;
- alarmeren en informeren van bestuurlijke eenheden en derden.
opnemen/aan- nemen melding
(1)
nazorg (6) waarschuwen/
informeren derden(5)
Procestoelichting: “meldkamer”
Start
Het proces ‘meldkamer’ vangt aan op het moment dat er een hulpvraag binnenkomt. Deze hulpvraag kan binnenkomen uit drie bronnen:
□ politie (vaste lijn);
□ Driebergen (mobiele net);
□ OMS/UGM (openbaar brandmeldsysteem).
Stap 1: Opnemen/aannemen melding
De melding komt binnen via de ARBI als de melder de melding doet via de vaste lijn of via het mobiele net. De melding komt binnen via OMS bij meldingen via het openbare brandmeldsysteem zoals deze in de gebouwen staan.
Stap 2: Bepalen inzet
De melding wordt ingevoerd in GMS en aan de hand van de melding wordt de inzet aan eenheden bepaald. Bij branden wordt in GASMAL gekeken naar de verspreiding van gassen. Via CityGIS wordt bij een melding voor ambulances gekeken waar in Groningen de ambulances zich bevinden.
Stap 3: Alarmeren melding
Nadat ook de inzet voor de melding bepaald is, worden de eenheden gealarmeerd. De alarmering vindt plaats via het omroepsysteem. Contact wordt gehouden met de meldkamer via het RDCS2000 systeem. Met het BMNI-systeem wordt informatie ingewonnen en eventueel gewaarschuwd voor radioactiviteit. Via het communicator-systeem wordt de telefonische communicatie uitgevoerd.
Stap 4: Informeren/begeleiden helpeenheden
De eenheden worden begeleid naar de plaats van melding. Hierbij is de telefooncentrale van de meldkamer (ARBI) betrokken. Het GMS geeft alle nodige informatie, maar wordt ook voor de voortgang van de melding gebruikt. Contacten met de hulpeenheden worden via RDCS2000 onderhouden. CityGIS zorgt voor een juiste locatiebepaling van de ambulances in de meldkamer. Via de chemiekaarten worden de hulpeenheden op de hoogte gehouden van eventuele gevaarlijke stoffen.
Stap 5: Waarschuwen/informeren derden
Als er derden moeten worden gewaarschuwd of geïnformeerd (bijvoorbeeld het bestuur van de gemeente) dan gebeurt dit via de telefooncentrale van de meldkamer (ARBI). De informatie uit GMS wordt doorgegeven en eventueel wordt (na goedkeuring van X) het WAS- systeem (systeem voor de aansturing van het sirenenetwerk) in werking gesteld. GASMAL wordt eventueel gebruikt voor de berekening van de verspreiding van gevaarlijke stoffen. Bij uitval van de ARBI wordt gebruik gemaakt van de PABX.
Communicator wordt gebruikt voor het uitbellen en de applicatie van telefoongids voor het opzoeken van de benodigde nummers.
Stap 6: Nazorg
Nadat de melding opgelost is wordt alle informatie in GMS bijgewerkt. Eventueel kan BUMICOM nog worden gebruikt om de opgenomen telefoongesprekken te kunnen terugluisteren. Voor ambulancevervoer (en de verrekening hiervan) wordt gebruik gemaakt van RAVIS. Via BRIO wordt uiteindelijk een managementrapportage opgeleverd, welke via de FAX wordt verstuurd naar de genodigde ontvanger.
Applicatietoelichting “meldkamer”
ARBI (stap 1,4,5)
Het telefoonnetwerk voor 112-meldingen. Bij uitval van de 112-lijn van ARBI kan vanuit Driebergen worden geherrouterd via een andere lijn; 3040. Beheer van ARBI vindt plaats m.b.v. de beheercomputer genaamd PUMA. Er zijn direct noodtoestellen en noodaansluitingen beschikbaar in de meldkamer bij uitval van ARBI.
BIG (stap 2,4)
Hiermee kunnen gevaaraspecten in beeld worden gebracht.
BMNI-systeem (stap 3)
Informatie- en waarschuwingssysteem voor radioactiviteit, zit in kelder aan de Sontweg (afdeling WVD = Waarschuwings Verkennings Dienst). Het proces “meten radioactieve straling” is als apart proces benoemd en vandaar grijs gearceerd aangegeven.
BRIO (stap 6)
Deze applicatie zit gekoppeld aan het GMS en zorgt voor managementrapportage over de geregistreerde meldingen. Kan een kritische applicatie zijn bij afleggen van verantwoording achteraf.
BUMICON (stap 6)
Dit is de recorder voor opname van de gesprekken in de melkamer en is verbonden met het GMS.
Chemiekaarten (stap 2,4)
Overzichten met relevante informatie over chemische stoffen ten behoeve van hulpverleningsdiensten.
CityGIS (stap 2,4)
Met deze applicatie is een overzicht te zien op de kaart van Groningen waar een incident zich voordoet en waar de voertuigen van de hulpeenheden zich in de stad bevinden. Dit gebeurt via het AVLS-systeem in de voertuigen. De applicatie AMBU net zorgt ervoor dat de positiegegevens uit het AVLS-systeem in het City GIS systeem komen bij de centrale (meldkamer).
Communicator (stap 3,5)
Het beleidsteam en het operationele team van crisismanagement worden via de communicator bereikt (crisismanagement is als apart proces benoemd en daarom grijs gearceerd). De communicator wordt ook bij een grootschalige geneeskundige ramp gebruikt voor communicatie met de coördinatieorganisatie GHOR (Geneeskundige Hulp bij Ongevallen en Rampen). Het GHOR coördineert de diverse hulpeenheden zoals het Rode Kruis. Bij uitval kan de communicator via de openbare telefoonlijnen worden gebruikt; zij het via codes.
DIAFRAAN (stap 3,5)
Diafraan is het semafoon systeem van de meldkamer.
Fax (stap 6)
Benodigd voor managementrapportage (over brandmelding).
GASMAL (stap 2,5)
GASMAL is een systeem voor berekening van de verspreiding van gassen. Hiervoor heeft de applicatie periodiek via modem contact nodig met het KNMI om actuele weergegevens te verkrijgen.
GMS (stap 2,3,4,5,6)
GMS staat voor geïntegreerde meldkamer systemen. Hierin wordt de registratie m.b.t.
meldingen geregeld. In GMS zitten o.a. BRIO (managementrapportage) en DGS (Databank Gevaarlijke Stoffen).
IDCS (stap 1)
Computergestuurd bediensysteem voor schakelfuncties en storingsmeldingen.
Omroepsysteem (stap 3)
Intern omroepsysteem in het gebouw aan de Sontweg voor alarmering van personeel.
OMS (stap 1 en 4)
Het openbaar brandmeldsysteem ook wel UGM genoemd (UGM is vermoedelijk de naam van de leverancier). Dit systeem zit in gebouwen en geeft een melding door aan de centrale.
De centrale kan vervolgens ook weer contact opnemen met het systeem in het gebouw (wederzijdse communicatie).
PABX (stap 5)
Telefooncentrale voor kantoortelefonie en het nationale noodnet.
RAVIS (stap 6)
Deze applicatie wordt gebruikt voor verwerking van de (management)rapportage over meldingen voor ambulances.
RDCS2000 (stap 3,4)
Dit is het verbindingsnetwerk voor brandweer en ambulancevervoer.
Telefoongids (stap 5)
Bij crisis kunnen mensen, m.b.v. de digitale telefoongids, telefonisch thuis bereikt worden.
WAS (stap 5)
Computergestuurde aansturing van het sirenenetwerk in de stad.
Applicaties en prioriteit
In het proces ‘meldkamer’ zijn een aantal applicaties met een hoge prioriteit. Dit betekent dat bij uitval van deze applicatie mogelijk gedeelten van het proces ‘meldkamer’ niet naar behoren kunnen worden uitgevoerd. De applicaties ‘GMS’, ‘RDCS2000’ en ‘Communicator’
hebben de hoogste prioriteit en daarna ‘Diafraan’. Deze applicaties te samen zijn minimaal nodig om het proces te kunnen uitvoeren.
GMS
Het geïntegreerde meldkamer systeem betreft de applicatie waarin een binnengekomen melding in de meldkamer wordt geregistreerd. Het hele verloop van de melding tot de afsluiting van de melding wordt met behulp van deze applicatie bijgehouden. Uitval betekend het niet kunnen bijhouden van meldingen, het niet kunnen maken/opleveren van managementrapportage en het niet kunnen bereiken van de Databank Gevaarlijke Stoffen (DGS).
RDCS2000
RDCS2000 is het verbindingsnetwerk voor brandweer en ambulancevervoer. Uitval van dit systeem heeft tot gevolg dat er geen communicatie tussen de meldkamer en de hulpeenheden van de ambulance en/of brandweer kan plaatsvinden. In het geval van grote calamiteiten kan dit grote gevolgen met zich meebrengen. Bij grote calamiteiten zal het
GSM-netwerk overbelast worden waardoor de communicatie tussen de hulpeenheden en de meldkamer niet via het GSM-netwerk kan plaatsvinden.
Communicator
Het beleidsteam en het operationele team van crisismanagement worden via de communicator bereikt. De communicator wordt bij een grootschalige geneeskundige ramp gebruikt voor communicatie met de coördinatieorganisatie GHOR (Geneeskundige Hulp bij Ongevallen en Rampen). Het GHOR coördineert de diverse hulpeenheden zoals het Rode Kruis. Falen van de communicator heeft tot gevolg dat het beleidsteam en het operationele team van crisismanagement niet of niet op tijd bereikt kunnen worden. Bij uitval kan de communicator via de openbare telefoonlijnen worden gebruikt; zij het via codes.
Diafraan
Diafraan is het semafoon systeem van de meldkamer. Bij uitval kunnen de hulpeenheden van de brandweer en/of de ambulance niet worden opgeroepen. Een alternatief is gebruik te maken van het GSM-netwerk. Bij ernstige calamiteiten zal het GSM-netwerk overbelast worden waardoor er geen gebruik van het GSM-netwerk kan plaatsvinden. Totaal gezien heeft Diafraan echter een minder hoge prioriteit dan GMS, RDCS2000 en Communicator.
Daarom worden hier geen verdere technische details van Diafraan vermeld.
GMS RDCS2000 Communicator
Gebruikmakende afdelingen:
Meldkamer (Sontweg) Meldkamer (Sontweg) WVD-kelder
(Sontweg)
Meldkamer (Sontweg) Thuislocatie
Configuratie: Server(s) gespiegeld Server Server(s) gespiegeld Desktopgegevens en
aantal desktops:
Windows XP 9 werkstations
MS-DOS 7 7 werkstations
Windows NT4 werkstation
2 werkstations Serverlocatie en
besturingssysteem
Computerruimte (Sontweg) Compaq TRUE64 5.1F
WVD-kelder (Sontweg) Novell 3.12
Koppeling naar GMS via NT4 werkstation
Computerruimte (Sontweg)
Windows NT4 server
Database (input) Oracle 9i DBASE Access
ICT-objecten
(database) (output):
clients clients clients
Modulaire applicatie nee (?) nee (?) ja
Toekomstige CIO- taken:
Onderhouden clients wordt opgevolgd door C2000
? Bijzonderheden: ♦ Continue
beschikbaar (24/7)
♦ Deskundige:
Derk Jager (FAB)
♦ Beheer:
Ito in Driebergen
♦ Continue beschikbaar (24/7)
♦ Telecom vereist
♦ Deskundige:
Derk Jager (FAB)
♦ Beheer: Getronics
♦ Verbindings- steunzenders in de provincie
♦ Continue beschikbaar (24/7)
♦ Telecom vereist
♦ Deskundige:
Hendrik Jan de Wolf (FAB)
tabel 9: (technische) gegevens over applicaties met prioriteit uitgelicht voor de CIO
