problem management

Gebruik de 522 IT checklisten van ITpedia, met in totaal 22028 vragen.

Zoek in de omschrijvingenOmschrijvingAantal vragen
IT projectfaseringBestaat uit meerdere checklisten
Application Services Library (ASL)Bestaat uit meerdere checklisten
ContinuïteitBestaat uit meerdere checklisten
KwaliteitsattributenBestaat uit meerdere checklisten
Functies in de automatiseringBestaat uit meerdere checklisten
WebdesignBestaat uit meerdere checklisten
Of zoek naar een woord: Fulltekst

Laatst gebruikt: Continuiteitsbeheer op: 2017-02-26 09:32 Checklist
Toezenden van eerdere beoordelingen per e-mail.
E-mailadres:

Het classificeren van systeemproblemen

Een probleem in de informatieverwerking kan vele oorzaken hebben. De neiging bestaat om een probleem gelijk op te lossen. Misschien is het echter verstandig om het probleem eerst maar eens te onderzoeken. Aan de hand van de probleemanalyse kan een probleem worden geclassificeerd. Deze classifica­tie kan dan worden gebruikt voor de keuze van een standaard plan van aanpak per klasse door applicatiebeheer. Voordeel van deze werkwijze is dat na de classificatie niet lang nagedacht hoeft te worden over hoe het probleem eens aangepakt moet worden. Ook de onzekerheid of de aanpak voor een bepaald type probleem wel juist is wordt hiermee weggenomen. [Klik op de titel voor het gehele artikel]

Problemmanagement formulier

Het aanmelden en registreren van problemen is vergelijkbaar met het geven van een opdracht. Niet te min zijn er enige verschillen. Veel problemen kennen namelijk een spoedeisend karakter, hetgeen een speciale procedure vergt. Vandaar een apart formulier voor het aanmelden van problemen. Daarnaast is het voor de eindgebruiker niet altijd mogelijk om de oorzaak van problemen te onderscheiden. Bij complexe of omvangrijke problemen kunnen verschillende bijlagen nodig zijn om het probleem nader toe te lichten.[Klik op de titel voor het gehele artikel]

Van Wim Hoogenraad op 5 januari 2011 | Best practices | Aanvullen?
Tags:,
Checklisten: 2

Storingsclassificatie in relatie tot de SLA

Bij de invoering van een SLA tussen een datacenter en een gebruikersorganisatie dient er te worden vastgesteld 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 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 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 classificatie van de storingen wenselijk.

Totstandkoming Storings Classificatie

Problem management procedure

Uit het bovenstaande is af te leiden dat de storingen die bij het datacenter worden gemeld zich in allerlei objecten kunnen voordoen, namelijk in zowel apparatuur, besturingssoftware en applicaties. Het datacenter kent de zogenaamde Problem management procedure voor de afwikkeling van problemen in applicaties. Deze procedure ondersteunt het ProblemManagementFormulier en wordt voornamelijk gebruikt voor de communicatie tussen functioneel beheer en onderhoudsteam van de applicaties. Het overzetten van applicaties van ontwikkelomgeving naar testomgeving en van testomgeving naar productie-omgeving wordt door het datacenter aan de hand van het formulier uitgevoerd.

De aanmelding van de overige storingen gebeurt telefonisch, mondeling, via mail maar altijd centraal aan de Servicedesk. Deze registreert de storing. Van de gemelde storingen ontvangt de gebruikersorganisatie periodiek een overzicht over de doorlooptijd en de status van de reparatie 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 wordt het als er meerdere complexe storingen tegelijkertijd optreden. Bij meerdere storingen zal 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 kan worden tegengegaan door vast te blijven houden aan één storings-ongevoelig platform van apparatuur, besturingssoftware en applicaties.

Oplossingen

Het is een uitdaging voor het 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. Een aantal oplossingen zijn denkbaar. Het is echter de vraag of ze voor iedere organisatie wel allemaal reëel zijn. Er is niet naar de kosten gekeken bij het opstellen voor onderstaande oplossingen:

  • Inzet extra medewerkers; met meer personeel kunnen meerdere storingen tegelijkertijd worden opgelost waardoor het prioriteitsprobleem kleiner wordt.
  • Opleiding medewerkers; door het vergroten van de kennis zal de tijd om een storing op te lossen kleiner worden waardoor het prioriteitsprobleem kleiner wordt. Tevens wordt het escalatieprobleem kleiner, de medewerker zal in staat zijn om complexere storingen op te lossen.
  • Uitbesteden; alle storingen worden uitbesteed aan experts waardoor een oplossing van het escalatieprobleem verzekerd is. De vraag is of deze oplossing ook het prioriteitsprobleem wegneemt.
  • Spares; door een minimale voorraad van randapparatuur achter de hand te houden kunnen veel apparatuurstoringen snel worden opgelost.

Een combinatie van bovenstaande oplossingen geeft vaak goede resultaten.

Noodzaak voor ICT investeringen

Voordat een oplossing wordt gekozen moet worden bepaald of de oplossing d.w.z. de investering wel noodzakelijk is. Daarbij draait alles om de beschikbaarheidseisen die aan de objecten worden gesteld. De beschikbaarheidseisen kunnen worden afgeleid 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 de deadline niet wordt gehaald. Als deze storing zich bij een ander niet voor doet kan de deadline mogelijk wel worden gehaald. Deze situatie heeft direct een vermindering van de ernst (lagere severity) tot gevolg.
  • Financiële Schade :
    • Schade t.g.v. leegloop; De ernst van de storing wordt groter naarmate het aantal gebruikers dat niet verder kan groter is. Er kan een kostenpost door overwerk ontstaan.
    • 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 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 het imago, maar kunnen ook renteclaims worden ingediend. De hoogte van de mogelijke claim is 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 van de storing)

Om de severity van een storing vast te kunnen stellen wordt voorgesteld de volgende rekenmethodiek toe te passen :

Deadline: Binnen een werkdag Severity 4
Binnen twee werkdagen Severity 3
Binnen vijf werkdagen Severity 2
Binnen tien werkdagen Severity 1
Financiële schade Leegloop : .. Euro per gebruiker per uur.
Schade organisatie : Hoogte van bedrag
Schade relaties : 20 % van bedrag
Schade > 10.000,- Severity 4
Schade 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
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)


-- Printbare PDF-versie --