organisatieadvies

Ondersteuning van organisaties op menselijk niveau

Geschreven door: op 9 december 2012 @ 5:09 pm

Een bekend IT grapje is dat de zwakste schakel binnen de infrastructuur de (eind)gebruiker is: het aantal incidenten zou fenominaal teruglopen door deze schakel weg te nemen. Uiteraard is dat niet realistisch omdat het gebruik (en gebruikers) directe verbonden zijn aan het bestaansrecht van ICT dienst. Bovendien wordt de oorzaak van verstoringen volledig toebedeeld aan gebruikers. Onterecht, zeker nu de impact van gebruikersfouten vermindert als gevolg van de opmars van cloudcomputing en client-serverbased architecturen.

Zelfs een technocratische samenleving als die van de Borg (uit de science fiction serie Startrek) kan voordeel hebben van een fundamenteel ITIL-proces zoals Change Management. De meeste downtime in ICT-omgevingen wordt namelijk veroorzaakt door veranderingen in de infrastructuur en de gebrekkige communicatie die hier vaak mee gepaard gaat. De downtime wordt deels veroorzaakt door een verhoogd risico op technische storingen, maar in nog grotere mate door menselijk falen zoals aangetoond in deze scène.
Voor de hand liggende tips voor het pro-actief verminderen van het aantal als ICT-incidenten zijn:

  1. Identificeer de systemen waarvan de betreffende technische component deel uitmaakt. Zorg ervoor dat U van te voren de relatie tussen uw technische componenten met en Services die ze ondersteunen in kaart heeft gebracht met behulp van een Component Failure Impact Analysis (CFIA) en hierdoor weet welke diensten beïnvloed zullen door de beoogde change, en welke gebruikers u moet informeren.
  2. Controleer mogelijke gevolgen en (onvoorziene) risico’s met operationele beheersactiviteiten, andere projecten en bedrijfsplanningen door alle beoogde wijzigingen te laten toetsen door en andere technische medewerkers en vertegenwoordigers in een Change Advisory Board (CAB). Zorg ervoor dat uw CAB is samengesteld uit relevante leden op basis van inhoudelijke kennis en mandaat.
  3. Kies het optimale moment om de wijziging door te voeren, gebaseerd op het gebruikspatroon van de diensten die door de te wijzigen technische componenten gefaciliteerd worden.
  4. Plan en communiceer indien mogelijk de geplande change en het maintenance-window goed vooruit, zodat zowel (eind)gebruikers als andere technische medewerkers hun eigen planning hierop aan kunnen passen, zodat directe risico’s zullen afnemen, evenals de impact van de verstoringen die op kunnen treden in geval de wijziging onverhoopt mislukt.
  5. Communiceer uw geplande veranderingen door middel van een Forward Schedule of Change (FSC), of in goed Nederlands Wijzigings Kalender.
  6. Zorg dat U altijd een ‘plan B’  paraat heeft voor het geval een doorgevoerde change mislukt of onvoorziene en ongewenste effecten veroorzaakt.  Definieer een rollback-scenario en zorg ervoor dat u precies het kritieke punt (het ‘point of no return‘) en stel dit vast als formeel beslis-moment.

Bron videofragment:  Star Trek Voyager – Seizoen 4 Episode 7 ‘Scientific Method’. Alle rechten van Star Trek ® berusten bij CBS Studios Inc. Dit videofragment wordt alleen gebruikt voor educatieve doeleinden.

Tags: , , , , , , , , , , , , , , , ,

Categorien: procesmanagement

Laat een reactie achter

RSS