Programma van eisen voor. Decentrale Uitgifte. Naar één voorziening voor het lokaal afhandelen van grote aantallen niet-spoedeisende meldingen

Programma van eisen voor

Decentrale Uitgifte Naar één voorziening voor het lokaal afhandelen van grote aantallen niet-spoedeisende meldingen

Redactie: Input:

Eindredactie: Status: Versienummer: Datum:

Jan-Willem van Aalst Paul van der Linden Netwerk Meldkamerdomein Netwerk Informatiemanagement Mark Luijten Definitief 1.0 25 mei 2012

Expertgroep Naam Paul van der Linden

Regio Brabant-Noord

Albert Borsje

Amsterdam-Amstelland

Peter Ploeg

Rotterdam-Rijnmond

Theo Roelofs

Amsterdam-Amstelland

Meldkamerdomein

Joop Wessels

Twente

Meldkamerdomein

Koen Gerritsen

Utrecht

Hendrik Jan de Wolf

Groningen

Netwerk Meldkamerdomein

Meldkamerdomein

Versiebeheer Versie Datum 0.1 29 november 2011

Omschrijving Te bespreken met portefeuillehouder MKD in PR-IM

0.2

6 januari 2012

Uit te zetten voor review aan expertgroep en BVIM community

0.9

5 maart 2012

Ter meningvorming in stuurgroep Meldkamers BRW

0.99

14 mei 2012

Ter besluitvorming in stuurgroep Meldkamers BRW

1.0

25 mei 2012

Vastgesteld door opdrachtgever

Document: PvE Project: DCU Blad: 2 / 19

Status: Versienummer: Versiedatum:

Definitief 1.0 25 mei 2012

Inhoudsopgave MANAGEMENTSAMENVATTING....................................................................................................................... 4 1

INLEIDING OP HET PROGRAMMA VAN EISEN DECENTRALE UITGIFTE ...................................................... 6 1.1 SCOPE VAN DIT DOCUMENT .......................................................................................................................... 6 1.2 AANLEIDING VOOR HET PROGRAMMA VAN EISEN .............................................................................................. 7 1.2.1 Overbelasting van de meldkamer...................................................................................................... 7 1.2.2 Gevolgen voor de burger ................................................................................................................... 7 1.2.3 Gebrek aan uniformiteit .................................................................................................................... 8 1.2.4 Afbreukrisico...................................................................................................................................... 8 1.3 STRATEGISCH BELANG VOOR DE BRANDWEER ................................................................................................... 8 1.4 ROLLEN BINNEN HET DCU PROJECT ................................................................................................................ 9 1.5 NA HET PROGRAMMA VAN EISEN .................................................................................................................. 9

2

PROGRAMMA VAN EISEN (INHOUDELIJK) .............................................................................................. 10 2.1 INLEIDING EN LEESWIJZER ........................................................................................................................... 10 2.2 DCU: HANDREIKING VOOR UNIFORME WERKWIJZE/PROCESSEN ......................................................................... 10 2.3 DCU: DE INFORMATIE-OBJECTEN................................................................................................................. 11 2.4 HOOFDEISEN AAN DE DECENTRALE UITGIFTE VOORZIENING ............................................................................... 12 2.5 PRIORITERING VAN FUNCTIONALITEITEN ........................................................................................................ 17 2.6 BESLUITVORMINGSCRITERIA ........................................................................................................................ 17 2.6.1 Kosten .............................................................................................................................................. 17 2.6.2 Tijd ................................................................................................................................................... 18 2.6.3 Overig .............................................................................................................................................. 18 2.7 VAN PVE NAAR FUNCTIONEEL ONTWERP ....................................................................................................... 18 2.8 GEÏDENTIFICEERDE RISICO’S ........................................................................................................................ 19 2.9 ADVIES ................................................................................................................................................... 19




Managementsamenvatting Doelstelling en aanbevelingen De PRIM heeft de volgende doelstelling geformuleerd in de projectopdracht Decentrale Uitgifte: Verbeter de incidentafhandeling bij grote aantallen niet-spoedeisende meldingen (bij de ‘stormnachtprocedure’ en oudjaarsnacht), door de informatievoorziening tussen meldkamer en uitrukposten te verbeteren. Lever hiertoe concreet op: A. handreiking voor uniforme werkwijze/werkprocessen voor decentrale uitgifte; B. programma van eisen voor een uniform ondersteunende applicatie decentrale uitgifte; C. functioneel ontwerp voor een uniform ondersteunende applicatie decentrale uitgifte (gebaseerd op het programma van eisen); D. proof of concept met de voorloperregio’s en leveranciers. Het eisenpakket dient als basis voor een module/onderdeel van het nieuwe meldkamersysteem NMS. Voor de periode tot aan het NMS kan het eisenpakket als input dienen voor regionale verwervingstrajecten. De gekozen oplossing dient te passen binnen de door de NVBR geformuleerde richting zoals beschreven in het meerjarenbeleidsplan ‘Informatie Meester’. Eind 2012 begint de pilotfase, het onderzoek moet dan gereed zijn. Op basis van deze doelstelling, de reeds uitgewerkte Business Case DCU (2011) en het voorliggende programma van eisen (PvE) voor DCU zijn de aanbevelingen als volgt: 1. Besluit tot vaststelling van dit PvE voor DCU, in de wetenschap dat het document draagvlak heeft bij de NVBR Netwerken Meldkamerdomein en Informatiemanagement. 2. Geef naar aanleiding van dit PvE opdracht tot het uitwerken van het ‘Functioneel ontwerp DCU’. 3. Positioneer het DCU richting het Veiligheidsberaad als toekomstvaste module in het te realiseren meldkamersysteem NMS. Achtergrond Bij schaalvergroting van meldkamers neemt de personeelsomvang relatief gezien af, terwijl het aantal niet-spoedeisende meldingen bij noodweer e.d. relatief gezien gelijk zal blijven. De situatie ontstaat dat in dergelijke omstandigheden te weinig personeel beschikbaar is. Dit leidt tot congestie op de meldkamer, wat voor de spoedeisende meldingen onacceptabel is. Er is dan ook behoefte aan slimme oplossingen waarmee grote hoeveelheden niet-spoedeisende meldingen binnen de meldkamer snel kunnen worden verwerkt . In het NVBR/BVIM-project DCU wordt zo’n ‘slimme oplossing’ bedacht en ontworpen, als toekomstbestendige bouwsteen in het nieuwe NMS. Het resultaat komt tot stand met participatie van relevante landelijke partijen/netwerken. Het ministerie van VenJ heeft een subsidie ter beschikking gesteld om de realisatie van een DCU voorziening te ondersteunen. De DCU voorziening is een relatief goedkope mogelijkheid om “extra capaciteit” te creëren die rechtstreeks is gekoppeld op NMS, als module om congestie te voorkómen. Strategisch belang en risico’s In de landelijke beleidsdocumenten “Informatie Meester” en de “Brandweer Informatievoorziening Leidraad – In helder perspectief” (BRIL) wordt nadrukkelijk gestreefd naar landelijke standaardisatie, onder het motto “centraal wat moet, regionaal wat kan”. Belangrijke uitgangspunten daarin zijn:  zorgen voor één gestandaardiseerd uitwisselingsformaat voor gegevens;  meervoudig gebruik van voorzieningen (1x25);  koppelen met ketenpartners via web services;  zoveel mogelijk open standaarden om uitwisselbaarheid van gegevens te verbeteren. Dit sluit aan op uitgangspunten in het programma “Standaardisatie” van de bestuurscommissie IV van het Veiligheidsberaad. Qua beleidslijn kan DCU dus een toekomstbestendige module in het nieuwe NMS worden.




Met de resultaten van dit DCU-project van de BVIM kan landelijke functionaliteit worden gedefinieerd, die al vanaf medio 2012 op basis van de huidige GMS-infrastructuur kan worden geïmplementeerd bij die regio’s die wensen dit vóór de ophanden zijnde schaalvergroting van meldkamers te doen. Door zoveel mogelijk gebruik te maken van bestaande ICT-infrastructuur moeten de kosten beperkt blijven. Dit moet uiteindelijk leiden tot een applicatie die in de toekomst deel uitmaakt van de landelijk uniforme blauwdruk van de meldkamerorganisatie. Het belangrijkste doel is uiteraard het verbeteren van de hulpverlening en het verhogen van de veiligheid van de burger. In lijn met het meerjarenbeleidplan “Informatie Meester” en de door de minister uitgezette beleidslijn 1 uit haar brief uit 2010 wordt aangestuurd op het meervoudig gebruik van ICT-systemen en het standaardiseren van werkprocessen. Het treffen van een centrale voorziening met een centraal beheer lijkt derhalve de meest logische keuze. In het document “Business case DCU” is deze keuze nader onderbouwd. De proof of concept gaat uit van één landelijke set aan DCU functionaliteit, waarop meerdere leveranciers in meerdere regio’s worden getest. Een landelijke aanbesteding voor één leverancier valt buiten de scope van deze fase van DCU. Gebruikte input voor het PvE voor DCU Bij het opstellen van dit PvE voor DCU zijn de volgende reeds bestaande documenten gebruikt: 1. 2. 3. 4.

Business case DCU, opgesteld door Paul van der Linden (Brabant-Noord) “Eisen aan informatievoorziening Meldkamer Brandweer”, NVBR/ZenC, 30 maart 2011 Het PID DCU 3.7 van de Veiligheidsregio Utrecht, opgesteld door Pagelink De handleiding van de DCU-applicatie van de Veiligheidsregio Rotterdam-Rijnmond, opgesteld door Peter Ploeg en Pareto 5. NVBR Meerjarenbeleidsplan “Informatie Meester”, maart 2006 6. “In helder perspectief”, Brandweer Informatievoorzienig Leidraad (BRIL), november 2007 7. Brief Minister Ter Horst betreffende Meldkamers in Nederland, 9 februari 2010. De rechten voor het hergebruik van stukken 1 t/m 3 zijn gewaarborgd door de BVIM. Document nr. 4 is met toestemming beschikbaar gesteld door de meldkamer Rotterdam-Rijnmond. De wijze waarop het PvE uitmondt in realisatie van DCU (via functioneel ontwerp, proof of concept en pilot) is nader beschreven in het BVIM-document “Projectplan DCU”, te verkrijgen bij de Secretaris BVIM.

1

www.rijksoverheid.nl/documenten-en-publicaties/persberichten/2010/02/16/ter-horst-wil-een-meldkamer-voor-alle-hulpdiensten.html




1

Inleiding op het programma van eisen Decentrale Uitgifte

Dit hoofdstuk beschrijft de context waarin dit programma van eisen (PvE) tot stand is gekomen. Hieronder valt de afbakening (scope) van het onderwerp, de aanleiding (problematiek en resulterende vraagstelling), de geïdentificeerde risico’s en het belang voor de brandweer.

1.1

Scope van dit document

Dit document beschrijft het inhoudelijke Programma van Eisen (PvE) voor de landelijke voorziening Decentrale Uitgifte (DCU). Dit PvE is een BVIM document. Daarbij geldt de volgende scope: In-scope 1. De werkwijze (proces) van het lokaal afhandelen van grote aantallen niet-spoedeisende 2 meldingen ; 2. De wijze waarop meldingen van GMS (en straks NMS) naar een DCU-voorziening worden doorgezet; 3. Het beheren van kenmerken van lokaal af te handelen meldingen, zoals toewijzing van voertuigen en taken; 4. Het beheren van incidenthistorie van lokaal afgehandelde meldingen, t.b.v. leercyclus en managementrapportages. Out-of-scope 1. Meldkamerprocessen. Dit PvE gaat niet over het herontwerp van de meldkamerprocessen. De scope begint bij de stap dat een melding wordt geclassificeerd als ‘niet-spoedeisend’. 2. Functioneel ontwerp. Dit PvE is nadrukkelijk géén functioneel ontwerp. Een functioneel ontwerp is wel een logische volgende stap, maar dient voorafgegaan te worden door een breed gedragen en formeel vastgesteld PvE. Daar dient dit document voor, dat weer is gebaseerd op het document “Business case DCU”. 3. Aanpassing van GMS. Het geschikt maken van GMS (NMS) om meldingen als elektronische berichten te kunnen verzenden vanuit de GMK (waar nu meerdere software oplossingen voor in omloop zijn) wordt slechts zijdelings belicht. Het project is primair gericht op het inrichten van de centrale DCUapplicatie; 4. Realisatie van lokaal benodigde voorzieningen. Een regio zal zelf lokale voorzieningen moeten inrichten om DCU-meldingen te kunnen ontvangen. De DCU voorziening is een voorziening waarop van elke willekeurige werkplek met 3 een betrouwbare netwerkverbinding kan worden ingelogd ; 5. Richting geven aan regionale planvorming. Dit is een regionale verantwoordelijkheid. Standaardisatie van werkprocessen is echter wel randvoorwaardelijk voor het kunnen werken met de DCU-voorziening;

2

Verderop gaat het PvE in op waar de grens “spoedeisend / niet-spoedeisend” wordt getrokken.

3

Uitgangspunten hierbij zijn: 1. Elke veiligheidsregio maakt gebruik van zijn eigen regionale netwerk inclusief internetfaciliteiten; en 2. deze zijn gekoppeld aan de gemeenschappelijke meldkamer, ook als deze opgaat in een landelijke organisatie. Voor DCU is het gebruik van publieke voorzieningen zoals Internet en e-mail het hoogst haalbare. Dit gaat thans zelden mis, en het gaat uiteindelijk ‘slechts’ om niet-spoedeisende meldingen.




6. Meldingen via vaste lijnen. Het treffen van maatregelen (zowel procesmatig als technisch) om niet-spoedeisende meldingen niet via het 112-netwerk binnen te laten komen valt buiten de scope van het project DCU. 7. Disciplines in de meldkamer Niet-spoedeisende meldingen spelen vooral in de Brandweer- en Politiemeldkamer. Omdat de huidige opdracht is verstrekt door de Programmaraad IM van de NVBR, is de scope voor dit PvE beperkt tot de Brandweer. Verbreding van de scope blijft echter mogelijk.

1.2

Aanleiding voor het Programma van eisen

Nederland wordt in toenemende mate geconfronteerd met extreme weersomstandigheden, waaronder zware stormen en met grootschalige overlast, bijvoorbeeld tijdens de oudejaarsnacht. De meldkamers in Nederland hebben in meer of mindere mate maatregelen genomen om overbelasting ten gevolge van extreem weer te voorkomen. Een standaardoplossing voor de meldkamers in Nederland is echter niet voorhanden. Knelpunten zijn met name (zie ook het document “Business case DCU”): 1.2.1

Overbelasting van de meldkamer

Ten aanzien van de overbelasting onderscheiden we: 

Congestie in het 112-netwerk. De bereikbaarheid van de meldkamer en hiermee ook de spoedeisende hulpverlening komt hierdoor in gevaar. Dit beperkt zich uiteraard niet alleen tot de brandweer maar geldt bijvoorbeeld ook voor het melden van spoedeisende medische meldingen die op de GMK worden ontvangen.



Door de grote hoeveelheden meldingen die de brandweercentralisten moeten ontvangen komt ook de bereikbaarheid van de MKB voor de eigen eenheden in gevaar. Dit levert risicovolle situaties op.



Het GMS-systeem is niet geschikt voor het aannemen van grote hoeveelheden meldingen binnen een beperkt gebied. Doordat de centralisten hun meldingen niet kwijt kunnen ontstaat een onoverzichtelijke situatie die door de beschikbare menskracht onvoldoende gemanaged kan worden.



Bij het doorvoeren van de geplande schaalvergroting (de huidige landelijke visie spreekt over 10/10) zal de overbelasting exponentieel toenemen indien er geen maatregelen worden genomen om de problematiek op te lossen.



Bij grote drukte zal capaciteitsmanagement op lokale, regionale én landelijke schaal moeten worden georganiseerd.

1.2.2

Gevolgen voor de burger

Ten aanzien van de kwaliteit van de hulpverlening naar de burger: 

Bij grotere hoeveelheden niet-spoedeisende meldingen mag het systeem niet verstopt raken, waardoor bij prio 1 meldingen de verwerkings- en daarmee de opkomsttijden niet meer gehaald worden.



De GMK wordt tijdelijk onvoldoende bereikbaar voor spoedeisende meldingen voor andere diensten. Meldingen die vragen om een spoedeisende inzet van ambulance, brandweer of politie komen in gevaar door de overbelasting van het GMK.



De meldkamer is verantwoordelijk voor het beoordelen en prioriteren van alle meldingen. Bij een overbelasting van de meldkamer kan het te lang duren voordat een melding kan worden beoordeeld en geprioriteerd. Dit kan dus vertraging (wachtrij) geven bij het inzetten van een brandweereenheid op een spoedeisende melding die zich in eerste instantie liet aanzien als een niet-spoedeisende melding zoals bijvoorbeeld de omgevallen boom die toevallig ook een gasleiding mee heeft gepakt o.i.d.






Als geen eenheden beschikbaar zijn dan wordt met decentrale uitgifte de burger niet sneller geholpen….de wachtrij moet goed georganiseerd worden. Er hoort dus ook bij dat bij de burger, in het frontoffice, verwachtingen worden gemanaged. In voorkomende gevallen bepalen de eenheden zelf in welke volgorde ze de incidenten behandelen. Je moet op de meldkamer Front of Back kunnen zien dat dit volloopt en daar op de verwachting van de burger managen.



Indien grote hoeveelheden prio 2-meldingen niet kunnen worden uitgegeven naar de eenheden blijven sommige meldingen op de meldkamer liggen. Bij het korps ontbreekt hierdoor ieder overzicht van nog openstaande meldingen en hun prioriteit. De burger moet hierdoor onnodig lang wachten op hulp van een brandweereenheid.

1.2.3

Gebrek aan uniformiteit

Ten aanzien van het ontbreken van uniformiteit met betrekking tot de gekozen oplossingen: 

Er bestaat geen robuuste landelijk beschikbare standaardinformatievoorziening om de problematiek rondom de overbelasting door weersinvloeden en dergelijke aan te pakken. Enkele regio’s maken echter gebruik van een oplossing die als basis zou kunnen worden gebruikt voor één landelijke voorziening.



Doordat iedere regio op zoek gaat naar een oplossing wordt onvoldoende gebruik gemaakt van elkaars ervaringen en expertise.



Door enkelvoudig gebruik van een applicatie stijgen de kosten. Ontwikkelingskosten en exploitatiekosten worden alleen door de eigen regio gedragen. Er vindt onvoldoende samenwerking plaats.



Er is geen uitwisselbaarheid met andere regio’s. Dit bemoeilijkt het realiseren van uitwijkvoorzieningen, de uitwisseling van centralisten en toekomstige schaalvergroting



Bij de vorming van een landelijke meldkamerorganisatie is het uit beheersmatig oogpunt wenselijk een uniforme structuur te hebben voor voorzieningen binnen de meldkamers en op het koppelvlak met de buitenwereld van deze organisatie. . Uniformiteit werkt kostenverlagend, bij voorbeeld bij het afsluiten van een Service Level Agreement voor 24/7 ondersteuning van de DCU-voorziening.

1.2.4

Afbreukrisico

Ten aanzien van de afbreukrisico’s: 

Sommige lokale oplossingen zijn onvoldoende robuust en worden onvoldoende 24/7 ondersteund.



Sommige lokale oplossingen zijn teveel regio gebonden. Bij een toekomstige samenvoeging van meldkamers en hiermee van de verzorgingsgebieden van verschillende Veiligheidsregio’s, met verschillende soorten planvorming, is het niet mogelijk en niet wenselijk om binnen de GMK verschillende systemen naast elkaar te gebruiken of aan te sturen.



In het licht van de komst van NMS dient een voorziening voor DCU hier optimaal rekening mee te houden.

1.3

Strategisch belang voor de brandweer

In de landelijke beleidsdocumenten “Informatie Meester” en de “Brandweer Informatievoorziening Leidraad – In helder perspectief” (BRIL) wordt nadrukkelijk gestreefd naar landelijke standaardisatie, onder het motto “centraal wat moet, regionaal wat kan”. Belangrijke uitgangspunten daarin zijn: 

zorgen voor één gestandaardiseerd uitwisselingsformaat voor gegevens;



meervoudig gebruik van voorzieningen (1x25);



koppelen met ketenpartners via web services;



zoveel mogelijk open standaarden om uitwisselbaarheid van gegevens te verbeteren.




Dit sluit aan op uitgangspunten in het programma “Standaardisatie” van de bestuurscommissie IV van het Veiligheidsberaad. Qua beleidslijn kan DCU dus een toekomstbestendige module in het nieuwe NMS worden. Met de resultaten van dit DCU-project van de BVIM kan een landelijke applicatie worden gerealiseerd, die al vanaf medio 2012 op basis van de huidige GMS-infrastructuur kan worden geïmplementeerd bij die regio’s die wensen dit vóór de ophanden zijnde schaalvergroting van meldkamers te doen. Door zoveel mogelijk gebruik te maken van bestaande ICT-infrastructuur moeten de kosten beperkt blijven. Dit moet uiteindelijk leiden tot een applicatie die in de toekomst deel uitmaakt van de landelijk uniforme blauwdruk van de meldkamerorganisatie. Het belangrijkste doel is uiteraard het verbeteren van de hulpverlening en het verhogen van de veiligheid van de burger. In lijn met het meerjarenbeleidplan “Informatie Meester” en de door de minister uitgezette beleidslijn uit haar brief uit 2010 wordt aangestuurd op het meervoudig gebruik van ICT-systemen en de standaardisatie van werkprocessen. Het treffen van een centrale voorziening met een centraal beheer lijkt derhalve de meest logische keuze. In het document “Business case DCU” is deze keuze nader onderbouwd.

1.4

Rollen binnen het DCU project

In het DCU-project zijn de volgende rollen te onderscheiden: Meningvormend / besluitvormend 1. Raad van Regionaal Commandanten en Programmaraad Informatiemanagement (besluitvormend), portefeuillehouder Meldkamerdomein 2. Netwerk Informatiemanagement (meningvormend) 3. Netwerk Meldkamerdomein (meningvormend) 4. Landelijk Netwerk Repressie (meningvormend) BVIM-community (uitvoerend) (Eind)gebruikers 1. Meldkamerfunctionarissen 2. (Regionale/lokale) postcoördinatoren 3. Lokale meldingcoördinatoren en eenheden

1.5

Na het Programma van Eisen

Het PvE dient als basis voor een functioneel ontwerp. Waar het functioneel ontwerp DCU de functionaliteit beschrijft die met een DCU-voorziening beschikbaar komt, stelt het PvE de kaders en randvoorwaarden waaraan dat functioneel ontwerp moet voldoen. Het PvE zorgt er dus voor dat het functioneel ontwerp optimaal aansluit op de gebruikerswensen, zoals vertegenwoordigd in de expertgroep DCU en de DCU vertegenwoordigers in de NVBR Netwerken IM, MKD en Repressie. Het functioneel ontwerp DCU dient weer als basis voor een technisch ontwerp met een daarbij behorende proof of concept, als eerste test voor de voorziening. Deze fasering is nader uitgewerkt in het BVIM-document “Projectplan DCU”.




2 2.1

Programma van eisen (inhoudelijk) Inleiding en Leeswijzer

Dit hoofdstuk bevat de inhoud van het PvE voor DCU. Allereerst volgt een beschrijving van de werkprocessen die de DCU-voorziening zal moeten ondersteunen. Daarna volgt een opsomming van de betrokken informatie-objecten (op basis van BRIL). Na de inhoudelijke functionele en nietfunctionele eisen volgt de prioritering van functionaliteiten, op basis van een brede consultatie langs de betrokken NVBR netwerken. Het hoofdstuk sluit af met besluitvormingscriteria en open opties in de functionaliteit. Het PvE gaat vooral over keuzes in werkwijze, werkprocessen en procedures (workflow). Het PvE heeft geen technische insteek; desondanks worden enkele technische termen vermeld; altijd met toelichting.

2.2

DCU: handreiking voor uniforme werkwijze/processen

De DCU-voorziening ondersteunt de volgende processen: 1. Doorzetten van meldingen naar de voorziening voor Decentrale uitgifte (nu in GMS, straks NMS)  Genereren en versturen van bericht naar DCU voorziening  Ontvangen van bericht door DCU voorziening  Inrichten vaste (coördinatie)post 2. Incidentmanagement binnen DCU  Beheer van incidenten (openen, wijzigen, afmelden, afsluiten)  Beheer van voertuigen (zoeken, filteren, koppelen, ontkoppelen, toewijzen, verwijderen, importeren)  Beheren van status van voertuigen. Let op: het gaat hier niet om de GMS status, maar om de status namelijk de inzetbaarheid van een voertuig voor de functionaris die belast is met de uitgifte van de DCU meldingen op de vaste post. Dit noemen we de DCU coördinator.  Beheer van prioriteiten van lokale meldingen  Beheer van taken en takenlijsten  Beheer van het kladblok (toevoegen, lezen, verwijderen)  Printen van incidenten 3. Configuratie van gebruik van DCU  Zoeken en filteren in incidenten(historie)  Instellen gebruikersprofielen  Configureren van gebruikers, groepen, autorisaties  Exporteren van bericht t.b.v. rapportage richting GMS (straks NMS)  Kopiëren van profielen exportbericht De volgende actoren zijn hierin relevant:  Meldkamer centralist Brandweer  DCU coördinator  Bevelvoerder brandweereenheden Herhaaldelijk is in de landelijke netwerken de wens geuit om te komen tot één landelijke beschrijving van werkwijze en procedures, zodat er geen eilandvorming ontstaat. In het licht van de schaalvergroting van de meldkamers is dit ook een logische wens. Voor de scope van DCU zijn de processen daarom uitgewerkt in het volgende SQEME diagram.




Figuur 1. Procesbeschrijving Decentrale Uitgifte

2.3

DCU: de Informatie-objecten

Informatie-objecten zijn groepen aan elkaar gerelateerde gegevens die door de DCU-werkprocessen ‘stromen’ en zo het werk effectiever maken. De objecten zijn van belang voor een effectief functioneel ontwerp. DCU onderscheidt de volgende informatie-objecten: Bericht Incidentenlijst

Het bericht dat aangemaakt wordt na afsluiten van een melding in de GMS- (later NMS-) database. De database waarin de meldingen worden opgeslagen die door de (vaste, lokale) coördinatieposten worden uitgelezen.

Gebruiker settings

Namen, relevante details, rechten en verzorgingsgebied van een DCUgebruiker.

Kladblok

Een klein venster waar berichten of incidentdetails kunnen worden geplaatst. Een taak die bij een incident hoort.

Taak Takenlijst Voertuig Custom voertuig

Een lijst met alle openstaande en afgehandelde taken voor een specifiek incident. Een voertuig dat aan een incident kan worden toegewezen.

Voertuigreferentie

Een custom voertuig dat is aangemaakt, waarna het aan een incident kan worden toegewezen. Het bestand met alle beschikbare voertuigen.

Incidenten

Een lokaal af te handelen incident.

Incidentdetails

Verzameling van details omtrent een incident.

Bedrijfsprocessensysteem

Een lokaal of regionaal in gebruik zijnde bedrijfsprocessensysteem.




2.4

Hoofdeisen aan de Decentrale uitgifte voorziening

De volgende eisen dienen gelezen te worden als “must-haves”. De lijst is besproken met de leden van de betrokken landelijke netwerken. Waar compromissen zijn geformuleerd, wordt dit zo goed mogelijk aangegeven. De eisen gaan uit van het voorkeurscenario uit de Business case DCU voor één 4 landelijke voorziening . De lijst is opgebouwd volgens de structuur van de werkprocessen in paragraaf 2.2. De eisen zijn genummerd zodat er later ondubbelzinnig naar gerefereerd kan worden. De eerste eis is dus A1.1. A. Doorzetten van GMS-meldingen naar de DCU-voorziening Dit proces vormt de trigger om (grote hoeveelheden) niet-spoedeisende meldingen decentraal te gaan afhandelen. Zie “Business case DCU” voor details van dit proces. A 1. Genereren en versturen van bericht 1. De Landelijk vastgestelde Meldingsclassificaties zijn van toepassing op het te genereren bericht. 2. Een bericht is gericht aan een of meerdere vaste decentrale (coördinerende) posten. 3. Het bericht sluit aan op de bestaande systematiek in GMS en houdt voor zover mogelijk rekening met eigenschappen van het toekomstige NMS. 4. Per discipline kunnen één of meer afsluitcodes worden opgenomen in het te genereren bericht. 5. De browser wisselt gegevens uit met de applicatie voor decentrale uitgifte middels een beveiligde (versleutelde) verbinding. Bij Internetverkeer volstaat SSL (https://). 6. Het bericht voor de lokale post bevat voldoende gegevens over de afzender/ maker van het bericht. Welke precies wordt gespecificeerd in het functioneel ontwerp. A 2. Ontvangen van het verstuurde bericht door de DCU voorziening 1. Een binnengekomen lokaal af te handelen incident wordt gekoppeld aan de meldkamer die het bericht heeft verstuurd. 2. Een binnenkomend bericht wordt in de DCU-database opgeslagen, waarna een ontvangstbevestiging wordt teruggestuurd naar de afzender, zodat beide partijen zeker weten dat het bericht niet verloren is gegaan. A 3. Inrichten vaste post 1. Qua gebruikersbeheer is een vaste post gelijk aan een groep in een CMS-omgeving, met bepaalde geautoriseerde gebruikers. 2. Groepen bevatten gebruikers die lokaal af te handelen incidenten kunnen zien. 3. De naamgeving van vaste posten heeft een standaard structuur voor naamgeving: Regio#gemeente#vaste_post_n. Dus bijv. Twente#Hengelo#vaste_post_1. B. Incidentmanagement binnen de DCU voorziening B 1. Algemeen 1. De DCU-voorziening is te gebruiken in een browser-omgeving (verbonden met een robuuste infrastructuur/verbinding, zie onderdeel D1). Een DCU coördinator van de posten kan via een browser inloggen op de DCU-voorziening. Per meldkamer is hiervoor een omgeving beschikbaar. Zie onderdeel E voor eisen aan gebruiksvriendelijkheid van de user interface. 2. Andere partijen zoals OT en actiecentra hebben de mogelijkheid om mee te kijken indien de situatie daar om vraagt. De exacte lijst van partijen met “lees-toegang” wordt nog nader vastgesteld. 4

In theorie wordt nog 10/10 als uitgangspunt genoemd. Echter de 10 frontoffice is, zeker bij grote drukte, feitelijk 1 frontoffice doordat

meldingen kunnen en moeten overlopen naar andere vestigingen. Vandaar dat we DCU beschouwen als één landelijke voorziening.




3. Innovaties bieden de mogelijkheid om DCU meldingen uit te geven aan bevelvoerders op voertuigen. Hoewel dit de afhandeling kan versnellen, is het complexer om op de coördinatiepost het overzicht te houden. Dit is op zich op te lossen, maar de regio moet dan goed nadenken over de indeling van coördinatieposten. Daarom is dit punt in dit PvE een mogelijkheid, maar geen eis. B 2. Beheer van incidenten (openen, wijzigen, afmelden, afsluiten) 1. Het startscherm bevat alle door DCU geregistreerde incidenten, gesorteerd op prioriteit. 2. Zodra men op een incident klikt ziet men, indien van toepassing, alle aan dit incident gekoppelde voertuigen met hun status. 3. Meldingen kunnen desgewenst ook via een aparte applicatie worden ingevoerd. Hierbij 5 is een optie om ze eerst naar GMS te sturen voor prioritering door meldkamer. Na prioritering worden ze via DCU naar de juiste decentrale uitgiftegroep gestuurd. 4. Vaste postcoördinatoren kunnen naast nieuwe en lopende incidenten, ook taken van een incident en de historie van incidenten inzien. 5. Incidenten worden voorzien van een heldere status van afhandeling, inclusief een ‘gezien’, ‘lopend’, en ‘afgesloten’ stempel. 6. Van de locatie van een incident is een standaardkaart en/of -luchtfoto op te vragen. (bijv. Google/Bing) Dit kunnen ook basiskaarten/foto’s zijn die via LCMS of NMS beschikbaar komen. 7. Om een oplossing voor een incident in te vullen, is naast een tekstvak een autofill-lijst beschikbaar om snel uit te selecteren. Standaardoplossingen zijn conform de huidige GMS-definities en zodra NMS operationeel is conform NMS-definities. 8. Is men klaar met een incident maar zijn er nog openstaande taken die moeten worden afgehandeld, dan kan men een incident afmelden. Zijn er nog voertuigen aan dat incident gekoppeld die nog de status aanrijdend of ter plaatse hebben, dan krijgen ze automatisch de status “vrij” met de bijhorende tijd. 9. Door een incident af te melden kan men ook geen kladblokberichten meer schrijven. Wel kan een incident indien noodzakelijk worden heropend binnen een bepaald tijdsinterval (niet een maand later; te specificeren in het document Functioneel Ontwerp DCU). 10. Zijn er geen openstaande taken of zijn ze allemaal afgehandeld kan een incident worden afgesloten. Ook hier geldt dat als er nog voertuigen gekoppeld zijn die de status “vrij” niet hebben dat die status automatisch wordt ingevuld met de bijhorende tijd. Een incident kan niet worden afgesloten als er nog openstaande taken zijn. B 3. Beheer van voertuigen (Zoeken, filteren, koppelen, ontkoppelen, toewijzen, verwijderen, importeren) 1. Voertuigen (alle disciplines) kunnen middels eenvoudige kliks uit een overzicht van beschikbare voertuigen worden toegewezen. 2. Op dezelfde wijze kunnen voertuigen worden ontkoppeld van een incident. 3. Naar voertuigen kan ook op vrijetekst-trefwoord worden gezocht. 4. De status van een voertuig kan op elk moment geactualiseerd worden. Mogelijke statussen zijn “vrij”, “niet beschikbaar”, “aanrijdend” en “ter plaatse”. 5. De DCU kan ook voertuigen uit andere regio’s importeren. 6. Een geautoriseerde functionaris kan ook een custom-voertuig aanmaken indien van toepassing voor de betreffende regio. Een regio kan dit alleen ondersteunen als een custom voertuig ook daadwerkelijk gevolgd kan worden.

5

Dit vormt een dilemma. Het is immers de bedoeling om de meldkamer te ontlasten. Echter, meldingen mogen niet aan de aandacht ontsnappen omdat ze bijvoorbeeld binnenkomen bij een vaste post maar eigenlijk door een andere post moeten worden afgewerkt die nog niet bemand is. Meldingen kunnen dan verdwijnen in een zwart gat. Ook is er geen mogelijkheid om meldingen te laten beoordelen op prioriteit. De meldkamer moet wel een mogelijkheid houden om het algehele overzicht te houden.




B 4. Beheren van status van voertuigen 1. Geautoriseerde personen kunnen de status van voertuigen aanpassen binnen de geldende statusdefinities. 2. Een voertuig kan alleen verwijderd worden als het status ”vrij” heeft. B 5. Beheer van prioriteiten van lokale meldingen 1. De incidentlijst kan worden gefilterd op prioriteitniveau. 2. Indien blijkt dat de prioriteit van een incident niet klopt, dan kan die aangepast worden. Elk incident heeft standaardprioriteit 3, maar de DCU coördinator kan die verhogen van 3 naar 2. Het incident wordt dan uit de DCU-applicatie verwijderd en moet door GMU opnieuw in GMS worden aangemaakt. B 6. Beheer van taken en takenlijsten 1. Een incident heeft lijsten van nog af te handelen taken en van afgehandelde taken. Deze lijsten worden periodiek ververst en/of handmatig ververst. 2. Geautoriseerde functionarissen kunnen taken toevoegen, bewerken en weer verwijderen. 3. Lijsten met afgehandelde taken komen ook ter beschikking van de bericht-export voor evaluatie en managementinformatie. B 7. Beheer van het kladblok (toevoegen, lezen, verwijderen) 1. Een kladbloktekst behoort altijd bij een te selecteren incident. 2. Eenmaal ingevoerde kladblokregels kunnen alleen door een beheerder gewijzigd of verwijderd worden. 3. Kladblokregels vormen onderdeel van het elektronisch bericht van incidenten t.b.v. evaluatie en managementinformatie. B 8. Printen van incidenten 1. Indien gewenst kan een incident geprint worden. Daarvoor wordt een incident in de lijst geselecteerd en wordt op de printknop geklikt. Vervolgens opent het standaardprintvenster van Windows. C. Configuratie van gebruik van DCU C 1. Zoeken en filteren in incidenten(historie) 1. Functionarissen kunnen zoeken en filteren (incidenten, voertuigen) alleen binnen het eigen verzorgingsgebied (gewoonlijk de regio). Administratoren kunnen de gehele database doorzoeken en filteren. 2. Medewerkers kunnen de lijst met incidenten filteren op prioriteit en op geografisch gebied. 3. De DCU-voorziening kent een hoofdmenu-item “incidentenhistorie”. 4. Incidentenhistorie kan worden bekeken op basis van een ingevulde periode of op basis van geografisch gebied of op basis van beide. C 2. Instellen gebruikersprofielen 1. Iedere rol heeft andere autorisaties waar het raadplegen en wijzigen van gegevens betreft. DCU kent de volgende autorisatiematrix: MK-server

Elektronisch bericht Incidenten-DB

RW

DCU-server

Medewerker vaste post

Beheerder MK

R RW

Incidentenlijst

RW




MK-server

DCU-server

Medewerker vaste post

Gebruikersrechten

Beheerder MK RW

Kladblok

RW

Taak

RW

Takenlijst

RW

Voertuig

R

RW

Custom-voertuig

RW

RW

Voertuiglijst

RW

Incident/melding

RW

Incidentdetails

RW

Lokaal BPS

R

R

C 3. Exporteren van bericht 1. Elk incident dat lokaal is afgehandeld, dient expliciet te worden teruggemeld door de DCU voorziening aan GMS (straks NMS). Dit ten behoeve van rapportages. 2. De DCU-voorziening kan een terugmeldbericht genereren dat leesbaar is voor bedrijfsprocessystemen in de regio. 3. De voorziening kan een terugmeldbericht genereren dat leesbaar is voor GMS (later: NMS) bij een incident waarvan de prioriteit is opgehoogd. 4. De exportfunctie is tevens van belang als managementinformatie voor GMS/NMS. 5. Het is aan GMS (straks NMS) te bepalen of een decentraal afgehandeld en teruggemeld incident een zojuist in GMS gesloten incident weer kan heropenen. C 4. Beheer van de DCU functionaliteit 1. Voor het (versie)beheer van de functionaliteit van DCU wordt een landelijke DCUgebruikersgroep ingericht. De leverancier gebruikt deze gebruikersgroep als primaire input voor volgende versies van DCU. D. Eisen aan betrouwbaarheid van de DCU voorziening D 1. Beschikbaarheid 1. De DCU-voorziening heeft een beschikbaarheid (uptime) van gemiddeld 99,0% op jaarbasis. Dit geldt voor zowel reguliere als bijzondere omstandigheden. ICTleveranciers geven vooraf duidelijk inzicht in de financiële consequenties van deze eis. De regio zorgt voor inzicht in de (piek)belasting van netwerklijnen bij grote drukte. 2. De DCU-voorziening dient rekening te houden met regionaal ingestelde firewalls. Deze configuratie moet zo zijn ingesteld dat er minimale vertraging in gegevenstransport plaatsvindt. 3. De voorziening dient niet enkel afhankelijk te zijn van de beschikbaarheid van een Internetverbinding. Als een Internetverbinding of publieke verbinding uitvalt, moet een alternatieve verbinding tot stand kunnen worden gebracht zonder tussenliggende uitval. Indien een eigen (regionaal) netwerk al beschikbaar is, verdient dat de voorkeur. 4. De DCU voorziening hoeft niet exclusief door één leverancier te worden geleverd. Elke leverancier die meent de functionaliteit in het functioneel ontwerp te kunnen bieden en voldoet aan de eisen in dit PvE, heeft het recht om te bieden. Dit heet ook wel het “DBK concept”. D 2. Performance 1. De DCU-voorziening draait in de regio in een web browser. Deze stuurt vanuit de userinterface requests naar de landelijke server. Deze reageert binnen maximaal 7 seconden




op dergelijke requests. De performance moet door gebruikers worden ervaren als ‘vergelijkbaar met Google Maps’. 2. De server moet minimaal 30 en maximaal 60 concurrent web clients (users) binnen de gestelde responstijd kunnen afhandelen. Dit geldt voor reguliere en bijzondere omstandigheden. ICT-leveranciers geven vooraf duidelijk inzicht in de financiële consequenties van deze eis. D 3. Fallback / backup 1. Gegevens-backup Alle gegevens, van zowel openstaande als afgesloten incidenten, zijn van groot belang voor de gebruikers. Gegevens van openstaande incidenten worden ten minste vier keer per uur op een backup-plaats weggeschreven. Gegevens van afgesloten incidenten worden tenminste dagelijks gebackupt. 2. Fallback bij uitval Het afhandelen van incidenten mag niet verstoord worden door uitval van ICT. De centrale DCU-voorziening is dan ook dubbel uitgevoerd. Gegevens zijn beschikbaar volgens een tijdinterval zoals vermeld in eis D3.1. Bij uitval van de centrale DCUvoorziening neemt de fallback-voorziening de beschikbaarheid over. Hier is nog een minimum/maximum reactietijd voor te bepalen. 3. Hersteltijd De dubbele werking (primair en fallback) wordt na uitval zo spoedig mogelijk hersteld, maar uiterlijk binnen 4 werkuren (uitgaande van een 24/7 bemensing). ICT-leveranciers geven vooraf duidelijk inzicht in de financiële consequenties van deze eis. D 4. Technische ondersteuning 1. Bij de DCU-voorziening hoort een technische ondersteuningsfunctie. Deze is beschikbaar in de vormen: PDF FAQ, website en telefonische ondersteuning. De technische ondersteuning per telefoon dient beschikbaar te zijn tussen 9 uur en 20 uur en in de uren rondom Nieuwjaarsnacht. 2. ICT-leveranciers verzorgen (beknopte) opleidingen voor lokale ICT-beheerders die de specifieke web clients beheren, die toegang krijgen tot de DCU-voorziening. E. Eisen aan gebruiksvriendelijkheid van de user interface 6 E 1. De user interface is opgebouwd in een browser-scherm en bevat voor de gebruiker direct herkenbare elementen (selectieknoppen, radio-buttons, check boxes, invulvelden, dropdown boxes etc). Deze zijn zo eenvoudig en sober mogelijk weergegeven op het scherm t.b.v. helderheid en performance. E 2. Het is voor elke gebruiker direct duidelijk met welke rol hij/zij is ingelogd en welke autorisaties daar bij horen (dus wat in de user interface voor die rol wel en niet werkt). E 3. De user interface is niet afhankelijk van één type browser. De volgende browsers moeten worden ondersteund: MS Internet Explorer (versie 7 of hoger), Google Chrome, Mozilla Firefox, Safari. E 4. Lange lijsten (van incidenten of voertuigen) op het scherm worden pas opgesplitst in pagina’s bij meer dan 100 items. E 5. Voor het benadrukken van statussen wordt de kleurstelling conform algemeen gebruik gehanteerd (rood: niet vrij; groen: vrij, etc.) E 6. De client-side-applicatie mag uitgaan van een minimum schermresolutie van 1024 x 768 pixels met meer dan 256 kleuren. E 7. Luchtfoto’s en tekeningen worden getoond in aparte popup-schermen. E 8. Coördinatieposten in een regio moet een lokale DCU beheerder zelf kunnen bepalen. E 9. Een geografisch (kaart)beeld van de omgeving moet opvraagbaar zijn.

6

Dat betekent niet automatisch dat de verbinding een Internet verbinding is, zie onderdeel D1.




2.5

Prioritering van functionaliteiten

De aangegeven functionaliteiten zijn door de betrokken experts als volgt geprioriteerd. Prioriteiten variëren van prioriteit 1 (Must have) tot prioriteit 3 (Nice to have). A. Versturen en ontvangen van elektronische berichten: 1. A1: Genereren en versturen elektronisch bericht: 1 2. A2: Ontvangen van elektronisch bericht door DCU: 1 3. A3: Inrichten vaste post: 1 B. Incidentmanagement: 4. B1: Algemeen incidentmanagement via DCU: 1 5. B2: Beheer van incidenten: 1 6. B3: Beheer van voertuigen: 1 7. B4: Beheer van status van voertuigen: 1 8. B5: Beheer van prioriteiten van lokale meldingen: 1 9. B6: Beheer van taken en takenlijsten: 1 10. B7: Beheer van het kladblok: 1 11. B8: Printen van incidenten: 2 C. Configuratie van het gebruik van DCU: 12. C1: Zoeken en filteren in incidenten: 1 13. C2: Gebruikersprofielen: 1 14. C3: Exporteren van elektronisch bericht: 1 15. C4: Beheer van DCU-functionaliteit: 1 D. Eisen aan betrouwbaarheid van DCU: 16. D1: Beschikbaarheid: 1 17. D2: Performance: 1 18. D3: Fallback / backup: 1 19. D4: Technische ondersteuning: 1 E. E. user interface DCU: 20. E1: UI / Eenvoud: 1 21. E2: UI / rollen en autorisaties: 1 22. E3: UI / typen browsers: 2 23. E4: UI / lange lijsten: 2 24. E5: UI / kleurgebruik: 2 25. E6: UI / schermresolutie: 2 26. E7: UI / popups: 2

2.6

Besluitvormingscriteria

In deze paragraaf worden ‘kosten’ en ‘tijd’ als besluitvormingscriteria uitgewerkt. Het besluitvormingscriterium kwaliteit is vervat in de eisen in dit document. 2.6.1

Kosten

Voor het aspect kosten gelden de volgende besluitvormingscriteria: 1. De benodigde eenmalige investering voor het realiseren van de landelijke voorziening vindt via cofinanciering plaats: het Veiligheidsberaad (/ NCTV) investeert een deel (in het kader van NMSdossier) en de collectieve regio’s investeren een deel. De verhouding van de bijdrage in de investering is nader te bepalen. 2. Voor het regionale deel van de investering geldt dat alle regio’s evenredig bijdragen aan de realisatie van de landelijke voorziening.




3. Regio’s kunnen daarnaast eventueel kosten hebben voor het inrichten van lokale werkplekken om de toegang tot de landelijke voorziening te configureren. 4. De terugkomende kosten voor het functioneel en technisch beheer van de landelijke DCUvoorziening gebeurt volgens een nader vast te stellen verdeelsleutel tussen opdrachtgever en gebruikende regio’s. 5. Het lokale beheer en gebruik van DCU dient door regio’s te worden ingebed in de bestaande formatie, omdat lokale afhandeling nu ook al moet gebeuren in voorkomende gevallen. Belangrijk criterium is dat regio’s niet genoodzaakt worden tot formatie-uitbreiding door de landelijke DCUvoorziening. 2.6.2

Tijd

Voor het aspect tijd gelden de volgende besluitvormingscriteria: 1. De tijdplanning voor de regionale invoering van DCU wordt afgestemd op strategisch niveau met de tijdplanning voor de invoering van NMS. DCU hoeft daarin overigens niet te wachten op NMS: ook met het huidige GMS kan DCU goed uitwisselen. De interoperabiliteit met NMS is wel (voor zover redelijkerwijs mogelijk) voorbereid in de landelijke DCU-voorziening. 2. Versiebeheer van de functionaliteit van DCU vindt plaats in vastgestelde tijdintervallen door een nader te benoemen functionele gebruikersgroep DCU.

2.6.3

Overig

De overige besluitvormingscriteria zijn overgenomen uit het Projectplan DCU: 1. Er is een wezenlijke, inhoudelijke inbreng vanuit meerdere regio’s. 2. Het proces is transparant voor betrokken partijen door heldere communicatie o.m. dankzij gebruikmaking van MijnNVBR. 3. Het resultaat voldoet aan de principes uit de BRIL. 4. Het resultaat is te bestempelen als toekomstbestendige module in het nieuwe NMS. 5. Het resultaat is desgewenst ook met het huidige GMS bruikbaar. 6. Acceptatie door de NVBR-netwerken Meldkamerdomein (NMKD), Repressie (LNR) en Informatiemanagement (NIM).

2.7

Van PvE naar functioneel ontwerp

Het PvE dient als basis voor een functioneel ontwerp. Waar het functioneel ontwerp DCU de functionaliteit beschrijft die met een DCU voorziening beschikbaar komt, stelt het PvE de kaders en randvoorwaarden waaraan dat functioneel ontwerp moet voldoen. Het PvE zorgt dus er dus voor dat het functioneel ontwerp optimaal aansluit op de gebruikerswensen. Het functioneel ontwerp DCU dient weer als basis voor een technisch ontwerp met een daarbij behorende pilot, als eerste test voor de voorziening. Deze fasering is nader uitgewerkt in het BVIM document “Projectplan DCU”. Zodra het PvE voor DCU is vastgesteld door de PR-IM wordt het functioneel ontwerp gerealiseerd. Ook dat document gaat de reviewronde in naar de betrokkenen zoals in dit document beschreven. Zie ook het projectplan DCU.




2.8

Geïdentificeerde risico’s

De volgende risico’s zijn geïdentificeerd betreffende de realisatie van DCU. Kans en effect zijn geprioriteerd op 0 (niet) tot 10 (zeer groot/ernstig). Risico

Kans

Effect

Tegenmaatregel

Geen financiering beschikbaar vanuit NCTV/VB vanwege NMS prioritering

5

8

Via RRC het belang van DCU (ook voor NMS) herhaaldelijk benadrukken bij Veiligheidsberaad (via POI?)

Gezamenlijke financiering van gebruikersdeel lukt niet of gaat te traag

6

8

Via de PR-IM agenderen in de RRC als discussiepunt – strategisch belang van DCU helder communiceren in RRC.

Geen consensus over PvE of functioneel ontwerp

2

7

Workshop organiseren om te bekijken waar de meningsverschillen exact zitten.

Gebruikersgroep DCU komt niet van de grond

2

6

Regionale commandanten stimuleren om hun experts hiervoor ruimte te geven.

Leverancier kan niet leveren door onduidelijkheid over koppeling met GMS

3

8

Kennis over hoe en wat is beschikbaar in het land – mobiliseren.

Onvoldoende (mens)capaciteit in regio’s aan de gebruikerszijde

3

7

Management in regio’s verzoeken om hiervoor capaciteit vrij te maken.

Verrassingen in PvE NMS waardoor DCU flink aangepast moet worden.

1

8

Al vanaf het begin goede contacten organiseren met het NMS team.

2.9

Advies

Op basis van de doelstelling van DCU, de reeds uitgewerkte Business Case DCU (2011) en het voorliggende PvE voor DCU is het advies richting de opdrachtgever als volgt: 1. Besluit tot vaststelling van dit PvE voor DCU, in de wetenschap dat het document draagvlak heeft bij de drie betrokken NVBR netwerken. 2. Geef naar aanleiding van dit PvE opdracht tot het uitwerken van het functioneel ontwerp DCU. 3. Positioneer het DCU richting het Veiligheidsberaad als toekomstvaste module in het te realiseren Nationaal Meldkamer Systeem NMS.




Programma van eisen voor. Decentrale Uitgifte. Naar één voorziening voor het lokaal afhandelen van grote aantallen niet-spoedeisende meldingen

Recommend Documents