Sharing IT Best Practices with youSharing IT Best Practices with you
Maatwerk applicaties
Op grote maatwerk applicaties waarbij de informatiebehoeften vaak en onregelmatig wijzigen zal veel onderhoud plaatsvinden. Onderhoud op functies die soms al weer veranderen voordat de vorige wijziging in productie is genomen. Deze vorm van onderhoud doet zich met name voor als de applicatie regelgeving ondersteund die door de politiek wordt bepaald. Uitvoerenden hebben vrijwel geen invloed op hoe de regelgeving met alle uitzonderingen eruit komt te zien en op welk moment deze regelgeving van kracht wordt. De ervaring leert bovendien dat het geen zin heeft om tijd te rekken of de regelgeving onvolledig door te voeren. Wat wel werkt is de nieuwe regelgeving tijdelijk op een geïsoleerd systeem uit te voeren zodat we tijd winnen om de nieuwe informatiebehoefte goed in de applicatie in te bouwen.
De beheersing van de constante stroom van zowel correctieve als adaptieve wijzigingen noemen we change-management, een van de belangrijkste ITIL processen. Om de beheersbaarheid zo groot mogelijk te maken is het verstandig om het onderhoud te bundelen in kleine overzichtelijke releases van de maatwerk applicatie.
Bij omvangrijke maatwerk applicaties zal er zeker na de in productie name al een grote stroom van problemen opgang komen. Om niet te verzanden in een brei van problemen, foutmeldingen, storingen en verschillen in versies van modules dienen we te zoeken naar een structuur waarin we de toevloed van problemen kunnen stroomlijnen. Het beheersen van zo’n omgeving en de bedrijfsprocessen die daar bij horen noemen we ook wel change-management.
Problemen met de applicaties die zich bij functioneel beheerders aandienen kunnen van velerlei aard en diepgang zijn. Tevens worden problemen door verschillende personen en instanties aangemeld. Om te komen tot een gefundeerde aanpak van problemen dienen we deze eerst te classificeren naar aard en herkomst. Hiertoe dient eerst een probleemanalyse plaats te vinden. De probleemanalyse door de functioneel functioneel beheerder dient de volgende gegevens op te leveren:
Het resultaat van de probleemanalyse door de functioneel beheerder dient een classificatie van het probleem te zijn. De verschillende probleemklasses wordt in Het classificeren van problemen beschreven. Problem Management is eveneens een belangrijk ITIL process.
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 overdachte aanpak van problemen zouden we echter langer stil moeten staan bij de probleemanalyse. Voorwaarde hiervoor is dat men alle problemen bij de functioneel beheerder meldt. De functioneel beheerder kan de problemen dan eenduidig analyseren en volgen.
In de meeste gevallen is de aanpak van problemen voornamelijk gebaseerd op de aard en de ernst van een probleem. Adaptieve problemen pakken we meestal wel grondig aan, ernstige problemen leveren we vanwege de spoedeisendheid vaak direct bij aan het onderhoudsteam. Deze aanpak leidt echter niet altijd tot het gewenste resultaat. Spoedeisende problemen kunnen bijvoorbeeld omvangrijker zijn dan ze in aanvang lijken. Het komt ook regelmatig voor dat ernstige problemen na verdere analyse worden ingetrokken. Oorzaken hiervan zijn: Het dubbel aanmelden van problemen, het alsnog d.m.v. SQL updaten van records en een verkeerde beoordeling.
De wijze waarop we een probleem aanpakken moeten we echter uitsluitend afhankelijk maken van de klasse waarin een probleem valt. Bij een groot probleem (klasse A) zal de aanpak bovendien grondig en uitgebreid moeten zijn. Er zou voor gekozen kunnen worden om alle problemen volgens klasse A aan te pakken zodat een eenduidige werkwijze ontstaat. In de praktijk is dit echter een onnodige verspilling van tijd en geld zijn. Het is daarom verstandig om per probleemklasse een aanpak vast te stellen waarbij ook de kwaliteit blijft gewaarborgd. Het is van belang om ook onder tijdsdruk niet van deze aanpak af te wijken. Ernstige problemen uit klasse A of B zullen we echter ongeacht hun prioriteit wel degelijk grondig moeten aanpakken.
Per probleemklasse geven we een algemene fasering weer. De stappen lichten we daarna afzonderlijk toe.
fase
a. Informatieanalyse.
b. Ontwerp administratieve organisatie.
c. Functioneel- en Technisch-ontwerp.
d. Aanpassen van de procedures.
e. Realisatie programmatuur en database.
f. Acceptatietesten.
g. Invoering.
fase
b. Ontwerp administratieve organisatie.
c. Functioneel- en Technisch-ontwerp.
d. Aanpassen van de procedures.
e. Realisatie programmatuur en database.
f. Acceptatietesten.
g. Invoering.
fase
c. Functioneel- en Technisch-ontwerp.
e. Realisatie programmatuur.
f. Acceptatietesten.
g. Invoering.
fase
e. Realisatie programmatuur.
f. Acceptatietesten.
g. Invoering.
fase
c. Functioneel- en Technisch-ontwerp.
d. Aanpassen van de procedures.
e. Realisatie programmatuur.
f. Acceptatietesten.
g. Invoering.
fase
c. Technisch-ontwerp.
e. Realisatie programmatuur.
f. Acceptatietesten.
g. Invoering.
fase
c. Technisch-ontwerp.
e. Realisatie programmatuur.
f. Acceptatietesten.
g. Invoering.
fase
c. Functioneel- en Technisch-ontwerp.
e. Realisatie programmatuur.
f. Acceptatietesten.
g. Invoering.
fase
c. Technisch-ontwerp.
e. Realisatie programmatuur.
f. Acceptatietesten.
g. Invoering.
Ten aanzien van onderhoud kunnen we per fase een aantal standaard producten en activiteiten definiëren. Hieronder gaan we daarop nader in.
Het plan van aanpak bevat de volgende producten :
Deze fase passen we uitsluitend toe bij de grotere problemen waarbij we een projectteam met een projectmanager formeren dat als geheel voor de oplossing verantwoordelijk is. Denk aan materiedeskundige gebruikers, functioneel beheerders, beleidsmedewerkers, testers (gebruikers), accountmanagers en ook leden van het onderhoudsteam. Door deze aanpak creëren we namelijk een teamgeest, met een gezamenlijke verantwoordelijkheid. Dat wil zeggen, de verantwoordelijkheid wordt niet telkens van de ene persoon op de andere overgedragen.
De functioneel beheerder vervult hierin een centrale rol. Hij kan in die gevallen als projectmanager of projectleider worden aangewezen. De projectleider is verantwoordelijk voor het maken van een plan van aanpak, de bewaking van de voortgang van het project en de rapportage aan de opdrachtgever. De projectleider blijft hier bovendien voor verantwoordelijk totdat de opdracht is afgerond. In veel gevallen zal de functioneel beheerder als projectleider optreden.
De Informatie-analyse hoort ook thuis bij de grotere problemen en zal door een informatie-analist worden uitgevoerd. De opgeleverde producten zijn een activiteitenmodel en een gegevensmodel. Verder besteden we ook aandacht aan eventuele aanpassingen in de systeemstructuur, de beveiliging en de gewenste kwaliteit van de op te leveren producten.
De functioneel beheerder zal producten uit de IA mede reviewen en daarbij met name letten op de inpasbaarheid in maatwerk applicaties als geheel en de interfaces met de buitenwereld. Tevens beoordeelt hij of er een werkbare situatie zal ontstaan voor de eindgebruikers.
Deze fase voeren we met name uit bij grote wijzigingen op informatiesystemen. Aangezien het om onderhoud gaat dient er een nauwe samenwerking te zijn met de procedure-beheerder in verband met de principes zoals die bij de bedrijfsprocessen gelden. De functioneel beheerder dient namelijk vast te stellen of er een werkbare situatie ontstaat waarbij een vertaling naar de maatwerk applicaties mogelijk is en de risico’s voldoende zijn afgedekt.
Tijdens deze fase stellen we vast op welke werkplek men welke processen uitvoert. In de onderhoudsfase kunnen hierin veranderingen optreden als gevolg van veranderde inzichten. Een en ander kan gevolgen hebben voor de organisatie, de werkprocessen, de procedures en de werkinstructies. Afhankelijk van de organisatie voert de functioneel beheerder ook een deel van de werkzaamheden uit.
Het ontwerp wordt meestal door het onderhoudsteam onderhouden. Wijziging van het ontwerp kan een onderdeel zijn van grotere onderhoudsklussen. Als het ontwerp wijzigt moet de functioneelbeheerder vaststellen of het aansluit op de Informatie-analyse en de bedrijfsprocessen. Tevens dient er een afstemming met de beleving van de gebruikers plaats te vinden. Als gevolg van onderhoud kunnen wijzigingen optreden in het database-ontwerp. Ook reeds genomen ontwerpbeslissingen, interfaces en de lay-out van schermen en lijsten kunnen veranderen.
De realisatie komt in iedere probleemklasse voor. Het is echter niet zo dat iedere realisatie door het onderhoudsteam wordt uitgevoerd. Ook de invoering van nieuwe systeemsoftware of een SQL-update kunnen we tot een realisatie rekenen. Tijdens de realisatie brengt het onderhoudsteam de in het ontwerp bedachte wijzigingen aan. Zij geven tevens een planning af voor de uit te voeren werkzaamheden.
Net als de realisatie komt de acceptatietest in alle probleemklassen voor. De diepgang van de test kan per klasse echter zeer verschillend zijn. Bij kleine aanpassingen kan een test door de functioneel beheerder al voldoende zijn om vast te stellen dat de wijziging is doorgevoerd. Bij grotere problemen (klasse A en B) dienen we echter de gebruikers bij de test te betrekken. In dergelijke gevallen moeten we bovendien een testset maken en een testverslag inclusief de archivering van de resultaten. Tevens dienen we vast te stellen of de nieuwe functies aansluiten op de bedrijfsprocessen.
De invoering van de oplossing van een probleem kan soms al eenvoudig plaatsvinden door het overzetten van de aangepaste programmamodule met daarbij een telefoontje aan de gebruiker. Dit geldt met name voor de problemen in de klassen D, F, G en H. In voorkomende gevallen kan dit ook voor een probleem in de klasse C gelden. Het andere uiterste is de instelling van een Invoeringsteam, hetgeen echter afhankelijk is van de omvang van het probleem. De volgende extra activiteiten kunnen tijdens de invoering een rol spelen :
Discussieer mee op LinkedIn.
Mogelijk is dit een vertaling van Google Translate en kan fouten bevatten. Klik hier om mee te helpen met het verbeteren van vertalingen.