Management

Procesmanagement
Amsterdamse grachten

‘Noodprocedures ICT gemeente Amsterdam onvoldoende’

Standaardprocedures bij ICT-storingen in de hoofdstad faalden bij grote storingen eerder dit jaar.

© CC BY-SA 2.0 - Flickr.com dronepicr
11 juli 2019

Standaardprocedures bij ICT-storingen in de hoofdstad faalden bij grote storingen eerder dit jaar.

De standaardprocedures van de gemeente Amsterdam, die bij een ICT-storing moeten zorgen voor een snel herstel van de werkzaamheden, hebben bij de twee storingen eerder dit jaar gefaald. Dat is de conclusie die stadszender AT5 heeft getrokken na het inzien van documenten op basis van een Wob-verzoek.

De stadszender zag documenten in die zijn opgesteld na een onderzoek door wethouder Touria Meliani (ICT), die de gemeente na het Wob-verzoek vrijgaf. Hieruit blijkt dat de hoofdstad in de eerste zes maanden van het jaar zes keer is getroffen door een ICT-storing, waarbij het drie keer een netwerkstoring betrof. Twee keer ging het mis rond het mailverkeer, één keer kon er door medewerkers niet geprint worden. Vorig jaar lag het totaal aantal storingen op acht, terwijl er in 2017 nog negen storingen te noteren vielen. 2016 spande de kroon met een totaal van 22 stroringen in de gemeente-ICT.

Vier-ogen principe

De grootste twee storingen van dit jaar vonden in februari en maart plaats. Toen er op 18 februari een routinematige aanpassing van de ICT-infrastructuur gepland stond, moesten er volgens de interne afspraak twee medewerkers bij deze aanpassing aanwezig zijn. Dit zogeheten vier-ogen principe werd echter niet aangehouden door een tekort aan personeel. Waar er normaliter op een gewone werkdag zes specialisten aanwezig zijn voor dit soort specifieke werkzaamheden, waren er nu vier afwezigen, waarvan drie ongepland. Zodoende werd er afgeweken van het protocol.

De storing in februari legde het netwerk van Amsterdam bijna 12 uur lang plat, en ook een zogeheten 'rollback' van het systeem mislukte. Ook de beheeromgeving van de ICT-beheerders was gedurende de storing onbereikbaar.

Weigerend onderdeel

In maart ging het wederom mis door een grote netwerkstoring, die vrijwel het hele gemeenteapparaat plat legde. Deze storing zou volgens de documenten komen door een weigerend netwerkonderdeel. Waar er normaliter automatisch zou moeten worden doorgeschakeld naar een reserveonderdeel, bleef dit achterwege. Ondanks het Wob-verzoek van AT5 blijft onduidelijk hoe dit kon gebeuren. Intern is er daarentegen wel een rapport opgesteld naar aanleiding van deze storing, dat niet naar buiten mag komen uit angst voor beveiligingsrisico's. 

'Geen structureel probleem' 

Volgens de gemeentelijke analyse zou de storing van februari een op zichzelf staand incident zijn, dat onder 'normale omstandigheden' niet voor zou komen en geen structureel probleem vormt. Toch was de communicatie richting de stad volgens de gemeente onvoldoende geweest, mede doordat het informatienummer onbereikbaar was, en de loketten van de gemeente de gehele dag gesloten bleven. 

Moeizame communicatie

Over de interne communicatie kan er volgens AT5 niet worden gesteld dat deze geen structureel probleem vormt. De stadszender schetst het beeld van gefrustreerde ambtenaren die niet of nauwelijks worden geïnformeerd over de storingen. 

Volgens AT5 werkt de hoofdstad nu hard aan nieuwe draaiboeken en protocollen die voor sturing moeten zorgen bij dergelijke versterking. Ook een nieuw communicatieplan moet helderheid scheppen in tijden van verstoring. De plannen worden op korte termijn aan de gemeenteraad gepresenteerd.

 

 

Lees meer over Management OP AG Intelligence
2
Reacties
Atilla Vigh 12 juli 2019 08:17

Ik zou nog een stapje verder willen gaan wat betreft verstoringen. Hoeveel is het de inwoners waard om nooit meer een storing mee te maken. Voor een overheid (of dat nu een gemeente, provincie of rijksoverheidsinstelling is) wordt het na 99,99% erg duur. Ik hoor hele horden miskenden al roepen, ga in de cloud,, dan zijn al je problemen weg. Wat een naïef. Wat je als overheid vooral niet wil, zijn fouten die je in alle realiteit wel had kunnen voorkomen. Ik lees hier het niet navolgen van het meer-ogen principe en dat gebeurde toch. Dan zou ik dat geautomatiseerd doen: het is gewoonweg niet meer mogelijk om een wijziging door te voeren, als er twee mensen na gekeken hebben. Ik lees ook een uitvallend uitwijk onderdeel. Het is altijd mogelijk. Mijn eerste vraag zou zijn: is er getest op dit specifieke onderdeel. BCM (Business Continuity Management) waar DR (Disaster Recovery) een deel van uitmaakt, moet je net zo als software blijven testen. Maar tja, was testen geen sluitpost?

Peter Deutekom van 11 juli 2019 16:02

Een gedegen stappenplan is niet alleen voldoende. Het gaat juist om de sturing van de activiteiten. Wij hebben software ontwikkeld waarmee men niet alleen de mensen kan aansturen maar ook reclameren en informeren. Je bepaalt vantevoren wie er geïnformeerd wordt en het geschiedt daarna volledig automatisch waardoor altijd iedereen tijdig op de hoogte wordt gebracht.

Reactie toevoegen
De inhoud van dit veld is privé en zal niet openbaar worden gemaakt.