Releases en change-management bij maatwerkapplicaties

Op grote maatwerk informatiesystemen 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 onder­houd doet zich met name voor als het informatiesysteem 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 regelge­ving van kracht wordt. De ervaring leert 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 (PC)systeem uit te voeren zodat tijd ontstaat om de nieuwe informatiebehoefte goed in het informatiesysteem in te bouwen.

De beheersing over de constante stroom van zowel correctieve als adaptieve wijzigingen wordt change-management genoemd. Om de beheersbaarheid zo groot mogelijk te maken is het verstandig om het onderhoud te bundelen in kleine overzichtelijke releases van het informatiesysteem.

Opzet Change-management organisatie.
Bij omvangrijke maatwerksystemen zal er zeker na de in productie name een grote stroom van problemen opgang komen. Om niet te verzanden in een brei van problemen, foutmeldingen, storingen en verschillen in versies van modules dient er te worden gezocht naar een structuur waarin de toevloed van problemen kan worden gestroom­lijnd. Het beheersen van zo’n omgeving wordt ook wel change-management genoemd.

Problemen die zich t.a.v. de applicaties bij applicatiebeheerders aandienen kunnen van velerlei aard en diepgang zijn. Tevens worden problemen door verschillende personen en instanties aange­meld. Om te komen tot een gefundeerde aanpak van problemen dienen deze eerst te worden geclassificeerd naar aard en herkomst. Hiertoe dient eerst een probleemanalyse plaats te vinden. De probleemanalyse door de applicatiebeheerder dient de volgende gegevens op te leveren :

• Aantal betrokken programmamodules.
• Controle status betrokken programmamodules
           Voor een juist versiebeheer dient rekening te worden gehouden met het overige onderhanden onderhoud.
• Aantal betrokken gegevensverzamelingen.
• Aantal betrokken records.
• 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.
• Eventueel afstemming met onderhoudsteam.
• Aangeven oplossingsrichting.
• Aangeven of aanpassing van het ontwerp nodig is.
• Aangeven of aanpassing van de programmamodules nodig is.
• Aangeven of aanpassing van ede administratieve organisatie nodig is.
• Eventueel eenvoudige aanpassing Database d.m.v. SQL-update doorvoeren.
• Eventueel complexere aanpassing Database d.m.v. geleide conversie doorvoeren.
• Analyse van de gevolgen van de oplossing voor het systeem als geheel en voor de gebruikersorganisatie.

Het resultaat van de probleemanalyse door de applicatiebeheerder dient een classificatie van het probleem te zijn. De verschillende probleemklasses wordt in Het classificeren van problemen beschreven.

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 zou langer stilgestaan moeten worden bij de probleemanalyse. Voorwaarde hiervoor is dat alle problemen bij de applicatiebe­heerder worden gemeld. De applicatiebeheerder kan de problemen dan eenduidig analyseren en volgen.

Aanpak van een probleem.
In de meeste gevallen is de aanpak van problemen voornamelijk gebaseerd op de aard en de ernst van een probleem. Adaptieve problemen worden meestal wel grondig aange­pakt, ernstige problemen worden vanwege de spoedeisendheid vaak direct bij het onderhouds­team aangele­verd. Deze aanpak leidt 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 een probleem wordt aangepakt moet echter uitsluitend afhankelijk worden gemaakt van de klasse waarin een probleem valt. Bij een groot probleem (klasse A) zal de aanpak 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 ongeacht hun prioriteit wel degelijk grondig aangepakt moeten worden.

Per probleemklasse wordt een algemene fasering weergegeven de stappen worden daarna afzonderlijk toegelicht.

Aanpak klasse A probleem.
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.

Aanpak klasse B probleem.
fase
b.  Ontwerp administratieve organisatie.
c.   Functioneel- en Technisch-ontwerp.
d.  Aanpassen van de procedures.
e.   Realisatie programmatuur en database.
f.   Acceptatietesten.
g.  Invoering.

Aanpak klasse C probleem.
fase
c.   Functioneel- en Technisch-ontwerp.
e.   Realisatie programmatuur.
f.   Acceptatietesten.
g.  Invoering.

Aanpak klasse D probleem.
fase
e.   Realisatie programmatuur.
f.   Acceptatietesten.
g.  Invoering.

Aanpak klasse E probleem.
fase
c.   Functioneel- en Technisch-ontwerp.
d.  Aanpassen van de procedures.
e.   Realisatie programmatuur.
f.   Acceptatietesten.
g.  Invoering.

Aanpak klasse F probleem.
fase
c.   Technisch-ontwerp.
e.   Realisatie programmatuur.
f.   Acceptatietesten.
g.  Invoering.

Aanpak klasse G probleem.
fase
c.   Technisch-ontwerp.
e.   Realisatie programmatuur.
f.   Acceptatietesten.
g.  Invoering.

Aanpak klasse H probleem.
fase
c.   Functioneel- en Technisch-ontwerp.
e.   Realisatie programmatuur.
f.   Acceptatietesten.
g.  Invoering.

Aanpak klasse I probleem.
fase
c.   Technisch-ontwerp.
e.   Realisatie programmatuur.
f.   Acceptatietesten.
g.  Invoering.

Aanpak per fase.
Ten aanzien van onderhoud kan per fase een aantal standaard producten en activiteiten worden gedefinieerd. Hieronder wordt daarop nader ingegaan.

Plan van aanpak.
Het plan van aanpak bevat de volgende producten :
•    Opdracht waarbij een formele opdrachtgever bekend dient te zijn.
•    Een overzicht van de personele inzet.
•    Een overzicht van de uit te voeren activiteiten (kan door verwijzing naar klasse).
•    Een geschat tijdsplan van activiteiten met bezetting van mensen.
•    Een overzicht van de op te leveren producten (kan door verwijzing naar klasse).
Deze fase wordt uitsluitend bij de grotere problemen toegepast waarbij een team wordt geformeerd dat als geheel voor de oplossing verantwoordelijk is. Te denken is aan materiedeskundige gebruikers, applicatiebeheerders, beleidsmedewerkers, testers (gebruikers) en leden van het onderhoudsteam. Door deze aanpak wordt een project­teamgeest gecreëerd, met een gezamenlijke verantwoordelijkheid. D.w.z. de verant­woor­delijkheid wordt niet telkens van de ene persoon op de andere overgedragen.

De applica­tiebeheerder vervult hierin een centrale rol. Er zal in die gevallen een project­leider worden aangewe­zen. De projectleider is verantwoordelijk voor het maken van een plan van aanpak, de bewaking van de voortgang van het project en de rapport­age aan de opdrachtge­ver. De projectleider blijft hiervoor verantwoordelijk totdat de opdracht is afgerond. In voorkomende gevallen kan de applicatiebeheerder als projectleider optre­den.

a.   Informatieanalyse.
De Informatie-analyse hoort ook thuis bij de grotere problemen en zal door een Informa­tie­analist worden uitgevoerd. De opgeleverde producten zijn een activiteiten­model en een gegevensmodel. Verder wordt aandacht besteed aan eventuele aanpassingen in de systeemstructuur, de beveiliging en de gewenste kwaliteit van de op te leveren produc­ten.
De functioneelbeheerder zal producten uit de IA mede reviewen en daarbij met name letten op de inpasbaarheid in het informatiesysteem als geheel en de interfa­ces met de buitenwereld. Tevens beoordeelt hij of er een werkbare situatie zal ontstaan voor de eindgebruikers.

b.  Ontwerp administratieve organisatie.
Deze fase wordt met name uitgevoerd bij grote wijzigingen op informatiesystemen. Aange­zien het om onderhoud gaat dient er een nauwe samenwerking te zijn met de procedure-beheer­der in verband met de principes zoals die bij de administratieve organisatie gelden. De Applicatiebeheerder dient vast te stellen of er een werkbare situatie ontstaat waarbij een vertaling naar het informatie­sys­teem mogelijk is en de risico’s voldoende zijn afgedekt.

c.   Aanpassen van de procedures.
Tijdens deze fase wordt vastgesteld op welke werkplek welke processen worden uitgevoerd. In de onderhoudsfase kunnen hierin veranderingen optreden a.g.v. verander­de inzichten. E.e.a. kan gevolgen hebben voor de organisatie, de processen, de procedu­res en de werkinstructies. Afhankelijk van de organisatie wordt een deel van de werkzaam­heden door de applicatiebeheerder uitgevoerd.

 d.  Functioneel- en Technisch-ontwerp.
Het ontwerp wordt meestal door het onderhoudsteam onderhouden. Wijziging van het ontwerp kan een onderdeel zijn van grotere onderhoudsklussen. De applicatiebe­heer­der moet vaststellen of het ontwerp aansluit op de Informatie-analyse en de Administratieve Organisatie. Tevens dient er een afstem­ming met de beleving van de gebruikers plaats te vinden. A.g.v. onderhoud kunnen wijzigingen optreden in het database-ontwerp, reeds genomen ontwerpbeslissingen, interfaces en de lay-out van schermen en lijsten.

e.   Realisatie programmatuur en database.
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 kan tot een realisatie worden gerekend. Tijdens de realisatie worden de in het ontwerp bedachte wijzigingen aangebracht. Het onderhouds­team geeft een planning af voor de uit te voeren werkzaamheden.

 f.       Acceptatietesten.
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 aanpas­singen kan een test door de applicatiebeheerder voldoende zijn om vast te stellen dat de wijziging is doorge­voerd. Bij grotere problemen (klasse A en B) dienen de gebruikers bij de test te worden betrokken. In dergelijke gevallen dient een testset te worden gemaakt en er dient een testverslag te worden gemaakt inclusief de archivering van de resultaten. Tevens dient te worden vastgesteld of de nieuwe functies aansluiten op de administra­tieve organisatie.

g.  Invoering.
De invoering van de oplossing van een probleem kan soms eenvoudig plaatsvinden door het overzetten van de aangepaste programmamodule met daarbij een telefoon­tje aan de gebruiker. Dit geldt met name voor de problemen in de klassen D, F, G en H. In voorko­mende gevallen kan dit ook voor een probleem in de klasse C gelden. Het andere uiterste is de instelling van een Invoeringsteam, hetgeen afhankelijk is van de omvang van het probleem. De volgende extra activiteiten kunnen tijdens de invoering een rol spelen :
• Overgang buiten de kantooruren, bijvoorbeeld in verband met een database-wijziging of conversie.
• Het veilig stellen van de uitgangssituatie (backup).
• Instructie en training van de eindgebruikers.
• Pre-productierun. Bij een enkelvoudige uitvoering van een informatiesysteem en het onmiddellijk van kracht worden van de aanpassingen is het vrijwel onmoge­lijk om bij een systeem dat reeds in de onderhoudsfase verkeerd nog principes als schaduwdraaien en pilotgroepen toe te passen. De bruikbaarheid van de aange­paste programmamodules dient reeds in de acceptatietest te zijn aange­toond.

Boeken over dit onderwerp

ITIL A Pocket Guide – 2011 Edition

Auteur: Jan van Bon
Het primaire doel van deze pocket guide is een snelle referentie te bieden van ITIL. Zodoende is dit een zeer waardevolle hulp voor alle managers die actief zijn binnen Service Management.
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 change management vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Release evaluatie 61 vragen.
Release definitie 17 vragen.
Storingsafhandeling en registratie 31 vragen.
Sidebar