III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management...

34
Pagina {154} III. Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk wordt dit domein al snel gezien als DE IT-afdeling en krijgt daarbij ook vele namen. Helaas ontkomt dit boek er ook niet aan om vele van deze namen te gebruiken voor de IT ondersteuning. Namen als de productie omgeving, operationeel beheer, technisch beheer en de ICT lijn organisatie wijzen vaak allemaal naar dezelfde club mensen, namelijk degene die de alledaagse werkzaamheden uitvoeren zodat iedereen kan werken op zijn/haar computer. Sommige gebruikers zien de personen die de telefoon opnemen bij de helpdesk ook als de verpersoonlijking van het hele beleid. Dit terwijl de persoon vaak niet meer doet of kan doen dan de verstoring goed beschrijven en doorvragen naar de juiste bron van de fout. Uiteraard is dit afhankelijk van de organisatie omdat er in de kleinere organisaties enkele all-round IT-ers werken die ook daadwerkelijk langskomen om de fout persoonlijk te herstellen. Hierbij is het ook vaak een moeizame woordkeuze in het kader van de juiste omschrijving van datgene wat bedoeld is. Enerzijds is dit omdat het aantal Engelse woorden enorm is binnen dit vakgebied, dat ook nog vaak niet te vertalen valt in fatsoenlijk Nederlands, anderzijds omdat iedereen wel iets anders verstaat onder de meer generieke termen. Binnen dit boek wordt bijvoorbeeld de term “omgeving” gebruikt. In het woordenboek wordt deze term als volgt verklaart: zn v omgeving (-en mv) [ɔmˈxevɪŋ] 1 gebied in de buurt In de wijde omgeving was geen huis te zien. 2 groep mensen met wie je omgaat je naaste omgeving

Transcript of III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management...

Page 1: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {154}

III. Service Portfolio Management

Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel

Operations genoemd. In de praktijk wordt dit domein al snel gezien als DE IT-afdeling en krijgt

daarbij ook vele namen. Helaas ontkomt dit boek er ook niet aan om vele van deze namen te

gebruiken voor de IT ondersteuning. Namen als de productie omgeving, operationeel beheer,

technisch beheer en de ICT lijn organisatie wijzen vaak allemaal naar dezelfde club mensen,

namelijk degene die de alledaagse werkzaamheden uitvoeren zodat iedereen kan werken op

zijn/haar computer. Sommige gebruikers zien de personen die de telefoon opnemen bij de

helpdesk ook als de verpersoonlijking van het hele beleid. Dit terwijl de persoon vaak niet meer

doet of kan doen dan de verstoring goed beschrijven en doorvragen naar de juiste bron van de

fout. Uiteraard is dit afhankelijk van de organisatie omdat er in de kleinere organisaties enkele

all-round IT-ers werken die ook daadwerkelijk langskomen om de fout persoonlijk te

herstellen.

Hierbij is het ook vaak een moeizame woordkeuze in het kader van de juiste omschrijving van

datgene wat bedoeld is. Enerzijds is dit omdat het aantal Engelse woorden enorm is binnen dit

vakgebied, dat ook nog vaak niet te vertalen valt in fatsoenlijk Nederlands, anderzijds omdat

iedereen wel iets anders verstaat onder de meer generieke termen. Binnen dit boek wordt

bijvoorbeeld de term “omgeving” gebruikt. In het woordenboek wordt deze term als volgt

verklaart:

zn v omgeving (-en mv) [ɔmˈxevɪŋ] 1 gebied in de buurt In de wijde omgeving was geen huis te zien. 2 groep mensen met wie je omgaat je naaste omgeving

Page 2: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {155}

Pas de Thesaurus geeft enige houvast voor hoe omgeving hier gebruikt wordt, namelijk “vorm”

en “omtrek”. Dit betekent dat de gebruikte woorden rekbaar zijn. Voor het verdere gebruik zijn

in dit boek de woorden omgeving, gebied en domein uitwisselbaar. In het vervolg wordt ook

gesproken in het operationele gebied van een service. Hieronder kan zowel een service als een

asset of een applicatie worden verstaan. Het is nadrukkelijk niet de bedoeling om

gedetailleerder een service te gaan bespreken, daar zijn andere boeken voor. Het feit dat aan

een service een technische infrastructuur, een database en bijvoorbeeld een interface nodig is,

is niet relevant voor de CPM methode. Dit is natuurlijk wel interessant voor de ICT

beheerafdeling.

In dit hoofdstuk zal eerst een beschrijving worden gegeven van de verschillende methodes die

gangbaar zijn binnen het operationele domein. Deze worden, zoals ook in de eerdere

hoofdstukken, in zijn geheel kort beschreven om een beeld te krijgen wat deze behelzen. Aan het

einde van deze uitwerking wordt nog specifiek de overgang van Project Portfolio Management

en Service Portfolio Management besproken in het kader van de gebruikte methodes. Dit om

extra aandacht te vragen aan het feit dat in de praktijk het hier een duidelijk ander metier

betreft, met haar eigen werkwijze. Het specifieke uitwerken van deze methodes wordt

vervolgens gedaan bij de onderliggende processen van het Service Portfolio Management zelf.

Het beheer domein is verantwoordelijk voor het gehele productionele gebied van het ICT

omgeving. Dit betekent dat de primaire taak van de resources op het productionele gebied het

operationeel houden van de productieomgeving conform de Service Level Agreements zoals

deze contractueel zijn vast gelegd. Dit betreft het bewaken en, indien noodzakelijk, het

herstellen van de huidige set van services, assets en applicaties. Kort gezegd is dit alles wat nu

productioneel draait ter ondersteuning van alle eindgebruikers.

Binnen het operationele domein zijn enkele afdelingen actief die ook hun vertegenwoordiging

hebben binnen de projecten die daarvoor spelen. Zij zijn ook betrokken bij die projecten als

leverancier van resources en zij zijn nu ook acceptanten van de op te leveren producten van het

project. Het heeft hiervoor ook aparte acceptatiecriteria, waar een project rekening mee moet

houden voor deze goedkeuring. Afhankelijk van de grootte en inrichting van een organisatie zijn

deze afdelingen in mindere of meerdere mate vertegenwoordigd.

1. Afdeling technisch beheer. Dit is de ICT afdeling die de lijn vertegenwoordigt en primair

bezig is om de dagelijkse taken uit te voeren die nodig zijn om de organisatie optimaal te

ondersteunen. Een aparte afdeling hier te benoemen kan een applicatie beheer afdeling

zijn. Deze is gericht op specifieke applicaties, maar ook met hetzelfde doel: draaiend

houden van deze applicatie.

2. Afdeling functioneel beheer. Dit is de afdeling, vaak ingedeeld aan de kant van de

gebruikersorganisatie, die de applicaties functioneel ondersteunt. Deze groep mensen is

specifiek ter ondersteuning van de gebruikers en is vaak ook de buffer tussen gebruikers

en ICT. Hierbij is een splitsing te maken tussen kantoorautomatisering (standaard

programma’s als MS Word en Excel) en specifieke pakket ondersteuning (bijvoorbeeld

SAP of PeopleSoft).

3. Gebruikersorganisatie. Dit zijn de eindgebruikers en degene die gebruik maken van de

diverse applicaties in dagelijks gebruik. Vaak zijn binnen de diverse afdelingen

Page 3: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {156}

vertegenwoordigers aangesteld om de communicatie richting functioneel beheer en

technisch beheer te kanaliseren.

Zie hiervoor ook in hoofdstuk 1, paragraaf Fout! Verwijzingsbron niet gevonden., de opsomming

van de wijze van communicatie van gebruikers naar de ICT afdeling op bladzijde Fout!

Bladwijzer niet gedefinieerd.. Besef hierbij dat voor een gebruiker vaak een ander proces

wordt gevolgd wanneer de persoon niet kan inloggen (melding bij de helpdeks) dan wanneer de

persoon binnen een applicatie een verstoring heeft op de werkwijze (melding via Functioneel

Beheer).

Het Service Portfolio Management wordt in het kader van het Corporate Portfolio Management

verdeeld in twee onderdelen. Hierbij wordt dezelfde onderverdeling gemaakt als bij het

Strategische en het Tactische Portfolio, namelijk een scheiding tussen alle processen die nodig

zijn voor het uitvoeren van het domein en de processen die specifiek gericht zijn op de

processen rondom het portfolio management binnen dat domein. Het Service Portfolio

Management domein wordt gedomineerd door enkele zeer bekende en goed uitgewerkte

methodes (ITIL, CoBIT, etc.). Echter is het portfolio proces als onderdeel van deze

beheermethodes of relatief onbekend of niet aansluitend op de voorgaande portfolio’s en

bijbehorende methodes. Voor het Service Portfolio Management ziet de tweedeling er als volgt

uit:

1. Alle processen behorende bij het bewaken en beheren van de huidige services, assets

en applicaties, de IT Service Management of Operationeel Beheer. Voor het vaststellen

en uitvoeren van het Service Portfolio Management zijn deze processen niet primair van

belang. Pas wanneer uit deze processen wijzigingen voortkomen of project afhankelijke

zaken worden opgepakt, starten de processen vanuit SPM. Onafhankelijk van welke

methode wordt gekozen, behoort bij de IT Service Management of Operationeel Beheer

o.a.:

a. Helpdesk of eerstelijns verstoring. Dit is het aannemen van alle meldingen of

verstoringen vanuit de gebruikersorganisatie. Dit kan of direct afgehandeld

worden of doorgezet worden naar de tweedelijn (intern of extern).

b. Gebruikersondersteuning. Dit is een breed taken pakket, waarbij de nadruk ligt

op de processen zoals Functioneel Beheer deze uitvoert.

c. Service monitoring. Het real time monitoren van de services om pro-actief

verstoringen te voorkomen. Het liefst gebeurt dit vanuit het perspectief van de

gebruiker. Vaak wordt dit uitgevoerd vanuit de verschillende assets die ICT

beheert.

d. 2e lijns en 3e lijns verstoringen oplossen (tevens voor Functioneel Beheer en

Applicatie Beheer).

e. Operationeel beheer als backups maken, batches draaien en alle taken t.b.v. het

dagelijks assisteren van applicaties.

Page 4: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {157}

2. De processen benodigd voor het handhaven van een Service Portfolio, binnen het

Portfolio Management samengevat door de term Service Portfolio Management.

Hieronder vallen:

a. Opname van services in het portfolio.

b. Het opstellen van een Release Kalender.

c. Het maken van Portfolio beslissingen.

d. Het bijwerken en rapporteren van de status van het Service Portfolio.

Deze twee onderdelen zijn met elkaar verbonden volgens onderstaand schema (Figuur 1 De

processen behorend bij het Service Portfolio Management). Het operationeel beheer dat

weergegeven is, betreft niet slechts de ICT afdeling, maar ook Functioneel Beheer dat in de

meeste organisaties aan de kant van de gebruikersorganisatie wordt gepositioneerd. Ongeacht

welk organisatieonderdeel of welke functies binnen een bedrijf aangewezen worden om de

bedrijfsvoering te vertegenwoordigen: bedoeld wordt dat vanuit deze groep of eenheid

wijzigingen op de bestaande onderhouden services worden ingediend.

Figuur 1 De processen behorend bij het Service Portfolio Management

De vier hoofdprocessen van het Service Portfolio Management worden later in dit hoofdstuk

verder uitgewerkt. De getoonde interactie is het verwerken van wijzigingen die vanuit het

operationele beheer worden ingediend. Deze wijzigingen worden, zoals ook eerder vermeld,

gebundeld gezien als een project binnen de CPM methode. Deze bundeling zal uiteindelijk

worden gerepresenteerd door de Release Kalender die als output gedefinieerd is binnen het

Service Portfolio Management domein. Deze is als input genomen in het derde CPM proces, het

uitwerken naar programma’s en projecten.

Het operationele beheer wordt gedomineerd door raamwerken die de afgelopen jaren zodanig

populair werden, dat deze standaard binnen elk bedrijf gehanteerd worden. Sommige

raamwerken zijn zeer uitvoerig, waarbij in de praktijk bij de wat kleinere organisaties enkele

processen of functies zijn komen te vervallen. Deze raamwerken beschrijven de best practices

Page 5: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {158}

van de verschillende processen die nodig zijn voor het operationele domein. Voor het

beschrijven van de CPM methode worden de methodes van ITIL, ASL en BiSL als uitgangspunt

genomen.

Figuur 2 ITIL, ASL en BiSL methodes gepositioneerd

De drie methodes zijn met elkaar verweven, waarbij de communicatie tussen (eind)gebruikers

en ICT wordt gekanaliseerd. Deze driedeling is weergegeven in bovenstaande figuur (Figuur 2

ITIL, ASL en BiSL methodes gepositioneerd) en staat tussen de gebruikersorganisatie en de ICT-

serviceorganisatie (BiSL) of zijn de gebruikelijke gang van zaken voor de ICT beheer afdeling

(ITIL en ASL). Deze acteren in de bovenstaande figuur als vraag en aanbod.

Het drieluik dekt de drie vormen van beheer van informatiesystemen (looijen 1997) af,

namelijk:

Technisch beheer (ITIL)

Applicatie beheer (ASL)

Functioneel beheer (BiSL)

De gebruikersorganisatie maakt gebruik van de afdeling Functioneel Beheer als communicatie

mechanisme richting de ICT organisatie. Functioneel Beheer is hierin primair aan de

gebruikerskant beschikbaar voor het ondersteunen van gebruikers. Voor zover van belang voor

de CPM methode is functioneel beheer de afdeling die wijzigingen t.b.v. van de Informatie

Voorziening opstelt, uitwerkt en indient. Aan de zijde van ICT is een (virtueel) serviceteam dat

bestaat uit twee kampen, namelijk Applicatie Beheer en Technisch Beheer. Hierbij is voor het

Technisch Beheer primair de taak om de technische inhoudelijke zaken te beheren en voor het

Applicatie Beheer de taak om de applicaties te beheren. Deze focus is uiteraard dezelfde

wanneer een verzoek tot wijziging wordt ingediend, namelijk vanuit een technisch beheer

perspectief en een applicatiebeheer perspectief.

Page 6: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {159}

Aangezien het te veel methodes zijn die dit domein beheersen en omdat deze methodes ook zeer

uitgebreid zijn, worden deze in dit hoofdstuk beperkt tot het beschrijven van ITIL, ASL en BiSL.

Tevens zal een moedige poging worden ondernomen om de beschrijving zo min mogelijk het

opsommen van processen zijn om de leesbaarheid te bevorderen. In de behandeling van de

processen behorende bij de CPM methode worden ITIL en BiSL genomen als ijkpunt.

1. ITIL

ITIl bestaat uit drie onderdelen, die elk weer hun eigen subprocessen meebrengen. Deze drie

onderdelen zijn:

Service Operation; Dit zijn alle processen die primair gericht zijn op het draaiend houden van de

dagelijkse gang van zaken, dus het leveren en ondersteunen van services. De belangrijkste

onderliggende processen zijn:

Incident management; Alle processen die gericht zijn op de zo snel mogelijke afhandeling

van een verstoren op een service in de productionele omgeving. Hoe hard ITIL ook poogt

deze los te koppelen: dit is de helpdesk.

Event management; het monitoren van alle mogelijke verstoringen (events) van de huidige

productieomgeving. Een event wordt gedetecteerd, gefilterd, gecategoriseerd en na een

adequate reactie weer afgesloten. Gedacht moet worden aan het koppelen van agents

(event detectoren) aan een database om pro-actief te voorkomen dat de database te groot

wordt om nog op een server te passen.

Problem management; Het proces van analyseren van incidenten en het proberen om de

onderliggende problematiek te vinden en op te lossen. Wanneer een gebruiker een

vastgelopen computer heeft, heeft het incident management de oplossing in het opnieuw

Page 7: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {160}

aan- en uitzetten van de computer. Hiermee is het onderliggende probleem niet opgelost,

namelijk waarom de computer eigenlijk in de eerste plaats vastliep.

Service Design; Het bouwen, testen, onderhouden van services in de operationele omgeving in de

vorm van releases. De hierbij onderliggende processen zijn:

Supplier Management; Alle processen die nodig zijn om de relatie met de diverse

leveranciers te waarborgen. Dit in de gewenste constante kwaliteit en tegen de laagste (of

althans de meest acceptabele) kosten.

Service Level Management; Een SLA is een overeenkomst om de te leveren dienst aan een

klant in een contractvorm vast te leggen. Hierin staat gekwantificeerd wat een klant kan

verwachten en waar een leverancier aan moet voldoen. Dit start al met het benoemen van

de werktijden van de helpdesk en omvat zaken als de maximale tijd die deze helpdesk er

over mag doen om een issue op te lossen.

Service Catalog Management; De diverse processen die nodig zijn om een service op te

nemen in een voor eindgebruikers bruikbare catalogus om de beschikbare services weer te

geven. Deze catalogus kan gezien worden als het winkelwagentje van alle services.

Availability Management; Alle processen die gericht zijn op het managen van de

beschikbaarheid van de services voor de klanten. Doel van dit proces is het niveau van

beschikbaarheid op een reactieve en proactieve wijze te volbrengen conform de afgesproken

SLA.

Service Transition; Het geheel aan processen dat verantwoordelijk is voor het in beheer nemen van

veranderingen in de productionele omgeving. De deelprocessen zijn:

Change Management; Het proces van vastleggen en begeleiden van alle wijzigingen naar de

productionele omgeving. Hierbij wordt een standaard proces vastgehouden waarbij het doel

is om de wijzigingen zo min mogelijk de huidige productie te verstoren.

Knowledge Management; Het kennismanagement proces is gericht op het overdragen van

kennis om de algemene kwaliteit van de processen te verbeteren. Tevens is het gericht op

het verhogen van de kwaliteit van de kennis van de personen die betrokken zijn in het ITIL

proces.

Release & Deployment Management; Het proces van begeleiden van alle wijzigingen richting

productie.

Service Testing & Validation; het toetsen van de service op de wenselijkheid van de service

voor de eindgebruiker.

Hierboven hangt het overkoepelende Service Strategy Process; Dit zijn diverse processen en

methodes om met eindgebruikers samen de markt van een organisatie te bepalen en de daarvoor

benodigde services ter ondersteuning te ontwerpen, bouwen en in productie te nemen.

Page 8: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {161}

2. BiSL

BiSL staat voor Business Information Service Library en is binnen grote Nederlandse organisaties

geadopteerd als middel om de informatie behoefte vanuit de gebruikersorganisatie op te vangen

richting de IT afdeling en om de belangen te behartigen van deze gebruikers. Het is bedoeld als

raamwerk voor Functioneel Beheer en Informatie Management.

Figuur 3 BiSL overzicht

BiSL bestaat uit drie niveau’s, die elk ook haar eigen rollen kent. Deze niveau’s voeren de

informatievoorziening uit met de volgende doelen:

Richtinggevend; De CIO wordt door de informatie manager voorzien van de strategische plannen

en uitvoering van IM. Hier wordt het beleid bepaald, uitgezet en gemonitord. Hieronder vallen:

1. Inrichting van de informatievoorziening; Voor het inrichten van de

informatievoorziening worden alle betrokkenen, gebruikersorganisatie, ketenpartners

en leveranciers, betrokken om uiteindelijk de strategie van de informatievoorziening in

te richten.

2. Inhoudelijke toekomst van de informatievoorziening; Het bepalen van de

informatievoorziening voor de toekomstige ontwikkelingen van een organisatie. Hierbij

komen de subprocessen als het ontwikkelen van de informatieketen, het bedrijfsproces

en de informatiebehoefte zelf samen in het opstellen van een informatie lifecycle en

portfolio.

Page 9: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {162}

Sturend; De systeemeigenaren en productmanagers worden op tactisch niveau voorzien van

informatievoorziening. Bijbehorende processen zijn:

1. Planning & control; Het bijhouden van de verandercapaciteit (resource management),

monitoren van de tijdslijnen. Hierbij wordt ook een projectenkalender bijgehouden als

stuurelement.

2. Financieel Management; Met behulp van de business case, de marktconformiteit van

ICT-dienstverlening en het financieringsmodel, wordt de financiële

informatievoorziening opgezet, onderhouden en bewaakt.

3. Behoefte Management; het laten aansluiten van de informatievoorziening op de

bedrijfsprocessen op de gebieden van medewerkers, omgeving, kwaliteit van de

informatie en de procesgang van de organisatie.

4. Contract Management; Het plannen, controleren en evalueren van de geleverde diensten

vanuit de ICT organisatie ten opzichte van de afgesproken contractuele kwaliteits- en

kwantiteitsnormen.

Uitvoerend; De kerngebruiker en superuser interacteren op operationeel niveau met de

medewerkers van Functioneel Beheer. Kerntaak van Functioneel Beheer is het vertalen van het

bedrijfsproces naar informatievoorziening.

1. Gebruiksbeheer; het operationeel bewaken en monitoren van de informatievoorziening

over de processen. Hierbij komen service calls binnen en worden behandeld,

verwerkingen van batches gecontrolleerd en bewaakt en wordt de eindklant

geïnformeerd.

2. Functionaliteitenbeheer; Het onderhouden van de huidige functionaliteit en het

begeleiden van eventuele wijzigingen zodat deze conform de wens van de eindgebruiker

is. De processen die hierbij gevolgd worden zijn het specificeren van functionaliteit, het

vormgeven en het testen en toetsen van de nieuwe (of gewijzigde) functionaliteit.

3. Verbindende processen; Het wijzigingsbeheer is de verbindingsweg van gebruiksbeheer

naar functionaliteitenbeheer. Het omvat het inventariseren, registreren, evalueren en

prioriteren van wijzigingen. De transitie processen zijn de processen de andere kant op,

namelijk gericht op het in productienemen van functionele wijzigingen.

3. ASL

Voor het verder uitwerken van de methodes zal ASL niet worden meegenomen. ASL lijkt in haar

verschijningsvorm erg op BiSL en de processen zijn dus vrij eenvoudig op dezelfde wijze te

matchen op de diverse CPM processen. Deze paragraaf zal deze methode toch rudimentair

beschrijven.

ASL, Application Services Library, is een proces model dat ook door de BiSL organisatie

beheerd wordt. ASL is gericht op bestaande applicaties en heeft als zodanig niets te maken met

projecten die nieuwe applicaties tot gevolg hebben. Het betreft het aanpassen van de bestaande

functionaliteit n.a.v. issues in productie of gewijzigde eisen en wensen.

Page 10: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {163}

Figuur 4 Het ASL model

ASL is ook weer ingedeeld in strategisch, tactisch en operationeel. Hierbij komt bij het beheer de

volgende vijf processen:

Incidentenbeheer; Het registreren en oplossen van incidenten op het gebied van

applicatie management. De registratie vindt plaats bij de centrale servicedesk, waarbij

het incident doorgerouteerd wordt naar applicatie management.

Configuratiebeheer; Administratie van de de diverse applicaties of onderdelen van de

applicatie. Hier worden ook de wijzigingen hierop bijgehouden.

Beschikbaarheidsbeheer; Het meten, registreren en rapporteren van de beschikbaarheid

van (onderdelen) van een applicatie. Hierbij wordt een beschikbaarheidsplan gemaakt

voor het huidige en toekomstige applicatief beheer.

Capaciteitsbeheer; Het beheren van de fysieke randvoorwaarden als geheugenruimte,

CPU, etc.. Hier wordt de mapping gedaan van functionaliteit en de technische

infrastructuur, waarbij de vraag kan worden beantwoord of een wijziging op het

landschap niet teveel performance vraagt.

Continuïteitbeheer; Het beheren van het totale landschap v.w.b. het zorgen voor het

continu aanbieden van de applicaties. Hierbij vallen dus ook uitwijkplannen in het geval

van brand, virussen en hackers.

Deze processen zijn te mappen op de processen van BiSL.

Page 11: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {164}

B. Transitie naar Productie

Als we de transitie van project naar productie gaan bekijken, zien we in feite de overgang van

twee CPM domeinen. Daarbij raken we de drie bovenstaande onderliggende methodes die we

eerder in dit boek hebben uitgewerkt, Prince2, ITIL en BiSL. Hierbij komen er enkele opvallende

zaken naar boven. De Prince2 methode heeft geen specifieke processen voor transitie

gedefinieerd. Sterker nog, ze is in principe niet eens ICT gerelateerd. Je kunt er huizen mee

bouwen of de metrolijn onder Amsterdam. De transitie naar productie zal dus gedefinieerd

moeten worden in de afsluitende fase, waarbij de diverse taken die nodig zijn voor het

overdragen naar de lijn moeten gezien worden als workpackages binnen deze fase.

De methodes ITIL en BiSL zijn primair gericht op het beheren van de huidige productie

omgeving en het voorkomen van verstoringen op deze lijn. De praktijk van deze methodes is

vaak gericht op het adapteren van wijzigingen vanuit dezelfde lijn en niet op het opnemen van

hele (grote) projecten. Dit betekent dat de terminologie voor BiSL, ASL en ITIL voornamelijk de

wijzigingen of changes betreffen die de gebruikers organisatie wil doorvoeren op het huidige

productie landschap en niet het opzetten en uitvoeren van projecten. BiSL gebruikt het woord

project in het standaard boek, BiSL – een framework voor Functioneel Beheer en Informatie

Management (van Haren, 2005), pas op bladzijde 81. Hierbij volgt ook de zin: De initiëring,

besluitvorming en aansturing van projecten valt ook onder de sturende processen binnen BiSL. Los

van het feit of dit zinvol of wenselijk is, komt dit in de praktijk niet of nauwelijks voor. De

standaard indeling voor de methodes is:

MSP – het opzetten en invoeren van programma’s binnen organisaties

Prince2 – Project methode voor ICT projecten

ITIL/BiSL – Operationeel beheer framework, inclusief de RfC’s voor de huidige

omgeving.

Nogmaals is het mogelijk om een andere methode voor b.v. projecten te gebruiken, maar de kans

dat ITIL wordt geïntroduceerd in de projectorganisatie is niet groot. Hetzelfde geldt voor het

strategisch meedenken met de klanten met behulp van de ITIL methodes voor het opzetten van

grote verandertrajecten. ITIL is voor de wijzigingen (RfC’s) op de bestaande omgeving met een

vooraf bepaald goedgekeurd budget van de gebruikersorganisatie. De praktijk leert dat dit vaak

een aparte stroom binnen een organisatie is, die wel een afhankelijkheid heeft met projecten.

Deze afhankelijkheid is bijvoorbeeld mogelijk wanneer er wijzigingen plaatsvinden op het

landschap waar ook een project loopt. Hierbij moet in de planning rekening gehouden worden

en moeten de werkzaamheden gecoördineerd worden. Het kan zijn dat kosten bespaard kunnen

worden door sommige wijzigingen dan door het project mee te laten nemen omdat een bepaalde

module toch wordt gewijzigd in het kader van het project. De afhankelijkheid van wijzigingen en

projecten kan ook directer tastbaar zijn, wanneer een project in haar planning afhankelijk is van

een wijziging. In het eerste proces, Opname van de Service in Portfolio, wordt de overlap

Page 12: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {165}

aangegeven en worden de processen aan de beheer zijde beschreven waar de projecten mee te

maken zullen krijgen. Vanaf het tweede proces is er geen project inmenging meer aanwezig.

Primaire taak voor het operationele beheer is het garanderen en continueren van de huidige

productie omgeving. Hierbij moet elke wijziging gezien worden als een potentiële verstoring van

deze omgeving die bijvoorbaat liever niet moet doorgevoerd worden. Echter zal dit niet mogelijk

zijn en moet de beheerorganisatie zorgdragen dat ze gereed is voor wijzigingen. Voor het

draaiende houden van de services is het zaak om zodanige eisen op te stellen aan de

opleverende partijen, dat de verwachte impact op productie minimaal is, of op zijn minst

voorspelbaar. Hiervoor zijn enkele processen en acceptatiecriteria opgesteld waaraan een

wijziging moet voldoen voordat deze naar productiegenomen kan worden. Dit geldt zowel voor

wijzigingen als voor projecten.

De oplevering van het Project Management gaat in nauwe samenwerking met de eindgebruikers,

Functioneel Beheer, Applicatie Beheer en Technisch Beheer. De eerste is de opdrachtgever van

het project en degene die aan kan geven of het project voldoet aan haar wensen. De laatste drie

zijn de afdelingen die de service moet accepteren voor uiteindelijk het beheer hiervan. De

acceptatiecriteria zijn voor elke afdeling anders, namelijk:

Eindgebruikers – voldoet de opgeleverde service(s) aan de vooraf opgestelde requirement?

Zowel in kwalitatieve zin als kwantitatieve (performance) zin, accepteert de

gebruikersorganisatie de functionaliteit en het gebruik hiervan, conform de eisen die gesteld zijn

bij de start van een project.

Functioneel Beheer – De acceptatie van Functioneel Beheer heeft betrekking op acceptatie van

de gebruikers documentatie, trainingen, informatie documentatie, werkinstructies,

jobschedules, etc.. Hiermee vertegenwoordigt ze ook de eindgebruikers organisatie omdat de

documentatie en bijvoorbeeld de training ook bij hun als criteria opgevoerd kunnen worden.

Echter is er ook een stevige technische component daarbij.

Technisch Beheer – De criteria voor acceptatie vanuit Technisch Beheer hebben betrekking op

de fysieke service zelf, de broncode waarmee deze gebouwd is en de technische documentatie

waarmee deze wordt opgeleverd.

Elk van deze afdeling heeft haar eigen moment van controle van de acceptatie criteria, waarbij

deze getoets moet worden. Voor de meeste criteria geldt dat deze moeten gerealiseerd worden

tijdens de realisatiefase of in de stadia daarna. Ongeacht de mogelijke indelingen van ICT

projecten, deze verschilt per organisatie, en de daarvoor gebruikte termen, heeft de indeling van

een standaard project de volgende fasen:

Figuur 5 Standaard projectstadia

Vooronderzoek; het vooronderzoek levert inzage in het doel, de scope en de daarvoor

benodigde tijd, geld en kwaliteit. In Prince2 termen levert deze fase een PID op ter goedkeuring

voor de rest van de fasen.

Page 13: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {166}

Realisatie; het bouwen en inrichten van de applicatie. Tijdens deze fase zullen de meeste

objecten worden gefabriceerd die nodig zijn voor de acceptatie van Technisch Beheer.

FAT; de Functionele Acceptatie Test is de fase waarin Functioneel Beheer toetst of de gebouwde

functionaliteit voldoet aan de eisen zoals deze zijn opgesteld door de business analist tijdens het

vooronderzoek. Dit gaat niet op gebruikersgemak, maar op werkwijze en correctheid van de

informatie verwerking.

GAT; de Gebruikers Acceptatie Test is de periode waarin de eindgebruikers, vaak begeleid door

Functioneel Beheer, de applicatie toetst voor gebruik. Hierbij wordt gekeken of de applicatie

voldoet aan de verwachting en of de werkwijze conform de eisen is.

PAT; de Productie Acceptatie Test is de fase waarin de technische beheerorganisatie de

oplevering vanuit de realisatie toetst op grond van de werking van de applicatie in de productie.

Ze doet dit door een omgeving op te zetten die nagenoeg gelijk is aan productie om te kunnen

testen of de performance acceptabel is en of de impact op de huidige productie omgeving

miniem is.

Voor alle beschreven fasen zijn acceptatiecriteria vanuit de belanghebbenden. De afdeling

Functioneel Beheer beoordeelt de oplevering vanuit de realisatie op basis van werkinstructies

voor beheertaken, procesbeschrijving, nazorg inrichting, autorisatieprofielen, SLA

beschrijvingen, issue lijsten vanuit de systeemtest, etc., etc. De eindgebruikers zullen

acceptatiecriteria hanteren op het gebied van opleidingen, gebruiksgemak, werkinstructies voor

eindgebruikers, etc..

De gebruikte terminologie en documentatie zal dus ook voortkomen uit de gebruikte methode

voor de desbetreffende afdeling. Voor de BiSL methode is hier de term Implementatie Plan voor,

de eindgebruikers zullen hier termen gebruikt worden die de bedrijfsprocessen of de

requirements spiegelen en de technische beheerafdeling spreekt over Transitie Planning.

Vanuit de project management zijde van Prince2 spreekt men niet expliciet over overdrachts-

documenten voor beheer. Deze zijn impliciet weergegeven in het configuratie item management

voor wat betreft de acceptatie criteria van beheer en in het Afsluiten van een Project (AP). Deze

laatste echter is zeer gericht op het goed afsluiten van een project en het leren vanuit de

opgedane ervaring. Dit zijn activiteiten die aan het einde van de nazorg periode plaatsvinden en

niet met de in productiename van het project. Dit betekent dat het moment van productiegang

impliciet is opgenomen in de fase plannen voorafgaand aan de AP fase.

De acceptatie criteria zijn per afdeling en vaak per organisatie verschillend en zullen hier niet

worden opgenomen. Wel kan hier opgemerkt worden dat specifiek voor het testen de diverse

testsoorten hun weerslag hebben op de criteria. Zoals in het vorige hoofdstuk beschreven

worden testrapportages mogelijk ook opgeleverd vanuit het project management, aangezien

deze de huidige status aangeven van het project wanneer het eenmaal in de testfase zit. Het

aantal en de aard van de testbevindingen zijn vaak een indicatie van de acceptatie richting

productie.

De transitie naar beheer betreft enkele stromen van deliverables vanuit het project naar de

diverse beheerorganisatie. Deze stromen zijn:

Page 14: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {167}

Fysieke deliverables; de applicatie zelf of de gewijzigde objecten die naar productie worden

genomen. Voor de technische beheerders zijn dit de Configuratie Items die ze operationeel

moeten houden en de daarbij behorende bron code die het mogelijk maakt om deze

deliverables wederom te bouwen en te onderhouden. Het transport naar productie wordt door

de technische beheerders zelf gedaan.

Documentatie deliverables; de op te leveren documentatie zoals gebruikersdocumentatie,

processchema’s, trainingen, informatieplannen blauwdrukken, werkinstructies,

gebruikershandleiding, etc. worden overgedragen aan de beheer afdelingen en eindgebruikers.

Vaak betreft dit natuurlijk niet een specifieke overdracht aangezien dit reeds in de voorafgaande

fase uitgevoerd is. De documentatie is verschillend per afdeling en is conform de eerder

beschreven acceptatiecriteria van de desbetreffende afdeling. Facultatief zijn de plannen rond

nazorg (valt dit onder project of zijn dit lijnwerkzaamheden).

Project informatie; In principe is dit ook onderdeel van de Documentatie deliverables, echter is

dit informatie zoals deze gevraagd is door de PMO in opdracht van de organisatie zelf. Voor de

CPM methode is het zinvol om deze specifiek te benoemen aangezien deze een rol speelt in het

opnemen van de service in een portfolio. Onder project documentatie wordt ook de informatie

m.b.t. de kosten van het bouwen, de Project documentatie en de Business Case verstaan.

De overgang van Project Portfolio Management naar het Service Portfolio Management betreft

alleen informatie over de service en niet (onderdelen van) de service zelf. Alle informatie m.b.t.

het project zelf is voor de acceptatie van de service voor het Service Portfolio Management.

Dit is weergegeven als overdracht van het Project Management naar het Operationeel Beheer.

Figuur 6 Overgang tussen Tactisch en Operationeel Portfolio

Aangezien Prince2 geen specifieke zaken opneemt in haar methode over de overdracht naar een

ICT beheer afdeling, is ook de transitie niet opgenomen in het vorige hoofdstuk van Project

Portfolio Management. Conform deze methode is de afsluiting van een fase mogelijk de afsluiting

van het hele project en is de overdracht naar productie opgenomen als werkzaamheden binnen

deze fase.

Page 15: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {168}

In dit hoofdstuk is de focus echter op het beheer van de bestaande lijnorganisatie, waarbij de

processen primair gericht zijn op het handhaven van deze lijn en het begeleiden van mogelijke

wijzigingen hierop. Daarom zal in de komende paragrafen vanuit de methodes niet alleen

beschreven worden welke processen ingericht (moeten) zijn aan de kant van Operationeel

Beheer, maar ook welke processen, taken en deliverables verwacht worden aan de kant van het

Project Management voor een geleidelijke transitie naar de lijn. Het tweede gedeelte zou met

hetzelfde gemak dus opgenomen kunnen worden in het vorige hoofdstuk. Daar zou het echter

vreemd overkomen omdat het kader voor deze processen, de ITIL en BiSL methodes, ontbreekt.

Dit geeft in een notendop weer hoe in de praktijk ook tegen deze processen wordt aangekeken.

De focus binnen de projectorganisatie ligt sterk binnen de eigen lijnen van scope, tijd en geld. De

vraag waarom het project wordt uitgevoerd (Idee Portfolio Management) en dat er na

oplevering ook nog mee gewerkt wordt (Service Portfolio Management) zijn in de praktijk

lastige ontkoppelpunten.

Page 16: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {169}

A. Opname Service in Portfolio Bij de oplevering van een project komt een kantelpunt voor het aansturen, beheer en

eigenaarschap van de producten die gedefinieerd zijn in de scope van het project. Dit kantelpunt

is vrijwel direct, waarbij de inzet vanuit het project nog zeker gewaarborgd moet zijn na deze

overgang. Deze overgang moet ruim vooraf worden voorbereid en alle belanghebbenden zullen

hier een taak in hebben. Vanuit het oogpunt van het project zullen er aan het einde steeds meer

mensen betrokken raken vanuit de lijn organisatie ter voorbereiding van het in beheer nemen.

Aangezien deze lijnorganisatie primair gericht is op het operationele gedeelte, zal een groot

gedeelte van deze lijn echter maar op generiek kennis niveau op de hoogte gehouden worden

van de aankomende wijziging. De personen die binnen een project mee gaan draaien zijn vaak

voor de transitie begeleiding of specifiek als kennisbron van de lijn ingeschakeld voor het

project. Echter betreft het andere rollen en mensen die de producten in ontvangst nemen voor

na deze transitie.

De overgang zal enkele zeer duidelijke go/no go momenten gedefinieerd moeten hebben,

waarbij het proces van de overgang en de rollen goed beschreven moeten zijn. De onderdelen

die hierbij noodzakelijk zijn, komen tot uiting bij de acceptatie criteria van het functionele,

applicatieve en technische beheer. Ook deze zullen niet expliciet worden uitgewerkt voor de

CPM methode, aangezien het zeer afhangt van de gebruikte beheer methode en de terminologie

die hierbij gehanteerd wordt.

Overkoepelend kan verwacht worden dat er een implementatie plan ten grondslag ligt voor de

overgang (go live) naar productie. Hierin zijn alle criteria van de diverse stakeholders

opgenomen, waaronder opleiding voor gebruikers en beheer, acceptatie testen en handleiding

documentatie (wederom voor gebruikers en beheer). Onderdeel van dit plan is het opstellen en

goedkeuren van een transitieplan. Dit plan betreft een draaiboek rondom de in productiename

van het project deliverable. Dit betreft een zeer gedetailleerd stappenplan van de acties die

nodig zijn vooraf, tijdens en na het “aanzetten” van bijvoorbeeld een applicatie.

1. Doel

Doel van 8.1 Opname Service in Portfolio is het accepteren en vervolgens opnemen van de

service(info) in de Service Portfolio. Onderdeel hiervan is het vaststellen van een chargeback

fee voor het gebruik van deze service.

2. Input

Aangezien het project waarschijnlijk een nazorg heeft die ze zelf bemant, is het mogelijk dat de

opname van het project niet gelijk valt met de go live datum van de applicatie. Bij de uitwerking

van de benodigde informatie voor deze opname, wordt veronderstelt dat deze nazorg reeds

heeft plaatsgevonden of dat deze niet mee wordt genomen in de projectplanning. De input die

nodig is de service op te nemen in een portfolio is:

Kosten van het project; Hierbij de totale actuals opgeteld van de geschreven uren en de

aanpalende sourcing die nodig was. Deze zijn noodzakelijk voor enerzijds de Total Cost of

Ownership (TCO) te berekenen en anderzijds als documentatie voor volgende projecten. De

TCO heeft tijdens de start van productiename van een service natuurlijk een totaal andere

belevenis en waarde dan halverwege de levenscyclus. Bij oplevering worden alle bouwkosten in

principe doorbelast naar de eerste afnemer. Wanneer deze puur doorgevoerd moet worden is

deze vaak onevenredig zwaar voor generieke voorzieningen. Hierbij beseffend dat via studies is

Page 17: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {170}

berekend dat zo’n 80% van de totale kosten gedurende deze levenscyclus tijdens de runtime van

een service is en niet in de bouw. De TCO en de chargeback die vervolgens wordt berekend

naar de afnemers, bestaat dus uit de berekeningen van de lopende kosten vermeerderd met een

boekhoudkundige afschrijving van het project over deze tijd. De lopende kosten bestaan zowel

uit (een deel van) de hardware en infrastructuur, de technsiche beheerkosten, de functionele

beheerkosten en alle inzet noodzakelijk voor het draaiende houden van de service in de eerste

en tweede lijn. Uiteraard zijn alle wijzigingen wel goed door te voeren op deze TCO.

Project documentatie; Alle documentatie die niet onderdeel vormen van de acceptatiecriteria

van de beherende of gebruikende afdelingen komen in aanmerking voor opname in het Service

Portfolio. Specifiek wordt hier de planning (van zowel het project als eventuele fasen of

transities), de PID, alle logging en de beslisdocumenten bedoeld. Hierbij wordt tevens een

project afsluitdocument, in Prince2 termen de End of Project Report, en een evaluatie of

lessons learned document. Deze zijn als naslagwerk nodig voor vervolgprojecten of te

gebruiken voor additionele wijzigingen. Tevens is hier een overzicht nodig van alle eventuele

openstaande bevindingen uit de testen en alle nog openstaande issues uit productie (bij

overdracht van de nazorg). Voor beide categorieën zal een beslissing nodig zijn van de lijn

organisatie of deze lijst acceptabel is. Zo niet, moet het project er voor zorgdragen dat hier nog

capaciteit voor nodig is. Het project krijgt vervolgens geen decharge.

De Business Case; Aangezien de baten worden behaald na oplevering van een project, begint bij

opname van de service in de portfolio de periode waarin deze ook daadwerkelijk behaald

moeten worden. Naast het opleveren van de business case, bijgewerkt met de laatste cijfers van

de kosten conform het eerste onderdeel, moet ook de eigenaarschap van deze business case en

de methode van meting worden opgeleverd.

Service Level Agreements; voor zover deze niet door de beheerde afdelingen zelf opgenomen

zijn in de lijst van acceptatie criteria, zal een project alle gemaakte afspraken op moeten leveren.

Hieronder vallen bijvoorbeeld afspraken over de lijst met issues die nog uit de nazorg komen,

tijdstip van overdracht en eventuele additionele training van de projectmedewerkers naar de

lijnmedewerkers.

Specifiek wordt binnen de CPM methode niet meegenomen dat de service opgenomen moet

worden in de beheerde omgeving of dat deze service opgenomen moet worden in een service

catalogus. Uiteraard is dit wel nodig, maar kan in het kader van CPM worden deze acties als

proces(sen) in een onderliggend beheermethode gezien.

Wanneer er een geïntegreerde CPM omgeving is, zijn de verschillende applicaties gekoppeld aan

elkaar, waarbij het mogelijk is informatie te delen. Afhankelijk van het CPM hulpmiddel, de

inrichting hiervan en de informatiestroom die gekozen is, kan de Project & Portfolio

Management tool als leidraad dienen voor alle informatie omtrent een service. De informatie

kan bestaan uit:

Algemene informatie; Wanneer er sprake is van een geïntegreerde omgeving zal het

project met al haar informatie reeds aanwezig zijn binnen de tool. Bij overgang naar

productie verandert de status van het project, waarbij andere personen betrokken

worden. De applicatie wordt opgenomen in de Service Catalogus, de status wordt die

van productie en de uren die gekoppeld zijn aan werkzaamheden op deze applicatie

Page 18: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {171}

worden door beheerders geschreven. Tevens worden alle processen die algemeen

beschikbaar zijn, zoals de helpdesk en 2e lijns ondersteuning, actief. Dit niet alleen fysiek,

maar ook in informatie stroom.

Gekoppelde projecten; Hierbij wordt een overzicht gegeven van alle projecten die nog

lopen of gepland zijn voor deze applicatie.

Wijzigingen lijst; Alle wijzigingen die ingediend zijn via het ideeën proces die gepland of

onderhanden zijn.

Kosten; Via koppelingen naar het urenregistratiesysteem (of gebruik makend van het

eigen urenregistratiesysteem) en een Asset Management systeem kunnen de totale

runkosten inzichtelijk worden gemaakt. Hierbij is het ook mogelijk om deel

doorbelastingen op te nemen van applicaties die bijvoorbeeld maar voor een deel

gebruik maken van een server. Hiervoor dienen ook de lijnmedewerkers de uren te

schrijven op de applicatie die ze beheren voor een juist overzicht.

3. Rollen

De deelname van de rollen betreft zowel de opleverende partij als de ontvangende partij. Zoals

eerder beschreven heeft de project methode Prince2 geen specifieke uitwerking voor ICT.

Daarom is de overdracht als zodanig niet beschreven in een proces of rol. Het kan gezien worden

als een van de taken (work packages) binnen een fase, waarschijnlijk de laatste fase. Voor het

uitwerken van de rollen voor transitie wordt hier daarom Prince2 niet meegenomen, maar ITIL

wel. Bij het uitwerken van de rol is direct aangegeven vanuit welke methode deze wordt

aangeleverd.

Projectleider (Prince2); Vanuit het project is de projectleider eindverantwoordelijke

voor alle deliverables en dus ook voor alle opleveringen met betrekking tot opname van

de service in het portfolio.

Change Manager (ITIL/BiSL); De Change Manager is vanuit de lijn de persoon die alle

wijzigingen op het productielandschap begeleidt. Wanneer de processen hiervoor zijn

ingericht is deze persoon ook verantwoordelijk voor het begeleiden van het lijnproces.

Specifiek is hier o.a. en indien van toepassing, het opvoeren van de change in de

wijzigingenlijsten, opname in de CMDB, wijzigen van de SLA, inrichten autorisatietraject

en het aanvullen van de helpdesk verwerkingen. Aangezien beide methodes een Change

Manager als rol erkennen zullen dus ook twee personen aangehaakt moeten worden,

elke met zijn/haar eigen specificaties.

PMO; Het PMO is niet specifiek betrokken vanuit een methode, maar wel vanuit de

optiek voor het vasthouden van informatie als kennisbank voor andere projecten. Het

PMO is de afdeling die niet alleen aan het project vraagt om de informatie over te dragen,

maar ook als zodanig afsluit (EPR) en zorgt voor de borging van de business case.

Page 19: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {172}

Binnen het BiSL raamwerk wordt de Transitie naar Productie weergegeven in de verbindende

processen tussen Gebruiksbeheer en Functionaliteitenbeheer. De transitie zelf is het uitvoeren

van een transitieplan, waarbij de diverse participerende afdelingen betrokken worden bij het

daadwerkelijk overgaan naar de nieuwe situatie. De voorbereidingen van deze transitie

gebeuren in het onderdeel van Functionaliteitenbeheer, namelijk in de processen Specificeren

(wat wil ik), Toetsen en Testen (Is het wat ik wil?) en Voorbereiden Transitie. Nogmaals wordt

hier benadrukt dat BiSL niet specifiek voor projecten is ingericht, maar voor wijzigingen op het

bestaande landschap. In de praktijk worden de processen Wijzigingenbeheer en Transitie naar

Productie door dezelfde functie uitgevoerd.

Bij de eerste in productie name van een nieuwe service (en dus niet een wijziging op een

bestaande) zal bij de Transitie naar Productie een lijst opgeleverd moeten worden van nog

openstaande issues vanuit het project. Dit kunnen bevindingen zijn vanuit het testen, dus

binnen de grenzen van de acceptatie criteria van Functioneel Beheer, maar ook issues vanuit de

gebruikerswensen. Dit zijn bijvoorbeeld zaken die (bewust) buiten de scope van een project

gehouden zijn. Deze gebruikerswensen zijn dus niet binnen de bevindingen van het testen

gekomen aangezien ze niet zijn opgenomen in de requirements en daarom ook niet als

showstopper aangegeven bij de Transitie naar Productie. Echter staan ze wel op het netvlies

van de eindgebruikers, aangezien deze met voortschreidend inzicht toch gewenst zijn. De eerste

soort issues, de onopgeloste bevindingen, komen direct in het Gebruikersbeheer terecht. Deze

zullen, al dan niet met behulp van het project zelf in de nazorg periode, opgelost worden binnen

de lijn. De tweede soort issues geeft al direct een wensenlijst voor de nabije toekomst die input

betreft voor het opstellen van de Release Kalender.

Voor de transitie naar productie heeft ITIL de processen Release- en Deploymentmanagement

gedefinieerd. Dit zijn processen die een release op een controlleerde wijze moet begeleiden

naar productie. Een release is voor ITIL een set aan gewijzigde CI’s (configuratie items).

Page 20: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {173}

Figuur 7 ITIL service V-model

Voor deze processen heeft ITIL v 3 een V-model gedefinieerd. Hierbij zijn de diverse stappen aan

de kant van de bouw gespiegeld in de processen aan de kant van acceptatie en transitie. Hierbij

worden alle stappen van zowel het opstellen van requirements, ontwerp (functioneel en

technisch) en bouw beschreven. Daar tegenover worden de processen van unit, systeem en

functionele testen geplaatst die elk het proces van specificeren kunnen valideren.

Aan de kant van het project beschrijft het proces Transitieplanning en -support de onderdelen

waar een project aan moet voldoen om via een technische beheerafdeling in productie te

worden opnemen. Het beschrijft de risicobeperkingen, transfers, upgrades, logistieke zaken,

kennisoverdracht en communicatie voor de wijziging. Hierbij wordt een project gezien als een

grote wijziging. Wanneer deze plannen worden goedgekeurd, kan een RfC worden ingediend

naar changemanagement.

De daadwerkelijke overdracht wordt beschreven in het proces deployment. Hierbij zitten alle

processen die nodig zijn om de service fysiek in productie te brengen. Tevens ook de overdracht

naar buiness en organisatie, een proces dat in de praktijk binnen het project wordt opgepakt

met inbreng van deze gebruikersorganisatie. De voor het CPM van belang zijnde proces is de

overdracht van ‘servicemanagementresources’. Hierbij worden de nieuwe of gewijzigde

procesinformatie, systemen en hulpmiddelen overgedragen aan het team dat verantwoordelijk

is voor de servicemanagementactiviteiten.

ITIL hanteert ook het Early Life Support, de periode kort na de oplevering naar productie. Deze

is in de CPM methode de nazorg periode genoemd. Het valt nog binnen de service transitie voor

de ITIL terminologie.

Page 21: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {174}

B. Opstellen Release Kalender Het opstellen van een Release Kalender betreft het maken van een levensverwachting van een

service samen met een lijst met toekomstige functionele wijzigingen uitgezet over een

specifieke periode. Hierbij wordt op hoofdlijnen weergegeven hoe lang een service wordt

verwacht te bestaan, wie de gebruikers zijn of zullen zijn, welke rol deze service speelt in de

gehele Portfolio aan services en de verwachting hoe deze service zich functioneel gaat

ontwikkelen in de toekomst.

1. Doel

Doel van 8.2 Opstellen Release Kalender is het maken van document waarin de toekomst

verwachting van de service wordt opgesteld.

Voor het opstellen van de Release Kalender moet rekening gehouden worden met de reeds

lopende release momenten van de desbetreffende omgeving. Aangezien we uitgaan van een al

lopende operationele omgeving zal deze reeds vastgelegd zijn. Voor de kalender zal deze vaste

periodes als bijvoorbeeld kwartaal gedreven, release datums hanteren. Dit geldt tevens voor

omgevingen waar afhankelijkheden mee zijn. Zo zal een printstraat voor de verwerking van de

brieven van een ERP pakket dezelfde release momenten moeten hebben als het ERP pakket zelf.

Om hier los van te opereren creëert enorme overlap en inefficiëntie.

De Release Kalenders bestaan uit twee dimensies, namelijk de periode waarover men

beslissingen neemt en de inhoudelijke wijzigingen. De periode is zoals eerder genoemd

gekoppeld aan de release momenten die gelden in de specifieke omgeving van de applicatie. Een

groot ERP pakket heeft bijvoorbeeld per kwartaal een release en de beheerafdelingen stellen de

datums (weekenden) aan het begin van het jaar vast in samenwerking met de eigenaren van de

applicatie. Hierbij spreekt men dus bij de Release Kalender in termen als Q1, Q2, Q3 en Q4.

Hierbij zijn de datums van deze kwartalen, bijvoorbeeld 25 september 2011, mijlpalen zijn

waarnaar toe gerekend kan worden met alle voorbereidende werkzaamheden.

Wanneer de service een of meerdere soortgelijke services vervangt of versterkt zal ook in de

samenhang van deze services een Release Kalender gemaakt moeten worden. Dit betekent dus

dat niet zozeer de kalender van de opgeleverde service uitgewerkt moet worden, maar ook de

bestaande service die vervangen gaat worden. Denk hierbij aan het gefaseerd vervangen van

een pakket dat niet meer door de leverancier ondersteund wordt. Bij het opstarten van het

project in de Idee Portfolio Management fase zal dit idee omgezet worden in een project dat

hangt onder het multi-project programma van bijvoorbeeld compliancy. Hierbij wordt de

business case zodanig uitgewerkt dat de kosten van het implementeren van een nieuwe

applicatie worden terugverdiend door het in de toekomst uitzetten en vervangen van de oude

applicatie. Het kan zijn dat deze business case niet positief is, maar desondanks uitgevoerd

moet worden.

Op dit moment zal de Release kalender van de te vervangen service stop gezet worden of in een

apart proces komen. Dit aparte proces is wellicht noodzakelijk omdat elke wijziging op deze

applicatie in principe onnodig is. Echter staan gedurende de looptijd van het vervangingsproject

de wensen van de eindgebruikers, maar ook de wettelijke verplichtingen, niet stil. Door hier een

apart proces in te richten kunnen deze wijzigingen goed gecontrolleerd worden gestuurd en kan

ook de communicatie naar het vervangings project worden gekanaliseerd. Wettelijke

wijzigingen zullen namelijk een wijziging op de scope van het project kunnen veroorzaken.

Page 22: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {175}

Bij de transitie naar productie zal de applicatie eigenaar samen met de beheerorganisatie een

Release Kalender opstellen van de opgeleverde applicatie. Hierbij zal de in de business case

opgestelde gefaseerde afname van de oude service opgenomen moeten worden in de Release

Kalender van deze service.

Binnen het BiSL raamwerk is het opstellen van de Release Kalender in de sturende processen

ondervangen door het onderdeel Behoeftemanagement. Het behoeftemanagement is een

sturend proces waarbinnen de vernieuwingen ten behoeve van de behoeften op

informatievoorzienend gebied. Het proces is ter ondersteuning van de informatie voorziening

van het onderliggende bedrijfsproces. Hierbij is specifiek de behoefte planning van belang voor

het aansturen van het wijzigingenbeheer, wat op uitvoerend niveau de gewenste aanpassingen

maakt voor de onderliggende processen. Binnen BiSL is de term Release Kalender geen

algemene term en komt deze ook niet voor in de processen. Voor het Behoeftemanagement

wordt een jaarplan opgesteld en voor wijzigingenbeheer wordt over het maken van een release

gesproken. Deze laatste is een clustering aan wijzigingen of een project.

Vanuit ITIL wordt er niet (meer) gesproken over een Release Kalender, maar over een

Schedule of Change. De changes worden gebundeld in een release via het Release en

Deployment proces. Het registeren, beoordelen en coördineren van Changes zijn taken van een

Changemanager. Deze beheert de hele cyclus. Dit betekent dat binnen deze cyclus de

afstemming plaatsvindt tussen aanvrager, uitvoerder en bijvoorbeeld een Change Advisory

Board. Voor de CPM methode zijn deze in zoverre van belang dat changes als bundeling in een

release kunnen worden beoordeeld t.o.v. investeringen in een project. Het kan ook zijn dat

changes randvoorwaardelijk zijn voor een of meerdere projecten zodat hierbij de

gecoördineerde taken binnen een portfolio moet worden gewaarborgd.

Input voor het Change Proces zijn de RfC's voortkomend uit de gebruikersorganisatie, service

management, incident management, event management en het Probleembeheer. Voor het

doorvoeren van deze RfC's heeft elke organisatie een eigen proces met betrokkenen ingericht.

Vanuit ITIL is dit een Change Advisory Board, waar de beoordeling van RfC's en het overzicht

van alle changes wordt behandeld. Dit zorgt ervoor dat slechts goedgekeurde changes worden

ingepland en uitgevoerd.

Page 23: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {176}

C. Maken Portfolio beslissingen Binnen het totale domein van het technische en functionele beheer worden bij elk proces

beslissingen genomen omtrent een of meerdere services. Hierbij is het mogelijk dat deze

beslissingen, met de beste bedoelingen, niet het belang van de gehele portfolio meenemen. Net

zoals binnen een programma de daaronder hangende projecten worden gezien als een bij elkaar

horende groep, zal voor het nemen van beslissingen over de operationele services ook de

context van andere services meegenomen moeten worden. Het maken van Portfolio

beslissingen centraliseert dus de diverse processen en beslissingen binnen het IT service

management om de bewustwording van het beheren en aanbieden van een portfolio aan

services richting een klant. Hierbij combineert dit proces o.a. de verschillende Release

Kalenders met de actuele stand van zaken m.b.t. de services.

Voor het maken van beslissingen is het zinvol om deze beslissingen te groeperen in categorieën

die dezelfde aard en structuur hebben. Dit wil niet zeggen dat de beslissingen die genomen

worden binnen een categorie op zichzelf staan. Er bestaat een overlap aan belangen en er is

tevens een gemeenschappelijk criterialijst voor het nemen van de beslissingen. Daarnaast is er

een overlap tussen de processen van het Maken van Portfolio beslissingen in het Operationele,

het Tactische en in het Strategische Portfolio. In het Operationele Portfolio kunnen beslissingen

genomen worden die teruggekoppeld moeten worden naar het Strategisch Portfolio voor zowel

de projecten die zich daarin bevinden als de projecten die reeds onderhanden zijn. Daarbij zijn

de criteria die een organisatie hanteert voor het autoriseren van projecten dezelfde als de

criteria die beoordelen of een project door moet gaan of dat een service gereviseerd moet

worden in het operationele domein.

1. Wijzigingen

Wijzigingen (of Changes) die doorgevoerd worden op de bestaande services. Deze wijzigingen

zijn afkomstig uit de gebruikersorganisatie of de ICT zelf en dienen het verbeteren van de

huidige situatie. De daarbij spelende zaken zijn:

Proces; hoe worden changes ingediend? Welke stappen moeten vervolgens doorlopen worden?

Rollen; welke mensen mogen een change indienen? Welke mensen moeten bij opeenvolgende

stappen werkzaamheden uitvoeren? Wie overziet het totaal?

Beslissingen: welke rollen mogen beslissingen maken binnen het proces? Welke criteria worden

gehanteerd? Binnen welk portfolio worden deze gemaakt (dus de grenzen waarbinnen)? Hoe

borg ik afhankelijkheden?

Tools; welke ondersteunende hulpmiddelen kunnen gebruikt worden? Hoe zijn deze

gekoppeld?

Project ideeën; Voor het opstarten van een project is het niet strikt noodzakelijk het gehele

proces van ideeën te doorlopen zoals deze is beschreven aan het begin van de CPM beschrijving.

Binnen het Changeproces is het namelijk mogelijk om vanuit de bestaande stroom van changes

projecten te initiëren. Hierbij zijn enkele criteria mogelijk, zoals:

de verwachte kosten van een change. Wanneer een change groter is dan 100k € is er geen

sprake meer van een change, maar zal er een project van gemaakt moeten worden. De reden

hierachter is dat een change van die omvang ook gemanaged moet worden door een daarvoor

Page 24: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {177}

specifiek aangestelde projectleider. Deze is ook verantwoordelijk te maken over de totale

oplevering, budget en planning.

de complexiteit van een change. Wanneer een change verwacht wordt impact te hebben op vele

losse applicaties of dat het een behoorlijke organisatorische wijziging met zich meebrengt is het

ook hier beter een project te maken. Vaak zijn de kosten en de complexiteit verbonden, maar dit

is niet strikt noodzakelijk. Hierbij is het ook mogelijk dat de complexiteit komt uit de aangepaste

software.

{voorbeeld} Voor een financieel pakket is de functionele module voor het berekenen van rente over

een incasso zo ongeveer het moeilijkste dat er in zit. Men moet rekening houden met het

uitstaande bedrag, de periode, het afgeloste bedrag en rentestanden. Wellicht ook nog met

staffels en administratiekosten die variabel zijn. Een change in deze module is bijvoorbaat

complex.

de bundeling van changes; Als meerdere changes betrekking hebben op het zelfde gebied dan is

het wellicht zinvol om deze te bundelen tot een project. Het woord "gebied" is een breed concept

en kan slaan op een module, proces, service of applicatie. Het is mogelijk dat de changes

onderling weinig verband hebben, maar in de praktijk is de afhankelijkheden en de daarbij

behorende afstemming vaak de reden om deze te bundelen. Het is echter wel zo dat de changes

onderling diverse prioriteiten hebben waardoor ook minder urgente changes worden

doorgevoerd ten koste van wellicht belangrijkere op een andere module. Zolang deze niet

blokkerend werken voor het totale project is het aan de andere kant ook prettig om diverse

openstaande wijzigingsverzoeken in een keer te kunnen inwilligen.

Figuur 8 Change proces voorbeeld

Hiervoor kunnen processchema's opgesteld worden als in bovenstaande figuur. Uiteraard zijn

hier vele varianten op te bedenken, maar deze figuur geeft in de basis handvatten om

wijzigingen door een organisatie te laten doorvoeren. In eerste instantie zijn er rollen

Page 25: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {178}

gedefinieerd die een change kunnen indienen. Deze kunnen uit diverse afdelingen benoemd

worden. Vanuit een business unit kan dit een key-user zijn, een informatie manager of een

afdelingshoofd. Niet iedereen moet deze functionaliteit ter beschikking hebben. In deze stap is

een enorme versnelling mogelijk door te zorgen voor duidelijke informatie in de wens, de

urgentie en eventuele oplossingen die nodig is. Dit is vaak mogelijk indien er maar een beperkt

aantal mensen autorisatie hebben om dit te kunnen starten. Vanuit de ICT kan dit komen uit een

helpdesk of uit de functionele of technische beheer afdeling. Voor details hiervoor wordt

verwezen naar het ITIL paragraaf aan het einde van dit hoofdstuk.

Er moet een uniek punt zijn waar de wijzigingen ingediend worden. Dit punt levert een overzicht

van alle ingediende wijzigingen, alle daarbij behorende informatie en hun status. Dit is ook de

informatiebron voor de persoon die de wijzigingen moet managen. In het voorbeeld is dit een

change manager. Deze moet niet verward worden met een change manager aan de zijde van

MSP. Bij de indiening zal elke wijziging ook aan een set van criteria moeten voldoen om

opgenomen te worden.

Hierna komt een proces van identificatie, classificatie en verrijking die meerdere zaken tot

gevolg kan hebben. Afhankelijk van deze stap kan een ander proces inwerking gezet worden

(denk aan overdracht naar een afdeling of andere wijzigingen manager) of kunnen mensen

aangehaakt worden om de volgende stap uit te voeren.

De impact analyse kan gebeuren op drie gebieden, namelijk een mogelijk business impact, een

functionele en een technische impact. De business impact kan al uitgevoerd zijn voordat de

wijziging door een key-user is ingevoerd. De technische (TO) of functionele (FO) impact zal dan

nog gemaakt moeten worden. Hetzelfde kan omgekeerd gelden wanneer een afdeling als service

management of functioneel beheer de wijziging heeft ingebracht. De uiteindelijke output van het

proces is een goede inschatting van de kosten, doorlooptijd, wenselijkheid en impact van de

wijziging. Vaak hebben alle drie de invalshoeken een toetsing uitgevoerd naar de standaarden

die binnen hun vakgebied gelden. Zo heeft de business vaak een beleid waaraan getoetst moet

worden en heeft de ICT afdeling een enterprise architectuur die uitmaakt hoe de oplossing er

uit moet komen te zien. Wanneer de ICT een wijziging afwijst omdat het indruist tegen het

beleid van een organisatie is het tijd voor een goed gesprek tussen beide afdelingen.

Besluitvorming van de wijziging betreft het accorderen van de wijziging door alle stakeholders.

Hierbij wordt niet alleen aangegeven dat de wijziging nodig is, maar ook dat men akkoord gaat

met de in de impact analyse gemaakte uitwerking informatie. In de figuur aangegeven met de

twee groene vinkjes. Tevens wordt hier de wijziging in een prioriteitenlijst geplaatst voor de

realisatie van de wijziging. Hiervoor wordt vaak een Change Advisory Board benoemd om deze

wijzigingen te managen.

Uiteindelijk sluit het proces zich door het opleveren van de deliverables die via een Systeem

Test, een Functionele Acceptatie Test en een Gebruikers Acceptatie Test weer in productie wordt

genomen.

Het goedkeuren van changes gaat m.b.v. prioriteit stellen en het handhaven van grenzen in

budget, tijd en scope. De grenzen worden aan het begin van het kalenderjaar vastgesteld en

staan vaak ongenaakbaar vast. De tijd is afhankelijk van de release momenten van de

productionele omgeving, de scope is afhankelijk van de ingediende change en het budget is een

Page 26: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {179}

totaal change budget voor een bepaalde afdeling. Zoals eerder vermeld is voor het CPM domein

altijd mogelijk dat het totaal aantal changes gezien kan worden als een project waarvoor

dezelfde regels gelden als voor willekeurig elk ander project.

De prioriteitstelling van changes kan op dezelfde wijze worden vormgegeven als de prioritering

van projecten zoals deze beschreven is in proces 4.1. Deze wijze wordt uitgewerkt in de

behandeling van de methode achter het stellen van prioriteiten. Ook voor wijzigingen is het

prima doenlijk om een business case te schrijven of om aan te geven welk strategisch doel deze

ondersteunt. Vaak is dit laatste niet het geval en afhankelijk van de hoeveelheid (aantal en

budget) is het wellicht ook niet noodzakelijk om te vermelden. Voor het stellen van prioriteit

komt wel vaak het eigenbelang sterk om de hoek kijken. Men is bang een functionaliteit te

missen en automatisch zijn de changes voor de eigen afdeling urgenter dan die van een andere

afdeling. Hierdoor komt ook geen afweging voor de organisatie, maar de afweging gebeurt met

oogkleppen voor de eigen processen. Het is daarom ook in ieder geval zinvol om minimaal een

business case te eisen waarbij duidelijk beschreven wordt wat de besparingen zijn bij het

doorvoeren van deze wijziging.

Standaard prioriteitmethodes zijn:

MoSCoW-lijsten. Hiermee worden op basis van vier categorieën de changes ingedeeld op basis

van gewenste urgentie. Hierbij staat de lijstnaam voor de volgende ezelsbrug:

Must have: dit zijn de changes waar de eindgebruikers niet zonder kunnen. Deze moeten mee,

anders is het zonde van het budget. Het is noodzakelijk voor het succes van de afdeling.

Should have: dit is heel belangrijk, maar minder tijd en oplever gevoelig als de Must have. Als

deze niet meegaat in de komende release, kan men het beste gaan kijken voor een work-

around om toch in de praktijk dit uit te voeren.

Could have: deze changes zijn niet belangrijk voor het succes van de afdeling. Wanneer het

weinig moeite kost, kan dit meegenomen worden. Denk bijvoorbeeld aan een change van de

Could have categorie die op dezelfde module wordt uitgevoerd als een andere change met

Must have prioriteit. Dan kan deze erbij genomen worden.

Won’t have: Deze change is niet van zodanige impact dat we hem meenemen in deze release. In

principe zullen deze altijd in de achtervang belanden.

Deze methode is redelijk standaard, en levert in de praktijk voldoende stof tot gesprek. Iedereen

heeft voor eigen parochie meer dan een eigenwijze stem in het bepalen van welke functies nu

eenmaal verplicht doormoeten gaan t.o.v. de functies die leuk zijn om te hebben of het leven iets

aangenamer maken. Als voorbeeld is het raadzaam om binnen de groep die prioriteiten moet

bepalen eens een oefening met de MoSCoW-lijst uit te voeren.

{voorbeeld} Bijvoorbeeld over het produceren van een videorecorder: welke knoppen staan in de

Must have, Should have, Could have en Won’t have? Zo zal er een spreiding zijn in het aantal

functionaliteiten in alle categorieën. In een praktijk geval was deze spreiding in de Must have

catagorie van drie tot veertien functies.

Page 27: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {180}

Product Risico Analyse (PRA) is een methode gebruikt in het Tmap testmethode. Hierbij wordt

per (deel)product een analyse gemaakt voor het risico dat daarbij hangt. Hierbij worden ook

categorieën gemaakt op basis van deze risico’s, namelijk hoog, midden of laag. Het risico wordt

berekend door de kans te nemen dat een product gaat falen en deze te vermenigvuldigen met de

schade die vervolgens ontstaat als gevolg van dit falen. Hierbij is de kans van falen ook weer

opgebouwd als de vermenigvuldiging van foutkans maal de gebruikersfrequentie. Nadeel van

deze techniek is dat, zonder wijziging ervan, de insteek puur vanuit de ICT afdeling is bepaald.

De kans op falen komt vanuit de ontwikkelaars en ook de uiteindelijke schade is bepaald als ICT

schade.

Bovenstaande methodes zijn slechts twee van de bekendere wijzen om tot prioritering te

komen. Aangezien beiden nadelen hebben in de originele vorm, wordt hier een generieke

methode beschreven voor prioritering. Om tot een goede inschatting voor de prioriteit van de

changes te komen, zijn de volgende aspecten noodzakelijk:

Representatieve mensen; Voor het bepalen van de prioriteit zal de groep die besluitvorming

rond changes uitvoert moeten bestaan uit alle relevante afdelingen. De business/informatie

management kan de voor de business relevante zaken inbrengen. Daarnaast zit er aan de

beheerkant zowel technisch als functionele afdeling representatie. Daarnaast kunnen de

architecten toetsend bezig zijn in de gewenste vraag en oplossing. Deze groep is dus

bijvoorbeeld:

Business

Beheer (technisch en functioneel)

Architectuur (informatie of applicatie)

Juiste impact of criteria; De criteria per aanwezige afdeling zijn verschillend. Hierbij kan een lijst

worden opgesteld van criteria die per afdeling meespeelt voor de afweging van de changes.

Deze criteria zijn vervolgens eigenaar van deze afdeling. Dit ter voorkoming van het eerder

genoemde voorbeeld dat de ICT afdeling een change afkeurt omdat deze niet conform beleid is.

De ICT afdeling gaat daar niet over.

Business

Business case, NPV of terugverdientijd

Wettelijke verplichting

Vanuit directie afgekondigde richting

Reductie in complexiteit

Standaardisatie/flexibiliteit

Voor de business is het een zaak om goed af te wegen wat het de organisatie oplevert als de

change wordt uitgevoerd. Dit moet zo kwantitatief mogelijk gemaakt worden, waarbij ook de

wettelijke verplichting toe behoort. Het kost namelijk gewoon geld als een wettelijke verplichte

change niet wordt doorgevoerd.

Page 28: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {181}

Beheer

Betere beheersbaarheid

Betere controleerbaarheid

Stabieler

Is de oplossing generiek?

Is het beter onderhoudbaar?

Voor het beheer is het zaak te kijken of het meer of minder werk gaat opleveren wanneer de

change wordt doorgevoerd. De impact is bedoeld voor de run-omgeving en niet voor het

uitvoeren van de change.

Architectuur

Past het in de toekomstige architectuur?

Is het een logische stap naar deze architectuur?

Voor de architectuur is het een toetsing of de change niet alleen past binnen het gewenste

toekomstbeeld, maar ook daadwerkelijk een stap die richting in.

Hierbij moet voor de verschillende groepen ook het risico voor zowel het uitvoeren als voor het

niet uitvoeren van de change bekeken worden. Elk voor haar eigen gebied, zodat de totale

impact van een change wordt bekeken.

Een onafhankelijke, overkoepelende voorzitter; Binnen elke organisatie en haast elke groep zit

iemand die het hardst kan schreeuwen en daarom al 80% van de keren gelijk krijgt. Dit kan de

business zijn in dit toetsingsgroepje, maar soms ook de architect of beheerafdeling. Om

uitspraken te ontdoen van politieke lading en de inbreng per afdeling ook zo objectief mogelijk

te krijgen is het zaak een onafhankelijke voorzitter aan te wijzen die sturing geeft aan het proces.

Bewaking van het proces; Er zijn enkele aspecten aan het proces die niet gevat kunnen worden

binnen de bovenstaande zaken. Sommige changes zullen bijvoorbeeld de lat niet halen, terwijl

het wel zinvol is ze uit te voeren. De reden hiervoor is bijvoorbeeld dat een change een enabler

is voor toekomstige wijzigingen die zeer zeker de gestelde lat zullen halen. De change in kwestie

kan een bepaalde flexibiliteit veroorzaken die randvoorwaardelijk is voor andere changes of

projecten. De change kan op zichzelf gezien bijvoorbeeld geen positieve business case hebben

of voor de beheerafdeling geen noemenswaardige reducering van de complexiteit. Deze

aspecten zijn:

a) afhankelijkheden,

b) tijdsbepalingen

Page 29: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {182}

c) hernieuwde inzichten en

d) organisatorische wijzigingen.

Belangrijk in deze bewaking is de nuance voor de verschillende soorten changes die worden

ingediend en de daarbij behorende gewichten. Denk hierbij aan het feit dat bovenstaande een

vrij zware exercitie is voor sommige changes. Dit zijn bijvoorbeeld kleine changes die voor alle

betrokken partijen overduidelijk goedkeuring vergt en dus snel uitgevoerd moeten worden. Het

zou een grote administratieve balast worden wanneer bovenstaande tot in de puntjes wordt

uitgevoerd. Verder dient tijdens het proces gekeken worden of de change nog steeds voldoet

aan de kriteria van de organisatie (lees: onder de 100k en niet te complex). Ook is een change

die de flexibiliteit verhoogt, en dus als randvoorwaardelijk voor volgende projecten/changes te

fungeren, niet direct op de bovenstaande objectieve criteria te beoordelen.

Figuur 9 Change Advisory Board

Het proces zal dus in diverse stappen worden vrijgegeven naar de uitvoerende organisatie, al

dan niet als change of als project. Het grote verschil tussen beide soorten is het feit dat een

change wordt doorgevoerd naar productie via een vooraf gedefinieerd proces en dat een project

door een projectleider wordt begeleid door dit proces. Zoals in het bovenstaande proces is

getoond is de Change Advisory Board voornamelijk bezig met de vraag “Waarom” om te zetten

in “Hoe”.

Over het algemeen moet gewaakt worden voor het feit dat dit proces niet gezien wordt als

rechtvaardiging achteraf. Het is namelijk eenvoudig om achteraf aan te wijzen waar het fout ging

en welke beslissing juist geweest was. Het is daarom ook noodzakelijk om achteraf te evalueren

welke informatie beschikbaar was ten tijde van de beslissing om zo het proces en de gebruikte

criteria te verbeteren. Aangezien changes over het algemeen in een ander proces uitmonden,

worden ze vaak niet op dezelfde wijze behandeld als een project. Dus tijdens de uitvoer van een

change wordt zelden pas op de plaats gemaakt om te evalueren of de change nog voldoet aan de

vooraf opgestelde criteria. Enerzijds terecht, namelijk wanneer men praat over kleine changes

die snel door het proces worden opgepakt. Anderzijds blijft het resources vragen die anders

ingezet kunnen worden. Wanneer de complexiteit en impact groter is dan verwacht kan een

change ook uitmonden in een zogenaamd functioneel project. Deze moet opgepakt worden

door een technische projectleider. Dit laatste betreft een normaal project, waarbij ook de

normale governance geldt gedurende het project. Echter vallen changes en de daaruit

voortvloeiende functionele projecten niet onder een programma, waardoor de governance van

het programma niet wordt gehandhaafd. In plaats daarvan wordt het op dezelfde manier

aangevlogen als een reguliere change, dus zonder periodieke pas op de plaats.

Page 30: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {183}

Additioneel is er een noodproces nodig die naast de changes en projecten ingericht moet

worden. Input voor het proces zijn ook de zogenaamde Urgente Wijzigingen. Dit zijn ad hoc

wijzigingen die onder druk worden doorgevoerd om in productie bugs op te lossen die de

productie ernstig verstoren. Deze wijzigingen moet vervolgens ook worden doorgevoerd in de

omgevingen die van dezelfde applicatie/service gebruik maken, specifiek de ontwikkel, test en

acceptatie omgeving. Aangezien deze wijzigingen verplicht doorgevoerd moeten worden, ter

voorkoming dat de bug nogmaals optreedt, zal het proces anders eruit zien als een standaard

verzoek tot wijziging. De benodigde informatie met betrekking tot de status van de service

(worden de sources reeds gebruikt in een huidig project? In welk stadium zit dit project? Moet

er een scope wijziging worden doorgevoerd?) bepaalt waar de wijziging uiteindelijk wordt

doorgevoerd. Doel van deze exercitie is het gelijktrekken van alle omgevingen. De

geconstateerde bug is natuurlijk niet automatisch verdwenen in een testomgeving. De gekozen

oplossing voor het snel herstellen van productie zal na het optreden en oplossen, versneld en

met hoge prioriteit het reguliere proces van de Change Advisory Board moeten doorlopen. Dit

is ter verificatie dat de gekozen oplossing ook toekomst vast is of dat er een andere oplossing

gekozen moet worden. In het laatste geval zal de tijdelijke oplossing in productie ook weer

verwijderd moeten worden.

1. Business Case

De overdracht van het project naar de lijn (al dan niet voor of na het nazorg traject) is een

mogelijke trigger om de huidige portfolio aan services onder de loep te nemen. Daarna komt

een additionele trigger, namelijk het breakeven moment voor de business case.

Ondanks het feit dat praktisch elk zichzelf respecterende organisatie een business case ten

grondslag van een project vereist, zijn er maar weinig bedrijven die de uiteindelijke

consequenties hiervan compleet doorvoeren. Zoals getoond in het eerdere opstellen van een

business case, worden vaak wel de verwachte kosten van een project opgesteld bij aanvang van

een project. Dit betekent dat er een (goede) inschatting gemaakt wordt naar de inzet van alle

mensen binnen het project. Hierbij kokmen de ureninschatting vanuit de personen die ook

verantwoordelijk zullen zijn voor de daadwerkelijke realisatie ervan.

Binnen de project methodes is nadrukkelijk ruimte gereserveerd voor het periodiek bijhouden

van deze business case gedurende de uitvoer van het project. Echter is in de praktijk dit een

activiteit die zelden tot uitvoer komt. Voornaamste reden hiervoor is de hectiek, alhoewel hier

het adagio “geen tijd” natuurlijk een kwestie van slecht plannen is. Een andere oorzaak is het feit

dat deze taken bij de verkeerde persoon belegd wordt, namelijk de projectleider. Deze heeft er

geen baat bij, waardoor het automatisch terechtkomt op een lagere prioriteit. Bij het opstellen

van de business case dient reeds te worden vastgesteld bij wie deze verantwoordelijkheid ligt

en of het project gevoelig is voor externe invloeden die deze business case beïnvloeden.

Uiteraard zijn de interne invloeden binnen het project belegd. Het optellen van een business

case wordt behandeld in Fout! Verwijzingsbron niet gevonden. op bladzijde Fout! Bladwijzer

niet gedefinieerd..

Bij de overdracht van het project naar de lijn moet het monitoren van de opbrengsten worden

belegd. Wanneer bij de aanvang van een project de business case reeds bij de juiste persoon

belegd is, is het een kwestie van nazorg van het project om deze te blijven volgen. Uiteraard is

dit een verbreding van taken binnen de lijn. In ieder geval voor de periode waarin de

Page 31: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {184}

terugverdientijd is gedefinieerd. De besparingen na deze breakeven moment kunnen gezien

worden als de standaard van de processen vanaf dat moment en zal de nieuwe baseline zijn

voor de SLA. Bij deze overdracht zal ook de Earned Value Analyses een rol spelen. Wanneer

een project later oplevert dan gepland zullen ook niet alleen de kosten hoger uitgevallen zijn

gedurende het project (hiervoor zijn conform de governance ook afwijking rapportages

gemaakt en goedgekeurd), maar zal de periode van terugverdienen langer zijn. Tevens zullen de

beoogde besparingen die gepaard gaan met het project in het jaar van oplevering lager uitvallen.

Voor de oplevering van het project zal de mogelijkheid moeten worden gecreëerd om de

business case te blijven volgen gedurende de periode na de oplevering. Aangezien dit reeds in

de basis van de project initiatie moet worden ingericht, is het logisch dat deze inrichting zich

voortzet gedurende de oplevering van het project. In een geïntegreerde CPM omgeving zal dit

uitvoerig moeten worden besproken, aangezien het een zeer ondergeschikte stap is die niet

binnen de cultuur van de meeste organisaties valt.

2. Kwaliteitsplannen

Vanuit de diverse afdelingen is het mogelijk dat er kwaliteitsplannen geïnitieerd worden die als

doel hebben de huidige werkwijze of service aanbod te verbeteren. Dit zijn vaak periodiek

opgestarte, gesloten cirkels die zorg dragen voor een continue verbeterslag voor de huidige

werkwijze. Of dit nu moderne lean-projecten zijn, initiatieve voor Business Process Redesign of

jaarlijks ingestoken TQM processen, deze zijn ingericht om het huidige werk tegen het licht aan

te houden. Vanuit deze plannen komen concrete verbeteringen zoals aanpassen van de

processen, die hun weerslag kan hebben op de aangeboden services zoals deze nu opgenomen

zijn in de productcatalogus.

Indien deze voldoende goed zijn uitgewerkt is het mogelijk deze of via het ideeën proces zoals

beschreven in hoofdstuk 1 of in te dienen als zelfstandige change binnen het

wijzigingenbeheerproces.

Binnen ITIL worden alle services ondergebracht in een Service Portfolio. Deze zijn verdeeld

over alle fasen van de service levenscyclus, namelijk:

Service- pijplijn; Alle services die nog gemaakt moeten worden

Servicecatalogus; Alle operationele services die ook zichtbaar zijn voor de klant

Uitgefaseerde Services; De services die niet meer beschikbaar zijn.

Vanuit de technische beheerafdeling opereert een BRM, een Business Relationship Manager,

die het aanbod van services richting deze Service Portfolio beheert.

Page 32: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {185}

Figuur 10 Strategisch planning- en beheersingssysteem

Binnen ITIL worden services geplaatst in een levenscyclus. Hierbij doorloopt een service de

cyclus ontwerp, transitie en productie (zie figuur) en komt deze wederom via het Continual

Service Improvement proces terug in het ontwerp proces. Dit CSI proces is een periodieke

uitvoer van deelprocessen bedoeld om de huidige service te meten, evalueren en verbeteren. Zij

omvat enkele algemene gebieden, waaronder die van het afstemmen van de IT service portfolio.

De input voor verbeteringen komen uit het servicelevel management.

De verbeteringen kunnen bijvoorbeeld via de Demming Plan-Do-Check-Act cirkel worden

doorgevoerd. Hierbij is de uitkomst van een Plan-fase een SIP, Service Improvement Plan. Dit

plan geeft in hoofdlijnen weer welke verbeteringen doorgevoerd kunnen en moeten worden en

de daarbij behorende onderbouwing van SLA's, KPI's en metingen hieromtrent.

Page 33: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {186}

D. Bijwerken en rapporteren status Portfolio Het bijwerken van de status van het portfolio betreft wederom de actuele administratie ter

ondersteuning van de eerder genoemde processen. Wanneer changes worden goedgekeurd of

als deze van status veranderen (b.v. van systeem test naar acceptatietest), kan dit gezien worden

als een onderdeel van de Release Kalender en dus als onderdeel van de CPM methode. Voor alle

gebieden wordt de specifieke uitwerking in deze paragraaf weergegeven. Verder moet hier wel

toegevoegd worden dat de integratie met de verschillende onderliggende methodes groot is. Het

is moeilijk om specifiek aan te geven welke acties nu bij het te beheren systeem horen en welke

bij een CPM methode.

De Finance & Control van de Service Portfolio Management betreft het bijwerken van de

doorbelasting van services richting de eindgebruiker. De wijzigingen op de charge-back voor

de diverse afdelingen wordt doorgevoerd in de systemen die daarvoor aanwezig zijn. Tevens

geldt dit ook voor de documentatie voor het berekenen van de TCO, benodigd voor het

doorbelasten van een service richting de eindgebruikers. Deze doorbelasting wordt expliciet

niet meegenomen in het bovenstaande CPM proces, maar is uiteraard wel een enorme drijfveer

voor inzage in werkelijk verbruik en basis voor vernieuwingen.

Het bijwerken van de Service Portfolio betreft o.a. de wijzigingen die hierop zijn aangevraagd

door te voeren in de documentatie op de SLA. Dit zijn veranderingen op de service zoals deze

reeds operationeel zijn of additionele afspraken voor nieuwe services. In het operationele

domein zullen deze natuurlijk verwerkt moeten worden in het geheel aan te beheren services,

denk aan het opnemen in eventmanagement, het inrichten van de helpdesk, eerste en

tweedelijns kennisborging en het bijwerken van de diverse administratieve

verwerkingssystemen als asset management systemen en configuratie adminstraties.

Het bijwerken van openstaande wijzigingsverzoeken en dus het bijwerken portfolio

management omgeving (service catalogus). Wanneer enkele verzoeken worden goedgekeurd of

van status veranderen gedurende de levenscyclus van zo’n verzoek, moet deze bijgewerkt

worden in de overzichten die hiervoor gemaakt worden. Hieronder valt tevens het bijwerken

van de genomen beslissingen in proces 8.3. Hierbij krijgt de aanvrager, de eigenaar van de

service of applicatie, een compleet overzicht met status van de verschillende services en

verzoeken hierop.

Het opslaan van de documentatie m.b.t. de wijzigingen die doorgevoerd en in productie zijn

genomen. Hierbij ook de beslissingen die genomen zijn, de kosten en de planning die daarbij

gemoeid zijn.

Verwerken uren gespendeerd aan transitie. Dit voor de totale charge-back, maar ook voor het

vastleggen welke kosten gemaakt worden expliciet voor het verwerken van changes in het

algemeen t.o.v. specifieke kosten die gemaakt worden per change.

Het vrijgeven van capaciteit voor het oppakken van nieuwe wijzigingsverzoeken (resource

management), het reserveren van capaciteit voor het oppakken en oplossen van mogelijke

issues die voortkomen uit het doorvoeren van de wijziging en het eventueel (tijdelijke)

opschalen van de operationele resources.

Page 34: III. Service Portfolio Management · Service Portfolio Management Het Service Portfolio Management wordt gedomineerd door het beheer domein, ook wel Operations genoemd. In de praktijk

Pagina {187}

Het periodiek bijwerken van de project of wijzigingen documentatie, specifiek de Business

Case. Hierbij moet de genoemde opbrengsten vanuit deze project of wijzigingsverzoek

documentatie vergeleken met de actuele situatie. Eventuele grove afwijkingen hierbij zijn niet

meer terug te draaien, het project is immers geweest, maar hier valt wel lering uit te trekken. Bij

het opstarten van nieuwe projecten zal deze lering mee genomen moeten worden voor het

voorkomen van het maken van dezelfde fout. Uiteraard is het zeer afhankelijk van de reden van

de afwijking in hoeverre dit terug te voeren valt op het project, de business of externe factoren.

Maar in principe zullen alle factoren wederom een rol gaan spelen bij het opstellen van nieuwe

business cases voor nieuwe projecten of wijzigingen.

1. Output

8.1 Opname Service in Portfolio Bijgewerkt Portfolio met alle beschikbare services in

productie.

Chargeback fee

8.2 Uitzetten Service Life Cycle Release Kalender

8.3 Maken Portfolio beslissingen MT beslissing

Autorisatie Release Kalender

8.4 Bijwerken en rapporteren status

portfolio

Actueel Service Portfolio

2. Rollen

De rollen die onderdeel uit maken van de deelprocessen voor het handhaven van een Service

Portfolio zijn sterk afhankelijk van de gekozen beheermethode. Hierbij speelt de vraag wie de

service beheert in Service Level Agreement en wie de service eigenaar is.

1. Service Management

2. Hoofd Business Unit

3. Informatie Management

Voor het beheer gedeelte zijn er rollen nodig voor het in productie nemen van de service in een

catalogus, het opnemen van de service in een kosten en chargeback systeem en voor het

uitwerken van een Service Lifecycle. Dit kan een van de bovengenoemde rollen zijn, maar dit

kan ook gedelegeerd zijn.