change
V
IA beschrijft de manier waarop binnen de ANWB veranderingen met een ICT component worden gerealiseerd. Doel van VIA is om deze veranderingen voorspelbaar, beheersbaar en in samenhang door te voeren. VIA biedt hiervoor een toegankelijk en herkenbaar veranderproces gericht op resultaat voor de ANWB en op basis van heldere rollen en verantwoordelijkheden. Gewenste veranderingen binnen de ANWB worden bestuurd op strategisch, tactisch en operationeel niveau. VIA is derhalve opgebouwd uit drie onderdelen, Portfolio, Project en Change, en beschrijft ook de relatie tussen deze besturingsniveaus.
Inleiding VIA Change omvat het operationeel niveau binnen het VIA veranderproces, zie figuur 1, en beschrijft de manier waarop veranderingen op het ICT landschap worden gerealiseerd. Het doel van VIA Change is om op een gecontroleerde en gestandaardiseerde wijze wijzigingen op het ICTlandschap door te voeren met minimale impact op de bestaande bedrijfsprocessen van de klant. Deze brochure beschrijft op hoofdlijnen de aanpak en is bestemd voor iedereen die binnen de ANWB betrokken is bij de uitvoering van een change.
Doel
Portfolio
ANWB ondersteunen bij het realiseren van haar strategische doelstellingen
Doel
Project
Voorspelbaar realiseren van gewenste veranderingen
Change
Voorspelbaar realiseren van een gewenste aanpassing op het bestaande ICT landschap
Doel
VIA Change bestaat uit de volgende elementen:
• Principes • Hoofdproces • Changemanagement DT
Rollen Portfolio Comité (PC) Directieteam (DT) Informatiemanager (IM)
Rollen
Opdrachtgever Senior Supplier Senior User Projectmanager Projectteam
Informatieplanning Portfoliomanagement
Intake
IM Project
Studie & Ontwerp
Realisatie & Afronding Projectmanagement
Rollen
Intaker Opdrachtgever Lijnverantwoordelijke Change coördinator Uitvoerder
Change
VIA Change binnen het VIA Veranderproces
Impact & Oplossing
Bouw & Test Changemanagement
Intaker
Figuur 1
PC
Implementatie
Principes
D
e principes vormen de basis voor VIA Change en dienen als uitgangspunt voor het voorspelbaar en betrouwbaar realiseren van wijzigingen op het ICT landschap.
Gedefinieerde rollen & verantwoordelijkheden
Alle wijzigingen op het ICT landschap worden gerealiseerd op basis van heldere rollen en verantwoordelijkheden. Deze rollen houden rekening met de belangen van de Business (betalende klant), gebruikers en de leveranciers. Goed gedefinieerde rollen en verantwoordelijkheden ondersteunen een heldere en vlotte besluitvorming en betrouwbare ICT dienstverlening.
Managen per deelresultaat
Binnen het VIA Change proces wordt akkoord gegeven op vooraf vastgestelde (deel-)resultaten. Een changecoördinator is verantwoordelijk voor het realiseren van deze deelresultaten en het verkrijgen van een akkoord vanuit de klant en de beheerorganisatie op de levering. Het onderverdelen van een change in deelresultaten maakt het mogelijk om de mate
van beheersing door het bedrijfsmanagement te vergroten en te laten afhangen van de bedrijfsprioriteit, de risico’s en de complexiteit van de change.
Verantwoordelijkheid bij de specialist VIA Change biedt hulpmiddelen en richtlijnen voor het voorspelbaar en betrouwbaar realiseren van wijzigingen op het ICT landschap. Een specialist dient op basis van zijn eigen ervaring en deskundigheid de juiste afweging te maken in het toepassen van deze hulpmiddelen en richtlijnen.
Registratie
Alle veranderingen op het ICT landschap dienen via een change te worden doorgevoerd. Alle changes worden ANWB breed vastgelegd in één en dezelfde registratietool.
Hoofdproces
I
n figuur 2 wordt het hoofdproces weergegeven. Het changeproces start wanneer, op basis van de resultaten van de Intake, positief wordt besloten over uitvoering van een change. De opdeling in drie stappen en deelresultaten borgt vervolgens dat er goed is nagedacht voordat er grote uitgaven worden gedaan, duurzame verplichtingen worden aangegaan of ongecontroleerde veranderingen op het ICT landschap worden gerealiseerd die impact hebben op de ICT dienstverlening. OG
Intake
Helderheid verschaffen in de klantbehoefte en een eerste impactbepaling
Geregistreerde klantbehoefte
Intaker is verantwoordelijk
1
Impact & Oplossing
2
Definiëren van mogelijke oplossingsrichtingen en kiezen van één oplossing
VIA Change proces
Bouw & Test
OG
3
Realiseren en testen van voorgestelde change
Geregistreerde impact & oplossing: Request for Change (RfC)
Changecoördinator is verantwoordelijk
Implementatie
In productie en beheer nemen van goedgekeurde change
Ingeplande change
Geïmplementeerde change: levering
Changecoördinator is verantwoordelijk Akkoord RFC
Figuur 2
OG
Changecoördinator is verantwoordelijk Akkoord change
Akkoord levering
Intake
D
oel van de intake is om helderheid te verschaffen in de wens van de opdrachtgever (business of ICT) en een beeld te krijgen bij de noodzaak, scope en complexiteit van de gewenste aanpassing dan wel uitbreiding op het ICT landschap.
Aanleiding voor het starten van de intake is een idee uit het informatieplan, een project (zie ook VIA Project) of een spontane veranderbehoefte vanuit de opdrachtgever. Op basis van één of meerdere van de volgende criteria besluit de intaker (zie voor een rolbeschrijving Changemanagement), in overleg met de opdrachtgever, hoe de realisatie van een gewenste verandering bestuurd zal worden: • • • • • •
Heeft een 1ste echelon opdrachtgever met mandaat en middelen om de verandering te realiseren Heeft een budget > € 50K Betreft een verandering die meer dan 2 disciplines raakt (excl. ICT) Betreft een verandering die meerdere systemen en/of een keten (of meerdere ketens) raakt Heeft een mate van complexiteit (bv nieuwe technologie) Betreft een nieuw product welke nog niet bekend is binnen het ICT-domein
Een klantwens of veranderbehoefte wordt als change behandeld, wanneer deze niet voldoet aan bovenstaande criteria en wel van invloed is op het bestaande ICT landschap. In tabel 1 wordt een overzicht gegeven van de verschillende type changes die hierbij worden onderscheiden. De intaker is vervolgens verantwoordelijk voor het registreren van de klantbehoefte in de centrale registratietool en draagt de change over aan een changecoördinator (zie voor een rolbeschrijving Changemanagement).
Het resultaat van de intake is derhalve een geregistreerde klantbehoefte, waarbij de volgende informatie minimaal wordt opgeleverd: • • • • • •
Aanleiding/Context van de aan vraag Gewenste situatie Domein Datum 1e gesprek Gewenste opleverdatum Naam changecoördinator
Type
Definitie
Goedkeuring
Standaard change
Aanpassing van een bestaande dienst/service. Een veel voorkomende change, waarvan impact laag en bekend is en die herhaalbaar uitgevoerd kan worden
Eenmalige goedkeuring noodzakelijk door (minimaal) opdrachtgever, beheerpartij en beveiliging
Emergency change
Aanpassingen die naar aanleiding van een Prio-1 incident of een dreigende Prio-1 verstoring/risico doorgevoerd moeten worden.
Middels Emergency-CAB ( ECAB)
Change
Tabel 1
Aanpassingen van een bestaande of toevoeging van een nieuwe dienst / product. Impact vooraf niet bekend
Goedkeuring door (minimaal) opdrachtgever, beheerpartij en beveiliging
De verschillende type changes die worden onderscheiden binnen VIA Change
Impact & Oplossing
D
oel van deze stap is om een onderbouwde keuze te maken voor één oplossingsrichting om invulling te geven aan de klantbehoefte. Aanleiding is een door de intaker overgedragen en geregistreerde klantbehoefte. In deze stap wordt de impact bepaald op de betreffende dienst en/of het ICT landschap en wordt een oplossingsrichting gekozen. Om dit te bereiken moet de technische als ook de financiële impact worden bepaald met betrokken partijen en worden één of meerdere oplossingsrichtingen uit-
gewerkt in bijvoorbeeld een functioneel ontwerp. Ook moet de aanpak voor het bouwen en testen van de oplossingsrichting in deze stap worden vastgesteld. De changecoördinator maakt uiteindelijk de afweging welke activiteiten noodzakelijk zijn om een duurzame ICT oplossing aan de klant te kunnen voorleggen. Aan het einde van deze fase levert de changecoördinator een door ICT en door de opdrachtgever goedgekeurde oplossingsrichting, ook wel Request for Change (RfC) genoemd, op en verzorgt registratie in de centrale registratietool.
Implementatie
D
oel van deze fase is het implementeren en in beheer nemen van de gebouwde en geteste oplossing. Aanleiding is een door ICT en de opdrachtgever geaccordeerde en ingeplande change. In deze fase zal de in productie name van de goedgekeurde change plaatsvinden inclusief een gecontroleerde overdracht naar de ICT beheerorganisatie. In veel gevallen zal er een periode van nazorg zijn. Het eindresultaat van deze fase is een door ICT en de opdrachtgever goedgekeurde levering. De changecoördinator verzorgt de afrondende registratie.
Bouw & Test
D
oel van deze stap is om de gedefinieerde oplossingsrichting te bouwen en te testen op de ICT test- en/of acceptatieomgeving. Aanleiding is een vanuit ICT en de opdrachtgever goedgekeurde RfC. In deze stap wordt overgegaan tot alle activiteiten die noodzakelijk zijn voor het productioneel doorvoeren van de gewenste ICT Changes. De gekozen oplossing wordt daadwerkelijk gebouwd, waarbij ontwerpen uit de voorgaande stap de basis kunnen vormen voor de verdere technische invulling van de oplossing. In deze fase wordt de benodigde informatie voor de implementatie verzameld en wordt in productie name ingepland. Als onderdeel van het bouwen van de oplossing zullen, afhankelijk van de complexiteit van de change, ook testwerkzaamheden worden uitgevoerd Het eindresultaat van deze fase is een ingeplande change waarbij door ICT (waaronder de beheerpartij(en) en beveiliging) en de opdrachtgever akkoord is gegeven op de inhoud van de change en met moment van in productie name.
De onderstaande gegevens dienen daarbij minimaal te worden geregistreerd in de centrale registratietool: • • • • • • • •
Test uitgevoerd? ICT beveiliging akkoord? Beheerpartij akkoord? Diverse overige partijen akkoord? CMDB up-to-date? Changekalender ingevuld? Opdrachtgever akkoord? Datum akkoord
Changemanagement
C
hangemanagement beschrijft de manier waarop het geheel aan veranderingen op het ICT landschap wordt bestuurd.
Hierin worden drie niveaus onderscheiden • Operationele uitvoering: beschrijft de besturing van individuele changes • Operationele besturing: beschrijft de besturing van de verzameling aan changes • Procesbesturing: beschrijft de besturing van het proces Per niveau zijn er rollen, verantwoordelijkheden en overlegvormen gedefinieerd. Het voor iedere change vaststellen van de structuur van rollen en verantwoordelijkheden is essentieel voor de succesvolle uitvoering van deze change.
Operationele Uitvoering
V
oor de succesvolle operationele uitvoering van individuele changes worden de volgende rollen onderscheiden:
•
•
•
•
Opdrachtgever: budgetverantwoordelijk; stemt af met eigen lijnorganisatie en neemt de besluiten. Intaker: brengt de klantbehoefte in kaart, verzorgt registratie en de overdracht naar een changecoördinator
Procesbesturing
Changecoördinator: uitvoeringsverantwoordelijk; geeft dagelijkse sturing, verzorgt registratie en afstemming met betrokken partijen. Uitvoerder: voert werkzaamheden uit voor het realiseren van een change
Afhankelijk van de complexiteit van de change kan één medewerker meerdere van deze rollen invullen.
Operationele Besturing
V • • • •
oor het besturen van het geheel aan changes en het aanbrengen van prioriteit worden de volgende rollen onderscheiden: Lijnverantwoordelijke: levert ICT specialisten met voldoende kennis & competenties voor de uitvoering van changes en stelt prioriteiten Opdrachtgever: bepaalt de urgentie van changes t.o.v. elkaar Procesmanager: levert een optimaal proces Beheerder changekalender: levert een up-to-date changekalender
Binnen de operationele besturing wordt van de verschillende rollen verwacht dat er, naast het scheppen van de randvoorwaarden voor de operationele uitvoering, wordt gestuurd op het algeheel functioneren van het proces en van de verschillende ketens.
B
innen de procesbesturing wordt periodiek getoetst of het changeproces nog voldoende ondersteunend is voor de snelle en duurzame uitvoering van changes. De rollen binnen procesbesturing zijn: • •
Procesmanager: levert een optimaal proces Proceseigenaar: eindverantwoordelijk voor het changeproces
Kijk voor meer informatie op de Intranetsite van VIA.
Ontwerp: Alexandra Degraeve Tekst: Darja Bouts