Kosten van applicatiebeheer onder de loep

Samenvatting van een artikel van Wil van der Drift en Mark Smalley, eerder op ASL BiSL Foundation

De laatste jaren kijken veel organisaties kritischer dan voorheen naar hun kosten, ook voor de ICT-ondersteuning. Uiteraard moet ook naar de opbrengsten worden gekeken, maar de actuele trend is om de kosten onder de loep te nemen. Dit artikel verkent het gebied applicatiebeheer vanuit de kant van kosten die met de uitvoering ervan samenhangen en mogelijkheden om deze te verminderen.
In relatie tot het framework voor applicatiebeheer, de Application Services Library, beogen de auteurs een bijdrage te leveren voor de uitvoerders van het proces Kostenmanagement.

In hoofdlijnen wordt gesteld dat de kosten door diverse factoren worden bepaald en beïnvloed:
1 De marktbenadering waarvoor een organisatie heeft gekozen: een innovatieve organisatie zal doorgaans meer aan ICT uitgeven dan een efficiency-gerichte organisatie.
2 De doelmatigheid waarmee applicatiebeheerdiensten worden geleverd en meer in het bijzonder de mate waarin stabiliteit in de personele bezetting kan worden bereikt.
3 De onderlinge afstemming met de ‘partners’ van applicatiebeheer, dat zijn: applicatiearchitectuur en -ontwikkeling, technisch beheer, functioneel beheer en de gebruikers.

De voornaamste constateringen, conclusies en aanbevelingen zijn:
• Er zijn weinig feiten – maar wel opvattingen – over kostenverschillen die samenhangen met de gekozen marktbenadering van een organisatie. Het ICT-beleid wordt sterk beïnvloed door de marktbenadering. De kostenverschillen hebben voornamelijk betrekking op het volume en kwaliteit van de benodigde ICTdiensten en minder op de doelmatigheid waarmee deze worden Kosten geleverd. Uitgaand van vier soorten marktbenaderingen – gericht op efficiency, effectiviteit, innovatie of flexibiliteit – wordt gesteld dat organisaties met een op innovatie of effectiviteit gerichte marktbenadering bereid zijn hogere kosten te maken dan organisaties die flexibiliteit- of efficiency-gedreven zijn.
• Aanzienlijke kostenbesparingen zijn te realiseren wanneer de applicatiebeheerorganisatie kennisacquisitie en -behoud goed heeft georganiseerd. 15 tot zelfs 50% van applicatiebeheerkosten
wordt hieraan besteed. Kennisoverdracht als gevolg van vervanging van personeel is verreweg de grootste kostenpost. Aanbevolen wordt applicatiebeheer in daarin gespecialiseerde organisatorische eenheden te beleggen en een daarop afgestemd personeelsbeleid te hanteren, waarmee medewerkerstevredenheid en daarmee ook behoud van personeel wordt verhoogd.
• De kosten voor applicatiebeheer worden sterk beïnvloed door de factoren die buiten de applicatiebeheerorganisatie liggen. Het is daarom van belang dat het beleid van alle aan applicatiebeheer gerelateerde ICT-functies in gelijke mate is afgestemd op de gekozen marktbenadering van de organisatie. Anders kunnen kostenbesparingen bij applicatiebeheer tenietgedaan worden door bijvoorbeeld een functioneel beheer dat onvoldoende kritisch naar wijzigingsverzoeken vanuit de gebruikersorganisatie kijkt en dus onnodig veel wijzigingen door applicatiebeheer laat uitvoeren. Sommige van de kostenbeïnvloedende factoren staan relatief vast, maar met name in de aansturing van applicatieontwikkeling en in de inrichting van functioneel beheer zijn besparingen in de kosten van applicatiebeheer te realiseren.

POSITIONERING IN RELATIE TOT ASL

Voordat inhoudelijk ingegaan wordt op bovenstaande punten, wordt het onderwerp in relatie gebracht tot ASL, de Applications Services Library [Pols]. ASL biedt een framework voor application management dat gestoeld is op de best practices van professionals met jarenlange ervaring. Waar ITIL een algemeen aanvaarde standaard is geworden om technisch beheer in te richten, biedt de ASL een framework voor het inrichten van applicatiebeheer. Het budgetteren, bewaken en evalueren van kosten wordt beschreven door een van de sturende processen van ASL, namelijk Kostenmanagement. De soorten kosten die in dit artikel worden behandeld, hebben voornamelijk betrekking op de operationele  processen in de clusters Beheer, Onderhoud/vernieuwing en de Verbinding daartussen.
Aangegeven wordt dat de wijze waarop Applications
Management en Planning en Control worden ingevuld, mede bepalend is voor de kosten van applicatiebeheer. Relevant bij Applications Cycle Management is een goede vertaling van het bedrijfsbeleid in de gevolgen voor de applicaties. Bij Organization Cycle Management heeft dit beleid invloed op de diensten die rondom de applicaties worden aangeboden, en tevens is het van belang dat de kostenbesparende aspecten van kennismanagement worden onderkend en geïmplementeerd. Binnen Planning en Control worden deze punten vertaald in concrete activiteiten.

FACTOR 1: DE GEKOZEN MARKTBENADERING

Inleiding
Organisaties kunnen worden getypeerd door de gekozen marktbenadering: zijn zij voornamelijk innovatief van aard (steeds bezig met introductie van nieuw producten en/of de entree in nieuwe markten), gericht op effectiviteit (met de nadruk op klanttevredenheid) of efficiency-gedreven (kostenbesparing)? Naar onze overtuiging is het het beste zich te richten op één van deze aspecten; het is niet goed mogelijk om tegelijkertijd én innovatief én effectief én efficiënt te zijn. Dit is de context waarin de levenscyclus van applicaties wordt beschouwd. De applicaties zijn er immers om de bedrijfsvoering te ondersteunen met een informatievoorziening die in de behoeften van de gebruikers voorziet. Jaar in en jaar uit, steeds is actuele functionaliteit nodig. De dynamiek van de bedrijfsprocessen is bepalend voor de dynamiek – en daarmee de kosten – van de applicatielevenscyclus.
Een vierde mogelijkheid is zich te richten op flexibiliteit. Volgens ons hoort flexibiliteit niet echt bij dit trio, omdat het meer een tactiek is in onzekere tijden met een grote (externe) dynamiek dan een bewust gekozen strategie. In dit hoofdstuk worden deze marktbenaderingen en de relatie met Kostenmanagement verder uitgewerkt (het overgrote deel hiervan is eerder gepubliceerd [Drift]).
Bedrijfskundige benadering gewenst Het bouwen van een nieuwe applicatie is slechts één fase binnen de levenscyclus en zeker niet de meest omvangrijke. Een groot deel van het werk van ICT-afdelingen richt
zich op het aanpassen van bestaande applicaties als gevolg van veranderingen in de eisen of de technische omgeving. De dynamiek van het bedrijfsproces is bepalend voor de dynamiek van de applicatielevenscyclus. Goed management van het beheerproces kan daarom de levensduur verlengen. Ook het leggen van de juiste accenten is van belang. De context waarin de levenscyclus van applicaties
wordt beschouwd, heeft een bedrijfskundig karakter.

Levenscyclus
Het eerste deel van de levenscyclus, de innovatiefase, is die van de introductie van een nieuw product of de entree in een nieuwe markt. Daarna breekt de groeifase aan waarin het klantenbestand zich uitbreidt en de nadruk ligt op klanttevredenheid. Na verloop van tijd – de feitelijke duur hiervan wordt inmiddels eerder in maanden dan in jaren gemeten – worden de winstmarges verbeterd door het verbeteren van de productie en leveringsprocessen: de fase van de kostenbeheersing door efficiency-verbetering.

Concentreren
In de eerste fase wordt een beroep gedaan om het innovatief vermogen van de organisatie. De interne bedrijfsvoering wordt afgestemd op het bedenken van nieuwe producten en de introductie op de markt.  Deze innovatie wordt gedreven door de markt, de technologie of een nieuwe visie. In de tweede fase verschuift de focus naar effectiviteit. Dit betekent dat het bedrijfsbeleid vooral gericht is op het leveren van de optimale dienst en service aan de klanten. In termen van de Consumentenbond: de beste koop.
De derde fase moet het hebben van een efficiënte benadering. Het bedrijf wil, mede als gevolg van de inmiddels aanwezige concurrentie, de markt het optimum bieden waar het gaat om kosten/opbrengsten. Hier geldt de 80/20-regel; dat wil zeggen dat aanvaard wordt dat het beter zou kunnen. In consumentenbondtermen: de voordelige keus.
Naar onze overtuiging is het beter zich te richten op een van deze aspecten dan te proberen tegelijkertijd én innovatief én effectief en efficiënt te zijn. Het is zeker niet zo dat een van deze drie aspecten superieur is aan de andere twee. Zo zijn sommige supermarkten succesvol met het leveren van producten van een hoge kwaliteit, terwijl anderen net zo succesvol zijn met een ‘voordelige keus’-formule.

Flexibiliteit
Een vierde mogelijkheid is zich te richten op flexibiliteit. Volgens ons is flexibiliteit minder doeltreffend, omdat het meer een tactiek is in onzekere tijden met een grote (externe) dynamiek dan een bewust gekozen strategie.
Bij het maken van deze keuze is het van wezenlijk belang te onderkennen dat met de keuze voor één aspect automatisch voordelen van andere aspecten worden uitgesloten of in ieder geval sterk  verminderd.

Bedrijfsbeleid en ICT-beleid

Het algemeen beleid van de onderneming drukt een stempel op het beleid van specifieke aspecten, zoals de ICT. Hoe dominanter de keuze op algemeen-beleidsniveau voor innovatie, effectiviteit, efficiëntie of flexibiliteit, hoe makkelijker het wordt om een slagvaardig ICT-beleid uit te stippelen.
Wordt er bijvoorbeeld voor effectiviteit gekozen, dan ligt het voor de hand dat alleen een op effectiviteit gerichte informatievoorziening daaraan de beste bijdrage zal leveren. Dit betekent dat er primair voor de beste oplossing gekozen zal worden. Dit zal zich manifesteren door een inrichting van functioneel applicatiebeheer – altijd een verantwoordelijkheid van de gebruikers – waarmee optimale aandacht aan de gebruikers wordt gegeven:
hun wensen voor verbetering van de ICTondersteuning staan centraal. Het technisch applicatiebeheer zal dit versterken door zich steeds op de beste ICT-oplossing te oriënteren.
Dat dit meer kosten met zich meebrengt wordt aanvaard: men ging immers niet voor de goedkoopste oplossing, maar voor de beste. De kwaliteit van de bedrijfsvoering en daarmee de geleverde producten en diensten wordt verhoogd. De hogere kwaliteit vertaalt zich in het te realiseren prijsniveau; dit rechtvaardigt hogere (ICT-)kosten. Een variant gebaseerd op efficiëntie zou uitmonden in een situatie waarin het functioneel applicatiebeheer aan de gebruikers steeds ‘nee’ verkoopt, tenzij er een kostenvoordeel te behalen valt. En van de technisch applicatiebeheerders wordt verwacht dat zij eventueel concessies in de functionaliteit van gevraagde oplossingen voorstellen, indien dit aanzienlijk in de kosten scheelt. Varianten voor innovatie en flexibiliteit zijn er natuurlijk ook.
Welke keuze er ook gemaakt wordt, het is essentieel dat de relevante ICT-disciplines (in bovenstaande voorbeelden gaat het om de functioneel applicatiebeheerder en de technisch applicatiebeheerder) zich richten op het bedrijfsbeleid en dat zij dit in de uitvoering van hun activiteiten doorvoeren.

Application Lifecycle Management

De focus van het Application Lifecycle Management (ALM) is niet beperkt tot de levenscyclus van slechts één applicatie. Een recent gebouwde applicatie is meestal de opvolger van een eerdere  applicatie die de bedrijfsprocessen voorheen ondersteunde. En er zal ook een tijd komen dat een nu gloednieuwe applicatie als verouderd gezien zal worden. Application Lifecycle Management richt zich op de opeenvolgende generaties van applicaties die een bedrijfsproces ondersteunen. Wanneer de ondersteuning door een applicatie op het gewenste niveau is en de fase van verbetering in efficiency is bereikt, zal periodiek een belangrijk besluit moeten worden genomen over de toekomst van de applicatie. Het besluit zou kunnen zijn om de huidige ICT-architectuur te continueren en slechts kleine wijzigingen aan te brengen. Wanneer de basisfunctionaliteit nog steeds voldoet maar de bedrijfsprocessen een betere performance of meer flexibiliteit nodig hebben, zou een migratie naar een ander platform een toepasselijke stap zijn. De meest radicale stap is om de gehele applicatie te veranderen:
wanneer een fundamentele verandering in de bedrijfsprocessen plaatsvindt, moet ook de manier waarop deze nieuwe processen ondersteund wordt door de ICT geheel opnieuw bekeken worden. Binnen de levensloop van een applicatie zal na verloop van tijd het relatieve belang van bovengenoemde vier aspecten wijzigen.

ALM en Kostenmanagement

De ICT-kosten van een organisatie kunnen worden bezien als het product van enerzijds het volume aan ICT dat de organisatie verbruikt (gemeten in eenheden zoals werkplekken, functiepunten enz.) en anderzijds de kosten per eenheid. De door een organisatie gekozen strategie werkt primair door in het verbruikte volume. Op effectiviteit gerichte organisaties zullen additionele eenheden ICT blijven verbruiken zolang het inzetten ervan leidt tot een substantiële verbetering van het te leveren product. De op innovatie gerichte organisatie verbruikt eenheden tot het moment dat een extra eenheid niet veel innovatief vermogen meer toevoegt. Organisaties die zich op efficiency oriënteren verbruiken extra eenheden ICT wanneer dat per saldo direct geld oplevert (grensnut). Dit verschilt van de benadering bij de keuze voor effectiviteit en innovatie: bij deze twee benaderingen wordt in ICT geïnvesteerd in de overtuiging dat deze strategie indirect tot geldelijk voordeel zal leiden.
Bij de keuze voor flexibiliteit worden ICT-eenheden verbruikt tot het gewenste niveau van flexibiliteit bereikt is. Dit verschilt van de benaderingen voor effectiviteit en innovatie in die zin dat het niet zinvol is extra eenheden te verbruiken teneinde extra flexibiliteit te creëren:
het gewenste niveau is afdoende. Het ligt voor de hand dat organisaties met een effectiviteits- of innovatiebenadering van de markt een hoger volume aan ICT verbruiken dan organisaties die zich op efficiency of flexibiliteit richten. Dit kan belangrijk zijn bij het hanteren van benchmarks.

Samenvatting bedrijfskundige benadering van applicatiebeheer

In onze optiek gaat een juist Application Lifecycle Management uit van de volgende omstandigheden:
• Door een applicatie ondersteunde bedrijfsprocessen veranderen continu.
• De dynamiek van deze veranderingen is terug te voeren op de business lifecycle
• De fundamentele keuzes die gemaakt moeten worden, draaien om vier met elkaar deels concurrerende aspecten: innovatie, effectiviteit, efficiëntie en flexibiliteit.
Een duidelijke keuze voor één dominant aspect in het bedrijfsbeleid is noodzakelijk om een succesvol ICT- en ALM-beleid te kunnen definiëren.
De gebruikersorganisatie is verantwoordelijk voor functioneel beheer, de ICT-organisatie voor applicatiebeheer en beide processen zijn nauw zijn met elkaar verbonden. In onze visie zijn beide partijen verantwoordelijk voor het in lijn houden van het feitelijk gevoerde ICT-beleid met het algemene bedrijfsbeleid. Deze gezamenlijke verantwoordelijkheid voor een goed Application Lifecycle Management biedt een solide basis voor een succesvolle samenwerking tussen de gebruikersorganisatie en de automatiseringsorganisatie, waardoor de voordelen van ICT optimaal worden benut.

FACTOR 2: DE INRICHTING VAN DE APPLICATIEBEHEERORGANISATIE ZELF

In deze paragraaf worden de kosten van de operationele processen van applicatiebeheer in beeld gebracht en worden enkele aanbevelingen voor kostenbesparingen gedaan. Deze verbeteringen, die met efficiënter kennismanagement te maken hebben, kunnen worden bereikt door in het strategisch ASL-proces
Skills Definition het belang van het aspect kenniscontinuïteit expliciet te benoemen en vervolgens vanuit het tactisch ASL-proces Planning en Control dit te operationaliseren.

Operationele kosten van applicatiebeheer
Het merendeel van de kosten die met applicatiebeheer samenhangen, heeft te maken met de personele bezetting (eigen en/of ingehuurde medewerkers). Het andere deel heeft met de faciliteiten te maken die nodig zijn voor het uitvoeren van de werkzaamheden.
De kosten van de faciliteiten worden voornamelijk beïnvloed door de keuzes die de  applicatiearchitecten en -ontwikkelaars hebben gemaakt.
Een indicatie van de verhouding tussen deze twee soorten kosten is dat de personeelskosten
70 à 80% van het geheel beslaan. De inspanning van de applicatiebeheerders is voornamelijk gericht op de instandhouding en verbetering van de applicatie, alsmede op ondersteuning op functioneel en technisch gebied.
Naast deze directe werkzaamheden zijn er ook noodzakelijke indirecte werkzaamheden om de applicatiebeheertaken goed te kunnen uitvoeren.

Tijdsbesteding Applicatiebeheer
Een van de belangrijkste activiteiten in deze categorie betreft het opbouwen en instandhouden van de benodigde kennis van de applicatie. De hoeveelheid benodigde kennis wordt hierbij beschouwd als een gegeven (dit is immers voornamelijk door applicatiearchitectuur en -ontwikkeling bepaald); waar het nu om gaat is de efficiency waarmee het kennismanagement wordt uitgevoerd. Van de totale inspanning voor applicatiebeheer wordt, afhankelijk van de omvang van de werkzaamheden, 15 tot 50% besteed aan het opdoen van voldoende kennis om in staat te zijn de werkzaamheden uit te voeren. Dit percentage is het hoogste bij grote applicaties met relatief weinig incidenten, wijzigingen en ondersteuningsvragen. De voornaamste factor die de omvang van deze kosten bepaalt, is de frequentie van vervanging van personeel. Vaak vindt vervanging plaats op verzoek van de medewerker zelf. Dit gebeurt meestal omdat de medewerker het niet meer naar zijn zin heeft. Hij is toe aan iets anders. Het is algemeen aanvaard dat er verschillen zijn tussen de stereotiepe ontwikkelaar en de stereotiepe beheerder. De ontwikkelaar wordt primair door creativiteit gedreven, de beheerder meer door verantwoordelijkheid. Wanneer applicatiebeheeropdrachten met stereotiepe ontwikkelaars worden bemand, zal er vaker sprake zijn van vervanging dan wanneer op beheerderskwaliteiten is geselecteerd.
Bij vervanging van een teamlid begint de kennisoverdracht met een korte periode voor uitleg door ervaren teamleden en het bestuderen van de applicatie inclusief documentatie en de broncode. Deze periode duurt een paar dagen en wordt gevolgd door een lange periode van feitelijk uitvoering van werkzaamheden.
In het begin gebeurt dit met veel begeleiding en toezicht, daarna met ondersteuning op afroep en tot slot op zo goed als zelfstandige basis. Over het algemeen zal deze periode als beëindigd worden beschouwd wanneer de applicatiebeheerder een productiviteit heeft bereikt gelijk aan 80% van de productiviteit van een ervaren teamlid. De ervaring leert dat deze periode tussen 3 en 9 maanden duurt. Dit is enerzijds afhankelijk van de omvang en kwaliteit van de applicatie en anderzijds van de kwaliteit van de applicatiebeheerder zelf. Er is uitgerekend hoeveel inspanningen een vervanging kost als de inleerperiode voor een applicatie 6 maanden bedraagt. Uit deze exercitie komt naar voren dat per keer dat iemand vervangen wordt 88 dagen in kenniscontinuïteit wordt geïnvesteerd. Indien de continuïteit van de ondersteuning tijdens kantooruren moet worden gewaarborgd, zal een applicatiebeheerteam uit drie leden bestaan.
Als in zo’n team gemiddeld eens per twee jaar een lid wordt vervangen, worden er dus jaarlijks 132 dagen uitsluitend aan kenniscontinuïteit besteed. Wanneer de feitelijke werkzaamheden voor  applicatiebeheer bijvoorbeeld 200 dagen in beslag nemen, blijkt dat 40% van de totale kosten met kenniscontinuïteit samenhangt. Wanneer het een organisatie lukt om personeel van applicatiebeheer
langer op een opdracht te houden, bijvoorbeeld vier jaar, daalt dit percentage tot 25%.
Hieruit volgt dat het hanteren van een effectief personeelsbeleid gericht op behoud van beheerpersoneel aanzienlijke kostenreducties met zich meebrengt. Dit pleit voor het organiseren van applicatiebeheer als gespecialiseerde activiteit in plaats van iets dat naast ontwikkeling gedaan moet worden.
Een eerste stap is dat de bewuste keuze voor applicatiebeheer als vakgebied een belangrijk selectiecriterium moet zijn bij het aantrekken van personeel. Andere mogelijkheden om behoud onder onderhoudspersoneel te bevorderen liggen op het gebied van het creëren van afwisselende werkzaamheden
binnen het kader van beheer. Ook dient de leiding ervoor te zorgen dat de teams voldoende autonomie hebben; dit ‘eigen winkel’- gevoel heeft tevens een positieve effect op de kwaliteit van de diensten: je bent trots op je eigen winkel! Dit betekent dat beleid gericht op het reduceren van het aantal medewerkers dat voor applicatiebeheer staat opgesteld niet dan met de grootste zorgvuldigheid moet worden ingezet. Wanneer de formatie onder de 3 respectievelijk 6 teamleden wordt teruggebracht, leidt dit tot risico’s voor de continuïteit. Zo kan goedkoop duurkoop worden; daarnaast is het denkbaar er een ongewenste afhankelijkheid van een persoon ontstaat.

FACTOR 3: DE OMGEVING VAN APPLICATIEBEHEER

Applicatiebeheer staat niet alleen. Er zijn diverse andere taakgebieden waarmee interactie plaatsvindt en die invloed op de inspanning en de kosten van applicatiebeheer uitoefenen.

A Applicatiearchitectuur en -ontwikkeling;
B Technisch beheer;
C Functioneel beheer; en
D Gebruikers.

A Applicatiearchitectuur en -ontwikkeling
Complexiteit van de applicatie
De keuzes die vanuit het taakgebied applicatiearchitectuur worden gemaakt, beïnvloeden met name de hoeveelheid kennis die door de applicatiebeheerders moet worden opgebouwd en onderhouden. Wanneer
applicatiearchitectuur bijvoorbeeld regelmatig nieuwe technologieën adopteert, staat applicatiebeheer voor de keuze om óf de huidige applicatiebeheerders bij te scholen in de nieuwe technologieën, dan wel om hiervoor nieuwe applicatiebeheerders aan te trekken. Het fenomeen dat beheer volgende is, is niet nieuw. Berghout [Berghout] beschrijft dit als volgt in zijn ‘beheerparadox’: hoewel de meeste kosten ná de bouwfase worden gemaakt, zijn er dan (in de beheerfase) minder mogelijkheden om de kosten direct te beïnvloeden. Dit geldt eveneens voor de opbrengsten van de ICT.
Dit pleit voor een goede benutting door de architecten en ontwikkelaars van de ervaringen vanuit de huidige beheerfase, opdat er bij de ontwikkeling van opvolgende systemen wordt gelet op de kosten voor de gehele levenscyclus van die systemen. Dit in tegenstelling tot het (sub)optimaliseren van de
kosten voor alleen de ontwikkelingsfase.

Kwaliteit van de applicatie
De applicatieontwikkelaars hebben invloed op het aantal incidenten dat door applicatiebeheer moet worden opgelost en op de doelmatigheid van de in de toekomst aan te brengen wijzigingen van de applicatie. Het aantal incidenten is voornamelijk afhankelijk van de kwaliteit van de programmatuur,
en dus de kwaliteit van de ontwikkelaars en het ontwikkelproces.
De doelmatigheid waarmee latere wijzigingen kunnen worden aangebracht wordt beïnvloed door de gehanteerde constructieprincipes, bijvoorbeeld of er bewust rekening gehouden is met de eisen die door applicatiebeheer worden gesteld. Denk hierbij met name aan onderhoudbaarheid, aanpasbaarheid, uitbreidbaarheid en testbaarheid [Bemelmans]. Het beschikken over adequate functionele specificaties
en technische documentatie speelt hierbij een doorslaggevende rol. Zo is er een causale samenhang tussen het kostenniveau van applicatiebeheer en de keuzes die bij de applicatiearchitectuur en -ontwikkeling zijn gemaakt.

B Technisch beheer
Kwaliteit van de technische infrastructuur en het beheer ervan
Uitval van de technische infrastructuur kan, afhankelijk van de robuustheid van de Applicatieprogrammatuur, gevolgen hebben voor applicatiebeheer. Verstoorde productieprocessen behoren, strikt gesproken, door operational maintenance te kunnen worden herstart, maar de praktijk is regelmatig dat dit taakgebied niet is belegd en dat toch applicatiebeheer voor de oplossing moet zorgen.

Omvang en frequentie van wijzigingen van de technische infrastructuur
De invoering van nieuwe versies van componenten van de technische infrastructuur, bijvoorbeeld het besturingssysteem of databasEmanagementsysteem, brengt in ieder geval met zich mee dat de correcte werking van de applicaties na de wijziging moet worden vastgesteld. In bepaalde gevallen moeten ook wijzigingen in de applicaties worden aangebracht, bijvoorbeeld als een oudere versie van een Ontwikkelomgeving wordt vervangen en bepaalde functies niet meer ondersteund worden.
Hoe vaker dit gebeurt, hoe hoger de kosten van applicatiebeheer voor ‘adaptief onderhoud’ als gevolg van de inspanning voor het aanbrengen van wijzigingen en met name het uitvoeren van de Regressietesten.

C Functioneel beheer
Mate van aansluiting van de informatievoorziening op de bedrijfsvoering
De mate waarin functioneel beheer de behoeften van de gebruikersorganisatie kan vertalen, resulteert primair in betere informatievoorziening, maar de ervaring leert ook dat een goede functioneel Beheerder in staat is om in één keer de goede functionaliteit bij applicatiebeheer te bestellen, en dit heeft uiteraard zijn weerslag in de kosten die met perfectief en additief onderhoud samenhangen.
Een algemeen geaccepteerde stelling is dat hoe eerder in het ontwikkelproces (ontwerp/bouw/test) een fout gemaakt is, hoe hoger de kosten later zijn om dit te herstellen. Dit geldt ook voor de Ontwikkeling die in het kader van applicatiebeheer plaatsvindt.

Samenstelling van portfolio van applicaties
Functioneel beheer bepaalt welke applicaties Gebruikt en beheerd worden. Wanneer een bedrijf besluit – om welke reden ook – om in meer afdelingen of divisies verschillende applicaties voor dezelfde functionaliteit te gebruiken, zal dit tot hogere kosten leiden.
Kostenbesparing wordt daarbij als voornaaste driver genoemd. Hoewel onze focus hier ligt op het beheer van maatwerkapplicaties, kan met betrekking tot standaardapplicaties worden opgemerkt dat een kritische blik op het aantal in een organisatie aanwezige licenties behoorlijke kostenbesparingen met relatief weinig ‘pijn’ kan opleveren (Application Consolidation).

Inrichting van functioneel beheer
De kwaliteit van de functioneel beheerder en het proces van functioneel beheer is mede bepalend voor de hoeveelheid ondersteuning die door de applicatiebeheerder moet worden geleverd. Dit hoeft niet per definitie te leiden tot hogere kosten voor functioneel beheer en applicatiebeheer tezamen, maar verhoogt wel de applicatiebeheerkosten sec. Veel organisaties worstelen met de invulling van functioneel beheer en doen een structureel beroep op applicatiebeheer om bijvoorbeeld functionele specificaties van wijzigingen op te stellen, releases te testen en de invoering te begeleiden. De uitdaging voor applicatiebeheer hierbij is om de functioneel beheerder steeds bij het verifiëren van specificaties en testresultaten te betrekken. Belangrijk is dan vooral om de verleiding te weerstaan de verantwoordelijkheid voor het bepalen van de noodzakelijke functionaliteit over te nemen van functioneel beheer.

D GebruikersDynamiek van de informatiebehoefte
Organisaties verschillen onderling in zowel hun informatiebehoefte als de frequentie en mate waarmee deze verandert. Galbraith [Galbraith] heeft uitgebreid geschreven over de strategie van verminderen van de behoefte aan informatie van organisatie door een daarop afgestemde inrichting van  bedrijfsprocessen en dit zal uiteraard gevolgen hebben voor de kosten van de informatievoorziening, inclusief applicatiebeheer. In onze visie wordt de informatiebehoefte van een organisatie voornamelijk bepaald door de marktbenadering van de organisatie.

Service levels waaraan voldaan moet worden
Vanuit het gebruik worden eisen aan de informatievoorziening gesteld. Deze worden vaak in service levels vertaald, waar van door de beheerders voldaan moet worden. Een service level dat relatief veel invloed op de kosten van applicatiebeheer heeft, is de beschikbaarheid van de applicatie buiten kantooruren. Dit service level kan geformuleerd worden in termen van een beschikbaarheidspercentage, een call-to-fix-afspraak of reactietijd bij incidenten.
Ondersteuning buiten kantooruren heeft grote gevolgen voor het aantal mensen met inhoudelijke kennis van de desbetreffende applicatie. Waar overdag voldaan kan worden met een team van minimaal drie leden (dit geeft relatieve zekerheid bij een combinatie van gepland en ongepland verzuim), moet voor bezetting ook ’s avonds of 7×24 uur gedacht worden aan zes teamleden. Uiteraard kunnen deze teamleden ook taken voor andere applicaties verrichten, maar de investering in kennisacquisitie en -behoud is nu eenmaal aanzienlijk hoger dan bij een service level voor ondersteuning tijdens kantooruren. Zoals eerder werd toegelicht, blijkt kennisacquisitie en -behoud een aanzienlijke kostenpost te zijn. Een uiterst zinvolle actie in het kader van kostenvermindering is om samen met de gebruikersorganisatie, veelal vertegenwoordigd door functioneel beheer, na te gaan in hoeverre in het verleden  gespecificeerde service windows werkelijk nodig zijn.

Aantal gebruikers en de organisatorische en geografische spreiding ervan
Het aantal gebruikers, maar ook de heterogeniteit (verschillende afdelingen, vestigingen) ervan, beïnvloedt het aantal incidenten. De ervaring leert dat de (Dijkstra vergeef ons) onvermijdelijke fouten in de applicatieprogrammatuur eerder worden ontdekt door intensiever gebruik. Hierbij past de kanttekening dat deze fouten vroeger of later toch ontdekt zouden worden. Intensiever gebruik haalt de kosten alleen maar naar voren. Een aanvullend punt is het kennisniveau van de gebruikers. Een laag kennisniveau van de gebruikers brengt hogere ondersteuningskosten met zich mee. Deze ondersteuning wordt meestal door de functioneel beheerder geleverd en, zoals eerder bleek, er is vaak sprake van ondersteuning van functioneel beheer door applicatiebeheer.

De invloeden uit de omgeving op het kostenniveau van applicatiebeheer zijn aanzienlijk. Een applicatiebeheer dat perfect is afgestemd op het bedrijfsbeleid in combinatie met een zorgvuldig gekozen personeelsbeleid kan door deze invloeden toch nog op een onaanvaardbaar kostenniveau terechtkomen. Het realiseren van het gewenste ‘kostenplaatje’ lukt daarom alleen als dit wordt gecoördineerd over taakgebieden binnen het ICT-beleid.

REFERENTIES
• [Bemelmans] Bemelmans T., Bestuurlijke informatiesystemen en automatisering, ISBN 90-207-2054-6, Kluwer Bedrijfswetenschappen, 1991.
• [Berghout] Berghout, E. hoofdstuk Van beheerparadigma naar beheerparadox, Complexiteit van beheer, beheer van complexiteit, ISBN 90-407-2168-8, Delft University Press, 2001.
• [Drift] Drift, van der W., Smalley, M. artikel Application Lifecycle Management in IT Beheer Magazine, oktober 2002.
• [Galbraith] Galbraith, Organizational Design: An Information Processing View, ISBN 0-8039-7177-X, Addison Wesley, 1974.
• [Pols] Pols, R. van der, ASL, een framework voor applicatiebeheer, ISBN 90-440-0266-X, ten Hagen & Stam, 2001.

Boeken over dit onderwerp

ASL 2 – Een framework voor applicatiemanagement

Auteur: Remko van der Pols
ASL, application Service Library, is als publicdomain-standaard hét procesframework voor applicatiemanagement. Dit handboek geeft u een gedegen en compleet overzicht van ASL 2, een evolutionaire vernieuwing van het succesvolle en breed toegepaste ASL framework. ASL ondersteunt u bij het inrichten van applicatiemanagement, onder andere door de best practices die te vinden zijn op de website van de ASL BiSL foundation. ASL is daardoor ook een kennisnetwerk. Bovendien sluit ASL aan op andere frameworks zoals BiSL (voor business information management) en ITIL.
Europrijs: 42,35
Bestellen

Naar een vraaggestuurde informatievoorziening

Auteur: Remko van der Pols
‘Naar een vraaggestuurde informatievoorziening’ is geschreven door experts op het gebied van de standaarden voor het beheer van IT en de informatievoorziening (IV). Zij brengen de werelden van IT en de business – in dit geval de zorg en bedrijfsvoering daarvan – bij elkaar. Dit combineren ze met hun jarenlange beheerervaring in verschillende marktsegmenten, waardoor Naar een vraaggestuurde informatievoorziening een praktisch boek is geworden. Het biedt de lezers vanuit verschillende perspectieven en op verschillende niveaus handreikingen en best practices.
Europrijs: 39,95
Bestellen

Meer boeken over ASL vinden.


-- Printbare PDF-versie --


No votes yet.
Please wait...

Aanvullingen

Geef zelf een aanvulling.

Geef een aanvulling

Licentie: Creative Commons (Naamsvermelding/Gelijkdelen)

Checklisten:
Invulling kostenmanagement 18 vragen.
Kosten/baten-analyse Ontwerp 25 vragen.
Kosten/baten analyse Realisatie 26 vragen.
Sidebar