Het in beheer nemen van een applicatie is voor zowel een
|
|
- Timo Janssens
- 8 jaren geleden
- Aantal bezoeken:
Transcriptie
1 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
2 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
3 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., Van der Pols, Chrissis et al., 2003 Clerc et al., 200 IT Service Management best practices, deel 3
4 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.
5 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
6 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.
7 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
8 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? ).
9 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
10 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
11 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, Chrissis, Mary Beth, Mike Konrad en Sandy Shrum, CMMI. Guidelines for Process Integration and Product Improvement, Addison-Wesley, Clerc, Viktor en Frank Niessink, IT Service CMM. A pocket guide, Van Haren Publishing, Haagen, Frances van en Norbert Huijzer, Back to the Specs, IT Beheer Magazine no. 4, mei 200. Looijen, Maarten, Beheer van informatiesystemen, SDU Uitgeverij, Smulders, André en Hans Boer, In beheer nemen van een applicatie, White Paper ASL Foundation, december IT Service Management best practices, deel 3
12
Goed functioneel beheer noodzaak voor effectievere SPI
getronicspinkroccade.nl Goed functioneel beheer noodzaak voor effectievere SPI Machteld Meijer Zeist, 3 oktober 2006 Inhoud Domeinen en modellen Functioneel beheer en BiSL Rol van BiSL in SPI 1 Goed functioneel
Nadere informatieBISL Business Information Services Library. Een introductie. Algemene informatie voor medewerkers van SYSQA B.V.
BISL Business Information Services Library Een introductie Algemene informatie voor medewerkers van SYSQA B.V. Organisatie SYSQA B.V. Pagina 2 van 9 Inhoudsopgave 1 INLEIDING... 3 1.1 ALGEMEEN... 3 1.2
Nadere informatieHet in beheer nemen van een applicatie Een white paper van de ASL BiSL Foundation
Het in beheer nemen van een applicatie is voor zowel de opleverende (project)organisatie als de ontvangende (beheer)organisatie vaak een moeizaam proces waarbij de betrokken partijen geconfronteerd worden
Nadere informatieExamen BiSLF Business Information Management Foundation
Examen BiSLF Business Information Management Foundation Publicatiedatum Startdatum 1 januari 2006 1 oktober 2005 Doelgroep De doelgroep voor deze module heeft in zijn of haar functie een rol bij het aansturen,
Nadere informatieStarterskit ASL. Plaats Nieuwegein Datum 4 mei 2010 Auteur Werkgroep ASL Best Practices Status Definitief 1.0
Starterskit ASL Plaats Nieuwegein Datum Auteur Werkgroep ASL Best Practices Status Definitief 1.0 1 Doelstelling... 3 2 Onderdelen Starterskit ASL... 3 3 Processtappen Starterskit ASL... 3 4 Achtergronden...
Nadere informatiegetronicspinkroccade.nl EPD en BiSL! 13 e EPD-ICT Congres NVMA 12 juni 2008 Thijs de Jong Senior adviseur en trainer
getronicspinkroccade.nl EPD en BiSL! 13 e EPD-ICT Congres NVMA 12 juni 2008 Thijs de Jong Senior adviseur en trainer Kennismaking 1 Beheer Van project naar beheer Grootschalige Vernieuwing Applicatiebeheer
Nadere informatieHet BiSL-model. Een whitepaper van The Lifecycle Company
Het BiSL-model Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht op hooflijnen van het BiSL-model. U vindt een overzicht van de processen en per proces een beknopte
Nadere informatieRapportage Pizzasessie Functioneel-beheer.com Specialisten Managers Adviseurs Algemeen functioneel beheer applicatiebeheer informatiemanagement
Rapportage Pizzasessie Functioneel-beheer.com Alle deelnemers hebben hun functienaam opgegeven. De volgende functienamen zijn gemeld: Specialisten o Functioneel beheerder (9x) o Functioneel applicatiebeheerder
Nadere informatieDe relatie tussen projecten en (functioneel) beheer
De relatie tussen projecten en (functioneel) beheer Een whitepaper van The Lifecycle Company Met dit whitepaper proberen we u inzicht te geven in: de eisen ten aanzien van overdracht van project naar gebruik,
Nadere informatieMet dit whitepaper bieden we u een overzicht we een aantal soorten (product-) toetsing. Dit overzicht is niet volledig!
Toetsingen Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u een overzicht we een aantal soorten (product-) toetsing. Dit overzicht is niet volledig! 1. Product-, proces- of organisatie-audit
Nadere informatieUitgangspunten en randvoorwaarden bij implementatie BiSL
Uitgangspunten en randvoorwaarden bij implementatie BiSL Auteurs: Frank van Outvorst, Henri Huisman Datum: Januari 2009 Inleiding Veel organisaties zijn momenteel bezig met het (her)inrichten van de vraagzijde
Nadere informatieBetere koppeling processen door helder onderscheid
outsourcing f Betere koppeling processen door helder onderscheid Een keten van functioneel, applicatieen technisch beheer De noodzaak tot standaardisatie en professionalisering van applicatiebeheer is
Nadere informatieEibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008
Titel, samenvatting en biografie Eibert Dijkgraaf Kijk verder dan je test neus lang is: Life Cycle Testing Scan Voorjaarsevent Testnet: 30 juni 2008 Samenvatting: Eibert Dijkgraaf (testconsultant Test
Nadere informatieApplication Management Foundation based on ASL2
Voorbeeldexamen Application Management Foundation based on ASL2 Editie december 2011 Copyright 2011 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or stored
Nadere informatieContinue kwaliteit: samenwerken bij dagelijks beheer van applicaties
ICT-beheerdomeinen laten samenwerken (deel 3) Continue kwaliteit: samenwerken bij dagelijks beheer van applicaties Eerder in deze reeks artikelen ging het over de noodzaak vorm te geven aan de concrete
Nadere informatieEXIN Business Information Management Foundation
Preparation Guide EXIN Business Information Management Foundation with reference to BiSL Editie 201601 Copyright 2016 EXIN Alle rechten voorbehouden Niets uit deze uitgave mag worden openbaar gemaakt of
Nadere informatieProjectmanagement De rol van een stuurgroep
Projectmanagement De rol van een stuurgroep Inleiding Projecten worden veelal gekenmerkt door een relatief standaard projectstructuur van een stuurgroep, projectgroep en enkele werkgroepen. De stuurgroep
Nadere informatieFunctioneel Applicatie Beheer
Functioneel Applicatie Beheer Functioneel Applicatie Beheer Goed functioneel beheer werkt als smeerolie voor uw organisatie en zorgt voor een optimale aansluiting van de informatievoorziening op de primaire
Nadere informatieKwaliteitsbewaking en testen in ICT beheerorganisaties
DKTP Informatie Technologie Veembroederhof 1 1019 HD Amsterdam Telefoon 020 427 52 21 Kwaliteitsbewaking en testen in ICT beheerorganisaties Voor de meeste projectgroepen die software ontwikkelen vormt
Nadere informatiePROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D
PROJECT PLAN VOOR DE IMPLEMENTATIE VAN EEN STANDAARD SITE VOOR DE VERENIGING O3D Auteur : P. van der Meer, Ritense B.V. Datum : 17 juli 2008 Versie : 1.3 2008 Ritense B.V. INHOUD 1 VERSIEBEHEER...1 2 PROJECT
Nadere informatieITIL en/of eigen verantwoordelijkheid
ITIL en/of eigen verantwoordelijkheid Leo Ruijs 20 SEPTEMBER 2011 INNOVATIEDAG MANSYSTEMS Service8 B.V. Stelling ITIL BEPERKT DE EIGEN VERANTWOORDELIJKHEID VAN MEDEWERKERS EN HEEFT DAARMEE EEN NEGATIEVE
Nadere informatieBusiness-ICT-Alignment en functioneel beheer Een nuchtere kijk op functioneel beheer
Business-ICT-Alignment en functioneel beheer Een nuchtere kijk op functioneel beheer Inleiding Functioneel beheer, dat klinkt wellicht als een ICT-activiteit. En ICT-activiteiten, dat zijn zaken voor de
Nadere informatieEXIN Application Management Foundation
Voorbeeldexamen EXIN Application Management Foundation with reference to ASL Editie mei 2012 Copyright 2012 EXIN All rights reserved. No part of this publication may be published, reproduced, copied or
Nadere informatieMisvattingen en misverstanden over ASL en BiSL (deel 1)
RENÉ SIEDERS Waarom de modellen zijn zoals ze zijn Misvattingen en misverstanden over ASL en BiSL (deel 1) René Sieders, gespecialiseerd in het inrichten en verbeteren van applicatiebeheer en functioneel
Nadere informatieITIL v3 en ASL, een Latrelatie
dossier SOA- en applicatiebeheer ITIL v3 en ASL, een Latrelatie Verwantschap is groot, maar filosofieën erachter verschillen In de nieuwe versie van ITIL is vrij veel veranderd. Aspecten van applicatiebeheer
Nadere informatieLast but not least. Hoofdstuk 35. Bijlagen
Last but not least Hoofdstuk 35 Bijlagen V1.2 / 01 februari 2016 Geen copyright! MCTL is in licentie gegeven volgens een Creative Commons Naamsvermelding 3.0 Nederland licentie. Gebaseerd op een werk van
Nadere informatieCopyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.
ASL 2 Z elfevaluatie Werkboek Beleidsmatig OCM ACM Sturende processen (intern) Sturende processen (extern) Operationeel Beheer Onderhoud/vernieuwing Intern Verbindende processen Extern Naam Groep Datum
Nadere informatieBusiness Information Management Foundation
Preparation Guide Business Information Management Foundation Editie februari 2012 Alle rechten voorbehouden Niets uit deze uitgave mag worden openbaar gemaakt of verveelvoudigd, opgeslagen in een dataverwerkend
Nadere informatieProactief en voorspellend beheer Beheer kan effi ciënter en met hogere kwaliteit
Proactief en voorspellend beheer Beheer kan effi ciënter en met hogere kwaliteit Beheer kan efficiënter en met hogere kwaliteit Leveranciers van beheertools en organisaties die IT-beheer uitvoeren prijzen
Nadere informatieEen framework voor applicatiebeheer
Een framework voor applicatie Mark Smalley ASL-Foundation www.aslfoundation.org SPIder, Utrecht, 10 juni 2003 Agenda Positionering applicatie Wat is ASL Waarom ASL Hoe ziet ASL eruit Samenwerking domeinen
Nadere informatieFactsheet CONTINUOUS VALUE DELIVERY Mirabeau
Factsheet CONTINUOUS VALUE DELIVERY Mirabeau CONTINUOUS VALUE DELIVERY We zorgen ervoor dat u in elke volwassenheidsfase van uw digitale platform snel en continu waarde kunt toevoegen voor eindgebruikers.
Nadere informatiePositionering functioneel beheer
Positionering functioneel beheer Een whitepaper van The Lifecycle Company Met dit whitepaper bieden we u inzicht in de opties van het organiseren van functioneel beheer: concentreren (centraal) of niet
Nadere informatieResultaat risico inventarisatie Noordelijk Belastingkantoor
Resultaat risico inventarisatie Noordelijk Belastingkantoor NOTITIE AAN: Bestuur NBK 11-1-2019 VAN: VKA STATUS: Aanleiding en vraag Het Noordelijk Belastingkantoor (hierna: NBK) verzorgt voor drie noordelijke
Nadere informatie5 handvatten voor de menselijke maat voor gegevenskwaliteit
5 handvatten voor de menselijke maat voor gegevenskwaliteit Frank van Outvorst Tooling-Event Wie ben ik? Wie zijn wij? Frank van Outvorst Mede-auteur BiSL Werk: Consultant procesverbetering BIM en IM inhoudelijke
Nadere informatieISM en Lean, natuurlijke bondgenoten
ISM en Lean, natuurlijke bondgenoten Een introductie van de samenwerking tussen de ISM-methode en Lean Een whitepaper van 10-8-2017 Whitepaper: ISM en Lean 1 ISM en Lean, natuurlijke bondgenoten De ISM-methode
Nadere informatieProject Methodiek. 15:00 u
15:00 u Project Methodiek Hoe zorgt u dat ICT projecten op een geborgde manier uitvoering vinden, binnen tijd en budget en met het doel dat de functionele eisen en wensen ingewilligd worden? Projectmethodiek
Nadere informatieTESTEN % ITIL & ASL & BISL WAT HEEFT EEN TESTER AAN ITIL? EEN PRAKTISCH HULPMIDDEL OF BUREAUCRATISCHE BALLAST?
TESTEN % ITIL & ASL & BISL WAT HEEFT EEN TESTER AAN ITIL? EEN PRAKTISCH HULPMIDDEL OF BUREAUCRATISCHE BALLAST? ITIL INFORMATION TECHNOLOGY INFRASTRUCTURE LIBRARY OPGEKOMEN IN DE JAREN 1980 ITIL V2 IN 2001
Nadere informatieBiSL Zelfevaluatie. Auteur: Ralph Donatz. Naam Groep Datum. Met bijdragen van: Frank van Outvorst, René Sieders, Remko van der Pols en Kees Deurloo
BiSL Zelfevaluatie Naam Groep Datum Auteur: Ralph Donatz Met bijdragen van: Frank van vorst, René Sieders, Remko van der Pols en Kees Deurloo Colofon Titel: Ondertitel: Auteur: Uitgever: BiSL Zelfevaluatie
Nadere informatieVan BiSL naar BiSL Next
Whitepaper Van BiSL naar BiSL Next Auteur: Lucille van der Hagen Datum: 14 november 2016 Inhoud 1 Inleiding 2 Waarom veranderen? 3 Huidige BiSL model 4 Nieuwe BiSL model 5 Van huidig naar nieuw 6 Mapping
Nadere informatieAnt: B Dit is het doel van het proces.
In welk proces vormt het voor aanpassingen in de informatievoorziening beschikbaar gestelde budget een mandaat voor besluitvorming? A: Contractmanagement B: Financieel management C: Transitie D: Wijzigingenbeheer
Nadere informatieSamenwerken bij wijzigingen op applicaties
ICT-beheerdomeinen laten samenwerken (deel 4) Samenwerken bij wijzigingen op applicaties In dit vierde en in het volgende artikel beschrijven Machteld Meijer en Frances van Haagen de samenwerking tussen
Nadere informatieCopyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.
ASL 2 Z elfevaluatie Werkboek Beleidsmatig OCM ACM Sturende processen (intern) Sturende processen (extern) Operationeel Beheer Onderhoud/vernieuwing Intern Verbindende processen Extern Naam Groep Datum
Nadere informatieWHITE PAPER. Business Solutions
WHITE PAPER Business Solutions De keuze van de strategie/aanpak is be-palend voor de complexiteit en doorlooptijd van een implementatie. Introductie Uw organisatie staat op het punt om een standaard software
Nadere informatie14-9-2015. Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling
Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Systeemontwikkeling Je kunt hier (optioneel) ook een gratis tool downloaden
Nadere informatieBABOK en BiSL. Marcel Schaar Machteld Meijer. Valori Maise
BABOK en BiSL Marcel Schaar Machteld Meijer Valori Maise Wat is BABOK BABOK. Ondersteuning voor het werk van de business analist Beschrijving van kennisgebieden (knowledge areas) en bijbehorende taken
Nadere informatieBiSL Scenario s. Informatiebeleid. Bijlage E Best practice Verzamelen objectieve gegevens. Hans van der Linden, Remko van der Pols
BiSL Scenario s Informatiebeleid Best practice Verzamelen objectieve gegevens Hans van der Linden, Remko van der Pols 2016 Hans van der Linden, erven Remko van der Pols Boom uitgevers Amsterdam Alle rechten
Nadere informatie8-12-2015. Hoe test je een pen? Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten
Les 1 Docent: Marcel Gelsing Je kunt de presentatie na afloop van elke les downloaden. Ga naar : www.gelsing.info Kies voor de map Acceptatietesten Hoe test je een pen? 1 Bekijk eerst het filmpje over
Nadere informatieEXIN Business Information Management Foundation
Voorbeeldexamen EXIN Business Information Management Foundation with reference to BiSL Editie mei 2012 Copyright 2012 EXIN Alle rechten voorbehouden. Niets uit deze uitgave mag worden openbaar gemaakt
Nadere informatieOpdrachtgever in het testproces
Opdrachtgever in het testproces Testnet Voorjaarsevenement 2011 Olaf Agterbosch 1.0 Agenda Even voorstellen; De onderschatte rol van opdrachtgevers bij testen; Aansturen van testen in (out)sourcingsituaties;
Nadere informatieIn een keten gaat het om de verbindingen, niet om de schakels.
Verbindingsmodel IV Serviceketen Theo Thiadens en Adri Cornelissen In een keten gaat het om de verbindingen, niet om de schakels. Verbindingsmodel IV Serviceketen Theo Thiadens Alleen een organisatie die
Nadere informatieApplicatiebeheer opereert niet alleen maar vormt vaak de schakel tussen functioneel beheer (opdrachtgever) en technisch beheer (rekencentrum)
ASL Plaats en boodschappen van ASL Applicatiebeheer opereert niet alleen maar vormt vaak de schakel tussen functioneel beheer (opdrachtgever) en technisch beheer (rekencentrum) Functioneel beheer: namens
Nadere informatieERP Implementatie in de praktijk
ERP Implementatie in de praktijk Door: Erik Meevis www.kcla.nl 11 juni 2008 Even voorstellen. Erik Meevis, partner bij KCLA Groep onafhankelijke organisatieadviseurs Afkomstig uit en gericht op productiebedrijven
Nadere informatieCustomer Case CED. Feiten in het kort:
Feiten in het kort: Bedrijf: European Claim Experts Branche: Verzekeringen Werknemers: 1.150 Activiteiten: Internationale Claims management en Expertise Oplossing: Opbouw Mendix-platform voor het flexibel
Nadere informatiePraktijkvoorbeelden en w aarom ISO
Softw are Asset Management Praktijkvoorbeelden en w aarom ISO Rogier van Kuijk Sof tw are Asset Manager Nederland in 1850 NS nu (jaarverslag 2013) 406 5.200 32.155 250.000 1.200.000-43.000.000-64.000.000
Nadere informatieVernieuwing VMS ICT oplossing v0.1
Bijlage D: Projectplan Vernieuwing VMS ICT oplossing v0.1 Realisatie, Implementatie en overdracht aan beheer Inhoudsopgave 1 Projectdefinitie 3 1.1 Inleiding 3 1.2 Doelstelling 3 1.3 Reikwijdte 4 1.4 Randvoorwaarden,
Nadere informatiePinkSCAN. Verbeter de kwaliteit van uw IT dienstverlening
PinkSCAN Verbeter de kwaliteit van uw IT dienstverlening De business stelt steeds hogere eisen aan de kwaliteit van de IT dienstverlening. Nieuwe service modellen vereisen aanpassingen in de wijze waarop
Nadere informatieProefexamen ITIL Foundation
Proefexamen ITIL Foundation 1. Van welk proces is risicoanalyse een essentieel onderdeel? a. IT Service Continuity Management b. Service Level Management c. Capacity Management d. Financial Management
Nadere informatieWij testen..maar....wat test jij?
Wij testen..maar....wat test jij? Wij testen maar wat test jij? Harm Pul, Busineslinemanager Functioneel Beheer TMAP dag 2015, 29 september 2015 Bussum 2 Herkent u dit? De gebruikers testen dit straks
Nadere informatieOpdrachtgever in het testproces. Testnet Voorjaarsevenement 2011 Olaf Agterbosch
Opdrachtgever in het testproces Testnet Voorjaarsevenement 2011 Olaf Agterbosch Agenda Even voorstellen; De onderschatte rol van opdrachtgevers bij testen; Aansturen van testen in (out)sourcingsituaties;
Nadere informatieBrochure ASL2 Foundation
Brochure ASL2 Foundation Over Pink Elephant Pink Elephant is een internationale kennisleider op het gebied van bedrijfsinnovatie en bedrijfsverandering. Met advies- en IT dienstverlening haalt Pink Elephant
Nadere informatieInhoud. Deel een Het ontwikkeltraject 13. Inleiding 11
5 Inhoud Inleiding 11 Deel een Het ontwikkeltraject 13 1 Werken binnen organisaties 15 1.1 Non-profit-organisatie 15 1.2 Profit-organisatie 16 1.3 Doelen 16 1.4 Rechtsvormen 16 Rechtspersoon 17 Persoonlijke
Nadere informatieTestgedreven ontwikkeling dat is pas veilig!
Testgedreven ontwikkeling dat is pas veilig! INTRODUCTIE ANKO TIJMAN 2 Software tester sinds 1997 (TMap, ISEB Practitioner) Eerste agile ervaring in 2001 Presentaties op (inter)nationale congressen Nov
Nadere informatieOlde Bijvank Advies Organisatieontwikkeling & Managementcontrol
SAMENVATTING ITIL ITIL is nog steeds dé standaard voor het inrichten van beheerspocessen binnen een IT-organisatie. En dekt zowel applicatie- als infrastructuur beheer af. Indien gewenst kan ITIL worden
Nadere informatieICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden
Drechtsteden Technische Architectuur (DTA) ICT Beheermodel informatiesystemen Drechtsteden Baseline inrichting ICT beheermodel Drechtsteden Status : Definitief 1.0 Redactie : DTA Datum : 29-08-2007 1 Versiebeheer
Nadere informatieDe impact en implementatie van de outsourcing op de bedrijfsvoering is als één van de 6 deelprojecten ondergebracht binnen het project outsourcing.
Bijlagen 1 en 2: Aanbevelingen en opvolging Gateway Reviews (corsa 2018017934) Bijlage 1: Aanbevelingen en opvolging Gateway Review 2018 Aanbeveling Opvolging Status Opmerking 1. Richt een apart project
Nadere informatieHandout. Pagina 1. SYSQA B.V. Almere. Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven SYSQA SYSQA.
Capability Maturity Model Integration (CMMI) Technische Universiteit Eindhoven Johan Zandhuis SYSQA Start: 1999 Onafhankelijk Quality Assurance in IT 150 medewerkers (en groeiend) 2 SYSQA Operationeel
Nadere informatieVoorbeeldexamen. Business Information Management Foundation. Editie augustus 2011
Voorbeeldexamen Business Information Management Foundation Editie augustus 2011 Copyright 2011 EXIN Alle rechten voorbehouden. Niets uit deze uitgave mag worden openbaar gemaakt of verveelvoudigd, opgeslagen
Nadere informatieSamenvatting ASL 2 Een Framework voor Applicatiebeheer
S A M E N V A T T I N G Samenvatting ASL 2 Een Framework voor Applicatiebeheer Versie 1.0 ML augustus 2010 Inhoudsopgave INTRODUCTIE 3 UITVOERENDE PROCESSEN 6 1. DE BEHEERPROCESSEN 6 1.1. GEBRUIKSONDERSTEUNING
Nadere informatieProcesvalidatie voor een veiliger ketentest
Procesvalidatie voor een veiliger ketentest Johan Vink TestNet Voorjaarsevenement 2010 Agenda Inleiding Typering project & testaanpak Werkwijze business proces Probleem De opdracht voor het testteam Probleemanalyse
Nadere informatieMartin van Leeuwen Happy Testing
Titel, samenvatting en biografie Samenvatting: Deze presentatie beschrijft een aantal test maatregelen die in een RUP nieuwbouw project zijn genomen, om ervoor te zorgen dat het testen aan het eind van
Nadere informatiePlan van Aanpak Pilot
Plan van Aanpak Pilot DBK-applicaties Beproeven compatibiliteit DBK-applicaties op innovatieplatform voor de Veiligheidsregio s Status : concept Versienummer : V0.2 Datum : Augustus 2012 Blad : 2 / 6 Inhoudsopgave
Nadere informatieManagement. Analyse Sourcing Management
Management Analyse Sourcing Management Management Business Driven Management Informatie- en communicatietoepassingen zijn onmisbaar geworden in de dagelijkse praktijk van uw organisatie. Steeds meer
Nadere informatieTussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011
Universitair Informatiemanagement Kenmerk: SECR/UIM/11/0914/FS Datum: 14-09-11 Tussenrapportage project professionaliseren functioneel beheer instellingssystemen September 2011 1. Inleiding Begin 2011
Nadere informatie10 trends in Performance testen of: wat hebben we écht te bieden?
10 trends in Performance testen of: wat hebben we écht te bieden? Martijn Ruff 30 mei 2012 Agenda Even voorstellen... Introductie 10 Trends Conclusies KETENBEWAKING TM 2 Even voorstellen... KETENBEWAKING
Nadere informatieHet succes van samen werken!
White paper Het succes van samen werken! Regover B.V. Bankenlaan 50 1944 NN Beverwijk info@regover.com www.regover.com Inleiding Regover B.V., opgericht in 2011, is gespecialiseerd in het inrichten en
Nadere informatieOnderwijsgroep Tilburg. De Blauwdruk van Onderwijsgroep Tilburg
Onderwijsgroep Tilburg De Blauwdruk van Onderwijsgroep Tilburg Even voorstellen Jan Schrevel jan@jsad.nl +31625181818 Projectleider Blauwdruk Joël de Bruijn jdebruijn@onderwijsgroeptilburg.nl +31614241587
Nadere informatieFunctionaliteitenbeheer
Organisatie Functionaliteit 1 Richtinggevend Sturend Uitvoerend Het gaat hier om het initiëren van en zorgdragen voor de uitwerking en verandering van de gewenste wijzigingen aan de informatievoorziening.
Nadere informatiePQR Lifecycle Services. Het begint pas als het project klaar is
PQR Lifecycle Services Het begint pas als het project klaar is IT wordt een steeds crucialer onderdeel van de dagelijkse bedrijfsvoering. Waar u ook bent, het moet altijd beschikbaar en binnen bereik zijn.
Nadere informatieEPD Epic. (Inbare) Baten met het nieuwe EPD
EPD Epic (Inbare) Baten met het nieuwe EPD Agenda 1. De baten in de business Case 2. Voorbereiding realisatie gedurende implementatie Epic Business Case Epic MCL Opdracht: werk een business case integraal
Nadere informatiePortal Planning Process
BROCHURE Portal Planning Process SAMENWERKEN AAN EEN WAARDEVOL PORTAAL BROCHURE PORTAL PLANNING PROCESS 2 Axians PORTAL PLANNING PROCESS BROCHURE Inhoud Introductie 4 3 Portal Planning Process 5 4 Uitdagingen
Nadere informatieFunctiebeschrijving. Applicatiebeheerder. Graad B1-B3
Functiebeschrijving Applicatiebeheerder Graad B1-B3 1 1 Applicatiebeheerder 1.1 Rol Als applicatiebeheerder ben je het aanspreekpunt voor het ontwerp, beheer en de instandhouding van de toegewezen applicaties.
Nadere informatieCourseware. BiSL Foundation
BiSL Foundation Courseware Courseware Colofon Titel: Auteurs: Uitgever: BiSL Foundation Courseware Frank van Outvorst & Réne Sieders Van Haren Publishing, Zaltbommel ISBN Hard copy: 978 94 018 0051 8 Druk:
Nadere informatieDe Next Practice. Wilbert Teunissen Management Consultant Informatiemanagement
De Next Practice Wilbert Teunissen Management Consultant Informatiemanagement Sogeti & ontwikkeling van FB 2005 De Uitdaging 4 e industriële revolutie NU!! Digitale Economie 27% heeft op dit moment een
Nadere informatieISM: BPM voor IT Service Management
ISM: BPM voor IT Service Management ISM: BPM voor IT Service Management Het jonge IT-vakgebied wordt bestookt met allerlei frameworks om grip te krijgen op de input en output: ITIL, ASL, BiSL, COBIT en
Nadere informatieStop met procesgericht ICT-beheer. Betere resultaten door eigen verantwoordelijkheid
Stop met procesgericht ICT-beheer Betere resultaten door eigen verantwoordelijkheid Wie is Leo Ruijs? Leo Ruijs, Service 8-2 - Ontwikkelingen vakgebied 1950-1970 Beheer als specialisatie 1970-1990 ICT
Nadere informatieBusiness Scenario. Voorbeeld Archimate Risico Extensie. versie 0.1. Bert Dingemans
Business Scenario Voorbeeld Archimate Risico Extensie versie 0.1 Bert Dingemans Administratieve pagina Wijzigingshistorie Versie Datum Auteur Reden wijziging Review historie Naam Afdeling Functie Datum
Nadere informatieTesten. Presentatie. Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2
Testen Presentatie Open-i Software Services BV, Maarssen Datum : 06-07-2013 Versie : 1.2 Algemeen Tegenwoordig behoeft het belang van testen nauwelijks nog te worden uitgelegd. Binnen organisaties speelt
Nadere informatieVoorbeeld SLA <applicatie>
Naam Best Practice Voorbeeld SLA IDnr 067_BP_N Datum aangepast 01/01/2011 Omschrijving van de inhoud Een voorbeelddocument van (SLA) Soort document Voorbeeld ASL Processen Servicelevel management
Nadere informatieHERGEBRUIK VAN REQUIREMENTS
HERGEBRUIK VAN REQUIREMENTS EEN PRAKTISCHE AANPAK BUSINESS ANALYSE CENTER OF EXCELLENCE - SYNERGIO Inhoudsopgave 1 HERGEBRUIK VAN REQUIREMENTS... 3 1.1 GEBRUIKEN VERSUS HERGEBRUIKEN... 4 2 STRATEGIE...
Nadere informatieAlbert Jan Anneveld en Co Meerveld Testomgevingen, nu zeker wel!!!
Titel, samenvatting en biografie Albert Jan Anneveld en Co Meerveld Testomgevingen, nu zeker wel!!! Samenvatting: Het belang van testen hoeven we niet uit te leggen. Onze presentatie behelst een warm pleidooi
Nadere informatieTesten+ Testaanpak Sogeti testteam bij de Friesland Bank. Versie: 13 februari 2012 André Louwes / Arjan van der Haar
Testen+ Testaanpak Sogeti testteam bij de Friesland Bank Versie: 13 februari 2012 André Louwes / Arjan van der Haar Testen+ Voorstellen André Louwes Senior Testmanager (Sogeti) Manager testline (Friesland
Nadere informatieConclusie: voor elke organisatie die dit nastreeft is het goed besturen en beheersen van de bedrijfsprocessen
1 Waarom? : Succesvol zijn is een keuze! Organisaties worden door haar omgeving meer en meer gedwongen om beter te presteren. Voornamelijk wordt dit ingegeven door de klant die haar eisen en wensen m.b.t.
Nadere informatieEnd-to-End testen: de laatste horde
End-to-End testen: de laatste horde Dieter Arnouts Agenda Begrip End-to-End testen in het test proces Praktische aanpak End-to-End Test Omgeving Uitdagingen End-to-End testen: De laatste horde 11/10/2010
Nadere informatieWerkgroep Integrale SPI Strategieën
Werkgroep Integrale SPI Strategieën Mario van Os Sogeti Nederland B.V. 10 november 2005 Agenda werkgroep 16:40 Eindresultaat Werkgroep Modellen: wanneer wat door Mario van Os, Sogeti 17:15 Presentatie
Nadere informatieMisvattingen, misverstanden en vragen over ASL en BiSL
Misvattingen, misverstanden en vragen over ASL en BiSL Machteld Meijer en René Sieders Machteld Meijer en René Sieders, specialisten op het gebied van applicatiemanagement en businessinformatiemanagement,
Nadere informatieOUTSOURCING In dit document wordt het begrip outscourcing of aanbesteding nader toegelicht.
OUTSOURCING In dit document wordt het begrip outscourcing of aanbesteding nader toegelicht. Vormen van outsourcing In praktijk zien we verschillende vormen van outsourcing die we verder niet toelichten
Nadere informatieL = Lokaal, R = Regionaal; N = NL, Landelijk. (Het betreft hier de Nederlandse politie) T1 = tussentijds resultaat, Tn = gewenst eindresultaat
Bron [een deel van; zie ook blz 6]: http://www.aslbislfoundation.org/dmdocuments/bisl_bp051_wie_doet_wat_matrix.doc (BiSL-Procescluster/Proces Informatiecoördinatie) Wie-Doet-Wat-Matrix / WDW-matrix 1.
Nadere informatieCopyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see
BiSL Foundation Courseware - Nederlands Colofon Titel: Auteurs: Uitgever: BiSL Foundation Courseware - Nederlands Frank van Outvorst & Réne Sieders Van Haren Publishing, Zaltbommel ISBN Hard copy: 978
Nadere informatieOverzicht van taken en competenties. Demandmanager-rol
Overzicht van taken en competenties Demandmanager-rol Inhoudsopgave 1 Taakomschrijving... 2 1.1 AA-1 Goedkeuren/beoordelen opdracht, verzoek, e.d.... 2 1.2 AA-7 Evalueren opdracht... 2 1.3 CA-1 Onderhouden
Nadere informatieProject Dijkversterking Krimpen
Project Dijkversterking Krimpen Dijkversterking & UAV-gc Samenwerken met de opdrachtnemer Huub Verbruggen Projectmanager Dijkversterking Krimpen Even voorstellen Huub Verbruggen Projectmanager van beroep
Nadere informatie