1. Probleemstelling
2. Doel en afbakening van de blauwdruk
3. Architectuur van de blauwdruk
4. Toepassingen van deze blauwdruk

1.  Probleemstelling

Het is een bekend gegeven dat er vaak sprake is van miscommunicatie tussen de ICT-dienstverleners en de gebruikers die zij bedienen. Lang heeft men de oplossing gezocht in de invoering van methoden en technieken, maar in de meeste gevallen werd hierdoor de stroperigheid van de communicatie alleen maar verhoogd. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2′.)  Zelfs een SLA is doorgaans onvoldoende om dit op een adequate manier te regelen.
Het probleem zit hem dan ook vaak niet in de methoden en de technieken, maar in de afspraken die gemaakt wordt tussen partijen over de samenwerking en de afbakening van verantwoordelijkheden. (Zie ook ‘BiSL maakt functioneel beheer wel erg ingewikkeld’.)
Hierdoor kan voorkomen worden dat enerzijds overlap van activiteiten voorkomt en anderzijds bepaalde activiteiten blijven liggen. Het gaat er tenslotte niet om wie welke activiteiten uitvoert in uw organisatie, maar dat ze uitgevoerd worden.
In dit artikel wordt u een tweetal modellen aangereikt waarmee u het huidige functioneren van de samenwerking kunt evalueren (zie voor een voorbeeld hiervan ‘Review processen informatievoorziening praktijkvoorbeeld’) en hoe u dit kunt verbeteren. 

2.  Doel en afbakening van de blauwdruk

Het doel van deze blauwdruk is het beschrijven van de inrichting van processen binnen een interne ICT-organisatie ter borging van het op flexibele wijze ontwikkelen en in stand houden van een betrouwbare en beheersbare informatievoorziening.

Uitgangspunten, die zijn gehanteerd bij de opzet van de blauwdruk zijn:

• De procesinrichting is zodanig, dat voor elk proces een klant en een leverancier is te onderscheiden en dat gestructureerd en klantgericht werken wordt gestimuleerd en deels wordt afgedwongen.
• Processen worden meetbaar en controleerbaar.
• Er worden zelfsturende mechanismen gebruikt.

 Deze blauwdruk is bruikbaar voor interne en externe ICT-organisaties, die diensten willen verlenen volgens afspraak.

3.   Architectuur van de blauwdruk

3.1 Inrichting van de overall informatievoorzieningsfunctie

Bij het inrichten van de processen zal de driedeling beleid, planning & control en uitvoering zowel bij de gebruikersorganisatie als de ICT-organisatie belegd moeten zijn. Onderstaand wordt een situatie geschetst, die uitgaat van formele overeenkomsten. Omdat meestal onvoldoende inzicht bestaat in zowel de gekwantificeerde behoefte als in de performance, zal het enige jaren vergen, voor dit gerealiseerd is.

Figuur 1: Inrichten van de processen beleid, planning & control en uitvoering

 Op het hoogste niveau bij de gebruikersorganisatie dienen de volgende zaken belegd te worden:

• informatiebeleid en projectenplan;
• informatie architectuur, gegevensarchitectuur, beveiligingsarchitectuur;
• normen en standaards m.b.t. processen en middelen;
• opdrachtenbeheer;
• contractbeheer;
• auditing.

Op het hoogste niveau bij de ICT-organisatie worden belegd:

• servicebeleid en de dienstenportfolio;
• een architectuur van de ICT-infrastructuur, waarmee adequaat behoeften van de klanten vervuld kunnen worden;
• relatiebeheer;
• service level management;
• opdrachtenbeheer.

De partijen op dit niveau stemmen met elkaar af over service level agreements, opdrachten en leveringsvoorwaarden. Voorts zijn behoeften op termijn en de kwaliteit van de dienstverlening onderwerp van gesprek.

Op het P&C-niveau binnen de gebruikersorganisatie worden o.a. belegd:

• projectenbeheer;
• financieel beheer;
• functioneel beheer (o.a. gegevensbeheer, applicatiebeheer etc.);
• toetsing;
• beveiligingsbeheer;
• kennisbeheer;
• accountbeheer;
• inkoop en afroepen diensten en producten.

Het P&C-niveau binnen de ICT-organisatie vormt de front office van haar operationele dienstverlening aan de klanten en tevens de aansturing van haar back office activiteiten. Hier worden o.a. belegd:

• incidentbeheer;
• wijzigingsbeheer;
• configuratie beheer;
• projectbeheer;
• service management;
• quality assurance;

Deze niveaus stemmen af over de besturing en bewaking van de uitvoerende activiteiten in het kader van de behoeften van de gebruikersorganisatie op basis van de op het hoogste niveau gesloten overeenkomsten.

Op het laagste niveau binnen beide organisatie zijn de uitvoerende en ondersteunende processen en activiteiten belegd. De focus op dit niveau is primair inhoudelijk gericht en afstemming vindt plaats over inhoudelijke zaken. Bij de gebruikersorganisatie zijn dit o.a.:

• gebruikersondersteuning;
• logistieke processen;
• afhandeling incidenten;
• documenteren;
• controle taken.

Bij de ICT-organisatie zijn dit o.a.:

• operationeel beheer automatiseringsmiddelen;
• uitvoeren project activiteiten;
• advisering;
• incident afhandeling;
• documenteren;
• controle taken.

3.2 Afbakening van de informatievoorzieningsfunctie

Om verantwoordelijkheden eenduidig te kunnen beleggen, maken we enerzijds een onderscheid tussen taken, waarvoor de gebruikersorganisatie verantwoordelijk voor is en de taken, waar de ICT-organisatie verantwoordelijk voor is.
Voorts wordt er onderscheid gemaakt tussen het in stand houden van de informatievoorziening (niet projectmatig), en het ontwikkelen en wijzigen (onderhoud) van de informatievoorziening (wel projectmatig). Belangrijk item hierin is het helder vastleggen van de koppelvlakken. Schematisch kunnen we dit als volgt illustreren:

Figuur 2: Koppelvlakken gebruikersorganisatie - IT-organisatie

Belangrijk verschil tussen de ontwikkeling en de instandhouding is dat het opdrachtbeheer, project management en uitvoering bij de ontwikkeling over de betrokken partijen sterk geïntegreerd dient te worden, terwijl bij het in stand houden de koppeling zich met name op het middelste niveau afspeelt. Dat betekent, dat het in stand houden een andere set aan procedures kent dan de ontwikkeling.

3.3 Koppelvlakken 

Koppelvlak 1

Ontwikkelen en wijzigen van informatie systemen is een activiteit, die projectmatig wordt uitgevoerd in een doorgaans multidisciplinair samenwerkingsverband. Beheer vindt plaats op drie niveaus t.w. opdrachtbeheer, projectmanagement en de uitvoering. (Zie ook ‘Voorbeeld opzet handboek voor ICT-kwaliteit deel 3′.) Van belang m.b.t. het koppelvlak zijn een aantal aspecten:

• de opdracht, waarin resultaatbeschrijvingen, verantwoordelijkheden, bevoegdheden, budgettering, capaciteitsbehoeften en kwaliteitscontroles zijn geregeld;
• het projectplan, waarin een fasering, mijlpalen, rollen, activiteiten in de tijd en procedures zijn beschreven;
• de uitvoering op basis van een maximale uitnutting van beschikbare expertises en skills;
• de toetsing van de onderling op te leveren resultaten op plannen, standaards en normen.

Om de klant-leverancier relatie tussen de gebruikersorganisatie en de ICT-organisatie zuiver te houden, zal het budget voor ontwikkeling en wijziging toegewezen moeten worden aan de gebruikersorganisatie. Ook hierbij is het motto: ‘Wie betaalt, bepaalt en wie betaalt, bepaalt’. Uiteraard betekent dit wel, dat de kosten van de dienstverlening door de ICT-organisatie doorbelast dienen te worden. Indien de vraag van de gebruikersorganisatie de capaciteit van de ICT-organisatie te boven gaat, kan de ICT-organisatie aanvullende capaciteit inhuren.

Koppelvlak 2 en 3

Het projectresultaat dient na oplevering in stand gehouden te worden. Dat betekent dat vooraf de acceptatiecriteria gedefinieerd dienen te worden om zeker te stellen, dat het op te leveren resultaat voldoet aan de standaards en eisen (functioneel en technisch), die nodig zijn om een adequaat beheer in de productieomgeving mogelijk te maken. Uiteraard heeft dit ook betrekking op eisen m.b.t. de beveiliging. Hiertoe participeren functioneel en technisch beheerders doorgaans tijdig in het project.
Voor de oplevering zal door de beheerders getest worden of het resultaat aan de acceptatiecriteria voldoet. Is dit niet het geval, dan kan dit resultaat niet in productie genomen worden. Na acceptatie wordt het product overgedragen naar de beheerorganisatie belast met het beheer. Na een afgesproken garantieperiode van bijvoorbeeld drie maanden (nazorg) wordt het projectteam bij beide partijen gedechargeerd en zijn dan ook niet meer aanspreekbaar op eventuele tekortkomingen.

Koppelvlak 4

Belangrijke voorwaarde voor het in stand houden van de informatievoorziening is een adequate ICT infrastructuur. Op basis van de door de ICT-organisatie gespecificeerde dienstenportfolio wordt over de behoeften en eisen, die door de gebruikersorganisatie gesteld worden aan deze ICT-services en de kosten, die hiermee gemoeid zijn voor de ICT-organisatie, een service level agreement gesloten tussen de gebruikersorganisatie en de ICT-organisatie.
Meer over dit koppelvlak vindt u in het artikel ‘Inrichtingsmodel IT-beheer’. 

4.  Toepassingen van deze blauwdruk

Deze blauwdruk is bruikbaar om snel in kaart te brengen welke zaken wel en niet goed geregeld zijn tussen de gebruikersorganisatie en de ICT-organisatie. Een uitwerking van zo’n review uit de praktijk vindt u in het artikel ‘Review processen informatievoorziening praktijkvoorbeeld’.
Deze review kunt u zelf eenvoudig uitvoeren. Alleen als er sprake is van spanning tussen de gebruikers en de ICT-afdeling is het verstandig om dit uit te laten voeren door een externe partij zoals bijvoorbeeld ZBC, die dan tevens in staat is beide partijen bewust te maken van de mogelijkheden en onmogelijkheden in de relatie.
Vaak is het verstandiger om niet direct te streven naar een SLA, maar om eerst te proberen de samenwerking te verbeteren .(Zie ook ‘ITIL: professionalisering of indekken?’.) Als deze samenwerking eenmaal loopt, dan zijn ‘lean and mean’ afspraken mogelijk om ICT tot een efficiënt bedrijfsmiddel te maken.
Vaak is het verstandiger om niet direct te streven naar een SLA, maar om eerst te proberen de samenwerking te verbeteren.  Als deze samenwerking eenmaal loopt, dan zijn ‘lean and mean’ afspraken mogelijk om ICT tot een efficiënt bedrijfsmiddel te maken. Het is verstandig om bij de verbetering zelf de regie te houden en uit te gaan van uw eigen behoeften, want anders loopt u het risico dat u weer in een keurslijf geperst wordt, dat u niet past. (Zie ook ‘Groepstraining on the job: integratie functioneel en technisch beheer en applicatiebeheer’.)

Download:         

Gerelateerde artikelen:

1. Review processen informatievoorziening praktijkvoorbeeld
2. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1
3. Inrichtingsmodel IT-beheer

1. Functioneel beheer verschilt per bedrijf
2. Zelf het wiel uitvinden?
3. Cursus functioneel beheer, ICT- en applicatiebeheer
4. Mogelijke issues

1. Functioneel beheer verschilt per bedrijf

Op papier lijkt het zo gemakkelijk en aantrekkelijk: het functioneel beheer, ingericht volgens BiSL, als regisseur van de ICT-functie, zodat de bewaking van de eisen en wensen van gebruikers geborgd is en de ICT’ers zich verzekerd weten van sparringpartners die deskundig zijn en ook de belangen van de ICT begrijpen.
De praktijk is echter vaak weerbarstig. (Zie ook ‘Valkuilen functioneel beheer volgens BiSL’.) De ICT’ers hebben hun processen al lang ingericht volgens ITIL en ITIL sluit vaak allerminst aan op BiSL. De gebruiker heeft zijn plek zwaar bevochten en is niet bereid zijn bevoegdheden zomaar op te geven. Functioneel beheer volgens BiSL wordt hier maar wat tussen gefrommeld en dan vaak uitsluitend op operationeel niveau en het met elkaar in balans brengen van de methoden krijgt meestal geen prioriteit. (Zie ook ‘Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1′.)
De functioneel beheerder treedt vaak op als een leeuwentemmer zonder zweep; hij moet de leeuwen (gebruikers en ICT’ers) vriendelijk vragen om netjes hun kunstjes te doen. Als dan blijkt, dat de leeuwen in het verleden een grote aversie tegen elkaar hebben opgebouwd, dan wordt zijn hoofdtaak al gauw het uit elkaar houden van de vechtende partijen door vanaf twee kanten de klappen op te vangen. En daar de functioneel beheerders in de meeste organisaties toegewezen zijn aan afdelingen waar ze eigenlijk niet thuishoren, is hiërarchische escalatie van de problematiek ook zinloos; het management heeft tenslotte wel meer aan het hoofd. (Zie ook ‘Afbakening taken functioneel beheer baseren op behoefte’.)
Kortom, hoe je functioneel beheer soepel laat werken, verschilt per organisatie.

2. Zelf het wiel uitvinden?

Gelukkig is het probleem van maatwerk niet zo groot. Functioneel beheer is altijd nodig geweest, ook al wisten we vroeger nauwelijks dat het zo heette. Het was vaak een rol die per situatie ingevuld werd en daarom zijn er ervaringen genoeg met functioneel beheer.
Vijftien jaar geleden schreven we al over deze problematiek. (Zie ‘Blauwdruk processen IT-organisatie’.) We introduceerden het verhaal over de koppelvlakken tussen gebruikers en ICT en de koppelvlakken tussen ontwikkeling en in stand houden. En wat we nu functioneel beheer en functioneel applicatiebeheer noemen, zat toen in hoofdzaak vervlochten in de koppelvlakken.

Figuur 1: Koppelvlakken tussen gebruikers en ICT

De probleemstelling en de oplossingen zijn echter nog steeds hetzelfde. Het gaat er niet om waar de koppelvlakken precies liggen. Het gaat erom dat hierover goede afspraken gemaakt worden, waarbij de ervaringen van de betrokkenen maximaal benut worden. Een massale implementatie van ITIL of BiSL leidt alleen maar tot veel bureaucratie en dus irritatie.
Het model dat we destijds introduceerde voor de inrichting van ICT beheer (zie ‘Inrichtingsmodel IT-beheer’) is dan ook nog steeds bruikbaar; het probleem van functioneel beheer is immers nog steeds een probleem van communicatie, verantwoordelijkheden en bevoegdheden. Wel is het instrumentarium deels vernieuwd.
Op onze site vindt u de best practices van de organisatie van ICT van zeker 15 jaar en bekeken vanuit diverse invalshoeken (functioneel/technisch; strategisch/tactisch/operationeel; mate van volwassenheid), methodieken (ITIL/BiSL/ASL/Prince2/ SDM/RAD) en organisatiemodellen. Vrijwel al deze best practices zijn nog steeds uitstekend bruikbaar als je maar weet in welke situatie en in welke samenhang deze best practices het best gebruikt kunnen worden.
Het inrichten van functioneel beheer is dan ook vaak niet meer dan het kiezen van de goede en vooral ook passende bouwstenen. En dat begint niet bij de theorie van de methodiek, maar bij uw concrete behoefte en situatie.

3. Cursus functioneel beheer, ICT- en applicatiebeheer

Dat heeft uiteraard impact op de opleiding van de betrokkenen. Natuurlijk kunt u op zoek gaan naar een algemene cursus BiSL of een standaard cursus ‘Organisatie van ICT’. Wat in deze generieke cursussen geleerd wordt, sluit echter zelden aan bij uw specifieke situatie en behoefte. Het geleerde in de cursus kan veelal niet toegepast worden en dat leidt tot frustratie. Ook voor onze generieke cursus ‘Organisatie functioneel beheer en ICT-beheer’ voor middelgrote en kleinere organisaties’ bleek dit te gelden.
Daarom komen we nu met een bedrijfsspecifieke aanpak. We hebben het totale beheerlandschap in kaart gebracht. In een workshop van enkele uren met de opdrachtgever of de contactpersonen van de klant presenteren we het totale landschap en bepalen dan samen welke best practices passen op de betreffende organisatie, eventueel opgesplitst naar doelgroepen. Dit worden de opleidingsmodules. Het geleerde kan desgewenst direct vastgelegd worden in standaards en procedures, maar dat is de interne keuze en de interne activiteit van de organisatie. Wel kunnen wij een dergelijk traject coachen.

3.1 Doel en afbakening

Kort gezegd gaat het om het op een pragmatische manier effectiever en efficiënter organiseren van de processen rond ICT. De totale levenscyclus omvat:

• behoeftebepaling,
• planvorming,
• aanschaf of ontwikkeling,
• implementatie,
• functioneel en technisch (applicatie)beheer.

Het grootste deel hiervan heeft u op orde, dus daar hoeven we ons niet druk om te maken. Het traject start daarom met een kort voorgesprek waarin twee aspecten aan de orde komen:

• De contactpersoon of opdrachtgever geeft aan welke problemen er zijn en wat de behoeften zijn.
• Wij laten vervolgens zien welke best practices we hiervoor hebben ontwikkeld en wat we dus voor u kunnen betekenen.

Als u een globaal beeld wilt krijgen van hoe die landkaart eruit kan zien, dan nodigen we u graag uit voor ons webseminar ‘Organisatie ICT-beheer voor middelgrote organisaties’.

3.2 Aanpak en uitvoering groepstraining-on-the-job

Onze aanpak voor groepstraining-on-the-job is als volgt.

• Per opleidingsmodule wordt een ‘probleemeigenaar’ aangewezen. Deze probleemeigenaar heeft belang bij de oplossing en de bevoegdheden om hierover afspraken te maken met andere betrokkenen. Dit kan een ICT-manager zijn, een functioneel beheerder of een lijnmanager. Met deze probleemeigenaar worden afspraken gemaakt over de te realiseren doelen.
• In een workshop van één of twee dagdelen wordt het onderwerp behandeld, worden best practices aangereikt en keuzes gemaakt, waarbij afspraken gemaakt wordt over de rollen van alle betrokkenen.
• Met de probleemeigenaar worden de uitkomsten geëvalueerd en wordt afgesproken hoe we de resultaten in concrete acties en een actieplan kunnen vertalen.
• De acties worden intern uitgevoerd en vervolgens door de probleemeigenaar geconsolideerd.

Uiteraard kunnen we coaching bieden bij het uitvoeren van de acties, veelal door het leveren van sjablonen of door het uitvoeren van reviews. Deze coaching vindt meestal op afstand plaats.

3.3 Evaluatie en beheersing

Periodiek is er een afstemmingsgesprek met de contactpersoon of opdrachtgever, waarin de resultaten besproken worden en vervolgafspraken worden gemaakt.
De onderwerpen worden vooraf goedgekeurd door de contactpersoon of opdrachtgever. Hetzelfde geldt voor het afgesproken actieplan.

3.4 Condities en randvoorwaarden

Tarieven:

• Werkzaamheden bij u op locatie: € 125,-
• Werkzaamheden op locatie van ZBC: € 110,-
• Het voorgesprek is gratis.

Omdat alle werkzaamheden op afspraak en afroep plaatsvinden (nul uren contract), is dit traject voor u gemakkelijk te beheersen. In de praktijk hebben deze trajecten 4 uur tot 8 weken in beslag genomen.

3.5 Meer weten

Is uw ICT-dienstverlening verder dan ‘het onmogelijke doen we direct; wonderen duren iets langer maar we beloven niets’, maar nog niet vastgeroest in procedures, dan past deze opleiding waarschijnlijk goed bij u. Wilt u meer weten over onze groepstraining-on-the-job, dan kunt u bellen met 0318 641 898 of reageren via het reactieformulier.

3.6 Case study

Een voorbeeld van een dergelijk traject kunt u lezen in Casestudy Training Outsourcing werkplekbeheer

4. Bijlage: Mogelijke issues

In principe komen alle onderwerpen in onze ICT-kennisbank in aanmerking voor de groepstraining-on-the-job. Voor de hand liggende onderwerpen kunnen zijn:

Blauwdruk processen IT-organisatie

Een beschrijving van de proces architectuur van een IT-organisatie in relatie tot haar omgeving.

Voorbeeld opzet handboek voor ICT kwaliteit deel 1 (2 en 3)

Dit praktijkvoorbeeld van een kwaliteitshandboek publiceren wij in drie delen. Het handboek is uitstekend te combineren met een watervalmethode voor systeemontwikkeling en dus met outsourcing, met Prince 2 en met ITIL.

ICT en functioneel beheer steeds meer logistieke processen

Als ICT niet je core business is, moet je niet eens willen investeren in functioneel beheer en ICT-beheer of in hardware of software. Het is gewoon een facilitaire dienst zoals schoonmaak, vervoer, catering of security dat ook zijn. Dat doe je ook niet zelf.

Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1

Beschrijving van knelpunten, oplossingen en alternatieven als deze drie frameworks (BiSL, ASL en ITIL) naast elkaar geïmplementeerd worden.

Functioneel beheer en inkoop vaak bottlenecks in de ICT-leveringsketens

ICT  is mateloos complex geworden. Als ICT niet je core business is, moet je ICT dan ook uitbesteden aan partijen voor wie de beheersing van complexiteit dagelijks werk is. Pas dan krijgen ook gebruikers in middelgrote organisaties de service die ze verdienen.

ICT-service management: contact is belangrijker dan contract

De gemiddelde service manager is meestal een goed opgeleide en goed gebekte techneut, die zich niet laat  ondersneeuwen door gebruikers en business managers. Als het echter de intentie van de ICT-afdeling is haar klanten tevreden te stellen, dan zijn andere vaardigheden nodig.

Inrichtingsmodel IT-beheer

Hoe ITIL te implementeren voor een betrouwbare en flexibele IT-dienstverlening, gebruik makend van moderne bedrijfskundige principes en zonder te verzanden in een bureaucratie.

Besparingen door gebruik van professionele Service Level Agreements – SLA’ s

Beter goed gejat dan slecht verzonnen; dit geldt zeker bij het opstellen van een SLA. De meeste checklists zijn gemaakt voor complexe omgevingen en opgebouwd uit meerdere Service Level Agreements en geven veel overhead. In dit artikel meer over de valkuilen van deze werkwijze.

Valkuilen functioneel beheer volgens BiSL

Functioneel beheerders zijn niet te benijden. Ze heten de regisseurs van de informatievoorziening te zijn, maar dat geldt alleen in het weekend, als business en ICT er niet zijn. Ook BiSL is niet het gewenste breekijzer. Het is gebaseerd op een aantal aannames die in de praktijk vaak onjuist blijken te zijn.

Projectinrichting en opdrachtbeheer

De basis voor een gezond project is een goede samenwerking. Voorwaarde hiervoor is helderheid over de rollen, die vervuld moeten worden en de hierbij horende verantwoordelijkheden en bevoegdheden.

Opdrachttypen voor projecten

Afhankelijk van de fase, waarin een project verkeert, is er een andere verdeling van verantwoordelijkheden en bevoegdheden nodig. Via gedefinieerde opdrachttypen is dit eenvoudig te realiseren.

Waarom veel organisaties niet met projecten kunnen omgaan

Projectmatig werken is zo gewoon geworden, dat we eigenlijk niet eens meer nadenken over hoe we het moeten doen en vooral niet over waarom we het zouden moeten doen. In dit artikel meer over het hoe en waarom van projectmatig werken, over de rol van de projectmanager en over de verdeling van verantwoordelijkheden en bevoegdheden, zodanig dat projectmatig werken beheersbaar blijft.

Kwantitatieve risicoanalyse IT-projecten

U weet ongetwijfeld dat veel projecten de mist ingaan. Vaak is dit een kwestie van opportunisme, waarbij risico’s vanwege het ’superieure team’ gebagatelliseerd worden. Natuurlijk is de kwaliteit van mensen van belang. Maar het invullen van de randvoorwaarden voor het project levert toch meer garantie voor succes. In dit artikel meer over de uitvoering van een kwantitatieve IT-project risicoanalyse.

Selectie leverancier voor outsourcing werkplekbeheer

Vaak wordt de selectie van een leverancier voor outsourcing van werkplekbeheer gedaan aan de hand van een waslijst aan eisen en wensen. Van veel daarvan zou u zich moeten afvragen wat de toegevoegde waarde ervan is. U kunt daarom beter kiezen voor een beperkt aantal knock-out criteria die er werkelijk toe doen.

Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen

Voor de meeste ICT-organisaties is het niet rendabel om zelf over ICT-competenties en infrastructuur te beschikken. Outsourcing met als doel het just-in-time inkopen van dergelijke diensten geeft de gebruiker vaak een veel betere prijs-prestatieverhouding.

Recessie dwingt ICT-bedrijven tot herziening SWOT-analyse

Iedere bedreiging is tevens een kans. Dat geldt zeker in 2009, nu niet alleen de technologie zich ontwikkelt, maar vooral ook de markt verandert.

Download:         

Gerelateerde artikelen:

1. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 2
2. Integratie ITIL, ASL en BiSL is noodzaak of niet doen deel 1
3. BiSL maakt functioneel beheer wel erg ingewikkeld

1. Inleiding vierluik PSI
2. Inleiding pakketselectie en -implementatiemethode
3. Checklist per activiteit 

1. Inleiding vierluik PSI

In vier delen publiceren wij een methodiek voor een complexe pakketselectie en -implementatie, aangevuld met een checklist. Deze methode is primair geschreven voor de externe projectleider, maar is zeker in combinatie met de checklist ook toepasbaar voor intern gebruik.

De methode is gemaakt voor omvangrijke trajecten, waarbij sprake is van aanvullend maatwerk en integratie met andere systemen, die ook deels maatwerk zijn. Schroomt u dus niet om activiteiten te schrappen, maar checkt u wel of daarmee geen belangrijke controles verloren gaan, ook al vergt de uitvoering daarvan maar enkele minuten.

Dit handboek sluit goed aan op Voorbeeld opzet handboek voor ICT kwaliteit deel 1 (2 en 3).

De opbouw van de delen is als volgt:

• Deel 1 omvat de inleiding en het vooronderzoek
• Deel 2 omvat de pakketselectie en het functioneel ontwerp 
• Deel 3 omvat de pakketimplementatie
• Deel 4 omvat de checklist per activiteit 

2. Inleiding pakketselectie en -implementatie methode

De pakketselectie en -implementatie methode (PSI) verdeelt een project waarmee een pakket wordt geselecteerd en geïmplementeerd in een aantal fasen, die op hun beurt weer verder onderverdeeld zijn in respectievelijk taken en activiteiten. Bovendien zijn beslis- en rapportage momenten gedefinieerd. Dit handboek geeft op globaal niveau aan hoe het selectie- en implementatietraject opgedeeld wordt in fasen, taken en activiteiten en is met name bestemd voor degenen die de selectie en implementatie daadwerkelijk uitvoeren.

In deel 1 van dit handboek werd allereerst ingegaan op de fasering van het totale selectie- en implementatietraject. Vervolgens werd iedere fase met bijbehorende taken kort beschreven. De nadruk lag hierbij op het doel en de belangrijkste resultaten van de taak. Daarna werd het vooronderzoek beschreven. In de delen 2 en 3 werd dieper ingegaan op de afzonderlijke volgende fasen. Deel 4 bevat de checklist per activiteit. 

3. Checklist per activiteit

Act. Nr.	Act. naam	Taaknaam
1.01	Opstellenprojectkwaliteitsplan	Opstellen projectkwaliteitsplan Afstemmen projectkwaliteitsplan Afronden projectkwaliteitsplan Verkrijgen formele goedkeuring voor projectkwaliteitsplan
1.02	Bepalen systeem-eisen en -wensen	Analyseren bedrijfsdoelstellingen Definiëren basissysteemeisen Definiëren interface-eisen Definiëren autorisatie-eisen Definiëren performance- eisen Definiëren operationele eisen Consolideren systeemeisen en -wensen Review gebruikers acceptatiecriteria Afronden systeemeisen en -wensen
1.03	Analyserenhuidige systemen	Review huidige systeemdoelstellingen Opstellen huidig gegevensmodel Opstellen huidig procesmodel Beschrijven huidige interfaces Beschrijven gebruikerstaken Beoordelen huidige operationele kenmerken van het systeem Afronden huidig systeemmodel
1.04	Analyserenhuidige organisatie	Review huidige bedrijfsdoelstellingen Beschrijven organisatiestructuur Analyseren bedrijfsfuncties Analyseren bedrijfsverantwoordelijkheden Analyseren operationele kosten Inschatten potentiële organisatiewijzigingen
1.05	Samenstellenshortlist	Opstellen geografisch systeemoverzicht Samenstellen longlist Samenstellen verzoek voor informatie Samenstellen evaluatiecriteria van leverancier Verzoek leverancier pakketinformatie Definiëren teststrategie Evalueren response van leveranciers Formuleren van de shortlist Afronden shortlist

 

Download:         

Gerelateerde artikelen:

1. Methode en checklist pakketselectie en -implementatie deel 3
2. Methode en checklist pakketselectie en -implementatie deel 2
3. Methode en checklist pakketselectie en -implementatie deel 1

1. Inleiding vierluik PSI
2. Inleiding pakketselectie en -implementatiemethode
3. Fase 4. Technisch Ontwerp
4. Fase 5. Bouw
5. Fase 6. Testen
6. Fase 7. Invoeren 

1. Inleiding vierluik PSI

In vier delen publiceren wij een methodiek voor een complexe pakketselectie en -implementatie, aangevuld met een checklist. Deze methode is primair geschreven voor de externe projectleider, maar is zeker in combinatie met de checklist ook toepasbaar voor intern gebruik.

De methode is gemaakt voor omvangrijke trajecten, waarbij sprake is van aanvullend maatwerk en integratie met andere systemen, die ook deels maatwerk zijn. Schroomt u dus niet om activiteiten te schrappen, maar checkt u wel of daarmee geen belangrijke controles verloren gaan, ook al vergt de uitvoering daarvan maar enkele minuten.

Dit handboek sluit goed aan op Voorbeeld opzet handboek voor ICT kwaliteit deel 1 (2 en 3).

De opbouw van de delen is als volgt:

• Deel 1 omvat de inleiding en het vooronderzoek
• Deel 2 omvat de pakketselectie en het functioneel ontwerp 
• Deel 3 omvat de pakketimplementatie
• Deel 4 omvat de checklist per activiteit 

2. Inleiding pakketselectie en -implementatie methode

De pakketselectie en -implementatie methode (PSI) verdeelt een project waarmee een pakket wordt geselecteerd en geïmplementeerd in een aantal fasen, die op hun beurt weer verder onderverdeeld zijn in respectievelijk taken en activiteiten. Bovendien zijn beslis- en rapportage momenten gedefinieerd. Dit handboek geeft op globaal niveau aan hoe het selectie- en implementatietraject opgedeeld wordt in fasen, taken en activiteiten en is met name bestemd voor degenen die de selectie en implementatie daadwerkelijk uitvoeren.

In deel 1 van dit handboek werd allereerst ingegaan op de fasering van het totale selectie- en implementatietraject. Vervolgens werd iedere fase met bijbehorende taken kort beschreven. De nadruk lag hierbij op het doel en de belangrijkste resultaten van de taak. Daarna werd het vooronderzoek beschreven.
Vanaf deel 2 wordt dieper ingegaan op de afzonderlijke volgende fasen. 

3. Fase 4. Technisch Ontwerp

De doelstelling van het technisch ontwerp is het opleveren van technische specificaties voor het bouwen en testen van de pakketmodificaties en -uitbreidingen en voor wijzigingen in andere systemen.

In de technisch ontwerp fase worden de functionele specificaties vertaald naar technische specificaties. Deze specificaties vormen de basis voor de bouw- en testfase. Prototyping kan in deze fase gebruikt worden voor het demonstreren van de technische mogelijkheden, kenmerken en ontwerpen. In deze fase worden ook de systeem- en acceptatietestplannen en testspecificaties opgesteld. Ter voorbereiding op het in productie nemen van het systeem wordt een invoeringsplan opgesteld en worden handmatige procedures en trainingen gespecificeerd. Alle op te leveren producten uit deze fase worden getoetst op onder andere volledigheid, consistentie en haalbaarheid. De resultaten van deze fase worden vastgelegd in het technisch ontwerp rapport.

Figuur 7: Fase Technisch ontwerp

De verplichte taken zijn:

• bijwerken projectkwaliteitsplan (4.01);
• opstellen technische pakketspecificaties (4.02);
• ontwikkelen invoeringsplan (4.03);
• plannen en specificeren systeemtesten (4.04);
• controleren technisch ontwerp (4.05);
• plannen en specificeren acceptatietesten (4.06).

De belangrijkste producten die in deze fase technisch ontwerp worden opgeleverd zijn:

• bijgewerkt projectkwaliteitsplan;
• gedetailleerd technisch ontwerp voor pakket en maatwerk;
• testplannen en specificaties;
• invoeringsplan.

Taak 4.01 Bijwerken projectkwaliteitsplan

Binnen deze taak wordt het projectkwaliteitsplan nader gedetailleerd voor de fase technisch ontwerp.
Het uitgangspunt voor deze fase is een goedgekeurd functioneel ontwerp. Hiervan moeten de volledigheid en de consistentie worden vastgesteld. Tevens dient een technische omgeving beschikbaar te zijn ter ondersteuning van het opstellen van de technische specificaties. Binnen de gekozen aanpak worden vervolgens de uit te voeren taken bepaald, alsmede volgorde hiervan en de resources die erbij betrokken zijn.
In het projectkwaliteitsplan wordt tevens vastgelegd welke standaards, procedures, technieken en hulpmiddelen gebruikt worden bij het technisch ontwerp.

Taak 4.02 Opstellen technische pakketspecificaties

De functionele specificaties van de pakketwijzigingen (taak 3.03) worden in deze taak vertaald naar technische specificaties. De eerste taak die hierbij wordt uitgevoerd is het beoordelen van de technische architectuur en het procesmodel en het verfijnen hiervan op basis van de functionele specificaties. Hierbij wordt op basis van de hard/software configuratie aangegeven op welke wijze de pakketwijzigingen of -uitbreidingen worden ondergebracht en hoe de relatie is van het pakket met de maatwerkontwikkelingen.

Tegelijkertijd wordt het functionele datamodel omgezet in een technisch datamodel, dat is toegespitst op de file of het database management systeem van het pakket.

De netwerkarchitectuur en de ondersteunende processen worden beoordeeld en zonodig aangepast om de communicatie te realiseren en eventuele bottlenecks te signaleren.

De autorisatie- en beveiligingsfaciliteiten worden ingericht en zonodig uitgebreid.

Tenslotte wordt in het technisch ontwerp aandacht besteed aan het ontwerpen van de interfaces met betrekking tot de systeem software utilities en systeem- en userinterfaces.

Taak 4.03 Opstellen gedetailleerde technische specificaties

De gedetailleerde functionele specificaties voor de additionele functionaliteit (uit taak 3.04) worden in deze taak vertaald naar technische specificaties. De activiteiten die binnen deze tak worden uitgevoerd zijn gelijk aan die van taak 4.02 ‘Opstellen technische pakketspecificatie’, met dien verstande dat hierbij het zwaartepunt ligt op het realiseren van additionele functionaliteit op het pakket.

Taak 4.04 Ontwikkelen invoeringsplan

In het invoeringsplan wordt het proces beschreven voor de overgang naar het nieuwe systeem. Bij het opstellen van het plan dient rekening te worden gehouden met de synchrone activiteiten voor wijzigingen in andere systemen, voor data conversie, voor organisatiewijzigingen en voor training.

Ook worden de volgende aspecten in ogenschouw genomen:

• aanpassingsvermogen van de gebruikerorganisatie;
• gevolgen voor de gebruikers in de tweede lijn;
• tijdelijke beperkingen en overbruggingen;
• mogelijke herinstallatie van het oude systeem;
• opslag en archivering van de oude systeemgegevens.

Voor het opstellen van het invoeringsplan worden de volgende activiteiten uitgevoerd:

• opstellen van een definitieve aankooplijst voor hard- en software;
• beschrijving van het overgangsproces;
• bepalen van de hardware-, software- en pakketinstallatie;
• verwerken van het conversieplan;
• opstellen van procedures en verantwoordelijkheden;
• verwerken van een trainingsplan;
• uitwerken van applicatiebeheer, gegevensbeheer en technisch beheer.

Taak 4.05 Plannen en specificeren systeemtesten

Uitvoering van de systeemtesten houdt onder andere in:

• uitgebreide functionele test (over de verschillende functiegebieden heen);
• test van complexe transactievolgorde (tijdsaspect);
• test van gedistribueerde functies en data;
• presentatie van alle uitzonderingscondities die in het ontwerp zijn voorzien;
• volumetest (data en transacties);
• stress test (piekverweking);
• security test (beveiliging programmatuur en gegevens);
• performance test (responsetijden);
• storage test (intern en extern geheugengebruik);
• configuratie test;
• compatibility/ conversion test ( aansluiten van nieuw systeem op het bestaande);
• reliability test (betrouwbaarheid van het systeem);
• recovery test (technische onderhoudbaarheid);
• documentation test (beoordelen en accepteren technische documentatie);
• proceduretest.

De systeemtest heeft betrekking op het gebruik en het beheer van het pakket, de pakketuitbreidingen en -wijzigingen, de interfaces en de wijzigingen in ander systemen.

Het plan van de systeemtest omvat de testaanpak, de hulpmiddelen die daarbij worden gebruikt, de aandachtsgebieden en de wijze waarop de resultaten moeten worden gedocumenteerd. De specificaties omvatten de doelstelling van de systeemtest, het afbakenen van het testgebied en van de specifieke onderdelen die worden getoetst en het vaststellen van de succes- en afbreukcriteria. Hiertoe wordt een testscript opgesteld en worden de testdata bepaald. Ook worden de afhankelijkheden tussen de verschillende testen vastgelegd. In het plan is ook aangegeven wie betrokken worden bij de uitvoering van de systeemtest. Dit zijn in principe medewerkers van het projectteam.

Taak 4.06 Specificeren wijzigingen andere systemen

De functionele specificaties voor de wijzigingen in andere systemen en interfaces ( taak 3.05 ) worden in deze taak vertaald naar technische specificaties. De activiteiten die binnen deze taak worden uitgevoerd zijn gelijk aan die van een technisch ontwerptraject voor maatwerk ontwikkeling.

Taak 4.07 Specificeren handmatige procedures

In deze  taak worden de procedures gespecificeerd die niet door het geautomatiseerde proces worden verzorgd. De handmatige procedures hebben enerzijds betrekking op het systeemgebruik en anderzijds op het systeembeheer.

Taak 4.08 Controleren technisch ontwerp

De controle van het technisch ontwerp is noodzakelijk om vast te stellen of het ontwerp een goede basis biedt voor de verder ontwikkeling van het systeem. Hierbij wordt aandacht besteed aan de volgende zaken:

• controleren of het technisch ontwerp aan de eisen uit het functioneel ontwerp voldoet, waarbij aandacht wordt besteed aan de achterhaalbaarheid, volledigheid en consistentie;
• de mogelijke conflicten tussen test- en invoeringsplan, gerelateerd aan organisatiewijzigingen, wijzigingen in andere systemen, dataconversie, training enzovoort;
• technisch haalbaarheid in termen van architectuur, data- en procesmodellen, netwerken, interfaces, performance enzovoort;
• operationele haalbaarheid in termen van organisatie, commitment aan de oplossing, trainingsfaciliteiten enzovoort;
• economische haalbaarheid (in het bijzonder de verwachte kosten/ baten en de balans tussen enerzijds pakket en anderzijds pakketwijzigingen en ander modificaties).

Na controle van het technisch ontwerp wordt dit ter goedkeuring aan de opdrachtgever voorgelegd.

Taak 4.09 Plannen en specificeren acceptatietesten

De doelstellingen van de acceptatietest zijn:

• toetsen of het gerealiseerde systeem aan de acceptatiecriteria voldoet;
• kennismaken met het systeem en de gebruiker vertrouwen geven dat het systeem werkbaar is voor de toekomstige situatie, in samenhang met de administratieve procedures en andere informatiesystemen;
• toetsen van de juistheid en bruikbaarheid van de handleidingen.

Het plan van de acceptatietest omvat de testaanpak, de hulpmiddelen die daarbij worden gebruikt, de aandachtsgebieden en de wijze waarop de resultaten moeten worden gedocumenteerd.

De specificaties omvatten de doelstelling van de acceptatietest, het afbakenen van het testgebied, de specifieke onderdelen die worden getoetst en het vaststellen van de succes- en afbreukcriteria. Hiertoe worden een testscript opgesteld en de testdata bepaald. Ook worden de afhankelijkheden tussen de verschillende testen vastgelegd. In het plan wordt ook aangegeven wie betrokken worden bij de uitvoering van de acceptatietest. Dit zijn in principe alle disciplines die in de toekomst gebruik gaan maken van het systeem.

Taak 4.10 Specificeren dataconversie tools

Deze taak omvat het opstellen van een technisch ontwerp voor software, van procedures en testen voor het ondersteunen van het dataconversieproces en voor het testen van de juistheid van de geconverteerde data. De basis hiervoor is aangegeven in het conversieplan (taak 3.09).

Bij de specificatie van dataconversie tools wordt er naar gestreefd het ontwerp aan te laten sluiten bij de ontwerpfilosofie van het pakket. Naast de specificaties van de conversie tools wordt ook een inschatting gemaakt van verwachte run tijden en data volumes. Tevens wordt aandacht besteed aan de herstartbaarheid van de conversieprocessen.

Taak 4.11 Specificeren training

Op basis van het trainingsplan (taak 3.10) worden in deze taak de specificaties van de training nader uitgewerkt. Activiteiten zijn: het specificeren van de trainingmodules, van de documentatie, van de faciliteiten en van het trainingtestplan. 

4. Fase 5. Bouw

De doelstellingen van deze fase zijn:

• realiseren van alle operationele systeemprocessen voor zowel de pakketuitbreidingen en -wijzigingen als ook voor de additionele functionaliteit en de wijzigingen in andere systemen;
• uitvoeren van de afzonderlijke testen;
• ontwikkelen conversie tools en trainingsmateriaal;
• ontwikkelen invoeringsprocedures;
• testen van de pakketuitbreidingen en -wijzigingen die door de pakketleverancier zijn aangebracht.

In de bouwfase worden de  gedetailleerde technische specificaties omgezet naar operationele programma’s en data. Elke opgeleverde eenheid wordt afzonderlijk getest.

Daarnaast worden de systeemhandleidingen gemaakt, de handmatige procedures afgerond en het trainingsmateriaal ontwikkeld.

De verplichte taken in deze fase zijn:

• bijwerken projectkwaliteitsplan (5.01);
• specificeren pakketwijzigingen (5.02);
• inrichten ontwikkelomgeving (5.05);
• ontwikkelen pakketwijzigingen (5.06);
• ontwikkelen invoeringsprocedures (5.10);
• testen pakket (5.11).

Indien wijzigingen en / of uitbreiding in het pakket of in andere systemen zijn voorzien, worden de betreffende taken opgenomen.

De belangrijkste producten die in deze fase worden opgeleverd zijn:

• bijgewerkt projectkwaliteitsplan;
• invoeringsprocedures;
• specificaties en gerealiseerde pakketwijzigingen;
• resultaten van de hertest.

Uitvoering van de overige taken is afhankelijk van de projectsituatie.

Figuur 8: Bouw

Taak 5.01 Bijwerken projectkwaliteitsplan

Binnen deze taak wordt het projectkwaliteitsplan nader gedetailleerd voor de fase bouw. Hierbij wordt speciale aandacht besteed aan  programmeerstandaards, technieken, hulpmiddelen en aan de inrichting van de verschillende omgevingen.

Taak 5.02  Specificeren pakketwijzigingen

In deze taak worden op basis van de technische specificaties van de pakketwijzigingen (taak 4.02) de programma- en testspecificaties opgesteld. De stijl van het structureren van de programma’s en testen moet consistent zijn met de standaard van het pakket. De uitvoering van de taak is verder conform het traditionele bouwproces dat behoort bij de betreffende omgeving. In verband met toekomstige releasewisselingen van het pakket is het noodzakelijk de wijzigingen in het pakket te herkennen. Dit vereist speciale procedures.

Taak 5.03 Plannen en specificeren integratietesten

De integratietest heeft betrekking op de relatie tussen het pakket en zijn uitbreiding / wijzigingen.

Het plan van de integratietest omvat de testaanpak, de hulpmiddelen die daarbij worden gebruikt, de aandachtsgebieden en de wijze waarop de resultaten moeten worden gedocumenteerd.

De specificatie omvat de doelstelling van de integratietest, het afbakenen van het testgebied, de specifieke onderdelen die moeten worden getoetst en het vaststellen van de succes- en afbreukcriteria. Hiertoe wordt een testscript opgesteld en worden de testdata bepaald. Ook worden de afhankelijkheden tussen de verschillende testen vastgelegd.

Taak 5.04 Opzetten systeemhandleidingen

De set van handleidingen is gericht op het gebruik en het beheer van het systeem en kan de volgende elementen omvatten:

• een systeemoverzicht;
• de gebruikershandleiding voor het gebruik van het systeem;
• de operators manual voor het technisch beheer van het systeem;
• online- helpfaciliteiten.

Taak 5.05 Inrichten ontwikkelomgeving

Deze taak omvat het inrichten en het beheren van een omgeving voor het uitvoeren van de bouwactiviteiten aan het pakket en andere systemen. Hierbij wordt aandacht besteed aan het creëren van een fysieke werkomgeving, aan het installeren en beheren van hardware en software en aan het inrichten en beheren van de ontwikkelingsomgeving.

Taak 5.06 Ontwikkeling pakketwijzigingen

Deze taak omvat het programmeren en testen in het pakket, op basis van de programmaspecificaties voor de pakketwijzigingen die zijn opgesteld in taak 5.02.

Taak 5.07 Specificeren programma’s

Op basis van de gedetailleerde technische specificaties voor additionele functionaliteit ( taak 4.03  ) worden in deze taak de programma- en testspecificaties opgesteld.

Taak 5.08 Wijzigen andere systemen

Binnen deze taak worden de programmaspecificaties opgesteld en uitgewerkt voor de gewijzigde interfaces en de wijzigingen in andere systemen, die het gevolg zijn van de pakketimplementatie. Ook hierbij wordt het klassieke bouwtraject gevolgd. De specificaties voor de wijzigingen in andere systemen zijn opgesteld in taak 4.06.

Taak 5.09 Ontwikkelen handmatige procedures

Deze taak omvat het ontwikkelen van handmatige procedures voor het beheer en het gebruik van het systeem, op basis van de specificaties die in taak 4.07 zijn gegenereerd.

Taak 5.10 Ontwikkelen invoeringsprocedures

Deze taak omvat het in detail uitwerken van de invoeringsprocedures zoals beschreven in taak 4.04 ‘Ontwikkelen invoeringsplan’. Hierbij moet rekening worden gehouden met de volgende aspecten:

• aflevering en installatie van de hardware, pakket en aanpassingen / uitbreidingen;
• configuratie van de technische installatie;
• tijdelijke overbruggingen tussen oude en nieuwe systemen;
• dataconversie en het creëren van nieuwe databases;
• gebruikerstraining;
• multi-site synchronisatie;
• afsluiten oude systeem;
• beveiligingsmechanismen;
• back-up en recovery;
• uitwijkscenario.

Als de invoering van het nieuwe systeem in verschillende fasen wordt uitgevoerd, worden voor elke fase de bovengenoemde aspecten beschreven.

Taak 5.11 Hertesten pakket

De doelstelling van deze taak is het afsluiten van het testtraject voor het pakket met de aangebracht pakketwijzigingen. Hierbij wordt met name aandacht besteed aan de wijzigingen en de invloed die de wijzigingen hebben op het pakket. In deze test worden de additioneel gerealiseerde functionaliteit en de wijzigingen in andere systemen buiten beschouwing gelaten. Het plan voor uitvoering is grotendeels analoog aan het plan voor testen van het pakket ( taak 2.05 ), met dien verstande dat speciale aandacht wordt besteed aan de pakketwijzigingen.

Taak 5.12 Ontwikkel integratietestprogrammatuur

De in taak 5.07 gespecificeerde software en de testdatabase om het pakket in samenhang met de omgeving te testen, wordt nu gebouwd nadat in taak 5.11 is vastgesteld, dat het pakket zelf correct werkt.

Taak 5.13 Ontwikkelen dataconversietools

De doelstelling van deze taak is het ontwikkelen en testen van conversieprogrammatuur op basis van de specificaties uit taak 4.10. Hiervoor kan speciaal programmatuur worden ontwikkeld of kan gebruik worden gemaakt van systeem utilities of van aanpassing van bestaande interfaces.

Taak 5.14 Ontwikkelen trainingsmateriaal

Deze taak omvat het genereren en testen van alle trainingsmaterialen, zoals visuele hulpmiddelen, hand-outs, zelfstudiemateriaal, casestudies, voorbeelden, evaluatieformulieren, coachrichtlijnen enzovoort. Er worden trainingen opgezet voor het gebruik en het beheer van het systeem, voor het conversieproces en voor de training zelf. De specificaties voor de ontwikkeling van het trainingsmateriaal zijn gegenereerd in taak 4.11. 

5. Fase 6. Testen

De doelstelling van deze fase is het pakket in een dusdanige staat van gereedheid te brengen dat het projectteam het vertrouwen krijgt dat het pakket met zijn wijzigingen en uitbreidingen, en de systemen die in relatie staan met het pakket, voldoen aan de gestelde eisen en wensen.
Binnen deze fase worden de systeem- en integratietesten uitgevoerd. In de teststrategie is de basis voor het testen vastgelegd ( taak 3.08 ) In de planning en in de specificaties voor het testen ( taken 4.05 en 5.03 ) is deze verder uitgewerkt. Fouten die tijdens de testen naar voren komen, worden in deze fase opgelost.

De resultaten van de systeem- en integratietesten kunnen gevolgen hebben voor het invoeringsplan. Indien dit het geval is, worden ze verwerkt in het plan.

Er zijn twee verplichte taken in deze fase, te weten:

• Inrichten testomgevingen (6.01);
• Uitvoeren systeemtesten (6.02).

De bovenstaande taken leveren respectievelijk een systeemtestrapport en een integratietestrapport op. De uitvoering van de integratietesten is afhankelijk van de aangebrachte pakketwijzigingen en -uitbreidingen.

Figuur 9: Testen

Taak 6.01 Inrichten testomgevingen

Deze taak voorziet in het inrichten van een omgeving voor het testen van het nieuwe systeem ( pakket en wijzigingen en uitbreidingen ) en zijn externe interfaces en van wijzigingen in ander systemen.
Hierbij wordt aandacht besteed aan het creëren van een fysieke werkomgeving, aan het installeren en beheren van testhardware en -software, aan het inrichten en beheren van de testomgeving en aan het definiëren en installeren van gebruikersprocedures en operationele procedures.

Systeemtesten zijn per definitie bedoeld om de juiste werking van het complete systeem te demonstreren. Dit houdt in een demonstratie van de gerealiseerde functionele specificaties, van de technische specificaties, van de gebruikershandleiding, van de operators handleiding, en van de operationele omgeving en de acceptatiecriteria.

Tijdens de systeemtesten kunnen de verschillende aspecten parallel worden getest. Bij het optreden van fouten worden de consequenties met grote zorg geëvalueerd.

Uitvoeren van de systeemtest omvat de volgende activiteiten:

• genereren van testdata;
• uitvoeren van de systeemtest volgens de voorgeschreven testspecificaties (taak 5.03);
• analyseren van testresultaten;
• uitvoeren van correctieve acties;
• opstellen van het integratietestrapport.
   

6. Fase 7. Invoeren

De doelstellingen van deze fase zijn:

• verkrijgen van systeem- en projectacceptatie;
• vullen van het systeem met operationele data;
• beschikbaar stellen van de applicatie voor beheer en gebruik;
• in gebruik nemen van de applicatie door de gebruikers;
• projectteam dechargeren van verantwoordelijkheden.

De invoering vindt plaats in drie stadia, te weten:

• ten eerste:
  De acceptatietest wordt uitgevoerd in een omgeving die zo goed mogelijk aansluit bij de toekomstige productieomgeving. Parallel daaraan kunnen de dataconversie en training plaatsvinden.
• ten tweede:
  Het productiesysteem wordt geïnstalleerd en alle benodigde hardware, software en gegevens zijn gereed om in productie te nemen.
• ten derde:
  Gebruikers en beheerders gaan over naar het nieuwe systeem, waarbij de overdracht van het projectteam naar beheer plaatsvindt.

Figuur 10: Invoeren

De invoering van het nieuwe systeem vindt plaats op basis van het invoeringsplan dat is opgesteld in taak 4.04. Binnen deze fase moet een formele acceptatie verkregen worden van de opdrachtgever. Deze acceptatie kan in diverse stappen plaatsvinden, bijvoorbeeld na de acceptatietest, na de invoering en na de garantieperiode.

De verplichte taken in deze fase zijn:

• inrichten invoeringsomgeving (7.01);
• uitvoeren acceptatietesten (7.02);
• inrichten productiesysteem (7.05);
• overdragen systeem (7.06);
• uitvoeren projectevaluatie (7.07);
• ondersteunen tijdens garantieperiode (7.08).

De belangrijkste producten die in deze fase worden opgeleverd zijn:

• acceptatietestrapport;
• systeeminstallatierapport;
• projectevaluatierapport.

Taak 7.01 Inrichten invoeringsomgeving

De invoeringsomgeving wordt ingericht voor uitvoering van de acceptatietest, voor de data conversie en voor training. Voor elk van deze drie kunnen aparte omgevingen worden ingericht. Bij het inrichten van de omgevingen worden de volgende activiteiten uitgevoerd:

• inrichten applicatiebeheer en technisch beheer voor productiefase;
• completeren en verspreiden systeemdocumentatie;
• inrichten accommodatie en administratie;
• inrichten beveiliging en toegangscontrole;
• installeren hard- en software;
• inrichten acceptatietestomgeving;
• inrichten data conversieomgeving;
• inrichten trainingsomgeving.

Taak 7.02 Uitvoeren acceptatietesten

De acceptatietest  valt volledig onder de verantwoordelijkheid van de gebruikersorganisatie, waarbij ondersteuning geleverd kan worden door het projectteam. De doelstelling van de acceptatietest is te verifiëren of het op te leveren systeem voldoet aan de opgestelde specificaties en gereed is voor in-productiename.

Het uitvoeren van de acceptatietest omvat de volgende activiteiten:

• genereren van (geconverteerde) data voor acceptatietest;
• installeren gebruikersprocedures en operationele procedures;
• uitvoeren van de acceptatietest volgens de voorgeschreven specificaties (taak 4.09);
• analyseren testresultaten;
• uitvoeren van correctieve acties;
• opstellen van acceptatietestrapport.

Taak 7.03 Converteren data

De doelstelling van deze taak is het uitvoeren van alle activiteiten, handmatig of geautomatiseerd, die zijn gespecificeerd (taak 3.09 en 4.10) voor het converteren van alle noodzakelijke data van het oude systeem naar het nieuwe systeem. De activiteiten die bij het converteren worden uitgevoerd zijn:

• installeren conversiesoftware;
• definiëren van conversieprocedures;
• uitvoeren van dataconversie;
• controle van geconverteerde data;
• ondersteunen van correctieve acties;
• opstellen conversierapport.

Taak 7.04 Verzorgen training

Deze taak omvat het verzorgen van trainingen voor het toekomstig gebruik en beheer van het systeem, zoals vastgelegd in het trainingsplan (taak 3.10).

Het doel van de training moet zijn dat:

• de gebruikersorganisatie overtuigd raakt van het nut van het systeem en gemotiveerd raakt om het te gebruiken;
• de gebruikers en beheerders zich bewust zijn van hun verantwoordelijkheid ten aanzien van het systeem;
• de gebruikers weten op welke wijze het systeem hen bij de uitvoering van hun werkzaamheden ondersteunt.

Taak 7.05  Inrichten productiesysteem

Deze taak gaat direct vooraf aan de overgang naar het nieuwe systeem en vereist daarom strakke controle vanwege het kritische karakter, de tijdsbeperkingen en het risico van verstoring van de dagelijkse operaties.
Alle benodigde hardware en operatingsysteemsoftware moet voorbereid zijn, data geladen, programma’s geladen, netwerk geïnstalleerd, systeemparameters gezet en alle betrokken medewerkers worden geïnformeerd ter bevestiging van hun verantwoordelijkheid en uitvoering van de invoeringsprocedures.

Taak 7.06 Overdragen systeem

Nadat het productiesysteem is geïnitieerd en gecontroleerd door een aantal vooraf opgestelde opstartactiviteiten, kunnen de systeemdocumentatie en de verantwoordelijkheden van het projectteam worden overgedragen aan de gebruikers en de beheerders.

Taak 7.07 Opstellen projectevaluatierapport

De doelstelling van deze taak is het vastleggen van de ervaringen die opgedaan zijn in het project in termen van:

• uitvoering van de fasen;
• gebruik van standaards, procedures, technieken en hulpmiddelen;
• kwalitatieve en kwantitatieve informatie van de betrokken partijen.

De evaluatie is ook bedoeld om inzicht te krijgen in de mate van tevredenheid van de klant over het uitgevoerde project en hieruit lering te trekken voor vervolgprojecten.

Taak 7.08 Ondersteunen tijdens garantieperiode

Het pakket en zijn wijzigingen kunnen om economische redenen niet voor 100 % worden getest. Door het testen kan de aanwezigheid van fouten worden aangetoond, maar niet de afwezigheid. De doelstelling van deze taak is dan ook om storingen of onjuist gerealiseerde specificaties te verhelpen. Dit betreft niet alleen het pakket, maar ook de wijzigingen, de additionele functionaliteit en de hardware. Het is van belang dat de opdrachtgever duidelijke afspraken maakt met de betrokkenen over de inhoud van de garantieondersteuning en de duur van de garantieperiode.

Download:         

Gerelateerde artikelen:

1. Methode en checklist pakketselectie en -implementatie deel 2
2. Methode en checklist pakketselectie en -implementatie deel 4
3. Methode en checklist pakketselectie en -implementatie deel 1

1. Inleiding vierluik PSI
2. Inleiding pakketselectie en -implementatie methode
3. Fase 2. Pakketselectie
4. Fase 3. Functioneel Ontwerp

 1. Inleiding vierluik PSI

In vier delen publiceren wij een methodiek voor een complexe pakketselectie en -implementatie, aangevuld met een checklist. Deze methode is primair geschreven voor de externe projectleider, maar is zeker in combinatie met de checklist ook toepasbaar voor intern gebruik.

De methode is gemaakt voor omvangrijke trajecten, waarbij sprake is van aanvullend maatwerk en integratie met andere systemen, die ook deels maatwerk zijn. Schroomt u dus niet om activiteiten te schrappen, maar checkt u wel of daarmee geen belangrijke controles verloren gaan, ook al vergt de uitvoering daarvan maar enkele minuten.

Dit handboek sluit goed aan op Voorbeeld opzet handboek voor ICT kwaliteit deel 1 (2 en 3).

De opbouw van de delen is als volgt:

• Deel 1 omvat de inleiding en het vooronderzoek
• Deel 2 omvat de pakketselectie en het functioneel ontwerp
• Deel 3 omvat de pakketimplementatie
• Deel 4 omvat de checklist per activiteit
   

2. Inleiding pakketselectie en -implementatie methode

De pakketselectie en -implementatie methode (PSI) verdeelt een project waarmee een pakket wordt geselecteerd en geïmplementeerd in een aantal fasen, die op hun beurt weer verder onderverdeeld zijn in respectievelijk taken en activiteiten. Bovendien zijn beslis- en rapportage momenten gedefinieerd. Dit handboek geeft op globaal niveau aan hoe het selectie- en implementatietraject opgedeeld wordt in fasen, taken en activiteiten en is met name bestemd voor degenen die de selectie en implementatie daadwerkelijk uitvoeren.

In deel 1 van dit handboek werd allereerst ingegaan op de fasering van het totale selectie- en implementatietraject. Vervolgens werd iedere fase met bijbehorende taken kort beschreven. De nadruk lag hierbij op het doel en de belangrijkste resultaten van de taak. Daarna werd het vooronderzoek beschreven.
In dit deel 2 en volgende delen zullen we dieper ingaan op de afzonderlijke volgende fasen.
 

3. Fase 2. Pakketselectie

De doelstellingen van de pakketselectie zijn:

• opstellen en uitsturen van de offerteaanvraag;
• evalueren van offertes en selecteren van een voorkeurspakket en -leverancier;
• bepalen van het additioneel te realiseren maatwerk, zowel binnen als buiten het pakket, om aan de bedrijfsdoelstellingen te voldoen;
• voorbereiden van de omgeving en de organisatie voor het testen van het pakket;
• testen van het standaardpakket op toepasbaarheid;
• bevestigen van de haalbaarheid van het project.

Vanuit de gedetailleerde systeemeisen en -wensen wordt een standaard offerte aanvraag opgesteld en verstuurd naar de leveranciers. In de aanvraag zijn de functionele, technische, implementatie, commerciële en administratieve eisen en wensen vastgelegd.

Figuur 3: Fase 2 pakketselectie

 De pakketvoorstellen van de leveranciers worden beoordeeld op basis van de evaluatiecriteria ( eisen en wensen ). Door het uitvoeren van een globale proces- en data-evaluatie wordt inzicht verkregen in de functionele toepasbaarheid van elk pakket. Daarnaast geeft de evaluatie inzicht in de gevolgen van elk pakket met betrekking tot:

• inrichting van het pakket;
• pakketwijzigingen/ uitbreiding en additioneel maatwerk in andere systemen;
• interfaces met de omringende systemen;
• wijzigingen van de organisatie (administratieve organisatie, training enzovoort);
• additionele hardware en software behoefte;
• risico’s als gevolg van het niet op tijd beschikbaar zijn;
• organisatie;
• gebruik en beheer van het pakket en de technologie.

Door het bijwonen van demonstraties en het afleggen van referentiebezoeken wordt informatie verkregen over de werking van het pakket, over de tevredenheid van derden over de leverancier en over eventuele knelpunten en ervaringen bij invoering. De evaluatie van pakketten resulteert in een aanbeveling van maximaal een pakket dat het beste aansluit bij evaluatiecriteria. De resultaten van de evaluatie worden opgenomen in het oplossingsvoorstel.

Door de leverancier kan voorafgaande aan de pakketdemonstratie vaak een proforma contract worden opgesteld. Dit vormt dan de basis voor het conceptcontract voor aankoop en onderhoud van het pakket en ook voor de eventuele ontwikkeling van additionele functionaliteit. Dit contractvoorstel wordt aan de opdrachtgever overgedragen voor de uiteindelijke onderhandelingen en de ondertekening.

Om meer inzicht te krijgen in de werking van het meest bruikbare pakket en de haalbaarheid en volledigheid van de voorgestelde oplossing, wordt een proefomgeving gecreëerd (ook wel Conference Room Pilot genoemd), wordt de functionele bruikbaarheid van het pakket uitgetest en worden de consequenties voor organisatie, personeel, administratieve organisatie, financiën, informatievoorziening en technologie nader uitgewerkt. Daarna wordt een globale implementatiestrategie opgesteld, voor zover daar al een beeld van is.

De resultaten van de proeftuin worden in het oplossingsvoorstel opgenomen. Dit voorstel wordt vervolgens voorgelegd aan de opdrachtgever, die op basis van dit rapport een besluit neemt over het voorstel.

De verplichte taken in deze fase zijn:

• opstellen offerteaanvraag (2.01);
• evalueren offertes en selecteren leveranciers (2.02);
• inrichten proefomgeving ( 2.04);
• testen pakket (2.05).

De belangrijkste producten die in deze fase worden opgeleverd zijn:

• offerte aanvraag;
• offerte met pakketvoorstel van de leverancier;
• oplossingsvoorstel inclusief pakketvoorstel.

Figuur 4: Selectieproces

Indien het uitgangspunt wordt gehanteerd dat functionaliteit van het pakket bepalend is voor de organisatie en geen additionele functionaliteit is toegestaan, kan taak 2.3 ‘Bepalen pakket/ niet- pakket grenzen’ achterwege worden gelaten.

Taak 2.01 Opstellen offerteaanvraag

Voor het opstellen van de offerteaanvraag (zie ‘Methode en checklist pakket selectie en -implementatie (deel 4)’ worden de eisen en wensen verzameld en verwerkt in de offerte en vervolgens verstuurd vaar de pakketleveranciers van de shortlist. De offerteaanvraag bevat minimaal de volgende onderdelen:

• standaard inkoopvoorwaarden van de opdrachtgever;
• administratieve afspraken met betrekking tot het offerteproces;
• beschrijving van de projectachtergrond en de benodigde commerciële informatie van de leverancier;
• beschrijving van de functionele, technische en operationele eisen en wensen.

Daarnaast worden in deze taak de evaluatiecriteria en daaraan gerelateerde wegingsfactoren toegespitst op de eisen en wensen zoals deze in de offerte aanvraag zijn opgenomen.

Taak 2.02 Evalueren offertes en selecteren leverancier

Binnen deze taak worden de pakketvoorstellen beoordeeld op basis van de evaluatiecriteria. De evaluatie geeft een beeld van de toepasbaarheid van elk van de pakketten ( bedrijfsstructuur, processen, gegevens en gebruikerstaken ) en van de gevolgen voor onder andere conversie, interfaces, implementatie en organisatie. De taak kan gecombineerd worden uitgevoerd met taak 2.03 ‘Bepalen pakket/ niet–pakket grenzen’, indien blijkt dat extra functionaliteit aan het pakket moet worden toegevoegd.

Ter ondersteuning van de evaluatie kunnen demonstraties worden bijgewoond of referentiebezoeken worden afgelegd. De pakketvergelijking resulteert in een  pakketoplossingsvoorstel waarin de volgende onderdelen zijn opgenomen:

• uitgangspunten en reeds genomen beslissingen;
• samengevatte conclusies ten aanzien van de functionele toepasbaarheid van de pakketten ( pakketfuncties, pakketaanpassingen, additioneel maatwerk en interfaces);
• consequenties van implementatie van elk pakket naar aspecten van organisatie, personeel, administratieve organisatie, financiële middelen, informatie voorzieningen en technische hulpmiddelen;
• aanbevelingen ten aanzien van de pakketkeuze en het vervolgtraject.

Het oplossingsvoorstel dat binnen deze taak wordt opgesteld heeft een dusdanige diepgang dat het voldoende basis geeft voor het maken van een gedegen keuze voor  een pakket. Het verder uitdiepen van het oplossingsvoorstel voor het voorgestelde pakket vindt plaats binnen een proeftuin (zie taak 2.05 ‘Testen pakket’).

Nadat de opdrachtgever, op basis van het oplossingsvoorstel, het besluit heeft genomen om met het voorgestelde pakket door te gaan, wordt met de betreffende pakketleverancier het conceptcontract opgesteld, waarin afspraken worden gemaakt met betrekking tot de wijze van acquisitie, de implementatieplanning, de vereiste wijzigingen en uitbreidingen ( voor zover bekend) en de ondersteuning bij de invoering en het beheer.

Taak 2.03 Bepalen pakket/ niet -pakket grenzen

De doelstelling van deze taak is inzicht te krijgen in de hoeveelheid extra additionele ontwikkelingen die nodig zijn om aan de systeemeisen en -wensen te voldoen.

Op basis van een confrontatie van het referentiemodel ( bedrijfsstructuur, gegevens, processen en autorisatie ) met het pakketmodel wordt bepaald welke functionaliteit door het pakket wordt uitgevoerd en welke op een andere wijze moet worden gerealiseerd. Hierbij kunnen verschillende alternatieve oplossingen worden gegenereerd.

Dit resulteert uiteindelijk in een voorstel waarin is opgenomen:

• welk deel van de toepassing met het pakket wordt gerealiseerd en welke delen of modulen van het pakket daarvoor nodig zijn;
• welke softwarematige aanpassingen noodzakelijk zijn in de standaard pakketfuncties;
• welk deel van de toepassing door middel van maatwerk wordt gerealiseerd;
• welke interfaces worden gerealiseerd en welke aanpassingen daarvoor in de omringende systemen nodig zin;
• welke organisatorische aanpassingen noodzakelijk zijn.

Figuur 5: Applicatiegebied

Dit voorstel, met zijn consequenties, wordt opgenomen in het oplossingsvoorstel.

Taak 2.04 Inrichten proefomgeving

Deze taak omvat het opzetten en beheren van een proefomgeving voor het uittesten van het standaardpakket. Hierbij wordt aandacht besteed aan de pakketinstallatie procedures, aan het creëren van een fysieke werkomgeving, aan het verzorgen van hardware, aan het opzetten van training, aan een testscenario en aan het verzamelen van de testgegevens.

Taak 2.05 Testen pakket

De doelstelling van deze taak is:

• vertrouwd raken van projectmedewerkers met de werking van het standaardpakket;
• beoordelen van de pakketdocumentatie;
• toetsen van de realiseerbaarheid van de eisen en wensen in het pakket;
• verfijnen van het oplossingsvoorstel.

Daarnaast wordt in deze taak ook documentatie vastgelegd van het implementatiemodel, voorzover deze reeds bekend is:

• gegevens- en procesmodel waarin de gekozen oplossing voor implementatie is verwerkt;
• autorisatiestructuur geënt op de nieuwe situatie;
• beschrijving van interfaces en aanpassingen in andere systemen.

De projectmedewerkers die de test gaan uitvoeren worden opgeleid in het pakket. Het testen van het pakket concentreert zich primair op de primaire bedrijfsprocessen van het applicatiegebied en op de consequenties voor de organisatie.

Naar aanleiding van de test komen wijzigingen en uitbreidingen op het oplossingsvoorstel vaar voren. De resultaten van de pakkettest worden verwerkt in het oplossingsvoorstel. Dit voorstel wordt vervolgens aan de opdrachtgever voorgelegd, die hierover een beslissing neemt. 

4. Fase 3. Functioneel Ontwerp

De doelstellingen van het functioneel ontwerp zijn:

• opstellen van een functioneel implementatiemodel van het pakket, aangevuld met de additionele functionaliteit;
• opstellen van een gedetailleerd functioneel ontwerp voor respectievelijk:
  • pakketwijzigingen en -uitbreidingen;
  • wijzigingen in andere systemen;
  • interfaces;
  • dataconversie.
• uitwerken consequenties voor de organisatie;
• bevestigen van de technische, operationele en economische haalbaarheid van het project.

Het uitgangspunt voor het functioneel ontwerp is een goedgekeurd oplossingsvoorstel. Het functioneel ontwerp resulteert voor de opdrachtgever in een document waarin is aangegeven hoe het oplossingsvoorstel wordt gerealiseerd. Dit document dient als basis voor de formele goedkeuring. Daarnaast legt het functioneel ontwerp voor de technisch ontwerpers een gedegen basis voor het uitvoeren van het technisch ontwerp.

De verplichte taken in deze fase zijn:

• bijwerken projectkwaliteitsplan (3.03);
• opstellen functionele pakketspecificaties (3.03);
• definiëren teststrategie ( 3.08 );
• controleren functioneel ontwerp ( 3.07);
• opstellen trainingsplan (3.10).

De belangrijkste producten die in deze fase worden opgeleverd zijn:

• bijgewerkt projectkwaliteitsplan;
• functionele specificaties voor pakket en maatwerk;
• teststrategie;
• trainingsplan.

Indien additionele functionaliteit wordt gerealiseerd om aan de eisen en wensen te voldoen, worden ook de taken 3.02 ‘Opstellen globale functionele specificaties’ en 3.04 ‘Opstellen gedetailleerde functionele specificaties’ uitgevoerd. De uitvoering van de overige taken is afhankelijk van de projectsituatie.

Figuur 6: Functioneel ontwerp

Taak 3.01 Bijwerken projectkwaliteitsplan

Binnen deze taak wordt het projectkwaliteitsplan, dat is opgesteld in taak 1.01, nader gedetailleerd voor de fase functioneel ontwerp. Het uitgangspunt voor deze taak is een goedgekeurd oplossingsvoorstel. De volledigheid en consistentie hiervan moeten worden vastgesteld. Tevens dient een technische omgeving beschikbaar te zijn ter ondersteuning van het opstellen van de functionele specificaties.

Binnen het kader van het projectkwaliteitsplan wordt opnieuw vastgesteld op welke wijze het toepassingsgebied wordt benaderd: per organisatorische eenheid, per geografische eenheid enzovoort. Binnen de gekozen aanpak worden vervolgens de uit te voeren taken en hun volgorde bepaald, alsmede de resources die betrokken zijn bij de uitvoering. Het projectkwaliteitsplan geeft ook aan op welke wijze wensen tot aanpassing van het pakket worden beoordeeld.

Taak 3.02 Opstellen globale functionele specificaties

Deze taak omvat het opstellen van de globale functionele specificaties voor omvangrijke processen die niet of niet geheel door het te implementeren pakket en andere in de organisatie operationeel zijnde informatiesystemen vervuld worden. De basis hiervoor is reeds gelegd in de taak 2.03 ‘Bepalen pakket/ niet -pakket grenzen’ uit de fase pakketselectie.

Het opstellen van de functionele specificaties voor de additionele processen wordt iteratief uitgevoerd met taak 3.03 ‘Opstellen functionele pakketspecificaties’. De taak resulteert in een beschrijving van:

• de functionele architectuur;
• de scope van additionele subsystemen;
• het gegevensmodel;
• de interfaces van de subsystemen met het pakket of met andere systemen;
• de consequenties van het functioneel ontwerp voor onder andere de implementatie en organisatie.

Taak 3.03 Opstellen functionele pakketspecificaties

Door middel van een topdown proces- en gegevensbenadering wordt tot op een gedetailleerd niveau de vereiste systeemfunctionaliteit vergeleken met de pakketfunctionaliteit, met als doel na te gaan in welke mate en op welke wijze de gewenste functionaliteit in de pakketfuncties kan worden ondergebracht. Bij het opstellen van de functionele specificaties is gebruikersparticipatie van essentieel belang. Ter ondersteuning van dit proces kan gebruik gemaakt worden van een ingericht testomgeving ten behoeve van prototyping.

De taak resulteert in een document, waarin zijn beschreven:

• de keuzes die gemaakt zijn voor de inrichting van de pakketfuncties en de motivatie daarbij;
• de wijze waarop het pakket en de pakketfuncties worden geparametriseerd om de gewenste functionaliteit te verkrijgen;
• de gevolgen van bepaalde pakketinstellingen voor andere pakketfuncties;
• de structuur van de bij het proces betrokken pakketfuncties, zoals schermdefinities, scherm- en transactieverloop;
• functionele specificaties van kleine wijzigingen/ uitbreidingen binnen het pakket (bijvoorbeeld additionele rapportages);
• functionele specificaties van de interfaces tussen het pakket, de pakketuitbreiding en andere systemen;
• eventuele aanvullingen van de data dictionary conform de definitieve oplossing en de aanvullingen op het datamodel;
• een gedetailleerd implementatiegegevensmodel;
• specificaties van de autorisatie.

Taak 3.04 Opstellen gedetailleerde functionele specificaties

De globale functionele specificaties van additionele subsystemen die in taak 3.02 zijn opgesteld worden in deze taak nader gedetailleerd. De functionele in- en uitvoerprocessen worden uitgewerkt. Ook worden van de subsystemen de interfaces, de autorisaties en het gegevensmodel verder gedetailleerd.

Taak 3.05 Definiëren wijzigingsstrategie andere systemen

De wijzigingen in de systemen die buiten het applicatiegebied vallen, worden in deze taak geanalyseerd en functioneel beschreven. Door het te implementeren pakket kunnen wijzigingen in de andere systemen nodig zijn, bijvoorbeeld door overlapping van functionaliteit van het pakket en de andere systemen of door een gewijzigde invoer en/ of uitvoer van gegevens van het pakket aan de andere systemen.

Taak 3.06 Definiëren wijzigingsstrategie organisatie

De doelstelling van deze taak is om de gevolgen van het te implementeren systeem voor de organisatie te bepalen. Vaak zal een voorgenomen organisatiewijziging de reden zijn voor een pakketimplementatie en niet omgekeerd. Desalniettemin zal de pakketimplementatie vaak gezien worden als de oorzaak van verandering en daardoor mogelijk weerstand opwekken bij de gebruikersorganisatie. Het vroegtijdig begeleiden en betrekken van de gebruikersorganisatie in dit veranderingsproces is van essentieel belang om de implementatie te doen slagen.
Binnen deze taak worden wijzigingen voor de organisatiestructuur en de bedrijfsprocessen bepaald die het gevolg zijn van het nieuw te implementeren systeem. Enkele voorbeelden hiervan zijn:

• verplaatsen van werkzaamheden naar een andere afdeling of locatie;
• toevoegen of verwijderen van bedrijfsfuncties of verantwoordelijkheden;
• wijzigingen voor de IT –organisatie voor het beheer van het pakket tijdens en na afloop van de implementatie.

Voor het doorvoeren van de organisatiewijzigingen wordt een strategie opgesteld, waarin wordt aangegeven hoe de wijzigingen in de organisatie door te voeren. Ook wordt op globaal niveau de opleidingsbehoefte vastgesteld, om medewerkers te begeleiden naar de toekomstige situatie.

Taak 3.07 Controleren functioneel ontwerp

De controle van het functioneel ontwerp is noodzakelijk om vast te stellen of het ontwerp een goede basis biedt voor de verdere ontwikkeling van het systeem. Hierbij wordt aandacht besteed aan de volgende zaken:

• bevestiging dat aan de bedrijfsdoelstellingen wordt voldaan door de pakketfunctionaliteit, de gedefinieerde wijzigingen en de uitbreidingen;
• de mogelijke gevolgen van het functioneel ontwerp met betrekking tot de eisen en wensen (herleidbaarheid, volledigheid, consistentie);
• mogelijke conflicten tussen implementatieoverwegingen (gerelateerd aan eisen en wensen, organisatiewijzigingen, wijzigingen andere systemen, dataconversie, training, testen enzovoort);
• technisch haalbaarheid in termen van architectuur, data- en procesmodellen, interfaces enzovoort;
• economische haalbaarheid ( in het bijzonder de verwachter kosten/ baten en de balans tussen enerzijds pakket en anderzijds pakketwijzigingen en andere modificaties).

Na controle van het functioneel ontwerp wordt dit ter goedkeuring aan de opdrachtgever voorgelegd.

Taak 3.08 Definiëren teststrategie

De doelstelling van deze taak is een complete teststrategie te ontwikkelen, waarin is beschreven het testproces en de verantwoordelijkheden van betrokken partijen met hun rol daarin. De teststrategie bevat enerzijds een aantal fasen en anderzijds een aantal aandachtspunten.

Mogelijke testfasen zijn:

• test van de afzonderlijke wijzigingen in ander systemen en/ of additionele functionaliteiten die zijn gerealiseerd in subsystemen;
• pakkettest inclusief de aangebrachte pakketwijzigingen;
• integratietest tussen het pakket en de pakketuitbreidingen en ander systemen;
• systeemtest betreffende de functionaliteit en performance van het geïntegreerde pakket, de interfaces naar de externe systemen en alle operationele en gebruikersprocedures;
• acceptatietest betreffende het gehele systeem in een proefproductieomgeving en de overdracht naar het beheer.

De aandachtsgebieden van het testen zijn ondermeer:

• proeftransacties ( globaal functioneel testen  van afzonderlijke eenheden);
• complexe transacties (gedetailleerd functioneel testen);
• uitzonderingsvoorwaarden;
• hoge volumes van data en transacties;
• uitwijk- en recovery mogelijkheden;
• interfaces met andere systemen en dataconversie;
• handmatige procedures en training.

In de teststrategie worden testfasen, aandachtsgebieden, procedures, documentatie (testplan, specificaties, testdata en testrapport), hulpmiddelen en verantwoordelijken met hun rol vastgelegd.

Taak 3.09 Opstellen dataconversieplan

Bij de invoering van een nieuw informatiesysteem worden vaak bestaande gegevens uit het oude informatiesysteem geheel of gedeeltelijk overgenomen. Het opstellen van het conversieplan start met het identificeren van te converteren gegevens en het vaststellen de kwantiteit en de kwaliteit (correctheid en volledigheid) hiervan.

Voor elke conversie- en controleprocedure wordt een kostenschatting gemaakt voor zowel het ontwikkelen van de benodigde hulpmiddelen als voor het uivoeren van de betreffende conversie en controle. Hierbij dient benodigde man- en machinecapaciteit te worden aangegeven.
Voor de conversie en voor de completering van het datamodel worden vervolgens functionele specificaties opgesteld in de vorm van in- en uitvoerprocessen.

In het plan worden de afzonderlijke conversies, de controlepunten en het gebruik van resources vastgelegd. Het conversieplan is afhankelijk van de wijze van invoering van het nieuwe systeem en zal deel uitmaken van het nog op te stelle invoeringsplan.

Taak 3.10  Opstellen trainingsplan

Deze taak heeft tot doel het trainingsprogramma te bepalen voor het gebruik en het beheer van het nieuwe systeem. Hierbij gaat de aandacht uit naar algemene aspecten zoals:

• de basis van het nieuwe systeem;
• de gevolgen van het systeem voor de organisatie;
• basisinstructie in de nieuwe technologie;
• veranderingen en werkprocedures;
• verschillen tussen het oude en nieuwe systeem en de verwachte voordelen.

Maar vooral wordt aandacht besteed aan de wijze waarop het systeem de gebruiker ondersteunt bij het uitvoeren van zijn functie. In het trainingsplan worden er per doelgroep (eindgebruiker, beheerders, management) vastgelegd een trainingsprogramma en een planning van activiteiten en resources.

Download:         

Gerelateerde artikelen:

1. Methode en checklist pakketselectie en -implementatie deel 1
2. Methode en checklist pakketselectie en -implementatie deel 4
3. Methode en checklist pakketselectie en -implementatie deel 3

1. Inleiding vierluik PSI
2. Inleiding pakketselectie en -implementatie methode
3. Fasering
4. Beschrijving per fase
5. Fase 1. Bepalen eisen en wensen 

1. Inleiding vierluik PSI

In vier delen publiceren wij een methodiek voor een complexe pakketselectie en -implementatie, aangevuld met een checklist. Deze methode is primair geschreven voor de externe projectleider, maar is zeker in combinatie met de checklist ook toepasbaar voor intern gebruik.

De methode is gemaakt voor omvangrijke trajecten, waarbij sprake is van aanvullend maatwerk en integratie met andere systemen, die ook deels maatwerk zijn. Schroomt u dus niet om activiteiten te schrappen, maar checkt u wel of daarmee geen belangrijke controles verloren gaan, ook al vergt de uitvoering daarvan maar enkele minuten.

Dit handboek sluit goed aan op Voorbeeld opzet handboek voor ICT kwaliteit deel 1 (2 en 3).

De opbouw van de delen is als volgt:

• Deel 1 omvat de inleiding en het vooronderzoek
• Deel 2 omvat de pakketselectie en het functioneel ontwerp
• Deel 3 omvat de pakketimplementatie
• Deel 4 omvat de checklist per activiteit 

2. Inleiding pakketselectie en implementatie methode

De pakketselectie en -implementatie methode (PSI) verdeelt een project waarmee een pakket wordt geselecteerd en geïmplementeerd in een aantal fasen, die op hun beurt weer verder onderverdeeld zijn in respectievelijk taken en activiteiten. Bovendien zijn beslis- en rapportage momenten gedefinieerd. Dit handboek geeft op globaal niveau aan hoe het selectie- en implementatietraject opgedeeld wordt in fasen, taken en activiteiten en is met name bestemd voor degenen die de selectie en implementatie daadwerkelijk uitvoeren.

Na deze inleiding wordt in dit document allereerst ingegaan op de fasering van het totale selectie- en implementatietraject ( hoofdstuk 3) . Vervolgens wordt iedere fase met bijbehorende taken kort beschreven. De nadruk ligt hierbij op het doel en de belangrijkste resultaten van de taak ( hoofdstuk 4). Daarna wordt in het vervolg van dit handboek dieper ingegaan op de achtereenvolgende afzonderlijk fasen. 

3. Fasering

Als een bepaald pakket gekozen is, zal dit pallet zelden voorzien in 100 % van de gewenste functionaliteit. Het gedeelte dat niet door middel van het pakket gerealiseerd wordt, kan dan als maatwerk ontwikkeld worden. Tevens zullen interfaces van en naar andere informatiesystemen ontwikkeld moeten worden ( voor zover het pakket daar niet in voorziet). Ook kan het zijn dat andere informatiesystemen, noodgedwongen, door de starheid van het pakket en/ of door het belang van bepaalde wensen, aangepast moeten worden. Hierdoor komt het voor dat tijdens de realisatie van het informatiesysteem gewerkt wordt in een geïntegreerde omgeving, samengesteld uit aspecten van verschillende omgeving zoals:

• 3e generatie omgeving,
• 4e generatie omgeving,
• webbased omgeving,
• pakketomgeving.

Doordat binnen de diverse omgevingen bepaalde fasen niet doorlopen hoeven te worden en zwaartepunten binnen de fasen verschuiven, bestaan er voor de fasering tussen ontwikkelings-/ implementatietrajecten binnen de diverse omgevingen verschillen.

In een 3e generatie omgeving geldt nog de klassieke fasering waarin de fasen Informatieanalyse, Functioneel Ontwerp, Technisch Ontwerp, Bouw, Testen en Invoering sequentieel doorlopen worden.

Een 4e generatie omgeving wijkt voor wat betreft fasering gedeeltelijk af van een 3e generatie omgeving. Met name een groot deel van de activiteiten in de fase Technisch Ontwerp behoeft niet meer of slechts beperkt te worden uitgevoerd (voorbeelden hiervan zijn: beschrijvingen van technische processen, I/O-schema’s en programmaspecificaties). Voor de webbased omgeving geldt dit nog sterker. Gezien de aard en de omvang van de nog uit te voeren activiteiten is het niet meer zinvol om het Technisch Ontwerp als afzonderlijke fase te beschouwen. In dat geval zullen die werkzaamheden uit het Technisch Ontwerp die toch nog noodzakelijk zijn, deels opschuiven naar het Functioneel Ontwerp en deels naar de Bouw.

In een pakketomgeving (zonder aanpassingen of bij te bouwen functies) wordt de te realiseren functionaliteit van het informatiesysteem nog steeds in de fase Functioneel Ontwerp vastgelegd. De manier waarop deze functionaliteit gerealiseerd wordt, wordt echter niet meer in de vorm van het klassieke Technisch Ontwerp en Bouw uitgevoerd. Dit is overbodig geworden ( in geval van starre pakketten ) of blijft beperk tot het inrichten, het parametriseren van het pakket ( in geval van flexibele pakketten).

Zoals eerder vermeld: bij pakketimplementatie is bijna altijd sprake van meerdere ontwikkel- of implementatie omgevingen. Toch zal voor het totale implementatietraject een uniforme overall fasering gevolgd moeten worden, met name om activiteiten als planning en control zinvol te kunnen uitvoeren. De volgende fasen worden gehanteerd in zo’n geïntegreerde omgeving:

• informatie analyse,
• realisatie,
• invoering.

In afbeelding 1 is de relatie weergegeven tussen de fasering in een geïntegreerde omgeving, de PSI- fasering en de overall- fasering in de individuele omgevingen.

Figuur 1: De relatie tussen de fasering in een geïntegreerde omgeving, de PSI-fasering en de overall fasering in individuele omgevingen

Criterium bij de keuze voor de fasering van PSI is dat de ontwikkeling in andere omgevingen op eenvoudige wijze ingepast moeten kunnen worden in de methode. Afhankelijk van de projectsituatie kan van de PSI-fasering worden afgeweken. 

4. Beschrijving per fase

Opdeling van het pakketselectie en -implementatietraject in fasen zorgt er voor dat er mijlpalen (meetpunten) ontstaan op basis waarvan beslissingen genomen worden over de verdere uitvoering van het project. Het hele traject wordt opgedeeld in fasen die verder onderverdeeld worden in taken en activiteiten. Op basis van deze taken en activiteiten kan er gedetailleerd gepland worden per uit te voeren fase en worden concreet werkopdrachten opgesteld en uitgevaardigd.

PSI onderkent de volgende fasen:

• Bepalen eisen en wensen
• Pakketselectie
• Functioneel ontwerp
• Technisch ontwerp
• Bouw
• Testen
• Invoering

In de volgende hoofdstukken van dit handboek wordt een beschrijving gegeven van de fasen en de taken die daar binnen worden uitgevoerd. De beschrijving van de fasen bevat:

• de doelstellingen van de fase;
• de uitgangssituatie;
• de te bereiken resultaten;
• de aandachtspunten voor uitvoering;
• de relatie tussen taken;
• de inhoud van de taken van de fase.

Bij elke fase is een takendiagram opgenomen. Dit diagram geeft een overzicht van de ‘verplichte’ en ‘optionele’ taken. De verplichte taken zijn taken die onafhankelijk van de projectsituatie minimaal worden uitgevoerd. De optionele taken zijn projectafhankelijk. De meest logische volgorde van uitvoering van de taken is aangegeven door verbindingslijnen tussen de taken. Daarnaast is in het diagram de doorgaande fase in de vervolgfase aangegeven.

Per taak wordt een beschrijving gegeven van de doelstelling, de inhoud en de belangrijkste op te leveren producten. Daarnaast is in ‘Methode en checklist pakket selectie en -implementatie deel 4 het procesmodel van PSI weergegeven. In dit model wordt op schematische wijze de samenhang tussen de fasen, taken en activiteiten weergegeven. Tevens worden hierin van elke taak de benodigde producten, de uit te voeren activiteiten, de op te leveren producten en de betrokken verantwoordelijken en hun rol weergegeven. 

5. Fase 1. Bepalen eisen en wensen

De doelstellingen van het bepalen van de eisen en wensen zijn:

• bepalen van de bedrijfsdoelstellingen (systeem- en organisatiedoelstellingen) en potentiële mogelijkheden voor verbetering;
• bepalen van de gedetailleerde eisen en wensen ten aanzien van het nieuwe systeem’
• toetsen van de resultaten van inventarisatie, kosten/baten en risico analyse met het voorgaande plan uit de voorstudie;
• zorgen voor een basis voor onwikkeling, training conversie en implementatie;
• bevestigen van de haalbaarheid van het project.

Figuur 2: Fase 1. Bepalen eisen en wensen

Tijdens de fase ‘Bepalen eisen en wensen’ wordt de nadruk gelegd op wat het toekomstige systeem moet gaan doen. Het is essentieel dat de opdrachtgever de eisen en wensen grondig toetst, om onjuiste interpretaties te voorkomen. Onvolledige of inconsistente eisen of wensen kunnen resulteren in een ontoereikend ontwerp.

Een goed uitgevoerde bepaling van eisen en wensen geeft een solide basis voor een beoordeling van de belangrijkste onderwerpen:

• Worden de bedrijfsdoelstellingen gerealiseerd?
• Zijn de wijzigingen voor de organisatie acceptabel?
• Is het voorgestelde systeem technisch haalbaar?
• Zijn de verwachte kosten en baten haalbaar?

Bij de bepaling van eisen en wensen zijn de volgende elementen gedefinieerd en/ of gedetailleerd:

• systeemdoelstellingen;
• systeemeisen en -wensen;
• basisprocessen en daaraan gerelateerde gegevens;
• systeemgrenzen en relaties met andere systemen;
• bestaande onderdelen die moeten worden uitgebreid of vervangen;
• noodzakelijke organisatiewijzigingen.

De meeste zorg gaat uit naar het definiëren van de systeemeisen en -wensen en het maken van een referentiemodel, waarin de bedrijfsstructuur, gegevens, processen en gebruikerstaken van het applicatiegebied zijn opgenomen. Hierbij wordt nog weinig of geen rekening gehouden met de ontwikkel/ implementatie beperking. Indien echter reeds, bijvoorbeeld vanuit strategische overwegingen, een keuze is gemaakt voor een specifiek pakket, dan blijft het noodzakelijk de systeemeisen en wensen vast te stellen. Dit om uiteindelijk tot de meest ideale oplossing te komen en te bepalen welke behoeften door het pakket worden gedekt en welke door middel van additionele maatwerkontwikkeling of organisatorische aanpassing worden gerealiseerd. De projectmanager heeft de verantwoording om resultaten te verkrijgen, die de opdrachtgever in staat stellen beslissingen te nemen over de wenselijkheid voor continuering van de pakketselectie- en implementatie.

Er zijn vier verplichte taken in deze fase, te weten:

• opstellen projectkwaliteitsplan ( 1.01 );
• bepalen systeemeisen en -wensen (1.02);
• opstellen shortlist (1.05);
• opstellen referentiemodel (1.06).

Documenten die door deze taken worden voortgebracht zijn respectievelijk:

• projectkwaliteitsplan,
• definitie van systeemeisen en -wensen,
• de shortlist van pakketten en 
• het referentiemodel.

Als de omvang van de eisen en wensen beperkt is, worden taken (1.03 en 1.04) afhankelijk van de situatie. Ze zijn daarom optioneel.

Het projectkwaliteitsplan is een actief plannings- en controledocument waarin de projectmanager het operationele raamwerk voor het project uiteenzet. Het projectkwaliteitsplan bevat:

• de scope, doelstellingen en randvoorwaarden voor zowel project als systeem;
• het globale projectplan en de belangrijkste op te leveren producten;
• de projectorganisatie en de verantwoordelijkheden;
• het ontwikkelproces (fasering, taken en activiteiten);
• het projectmanagement proces, waarbij speciale aandacht wordt besteed aan de wijze waarop derden/ pakketleverancier worden aangestuurd;
• het controleproces inclusief configuratiemanagement, wijzigingenbeheer en kwaliteitsbeheer.

Een taak van de projectmanager is om elk van de projectdeelnemers te informeren over de inhoud van het plan en in het bijzonder over de rol van elk van de deelnemers in het project. Daarnaast wordt ook de organisatie op de hoogte gebracht vaan het projectkwaliteitsplan.

Bij het opstellen van het projectkwaliteitsplan wordt aandacht besteed aan:

• consistentie tussen de workbreakdown structuur, op te leveren producten en de overall planning;
• verplichtingen van de betrokkenen;
• te gebruiken technieken en tools;
• juiste allocatie van medewerkers en vaardigheden;
• procedures voor onder andere configuratiemanagement, wijzigingenbeheer, kwaliteitsbeheer en beveiliging;
• afstemming van het project met andere lopende projecten;
• beoordeling van uitgangsdocumentatie.

Taak 1.02 Bepalen systeemeisen en -wensen

Het doel van deze taak is het opstellen van een definitieve lijst met prioriteiten van de eisen en wensen voor het geprojecteerde toekomstige systeem. Bij het samenstellen van de eisen en wensen voor het toekomstige systeem worden de volgende activiteiten uigevoerd:

• vaststellen van de noodzakelijke systeemkenmerken ( in termen van bedrijfsstructuur, processen, gegevens, autorisatie, interfaces en performance ) en operationele behoeften ( gerelateerd aan organisatiewijzigen, implementatie centraal/ decentraal, geografische spreiding) of aan kwaliteitseisen (zoals overdraagbaarheid en hergebruik);
• toekennen van prioriteiten aan de behoeften.

De systeemeisen en -wensen worden door de opdrachtgever getoetst op consistentie met de bedrijfs- en systeemdoelstellingen, volledigheid en prioriteitsstelling.

Taak 1.03 Analyseren huidige systemen

In veel gevallen worden pakketten geïmplementeerd om bestaande systemen geheel of gedeeltelijk te vervangen. In deze taal worden de bestaande systemen in het applicatiegebied geanalyseerd, met als doel een bijdrage te leveren aan het samenstellen van de eisen en wensen ten aanzien van het toekomstige systeem. De uitvoering van de taak kan achterwege blijven indien deze reeds is uitgevoerd in het vooronderzoek, er sprake is van een volledig nieuwe opzet, of de functionaliteit en het gegevensmodel van het pakket bepalend is voor het nieuwe systeem.

In de beschrijving van de huidige systemen worden de volgende zaken opgenomen:

• bepalen van de huidige systeemdoelstellingen;
• beschrijvingen van het data- en procesmodel;
• beschrijvingen van interfaces en autorisatiestructuur;
• vaststellen van operationele kenmerken van het huidige systeem, zoals knelpunten, efficiency, kosten enz.

Taak 1.04 Analyseren huidige organisatie

Deze taak omvat het bestuderen en analyseren van de huidige bedrijfsdoelstellingen, van de organisatiestructuur en van bedrijfsfuncties, verantwoordelijkheden en operationele kosten. De doelstelling is het reduceren van de risico’s van het nieuwe systeem, om tegemoet te komen aan de bedrijfsdoelstellingen en het verhogen van het vertrouwen in het projectteam.

Indien als gevolg van de invoering van het pakket de toewijzing van kosten wordt geherstructureerd, is het noodzakelijk in deze fase inzicht te verkrijgen in de kostentoerekening.

Het onderzoek resulteert in een model dat de effectiviteit van de organisatie belicht met betrekking tot het ondersteunen van de huidige systemen, en dat ook de bereidheid en de geschiktheid van het personeel aangeeft om zich aan te passen aan de toekomstige veranderingen en een bijdrage te leveren aan de definitie van de systeemeisen -wensen.

Taak 1.05 Samenstellen shortlist

De doelstelling van deze taak is om te komen tot een shortlist van pakketleveranciers, die vervolgens een uitnodiging ontvangen voor het uitbrengen van een voorstel voor een pakketoplossing, gebaseerd op de eisen en wensen van het systeem. In het ideale geval bevat de lijst niet meer dan drie leveranciers.

Hieraan voorafgaand worden de volgende activiteiten uigevoerd:

• opstellen van een document voor het verkrijgen van pakket/ leverancier informatie;
• opstellen pakket/ leverancier evaluatiecriteria.

Daarnaast wordt een globale pakketstrategie opgesteld, waarin de aanpak wordt vastgelegd met betrekking tot zaken als:

• installatie van hard- en software;
• proeftesten;
• training van geschikte medewerkers voor het uivoeren van de test;
• bepaling van de gegevens die nodig zijn voor uitvoering van de test;
• meting van de geschiktheid van het pakket voor de organisatie.

Op basis van de evaluatiecriteria worden de pakketten en leveranciers beoordeeld.
Leveranciers die bij deze evaluatie afvallen, worden hiervan op de hoogte gebracht.

Taak 1.06 Opstellen referentiemodel

De systeemeisen en -wensen zijn geïdentificeerd tijdens de taak ‘Bepalen systeemeisen en -wensen’. Nadat deze zijn geaccordeerd door de opdrachtgever, moeten deze worden gemodelleerd om een geconsolideerde en consistente beschrijving van het systeem te verkrijgen, inclusief de gevolgen voor de organisatie en de pakketimplementatie.

Het referentiemodel bevat de volgende onderdelen:

• de toekomstige bedrijfsstructuur;
• het gegevensmodel;
• het procesmodel (van bedrijfsprocessen);
• de gebruikerstaken.

Daarnaast wordt een beschrijving opgenomen van de interfaces, de operationele kenmerken, de implicaties en de organisaties.

Omdat het pakketselectieproces uitsluitsel moet geven over de mate waarin het pakket aansluit bij de eisen en wensen, is het van belang dat het referentiemodel volledig is en voldoende diepgang heeft, alvorens gestart wordt met dit proces.

Download:         

Gerelateerde artikelen:

1. Methode en checklist pakketselectie en -implementatie deel 2
2. Methode en checklist pakketselectie en -implementatie deel 3
3. Methode en checklist pakketselectie en -implementatie deel 4

1. Toelichting op dit document
2. Inleiding: duidelijkheid als sleutelwoord
3. Duidelijke doelstellingen PPPP-IT
4. Het PPPP-IT kwaliteitssysteem
5. De systeemontwikkelingsmethode
   5.1 Structuur van de methode
   5.2 De ontwikkelingsfasen
   5.2.1 Definitiestudie
   5.2.2 Basisontwerp
   5.2.3 Detailontwerp
   5.2.4 Realisatie
   5.2.5 Invoering
   5.3 Onderhoud van informatiesystemen
   5.3.1 Onderhoudsaanpak
   5.3.2 Urgent onderhoud
6. Inrichting van het project
7. Meer over kwaliteitsbeheer ICT
8. Nawoord

 
1. Toelichting op dit document

Dit document bevat het tweede deel van een voorbeeld van een kwaliteitshandboek ICT, dat daadwerkelijk is geïmplementeerd in de praktijk. Het gaat in op systeemontwikkeling (waterval methode SDM-2), beheer (ITIL-based) en projectmanagement (ook mogelijk via Prince 2).
Het handboek is geschreven vanuit de behoefte van de bedrijfsprocessen en gebruikers en is bedoeld om de ICT-afdeling zo te laten werken, dat aan de gebruikers een adequate informatie voorziening wordt gegarandeerd. Er wordt dan vooral ook ingezoomd op de activiteiten die voor de gebruikers van belang zijn, zodat ook zij begrijpen dat hun participatie cruciaal is om dit te realiseren. Het maakt hierbij niet uit of het een interne of externe ICT-afdeling betreft. Zeker ook in het geval van outsourcing is dit handboek bruikbaar om tot een werkzame samenwerking te komen, waarbij taken, verantwoordelijkheden en bevoegdheden zijn vastgelegd.
Om hergebruik gemakkelijk mogelijk te maken, is de bedrijfsnaam vervangen door PPPP. Via zoek en vervang kunt u hier uiteraard de naam van uw organisatie invullen.

Uiteraard kan ZBC u ondersteunen bij de aanpassing en de invoering van dit handboek en het verzorgen van workshops aan betrokkenen.

Het handboek is gezien zijn omvang opgesplitst in drie delen, om problemen met downloaden te voorkomen. In deel 1 vindt u de inleiding op het handboek, die bestaat uit de volgende hoofdstukken: 

2. Inleiding: duidelijkheid als sleutelwoord
 

3. Duidelijke doelstellingen PPPP-IT
 

4. Het PPPP-IT kwaliteitssysteem 

Deel 2 

5. De systeemontwikkelingsmethode

5.1 Structuur van de methode

Het Kwaliteitshandboek beschrijft wèlke activiteiten kunnen of moeten worden uitgevoerd en wèlke producten daarbij dienen te worden opgeleverd. Met andere woorden: planning en beheersing vinden plaats op grond van mijlpaalproducten die als gevolg van alle activiteiten worden opgeleverd.

In het Handboek wordt de vormgeving van een informatiesysteem vanuit vier invalshoeken benaderd:

• verandering:
  Wat wil de organisatie? Hoe zal de organisatie er over twee tot vijf jaar uitzien?
• systeemontwikkeling:
  Welke ondersteuning van informatiesystemen heeft de organisatie nodig en hoe maken we deze?
• kwaliteitsborging:
  validatie, verificatie en acceptatie
• besturing:
  Hoe zorgen we ervoor dat het gewenste resultaat binnen de randvoorwaarden bereikt wordt?

Deze vier bouwstenen slaan de brug van de huidige naar de gewenste informatievoorziening en zullen als rode draden door alle modules van het Kwaliteitshandboek verweven zijn.
Het ontwikkelingstraject is opgedeeld in fasen, waarbij van elke fase de activiteiten en de te maken producten worden beschreven. Iedere fase kent activiteiten en producten die verband houden met de genoemde vier invalshoeken.

Fasen van het ontwikkelingstraject
De fasering dient om de ontwikkeling van het systeem in hanteerbare en overzichtelijke eenheden in te delen en om de noodzakelijke beslismomenten vast te leggen. PPPP-IT onderkent in de levensloop van een informatiesysteem vijf fasen, te weten:

1. Definitiestudie
2. Basisontwerp
3. Detailontwerp
4. Realisatie
5. Invoering

De Definitiestudie (fase 1) is het begin van het feitelijke systeemontwikkelingstraject, waarin de globale eisen, alternatieven en de haalbaarheid onderzocht worden, op grond waarvan beleidskeuzes gemaakt kunnen worden. In fase 2 (Basisontwerp) worden de gemeenschappelijke aspecten van de systeemdelen ontworpen en moeten de belangrijke ontwerpkeuzes gemaakt worden. Dit is de laatste fase waarin een systeem in z’n totaliteit wordt beschouwd. In de fasen 3 tot en met 5 wordt in deelprojecten het systeem verder ontworpen, gerealiseerd en ingevoerd. Vervolgens wordt de verantwoordelijkheid voor het systeem overgedragen aan de gebruikersorganisatie, waarbij PPPP-IT dienstverlening kan bieden op het gebied van productie, onderhoud en beheer.

De diverse fasen zullen in het vervolg van dit Kwaliteitshandboek nader uitgewerkt worden. Een en ander is weergegeven in figuur 4.

Figuur 4: Fasen systeemontwikkelingstraject

  Activiteiten en producten
Zoals al is aangegeven, kent iedere fase activiteiten die verband houden met de vier basisprocessen van waaruit PPPP-IT de ontwikkeling van de organisatie en de informatievoorziening benadert.

5.2 De ontwikkelingsfasen

PPPP-IT streeft naar fixed quality door een constante beheersing van de drie-eenheid kwaliteit, geld en tijd. Eén van de zaken waarmee een doortimmerd kwaliteitsbeleid staat of valt, is een gedegen, goed gefaseerde, strakke planning. Want alleen strak plannen en voortdurend controleren resulteert in een product dat voldoet aan de verwachtingen van de klant. Een goede planning schept echter niet alleen duidelijkheid naar de klant: ook het eigen personeel heeft er baat bij. Daarom worden op de volgende pagina’s uitgebreid de verschillende fasen behandeld die PPPP-IT onderscheidt in de levensloop van een informatiesysteem.

5.2.1 Definitiestudie

De definitiestudie is de eerste fase in de ontwikkeling van een informatiesysteem. Het doel van deze fase is: het definiëren en selecteren van de oplossingsrichting en het onderzoeken of deze oplossingsrichting economisch, technisch, sociaal en organisatorisch haalbaar is. De activiteiten in hun onderlinge samenhang zijn duidelijk weergegeven in figuur 2, (zie volgende pagina). Eerst volgt een korte toelichting op de activiteiten uit de definitiestudie.

Activiteit 1.1.
De definitiestudie begint zoals elke fase met het vastleggen van de uitgangspunten en het opstellen van het plan van aanpak. In termen van Prince 2 is dit te beschouwen als de projectdefinitie.
Deze activiteit levert twee producten op:

• De Werkopdracht:
  de door de opdrachtgever goedgekeurde opdracht waarin de basis wordt gelegd voor een gezond project met een aanvaardbaar risico. Aangezien de definitiestudie de basis vormt voor een aantal beleidskeuzes, wordt het daadwerkelijk uitvoeren van deze studie als een zelfstandig deelproject beschouwd, dat meestal als opdrachttype 1 wordt uitgevoerd.
• Het Plan van Aanpak:
  een duidelijke beschrijving wanneer welke producten tot stand komen, wie welke taken en verantwoordelijkheden heeft en langs welke weg de producten gerealiseerd worden. Het Kwaliteitshandboek vormt hiervoor de stevige basis.
  Beide producten zijn een mijlpaalproduct.

Figuur 5: De activiteiten behorend bij de Definitiestudie

Activiteiten 1.2 t/m 1.4: De informatieanalyse
Hierbij worden op basis van een analyse van de huidige èn de gewenste situatie de eisen en criteria vastgesteld waaraan de gewenste informatievoorziening moet voldoen. Als werkwijze en afbeeldingswijze wordt een mix gebruikt van ISAC-technieken en Yourdon Stuctured Analysis. Voor het beschrijven van de organisatorische gevolgen worden relatiematrices en technieken voor de administratieve organisatie gebruikt. De in activiteit 1.3 gedefinieerde systeemeisen vormen eveneens een mijlpaalproduct.

Activiteiten 1.5 t/m 1.7
Deze activiteiten richten zich op het definiëren van de hoofdfuncties, gegevensverzamelingen en interacties van het gewenste informatiesysteem. Ze geven antwoord op de vragen welke middelen hiervoor kunnen worden aangewend, naar welke oplossing de voorkeur uitgaat en welke eisen en consequenties deze oplossing heeft voor de organisatie en haar middelenvoorziening. De gekozen systeemoplossing (activiteit 1.7) is weer een mijlpaalproduct. De samenhang en de te volgen denkwijze voor activiteiten 1.2 t/m 1.5 (de informatieanalyse en het systeemconcept) is schematisch weergegeven in figuur 6.

Figuur 6: Samenhang en denkwijze informatieanalyse en systeemconcept

 In het systeemconcept wordt de basis voor het totale systeem ontworpen en weergegeven in een functie- en een gegevensmodel. Deze modellen worden ontwikkeld met behulp van respectievelijk Yourdon Structured Analysis en Entity Relationship Modelling.

Activiteiten 1.8 t/m 1.11
Het ontwikkelen van plannen die het mogelijk maken om een go/no go’-beslissing te nemen. In termen van Prince 2 is dit te beschouwen als het Project Initiatie Project (PID) voor het totale project.
In een dergelijk ontwikkelingsplan wordt aangegeven hoe de ontwikkeling van het systeem wordt aangepakt, welke hulpmiddelen en faciliteiten hiervoor nodig zijn en hoe de ontwikkeling in de tijd gerealiseerd kan worden. De Definitiestudie-fase wordt afgesloten met een eindrapport (1.11), waarin de economische, technische en sociaal/organisatorische haalbaarheid beschreven wordt. Ook dit Rapport Definitiestudie is een mijlpaalproduct.
Tenslotte: door het uitvoeren van een kosten/baten analyse heeft de Definitiestudie het karakter van het voorbereiden van een investeringsbeslissing.
Tot zover een toelichting op de activiteiten van de eerste fase, de Definitiestudie.Hierna wordt door de klantorganisatie beslist of en hoe met de systeemontwikkeling moet worden verder gegaan.

5.2.2 Basisontwerp

Het Basisontwerp is de tweede fase van systeemontwikkeling die het totale systeem betreft. Voortbordurend op hetgeen tijdens de Definitiestudie in kaart is gebracht, vormt het Basisontwerp letterlijk de basis, het fundament onder elk te ontwikkelen systeem.
Het Basisontwerp verschaft de gemeenschappelijke basis op grond waarvan te onderscheiden delen van het systeem afzonderlijk verder ontwikkeld kunnen worden. Daartoe worden zowel het systeemconcept als de systeemoplossing tot een zodanig niveau gedetailleerd, dat gewenste systeemdelen die in deelprojecten verder worden ontwikkeld, kunnen worden gedefinieerd. Bovendien moeten de interfaces tussen deze systeemdelen en die met andere systemen tot op detailniveau worden uitgewerkt. Dit impliceert tevens, dat vrijwel alle belangrijke ontwerpbeslissingen in het basisontwerp gemaakt moeten worden. Voorts moet bepaald worden, welke functies handmatig en welke geautomatiseerd uitgevoerd moeten worden.
De activiteiten in hun onderlinge samenhang zijn weergegeven in figuur 7.

Activiteitenschema Basisontwerp

Figuur 7: Het Basisontwerp: de fundering onder elk informatiesysteem

 
Hier volgt een korte toelichting op de in figuur 7 gepresenteerde activiteiten uit het Basisontwerp.

Activiteit 2.1: Uitgangspunten en Plan van Aanpak
Deze activiteiten leveren twee producten op:

• De werkopdracht:
  De basis voor een gezond project met een aanvaardbaar risico wordt hierin (vast)gelegd. Het uitgangspunt voor de werkopdracht is het Rapport Definitiestudie en de wijzigingen die de opdrachtgever heeft aangebracht naar aanleiding van dit rapport. Aangezien in het Basisontwerp belangrijke ontwerpbeslissingen genomen moeten worden en deelprojecten worden gedefinieerd, wordt het uitvoeren van een Basisontwerp als een zelfstandig deelproject beschouwd.
  Als PPPP-IT niet betrokken is geweest bij de Definitiestudie en wel projectverantwoordelijkheid draagt voor het Basisontwerp (opdrachttype 2), zal voor het opstellen van de opdracht een risicoanalyse en een audit op het Rapport Definitiestudie worden uitgevoerd, om te voorkomen dat de opdrachtgever met negatieve gevolgen van een slecht uitgangsproduct geconfronteerd wordt.
• Het Plan van Aanpak:
  Net als bij de Definitiestudie is het Plan van Aanpak ook hier een duidelijke beschrijving wanneer welke producten tot stand komen, wie welke taken en verantwoordelijkheden heeft en langs welke weg de producten gerealiseerd worden. Formeel is het Plan van Aanpak hetzelfde als bij de Definitiestudie, inhoudelijk is het hier geheel toegesneden op de fase van het Basisontwerp.

De producten van activiteit 2.1 zijn mijlpaalproducten.

Activiteiten 2.2 t/m 2.4
Definiëring van de functies van het informatiesysteem vanuit de eisen die de toekomstige werkomgeving aan het gebruik van dat systeem stelt.
Ook worden in dit stadium de gegevensverzamelingen beschreven en de dialogen vastgelegd. Het systeem wordt daarbij in functionele termen beschreven. Het wordt daarin voor de gebruiker zichtbaar wàt het systeem gaat doen, zonder dat in eerste instantie het hoè wordt ingevuld. Ook moet nu de keuze gemaakt worden welke functies handmatig en welke geautomatiseerd worden.
Voor het vastleggen van de toekomstige werkomgeving worden technieken voor de vastlegging van de administratieve organisatie gebruikt. De gegevensstructuur wordt met behulp van Entity Relationship Modelling bepaald en de functiestructuur via Yourdon Structured Analysis.

Activiteiten 2.5 en 2.6
Definiëring technische basisstructuur. Daarbij kunnen technische hulpmiddelen en faciliteiten gemeenschappelijk worden gebruikt door verschillende informatiesystemen. Die informatiesystemen zijn vaak al operationeel en daarom zal er gebruik moeten worden gemaakt van de beschikbare hulpmiddelen, of zullen nieuwe hulpmiddelen hierop moeten worden afgestemd. De eisen die in technische zin gesteld worden aan hardware en software worden in activiteit 2.5 nader gepreciseerd. De technische structuur uit activiteit 2.6 wordt ontworpen met behulp van Yourdon Structured Design.

Activiteiten 2.7 en 2.8
Aanscherping van de plannen uit de definitiestudie. Tevens te beschouwen als een aangescherpt PID in termen van Prince 2.

Activiteit 2.9: Het opstellen van het Eindrapport Basisontwerp
Hierin is een systeemontwikkelingsplan opgenomen waarin de ontwikkelstrategie wordt beschreven die aangeeft hoè het systeem in gedeelten zal worden gerealiseerd en op wèlke wijze en met het gebruik van wèlke faciliteiten dit zal gebeuren. Voor het opstellen van het plan is de projectleider verplicht gebruik te maken van functie-punt-analyse en risicoanalyse. De projectleider initieert tenslotte een kwaliteitsaudit.

Tot zover de fase van het Basisontwerp. In de nu volgende fase kunnen één of meer delen uit het Basisontwerp meer in detail uitgewerkt worden: de fase van het Detailontwerp.

5.2.3 Detailontwerp

In de fase van het Detailontwerp zijn we aangekomen op het punt waarop één of meer delen van het systeem uit het Basisontwerp in detail uitgewerkt/ontworpen worden. Op deze wijze kan beter gebruik gemaakt worden van de beschikbare mensen en middelen.

Het Detailontwerp richt zich op het voltooien van de in het Basisontwerp aangegeven systeemspecificaties. En wel op een zodanig niveau, dat in de hierna volgende Realisatiefase begonnen kan worden met de daadwerkelijke bouw van het systeem.
De activiteiten die in de Detailontwerpfase ontplooid worden zijn in figuur 8 in hun onderlinge samenhang weergegeven.

Activiteitenschema Detailontwerp

Figuur 8: De activiteiten behorend bij de het Detailontwerp

 In dit stadium van het project kunnen meerdere parallelsporen onderkend worden, waarvoor verschillende opdrachttypes gedefinieerd kunnen worden. Naast de pure systeemontwikkeling kunnen we de organisatie ontwikkeling, het voorbereiden van de acceptatietest en de conversie en het opleiden onderscheiden.
Het spreekt vanzelf dat de afbakening van de onderdelen in goed overleg tot stand moet komen.
Hieronder worden de tot deze fase behorende activiteiten meer ‘in detail’ toegelicht.

Activiteit 3.1
Deze activiteit levert de volgende twee producten op:

• De werkopdracht: de basis voor een gezond detailontwerp.
  De basis hiervoor wordt gevormd door het Rapport Basisontwerp en eventueel de wijzigingen die de opdrachtgever heeft aangebracht naar aanleiding van dit rapport. Aangezien in het basisontwerp de belangrijke ontwerpbeslissingen reeds genomen zijn, is het mogelijk dat de fasen 3 en 4 (respectievelijk Detailontwerp en Realisatie, zie ook volgende paragrafen) als één project geoffreerd worden en daarom een aparte projectopdracht kennen.
• Het Plan van Aanpak:
  de beschrijving wanneer welke producten tot stand komen, wie welke taken en verantwoordelijkheden heeft en langs welke weg de producten gerealiseerd worden. Het handboek vormt hiervoor weer een uitstekende basis.

De producten van activiteit 3.1 zijn mijlpaalproducten.

Activiteit 3.2 t/m 3.7
In het eerste deel van het Detailontwerp worden de functionele specificaties verder in detail uitgewerkt en beschreven. Vanuit de gedetailleerde structuur van de toekomstige werkomgeving (activiteit 3.2) worden de elementaire functies beschreven in activiteit 3.3. Het gaat daarbij om alle typen gebruikersspecificaties, inclusief de handmatige functies en de gedetailleerde prestatie-eisen. Vervolgens worden de elementen van de gegevensverzamelingen gedefinieerd (activiteit 3.4) en worden de mens x machine interfaces vastgelegd in activiteit 3.5.

Bij activiteit 3.2 wordt gebruik gemaakt van vastleggingstechnieken voor administratieve organisatie. Voor de activiteiten 3.3 en 3.5 wordt gebruik gemaakt van Yourdon Structured Analysis and Design, terwijl activiteit 3.4 wordt uitgevoerd met behulp van Entity Relationship Modelling.

Het eerste deel wordt afgesloten met een Functioneel Ontwerp Rapport en het bijbehorende validatierapport, (activiteiten 3.6 en 3.7).
In het Functioneel Ontwerp Rapport ligt dus in feite de volledige specificatie van het systeem vast en is het normeren van het aspect ‘kwaliteit’ afgerond.
Het is van het grootste belang dat dit rapport grondig geverifieerd wordt door de gebruikers en geaccepteerd wordt door het gebruikersmanagement. Wijzigingsvoorstellen van de gebruikers hoeven daardoor niet meer voor te komen, hetgeen een sterke reductie op de bouwkosten zal geven.
Het rapport vormt dan ook de basis voor de acceptatietest.

Activiteit 3.8 t/m 3.12
Na acceptatie van het Functioneel Ontwerp Rapport kan begonnen worden met het in technische zin verder specificeren en detailleren van het betreffende systeemonderdeel (activiteiten 3.8 t/m 3.12).
Vanaf dit moment gaan de gebruikers en de informatici in aparte werkgroepen verder.
De gebruikers houden zich bezig met het ontwerpen van procedures en het formuleren van de gebruikershandleiding. Daarnaast beginnen ze de acceptatietest voor te bereiden. Bovendien kunnen een aantal activiteiten uit de fase invoering nu al gestart worden.
Het belangrijkste aspect voor de informatici in het tweede deel van het Detailontwerp is de inbedding van het systeemonderdeel in zijn toekomstige technische omgeving. De specificaties worden zodanig opgesteld en structureel geordend, dat deze geprogrammeerd en getest kunnen worden. De structuur en fysieke organisatie van bestanden en programma’s worden vastgelegd. De bewerkingen worden zowel beschreven als vastgelegd in een gedetailleerde programmatuurspecificatie. Alle interfaces van het systeemonderdeel met zijn interne en externe omgeving worden tot op het laagste detailniveau gespecificeerd.

Activiteit 3.13 t/m 3.16
Na een laatste beoordeling van de technische specificaties wordt de fase Detailontwerp afgesloten met het voorbereiden van een gedetailleerd testplan (activiteit 3.13) en een rapport Detailontwerp (activiteit 3.16), waarin opgenomen een plan voor realisatie en invoering.
Voor het procedureontwerp worden technieken voor administratieve organisatie geadviseerd, terwijl voor het vastleggen van de specificatie van het geautomatiseerde systeem Yourdon Structured Design wordt gebruikt.

5.2.4 Realisatie

In deze fase wordt het door de klant verlangde ontwerp op grond van de specificaties uit het Detailontwerp omgezet in de realiteit en vervolgens productierijp gemaakt.
De bij deze fase behorende activiteiten zijn in figuur 9 in hun onderlinge samenhang weergegeven.

Activiteitenschema Realisatie

Figuur 9: De activiteiten behorende bij de Realisatie

 Het realiseren van het systeemonderdeel betreft het creëren van databases, het maken van de benodigde handmatige routines en geautomatiseerde programmamodules en het nemen van maatregelen voor het testen van het systeem en het opleiden van de gebruiker.
Voorts wordt het systeem getest op zowel programmaniveau als op systeemniveau.
Tenslotte wordt door de toekomstige gebruikers in een acceptatietest beoordeeld of de werking van het systeem (inclusief systeembeheer en productie) voldoet aan de verwachtingen en gestelde eisen, zodat het daarna bij akkoord kan worden ingevoerd. Dit betreft zowel de gedeelten van het systeemonderdeel die handmatig zullen worden uitgevoerd, als de delen die geautomatiseerd zullen gaan worden.
Hoewel de te gebruiken programmeertalen sterk kunnen verschillen, zal de programmering in ieder geval via gestructureerde technieken worden uitgevoerd.

5.2.5 Invoering

Gedurende de invoeringsfase worden zowel het systeemonderdeel als de werkomgeving waartoe het onderdeel gaat behoren gereed gemaakt voor gebruik. Het systeem kan ingevoerd worden in de dagelijkse praktijk, waarvoor het in samenspel tussen klant en PPPP-IT gecreëerd is.
Waarbij op voorhand nog eenmaal voor alle duidelijkheid gesteld dient te worden dat de vóórbereiding op die daadwerkelijke invoering reeds in een vroeger stadium getroffen moet zijn.
Dat begint al direct na de beslissing tot aanschaf of bouw van een nieuw informatiesysteem, bijvoorbeeld door het geven van voorlichting. Een belangrijke factor voor het welslagen van de invoering van het systeemonderdeel in de gebruikersorganisatie is namelijk de mate waarin de gebruiker betrokken is geweest bij de totstandkoming ervan. Goede en tijdige voorlichting en opleiding zijn essentieel met het oog op het uiteindelijk alles overheersende doel: de acceptatie van het systeem door tevreden gebruikers.
De klant is en blijft daarbij koning, PPPP-IT een meedenkende partner! De primaire verantwoordelijkheid voor de invoering ligt dan ook bij de gebruikersorganisatie. De informatici spelen een ondersteunende en adviserende rol.
In figuur 10 zijn de activiteiten in hun onderlinge samenhang weergegeven.

Activiteitenschema Invoering

Figuur 10: De activiteiten behorende bij de Invoering

 Zoals figuur 10 laat zien, worden tijdens de invoeringsfase taakbeschrijvingen opgesteld, de gegevensverzamelingen opgebouwd in hun nieuwe vorm en worden de gebruikers van het systeem opgeleid.
Het systeem zal tenslotte worden overgedragen aan de lijnorganisatie, die voor de goede werking daarvan de volledige verantwoordelijkheid gaat dragen.
Tot zover de diverse fasen die PPPP-IT onderkent in de ontwikkeling van een informatiesysteem. Deze fasering dient om in de ontwikkeling van dat informatiesysteem de verschillende mijlpalen te onderkennen en het systeem op te splitsen in overzichtelijke, goed hanteerbare eenheden.
Aangegeven werd hòe PPPP-IT in de diverse fasen (van Definitiestudie, Basisontwerp, Detailontwerp en Realisatie tot de uiteindelijke invoering) omgaat met het begrip Kwaliteit.
Het is PPPP-IT echter duidelijk dat het werk er na een perfecte voorbereiding, goede planning en dito uitvoering geenszins opzit. Goed onderhoud en beheer zijn eveneens onmisbare pijlers onder de kwaliteitsbenadering van PPPP-IT.

5.3 Onderhoud van informatiesystemen

De onderhoudskosten over de life cycle van een informatiesysteem zijn vaak aanzienlijk hoger dan de ontwikkelingskosten. Bovendien is de zorgvuldigheid van het onderhoud in hoge mate bepalend voor de levensduur van een systeem. Redenen waarom PPPP-IT kiest voor een projectmatige aanpak van het zo belangrijke onderhoudsaspect. Dit betekent dat er per jaar een nader met de klant overeen te komen aantal releases van een informatiesysteem gemaakt wordt. Voor elke release wordt dan vervolgens een project ingericht, waarin kwaliteit, tijd en geld beheerst worden conform het geldende kwaliteitssysteem.

5.3.1 Onderhoudsaanpak

De projectmatige aanpak van onderhoud is in feite niets anders dan het in kort bestek toepassen van diverse ontwikkelingsfasen van het Kwaliteitshandboek, zoals die hiervoor zijn gepresenteerd.
Deze aanpak bevat de volgende stappen:

• Problemen en wensen van de gebruikers worden aangemeld. Het verwerken ervan vindt plaats conform de wijzigings- of probleemrapportageprocedure. Daarnaast vindt per release een evaluatie plaats, waarin actief geïnventariseerd wordt welke overige wensen nog leven bij de gebruikers. Deze evaluatie wordt uitgevoerd door een werkgroep bestaande uit applicatiebeheerders en materiedeskundigen van de klant en de contactpersoon van PPPP-IT. Deze groep zorgt ervoor dat de wensen formeel vastgelegd worden in termen van de gewenste oplossing.
• Vervolgens is de contactpersoon verantwoordelijk voor het (laten) maken van een schatting voor de benodigde inspanning. Op basis van deze schatting komt de werkgroep tot een prioriteitsstelling en een definitieve opdrachtformulering voor de ontwikkeling van de nieuwe release. In feite hebben de voorgaande stappen het karakter van een Definitiestudie.
• Hierna stelt de werkgroep prioriteiten en geeft opdracht aan de contactpersoon om het project te plannen opdat het onderhoudswerk uitgevoerd kan worden. Dan worden door de werkgroep de gewijzigde functionele specificaties vastgelegd en overgedragen aan de onderhoudsgroep, één en ander vanzelfsprekend op basis van de specificaties van de gebruiker. Er is hier dus eigenlijk sprake van een Functioneel ontwerp. Als een bepaald project van grote omvang is of complex van aard, kan hiervoor ook een ontwerper van PPPP-IT ingezet worden om de onderhoudbaarheid van het systeem niet in gevaar te brengen. Indien het ook veranderingen in de hardware of systeemsoftware betreft, worden eerst de consequenties ervan geanalyseerd. In dit laatste geval wordt er in feite een verkort Basisontwerp uitgevoerd.
• De onderhoudsgroep verwerkt de specificaties in het technisch ontwerp (documenteren) en realiseert vervolgens de nieuwe release. Vervolgens worden de programmatest en de systeemtest uitgevoerd door het onderhoudsteam. In termen van het Kwaliteitshandboek is dit de uitvoering van het technisch Detailontwerp en de Realisatie.
• Tenslotte voert de aangewezen testgroep van de klant de acceptatietest uit en na acceptatie worden de gebruikers van het systeem geïnformeerd en wordt de release overgedragen aan de productie. Zonodig wordt het productieplan aangepast en worden eventuele conversies uitgevoerd.

5.3.2 Urgent onderhoud

Uiteraard zullen er situaties voorkomen dat onderhoud echt niet kan wachten tot de volgende release. Na erkenning van de noodzaak ervan door de applicatiebeheerder en aanmelding bij de contactpersoon, zal in dergelijke gevallen het noodzakelijke onderhoud zo spoedig mogelijk uitgevoerd worden in de vorm van een noodoplossing. Het is dan wel verplicht dat in de volgende release deze noodoplossing vervangen wordt door een regulier tot stand gekomen wijziging.
Het beleid van de werkgroep zal er dan ook op gericht zijn om dergelijk onderhoud zoveel mogelijk te voorkomen. Bijvoorbeeld door de planning van een nieuwe release af te stemmen op een aangekondigde wetswijziging. En natuurlijk door problemen actief op te sporen voor ze urgent worden. Voorkomen is immers beter dan genezen.
Dus, ter voorkoming van ‘noodzaken’: goed onderhoud, een noodzaak!

6. Inrichting van het project

In deel 3 van dit artikel werken we dit aspect verder uit.

7. Meer over kwaliteitsbeheer ICT

Meer over kwaliteitssystemen vindt u in de rubrieken ‘Kwaliteitsmanagement ICT‘.

8. Nawoord

Tot zover de methodiek voor systeemontwikkeling op basis van SDM.
In deel 3 van dit kwaliteitshandboek gaan we verder in op Projectbeheersing. Het raamwerk voor het kwaliteitshandboek vindt u in deel 1.

Download:         

Gerelateerde artikelen:

1. Voorbeeld opzet handboek voor ICT kwaliteit deel 3
2. Voorbeeld opzet handboek voor ICT kwaliteit deel 1
3. Methode en checklist pakketselectie en -implementatie deel 1

1. Toelichting op dit document
2. Inleiding: duidelijkheid als sleutelwoord
3. Duidelijke doelstellingen PPPP-IT
4.  Het PPPP-IT kwaliteitssysteem
   4.1 De gebieden waaruit de kwaliteitszorg bestaat
   4.1.1 Kwaliteitsvoorwaarden vooraf
   4.1.2 De projectinterne kwaliteitsborging
   4.1.3 De onafhankelijke kwaliteitsbeoordeling door middel van audits
   4.2 Inrichting opdrachtbeheer en kwaliteitszorg PPPP-IT
   4.3 Kwaliteitsnormen
   4.3.1 Procesdimensie
   4.3.2 De statische dimensie
   4.3.2 De dynamische dimensie
   4.4 Opdrachttypes
   4.5 Opbouw handboek: de drie niveaus
5. De systeemontwikkelingsmethode
6. Inrichting van het project
7. Meer over kwaliteitsbeheer ICT
8. Nawoord 

1. Toelichting op dit document

Dit document bevat een voorbeeld van een kwaliteitshandboek ICT, dat daadwerkelijk is geïmplementeerd in de praktijk. Het gaat in op systeemontwikkeling (waterval methode SDM-2), beheer (ITIL-based) en projectmanagement (ook mogelijk via Prince 2).
Het handboek is geschreven vanuit de behoefte van de bedrijfsprocessen en gebruikers en is bedoeld om de ICT-afdeling zo te laten werken, dat aan de gebruikers een adequate informatie voorziening wordt gegarandeerd. Er wordt dan vooral ook ingezoomd op de activiteiten die voor de gebruikers van belang zijn, zodat ook zij begrijpen, dat hun participatie cruciaal is om dit te realiseren. Het maakt hierbij niet uit of het een interne of externe ICT-afdeling betreft. Zeker ook in het geval van outsourcing is dit handboek bruikbaar om tot een werkzame samenwerking te komen, waarbij taken, verantwoordelijkheden en bevoegdheden zijn vastgelegd.     

Om hergebruik gemakkelijk mogelijk te maken, is de bedrijfsnaam vervangen door PPPP. Via zoek en vervang kunt u hier uiteraard de naam van uw organisatie invullen.     

Het handboek is gezien zijn omvang opgesplitst in drie delen, om problemen met downloaden te voorkomen.     

Uiteraard kan ZBC u ondersteunen bij de aanpassing en de invoering van dit handboek en het verzorgen van workshops aan betrokkenen.      

2. Inleiding: duidelijkheid als sleutelwoord

Het kwaliteitssysteem, zoals is beschreven in dit handboek, dient verschillende doelen.
Het weerspiegelt het grote belang dat PPPP-IT hecht aan een goed doortimmerd kwaliteitsbeleid. In dat opzicht schept het duidelijkheid in twee richtingen, zowel naar de klant als naar de eigen medewerkers, duidelijkheid over een internationaal aanvaarde definitie van kwaliteit, omschreven in de NEN-ISO norm 8402 en duidelijkheid over werkwijzen zoals die in de normen ISO 9000-2000 staan.
PPPP-IT streeft te allen tijde naar ‘fixed quality’ door een constante beheersing van kwaliteit, naast de beheersing van tijd en geld. Dat kan alleen door toewijzing van taken, verantwoordelijkheden en bevoegdheden. Daarmee kunnen klant en PPPP-IT langs beproefde wegen tot een beter eindresultaat komen. Klanten kunnen rekenen op een meedenkende PPPP-IT, een partner. Partnership leidt tot helderheid over de verhouding tussen prijs en prestatie.
PPPP-IT richt zich voortdurend op het bieden van de juiste kwaliteit, passend bij de behoeften van de klant. Het handboek sluit hier nadrukkelijk op aan. Het biedt duidelijke handvatten, voorschriften en procedures om uiteindelijk het allesbepalende doel te bereiken: een beter product en een tevreden klant. Dat kan alleen als het kwaliteitsstreven ver wordt doorgevoerd in de organisatie. Gesteund door opleidingsprogramma’s die medewerkers in staat stellen de producten met het vereiste kwaliteitsniveau te ontwikkelen.     

Wat wordt er gedaan, hoe en volgens welke normen?
Wat is de rol van het handboek in dit geheel?   

Het boek formuleert in eerste instantie de uitgangspunten. Producten van PPPP-IT moeten niet zomaar ‘goed’ zijn. Systemen dienen de prestatie te leveren die de klant nodig heeft. Systemen horen aan belangrijke criteria te voldoen als betrouwbaarheid, gebruikersvriendelijkheid en effectiviteit. Daarnaast moeten de PPPP-IT-producten enerzijds tegen concurrerende prijzen worden aangeboden en anderzijds over de totale life-cycle van het systeem een kostenreductie opleveren door een efficiënter onderhoud van het systeem.
Het handboek is een middel om tot het beste resultaat te komen. Het geeft normen voor de kwaliteit van producten en processen. Betrokkenen vinden in dit standaardwerk wat de producten zijn en hoe die producten tot stand moeten komen en hoe in het delicate samenspel tussen klant en PPPP-IT de voorwaarden worden geschapen voor het beste resultaat.
Het handboek is niet slechts gemaakt om regeltjes en voorschriften te introduceren. Dit kwaliteitshandboek doet meer. Het legt de basis, is een stevige theoretische fundering voor een succesvolle praktijk.    

3. Duidelijke doelstellingen PPPP-IT

Doelstelling van PPPP-IT is een klantgerichte dienstverlener te zijn, die producten levert met een goede prijs/prestatieverhouding. Om dat te kunnen zijn, heeft PPPP-IT de volgende algemene doelstellingen gedefinieerd:    

• het waarborgen van de productkwaliteit en de kwaliteit van de dienstverlening door het definiëren van duidelijke normen en de bewaking hiervan;
• het reduceren van kosten over de totale lifecycle van een systeem; dat kan door efficiënt te werken op basis van duidelijke standaards en procedures;
• het zò inrichten van de projectbeheersing, dat het resultaat optimaal aan de verwachtingen van de klant voldoet.

Met deze doelstellingen in de hand heeft PPPP-IT een kwaliteitssysteem opgezet dat bestaat uit de volgende elementen:    

• een uit drie lagen bestaand Kwaliteitshandboek, waarin werkwijze, normen, standaards, procedures, productbeschrijvingen en dergelijke zijn vastgelegd;
• een organisatie die is ingericht om projectmatig te kunnen werken; door het op de juiste wijze toewijzen van alle taken, verantwoordelijkheden en bevoegdheden worden kwaliteit, tijd en geld optimaal beheerst en gewaarborgd;
• een opleidingsprogramma dat de medewerkers in staat stelt de producten van de door de klant vereiste kwaliteit te maken.

Zó geeft PPPP-IT zowel de klant als de eigen medewerkers optimale duidelijkheid over wat er gedaan moet worden, wat er verwacht mag worden en hoe dit van beide kanten bewaakt moet worden.     

In de volgende hoofdstukken wordt in het kort uit de doeken gedaan hoe PPPP-IT dit alles concreet in praktijk brengt. Het is immers de dagelijkse praktijk waarin een product zichzelf moet bewijzen.    

4. Het PPPP-IT kwaliteitssysteem

Het kwaliteitssysteem van PPPP-IT is gebaseerd op de internationaal aanvaarde ISO-standaards. Omdat deze ISO-standaards zo algemeen zijn, heeft PPPP-IT deze standaards geconcretiseerd en vastgelegd in een reeks van handboeken.
Toepassing van deze handboeken moet er toe leiden, dat de dienstverlening en de producten kwalitatief goed zijn. Kwaliteit, zoals het begrip vastgelegd is in de ISO norm 8402:   

“Kwaliteit is het geheel van eigenschappen en kenmerken van een product of dienst, dat van belang is voor het voldoen aan vastgelegde en vanzelfsprekende behoeften.”   

• Concreet komt het erop neer, dat kwaliteit datgene is, wat de klant nodig heeft; niet meer en niet minder. Dat betekent, dat:
• de kwaliteit van het systeem niet alleen bepaald wordt vanuit functioneel of technisch perspectief, maar vooral vanuit organisatorisch en bedrijfseconomisch perspectief;
• kwaliteit niet alleen een zaak van de controleurs is, maar van alle betrokkenen binnen en rondom het project. van zowel de kant van de klant als van PPPP-IT;
• kwaliteitszorg een integraal onderdeel wordt van zowel de voorbereiding op als de uitvoering en de afronding van het project.

In dit hoofdstuk wordt ingegaan op:     

• de onderdelen waaruit de kwaliteitszorg in de verschillende fasen van het project bestaat;
• hoe PPPP-IT deze kwaliteitszorg organisatorisch heeft ingericht;
• wat er genormeerd en bewaakt moet worden om de vereiste kwaliteit te realiseren;
• projecttypes, teneinde het mogelijk te maken mogelijke verdelingen van verantwoordelijkheden met de bijbehorende bevoegdheden tussen de klant en PPPP-IT bespreekbaar te maken en te regelen.

4.1 De gebieden waaruit de kwaliteitszorg bestaat

We onderkennen een drietal gebieden die op het juiste moment de aandacht moeten krijgen om de vereiste kwaliteit te kunnen realiseren:     

• de kwaliteitsvoorwaarden vooraf;
• de projectinterne kwaliteitsborging;
• de onafhankelijke kwaliteitsbeoordeling door middel van audits.

4.1.1 Kwaliteitsvoorwaarden vooraf

PPPP-IT onderkent een vijftal voorwaarden vooraf:     

1. Er moeten normen gedefinieerd worden voor de kwaliteit van zowel de dienstverlening als van het product. In par 4.3 wordt een handreiking gedaan voor de inhoud van deze normen.
2. Zowel de klant als PPPP-IT levert medewerkers die vakbekwaam zijn en de bevoegdheden bezitten om de taken waarvoor ze verantwoordelijk zijn, adequaat te kunnen uitvoeren.
3. Er is een methode voor opdrachtmanagement afgesproken, die de verantwoordelijkheden en bevoegdheden en het rollenspel definieert rondom het project. Op deze wijze kan er zorg gedragen worden voor een goede beheersing van het project vanuit de lijnorganisatie van zowel de klant als van PPPP-IT. De globale inrichting van het opdrachtmanagement van PPPP-IT is beschreven in par 4.2. en verder uitgewerkt in het handboek.
4. Er is een methode voor projectmanagement, waarmee op projectniveau de beheersaspecten tijd, geld, kwaliteit, organisatie en informatie beheerst worden. Hiervoor kan de PPPP-IT-methode gehanteerd worden. Een globale beschrijving hiervan is terug te vinden in hoofdstuk 6. Een nadere uitwerking is opgenomen in de module projectbeheersing en kwaliteitsbewaking.
5. Er is een methode voor systeemontwikkeling, die binnen het project wordt toegepast en waarmee de functionele en technische kwaliteit van producten gerealiseerd wordt. In hoofdstuk 5 is een korte beschrijving weergegeven, die in verschillende andere modules van het handboek nader wordt uitgewerkt.

4.1.2 De projectinterne kwaliteitsborging

Binnen een project onderscheiden we drie onderdelen:     

1. Bij de projectstart worden de gemaakte afspraken over de kwaliteitsvoorwaarden vooraf vertaald in concrete standaards, procedures en maatregelen en vastgelegd in het kwaliteitsplan. Dit kwaliteitsplan vormt een onderdeel van het projectplan of van het plan van aanpak.
2. Het ontwikkelproces is zodanig opgezet, dat de ontwikkelaars zelf bewust kwaliteit ‘maken’ door in de methode voor systeemontwikkeling normen voor het proces vast te leggen. Het bekendste voorbeeld hiervan is het testen, dat als normale ontwikkelactiviteit in de methode is opgenomen.
3. Binnen het project wordt elk product bekeken door specifiek hiervoor aangewezen “beoordelaars”, die enerzijds de technische juistheid, volledigheid en de consistentie bekijken en anderzijds of het product de gespecificeerde functionaliteit bezit.

4.1.3 De onafhankelijke kwaliteitsbeoordeling door middel van audits

Onafhankelijk van de projectleiding laat PPPP-IT onder verantwoordelijkheid van het kwaliteitsmanagement audits uitvoeren, om te beoordelen of de producten en de dienstverlening voldoen aan de gestelde kwaliteitseisen. Wanneer daarbij tekortkomingen worden geconstateerd moet de opdrachtleiding actie ondernemen, om het geheel in overeenstemming te brengen met de kwaliteitseisen.
Op deze wijze is de lijnorganisatie van PPPP-IT in staat om tegenover haar klanten haar verantwoordelijkheid met betrekking tot de kwaliteitsbeheersing waar te maken.
Hiertoe gebruikt PPPP-IT als instrument een vijftal auditsoorten, die voorzien in de behoefte van PPPP-IT om de kwaliteitsbeheersing mogelijk te maken. Uiteraard kunnen deze audits ook als dienstverlening in opdracht van een klant worden uitgevoerd op projecten van derden of van PPPP-IT zelf.
Deze vijf auditsoorten kunnen als volgt gekarakteriseerd worden:     

1. Projectdiagnose:
   een gemeenschappelijke analyse door de klant en PPPP-IT van de uitgangspositie van een (deel-)project, die de risico’s en de haalbaarheid vooraf in kaart brengt; door het nemen van adequate maatregelen kunnen dan latere onwelkome verrassingen voorkomen worden;
2. Kwaliteits(systeem)inspectie:
   een toetsing op het functioneren van het kwaliteitssysteem; dit is een snelle en oppervlakkige audit, die zonodig gevolgd kan worden door een van de volgende twee diepte audits;
3. Productaudit:
   een onderzoek of bepaalde producten voldoen aan de overeengekomen en vanzelfsprekende behoeften van de klant;
4. Projectmanagementaudit:
   een onderzoek of de opdrachtleiding en de projectleiding het project goed in handen hebben en in hoeverre het project nog binnen budget en doorlooptijd afgerond kan worden;
5. Projectevaluatie:
   een evaluatie tijdens de afronding van een (deel-)project om te zorgen, dat de opgedane ervaringen ten goede komen aan volgende projecten; uiteraard wordt de projectleiding bij deze audit wel betrokken.

4.2 Inrichting opdrachtbeheer en kwaliteitszorg PPPP-IT

Het primaire proces van PPPP-IT, het uitvoeren van opdrachten, wordt uitgevoerd door het hoofd IT samen met projectteams en ICT-BEHEER.
Het hoofd IT treedt op als opdrachtnemer voor projecten ten behoeve van klanten.
De teamleider (in principe een groepshoofd) beheert een bepaalde opdracht en rapporteert hierover aan het hoofd IT. De teamleider is verantwoordelijk voor de zowel de kwaliteit van het product als van de dienstverlening.
Het projectteam is een tijdelijk samenwerkingsverband tussen de klant en PPPP-IT, gericht op het uitvoeren van de projectopdracht onder de dagelijkse leiding van een projectleider van de klant (GPL) en een projectleider van PPPP-IT (TPL) Iedere projectleider is verantwoordelijk voor de inbreng van de eigen partij, maar de algehele projectverantwoordelijkheid kan slechts bij één partij liggen, dus slechts bij één van de projectleiders. De projectopdracht en het projectplan moeten daarom uitsluitsel geven over de verantwoordelijkheden en bevoegdheden van beide partijen.
Om deze verdeling eenvoudig bespreekbaar te maken heeft PPPP-IT een tweetal projecttypes gedefinieerd, die elk staan voor een evenwichtige verdeling van verantwoordelijkheden en bevoegdheden.
De verantwoordelijkheid van de kwaliteitszorg ligt bij het hoofd IT. Hij draagt zorg voor de onafhankelijke beoordeling van projecten door reviews en audits (meestal door IC) als de projectinterne kwaliteitszorg (reviews). In principe vindt externe toetsing plaats op alle mijlpaalproducten.
De interne kwaliteitsborging is verantwoordelijk voor de validatie en verificatie van de in het project gerealiseerde producten.     

4.3 Kwaliteitsnormen

Kwaliteit is een bijzonder breed gebied en kent vele invalshoeken. Daarom willen we in deze paragraaf het algemene begrip kwaliteit uiteenrafelen tot dimensies en attributen, om het op deze wijze mogelijk te maken de werkelijke behoefte van de klant onder woorden te brengen. Vervolgens kan via adequate maatregelen en meting ervoor gezorgd worden, dat deze behoeften ook gerealiseerd worden. Bovendien krijgt de klant dan reeds van te voren inzicht in de mogelijke (soms ook negatieve) consequenties van de gestelde eisen.
Sprekend over kwaliteit moeten we allereerst een onderscheid maken tussen proceskwaliteit en productkwaliteit. Binnen de proceskwaliteit kunnen we dan nog een onderscheid maken tussen de kwaliteit die PPPP-IT als opdrachtnemer levert en de kwaliteit die de klant als opdrachtgever levert.
Als we kijken naar de productkwaliteit, kunnen we ook twee invalshoeken onderscheiden: enerzijds de intrinsieke eigenschappen, die de statische kwaliteit van het product bepalen, gezien vanuit de optiek van de ontwikkelaar en de toekomstige beheerder en anderzijds de dynamische kwaliteit, die de functionaliteit van het systeem bepaalt, vanuit het standpunt van de gebruiker. Schematisch is dit weergegeven in figuur 1.    

Figuur 1: Productkwaliteit

We zullen per dimensie kort schetsen welke attributen onderdeel van de dimensie zijn.     

4.3.1 De procesdimensie

De procesdimensie geldt voor zowel de klant als voor PPPP-IT, waarbij de inbreng van de partijen afhangt van het projecttype (zie par.4.4). Als een project is aangenomen op basis van fixed price, fixed date, dan zal de inbreng van PPPP-IT hoger zijn, terwijl bij detachering de inbreng van de klant groter is.
Binnen de procesdimensie onderkennen we de volgende attributen:     

• kwaliteitsvoorwaarden, onder te verdelen in:
  • vakbekwaamheid van de betrokkenen;
  • methode voor opdrachtmanagement met het bijbehorende rollenspel;
  • methode voor projectmanagement met het bijbehorende rollenspel;
  • methode voor systeemontwikkeling.
• kwaliteitscontrole;
• continuïteit;
• volledigheid van dienstverlening;
• uitbesteding.

4.3.2 De statische dimensie

De eisen m.b.t. de statische dimensie zijn primair van belang voor de onderhouds- en beheergroep en worden dan ook primair door deze groep, voor zover aanwezig bij de klant, bepaald.
We onderkennen de volgende attributen:     

• fexibiliteit;
• onderhoudbaarheid;
• testbaarheid;
• portabiliteit;
• connectiviteit;
• herbruikbaarheid;
• geschiktheid infrastructuur.

4.3.3 De dynamische dimensie

De eisen met betrekking tot de dynamische aspecten van het systeem zijn van belang voor het gebruik van het systeem. Deze eisen worden primair bepaald door de gebruikersorganisatie.
De attributen die PPPP-IT onderscheidt, zijn:     

• betrouwbaarheid;
• continuïteit;
• efficiency;
• effectiviteit.

4.4 Opdrachttypes

In de softwareontwikkeling is de uitvoering van iedere opdracht een gezamenlijke verantwoordelijkheid voor opdrachtgever en opdrachtnemer. Daarom benoemen ze ook ieder een projectleider in de projectgroep.
Op grond van de wijze waarop de klant als opdrachtgever en PPPP-IT als opdrachtnemer deze verantwoordelijkheid met elkaar delen, onderscheidt PPPP-IT een viertal opdrachttypes. In volgorde van toenemende verantwoordelijkheid (en dus risico en dus bevoegdheid) voor PPPP-IT zijn dit (zie ook fig 2):    

Figuur 2: Opdrachttypes

Type 1: Productverantwoordelijkheid
PPPP-IT neemt nu tevens de verantwoordelijkheid voor de kwaliteit van de producten. Hiertoe kan PPPP-IT zijn methode voor systeemontwikkeling inbrengen. Decharge is afhankelijk van acceptatie van de eindproducten door de opdrachtgever. Het projectmanagement en daarmee voortgang en kostenontwikkeling blijven verantwoordelijkheid van de opdrachtgever.     

Type 2: Projectverantwoordelijkheid
PPPP-IT neemt nu tevens de verantwoordelijkheid voor het voeren van het projectmanagement. Het project wordt geleid door PPPP-IT op basis van een plan dat door de opdrachtgever is aanvaard. Hiertoe kan PPPP-IT zijn methode voor project- en opdrachtmanagement inbrengen. Omdat financiële consequenties voor de opdrachtgever zijn, legt de PPPP-IT-projectleider verantwoording af aan de opdrachtgever met betrekking tot afwijkingen op dit plan.
Ook kan gekozen worden voor vier opdrachttypen. Dit scenario is uitgewerkt in het artikel over Opdrachttypen.
Omdat PPPP-IT streeft naar een optimale relatie met de klant, zal PPPP-IT in het algemeen adviseren de verantwoordelijkheid te verdelen zoals is weergegeven in figuur 3.     

Figuur 3: Verdeling projectverantwoordelijkheden

Op deze wijze kan de opdrachtgever nadrukkelijk bepalend zijn in het voortraject en bij de activiteiten die verandering voor de eigen organisatie betekenen. Om de relatie met de klant uit te bouwen tot een van beide zijden betrouwbaar partnership, zal PPPP-IT desgevraagd offreren over het gehele traject, waarbij per deeltraject werkopdrachten afgesloten worden.     

4.5 Opbouw handboek: de drie niveaus

In deze Basismodule, het eerste niveau van het PPPP-IT Kwaliteitshandboek, is tot zover vooral ingegaan op de algemeen geldige uitgangspunten en de essenties van het Kwaliteitshandboek. De uìtwerking ervan in concrete normen en standaards vindt in een aantal modules plaats op het tweede niveau. Het derde niveau bestaat uit allerlei referentiemateriaal, dat verkrijgbaar is via het PPPP-IT-netwerk.    

Hieronder kort iets meer over het tweede en derde niveau.     

Tweede niveau
Op het tweede niveau worden de volgende modules onderkent:     

• Inleiding op het tweede niveau:
  In deze module wordt ingegaan op de denkwijze achter het handboek en op module-overschrijdende zaken;
• Systeemontwikkelingsmodules per fase:
  Deze modules op het tweede niveau vormen het hart van de normstelling van het kwaliteitssysteem met betrekking tot de systeemontwikkeling. Er is een module per fase van de systeemontwikkeling, waarin is opgenomen:
• een activiteitenschema;
• een product/betrokkenen matrix.en vervolgens per activiteit: 
  • het doel van de activiteit;
  • aandachtspunten werkwijze;
  • productbeschrijvingen met:
    • inhoud;
    • diepgang
    • bronnen;
    • techniek;
    • hulpmiddelen;
    • plaats product in de documentatie.
• Projectbeheersing en kwaliteitsbewaking
  Deze module bevat onder meer de volgende onderdelen:
• activiteiten en producten voor de fasen voor projectbeheersing:
  • offertestadium;
  • projectvoorbereiding;
  • projectuitvoering;
  • projectafronding.
• projectorganisatie;
• standaards en procedures.
• Onderhoud
  Een module waarin een nadrukkelijke tweedeling gemaakt wordt tussen het projectmatig uitvoeren van onderhoud en het ad hoc uitvoeren ervan. Met betrekking tot het projectmatig uitvoeren van onderhoud worden een aantal projecttypes onderscheiden, met daarbij een globale beschrijving van de aanpak met verwijzingen naar de andere modules. Voor het ad hoc onderhoud wordt een zelfstandige aanpak beschreven.
• Documentatie
  Deze module beschrijft de te onderscheiden dossiers en de documentatiestandaards met onder andere:
  • opbouw projectdossier;
  • opbouw systeemdossier;
  • overige documentatiestandaards.
• Afwijkingen per projecttype en per systeemomgeving
  In deze module gaat het om een definiëring van projecttypen en systeemomgevingen waarvoor op het tweede niveau afwijkende normen gelden. Deze module bevat de belangrijkste afwijkingen en verwijst voorts naar een verdere detaillering op het derde niveau. Invulling van deze module vindt plaats nadat in de praktijk is aangetoond dat afwijkende normen noodzakelijk zijn.
• Verwijzingen
  De module Verwijzingen bevat lijsten met trefwoorden, tabellen en dergelijke die het gebruik en de toegankelijkheid van de handboeken vereenvoudigen.
  Derde niveau

Het derde niveau bestaat uit allerlei referentiemateriaal en is verkrijgbaar in de meeste bibliotheken. Dit materiaal bestaat onder andere uit:     

• checklists;
• specifieke standaards en procedures;
• studiemateriaal met betrekking tot methoden, technieken, hulpmiddelen enzovoort;
• reeds bestaande PPPP-IT-handleidingen;
• van leveranciers afkomstige documentatie en manuals. 

5. De systeemontwikkelingsmethode

Deze beschrijven we in deel 2 van dit artikel.     

6. Inrichting van het project

In deel 3 van dit artikel werken we dit aspect verder uit     

7. Meer over kwaliteitsbeheer ICT

Meer over kwaliteitssystemen vindt u in de rubrieken ‘Kwaliteitsmanagement ICT‘.    

8. Nawoord

Tot zover de Basismodule van het PPPP-IT Kwaliteitshandboek, waarin de algemene uitgangspunten en de essentie van PPPP-IT’s kwaliteitsstreven zijn uiteengezet.
De uitwerking van deze basisbeginselen in concrete normen en standaards vindt op het tweede niveau in een aantal modules plaats. Deze modules vormen samen “het hart” van het Kwaliteitshandboek.
In het daarop volgende derde niveau vindt de gebruiker tenslotte ondersteunend referentiemateriaal van waaruit verder gewerkt kan worden.

Download:         

Gerelateerde artikelen:

1. Voorbeeld opzet handboek voor ICT kwaliteit deel 3
2. Voorbeeld opzet handboek voor ICT kwaliteit deel 2
3. Case Kwaliteit tastbaar en concreet maken bij een instelling voor thuiszorg

1. Toelichting op dit document
2. Inleiding: duidelijkheid als sleutelwoord
3. Duidelijke doelstellingen PPPP-IT
4. Het PPPP-IT kwaliteitssysteem
5. De systeemontwikkelingsmethode
6. Inrichting van het project
   6.1 Inrichting van het operationele niveau
   6.2 Inrichting van het voorwaardenscheppen
   6.2.1Producten en beslismomenten
   6.2.2 Product/betrokkenen matrix
7. Meer over kwaliteitsbeheer ICT
8. Nawoord

1. Toelichting op dit document

Dit document bevat het derde deel van een voorbeeld van een kwaliteitshandboek ICT, dat daadwerkelijk is geïmplementeerd in de praktijk. Het gaat in op systeemontwikkeling (waterval methode SDM-2), beheer (ITIL-based) en projectmanagement (ook mogelijk via Prince 2).
Het handboek is beschreven vanuit de behoefte van de bedrijfsprocessen en gebruikers en is bedoeld om de ICT-afdeling zo te laten werken, dat aan de gebruikers een adequate informatie voorziening wordt gegarandeerd. Er wordt dan vooral ook ingezoomd op de activiteiten, die voor de gebruikers van belang zijn, zodat ook zij begrijpen, dat hun participatie cruciaal is om dit te realiseren. Het maakt hierbij niet uit of het een interne of externe ICT-afdeling betreft. Zeker ook in het geval van outsourcing is dit bruikbaar om tot een werkzame samenwerking te komen, waarbij taken, verantwoordelijkheden en bevoegdheden zijn vastgelegd.

Om hergebruik gemakkelijk mogelijk te maken, is de bedrijfsnaam vervangen door PPPP. Via zoek en vervang kunt u hier uiteraard de naam van uw organisatie invullen.

Uiteraard kan ZBC u ondersteunen bij de aanpassing en de invoering van dit handboek en het verzorgen van workshops aan betrokkenen.

Het handboek is gezien zijn omvang opgesplitst in drie delen om problemen met downloaden te voorkomen. Dit is deel 3

In deel 1 vindt u de inleiding op het handboek, die bestaat uit de volgende hoofdstukken:

2. Inleiding: duidelijkheid als sleutelwoord

3. Duidelijke doelstellingen PPPP-IT

4. Het PPPP-IT kwaliteitssysteem

Deel 2 gaat in op:

5. De systeemontwikkelingsmethode

Deel 3

6. Inrichting van het project

In deel drie van dit handboek werken we de inrichting van het project verder uit.

Door een adequate inrichting van het project kan het opdracht- en het projectmanagement er zorg voor dragen, dat het project succesvol beëindigd wordt. Dit betekent: een effectieve beheersing waardoor het overeengekomen resultaat op tijd en binnen budget gerealiseerd kan worden.

Concreet moet het projectmanagement daartoe zorgdragen voor het normeren en bewaken van de volgende vijf beheersaspecten:

• kwaliteit;
• tijd;
• geld;
• organisatie;
• informatie.

Figuur 11 geeft de samenhang tussen deze vijf beheersaspecten weer.
Eén ding blijkt daaruit in één oogopslag: zeker ook als het om de beheersing gaat, staat het kwaliteitsaspect bij PPPP-IT centraal. Letterlijk en figuurlijk.

Figuur 11: Samenhang tussen de beheersaspecten

De beheersing van het aspect kwaliteit richt zich op het ontwikkelen en bewaken van de normen waaraan het proces en het projectresultaat moeten voldoen. Aangezien het resultaat samenvalt met het doel is de kwaliteit het centrale beheersaspect van het project.

De beheersing van het aspect tijd is gericht op de zorg om het projectresultaat op het afgesproken tijdstip gereed te hebben. Om dit mogelijk te maken moeten er afspraken worden gemaakt en bewaakt over de capaciteit en de inzetbaarheid van mensen en middelen.

De beheersing van het aspect geld betreft de zorg om het resultaat binnen het gestelde budgetten te realiseren.

De beheersing van het aspect organisatie richt zich op de interne en externe communicatie in en rondom het project. Hierbij valt te denken aan zaken als taken, verantwoordelijkheden, bevoegdheden, besluitvorming, relatiebeheer enzovoort.

De beheersing van het aspect informatie betreft de zorg voor het beheer en de distributie van de actuele informatie. Tot dit beheersaspect behoren zaken als documentatie, versiebeheer, rapportagestructuren, wijzigings- en goedkeuringsprocedures en projectadministratie.

De vijf beheersaspecten dekken de projectbeheersing op zowel operationeel als op voorwaardenscheppend niveau af.

Op operationeel niveau zijn primair tijd, geld en kwaliteit van belang en onderling uitwisselbaar. Voor de oplossing van bijvoorbeeld een tijdsprobleem kan ook gekozen worden voor het inzetten van meer capaciteit (geld) of voor het naar beneden bijstellen van de eisen aan de functionaliteit (kwaliteit).

Op voorwaardenscheppend niveau zijn primair kwaliteit, informatie en organisatie van belang en met elkaar samenhangend.

De inrichting en het functioneren van het kwaliteitssysteem worden in de paragrafen 3.1 (operationeel niveau) en 3.2 (voorwaardenscheppend niveau) nader uiteengezet.

6.1 Inrichting van het operationele niveau

De primaire verantwoordelijkheid van het opdracht- en projectmanagement is het bereiken van het overeengekomen resultaat binnen de gestelde randvoorwaarden, meestal tijd en geld. Dit impliceert dat de opdracht- of projectleider van te voren moet onderzoeken of het inderdaad mogelijk is om het gevraagde resultaat binnen de randvoorwaarden te realiseren.
In de eerste plaats zullen dan de voorwaarden vooraf getoetst moeten worden. Daarnaast zal de opdracht- of projectleider bij projecten van het opdrachttype 2 een drietal onderzoeken (laten) doen naar de kwaliteit van de uitgangssituatie, te weten:

• een kwaliteitsaudit op het voorliggende product,
  dit om er zeker van te zijn dat het voorgaande product als basis kan dienen voor de verdere ontwikkeling;
• een risicoanalyse,
  dit om zicht te krijgen op eventuele verstoringen tijdens het project;
• een begrotingstechniek,
  om te bepalen of het resultaat inderdaad binnen de randvoorwaarden gerealiseerd kan worden (in termen van Prince 2 de businesscase).

Levert één van deze onderzoeken een onbevredigend resultaat op, dan zal met de klant overlegd worden op welke wijze het gesignaleerde probleem opgelost dient te worden. Daarna kan worden overgegaan tot het afgeven van een realistische offerte, waarin ook alle op te leveren producten worden genoemd. In het Kwaliteitshandboek is een nadere omschrijving van deze producten opgenomen, zodat de klant ook nauwkeurig de tegenprestatie van PPPP-IT kent.
Nadat overeenstemming is bereikt over de opdracht, werkt de projectleider die opdracht uit in een plan waarin de norm wordt gesteld voor de verschillende beheersaspecten.
Na goedkeuring van dit plan door de opdrachtgever wordt de opdracht conform het plan uitgevoerd.
De projectleider bewaakt de beheersaspecten door ze te meten en te vergelijken met de norm. Eventuele afwijkingen worden geanalyseerd en bijgestuurd.
Dit proces is in figuur 12 schematisch weergegeven.

Figuur 12: Beheerscyclus

Het beslissen kan drie mogelijke uitkomsten hebben, te weten:

bijstelling van de norm voor één van de vijf beheersaspecten, vanzelfsprekend binnen de gestelde opdracht en randvoorwaarden;
directe actie op de uitvoering, bijvoorbeeld door het motiveren of begeleiden van medewerkers;
het geaccepteerd krijgen van een wijziging in de opdracht of de randvoorwaarden of bijsturing op de afgesproken inzet van de gebruikersorganisatie.
Daarnaast kan worden volstaan met niets doen, mits de afwijking maar binnen de grenzen blijft.

6.2 Inrichting van het voorwaardenscheppende niveau

Het doel van een project is het opleveren van een product dat aan de kwaliteitsnormen voldoet. Deze kwaliteitsnormen omvatten alle vastgelegde en vanzelfsprekende behoeften.

Om het mogelijk te maken dat hieraan wordt voldaan, zullen de volgende zaken geregeld moeten worden:

• Door zorgvuldige specificaties en richtlijnen worden voorzover mogelijk ook de vanzelfsprekende behoeften vastgelegd. De specificaties zijn veelal afkomstig van operationele medewerkers, terwijl de richtlijnen doorgaans afkomstig zijn van het management of zijn staf.
• Door verificatie wordt geconstateerd of de producten op zich correct en onderling consistent zijn en of ze voldoen aan alle technische criteria en standaards. Deze validatie wordt op productniveau uitgevoerd door projectmedewerkers en op faseniveau door PPPP-IT onder verantwoordelijkheid van de ‘manager kwaliteitsborging’.
• Door validatie wordt gecheckt of de vastgelegde specificaties inderdaad de behoeften afdekken en of de specificaties compleet zijn. De verificatie wordt uitgevoerd door materiedeskundigen uit de organisatie van de klant.
• Door formele goedkeuring wordt duidelijkheid verschaft over de status (bevriezing) van de producten en de verantwoordelijkheid over de besluitvorming met betrekking tot wijzigingsvoorstellen. Door de formele goedkeuring van producten waarin functionele specificaties zijn vastgelegd, wordt bovendien de verantwoordelijkheid voor de acceptatie van het product overgedragen aan de fiatteur. Dit behoort dus de manager of staffunctionaris te zijn, die ook binnen de lijnorganisatie verantwoordelijk is/wordt voor deze zaak. Acceptatie vindt doorgaans alleen plaats bij mijlpaalproducten.

Deze activiteiten en hun samenhang zijn weergegeven in figuur 13.

Figuur 13: Het maken van productkwaliteit

Voorts worden er in de projectopdracht een aantal randvoorwaarden genoemd waarbinnen de gewenste kwaliteit gerealiseerd moet worden. Deze randvoorwaarden betreffen meestal de aspecten tijd en geld. In de randvoorwaarden zit echter meestal een marge die de opdrachtgever in geval van problemen de mogelijkheid geeft om prioriteiten te stellen in de driehoek tijd, geld en kwaliteit.

6.2.1 Producten en beslismomenten

Om de voortgang van het gehele proces te kunnen meten, worden er in de loop van het proces meetpunten ingebouwd, waarop beslissingen genomen kunnen worden ten aanzien van een eventuele bijsturing. Deze meetpunten liggen op drie niveaus:

• Productniveau.
  Producten zijn vooral bedoeld om te valideren en te verifiëren. Deze producten hebben primair een functie op project/werkgroep- niveau, mits de gebruikers hierin zitting hebben. Ze geven de projectleider de mogelijkheid om bij te sturen binnen de opdracht en randvoorwaarden.
• Mijlpaalproductniveau.
  Mijlpaalproducten zijn enerzijds een ‘gewoon’ product en worden als zodanig behandeld, maar zijn anderzijds bedoeld als verantwoording naar de stuurgroep. De stuurgroep heeft de bevoegdheid om zowel op de inhoud als op de randvoorwaarden bij te sturen binnen haar mandaat. Acceptatie van een mijlpaalproduct betekent dat de in het product beschreven situatie bevroren wordt en slechts via de formele wijzigingsprocedure geamendeerd kan worden.
• Faserapportniveau
  Faserapporten zijn enerzijds ‘normale’ mijlpaalproducten, maar zijn anderzijds bedoeld als verantwoording aan de organisatie. De organisatie moet hierop een “go/no go” beslissing nemen en heeft het recht om te amenderen.

Uit al het bovenstaande blijkt dat een zorgvuldige toewijzing van taken, verantwoordelijkheden en bevoegdheden van het grootste belang is om te waarborgen dat het resultaat conform de verwachting van de gebruikersorganisatie is.

Allereerst betreft dit taken op uitvoerend niveau:

• specificeren,
• vastleggen van specificaties in producten,
• valideren en
• verifiëren.

Deze taken zijn onderdeel van het project. De uitvoerders van deze taken vallen dus (in de projectgroep of de werkgroep) onder de projectleider.

Daarnaast zijn er een tweetal verantwoordelijkheden op besluitvormend niveau:

• De bewaking van de opdracht door de opdrachtgever binnen de randvoorwaarden. De projectleider legt hierover verantwoording af aan die opdrachtgever.
• De formele acceptatie van de producten door de functionaris die na het project aangesproken kan worden op de inhoud ervan; de afdelingsmanager bijvoorbeeld op de functionaliteit van het systeem of de gegevensbeheerder op de integriteit van het datamodel. Om de acceptatiegraad te verhogen, verdient het aanbeveling om de producten niet alleen inhoudelijk maar ook qua opzet en vorm herkenbaar te maken voor de gebruikersorganisatie. Daarom behoort het geven van richtlijnen eveneens tot de taak van deze functionarissen. In sommige organisaties is het verstrekken en bewaken van richtlijnen uitbesteed aan stafafdelingen zoals een afdeling Kwaliteit of Personeelszaken.

Gezien hun verantwoordelijkheid dienen de functionarissen met de inhoudelijke verantwoordelijkheid bòven de projectleider gepositioneerd te worden in bijvoorbeeld een stuurgroep, maar ònder de coördinerende functie van de opdrachtgever. Die laatste is immers over alle betrokkenen heen verantwoordelijk voor de prioriteitsstelling.
In geval van onenigheid tussen stuurgroepleden zorgt de opdrachtgever voor een eenduidig standpunt van de stuurgroep.
Het spreekt vanzelf dat het niet nodig is voor de formele goedkeuring van elk product de voltallige stuurgroep bijeen te roepen.

6.2.2 Product/betrokkenen matrix

Om de taken en verantwoordelijkheden eenduidig toe te wijzen, wordt gebruik gemaakt van een product/betrokkenen-matrix, waarvan een voorbeeld op de volgende pagina is afgebeeld. Voor PPPP zal deze nog verder uitgewerkt worden. In deze matrix staat per op te leveren product beschreven wie welke taak en/of verantwoordelijkheid heeft.
In de product/betrokkenen matrices uit het Kwaliteitshandboek staat bij de betrokkene meestal aangegeven welke expertise vereist is. In het Plan van Aanpak moet dan worden vastgelegd of de expertise wordt geleverd door de klant of door het PPPP-IT en wie de betreffende ‘expert’ is.

Voor de uitvoerende taken is het van belang te zoeken naar de grootste materiedeskundigen of specialisten binnen de organisatie, mensen die als belangrijke eigenschap het vermogen moeten hebben in teamverband te kunnen functioneren.
Voor de beslissers zijn de desbetreffende verantwoordelijken uit de gebruikersorganisatie de meest aangewezenen.
Voor elk specifiek project, zullen met name de betrokkenen nauwkeurig gespecificeerd moeten worden. Voorbeeld product / betrokkenenschema mijlpaalproducten

Legenda

7. Meer over kwaliteitsbeheer ICT

In het document ‘Checklist SDM-activiteiten’ vindt u een checklist om producten te beoordelen.
Als u kiest voor iteratief ontwikkelen verwijzen we u naar het document ‘Rapid Application Development’ (IAD of RAD).
Meer over projectbeheersing vindt u in de rubriek ‘Aanpak projecten ICT- ontwikkeling‘ in de kennisbank.
Meer over de inrichting van beheer conform ITIL vindt u in de rubriek ‘Checklists review ITIL-processen‘.
Meer over outsourcing vindt u in de rubriek ‘Management ICT-outsourcing‘.
Als informatiebeveiliging en business continuity ook tot het kwaliteitshandboek gerekend worden, verwijzen we graag naar de rubrieken ‘ISO 27002: Code voor informatiebeveiliging‘ (de opvolger van ISO 17799), ‘NEN 7512- informatiebeveiliging in de zorg‘ en ‘Calamiteitenplan- BCP‘.
Als verder ERP select: een issue is, verwijzen we graag naar de rubrieken ‘Selectie en implementatie ERP-software‘ om u te behoeden voor de valkuilen van de dure marktleiders met hoge implementatiekosten.

8. Nawoord

Tot zover de Basismodule van het PPPP-IT Kwaliteitshandboek, waarin de algemene uitgangspunten en de essentie van PPPP-IT’s kwaliteitsstreven zijn uiteengezet.

De uitwerking van deze basisbeginselen in concrete normen en standaards vindt op het tweede niveau in een aantal modules plaats. Deze modules vormen samen ‘het hart’ van het Kwaliteitshandboek.
In het daarop volgende derde niveau vindt de gebruiker tenslotte ondersteunend referentiemateriaal van waaruit verder gewerkt kan worden.

Download:         

Gerelateerde artikelen:

1. Voorbeeld opzet handboek voor ICT kwaliteit deel 1
2. Voorbeeld opzet handboek voor ICT kwaliteit deel 2
3. Case Kwaliteit tastbaar en concreet maken bij een instelling voor thuiszorg

1. Inleiding
2. Inrichting beheer informatievoorziening

1. Inleiding

ITIL is in Nederland de meest toegepaste beheersmethodiek.
Het beoogt een kwaliteitssysteem te zijn voor het beheren van de IT-infrastructuur. ITIL beschrijft processen, die bij een adequate implementatie de kwaliteit van de dienstverlening voor de afnemers zeker stelt.
Er moet daarbij echter wel aan de nodige randvoorwaarden worden voldaan:

1. Omdat ITIL uitsluitend logische procesbeschrijvingen geeft, maar niet ingaat op aspecten als het beleggen van verantwoordelijkheden en criteria voor de inrichting, stelt dit hoge eisen aan de inrichting van de organisatie en de sizing van ITIL, om het tot een werkend en vooral werkbare systematiek te vormen. (Zie ook ‘Blauwdruk processen IT-organisatie’.)
2. ITIL beperkt zich uitsluitend tot een beschrijving van de beheerprocessen. Uitvoerende IT-taken (ontwikkeling, onderhoud etc.) worden niet beschreven en ook de beheerprocessen aan de gebruikerskant (functioneel beheer) komen niet aan de orde. Bij de implementatie van ITIL dient dit echter wel meegenomen te worden om suboptimalisatie te voorkomen.
3. De meest gebruikte procesbeschrijvingen van ITIL (de Service Support set en de Service Delivery set stammen nog uit een periode, dat het IT-beheer nog te kampen had met vele kinderziekten en nog weinig last had van problematiek, die voortvloeit uit een moderne bedrijfsvoering. Het is de kwaliteit van ITIL, dat de processen ook nu nog zeer bruikbaar zijn, maar de accenten, die binnen de procesbeschrijvingen gezet zijn, verdienen tegenwoordig een aangepaste invulling. (Zie ook ‘Begrafenis ITIL is begin van herstel ICT-imago’.)

Dit artikel tracht een aantal implementatie aspecten van ITIL te belichten opdat invoering van ITIL voor bedrijven optimaal bijdraagt aan effectief en efficiënt beheer van de informatievoorziening gebaseerd op ITIL. In dit artikel gaan wij ervan uit, dat de lezer op de hoogte is van de procesdefinities van de bekendste ITIL-processen.

2. Inrichting beheer informatievoorziening

Aan de hand van een stap voor stap opgebouwd implementatiemodel wordt getracht een aantal issues, die voor een moderne bedrijfsvoering van belang zijn, op een samenhangende wijze in te bouwen in een algemeen implementatiemodel.

Figuur 1: Implementatiemodel IT-beheer

 Het basisprincipe van ITIL is, dat de IT-organisatie diensten verleent aan de afnemer tegen gerechtvaardigde kosten.
Dat ITIL geen harde koppeling legt tussen de te verlenen diensten en de vergoeding, die hiervoor gegeven wordt, is in deze tijd naïef en gevaarlijk. Enerzijds kan het ertoe leiden, dat de IT-organisatie zich bijzonder defensief en star gaat gedragen omdat zij weet, dat het honoreren van additionele wensen van de gebruikersorganisatie tot budgetoverschrijding gaat leiden of tot een niet hanteerbare workload voor de medewerkers. Anderzijds wordt de gebruikersorganisatie op geen enkele manier gemotiveerd om de doelmatigheid van haar verzoeken nadrukkelijk te bekijken. Kortom elk mechanisme om tot een spel van vraag en aanbod te komen en om (weliswaar ten koste van extra middelen) additionele wensen te realiseren ontbreekt. Daarom is het voor beide partijen van wezenlijk belang, dat tegenover het niveau en de omvang van de dienstverlening betalingen (reëel of administratief met kostenplaatsen) bestaan. Hierbij wordt budget rechtstreeks beschikbaar gesteld aan de IT-organisatie voor de uitvoering van de standaardtaken. De budgetten om projecten uit te voeren en wijzigingen door te voeren worden echter aan de afnemers toegekend. (Zie ook ‘Besparingen door gebruik van professionele Service Level Agreements – SLA’ s’.)

Figuur 2: Front office proces Service Level Management

De vastlegging van dit standaardpakket en het daarmee gemoeide budget wordt vastgelegd in de overeenkomst (Service Level Agreement), die wordt gesloten tussen budgethouders in de gebruikersorganisatie en Service Level Management binnen de IT-organisatie.
Als dit geregeld is kunnen er twee soorten verstoringen van deze stabiele situatie ontstaan.
Op zeker moment kan geconstateerd worden, dat de IT-organisatie niet voldoet aan het afgesproken service level. Dit noemen we een incident en dit kan door de gebruikersorganisatie gemeld worden aan de helpdesk. Vervolgens dient de helpdesk zo snel mogelijk een ‘fix’ te realiseren, zodat het afgesproken service level weer gehaald wordt en de gebruiker zijn werkzaamheden kan voortzetten. Dit impliceert nadrukkelijk, dat de oorzaak van het probleem nog niet weggenomen hoeft te zijn, maar dat is niet de zorg van de helpdesk. Zij dient afgerekend te worden op het aantal calls, dat ze per uur kan verwerken gecombineerd met het aantal incidenten, dat ze zelfstandig kan afhandelen. Over helpdesks, die uitsluitend een postbus zijn voor tweedelijns support, bestaat in het algemeen weinig waardering.
Het sterke accent, dat ITIL legt op de promotiefunctie van de helpdesk, is tegenwoordig vervangen door het effectief en efficiënt afhandelen van incidenten. (Zie ook ‘AO van Incidentbeheer’.)
De kosten van dit incidentbeheer (incl. correctief onderhoud) komen ten laste van het IT-budget.

Figuur 3: Front office proces Helpdesk

De tweede soort verstoring van de stabiele situatie kan voorkomen, als de gebruikersorganisatie behoefte heeft aan nieuwe of gewijzigde IT-services. Dit heet een wijzigingsvoorstel en kan worden ingediend bij wijzigingsbeheer. (Zie ook ‘Checklist ITIL Change Management of Wijzigingsbeheer’.) Het is van cruciaal belang, dat wijzigingsbeheer wordt gescheiden van incidentbeheer omdat:

• de realisatie van wijzigingsvoorstellen ten laste komt van de gebruikersorganisatie;
• er geen min of meer sequentiële afwikkeling plaatsvindt, zoals bij de helpdesk, maar een afwikkeling op basis van een prioritering van de gebruikersorganisatie. De IT-organisatie is slechts adviseur;
• de realisatie van wijzigingsvoorstellen impact kan hebben op het service level (bijv. de wens m.b.t. de beschikbaarheid van internet op de werkplek via het bedrijfsnetwerk impliceert de aanschaf en het beheer van een firewall o.i.d.).

Figuur 4: Front office proces Wijzigingsbeheer

In de praktijk blijkt m.n. dat een slecht ingericht wijzigingsbeheer leidt tot vergaande frustraties bij zowel de gebruikersorganisatie als bij de IT-organisatie. Alleen bij het juist beleggen van budgetten, kan de gebruikersorganisatie ervoor kiezen de IT-organisatie de middelen te verstrekken om evt. via externe inhuur de gevraagde services te leveren.

Tenslotte is er nog één proces, dat in hoge mate bij kan dragen aan de effectieve en soepele samenwerking tussen de gebruikersorganisatie en de IT-organisatie. ITIL noemt dit proces relatiebeheer, maar in de huidige tijd ziet men als belangrijkste taak van relatiebeheer, de advisering van de gebruikersorganisatie .
Voorbeelden, waarover relatiebeheer adviseert zijn o.a.:

• toepassing van IT ter verbetering van bedrijfsprocessen;
• mogelijkheden en gebruik van nieuwe technologieën ;
• opzetten en inrichten van projecten;
• toepassing van normen en standaards;
• opzet en inrichting functioneel beheer;
• advisering m.b.t. informatiebeveiliging;
• acceptatie en invoering van applicaties;
• perfectief onderhoud;
• gebruikers participatie;
• audits en systeemevaluaties;
• ideegeneratie voor het oplossen van knelpunten in het bedrijfsproces.

Indien deze diensten worden uitgevoerd op verzoek van de gebruikers organisatie, komen deze kosten ook voor rekening van de gebruikers organisatie. Als dit op eigen initiatief plaatsvindt, komt dit voor rekening van de IT-organisatie.
Met deze vier processen zijn de front office processen van de IT-organisatie naar de gebruikersorganisatie genoemd, die als primair aanspreekpunt gelden voor de gebruikers organisatie

Figuur 5: Front office proces Relatiebeheer

Naast deze voor de gebruikers organisatie zichtbare processen, bevinden zich in de front office ook nog een aantal ondersteunende processen.

Figuur 6: Backoffice processen

Voor Service level management zijn dit processen als kostenbeheer, capaciteitsbeheer, beschikbaarheidsbeheer en calamiteitenplanning. (Zie ook ‘Plan van aanpak: Business Continuity Plan – een voorbeeld van een BCP’.) Voor wijzigingsbeheer en de helpdesk zijn dit probleembeheer, configuratiebeheer (zie ook ‘Checklist ITIL Configuration Management of Checklist ITIL Configuration Management’) en programmatuurbeheer.

2.1 Functioneel beheer

Voor een goede samenwerking is er echter meer nodig. Aan de gebruikerskant dient nog het functioneel beheer ingeregeld te worden om zeker te stellen, dat ook van de gebruikerskant aan de voorwaarden uit de overeenkomst wordt voldaan en er een adequate behoeftestelling komt naar de IT-organisatie (geen zaken op het bord van de IT-organisatie leggen, die niet afgesproken zijn of geregeld worden via procedures). (Zie ook ‘Organisatie en inrichting functioneel applicatiebeheer.’)

Figuur 7: Functioneel beheer

 Voorbeelden van zaken, die binnen het functioneel beheer belegd worden, zijn:

• Gebruikersondersteuning,
• Begeleiden gebruik,
• Opleiding gebruikers,
• Functioneel systeembeheer:
  • Bewaken van het gebruik,
  • Beheren applicatie-parameters,
  • Beheren applicatiegegevens,
  • Het verzamelen en inventariseren van wijzigingen en problemen en het formuleren van voorstellen en opdrachten.
• Inhoudelijk beheer bedrijfsgegevens,
• Uitgifte autorisaties voor gebruik van bedrijfsgegevens door applicaties,
• Beheren bedrijfsgegevens- verzamelingen,
• Verstrekken van kopieën, selecties of ad hoc-rapportages vanuit de bedrijfsgegevens,
• Onderhoud handmatige procedures:
  • Onderhouden van (adm.) procedures,
  • Onderhouden opleidingsmateriaal en handleidingen.
• Functioneel onderhoud informatie systeem:
  • Onderhouden functionele specificaties,
  • Valideren functionele specificaties,
  • Onderhouden en uitvoeren acceptatietest,
  • Beoordelen acceptatietest.
• Gegevensdefinitie beheer:
  • Vaststellen gegevensdefinities,
  • Onderhouden en beschikbaar stellen van gegevensdefinities,
  • Bewaken consistent gebruik bedrijfsgegevens definities door de informatie systemen.
• Beveiligingsbeheer:
  • Accountbeheer,
  • Werkplekbeveiliging,
  • Instellingen beveiligingsmiddelen.

In de praktijk zien we, dat de gebruikersorganisatie een aantal van deze beheertaken uitbesteed aan de IT-organisatie. (Zie ook ‘Samenwerking tussen gebruikers en de ICT-afdeling door functioneel beheer’.) Dit is op zich niet bezwaarlijk, mits voldaan wordt aan een aantal criteria:

Niet uit te besteden zijn:

• Beleidsvoorbereiding
• Beslissen
• Controletaken
• Accountability

Duidelijk afspraken hierover worden gemaakt in het Service Level Agreement

Als ook (een aantal van) deze taken belegd zijn bij de IT-organisatie of niet worden uitgevoerd, zal de gebruikersorganisatie haar grip op haar informatievoorziening verliezen en zich doorgaans gaan afzetten tegen de IT-organisatie. (Zie ook ‘Operationele processen functioneel applicatiebeheer’.) Dit leidt er vaak toe, dat beide partijen zich in de loopgraven terugtrekken.

Helaas vallen deze functionele beheerprocessen buiten de afbakening van ITIL, zodat ze vaak vergeten worden bij ITIL implementaties.

2.2 Uitvoering

Daarnaast vervult de IT-organisatie in de back office nog een aantal uitvoerende taken zoals het operationeel beheer van de hardware en de netwerken, systeemontwikkeling en onderhoud en de verwerking.

Figuur 8: Uitvoerende taken back office

Deze processen kunnen ook gemakkelijk geheel of gedeeltelijk uitbesteed worden. (Zie ook ‘Outsourcing van werkplekbeheer is meer dan kostenbesparing alleen’.) Onafhankelijk of er sprake is van uitvoering in eigen beheer of uitbesteding, de front office blijft naar de gebruikersorganisatie verantwoordelijk voor de uitvoering van de werkzaamheden.
De werkzaamheden van de back office kunnen altijd als een project gedefinieerd worden, waarvoor projectopdrachten afgesloten kunnen worden. Gezien de omvang van veel van deze opdrachten, kiest men er vaak voor om een verzameling opdrachten onder te brengen in één project.

Deze opzet heeft een aantal belangrijke voordelen:

• De leverbetrouwbaarheid van de IT-organisatie wordt vergroot.
• Er sluipen minder adhoc werkzaamheden binnen bij de back office
• De back office hoeft niet groter te zijn dan nodig is vanuit de behoefte van de gebruikers organisatie.
• Er wordt voorkomen, dat een aantal specialisten een groot deel van hun tijd besteden aan het oplossen van problemen, die door niemand worden ervaren.
• Indien de behoefte van de gebruikersorganisatie de vaste formatie van de IT-organisatie overschrijdt, kan via extra inhuur of uitbesteding hier flexibel op ingespeeld worden.

De uitvoering wordt vaak door de front office aangestuurd door service managers of project managers.

Download:         

Gerelateerde artikelen:

1. Blauwdruk processen IT-organisatie
2. ITIL: professionalisering of indekken
3. Samenwerking tussen gebruikers en de ICT-afdeling door functioneel beheer