De mens in de veranderende organisatie.2 Een verlichtende kijk op inbeheername van applicaties 267 Het in beheer nemen van een applicatie is voor zowel een (opleverende) projectorganisatie als een (ontvangende) beheerorganisatie vaak een lastig proces, waarbij de betrokken partijen geconfronteerd worden met diverse afstemmingsproblemen. Procesmodellen zoals ITIL en ASL richten zich vooral op de inrichting van het beheer zelf, maar schenken eigenlijk weinig aandacht aan de overgang van de systeemontwikkelingsfase naar de beheerfase. Zowel de projectleider, de beheermanager als de businessmanager bevinden zich hierbij in een onduidelijke en ongewisse situatie. Met andere woorden: de manager bevindt zich in de Twilight Zone. In dit artikel nemen we u mee naar een bouwproject van de (fictieve) applicatie AAP die voor de (eveneens fictieve) directeur van GAAP wordt ontwikkeld en vervolgens in beheer genomen moet worden. Wat echter niet fictief is, zijn de problemen en aandachtsgebieden die men vervolgens tegenkomt bij de daadwerkelijke inbeheername en de gangbare procesmodellen die gehanteerd worden bij de inrichting van beheerprocessen in het algemeen. In navolging van Looijen 1 onderscheiden we bij het beheer van informatiesystemen de drie domeinen functioneel beheer, applicatiebeheer en technisch beheer. Vanuit de optiek van het domein applicatiebeheer wordt beschreven hoe men kan voorkomen dat de schemering valt! Auteurs: Frances van Haagen en André Smulders - Ordina Application Management HET BOUWPROJECT Het bouwen van de applicatie AAP is bijna klaar. De acceptatietest is in volle gang. De projectmanager is al door zijn budget heen, maar hij is de klant ter wille door nu nog een aantal wijzigingen vanuit testbevindingen te implementeren die de klant enorm zullen helpen, maar feitelijk buiten de projectscope vallen. De klant is verantwoordelijk voor de functionele specificaties op basis waarvan is gebouwd maar die nu toch niet helemaal door de gebruikers blijken te worden onderschreven. De projectmanager doet wat hij kan, maar de mogelijkheden zijn beperkt. De nog openstaande testbevindingen zullen, met de applicatie en documentatie mee, worden opgeleverd aan de opdrachtgever. De overschrijding van de afgesproken termijn en het overeengekomen budget is nog aardig binnen de perken gebleven, en niemand wil op dit moment het behaalde succes in 1 Looijen, 2004 IT Service Management best practices, deel 3
268 gevaar brengen. Er staan immers alweer nieuwe projecten op stapel en er wordt door alle projectmedewerkers reikhalzend uitgekeken naar nieuwe uitdagingen. DE OPDRACHTGEVER AAP is gebouwd in opdracht van de directeur van GAAP. Hij is verantwoordelijk voor de uitvoering van het GAAP-bedrijfsproces. Zijn mensen zijn bezig de acceptatietest van AAP te doen. Sommigen hebben wel wat afwijkende ideeën over hoe AAP voor GAAP zou moeten werken, maar ten slotte is AAP vooral gebouwd om een aantal taken die nu met de hand worden gedaan te automatiseren. De klagers zijn altijd dezelfde: ze kunnen niet meekomen met nieuwe ontwikkelingen. Dus dat probleem is snel opgelost. In zowel de productietest als de acceptatietest is gebleken dat het systeem wel erg traag werkt, je zit soms wel een minuut te wachten voordat een nieuw scherm verschijnt. Het bouwproject kan daar niets meer aan doen, want in de specificaties werd niets vermeld over responstijden. EN NU BEHEREN! - WE GAAN OP BEZOEK Wij zijn AAPI: een interne beheerorganisatie of een externe beheerpartij - voor dit verhaal maakt het niet zoveel uit. We hebben de opdracht voor de directeur van GAAP het applicatiebeheer van AAP te gaan regelen en uitvoeren. We moeten er dus voor zorgen, dat de applicatie AAP doet wat ze geacht wordt te doen om het bedrijfsproces van de opdrachtgever te ondersteunen. Daarnaast is het onze taak om wijzigingen en toevoegingen op de functionaliteit van AAP te implementeren, als de opdrachtgever dat wenst. Tegelijkertijd zijn onze collega s van technisch beheer aangezocht om de infrastructurele voorzieningen in gereedheid te brengen, zodat de techniek is geregeld. We zijn nooit eerder betrokken geweest bij (de totstandkoming van) AAP - deze is dus met recht opeens uit de mouw gekomen - en daarom gaan we op bezoek bij het bouwproject, omdat we graag willen begrijpen wat we gaan beheren. De projectmanager staat ons te woord, geeft ons een demo en legt uit waar de documentatie op de archiefschijf te vinden is. Hiermee krijgen we een zee aan informatie ter beschikking, die dankzij goed versiebeheer uitstekend inzicht verschaft in het evolutieproces rondom de bouw van AAP. Voor AAP is een nieuwe architectuur en technologie gebruikt. De beheerders zullen daarom specifieke expertise nodig hebben. Die medewerkers van het bouwproject die ons goed zouden kunnen helpen, zijn alweer beloofd aan andere projecten of ze hebben er geen zin in om in beheer te gaan werken. Beheer is niet dynamisch en het staat niet goed op je cv. We gaan ook op bezoek bij de opdrachtgever. Die ziet voor ons van AAPI een schone taak weggelegd: het oplossen van de nog openstaande problemen, zoals die lange responstijden, en allerlei andere zaken die voor de gebruikers eigenlijk niet werkbaar blijken te zijn. We moeten er daarbij wel rekening mee houden, dat de gebruikers nog behoorlijk wat weerstand hebben tegen het nieuwe systeem en tegen het feit dat enkele collega s overbodig zijn geworden door dat systeem. ALLE GEKHEID OP EEN STOKJE Op bovenstaand scenario bestaan allerlei varianten. Waar het om draait is: inbeheername van een nieuwgebouwde applicatie is vaak een lastig proces. De afstemming tussen de betrokkenen vindt moeizaam plaats. Dat is ook wel begrijpelijk, gezien de verschillende invalshoeken: De opdrachtgever wil zo snel mogelijk met de nieuwe applicatie aan de slag, zodat een aantal operationele problemen tot het verleden gaat behoren, hij sneller en efficiënter kan gaan werken en zijn personeelscapaciteit kan worden aangepast aan de nieuwe werkwijze. De projectmanager wil acceptatie van de
De mens in de veranderende organisatie applicatie door de opdrachtgever, zodat hij décharge kan krijgen van het bouwproject en de eindafrekening kan sturen. De projectstuurgroep wil extra investeringen in het bouwproject zoveel mogelijk voorkomen en voert de druk op de projectmanager op. De applicatiebeheerder wil duidelijkheid over de applicatie die hij gaat beheren, en de zekerheid dat hij straks niet wordt overstelpt met vragen en verstoringen. Hij ziet veel extra werk door de inbeheername van de nieuwe applicatie op zich afkomen, en tegelijkertijd wordt hij onder druk gezet om te bezuinigen met behoud van kwaliteit van de dienstverlening. Procesmodellen zoals BiSL 2 voor functioneel beheer en ASL 3 voor applicatiebeheer leveren algemene kaders voor processen die aan de orde zijn bij respectievelijk informatiemanagement- en applicatiebeheer-processen. Hoewel een aantal van deze processen van belang is in het kader van verbetering van het inbeheernameproces, maakt het inbeheernameproces zelf geen deel uit van deze modellen. Service Commitment Management (in dit proces wordt een realistische SLA overeengekomen). Inbeheername speelt zich af in de Twilight Zone tussen het domein van applicatieontwikkeling en het domein van applicatiebeheer, en valt, als proces, theoretisch min of meer tussen de wal en het schip. Het veroorzaakt echter problemen die iedere opdrachtgever en beheerorganisatie, en iedere projectmanager die een product wil leveren waar de opdrachtgever echt iets aan heeft, herkent. We zullen daarom het inbeheernameproces schetsen vanuit onze eigen ervaring, en vanuit die van vakgenoten die we hebben gevraagd om hun praktijkervaringen met ons te delen. Aan de hand van deze schets zullen we een aantal concrete inbeheername-problemen benoemen, deze in verband brengen met de inhoudelijke relatie tussen systeemontwikkeling en applicatiebeheer, en adviezen en tips geven met betrekking tot de aanpak van de problemen. We zullen ook aangeven hoe modellen ons kunnen helpen met het vormgeven van de relatie tussen systeemontwikkeling en applicatiebeheer. 269 Toegepast op onze concrete probleemstelling, geven volwassenheidsmodellen als CMMI 4 en ITSCMM zeer bruikbare kwaliteitsrichtlijnen voor respectievelijk het (verder) ontwikkelen van applicaties en het managen van de applicatiebeheer-organisatie. Deze richtlijnen zijn ook praktisch bruikbaar voor organisaties die zich niet expliciet bezighouden met het bereiken van een bepaald volwassenheidsniveau op basis van deze modellen. Hoewel inbeheername geen expliciet onderdeel is van de procesgebieden in CMMI en ITSCMM, zal het wel degelijk aan de orde komen als je concreet aan de slag gaat met procesgebieden als - in CMMI - Requirements Development ( beheerbaarheid is een requirement voor de applicatie) of - in ITSCMM - INBEHEERNAMEPROCES Wat gebeurt er eigenlijk bij inbeheername van een applicatie? De systeemontwikkelings- en testfase wordt afgesloten met een acceptatietest door de gebruikers. Deze test levert een aantal bevindingen op die door het project deels worden verwerkt en deels worden opgenomen in de mee te leveren lijst van openstaande issues en bevindingen. Na afronding van de acceptatietest wordt de applicatie met bijbehorende producten (zoals gebruikersdocumentatie en technische documentatie) formeel geaccepteerd door de opdrachtgever, als eigenaar van het systeem. Deze acceptatie vindt plaats op basis van acceptatiecriteria die van tevoren 2 Van der Pols et al., 200 3 Van der Pols, 2001 4 Chrissis et al., 2003 Clerc et al., 200 IT Service Management best practices, deel 3
Eigenaar/ gebruiker Project 270 Functioneel beheer Systeemontwikkeling Applicatiebeheer Technisch beheer Onderhoudsorganisatie Figuur 1 Van systeemontwikkeling naar beheer tussen opdrachtgever en ontwikkelproject zijn overeengekomen. De opdrachtgever geeft de beheerorganisatie vervolgens de opdracht het systeem te gaan beheren. De beheerorganisatie bestaat feitelijk uit drie organisaties: 1. functioneel beheer, dat de eigenaar en gebruikers vertegenwoordigt, de functionele specificaties en ontwerpen beheert en bijvoorbeeld ook de opleiding voor de gebruikers van het nieuwe systeem verzorgt; 2. applicatiebeheer, dat de applicatie en de data beheert en onderhoudt en zorgt dat de applicatie doet wat ze moet doen; 3. technisch beheer, dat de exploitatie verzorgt en de infrastructuur beheert waarop de applicatie draait. Het is gebruikelijk dat applicatiebeheer en technisch beheer een intake doen van de in beheer te nemen applicatie op basis van specifieke beheer-acceptatiecriteria. Uit deze intake kunnen bevindingen naar voren komen die moeten worden opgelost voordat de applicatie in beheer kan worden genomen. KNELPUNTEN EN PROBLEMEN Functioneel beheer is normaliter - impliciet of expliciet - al betrokken bij het ontwikkeltraject. Er wordt immers gebouwd op basis van functionele ontwerpen, er zijn acceptatiecriteria overeengekomen tussen opdrachtgever en opdrachtnemer en er worden gebruikersacceptatietests uitgevoerd. Soms wordt de rol van functioneel beheer Rekencentrum vanuit het bouwproject ingevuld, omdat de gebruikersorganisatie en/of haar functioneel beheer nog moet worden ingericht. Met technisch beheer is vaak al samengewerkt (al dan niet in harmonie), bijvoorbeeld omdat het project ontwikkel- en testomgevingen nodig heeft en omdat er een productietest wordt gedaan waar technisch beheer bij betrokken is. Er zijn echter geen momenten waarop applicatiebeheer automatisch bij het project wordt betrokken. Dat gebeurt eigenlijk alleen, als opdrachtgever en projectmanagement zich bewust zijn van de noodzaak tot betrokkenheid en als er inzicht bestaat in de wijze waarop die betrokkenheid - vanaf de opstartfase - kan worden gerealiseerd. Wanneer dit bewustzijn en/of inzicht ontbreekt, of - om wat voor redenen ook - niet wordt gerealiseerd, wordt applicatiebeheer niet, of in een heel laat stadium, betrokken bij het ontwikkeltraject. Daarnaast neemt de applicatiebeheer-organisatie zelf vaak een afwachtende houding aan. Het is nog steeds niet gebruikelijk, dat applicatiebeheer proactief acteert in relatie tot nieuwe ontwikkelingen in de klantorganisatie. De in het bovenstaande geschetste situatie brengt een aantal risico s met zich mee, die zich maar al te vaak ontwikkelen tot daadwerkelijke knelpunten: In de specificatie-, ontwerp-, bouw- en testfase wordt onvoldoende rekening gehouden met applicatiebeheeraspecten. Dit kan desastreuze gevolgen hebben voor de kwaliteit van de ondersteuning van het bedrijfsproces in de beheerfase.
De mens in de veranderende organisatie Er is bij de applicatiebeheer-organisatie te weinig kennis van de applicatie, toegepaste technologieën, architectuur, interfaces en dergelijke aanwezig om (zelfstandig) het beheer te kunnen uitvoeren. Naar aanleiding van de behoefte aan informatie over en inzicht in de te beheren applicatie, wordt in een kort tijdsbestek een grote hoeveelheid gegevens en informatie uitgestort over applicatiebeheer. Zeker wanneer er geen (eenduidig) versiebeheer is toegepast, is er veel tijd nodig om de samenhang en informatiewaarde te bepalen. Er kan niet tijdig overeenstemming worden bereikt tussen opdrachtgever en applicatiebeheerorganisatie over zaken als servicelevels en kosten. Dit vormt temeer een probleem, omdat het inschatten van de te verwachten beheerinspanning voor een nieuwe applicatie heel lastig kan zijn, bijvoorbeeld als we te maken hebben met nieuwe technologie, architectuurprincipes et cetera. Bruikbare ervaringscijfers met betrekking tot de beheerinspanning zijn dan nog niet voorhanden. Als gevolg van de drie voorgaande punten heeft de applicatiebeheer-organisatie te weinig inzicht in de specifieke resources (mensen en middelen) die nodig zijn om het applicatiebeheer goed te kunnen uitvoeren, en/of kan deze resources niet tijdig beschikbaar stellen of alleen tegen relatief hoge kosten. Er is te weinig gelegenheid om te toetsen of de processen en werkwijzen van de applicatiebeheer-organisatie adequaat zijn voor het beheren van de nieuwe applicatie en om eventueel aanpassingen hierin aan te brengen. Er ontstaat een negatieve spanning bij medewerkers van applicatiebeheer, die zich kan vertalen in weerstand tegen inbeheername en een defensieve houding. De uitdrukking over de schutting gooien horen we nergens zo vaak als bij beheerders. Naast de knelpunten die worden veroorzaakt door onvoldoende betrokkenheid van applicatiebeheer bij het bouwproject, zien we regelmatig het probleem dat applicatiebeheer wordt opgezadeld met openstaande testbevindingen en issues vanuit het bouwproject. Het oplossen van deze openstaande punten is vaak essentieel voor de klanttevredenheid, omdat het hier vooral problemen betreft die zijn ontstaan door gebreken in het functioneel ontwerp van de applicatie. De kans op het optreden van deze gebreken is groter naarmate functioneel beheer er minder goed in slaagt de gebruikers en de eigenaar van de applicatie te vertegenwoordigen. Wanneer de rol van functioneel beheer vanuit het bouwproject wordt ingevuld, is het bijna per definitie het geval dat de noodzakelijke inbreng vanuit de gebruikersorganisatie verre van optimaal is. Dergelijke gebreken in het functioneel ontwerp komen veelal pas aan het licht op het moment dat de gebruikers er in de acceptatietest daadwerkelijk mee worden geconfronteerd. Het project is echter niet verplicht om ze op te lossen; de scope van het project wordt immers bepaald door de functionele ontwerpen en de daarop gebaseerde acceptatiecriteria van de opdrachtgever. Daarnaast is er in de eindfase van het bouwproject vaak sprake van een grote tijdsdruk, omdat de afgesproken opleverdatum nabij is. Een groot deel van het bouwteam is al weg, om de budgetoverschrijding binnen de perken te houden. In deze situatie staat de kwaliteit van de opgeleverde producten onder druk. De applicatiebeheer-organisatie wordt maar al te vaak met de consequenties hiervan geconfronteerd, in de vorm van relatief veel correctief onderhoud in de eerste productiefase. AANPAK VAN DE KNELPUNTEN Resumerend hebben we te maken met twee kernproblemen die de inbeheername van nieuwe applicaties door applicatiebeheer bemoeilijken: 1. onvoldoende betrokkenheid van applicatiebeheer bij het ontwikkeltraject; 2. een ontevreden klant op het moment van inbeheername, omdat het systeem wel conform de specificaties, maar niet conform de verwachtingen is gebouwd. 271 IT Service Management best practices, deel 3
272 Het eerste probleem zullen we nader uitwerken. Het tweede, zeer fundamentele, probleem heeft ingrijpende consequenties voor de omstandigheden waaronder applicatiebeheer wordt uitgevoerd en voor de relatie tussen de applicatiebeheer-organisatie en de klantorganisatie, maar valt buiten het bestek van dit artikel. We geven eerst een beschrijving van de raakvlakken tussen applicatieontwikkeling en applicatiebeheer en vervolgens een aantal adviezen en tips die kunnen helpen om het eerste kernprobleem aan te pakken. Relatie tussen bouwtraject en applicatiebeheer Op welke momenten moet applicatiebeheer betrokken zijn bij het bouwtraject? Het antwoord hierop is eenvoudig: bouw is de eerste fase van beheer. Ter toelichting op deze stellingname wordt de inhoudelijke relatie tussen bouw en applicatiebeheer uitgewerkt in termen van de generieke 6 processen voor specificatie, planning, ontwerp, bouw en test. Om de redenering niet onnodig te compliceren, wordt het implementatieproces buiten beschouwing gelaten. Waar mogelijk, geven we aan hoe de modellen ons kunnen helpen bij het implementeren van deze relatie. Uitgangspunt hierbij is, dat ieder model vanuit zijn eigen invalshoek nuttig is als inspiratiebron. Zo is CMMI gericht op productontwikkeling (en dus ook op applicatieontwikkeling) en ASL op applicatiebeheer, maar beide benoemen ze aandachtspunten die toegepast kunnen worden op onze generieke processen. In de operationele laag van ASL (zie figuur 2) komt in het procescluster Onderhoud en vernieuwing dan ook veel terug van de applicatieontwikkelingsprocessen, maar dan toegepast binnen de beheersituatie, die specifieke eisen en beperkingen met zich meebrengt. Specificatieproces In het specificatieproces worden voor de gehele levenscyclus van de applicatie, van concept tot en met uitfasering, de behoeften en verwachtingen van alle belanghebbenden bij de applicatie verzameld en in kaart gebracht. Deze behoeften en verwachtingen worden vervolgens vertaald in functionele en niet-functionele specificaties voor de applicatie en bijbehorende deliverables, zoals documentatie. Over het geheel van specificaties wordt overeenstemming bereikt tussen alle belanghebbenden. Planning en control Kwaliteitsmanagement Kostenmanagement Service level management Beheer Onderhoud/vernieuwing Incidentbeheer Wijzigingenbeheer Ontwerp Capaciteitsbeheer Continuiteitsbeheer Configuratiebeheer Beschikbaarheidsbeheer Programmabeheer en distributie Impactanalyse Implementatie Testen Realisatie Figuur 2 ASL: Sturende en operationele processen Verbindende processen 6 Met generiek bedoelen we in dit verband: niet geënt op een specifiek procesmodel, maar onderkend en benoemd vanuit het perspectief van inbeheername. Vanuit dit perspectief is vervolgens verband gelegd met de modellen.
De mens in de veranderende organisatie Uitvoerend Specificeren Voorbereiden transitie Toetsen en testen Vormgeven niet geaut. IV 273 Funcionaliteitenbeheer Figuur 3 BiSL: Context van proces 'Specificeren' De applicatiebeheer-organisatie is een van de belanghebbenden. Eisen en beperkingen die voortvloeien uit beheeroverwegingen (zoals eisen aan de componentenstructuur en aan de technische documentatie) worden vertaald in niet-functionele specificaties. De acceptatiecriteria voor het project, op basis waarvan het project uiteindelijk décharge krijgt, worden overeengekomen op basis van de specificaties. In de praktijk ligt vaak de nadruk op het opstellen van functionele specificaties. De niet-functionele eisen zijn dan feitelijk wel aanwezig, maar het bouwproject is hier niet of onvoldoende op gericht. In zo n situatie ontstaat een mismatch tussen specificaties en (al dan niet expliciete) acceptatiecriteria, die pijnlijk duidelijk wordt op het moment dat applicatiebeheer betrokken raakt - hopelijk in de acceptatiefase, vaak pas daarna. 7 Van Haagen et al., 200 CMMI geeft zeer duidelijke richtlijnen voor het procesgebied Requirements Development, met behulp waarvan kan worden geborgd dat de eisen van applicatiebeheer ook in de specificaties worden opgenomen. In ASL, dat op de beheersituatie is gericht, wordt in het kader van het proces Wijzigingenbeheer genoemd dat er procesen producteisen worden vastgesteld. In de uitvoerende laag van BiSL (zie figuur 3) wordt vanuit de optiek van functioneel beheer het proces Specificeren onderkend en beschreven; in dit proces worden niet-functionele specificaties vanuit gebruikersoptiek benoemd, bijvoorbeeld op het terrein van performance en betrouwbaarheid. Het inbrengen van eisen vanuit de applicatiebeheerorganisatie en andere belanghebbenden buiten de gebruikersorganisatie vindt in de interactie tussen BiSL en ASL plaats in het ASL-proces Impactanalyse. De borging dat specificaties ook zijn gericht op beheereisen, moet er dan uit bestaan dat de resultaten van impactanalyse, indien nodig, teruggekoppeld worden naar een nieuwe ronde van het specificatieproces. Van Haagen & Huijzer 7 belichten het specificatieproces in de beheersituatie, dat veel overeenkomsten vertoont met datzelfde proces in de bouwfase. Vanuit de observatie dat het ontbreken van goede specificaties een van de grootste knelpunten binnen applicatiemanagement is, worden praktische tips ter verbetering van specificatiemanagement gegeven met eenvoudige Key Performance Indicators (KPI s) ter ondersteuning van het verbeterproces. Planningproces In het planningproces wordt op basis van specificaties en globale oplossingsrichtingen een plan van aanpak gemaakt. Het is gebruikelijk, dat dit plan van aanpak zich beperkt tot de bouwfase. Als het specificatieproces echter volledig wordt uitgevoerd, heeft het plan van aanpak betrekking op de realisatie van zowel ontwerp, bouw als beheer: de totale levenscyclus van de applicatie. IT Service Management best practices, deel 3
274 Concreet betekent dit, dat de benodigde resources (mensen en middelen) en kennis voor zowel bouw als applicatiebeheer in dit proces worden gespecificeerd, en dat alle belanghebbenden (zie Specificatieproces) zich aan het plan committeren. Commitment van de uitvoerenden vindt plaats zodra dit mogelijk is. In veel gevallen zal de leverancier voor applicatiebeheer-diensten nog moeten worden geselecteerd, hetgeen een mogelijk risico vormt voor de kwaliteit van de specificaties. In de praktijk zal een Service Level Agreement (SLA) voor applicatiebeheer als deliverable in dit integrale plan worden opgenomen. In CMMI worden concrete richtlijnen voor het procesgebied Project Planning gegeven, die borgen dat de planning is gericht op alle relevante aspecten, inclusief applicatiebeheer. In ASL komen de planningsaspecten voor applicatiebeheer terug in de processen Wijzigingenbeheer (operationeel niveau) en Planning en Control (sturend niveau). In ITSCMM behandelt het procesgebied Service Commitment Management de totstandkoming van een realistische SLA, en Service Delivery Planning de planning van de applicatiebeheer-organisatie ten behoeve van het realiseren van de overeengekomen servicelevels. Ontwerpproces In het ontwerpproces worden de verzamelde functionele en niet-functionele specificaties verder ontwikkeld tot ontwerpen en testspecificaties. Applicatiebeheer heeft hier vanuit verschillende invalshoeken belang bij: 1. De beheereisen moeten daadwerkelijk leiden tot ontwerpbeslissingen. 2. De resulterende ontwerpdocumenten moeten voldoen aan de eisen die door applicatiebeheer worden gesteld aan opzet, structuur, standaardisatie, beheerbaarheid (waar het technische ontwerpen betreft) et cetera. 3. De testontwerpen moeten de applicatiebeheer-aspecten goed adresseren. Het ontwikkelen van ontwerpen in aansluiting op het specificatieproces wordt in CMMI met name behandeld in het procesgebied Technical Solution. De ASL-processen Impactanalyse, Ontwerp en Realisatie bestrijken globaal de ontwikkeling van oplossingsrichting tot technisch ontwerp in de beheersituatie. In het proces Ontwerp worden generieke - kwaliteitscriteria ingebracht vanuit het sturende proces Kwaliteitsmanagement. In de opzet van ASL worden op deze wijze de specifieke eisen van applicatiebeheer ingebracht in de ontwerpfase. Bouwproces Tijdens de bouw van de applicatie worden de ontwerpen daadwerkelijk gerealiseerd. Applicatiebeheer levert in deze fase geen input. Wel wordt deze fase benut om de noodzakelijke inhoudelijke synergie tussen bouw en beheer verder vorm te geven. Met name als er sprake is van functionele en/of technologische complexiteit, wordt in deze fase al gewerkt aan de opbouw van kennis die ter beschikking zal komen van de beheerorganisatie. De concrete implementatie van de ontwerpen wordt in CMMI behandeld in het procesgebied Technical Solution. In Product Integration worden richtlijnen gegeven voor de integratie van de diverse componenten en de oplevering van de totale applicatie nadat het testproces (zie hieronder) heeft plaatsgevonden. Het ASL-proces Realisatie behandelt de realisatie van goedgekeurde wijzigingsverzoeken. Testproces Door middel van het testproces wordt geverifieerd of de gebouwde applicatie in overeenstemming is met de specificaties ( Did we build it right? ), en - als het goed is - ook gevalideerd of de gebouwde applicatie daadwerkelijk voorziet in de behoeften van de gebruikers en andere belanghebbenden, zoals applicatiebeheer ( Did we build the right thing? ).
De mens in de veranderende organisatie Chrissis et al., 2003, werken het testen op beheerbaarheid expliciet uit in de CMMIprocesgebieden Validation en Verification. Er wordt zowel getest op basis van specificaties (verificatie) als op basis van het concrete gedrag van de applicatie in de beoogde omgeving (validatie). Applicatiebeheer is actief betrokken bij het testtraject; tijdens de acceptatietest wordt de beheerder beschouwd als een specifiek type gebruiker. Ook in ASL is het proces Testen onderkend en beschreven. De applicatiebeheer-aspecten worden getest op basis van de generieke kwaliteitscriteria die in het proces Ontwerp zijn ingebracht vanuit Kwaliteitsmanagement (zie boven). Verbetering van de betrokkenheid van applicatiebeheer In het bovenstaande is toegelicht op welke punten bouw en applicatiebeheer elkaar raken en waarom betrokkenheid van applicatiebeheer nodig is om tot een goed totaalproduct, een beheerbare en beheerde applicatie, te komen. In figuur 4 is de relatie tussen bouw en beheer nog eens samengevat: Bouw Figuur 4 Bouw is eerste fase van beheer Beheer Moment van inproductiename Bouw is de eerste fase van beheer; beheer moet intensief betrokken zijn bij het bouwtraject, vooral in de begin- en eindfase. Alleen tijdens het eigenlijke bouwproces is de betrokkenheid van beheer minder intensief. Tot zover de ideale wereld! Hoe kan de noodzakelijke betrokkenheid van applicatiebeheer bij het ontwikkeltraject nu concreet worden verbeterd? Hieronder geven we een aantal ideeën en adviezen, die het mogelijk maken klein te beginnen en groot te groeien. Tips voor de opdrachtgever en de projectmanager De kern van ons advies is, dat het management van het bouwtraject en het applicatiebeheer zo veel mogelijk moet worden ingericht als een continu proces. Om de overdracht van kennis over de applicatie, technologie, interfaces en dergelijke aan applicatiebeheer te faciliteren, is ontwikkeling van een integrale visie op het management, de inrichting en de bemensing van bouw en beheer nodig. Om deze ontwikkeling te ondersteunen en te realiseren, zijn er verschillende concrete scenario s met verschillende integratiegraden van bouw en beheer mogelijk. De haalbaarheid hangt met name af van de contractuele en informele relatie tussen de opdrachtgever, de leverancier van de applicatie en de leverancier van het applicatiebeheer. Een aantal voorbeelden: Integreer het bouwteam en het beheerteam tot één applicatieteam : de ultieme realisatie van bouw is de eerste fase van beheer. Zorg ervoor, dat het applicatiebeheer in een zo vroeg mogelijk stadium wordt aanbesteed. Stel aan het begin van het bouwtraject acceptatiecriteria voor de eindoplevering vast; neem daarbij de intake -criteria van de applicatiebeheer-organisatie op als onderdeel van de acceptatiecriteria. Zorg er vervolgens voor, dat applicatiebeheer daadwerkelijk betrokken is bij de acceptatie. Zo wordt voorkomen dat de intake plaatsvindt als de applicatie al is geaccepteerd door de opdrachtgever, en dan alsnog voor onaangename verassingen zorgt. Laat de projectorganisatie tijdelijk het applicatiebeheer uitvoeren, als maatregel ter voorkoming van continuïteitsproblemen in de ondersteuning van de bedrijfsprocessen. Neem in de nazorg- en/of garantiebepalingen van het ontwikkelcontract op, dat pro- 27 IT Service Management best practices, deel 3
276 jectmedewerkers na oplevering gedurende een bepaalde periode beschikbaar zijn voor het leveren van ondersteuning aan beheerders (en eventueel ook aan eindgebruikers). In de projectbegroting wordt dan rekening gehouden met deze extra dienstverlening. Neem in het projectplan voor het ontwikkeltraject het resourceplan van de toekomstige applicatiebeheer-organisatie op als deliverable - dit stimuleert ook de samenwerking tussen de bouw en beheer. Zorg voor een goed en duidelijk projectdossier vanuit een multidisciplinaire visie - laat de toekomstige beheerders meedenken over de inhoud van het dossier. Zorg voor een deugdelijke inrichting van configuratiebeheer, met een goed onderhouden Configuration Management Database (CMDB) - dit voorkomt veel ellende bij de inbeheername. Gebruik, indien mogelijk, dezelfde tooling voor configuratiebeheer als de (applicatie)beheerorganisatie. Laat toekomstige beheerders als ontwikkelaar meedraaien in het projectteam. Laat toekomstige beheerders als tester meedraaien in het projectteam. Laat toekomstige beheerders participeren in het opstellen en uitvoeren van het integratieplan van de gekoppelde componenten. Laat toekomstige beheerders een rol vervullen in Quality Assurance of Quality Control. Laat functioneel beheer een projectopdracht geven aan de beheerorganisatie, die vervolgens een projectorganisatie formeert, met als doel het inrichten van beheer. Tips voor de applicatiebeheer-organisatie Het is cruciaal, dat applicatiebeheer een proactieve houding ontwikkelt om een grotere en meer structurele betrokkenheid bij ontwikkelprojecten te realiseren. Een aantal voorbeelden van proactieve acties: Bied aan, te participeren in specificatie- en ontwerpteams. Bied aan, het projectplan te reviewen. Zorg ervoor, dat intakecriteria (ofwel acceptatiecriteria) voor inbeheername aanwezig en gecommuniceerd zijn. Geef aan dat de intakecriteria deel moeten uitmaken van de acceptatiecriteria voor het bouwproject en participeer in het opstellen van de acceptatiecriteria. Review het testplan en de testgevallen op applicatiebeheer-aspecten. Neem zitting in het acceptatietestteam. Leg tijdig claims op unieke resources, indien deze randvoorwaardelijk zijn voor het uitvoeren van applicatiebeheer en/of het realiseren van de benodigde kennisoverdracht. Te denken valt aan: - informatiearchitecten (met name waar het nieuwe architectuur betreft); - materiedeskundigen; - ondersteuning door technologiepartners (zoals pakketleveranciers). CONCLUSIE Het in beheer nemen van een applicatie vergt een proactieve aanpak van zowel projectmanager en projectmedewerkers, als opdrachtgever, als (applicatie)beheerders. Door in een zo vroeg mogelijk stadium samen te werken kunnen we veel problemen voorkomen. Hier geldt dan ook de open deur: Voorkomen is beter dan genezen. De in dit artikel geschetste problemen zijn voor velen herkenbaar en gelden eigenlijk als worst practice. Maar door schade en schande worden we wijzer: we leren van de best practices èn de worst practices. Modellen die we tot onze beschikking hebben om de afzonderlijke ontwikkel- en beheerprocessen in te richten en te stroomlijnen geven nog geen expliciete aanknopingspunten om het proces rondom de feitelijke inbeheername op een gestructureerde en/of gestandaardiseerde manier vorm te geven. We hebben echter ook de meerwaarde laten zien van diezelfde modellen. Het eclectisch gebruik van juist die onderdelen van ASL, BiSL, CMMI en ITSCMM die ons kunnen helpen met het inbeheernameproces ( de krenten uit de pap ), biedt ons een inspiratiebron
De mens in de veranderende organisatie om onze ondersteuning van de bedrijfsprocessen ook op dit punt te verbeteren. Kortom: samen kunnen we zorgen voor verlichting in de Twilight Zone! Frances van Haagen is Senior Management Consultant bij Ordina Application Management B.V. Zij houdt zich bezig met vraagstukken rond Application Management in verbinding met procesverbetering en kwaliteitssystemen. Tevens is zij actief in de werkgroep Certificering van de ASL Foundation. André Smulders is Senior ICT Consultant bij Ordina Application Management B.V. Hij houdt zich bezig met consultancy, procesinrichting en -verbetering en implementaties van beheerprocessen. Daarnaast is hij actief in de werkgroep Development van de ASL Foundation. LITERATUUR Pols, Remko van der, Ralph Donatz en Frank van Outvorst, BiSL, Een framework voor Functioneel Beheer en Informatiemanagement, Van Haren Publishing, 200. Pols, Remko van der, ASL, Een framework voor applicatiebeheer, ten Hagen & Stam, 2001. Chrissis, Mary Beth, Mike Konrad en Sandy Shrum, CMMI. Guidelines for Process Integration and Product Improvement, Addison-Wesley, 2003. Clerc, Viktor en Frank Niessink, IT Service CMM. A pocket guide, Van Haren Publishing, 2004. Haagen, Frances van en Norbert Huijzer, Back to the Specs, IT Beheer Magazine no. 4, mei 200. Looijen, Maarten, Beheer van informatiesystemen, SDU Uitgeverij, 2004. Smulders, André en Hans Boer, In beheer nemen van een applicatie, White Paper ASL Foundation, december 200. 277 IT Service Management best practices, deel 3