Van Beheer tot Continuity Plan

Inhoudsopgave

  1. Inleiding
  2. De basis voor continuďteit van een organisatie
  3. Continuďteit door voorbereiding op rampen
  4. Continuďteit door voorbereiding op rampen en kansen
  5. Afsluiting

1. Inleiding

We hopen allemaal dat we ze niet nodig hebben, onze back-ups, maar helaas blijkt in veel situaties dat ze onmisbaar zijn in onze organisaties. Het spreekwoord ’Als het kalf verdronken is, dempt men de put’ klinkt wat ouderwets, dus tijd voor wat nieuws. ‘Na een stroomstoring wordt een plan gemaakt, voor onderhoud van de batterijen van de UPS en na een brand maakt men een Business Continuity Plan.’ Misschien is dit toch wat te lang, dus moeten we het oude maar houden. Er zit namelijk veel waarheid in het spreekwoord, want de meeste organisaties hebben een recoveryplan dat niet veel meer afdekt dan de rampen die ze (van nabij) hebben meegemaakt. En dit terwijl onderzoek heeft uitgewezen, dat tussen de 40 en 50% van de organisaties met een onvoldoende getest of afwezig recovery plan na een echte ramp ten onder gaan. Een paar procent gaat niet direct failliet, maar pas in de nasleep of redt zich nog één of twee jaar.
Maar goed, wat is de kans op zo’n ramp? Nihil toch? En wat kost het om een goed plan op te zetten en te onderhouden? Heel veel geld en tijd toch? Misschien wel, maar net als bij het afsluiten van een verzekering is het belangrijk om minimaal te hebben nagedacht over de risico’s, de kans op die risico’s, de mogelijkheden om deze te voorkomen en de mogelijkheden om de gevolgen te verzachten. Organisaties moeten omschakelen van onbewust risico’s lopen naar bewust risico’s nemen. Afhankelijk van de rijpheid van de organisatie kan een continuity plan worden doorgevoerd. In drie niveaus wordt deze rijpheid duidelijk gemaakt. Op het eerste niveau ligt de nadruk op beheer. Wanneer dat goed geregeld is, kan op het tweede niveau met rampenplannen begonnen worden. Op het derde niveau wordt tenslotte een business continuity plan uitgewerkt, waarmee de organisatie zich sterk en soepel maakt, om op de juiste manier te kunnen reageren op "alle" wijzigingen.

2. De basis voor continuďteit van een organisatie

Een praktijkvoorbeeld

In een logistieke organisatie wordt een disaster recovery test gedaan voor de iSeries met het ERP pakket. De test wordt uitgevoerd in de mobiele IBM uitwijklocatie. Tijdens de test blijkt, dat de nieuwe vorm van de dag back-up niet is opgenomen in de restore procedure. Prima test toch? Er kunnen nu verbeteringen doorgevoerd worden. Maar de organisatie vindt het toch wel belangrijk dat alles goed werkt, dus enige tijd later wordt een volgende test gedaan. Helaas, de weekback-up blijkt op een corrupte tape te zijn opgeslagen. Wanneer worden de tapes eigenlijk vervangen? Oeps, er moet dus een vervangschema gemaakt worden voor oude en gevallen tapes. Een maand later wordt weer een test gedaan, want de organisatie is nog niet tevreden. De restore verloopt nu prima, gelukkig. Er wordt een start gemaakt met een prille gebruikerstest, om te kijken of alles goed werkt. Dan komt het moment, dat de export afdeling niet via de vaste lijn, maar met een modemverbinding de EDI uitwisseling met de douane moet testen. Het modem blijkt niet goed aangesloten te zijn. Helaas wordt het uitwijksysteem opgehaald voor dit probleem is op te lossen. Er wordt nu in ieder geval een testplan gemaakt voor het modem, waarbij het modem vanaf het productiesysteem getest kan worden…

Conclusies:

  • Beheer en beheerprocedures van het systeem zijn toch echt de basis om risico’s te voorkomen.
  • Een goede back-up, noodprocedures, workarounds en een goed en bijgehouden disaster recovery plan zijn noodzakelijk om onverwachte uitval op te vangen.
  • Het testen van procedures en plannen voor disaster recovery moet op regelmatige basis plaatsvinden. Wanneer een test niet soepel is uit te voeren, moet er niet een jaar gewacht worden voor de volgende test.

Door de eerste disaster recovery laag uit te werken worden kleinere rampen voorkomen of opgelost. Deze kleinere rampen moeten niet onderschat worden. Uitval van een core systeem in een volcontinu bedrijf kan enorme kosten met zich meebrengen. Gelukkig is een goede voorbereiding mogelijk. Een werkstation, printer of ander apparaat dat uitvalt, een kabelbreuk, uitval van telefoon of internetverbinding, een server schijfcrash en stroomuitval zijn met goed systeembeheer, afspraken met leveranciers (SLA’s) en een goed restoreplan prima op te lossen. Iedere organisatie kent deze incidenten en de plannen voor onderhoud en recovery kunnen voor deze situaties tot in detail in draaiboeken worden uitgewerkt en getest.

3. Continuďteit door voorbereiding op rampen

Er kan pas doorgegaan worden met de volgende laag van de continuďteitsplanning, wanneer dit eerste niveau bereikt is. De tweede laag verlegt de focus van beheer naar rampen. Rampen kunnen er voor zorgen, dat de complete kantoorruimte en/of fabrieksruimte van de kaart geveegd worden en kunnen ook de medewerkers binnen de organisatie treffen. Deze rampen zijn lastiger. Het is moeilijk om zich een voorstelling te maken van deze rampen en hun impact. Dit blijkt bij elke ramp en rampentest. Moeten organisaties zich bijvoorbeeld voorbereiden op oorlog, een neergestort vliegtuig, een overstroming, een aardbeving of een epidemie zoals de vogelgriep?
Allerlei factoren bepalen in hoeverre een organisatie zich hierop kan voorbereiden. Het is echter voor iedere organisatie belangrijk om hier bij stil te staan.

Omdat de rampen nauwelijks te bevatten zijn, is het verstandig om zich van binnenuit voor te bereiden. Wanneer duidelijk is, wat de belangrijke processen zijn en wat de impact is wanneer deze processen uitvallen, kunnen de juiste voorzorgsmaatregelen genomen worden.
Dit interne onderzoek wordt een BIA (Business Impact Analysis) genoemd. Een BIA is een essentieel onderdeel van elke continuďteitsplanning. Het bevat aan de ene kant een onderzoekselement, waarin alle functies en processen met hun mogelijke bedreigingen worden opgenomen. Aan de andere kant bevat het een strategie-ontwikkelingselement voor het minimaliseren van de bedreigingen.

Nadat alle processen en functies zijn uitgezocht en beschreven, kan aan ieder vastgelegd proces en functie een RPO (Recovery Point Objective) en RTO (Recovery Time Objectives) gekoppeld worden. De RPO bepaalt hoeveel verlies te tolereren is. Wanneer bijvoorbeeld een verlies van 10 minuten werk te tolereren is, dan is de RPO voor die functie 10. Is een verlies van 0 minuten te tolereren, dan is de RPO 0. De RTO is de tijd, waarbinnen de functie weer operationeel moet zijn na uitval, voordat dit negatieve impact heeft. De RTO wordt gebruikt om functies en processen een prioriteit te geven binnen het recovery proces. Zo kan er een indeling worden gemaakt, van groepen processen en functies die binnen een bepaald tijdstip weer actief moeten zijn. Bijvoorbeeld range 1 met processen die tussen 0-24 uur weer moeten draaien en range 2 met alles wat tussen 24-48 uur weer moet draaien, enzovoort. Alle processen binnen range 1 moeten zo snel mogelijk hersteld. Daarbij moet rekening worden gehouden met de noodzakelijke resources voor de restore en de hersteltijd zelf. Bij andere organisaties zal een indeling in perioden van 5 uur worden gemaakt, of mogelijk van 48 uur waarbinnen processen weer actief moeten zijn.

In het kort bestaat de BIA met bijbehorende activiteiten uit negen stappen:

  1. Maak, eventueel per afdeling, een lijst van functies en processen die binnen de organisatie van belang zijn.
  2. Bepaal wat mogelijke verliezen zijn, als de functie of het proces uitvalt. Bedenk wat dit financieel betekent door verloren inkomsten, boetes en extra uitgaven, om de situatie op te lossen. Bepaal ook de kosten die ontstaan door reputatieverlies, negatieve publiciteit, waardevermindering van aandelen en dergelijke.
  3. Bepaal de tijdstippen waarop een interruptie het hardst aankomt voor een functie of proces. Is bijvoorbeeld het weekeinde, een kwartaalafsluiting of jaarafsluitingen het ergste moment?
  4. Link de functies en processen aan de resources, die de processen ondersteunen. Denk aan input van data, een ander proces, dat nodig is voor dit proces of misschien de acties van een sleutelgebruiker.
  5. Bepaal afhankelijkheden van functies en processen. Kan het uitvallen van andere functies of processen oorzaak zijn voor het uitvallen van deze functie?
  6. Leg workarounds vast. Zijn er methoden om door te gaan met andere input of een andere workflow?
  7. Zorg voor de juiste recovery strategieën door ranges te maken naar de tijdsduur waarin de processen kunnen functioneren zonder de infrastructuur, die ze normaal ondersteunt.
  8. Zorg voor de juiste classificatie van de processen en functies, op basis van het belang ervan voor de organisatie.
  9. Identificeer de kritische fysieke recovery resources en leg dit naast de tijd waarbinnen ze beschikbaar moeten zijn om de recovery goed te kunnen uitvoeren. (Denk aan mensen, middelen en data.)

Dit levert informatie op, over wat belangrijk is voor de organisatie om door te kunnen na een ramp. Er zijn verschillende oplossingen mogelijk en er moeten keuzes gemaakt worden. Zo kunnen onderdelen worden verzekerd of uitbesteed. Er kan een strategie bedacht worden om problemen te voorkomen of te vermijden. De strategie kan ook bepalen dat risico’s gespreid of mogelijk zelfs getolereerd worden. Leg dit vast met de reden waarom voor deze oplossingen gekozen is. Leg ook vast wat de acties zijn wanneer getolereerde risico’s zich voordoen. Het zal duidelijk zijn, dat een BIA waardevol is voor het bepalen van de juiste plannen en procedures voor disaster recovery. Ook de oudere disaster recovery plannen worden met een BIA onder de loep genomen, verbeterd en opgenomen in het geheel.

4. Continuďteit door voorbereiding op rampen en kansen

Wanneer het vanzelfsprekend is geworden, dat er oplossingen liggen voor de rampen, kan de focus weer verlegd worden. De zakelijke omgeving wordt tegenwoordig gekenmerkt door snelle en onvoorspelbare wijzigingen. Deze wijzigingen kunnen kansen zijn, uitdagingen of bedreigingen. Wanneer de rampenplannen gemaakt zijn, kan de organisatie zich richten op de kansen.

Een kans is positief, maar kan een zware bedreiging worden, wanneer de organisatie hier niets mee kan, terwijl de concurrent deze wel oppakt. Of stel dat de kans wordt opgepakt en zo’n groei oplevert, dat de capaciteit de vraag niet meer aankan. Klanten worden teleurgesteld met alle gevolgen van dien. Alle wijzigingen van bedreiging tot kans zijn dus een risico.
Om je hierop voor te bereiden moet de organisatie veerkrachtiger worden. Er moet robuust, anticiperend en adaptief op wijzigingen gereageerd kunnen worden. Er moet snel gereageerd kunnen worden op veranderende marktcondities en veranderende regelgeving vanuit de overheid. Door inhuur en/of training moet toegang verkregen worden tot de juiste expertise en skills. Er moet blijvend gewerkt worden aan vermindering van risico’s en de organisatie moet zich blijven bezig houden met beveiliging, privacy en data protectie.
Om dit te realiseren wordt een levenscyclus opgestart waarin de BIA centraal staat. Alle risico’s, dus ook de risico’s van kansen, worden meegenomen. Eerst wordt een framewerk gemaakt waarin de belangrijkste onderdelen van de organisatie zijn opgenomen. Hiermee wordt een goed beeld verkregen van die onderdelen die aangepakt moeten worden. Het framewerk kan bestaan uit:

  • Strategische functies met de dagelijkse activiteiten, die de continuďteit van het dagelijks werk verzorgen, zoals financiën en productie.
  • Menselijke functies met de verantwoordelijkheden, vaardigheden en kennis van medewerkers, zoals human resources en training.
  • Proces functies waarin kritische processen met hun IT processen opgenomen worden, zoals accounts payable, accounts receivable, change management en problem management.
  • Technologie functies waar netwerk, industriespecifieke technologie met applicaties en data horen.
  • Faciliterende functies zoals fabrieken, kantoren en bijvoorbeeld ook fysieke beveiligingsacties.

Dan wordt gestart met het controleren en beheren van de verschillende functies en processen in het framewerk. Daaruit kunnen voorspellingen en ontdekkingen worden gedaan, van de sterke en zwakke plekken binnen het bedrijf. De gevonden risico’s worden uitgewerkt. De strategieën, technieken en processen worden aangepast en geoptimaliseerd. Ze worden opgenomen in de organisatie en veiliggesteld. Daarna start de volgende cyclus met het controleren en beheren van de functies en processen.

5. Afsluiting

Om te komen tot een veerkrachtige organisatie is veel tijd en inspanning nodig. Bij alle stappen vanaf goed beheer tot een continuity plan voor een veerkrachtige organisatie komt één punt heel duidelijk naar voren: Het is voor alle procedures en plannen noodzakelijk om je organisatie goed in kaart te brengen. Ken je je organisatie dan kan je ook de juiste maatregelen nemen bij een ramp. Start dus met het in kaart brengen van de organisatie, demp vervolgens de putten zodat het kalf niet kan verdrinken en groei daarna uit tot een veerkrachtige organisatie.

De auteur, Mathilde Verhagen, is senior iSeries-consultant bij Acropolis Groep.


Dit artikel downloaden


In de rubriek
 ' ICT-bedrijven en gebruikers
vindt u meer artikelen over dit onderwerp.