Storingsclassificatie in relatie tot de SLA

Storingsclassificatie geeft een SLA meer diepgang en geeft bovendien ruimte in het afhandelen van storingen. Bij de invoering van een SLA tussen een datacenter en een gebruikersorganisatie dienen we vast te stellen wat de snelheid is waarmee storingen worden opgelost door het datacenter. In de SLA staat vaak het volgende :

“Datacenter is verantwoordelijk voor het oplossen van storingen aan apparatuur, besturingssoftware en applicaties welke onder haar beheer vallen. Zo spoedig mogelijk na het ontstaan van de storing zal deze zijn verholpen dan wel zullen bindende afspraken worden gemaakt voor de oplossing. Prioriteit en reactietijd zijn namelijk afhankelijk van de ernst (severity) en de impact van het probleem. Datacenter zal, in samenwerking met de functionele beheerders, een procedure uitwerken waarin wordt afgesproken in welke situatie een bepaalde ernst van toepassing is en hoe daar op gereageerd moet worden.”

Dit artikel geeft een aanzet en is bedoelt als vertrekpunt voor de uitwerking voor de afhandeling van storingen. Voor het Datacenter is echter het uitgangspunt dat storingen altijd zoveel mogelijk voorkomen moeten worden. In de SLA is beschreven welke maatregelen daarvoor zijn genomen. De ene storing is de andere niet en om juist te kunnen handelen is storingsclassificatie wenselijk.

Totstandkoming Storingsclassificatie

Uit het bovenstaande is af te leiden dat de storingen die het datacenter krijgt gemeld zich in allerlei objecten kunnen voordoen, namelijk in zowel apparatuur, besturingssoftware en applicaties. De aanmelding van de meeste storingen gebeurt telefonisch, mondeling, via mail maar altijd centraal aan de Servicedesk. Deze registreert de storing met ook altijd in een ticketsysteem, inclusief classificatie.

Problem management procedure

Het datacenter kent de zogenaamde Problem management en Incident management procedures voor de afwikkeling van problemen in applicaties. Deze procedures ondersteunen het ProblemManagementFormulier en worden dan ook voornamelijk gebruikt voor de communicatie tussen functioneel beheer en het onderhoudsteam van de applicaties. Het overzetten van applicaties van ontwikkelomgeving naar acceptatie testomgeving en van testomgeving naar productie-omgeving voert het datacenter eveneens aan de hand van deze procedure uit.

Van de gemelde storingen ontvangt de gebruikersorganisatie periodiek een overzicht over de doorlooptijd en de status van het herstel conform de SLA.

Problemen met storingen

Als er één gebruiker is met één eenvoudige storing zijn er weinig problemen bij het oplossen van deze storing te verwachten. Moeilijker is het als er meerdere complexe storingen tegelijkertijd optreden. Bij meerdere storingen zal bovendien de volgorde van afwerking een rol gaan spelen (prioriteit), bij complexe storingen zal het uitbesteden van de storing een rol spelen (escalatie). Door een steeds bredere inzet van complexere informatietechnologie zullen deze twee typen problemen meer voorkomen dan vroeger. D.w.z. dat storingen vaker in prioriteit afgehandeld zullen gaan worden terwijl vaker een beroep op experts gedaan moeten worden. Een toename van deze problemen kunnen we al tegengaan door vast te blijven houden aan één storings-ongevoelig IT platform van apparatuur, besturingssoftware en applicaties.

Oplossen van storingen

Het is al een uitdaging voor ieder datacenter om het aantal onderhanden storingen zo klein mogelijk te houden. Niet alleen de druk op de medewerkers zal daardoor afnemen, ook de tevredenheid van de eindgebruikers zal toenemen. Er zijn echter een aantal voorzorgsmaatregelen denkbaar. Storingsclassificatie speelt hierin altijd een belangrijke rol. Het is echter de vraag of deze oplossingen voor iedere organisatie wel allemaal reëel zijn. Er is niet naar de kosten gekeken bij het opstellen van de lijst met onderstaande oplossingen:

• Inzet extra medewerkers: met meer personeel kunnen we meerdere storingen tegelijkertijd oplossen waardoor het prioriteitsprobleem kleiner wordt.
• Opleiding medewerkers: door het vergroten van de kennis maken we de tijd om een storing op te lossen kleiner, waardoor het prioriteitsprobleem kleiner wordt. Tevens maken we het escalatieprobleem kleiner, de medewerker zal in staat zijn om zelf complexere storingen op te lossen.
• Uitbesteden: alle storingen besteden we uit aan experts waardoor een oplossing van het escalatieprobleem verzekerd is. De vraag is of deze oplossing ook het prioriteitsprobleem wegneemt. Storingsclassificatie blijft daarom noodzakelijk.
• Spares: een minimale voorraad van (rand)apparatuur achter de hand houden waardoor we veel apparatuurstoringen snel kunnen oplossen.

Een combinatie van bovenstaande oplossingen geeft vaak goede resultaten.

Noodzaak voor ICT investeringen

Voordat we een oplossing kiezen moeten we bepalen of de oplossing d.w.z. de investering wel noodzakelijk is. Daarbij draait ook alles om de beschikbaarheidseisen die we aan de objecten stellen. Deze beschikbaarheidseisen kunnen we echter afleiden van een aantal factoren die de ernst (severity) van een storing bepalen. De volgende beschikbaarheidsfactoren spelen een rol:

• Deadline: De werkzaamheden moeten volgens contracten of regelgeving voor een bepaalde tijd zijn afgerond. Het kan voorkomen dat één bepaalde medewerker een storing heeft waardoor we de deadline niet halen. Als deze storing zich bij een ander niet voor doet kan je de deadline mogelijk wel halen. Deze situatie heeft dan ook direct een vermindering van de ernst (lagere severity) tot gevolg.
• Financiële Schade:
  • Schade t.g.v. leegloop: De ernst van de storing neemt toe naarmate het aantal gebruikers dat niet verder kan groter is. Er kan namelijk een kostenpost door overwerk ontstaan.
  • Financiële Schade voor de organisatie: Als nota’s of heffingen niet (op tijd) worden verzonden heeft dit direct financiële gevolgen voor de organisatie. De hoogte van de bedragen is dan ook bepalend voor de ernst van de storing.
  • Schade bij relaties: Als organisatie niet is staat is om op tijd uit te betalen, heeft dit niet alleen gevolgen voor de reputatie, maar men kan ook renteclaims indienen. De hoogte van de mogelijke claim is namelijk mede bepalend voor de ernst van de storing.
• Informatievoorziening: Als enige tijd geen update van de informatievoorziening plaatsvindt zal dit leiden tot ontevredenheid bij gebruikers. Uiteindelijk zullen ze hun informatie ergens anders proberen te verkrijgen.

Bepaling severity (Ernst) levert de storingsclassificatie

Om de severity van een storing vast te kunnen stellen passen we als voorbeeld de volgende rekenmethodiek toe. De invulling kan per organisatie  verschillen:

Deadline:	Deadline binnen een werkdag	Severity 4
	Binnen twee werkdagen	Severity 3
	Binnen vijf werkdagen	Severity 2
	Deadline binnen tien werkdagen	Severity 1
Financiële schade	Leegloop : .. Euro per gebruiker per uur.
	Schade organisatie : Hoogte van bedrag
	Externe schade relaties : 20 % van bedrag
	Schade > 10.000,-	Severity 4
	Tussen 2.000 en 10.000	Severity 3
	Schade tussen 1.000 en 2.000	Severity 2
	Schade < 1.000,-	Severity 1
Informatie voorziening
	Informatie verliest waarde binnen een werkdag	Severity 4
	De informatie verliest waarde binnen twee werkdagen	Severity 3
	Informatie verliest waarde binnen vijf werkdagen	Severity 2
	Informatie verliest waarde binnen tien werkdagen	Severity 1

Download escalatieschema (pdf)

Discussieer mee op LinkedIn.