Problem-management na in productie name

Bij omvangrijke maatwerksystemen zal er zeker na de in productie name een grote stroom van problemen op gang komen. Problem-management wordt ingezet om niet de verzanden in een brei van problemen, foutmeldingen, storingen en verschillen in versies van modules. We moeten zoeken naar een structuur waarin we de toevloed van problemen kunnen stroomlijnen. De beheersing van zo’n omgeving noemen we ook wel Change management.

Problem-management, de probleem analyse

Problemen die zich t.a.v. de applicaties bij applicatiebeheerders aandienen kunnen van velerlei aard en diepgang zijn. Tevens melden verschillende personen en instanties problemen aan. Om te komen tot een gestroomlijnde aanpak van problemen moeten we deze problemen eerst classificeren naar aard en herkomst. Volgende de Problem-management processen moet hiervoor moet eerst een probleemanalyse plaats te vinden. De probleemanalyse door de (functioneel)applicatiebeheerder dient de volgende gegevens op te leveren:

• Aantal betrokken programmamodules.
• Controle status betrokken programmamodules. Voor een juist versiebeheer dienen we rekening te houden met het overige onderhanden onderhoud.
• Aantal betrokken databases.
• Omvang van de betrokken data.
• Ernst van het probleem.
• Aard van het probleem (Adaptief, correctief…).
• Controle of werking overeenkomt met de beschrijving in het ontwerp.
• Eventueel controle op de broncode.
• Eventueel afstemming met eindgebruikers.
• Afstemming met onderhoudsteam.
• Indicatie van de oplossingsrichting.
• Aangeven of aanpassing van het ontwerp nodig is.
• Aangeven of aanpassing van de programmamodules nodig is.
• Indien nodig aangeven of aanpassing van de bedrijfsprocessen nodig is.
• Eventueel eenvoudige aanpassing Database d.m.v. SQL-update doorvoeren.
• Eventueel complexere aanpassing Database m.b.v. een geleide conversie.
• Analyse van de gevolgen van de oplossing voor het systeem als geheel en voor de gebruikersorganisatie.

Probleemclassificatie binnen het Problem-management proces

Het resultaat van de probleemanalyse door de applicatiebeheerder is een classificatie van het probleem. Het uitvoeren van de probleemanalyse gebeurt vaak intuïtief met als gevolg dat de impact van een oplossing vaak groter is dan verwacht.

Om te komen tot een meer doordachte aanpak van problemen zouden we langer stil moeten staan bij de probleemanalyse. Voorwaarde hiervoor is dat iedereen alle problemen bij de applicatiebe­heerder meldt. De applicatiebeheerder kan de problemen dan eenduidig analyseren en volgen.

Aan de hand van de probleemanalyse is een probleem te 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 moeten aanpakken. 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 de classificatie niet juist is uitgevoerd; hiermee moeten we dus met de nodige flexibiliteit omgaan.

Klasse A. Groot probleem (Release)

Als grote problemen te classificeren zijn problemen waarbij het systeem veel van de verwachtte functionaliteit niet in zich heeft. Met andere woorden de gebruikersorganisatie wordt onvoldoende door informatiesysteem ondersteund. Bij deze problemen is het uitgangspunt vaak dat de werking van het informa­tiesys­teem wel voldeed aan de vroegere eisen en wensen maar niet aan de huidige en toekomstige. Kenmerkend voor dit soort problemen 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 informatiesysteem. Ze worden dan uit de Problem-management sfeer gehaald.

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 aanwijsbaar of de problemen hebben meerdere symptomen. Onder deze klasse vallen tevens programmamodules die individueel meerdere problemen veroorzaken. Ook de (eenduidig) onjuistheid van grote groepen van data records valt onder deze klasse.

Deze problemen ontdekken we in veel gevallen ontdekt door beoordeling van de management-informatie of afwijkingen t.o.v. de kengetallen. Er blijkt bijvoorbeeld dat het systeem bepaalde groepen records niet of verkeerd verwerkt. Bij een klasse B probleem volgt meestal automatisch de definitie van een nieuwe release van het informatiesysteem, al dan niet binnen het Problem-management proces.

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 ligt geheel of gedeeltelijk stil of de nacht- of dagbatch draait geheel of gedeeltelijk niet meer. 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 betalen van facturen.

Een ander belangrijk punt zijn de externe gebruikers (klanten) van het informatiesysteem. Zij mogen zo min mogelijk merken van het falen van het systeem. Het aanmaken 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. De systeem- of applicatiebeheerder is meestal degene die dit soort problemen ontdekt.

Klasse D. Geïsoleerd probleem

Geïsoleerd problemen kunnen we aanmerken als problemen in de verwerking van individuele mutaties waarbij we moeten constateren dat deze mutaties niet verder te werken zijn. 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 enkelvoudige 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, bijvoorbeeld het verhogen van het gebruikersgemak of de efficiëntie. Te denken valt aan het wijzigen van lijstindelingen of het integreren van schermen. Klasse E problemen verstoren de voortgang van de werkzaamheden op de afdeling doorgaans niet maar zouden bij oplossing de voortgang wel kunnen versnellen. Het clusteren met andere problemen tot een release kan eenvoudig plaatsvinden. Bij beoordeling van dergelijke problemen spelen de bedrijfsprocessen vaak ook een rol. Het zijn met name de eindgebruikers die dergelijke problemen bij de applicatiebeheerder melden.

Klasse F. Performance probleem

Performance problemen uiten zich op twee manieren:

• Ten eerste als responsprobleem 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 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 performanceprobleem zijn wijzigingen op het functionele ontwerp of de administratieve organisatie niet nodig.

Performance problemen worden in de Problem-management procedure door de eindgebruikers bij de applicatiebeheerder of de helpdesk gemeld. Afhankelijk 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 onrechte 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 problemen 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 layout wijziging waardoor dit adaptieve probleem vaak goed samen met andere problemen kan worden opgelost. Dit soort problemen verlaten het Problem-management proces al snel.

Klasse I. Systeemtechnisch probleem.

Systeemtechnische problemen zullen noch door het management noch door de gebruikersorganisatie worden onderkend. Zij worden veelal door de systeembeheerders aangemeld en worden vaak, terwijl toekomstige problemen worden voorkomen als slechts hinderlijk ervaren. Meestal overstijgen klasse I problemen een informatiesysteem­ waarmee we de individuele informatiesystemen aan het probleem ondergeschikt maken. 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 andere problemen. Dit kan alleen door onderling overleg tussen systeembeheer en gebruikersorganisatie.

Problem-management en de aard van de problemen

Ongeacht de klasse waarin een probleem volgens het Problem-management process 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-en maken het volgende onderscheid :

1. Preventief onderhoud; onderhoud ter voorbereiding van komende omgevingswij­zigin­gen. Klasse : I.
2. Perfectief onderhoud; onderhoud ter verbetering van het informatiesysteem. Klasse : E en F.
3. 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.
4. 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 gebruiken we om een gefundeerd onderhoudscontract op te stellen.

Problem-management en de ernst van de problemen

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

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

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

Het meest spoedeisende karakter (prio 1) is met name van toepassing voor het correctieve onderhoud en probleemklasse C. Daarbij moeten we aanmerken dat de ernst en de prioriteit toenemen naarmate een kritisch punt in het primaire bedrijfsproces nadert.

De oplossing voor problem-management problemen

Om de ernst van een probleem goed te kunnen bepalen is aan te raden om elke programmamodule (bedrijfsproces) binnen een informatiesysteem van een ernst-code te voorzien. Samen met de klasse (wegingsfactor) waarin het probleem valt wordt dan vastgesteld met welke prioriteit het probleem daadwerkelijk wordt aangeleverd aan de ontwikkelaars.

Bij omvangrijke informatiesystemen kan een dergelijke inventarisatie de nodige inspanning 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.