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.

Het nadeel is dat er een verkeerde aanpak kan worden gekozen als de probleemanalyse of de classificatie niet juist worden uitgevoerd; hiermee moet met de nodige flexibiliteit worden omgegaan.

Klasse A. Groot probleem. (Release)
Als grote problemen te classificeren zijn problemen waarbij het systeem veel gewenste functionaliteit niet in zich heeft. Met andere woorden de gebruikersorganisatie wordt onvoldoende door informatiesysteem ondersteund. Bij deze problemen is het uitgangs­punt dat de werking van het informa­tiesys­teem wel voldoet aan de actuele eisen en wensen maar niet aan de toekomstige. Kenmerkend voor dit soort proble­men is dat de nieuwe wensen vaak van buiten de gebruikersorganisatie worden geïnitieerd. Klasse A problemen leiden vaak tot het definiëren van een nieuwe release van het informatiesys­teem.

Klasse B. Veelomvattend probleem. (Release)
Van veelomvattende problemen is sprake als de problemen mogelijk te herleiden zijn naar meerdere programmamodules; de oorzaak van de problemen is niet direct aanwijs­baar of de problemen hebben meerdere symptomen. Onder deze klasse laten zich tevens programmamodules vatten die individueel meerdere problemen veroorzaken. Ook de (eenduidig) onjuistheid van grote groepen van records valt onder deze klasse.

Deze problemen worden in veel gevallen ontdekt door beoordeling van de management-informatie of afwijkingen t.o.v. de kengetallen. Er blijkt b.v. dat bepaalde groepen records niet of verkeerd worden verwerkt. Bij een klasse B probleem volgt meestal automatisch de definitie van een nieuwe release van het informatiesysteem.

Klasse C. Ernstig probleem.
Ernstige problemen kenmerken zich door een plotselinge stagnatie in de voortgang van de werkzaamheden. Deze problemen openbaren zich zodanig dat de facturering of uitbetaling geheel of gedeeltelijk niet meer plaats kunnen vinden; de formulierenstroom binnen de organisatie geheel of gedeeltelijk stop ligt of de nacht- of dagbatch geheel of gedeeltelijk niet meer draait. Het moment waarop zich één van deze problemen voordoet is sterk bepalend voor de ernst. Belangrijk ijkpunt is het tijdstip waarop in het primaire bedrijfsproces noodzakelijke verwerkingen moeten plaatsvinden zoals het uitdraaien van facturen. Een ander belangrijk punt zijn de externe gebruikers (klanten) van het informa­tiesysteem. Zij mogen zo min mogelijk merken van het falen van het systeem. Het aan­maken bepaalde transacties moeten soms ala minute plaats kunnen vinden. Naarmate zo’n ijkpunt bij het optreden van het probleem nadert zal de ernst groter zijn. Klasse C problemen concentreren zich in de meeste gevallen in één module of op het niveau van één record in de database (klasse D). Toch hebben ze directe gevolgen voor de primaire bedrijfsprocessen waardoor er geen sprake kan zijn van een release. Deze problemen worden meestal door de systeem- of applicatiebeheerder ont­dekt.

Klasse D. Geïsoleerd probleem.
Geïsoleerd problemen kunnen worden aangemerkt als problemen in de verwerking van individuele mutaties waarbij moet worden geconstateerd dat deze mutaties niet verder zijn te werken. Meestal zijn deze mutaties ten onrechte op een verkeerde status terecht gekomen of is er een ‘hik’ in het systeem opgetreden. Klasse D problemen worden meestal door de gebruikers bij de applicatiebeheerder aangemeld en kunnen individueel grote spoed hebben vanwege het financiële of directe belang dat met de mutatie is gemoeid. Een klasse D probleem wordt volgens een korte procedure, eventueel als enkelvoudi­ge SQL-update afgewikkeld. Problemen die minder spoedeisend zijn worden door de applicatiebeheerder ingepland als correctief onderhoud.

Klasse E. Optimaliserings-probleem.
Optimaliseringsproblemen zijn wensen waarmee de gebruiker vaak spontaan komt. Veelal gaat het optimaliseren van het werk op de afdeling, d.w.z. het verhogen van het gebruikers­gemak of de efficiëntie. Te denken valt aan het wijzigen van lijstindelingen of het integre­ren van schermen. Klasse E problemen verstoren de voortgang van de werkzaamheden op de afdeling doorgaans niet doch zouden bij oplossing de voortgang wel kunnen versnel­len. Het clusteren met andere problemen tot een release kan eenvoudig plaatsvin­den. Bij beoordeling van dergelijke problemen speelt vaak een ook een A.O. aspect mee. Het zijn met name de eindgebruikers die dergelijke problemen bij de applicatiebe­heerder melden.

Klasse F. Performance probleem.
Performance problemen uiten zich op twee manieren; ten eerste als responseprobleem voor online-verwerkingen; ten tweede als doorloopprobleem in de batchverwerking.

Afhankelijk van de impact kan de ernst van een performance probleem kan zeer sterk variëren. Uitgangspunt moet zijn dat de verwerking binnen de daartoe gestelde tijd moet kunnen plaatsvinden. Performance problemen zouden onder klasse E geschaard kunnen worden als er niet een aparte aanpak vereist zou zijn. Omdat er functioneel geen wijzigingen in de programmamodules kunnen plaatsvinden a.d.h.v. een performancepro­bleem zijn wijzigingen op het functionele ontwerp of de administratieve organisatie niet nodig.

Performance problemen worden door de eindgebruikers bij de applicatiebeheerder gemeld. Af­hankelijk van de oplossing zou een wijziging van de database nodig kunnen zijn. In dat geval bestaat de kans dat er veel programmamodules opnieuw gecompileerd en getest moeten worden; iets om planningstechnisch rekening mee te houden.

Klasse G. Storend probleem.
Storende problemen hebben doorgaans geen effect op een juiste verwerking van de mutaties in het informatiesysteem. Het komt echter voor dat eindgebruikers bij hun dagelijkse werkzaamheden ten on­rechte een boodschap op het scherm krijgen; dat kleine letters niet omgezet worden naar grote of dat voorloopnullen moeten worden ingegeven waar dat niet nodig is. Veel van deze correctieve problemen blijven door hun ondergeschikte belang vaak lang in informatiesystemen zitten en wekken daarmee dagelijks de ergernis van de gebruikers, die de problemen aanleveren op. Deze proble­men zijn echter door de gebruikers zelf veroorzaakt door een onvoldoende secure acceptatietest voor de in productie name. Om toch enige voortgang in de afwikkeling van deze problemen te krijgen ligt het clusteren met andere problemen in een release voor de hand.

Klasse H. Esthetisch probleem.
Esthetische problemen worden door de eindgebruikers vaak als storend probleem aangemeld. Bij een klasse H probleem is er echter sprake van een gewenste lay-out wijziging waardoor dit adaptieve probleem vaak goed samen met andere problemen kan worden opgelost.

Klasse I. Systeemtechnisch probleem.
Systeemtechnische problemen zullen noch door het management noch door de gebrui­kersorganisatie worden onderkend. Zij worden veelal door de verwerkingsorganisa­tie aangemeld en worden vaak, terwijl toekomstige problemen worden voorkomen als slechts hinderlijk ervaren. Meestal overstijgen klasse I problemen een informatiesys­teem ­waarmee de individuele informa­tiesystemen aan het probleem ondergeschikt worden gemaakt. T.g.v. van een klasse I probleem kunnen aanpassingen in het informa­tiesys­teem noodzakelijk zijn. Deze problemen kunnen niet worden geclusterd met problemen uit andere klassen. Daarom dient de prioriteit van systeemtechnische problemen te worden afgestemd met de prioriteit van de ande­re problemen. Dit kan alleen door onderling overleg tus­sen verwerkings- en gebruikersorganisatie.

Aard van een probleem.
Ongeacht de klasse waarin een probleem valt heeft het probleem een zekere aard waaronder het valt te rangschikken. Hoewel er theoretisch geen verband bestaat tussen­ klasse en aard van een probleem is in de praktijk wel een globale verdeling te maken.

De meeste methodologieën maken het volgende onderscheid :

a.   Preventief onderhoud; onderhoud ter voorbereiding van komende omgevingswij­zigin­gen.
              Klasse : I.

b.  Perfectief onderhoud  ; onderhoud ter verbetering van het informatiesysteem.
              Klasse : E en F.

c.   Correctief onderhoud; onderhoud a.g.v. afwijkingen t.o.v. het systeemontwerp en het buiten werking treden van systeemfuncties.
              Klasse : B, C, D en G.

d.  Adaptief onderhoud; het toevoegen van nieuwe functionaliteit aan informa­tiesys­temen t.g.v. nieuwe regelgeving of veranderde inzichten.
              Klasse : A en H.

 Ondanks het grote aantal probleemklassen blijkt met name categorie c, het correctieve onderhoud als spoedeisend en moeilijk te plannen te worden gekenmerkt.
De verdeling naar aard van een probleem wordt toegepast om een gefundeerd onder­houdscontract op te stellen.

De ernst van een probleem.
De ernst van een probleem en daarmee de spoedeisendheid is afhankelijk van wat de directe gevolgen zijn van het probleem voor de organisatie. De ernst is dus niet afhanke­lijk van de klasse of de aard waartoe een probleem behoort. De ernst is echter wel bepalend voor de voortvarendheid waarmee een probleem moet worden aangepakt.

De ernst van een probleem is dus bepaald voor de prioriteit die uiteenvalt in 4 catego­rieën:

4.        Niet tijdkritisch; in onderling overleg aanvangen met oplossing.
3.        Enigszins tijdkritisch; binnen 5 werkdagen aanvangen met de realisatie of zoveel eerder als mogelijk.
2.        Tijdkritisch;bedreigend voor een minder kritisch bedrijfsproces; binnen 2 werkda­gen aanvangen met de realisatie of zoveel eerder als mogelijk.
1.        Zeer tijdkritisch;bedrei­gend voor een kritisch bedrijfsproces; zoveel mogelijk direct aanvangen met de oplossing.

Het meest spoedeisende karakter (prioriteit 1) is met name van toepassing voor het correc­tieve onderhoud en probleemklasse C. Daarbij moet worden aangemerkt dat de ernst en de prioriteit toeneemt naarmate een ijkpunt in het primaire bedrijfsproces nadert.

•    Om de ernst van een probleem goed te kunnen bepalen wordt aangeraden om vooraf elke programmamodule (bedrijfsproces) binnen een informatiesysteem van een ernst-code te voorzien. Dit kan door in overleg met de gebruikersorganisatie de lijst met programmamodules door te lopen en de modules van een code te voorzien. Samen met de klasse (wegingsfactor) waarin een actueel probleem valt kan dan worden vastge­steld met welke prioriteit zo’n probleem daadwerkelijk wordt aangele­verd aan het onder­houdsteam.

Bij omvangrijke informatiesystemen kan een dergelijke inventarisatie de nodige inspan­ning vergen. De inspanning zal zich later echter snel terug verdienen.

De ernst is mede bepalend voor de wijze waarop volgens het contract met de onderhoudsorganisatie het probleem wordt opgelost.

Boeken over dit onderwerp

ITIL 2011 Editie – Pocketguide (NL)

Auteur: Jan van Bon
Deze pocketguide voorziet in dezelfde behoefte als de vorige edities: het bieden van een nauwgezette samenvatting van ITIL, gebaseerd op ITIL 2011 Editie.
Europrijs: 18,55
Bestellen

ITIL Service Operation – 2011 Edition

Auteur: Office of Government Commerce
Dit boek introduceert Service Operation en legt de activiteiten uit op het gebied van levering en controle en beschrijft welke Service Operations hierbij ondersteuning geven.
Europrijs: 85,0
Bestellen

Meer boeken over problem management vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Onderhouds procedures 36 vragen.
Storingsafhandeling en registratie 31 vragen.
Audit organisatie verwerkingsorganisatie 52 vragen.
Sidebar