Het classificeren van systeemproblemen

Een probleem in de informatieverwerking kan vele oorzaken hebben. De neiging bestaat om een probleem gelijk op te lossen. Het is echter verstandig om het probleem eerst maar eens te onderzoeken. Aan de hand van de probleemanalyse kunnen we een probleem classificeren. Deze classificatie kunnen we dan gebruiken voor de keuze van een standaard plan van aanpak per klasse door applicatiebeheer. Voordeel van deze werkwijze is dat we na de classificatie niet lang hoeven na te denken over hoe we het probleem eens zullen aangepakken. Ook de onzekerheid of de aanpak voor een bepaald type probleem wel juist is wordt hiermee weggenomen.

Het nadeel is dat we een verkeerde aanpak kunnen kiezen als we de probleemanalyse of de classificatie niet juist uitvoeren. Hiermee moeten we met de nodige flexibiliteit omgaan.

Klasse A. Groot probleem (Release)

Als groot probleem te classificeren zijn problemen waarbij het systeem veel gewenste functionaliteit niet in zich heeft. Met andere woorden het informatiesysteem ondersteunt de gebruikersorganisatie in onvoldoende mate. 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.

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.

Klasse B. Veelomvattend probleem (Release)

Deze problemen ontdekken we in veel gevallen door beoordeling van de management-informatie of afwijkingen t.o.v. de kengetallen. Er blijkt bijvoorbeeld 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. Het zijn de systeem- of applicatiebeheerders die dit soort problemen meestal ontdekken.

Klasse D. Geïsoleerd probleem

Geïsoleerd problemen kunnen we aanmerken als problemen in de verwerking van individuele transacties waarbij we constateren dat deze transacties niet verder zijn te werken. Meestal zijn deze transacties 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. Optimaliseringsprobleem

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 spelen de bedrijfsprocessen ook vaak mee. Het zijn met name de eindgebruikers die dergelijke problemen bij de functioneel applicatiebe­heerder melden.

Klasse F. Performance

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 we onder klasse E kunnen scharen 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 uiten zich op twee manieren; ten eerste als responseprobleem voor online-verwerkingen; ten tweede als doorloopprobleem in de batchverwerking.

De eindgebruikers melden performance problemen bij applicatiebeheer. Af­hankelijk van de oplossing zou een wijziging van de database nodig kunnen zijn. In dat geval bestaat de kans dat we veel programmamodules opnieuw moeten compileren en testen, 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

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

Systeemtechnische problemen zullen noch door het management noch door de gebrui­kersorganisatie onderkennen. 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. Daardoor zijn individuele informa­tiesystemen vaak ondergeschikt aan dit soort problemen. T.g.v. van een klasse I probleem kunnen aanpassingen in het informa­tiesys­teem noodzakelijk zijn. Deze problemen kunnen we niet clusteren met problemen uit andere klassen. Daarom dienen we de prioriteit van systeemtechnische problemen af te stemmen met de prioriteit van de ande­re problemen. Dit kan alleen door onderling overleg tus­sen verwerkings- en gebruikersorganisatie.

Aard van een softwareprobleem

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 in te plannen.
De verdeling naar aard van een probleem passen we toe 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. Dit 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 we een probleem moet aanpakken.

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

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

Het meest spoedeisende karakter (prioriteit 1) is met name van toepassing voor het correc­tieve onderhoud en probleemklasse C. Daarbij moeten we aanmerken 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 raden we aan 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 kunnen we dan vast­stellen met welke prioriteit we zo’n probleem daadwerkelijk kunnen aanleveren 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.

Discussieer mee op LinkedIn.