DEEL NEGEN REF. 19 ICT PROCESS FLOWS

De Lijn [email protected] LOGO

Besteknummer PG1280 00311E1

datum 05/06/2013

bladnummer 1

DEEL NEGEN – REF. 19 ICT PROCESS FLOWS 1.

Scope van deze bijlage Dit document bevat de beschrijving van de ICT processen die dienen te worden opgezet in de SAP Solution Manager. De bijlage hoort bij Perceel 1 – Scope onderdeel 6.2 “Functionele opzet SAP Solution Manager”. Deze processen zijn nog onderhevig aan veranderingen op basis van nieuwe inzichten van De Lijn. De definitieve procesflows zullen ter beschikking worden gesteld bij de start van het project.



datum 05/06/2013

bladnummer 2

INHOUDSTAFEL 1.

Scope van deze bijlage ........................................................................................................................ 1

2.

Beschrijving ICT processen ................................................................................................................ 3 2.1.

2.2.

2.3.

2.4.

Incident management ............................................................................................................... 3 2.1.1.

Proces “aanmaken service call” .................................................................................. 3

2.1.2.

Proces “verwerken incident geïntegreerde helpdesk” ................................................. 5

2.1.3.

Proces “Verwerken major incident” ............................................................................. 7

2.1.4.

Proces “verwerken incident 1 lijn” ............................................................................ 10

2.1.5.

Proces “Verwerken incident 2 lijn” ........................................................................... 12

2.1.6.

Proces “Verwerken service request geïntegreerde helpdesk” .................................. 14

2.1.7.

Proces “Verwerking request volgens SOP” ............................................................... 16

2.1.8.

Proces “Afsluiten service call” ................................................................................... 17

2.1.9.

Proces “Knowledge database aanvullen” .................................................................. 19

e

e

Change management ............................................................................................................. 21 2.2.1.

Proces “Change aanvraag indienen” ........................................................................ 21

2.2.2.

Proces “RFC voorbereiden voo CAB” ....................................................................... 24

2.2.3.

Proces “RFC prioritiseren voor uitvoering” ................................................................ 27

2.2.4.

Proces “Change plannen en uitvoeren” .................................................................... 29

2.2.5.

Proces “Change opleveren” ...................................................................................... 31

Release management ............................................................................................................. 33 2.3.1.

Proces “UAT release aaanvraag en planning” .......................................................... 33

2.3.2.

Proces “UAT release installatie, testing en bug fixing” .............................................. 36

2.3.3.

Proces “Intermediate release aanvraag en planning” ............................................... 38

2.3.4.

Proces “Intermediate release installatie, testing en bug fixing” ................................. 40

2.3.5.

Proces “Productie release aanvraag en planning” .................................................... 42

2.3.6.

Proces “Productie release installatie”........................................................................ 44

Test management ................................................................................................................... 47 2.4.1.

Proces “Maken Master Testplan” .............................................................................. 47

2.4.2.

Proces “Voorbereiden UAT” ...................................................................................... 49

2.4.3.

Proces “Uitschrijven testscenario‟s” .......................................................................... 51

2.4.4.

Proces “Uitvoeren integratietesten”........................................................................... 52

2.4.5.

Proces “Uitvoeren systeemtesten” ............................................................................ 55

2.4.6.

Proces “Uitvoeren UAT” ............................................................................................ 58

2.4.7.

Proces “PIT & afwerken testen” ................................................................................ 61



2.

datum 05/06/2013

bladnummer 3

Beschrijving ICT processen 2.1. Incident management 2.1.1. Proces “aanmaken service call” Doel 

Opnemen, evalueren, registreren en categoriseren van de service call.



Zorgen voor complete en kwaliteitsvolle service call informatie.

Input 

Oproep ICT-klant die inhoud service call omschrijft



ICT-klant voert zelf service call in via applicatie

Triggers 

ICT-klant die nood heeft aan een dienstverlening

Activiteiten 

Melden van een service call door de ICT-klant per telefoon of via de Service Desk



Evaluatie, aanvulling, validatie en registratie van de service call door de helpdeskmedewerker



Communicatie naar ICT-klant over eventuele weigering van de aanvraag



Dispatching van de service call

Output 

Gecategoriseerde, geregistreerde en gedispatchte service call (incident of service request of change aanvraag)



Geweigerde afgesloten service call

Procesflow



datum 05/06/2013

bladnummer 4

Procesbeschrijving # 1.1.

Titel Oproep of Web logging

1.2.

ICT-klant belt geïntegreerde helpdesk ICT-klant registreert zelf zijn call in de Service Desk

1.3.

1.4.

Evaluatie/Categorisatie type service call

1.5.

Nood aan bijkomende informatie?

1.6.

ICT-klant vragen om bijkomende informatie

1.7.

ICT-klant geeft bijkomende informatie Service call aanvaarden

1.8.

1.9.

Valideren en registreren van service call in Service Desk

1.10.

Incident of Service Request of change aanvraag

1.11.

ICT-klant informeren over weigering aanvraag/ Dispatchen naar andere dienst

Beschrijving De ICT-klant kan kiezen tussen de geïntegreerde helpdesk bellen of zelf zijn service call aanmaken via de Service Desk toepassing(en). Voor een service request is de regel dat de ICT-klant zelf zijn service call inbrengt via de Service Desk. Zo wordt hij volledig begeleid door de tool en wordt de geïntegreerde helpdesk minder belast. De ICT-klant belt de geïntegreerde helpdesk waar een helpdeskmedewerker hem verder helpt. De ICT-klant registreert zelf zijn service call via de Service Desk. Hij probeert zoveel mogelijke informatie mee te geven en het systeem zou hem daarin op een proactieve en intuïtieve manier moeten helpen. De helpdeskmedewerker opent een nieuwe service call indien de ICT-klant belt en opent de service call indien deze ingegeven werd door de ICT-klant. Hij maakt een eerste analyse van de service call en categoriseert deze via diagnosescripts. Via de knowledge database kan de helpdeskmedewerker alle nodige informatie vinden. Naar aanleiding van de eerste evaluatie en categorisatie kijkt de helpdeskmedewerker na of hij wel over de nodige informatie beschikt. Als er informatie ontbreekt, kan de helpdeskmedewerker de ICT-klant vragen om bijkomende informatie. Dit kan onmiddellijk gebeuren als de ICT-klant nog aan de lijn is. Als de service call via de Service Desk is binnengekomen kan de helpdeskmedewerker de ICT-klant om meer informatie vragen. De ICT-klant geeft de bijkomende informatie door aan de helpdeskmedewerker. De helpdeskmedewerker beslist op basis van de verkregen informatie of hij de service call aanvaardt en dient geregistreerd te worden. Bij twijfel aanvaardt ste de hij de service call en zal de 1 of 2 lijn verder beslissen over de afhandeling. De helpdeskmedewerker moet hier de service call definitief valideren. Dit houdt in dat hij moet nakijken dat de service call volledig is en aanvaard kan worden. Daarna registreert hij de service call definitief in de Service Desk. Vanaf hier gaat de service call door alle verplichte processtappen. Op basis van de categorisatie door de helpdeskmedewerker gaat de service call door verschillende subprocessen die afhangen van het type service call: incident, service request of change aanvraag. De change aanvraagen worden niet verder geanalyseerd binnen dit proces maar zijn opgenomen in het change management proces. De ICT-klant wordt door de helpdeskmedewerker geinformeerd over het waarom van de weigering van zijn service call. Indien nodig kan hij de ICT-klant nuttig doorverwijzen naar de dienst binnen De Lijn die hem beter gaat kunnen helpen. Deze communicatie gaat best via telefoon als de ICT-klant per telefoon de service call heeft gemeld en via de Service Desk toepassing indien de ICT-klant via deze de



1.12.

Afsluiten service call

datum 05/06/2013

bladnummer 5

service call heeft gemeld. In geval dat de service call nooit officieel werd aanvaard kan de helpdeskmedewerker hem ook direct afsluiten zonder door de officiële sluitingsprocedure van een service call te gaan.

2.1.2. Proces “verwerken incident geïntegreerde helpdesk” Doel 

Evaluatie impact(major-minor) en prioriteit incident



Afhandeling incident indien mogelijk, anders escalatie naar 1ste of 2de lijn van de minor incident of naar de incident manager voor major incident

Input 

Geregistreerd incident

Triggers 

Helpdeskmedewerker die de service call dispatcht

Activiteiten 

Evaluatie Major/Minor incident en dispatching major incidenten naar incident manager



Prioriteren van minor incidenten en eventuele communicatie als er een grote impact is



Oplossen incident door de helpdeskmedewerker indien een SOP bestaat



Escaleren en dispatchen incident naar 1ste of 2de lijn wanneer niet opgelost door de helpdeskmedewerker

Output 

Opgelost incident



Log voor knowledge database



Geëscaleerd incident



datum 05/06/2013

bladnummer 6

Procesflow


Titel Major or Minor?

2.2.

Dispatch major incident naar Incident Manager Prioriteren incident

2.3.

2.4.

Grote impact en nood aan communicatie?

2.5.

Communiceer naar de betrokken medewerkers

Beschrijving De helpdeskmedewerker evalueert of het om een major of een minor incident gaat. Hierbij kan hij gebruik maken van al de informatie in de knowledge database. Bij twijfel wordt het incident als major gecategoriseerd en de incident manager beslist dan of het om een major gaat of niet. De helpdeskmedewerker stuurt het major incident verder door naar de Incident Manager. Ook minor incidenten worden naar prioriteit geëvalueerd. Dit gebeurt op basis van een prioriteit-impact matrix. Op basis van de prioriteitsstelling kan later de ste e helpdesk, 1 lijn of 2 lijn medewerker binnen de af te handelen incidenten beslissen waarmee hij begint. De helpdeskmedewerker evalueert of het incident een voldoende grote impact heeft die een onmiddellijke communicatie naar een groep medewerkers vereist. (Deze betrokkenen zijn ofwel aangeduid in een SOP ofwel in bestaande algemene richtlijnen) Dit moet voorkomen dat er onnodige service calls worden ingediend voor incidenten die al bekend zijn. Indien communicatie nodig is gaat de helpdeskmedewerker deze opzetten, anders handelt hij het incident verder af. Indien communicatie nodig is, zet de helpdeskmedewerker deze op. Deze communicatie kan gebeuren via een bericht op het Intranet, ofwel via een bericht op het aanmeldingsscherm van de Service Desk, ofwel kan er



2.6.

Incident op te lossen door geïntegreerde helpdesk?

2.7.

Incident oplossen, documenteren en testen binnen SLA

2.8.

Opgelost SLA?

2.9.

Aanvullen knowledge database

2.10.


2.11.

Escaleren naar 1 de 2 Lijn

2.12.

Dispatch naar 1

ste

lijn

2.13

Dispacth naar 2

de

lijn

binnen

ste

of

datum 05/06/2013

direct een email gestuurd worden naar de betrokkenen. In functie van het type incident kan de helpdeskmedewerker zelf beslissen wat het beste communicatiekanaal is. Voor welbepaalde eenvoudige incidenten waarvoor een SOP met SLA bestaat, kan de helpdeskmedewerker zelf het incident afhandelen. Indien er geen SOP bestaat voor de geïntegreerde helpdesk escaleert hij het incident. De helpdeskmedewerker lost het incident op binnen de afgesproken SLA. Het oplossen van een incident gaat altijd gepaard met het documenteren en testen van dit incident. Eens het incident opgelost is, moet de helpdeskmedewerker de oplossing ook testen. Voor het testen van de oplossing kan de helpdeskmedewerker zelf beslissen wie hij nodig heeft om de tests uit te voeren. Helpdeskmedewerker volgt continu op of hij voor het oplossen van het incident binnen de SLA van de geïntegreerde helpdesk blijft. Indien dit niet het geval is, ste escaleert hij het incident onmiddellijk naar de 1 Lijn. (Het is niet de taak van een helpdeskmedewerker om meer dan enkele minuten bezig te zijn met een incident op te lossen, want zijn helpdeskrol heeft voorrang.) Moet de knowledge database aangevuld worden op basis van de afhandeling van dit incident? Indien wel maakt de helpdeskmedewerker een log aan, indien niet gaat men direct verder met het afsluiten van het incident. Indien het interessante informatie kan zijn wordt er een log gemaakt voor de knowledge database. Deze wordt dan verder opgevolgd door de coördinator support en verwerkt in de processtap “knowledge database aanvullen”. Het normale escalatieschema gaat van geïntegreerde ste ste de helpdesk naar 1 Lijn en van 1 Lijn naar 2 Lijn. In het geval van een incident waarvoor een SOP bestaat de waarin staat beschreven dat het incident door de 2 Lijn behandeld moet worden kan het incident direct de worden geëscaleerd naar 2 Lijn door de geïntegreerde helpdesk. De helpdeskmedewerker dispatcht het incident naar ste een 1 lijn. De helpdeskmedewerker dispatcht het incident naar de een 2 lijn. Kan enkel indien er een SOP bestaat.

2.1.3. Proces “Verwerken major incident” Doel 

Opvolging afhandeling van een major incident

Input 

Gelogd incident na behandeling door geïntegreerde helpdesk

Triggers 

bladnummer 7

Dispatching incident door geïntegreerde helpdesk



datum 05/06/2013

bladnummer 8

Activiteiten 

Diagnose en eventuele validatie als major incident door incident manager



Opvolging afhandeling van een major incident

Output 

Doorgestuurd incident naar 1ste of 2de Lijn



Doorgestuurd incident naar ander proces



Afgehandeld incident



Trigger voor change aanvraag



Trigger voor probleem

Procesflow

Procesbeschrijving # 3.1. 3.2.

3.3

Titel Diagnose Major Incident Validatie als Major Incident

Aanvullen knowledge database?

Beschrijving De Incident Manager evalueert het incident en beslist of het om een major incident gaat of niet. Indien het inderdaad om een major incident gaat, volgt dit incident verder zijn weg als major incident. Indien de Incident Manager echter beslist dat het om een minor incident gaat, wordt dit incident doorgestuurd naar de geïntegreerde helpdesk. Het incident is niet gevalideerd als major door de incident manager. Hij beslist nu of er een log moet komen voor de knowledge database om in volgende gelijkaardige gevallen te voorkomen dat het incident als major wordt doorgestuurd.



3.4. 3.5.

Log voor knowledge database Opzetten Major Incident Team in samenwerking met ICT hoofden

3.6.

Communicatie naar alle betrokkenen

3.7.

Oplossingsplanning opmaken

3.8.

Dispatch naar 1 afste de handelaar (1 of 2 lijn)

3.9.

Oplossen incident

3.10.

Testen oplossing

3.11.

Valideren oplossing

3.12.

Incident opgelost?

3.13.

Communiceren oplossing incident en of work-around naar betrokkenen

3.14.

Geleerde lessen rapport opmaken. Log voor knowledge database

3.15.

Status incident aanpassen?

ste

datum 05/06/2013

bladnummer 9

De incident manager maakt een log voor de knowledge database. De Incident Manager zet een crisis team op. Hierin betrekt hij alle personen die hij nodig acht om de opvolging en afhandeling van dit incident tot een goed einde te brengen. (Hij kan beslissen om als enige deel uit te maken van het crisis team.) Hij checkt af met de ICT hoofden welke resources hij best gebruikt. Een major incident heeft voorrang op alle andere activiteiten. In geval van een major incident wordt er normaal gezien altijd gecommuniceerd naar de nodige personen. De Incident Manager beslist samen met zijn crisis team wat, hoe, wanneer en naar wie er wordt gecommuniceerd. De Incident Manager stelt samen met zijn crisis team een planning op om het incident op te lossen. Hierin worden strikte deadlines gehanteerd voor de verschillende afhandelaars. Er wordt een eerste afhandelaar aangesteld. Hij krijgt de opdracht om het incident op te lossen, een eerste stap naar de oplossing te zetten en/of een workaround te vinden. Deze afhandelaar kan zowel een ste de 1 Lijn medewerker, een 2 Lijn mederker of een externe partij zijn. De verantwoordelijke afhandelaar zoekt naar een oplossing en implementeert deze. De verantwoordelijke afhandelaar test altijd zijn oplossing voor hij deze terugstuurt naar de Incident Manager. Hij kan hiervoor alle nodige personen inschakelen. De Incident Manager kijkt na of de oplossing en/of work-around in orde zijn. Hier zijn er drie mogelijkheden: - De oplossing en/of/work-around van de vorige afhandelaar werkt niet. Er is dus geen oplossing en we gaan over naar een volgende afhandelaar. - De opossing en/of work-around van de vorige afhandelaar werkt wel, maar deze was maar gedeeltelijk. Er is dus geen complete oplossing en/of work-around en dus gaat men over naar een volgende afhandelaar. - De oplossing en/of work-around is compleet. Men gaat over naar het afsluiten van het incident. Indien de oplossing en/of work-around compleet is, moet er onmiddellijk een communicatie komen naar alle betrokkenen. Dit gebeurt via het meest efficiënte kanaal en de Incident Manager(met advies van het Crisis Team) beslist hierover. Na elk major incident is het noodzakelijk om een geleerde lessen rapport te maken. Met dit rapport wordt ook gelogd wat interessant kan zijn voor de knowledge database. Na deze stap sluit men het incident af en stelt men zich de vraag of het incident een trigger kan zijn voor een change aanvraag of probleem. Na elke oplossingsstap kan de status van het incident eventueel aangepast worden.



3.16.

Aanpassen status incident Communiceren naar betrokkenen over statusverandering

3.17.

3.18.

Planning opvolgen/ Crisis Team meeting

3.19.

Dispatch naar volgenste de afhandelaar (1 of de 2 lijn) Trigger voor change aanvraag of Probleem?

3.20.

3.21.

Dispatch naar geïntegreerde helpdesk

datum 05/06/2013

bladnummer 10

De Incident Manager past de status aan indien nodig. Bij elke statusverandering is het goed om een communicatie te sturen naar alle betrokkenen. De Incident Manager (met advies van het Crisis Team) beslist welk kanaal het meest geschikt is. Bij elke planningsstap is het goed om het crisis team bijeen te roepen om de situatie te evalueren en te beslissen over de volgende oplossingstappen. Een volgende afhandelaar wordt aangesteld. Deze afste handelaar kan zowel een 1 Lijn medewerker, een de 2 Lijn mederker of een externe partij zijn. Bij elk major incident moet de vraag gesteld worden of dit incident niet als trigger kan dienen voor een change aanvraag of een probleem. Dit om in de toekomst gelijkaardige incidenten te vermijden. - Een change aanvraag wordt afgehandeld via het change proces - Een probleem wordt afgehandeld via het problem mngt proces Voor de afsluiting van een service call moet met deze dispatchen naar de geïntegreerde helpdesk. e

2.1.4. Proces “verwerken incident 1 lijn” Doel 

Afhandeling van een incident door 1ste lijn of escalatie naar 2de lijn of doorsturen naar change proces

Input 

Gelogd incident na behandeling door geïntegreerde helpdesk of incident manager

Triggers 

Escalatie incident door geïntegreerde helpdesk

Activiteiten 

Diagnose en eventuele vraag voor bijkomende informatie om incident te kunnen oplossen



Oplossen incident en indien nodig escalatie naar 2de lijn

Output 




Geëscaleerd incident naar 2de lijn






datum 05/06/2013

bladnummer 11

Procesflow


Titel Diagnose Incident

4.2.

Nood aan bijkomende informatie? Neem contact met ICT-klant voor bijkomende informatie Aanleveren bijkomende informatie de Escalatie naar 2 Lijn?

4.3.

4.4. 4.5.

de

4.6.

Escaleer naar 2

Lijn

4.7.

Oplossen, documenteren en testen Incident

4.8.

Incident opgelost?

Beschrijving De afhandeling van een incident start altijd met een diaste gnose. Dit helpt de 1 lijn medewerker om het incident te begrijpen en te evalueren of hij over genoeg informaste tie beschikt. Via de knowledge database kan de 1 lijn medewerker alle nodige informatie vinden om een zo precies mogelijke diagnose te stellen. ste De 1 lijn medewerker kan beslissen dat hij meer informatie nodig heeft. Om meer informatie te krijgen neemt hij contact op met ste de ICT-klant. De 1 lijn medewerker is vrij om zijn communicatiekanaal te kiezen. De ICT-klant geeft de nodige bijkomende informatie ste door aan de 1 lijn medewerker. ste Op basis van een eerste diagnose dient de 1 lijn medewerker te beslissen of hij het incident zelf kan oplossen, dan wel beter onmiddellijk escaleert naar de tweede lijn. ste de De 1 lijn medewerker stuurt het incident door naar 2 lijn. ste De 1 lijn medewerker lost het incident op en vergeet niet de oplossing zo goed mogelijk te documenteren. De ste 1 lijn medewerker is ook verantwoordelijk voor het testen van zijn oplossing. Hij kan vrij kiezen wie hij inschakelt voor het testen. Dit kan dus ook de ICT-klant zelf zijn. Na het testen is het incident ofwel opgelost ofwel niet. Indien het incident niet opgelost is, wordt er gekeken of er nood is aan een change aanvraag. Indien het incident opgelost is, gaat men door naar de vraag of er nood is aan een log voor de knowledge database.



4.9.

Aanvullen knowledge database?

4.10.


4.11.

Dispatch naar geïntegreerde helpdesk voor afsluiting Nood aan change aanvraag als oplossing?

4.12.

datum 05/06/2013

bladnummer 12

Moet de knowledge database aangevuld worden op basis van de afhandeling van dit incident? Indien wel maakt men een log aan, indien niet gaat men direct verder met het afsluiten van het incident. Indien het om relevante informatie gaat, wordt er een log gemaakt voor de knowledge database. Deze wordt dan verder opgevolgd door de coördinator support en verwerkt in de processtap “Knowledge database aanvullen”. Voor de afsluiting van een service call moet met deze dispatchen naar de geïntegreerde helpdesk. Wanneer er geen oplossing kan gevonden worden voor het incident kan het zijn dat er een change aanvraag nodig zal zijn om een oplossing te bieden. (Deze change aanvraag kan uitmonden op een normale of een urgent RFC in functie van de situatie.) Indien dit het geval is zal het incident verder worden opgevolgd via het change management proces. Indien geen change aanvraag nodig is, wordt het incident verder geëscaleerd de naar 2 lijn. e

2.1.5. Proces “Verwerken incident 2 lijn” Doel 

Afhandeling van een incident door de 2de lijn of doorsturen naar change proces

Input 

Gelogd incident na behandeling door geïntegreerde helpdesk of 1ste Lijn

Triggers 

Dispatching incident door geïntegreerde helpdesk of 1ste Lijn

Activiteiten 

Diagnose van het incident en eventuele nieuwe dispatching naar 1ste of 2de lijn



Vraag voor bijkomende informatie om incident te kunnen oplossen



Oplossen incident

Output 

Teruggestuurd incident naar 1ste Lijn



Doorgestuurd incident naar andere 2de lijn









datum 05/06/2013

bladnummer 13

Procesflow


Titel Diagnose Incident

5.2.

Nood aan nieuwe dispatching?

5.3.

Terugsturen naar 1 Lijn? ste Dispatch naar 1 lijn afhandelaar

5.4.

5.5. 5.6.

ste

Dispatch naar volgende de 2 lijn afhandelaar Nood aan change aanvraag als oplossing?

Beschrijving De afhandeling van een incident start altijd met een de diagnose. Dit helpt de 2 lijn medewerker om het incident te begrijpen, te evalueren of hij de correcte afhandelaar is en ook te evalueren of hij over genoeg informatie beschikt. Via de knowledge databade se kan de 2 lijn medewerker alle nodige informatie vinden om een zo precies mogelijke diagnose te stellen. de De 2 lijn medewerker kan na diagnose beslissen dat hij om welke reden ook niet de juiste afhandelaar is. Hij kan dan ofwel het incident terugsturen naar ste de 1 lijn ofwel doorsturen naar een andere 2 lijns afhandelaar. Hij moet zijn beslissing wel documenteren. (Men kan niet dispatchen naar een externe parde tij, de 2 lijn medewerker blijft altijd verantwoordelijk, maar hij kan wel beroep doen op hulp van een externe partij.) ste Opsplitsing om ofwel naar 1 lijn terug te sturen ofde wel door te sturen naar 2 lijn. de De 2 lijn medewerker moet het incident terugsturen ste naar de 1 lijn en dispacht dus het incident naar de ste 1 lijn. de De 2 lijn medewerker moet het incident doorsturen de naar een andere 2 lijn afhandelaar. Wanneer er geen oplossing kan gevonden worden voor het incident kan het zijn dat er een change aanvraag is om een oplossing te bieden. Indien dit het geval is zal het incident verder worden opgevolgd via



5.7.

Nood aan bijkomende informatie? Neem contact met ICTklant voor bijkomende informatie Aanleveren bijkomende informatie Oplossen, documenteren en testen incident

5.8.

5.9. 5.10.

5.11.

Incident opgelost?

5.12.

Aanvullen database?

5.13.


5.14.

Dispatch naar geïntegreerde helpdesk voor afsluiting

knowledge

datum 05/06/2013

bladnummer 14

het change management proces. Indien geen change aanvraag nodig is wordt het incident verder afgehandeld volgens het normale traject. de De 2 lijn medewerker kan beslissen dat hij meer informatie nodig heeft. Om meer informatie te krijgen neemt hij contact op de met de ICT-klant. De 2 lijn medewerker is vrij om zijn communicatiekanaal te kiezen. De ICT-klant geeft de nodige bijkomende informatie de door aan de 2 lijn medewerker. de De 2 lijn medewerker lost het incident op en vergeet niet de oplossing zo goed mogelijk te documende teren. De 2 lijn medewerker is ook verantwoordelijk voor het testen van zijn oplossing. Hij kan vrij kiezen wie hij inschakelt voor het testen. Dit kan dus ook de de ICT-klant zelf zijn. Indien de 2 lijn medewerker nood heeft aan een externe partij moet hij dit zelf opvolgen en blijft hij verantwoordelijk. (Enkel externe de partijen onder contract met De Lijn kunnen als 3 lijn support gebruikt worden.) Na het testen is het incident ofwel opgelost ofwel niet. Indien het incident niet opgelost is, wordt gekede ken of een volgende 2 lijn afhandelaar een oplossing zou kunnen bieden. Indien het incident opgelost is, kijkt men na of er nood is aan een aanvulling voor de knowledge database. Moet de knowledge database aangevuld worden op basis van de afhandeling van dit incident? Indien wel maakt men een log aan, indien niet gaat men direct verder met het afsluiten van het incident. Indien het over interessante informatie gaat, wordt er een log gemaakt voor de knowledge database. Deze wordt dan verder verwerkt door de coördinator support in de processtap “Knowledge database aanvullen”. Voor de afsluiting van een service call moet men deze dispatchen naar de geïntegreerde helpdesk.

2.1.6. Proces “Verwerken service request geïntegreerde helpdesk” Doel 

Evaluatie en verwerking van een service request



Nakijken aanwezige goedkeuringen en dispatching naar de correcte afhandelaar

Input 

Gelogde service request

Triggers 

Helpdeskmedewerker die service call dispatcht

Activiteiten 

Evaluatie van het type service request



Opvolging en afhandeling van een niet standaard service request



Nakijken van nodige goedkeuringen en dispatching naar een volgende afhandelaar



datum 05/06/2013

bladnummer 15

Output 

Gedispatchte service request



Voorstel SOP voor nieuwe standaard service request



Geweigerde niet-standaard service request



Geweigerde standaard service request



Afgehandelde service request

Procesflow


Titel Standaard service request?

6.2.

Evaluatie request

6.3.

Niet standaard?

6.4.

Aanvaarden als service request?

6.5.

Dispatchen naar verantwoordelijke afhandelaar

Beschrijving Voor elke service request moet er een SOP of standaard operationele procedure bestaan. Indien een request buiten de afgestemde standaarden valt, wordt de request doorgestuurd aan de coördinator support. De helpdeskmedewerker evalueert of het wel degelijk om een standaard service request gaat. Indien het gaat om een niet standaard service request evalueert de coördinator support de service request. De coördinator support beslist of het al dan niet om een niet standaard service request gaat. Indien het om een niet standaard request gaat, moet de coördinator support kunnen beslissen of hij dit nieuwe request kan aanvaarden. De request aanvaarden houdt in dat dit een nieuwe standaard request zal worden. De coördinator support dispatcht de request naar een ste de 1 of 2 lijn medewerker die dit zal afhandelen.



6.6

Afhandelen service request

6.7.

Aanmaken voorstel SOP voor nieuwe standaard service request

6.8.

Dispatch naar geïntegreerde helpdesk voor afsluiting Communiceer weigering naar ICT-klant

6.9.

6.10.

Dispatch naar geïntegreerde helpdesk voor afsluiting Goedkeuring hiërarchie nodig? Goedkeuring hiërarchie aanwezig?

6.11. 6.12.

datum 05/06/2013

ste

bladnummer 16

de

De verantwoordelijke 1 of 2 lijn medewerker moet een oplossing vinden om dit nieuwe request af te handelen. ste de Op basis van de oplossing die de 1 of 2 lijn medewerker heeft gevonden kan hij een nieuwe SOP procedure opstellen voor deze nieuwe standaard service request. Deze procedure zal later moeten gevalideerd worden door de coördinator support via de processtap “knowledge database aanvullen”. Voor de afsluiting van een service call moet men deze dispatchen naar de geïntegreerde helpdesk. Indien de nieuwe service request niet kan aanvaard worden als standaard zal deze geweigerd worden. Dit wordt duidelijk naar de ICT-klant gecommuniceerd. Voor de afsluiting van een service call moet men deze dispatchen naar de geïntegreerde helpdesk. Sommige service request aanvragen kunnen gelinkt zijn aan een goedkeuring van de hiërarchie. De helpdeskmedewerker moet nakijken of de goedkeuring van de hiërarchie aanwezig is. Dit moet als document gelinkt zijn aan de service request. Indien dit document niet aanwezig is gaat men over tot het afsluiten van de serivce call en zal de ICT-klant een nieuwe service request moeten aanmaken met de nodige goedkeuring.

2.1.7. Proces “Verwerking request volgens SOP” Doel 

Afhandeling van een service request volgens de SOP (standaard operationele procedure)

Input 

Gelogde en goedgekeurde service request na behandeling door geïntegreerde helpdesk

Triggers 

Dispatching service request door geïntegreerde helpdesk

Activiteiten 

Afhandelen service request volgens SOP

Output 

Afgehandelde service request



Doorgestuurde service request



datum 05/06/2013

bladnummer 17

Procesflow


Titel Afhandelen service request volgens SOP

7.2.

SOP nog up to date?

7.3.

Log voor knowledge database/ SOP aanpassing

7.4.

Dispatch naar geïntegreerde helpdesk voor afsluiting

Beschrijving Het afhandelen van een service request verloopt altijd volgens een SOP. In de SOP staat alles stap voor stap ste beschreven. De afhandelaar kan een helpdesk, 1 lijn de of 2 lijn medewerker zijn en voor sommige service requests zullen meerdere personen van verschillende niveaus moeten deelnemen. Bij de afhandeling van een service request wordt steeds nagekeken of de SOP nog overeenstemt met de realiteit. Indien alles nog klopt, gaat men over naar het afsluiten van de service call, anders gaat helpdesk, ste de 1 of 2 lijn medewerker een log maken voor de knowledge database. Wanneer de SOP niet meer overeenstemt met de realiteit wordt dit gemeld via een log voor de knowledge database. Dit kan dan verder opgenomen worden door de coördinator support. Voor de afsluiting van een service call moet men deze dispatchen naar de geïntegreerde helpdesk.

2.1.8. Proces “Afsluiten service call” Doel 

Resultaat afhandeling service call communiceren naar de ICT-klant



Tevredenheid van de ICT-klant meten



Afsluiten van de service call

Input 

Afgehandelde service call

Triggers 

Gedispatchte afgehandelde service call

Activiteiten 

Validatie en tevredenheid van ICT-klant navragen



Analyseren en nakijken van eventuele reden van ongenoegen van de ICT-klant



Afsluiten van de service call



datum 05/06/2013

bladnummer 18

Output 

Heropende service call



Afgesloten service call



Communicatie over afgesloten incident met grote impact

Procesflow


Titel ICT-klant vragen om validatie oplossing/afhandeling

8.2.

Evaluatie oplossing/afhandeling OK met oplossing/afhandeling?

8.3.

8.4.

Feedback tevredenheid

8.5.

Afsluiten service call

8.6.

Incident met grote impact en nood aan com-

Beschrijving De helpdeskmedewerker moet de ICT-klant vragen om de oplossing van zijn incident of de afhandeling van zijn service request goed te keuren. In sommige gevallen is er geen oplossing of is de service request uiteindelijk geweigerd. Dan gaat het niet over een formele goedkeuring maar meer over een aanvaarding van de beslissing door de ICT-klant. De ICT-klant evalueert de oplossing van zijn incident of de afhandeling van zijn service request. Indien de ICT-klant de oplossing/afhandeling goedkeurt/aanvaardt, wordt hij gevraagd om zijn tevredenheid te geven over de manier waarop zijn service call werd afgehandeld.; indien niet moet de helpdeskmedewerker de reden van diens ongenoegen analyseren. De ICT-klant geeft zijn tevredenheid over de afhandeling van zijn service call door. De service call kan na goedkeuring door de ICTklant of coördinator support (indien ICT-klant geen goedkeuring geeft) officieel afgesloten worden. Dit gaat gepaard met een automatisch bericht naar de ICT-klant en de verschillende medewerkers die hebben deelgenomen aan de afhandeling van deze service call. Indient dit incident initieel werd gecatalogeerd als “met grote impact en nood aan communicatie” dient



municatie?

8.7.

Communiceren naar betrokkenen over oplossing incident

8.8.

Diagnose reden ongenoegen

8.9.

Gegronde reden?

8.10.

Terugsturen naar verantwoordelijke oplossing/afhandeling

8.11.

Evaluatie reden van ongenoegen

8.12.

Gegronde reden?

8.13

Communicatie naar de ICT-klant

van

datum 05/06/2013

bladnummer 19

nu terug een communicatie te worden gericht naar de betrokkenen. Indien dit niet het geval is, zijn we aan het einde van het proces. Voor een incident met grote impact wordt er over de oplossing van het incident gecommuniceerd naar alle betrokkenen. De helpdeskmedewerker mag zelf het meest geschikte communicatiekanaal kiezen. De helpdeskmedewerker onderzoekt waarom de ICT-klant de oplossing van zijn incident of de afhandeling van de service request niet kan goedkeuren. Indien de helpdeskmedewerker van oordeel is dat het om een gegronde reden gaat kan hij overgaan tot het terugsturen naar de verantwoordelijke afhandelaar. Indien hij geen gegronde reden ziet, stuurt hij de service call door naar de Coördinator Support die finaal zal kunnen beslissen. Wanneer het incident inderdaad niet is opgelost of de service request niet is afgehandeld, wordt de service call teruggestuurd naar de verantwoordelijste de ke afhandelaar (helpdesk, 1 of 2 lijn medewerker) die de service call opnieuw zal bekijken en afhandelen. De coördinator support kijkt na waarom de ICTklant de oplossing van zijn incident of de afhandeling van de service request niet kan goedkeuren. Indien de coördinator support van oordeel is dat het om een gegronde reden gaat, kan hij overgaan tot het terugsturen naar de verantwoordelijke afhandelaar. Indien hij geen gegronde reden ziet, vraagt hij de helpdeskmedewerker om de argumentatie naar de ICT-klant te communiceren en gaat men daarna gewoon verder met het afsluiten van de service call. Wanneer er beslist wordt dat er geen gegronde reden is om de service call niet goed te keuren wordt dit met argumentatie aan de ICT-klant meegedeeld.

2.1.9. Proces “Knowledge database aanvullen” Doel 

Knowledge database continu verbeteren en aanvullen op basis van de afgehandelde incidenten

Input 

Log voor knowledge database door incident afhandelaar

Triggers 

Afgestemde periodieke trigger (niet afhankelijk van het aantal incidenten of service requests)

Activiteiten 

Verzamelen en categoriseren van alle aanvragen om knowledge database aan te vullen



Laten valideren van nieuwe SOP voorstellen



Aanvullen knowledge database



datum 05/06/2013

bladnummer 20

Output 

Aangevulde knowledge database

Procesflow


9.2.

Titel Oplijsten voorstellen voor knowledge database Categoriseren, aanvullen en valideren voorstellen

9.3.

Is voorstel een SOP?

9.4.

Geïmpacteerde helpdesk niveau‟s moeten SOP testen en valideren SOP ok?

9.5.

9.6. 9.7.

Aanvullen knowledge database Communiceren over aanvullingen knowledge database

Beschrijving De coördinator support moet alle logs voor de knowledge database verzamelen en oplijsten. De coördinator support moet alle logs analyseren en categoriseren. Daarna kan hij ze één per één aanvullen en valideren als nieuwe toevoeging voor de knowledge database. Hij kan ook andere personen betrekken bij de aanvulling en validatie. Een verschil moet worden gemaakt tussen een voorstel om een SOP aan te passen en andere knowledge database aanpassingen. Indien het om een SOP aanpassing gaat moet deze nog gevalideerd worden door de personen die de SOP zullen toepassen. De medewerkers van de geïmpacteerde helpdesk niveau‟s testen de aangepaste SOP om zeker te zijn dat deze ook werkbaar is. Na het testen wordt de aangepaste SOP gevalideerd of niet. Indien hij gevalideerd is, kan de coördinator support gewoon de knowledge database aanvullen. Indien hij niet gevalideerd is, moet het voorstel tot aanpassing terug naar de coördinator support die de nodige aan passingen moet maken. De coördinator support vult zelf de knowledge database aan met de gevalideerde aanpassingen/aanvullingen. Op regelmatige basis stuurt de coördinator support communicaties uit naar de verschillende doelgroepen in verband met de aanvullingen aan de knowledge database. Het is de verantwoordelijkheid van de coördinator support om te beslissen welke het meest opportune communicatiekanaal is. (Email, meeting, nieuwsbrief,…)



datum 05/06/2013

bladnummer 21

2.2. Change management 2.2.1. Proces “Change aanvraag indienen” Doel 

Een change aanvraag evalueren en klaarstomen tot een RFC

Input 

Een change aanvraag

Triggers 

Medewerkers die een idee hebben voor een change



Incidenten die enkel ten gronde kunnen worden opgelost via een change

Activiteiten 

Het aanmaken van een change aanvraag d.m.v. een service call (verplicht voor medewerkers van De Lijn; de eerste lijn, tweede lijn en business analist kunnen onmiddellijk een RFC document opstellen)



Het beoordelen en doorsturen naar de eerste lijn van de change aanvraag door de helpdesk



Het evalueren van de change aanvraag door de eerste lijn



Het opstellen van een RFC document en dit bespreken met de business analist door de eerste lijn



Het evalueren van de change aanvraag door de tweede lijn



Het opstellen van een RFC document en dit bespreken met de business analist door de tweede lijn



Het al dan niet aanvaarden van de change aanvraag door de business analist



Het opmaken van de business vereisten voor de change door de business analist



Het vragen van de goedkeuring van de directeur van het functioneel domein in geval van een urgent change (die geen bug is) door de business analist



Het officieel indienen van de RFC (samen met het RFC document) in de servicedesk door de business analist

Output 

Ingevuld RFC document waarbij business analist een omschrijving geeft van de functionaliteit.



Een registratie van de RFC in de servicedesk



datum 05/06/2013

bladnummer 22

Procesflow

Procesbeschrijving # 1.1

Titel Aanmaken call

1.2

Beoordeling call

1.3

Opname eerste lijn

service

service

Beschrijving De change aanvrager heeft een idee voor een change en geeft dit door met een service call naar de helpdesk. Hij kan de helpdesk via de telefoon bereiken of zelf een voorzet geven via een service call in de Service Desk applicatie. Service desk zal de service call bekijken en doorsturen: mogelijke service call: incident, informatieaanvraag, aanvraag nieuwe functionaliteit. Indien het handelt om een nieuwe functionaliteit zal de call worden doorgestuurd naar de eerste lijn. De eerste lijn (local supports voor technische materies of expertgebruikers voor functionele materies) zal een doorgestuurde call bekijken. Indien de eerste lijn de call niet kan oplossen, stuurt zij



1.4

Change?

1.5 1.6

Opstellen RFC document Opname tweede lijn

1.7

Bug?

1.8

Opstellen RFC document Terechte change aanvraag?

1.9

1.10

Informeer aanvrager en eerste lijn

1.11

Analyse en business vereisten opmaken

1.12

Urgent en geen bug?

1.13

1.14

Goedkeuring vragen aan directeur functioneel domein Aanmaak RFC

datum 05/06/2013

bladnummer 23

deze door naar tweede lijn (resp. dienst infrastructuur of dienst applicaties in de centrale diensten). Indien het gaat om een change aanvraag kan een RFC document worden opgesteld door de eerste lijn. Indien niet, wordt de service call verder afgehandeld binnen het incident management proces. De eerste lijn stelt een RFC document op in samenwerking en overleg met de business analist. De tweede lijn (dienst infrastructuur voor technische materies of dienst applicaties voor functionele materies) zal een doorgestuurde call bekijken. Indien het gaat om een change aanvraag, wordt de eerste lijn gevraagd om een RFC document op te stellen. Bij een bug echter, kan een RFC document worden opgesteld door de tweede lijn. Indien het niet over een change of bug gaat, wordt de service call verder afgehandeld binnen het incident management proces. De tweede lijn stelt een RFC document op in samenwerking en overleg met de business analist. De business analist evalueert de aanvraag op duidelijkheid, meerwaarde voor De Lijn over de verschillende entiteiten. In geval de change aanvraag volgens de business analist onvoldoende meerwaarde heeft, brengt hij hiervan de change aanvrager en de eerste lijn op de hoogte en licht zijn beslissing toe. De business analist bepaalt de scope en geeft duidelijke business vereisten. De business analist kan hier tevens de beslissing nemen dat het om een urgent change gaat, in overeenstemming met de afgesproken criteria (zie definities) In geval van een urgent change dient de business analist de goedkeuring te vragen van de directeur van het functioneel domein. Deze goedkeuring is overbodig indien het gaat om een bug. Opmerking: in geval van een bug komt het initiatief van de change aanvraag doorgaans van de tweede lijn die samen met de business analist het RFC document zal opstellen. De business analist vraag de nodige goedkeuring aan de directeur van het functioneel domein. De business analist voor het desbetreffende functionele domein zal een RFC registreren in de service desk en zal het RFC document daar aanhangen. De business analist vergewist zich ervan dat de functionaliteit gedragen wordt binnen alle entiteiten en de centrale diensten in zijn functioneel domein. De aanvraag moet duidelijk worden omschreven m.b.t. scope, prioriteit, ... volgens de inhoud van het sjabloon. Na aanmaak van de RFC, sluit de business analist alle service calls die door de RFC worden opgelost, en geeft als reden mee dat er een RFC voor werd ingediend.

1.15


Statusaanpassing in Service Desk: Geregistreerd De business analist brengt de aanvrager en de eerste lijn op de hoogte dat de change aanvraag officieel werd in gediend als een RFC.



datum 05/06/2013

bladnummer 24

2.2.2. Proces “RFC voorbereiden voo CAB” Doel 

Aanleveren van alle nodige informatie om een beslissing te laten nemen door de CAB.

Input 

Ingevuld RFC document



Resource planning

Triggers 

De registratie van de RFC in de service desk

Activiteiten 

Bepalen of de urgent change, bug of normale change procedure zal worden gevolgd



Impact van de change inschatten



Zicht krijgen op de nodige resources om de change te kunnen bouwen



De nodige goedkeuringen verkrijgen en nagaan



Het RFC document vervolledigen



De change manager kan de RFC aanvaarden of verwerpen



De change manager kan beslissen dat de RFC moet worden gepromoveerd tot project

Output 

Een duidelijk omschrijving van de gewenste change op vlak van infrastructuur en/of applicatie.



Stappen naar urgent change (indien relevant)



Competenties voor uitwerking van de change



Inschatting van mandagen en kosten



Inschatting planning



datum 05/06/2013

bladnummer 25

Procesflow


Titel Urgent change procedure?

2.2

Analyseer impact en vraag inschattingen

2.3

Vraag nodige goedkeuringen

2.4

Bug?

2.5

Geef goedkeuring?

2.6

Geef goedkeuring

2.7

Geef goedkeuring

Beschrijving Indien het om een urgent change gaat, besluit de change manager dat de urgent change procedure zal worden gevolgd. De betrokken partijen (dienst architectuur, dienst applicaties en dienst infrastructuur) wordt gevraagd om een inschatting (werklast) te geven voor de realisatie. Om te kunnen starten met een dringende change van software of infrastructuur moeten steeds de nodige goedkeuringen worden verkregen. De goedkeuringen die nodig zijn voor een urgent change verschillen al naargelang het om een bug gaat of niet. Normaler wijze is er voor een urgent change een goedkeuring nodig van de directeur van het functioneel domein én van het afdelingshoofd ICT. In het geval van een bug volstaat de goedkeuring van de change manager én van het hoofd infrastructuur. De change manager geeft al dan niet zijn goedkeuring voor urgent change die ook een bug is Het hoofd infrastructuur geeft al dan niet zijn goedkeuring voor urgent change die ook een bug is Het afdelingshoofd ICT geeft al dan niet zijn goedkeu-



2.8

Goedkeuringen OK?

2.9

Verzamel en evalueer RFC‟s

2.10

Analyseer impact en vraag inschattingen

2.11

Verzamel bijkomende RFC info

2.12

Vervolledig RFC

2.13

RFC volledig en correct?

2.14

RFC annuleren?

2.15


2.16

Promoveren tot project?

datum 05/06/2013

bladnummer 26

ring voor een urgent change. Wanneer alle benodigde goedkeuringen gegeven zijn zal een urgent change proces gevolgd worden. In dat geval gaat men onmiddellijk over tot het inplannen en uitvoeren van de change. Wanneer niet alle goedkeuringen voorhanden zijn, wordt het normale change proces verder gevolgd. De change manager verzamelt en evalueert de RFC‟s. Het RFC document wordt gecheckt op correctheid en volledigheid en eventuele additionele informatie wordt aangevraagd. Het aangevulde RFC document wordt doorgestuurd naar de desbetreffende personen binnen applicaties, architectuur, infrastructuur om na te gaan of de aanvraag eenduidig en verstaanbaar is. De betrokken partijen wordt gevraagd om een inschatting (werklast) te geven voor de realisatie van de change. Een inschatting wordt gevraagd van alle betrokken personen (solution architect, business analist, functioneel analist, programmeuranalist, tester, projectmanager indien er een overlap zou kunnen zijn). Inschattingen worden geconsolideerd in RFC document. De change manager zorgt ervoor dat alle informatie van business, BICC en ICT aanwezig is om het RFC document te kunnen vervolledigen. Samenbrengen van alle inschattingen van de verschillende resources + duidelijke afbakening van scope en vereisten. Verifieer of alle informatie aanwezig is van business, BICC en ICT om de RFC op de CAB te brengen. Het RFC document moet volledig en correct ingevuld zijn: business deel A-D; ICT deel 1-7 (zie sjabloon in bijlage). Indien de RFC onvolledig, niet correct of niet meer van toepassing is kan de RFC ofwel worden teruggestuurd om meer informatie te verzamelen ofwel gewoon worden geannuleerd indien de RFC niet meer nodig is. Statusaanpassing in Service Desk bij annuleren: Afgesloten - Geannuleerd Indien de aanvraag is geweigerd, wordt via de service desk de business analist geïnformeerd. De business analist informeert op zijn beurt de aanvrager en de eerste lijn en geeft toelichting bij de reden van de weigering. Indien aan de projectcriteria is voldaan, kan de change manager beslissen dat de RFC het project management proces dient te volgen. De change manager sluit dan de RFC af in de service desk. In het andere geval gaat het change management proces verder. Statusaanpassing in Service Desk bij promotie tot project: Afgesloten – Gepromoveerd tot project

2.17


Statusaanpassing in Service Desk bij geen promotie tot project: CAB Indien de RFC werd gepromoveerd tot project, wordt via de service desk de business analist geïnformeerd. De business analist informeert op zijn beurt de aanvrager en de eerste lijn en verwittigt hen dat zal aandringen bij de business project manager om een projectmandaat op te stellen.



datum 05/06/2013

bladnummer 27

2.2.3. Proces “RFC prioritiseren voor uitvoering” Doel 



Beslissing over de RFC o

vraag voor bijkomende informatie

o

afwijzing + argumentatie

o

goedkeuring van RFC + prioriteit voor latere inplanning

Afweging of change binnen een bestaand project kan worden genomen of bundeling van changes in een project

Input 

Ingevulde en gevalideerde RFC documenten



Resource capaciteit (ICT en BICC)

Triggers 

Eén week voor de CAB meeting

Activiteiten 

Prioriteren van de RFC‟s



Bundelen van de RFC‟s



Beslissen om de change uit te voeren



Beslissen om de RFC te promoveren tot project

Output 

Goedkeuring van voorgestelde RFC



Vraag tot opmaken van een project mandaat



Prioriteiten voor planning van changes

Procesflow



datum 05/06/2013

bladnummer 28


Titel Prioriteren RFC‟s binnen domein

3.2

Bepaal prioriteit (urgentie en belangrijkheid)

3.3

Bijkomende info nodig?

3.4

Bundeling van changes?

3.5

Bundel changes

3.6

Promoveren tot project?

3.7


3.8

Goedkeuring RFC voor uitvoering?

Beschrijving Eén week voor de CAB prioriteren de business analisten de RFC‟s binnen hun domein en geven dit door aan de change manager die het dan op de CAB gaat voorstellen. De RFC wordt op de CAB besproken en uit de verkregen informatie uit het sjabloon wordt de prioriteit bepaald op basis van urgentie en belangrijkheid. CAB dient elke 14 dagen op een vast tijdstip georganiseerd te worden. Een lijst van alle niet besproken aanvragen wordt 2 dagen op voorhand doorgestuurd. Indien bepaalde informatie niet beschikbaar is en relevant om de beslissing m.b.t. de goedkeuring voor de change te nemen, moet bijkomende informatie worden ingewonnen. Statusaanpassing in Service Desk bij nood aan bijkomende informatie: Geregistreerd De CAB bekijkt of verschillende changes kunnen gebundeld worden indien dit een vergemakkelijking zou zijn voor het uitvoeren van de change. Indien het resultaat van de bundeling het aantal dagen zou overtreffen waardoor het als een project moet beschouwd worden, kan de CAB beslissen dat de change/gebundelde changes als een project moeten beschouwd worden. Indien de totale change de 30 dagen (ICT all-in) zou overstijgen, zal de CAB voorstellen om de change te promoveren tot een kandidaat project. De change manager zal als gevolg van deze beslissing de RFC afsluiten in de service desk. Statusaanpassing in Service Desk bij promotie tot project: Afgesloten – Gepromoveerd tot project Indien de RFC werd gepromoveerd tot project, wordt via de service desk de business analist geïnformeerd. De business analist informeert op zijn beurt de aanvrager en de eerste lijn en verwittigt hen dat hij bij de business zal aandringen om een projectmandaat op te stellen. Beslissing van de CAB of RFC al dan niet moet worden uitgevoerd. Afhankelijk van de prioriteit en meerwaarde voor de business en beschikbare resources en huidige bezetting van resources moet bepaald worden of de change wordt aanvaard. De change manager zal de status updaten of de RFC afsluiten in de service desk. Statusaanpassing in Service Desk bij weigering door CAB: Afgesloten – Geweigerd door CAB

3.9


Statusaanpassing in Service Desk bij acceptatie door CAB: In te plannen De CAB heeft de change afgekeurd. De business analist informeert de aanvrager en de eerste lijn en geeft toelicht bij de reden van de afkeuring.



datum 05/06/2013

bladnummer 29

2.2.4. Proces “Change plannen en uitvoeren” Doel 

Inplannen van goedgekeurde change voor realisatie



Realiseren van de change

Input 

Goedgekeurde RFC met indicatie van verwachte oplevering



Ingevuld RFC document waarin de scope beschreven is

Triggers 

RFC CAB goedkeuring



Urgent change

Activiteiten 

Aanvragen resources



Architectuur uitwerken



Infrastructuur uitwerken



Functionele analyse



Technische analyse



Ontwikkeling



Testing



BICC uitwerken

Output 

Kwalitatieve realisatie van software en/of hardware volgens de scope beschreven in de RFC.



Testrapport



datum 05/06/2013

bladnummer 30

Procesflow


Titel Coördineer uitvoering

4.2

Inboeken resources

4.3

Informeer betrokkenen change

4.4

Opvolgen uitvoering change + testen

4.5

Uitvoeren architectuur

4.6

Uitvoeren A, D & T en bouw

4.7

Uitvoeren BICC

4.8

Uitvoeren

infrastruc-

Beschrijving De change manager zal de nodige profielen aanvragen bij de desbetreffende diensthoofden. Change manager zal de verschillende betrokken profielen inboeken volgens de opgegeven inschattingen. Zie het resource management proces voor meer detail. Nu de resources ingepland zijn, brengt de change manager de business analisten en de change aanvrager op de hoogte dat hun change is goedgekeurd en ingepland voor uitvoering. Deze communicatie wordt eveneens gericht aan alle betrokken bij de oplevering van de change en tevens wordt een datum van eerste mogelijke UAT en PROD meegegeven. De change manager volgt de uitvoering van de change op door de verschillende betrokken partijen. Ook ziet hij erop toe dat de gerealiseerde change grondig wordt getest. Statusaanpassing in Service Desk: In uitvoering Analyse Bij changes waar Architectuur is ingeboekt, dient eerst een oplossing te worden voorgesteld. Bij changes waar Applicaties is ingeboekt dient de nodige functionele analyse, technische analyse en ontwikkeling te worden uitgevoerd. Applicaties staat eveneens in voor het testen van de change. Bij changes waar BICC is ingeboekt dient de nodige rapportering worden aangemaakt of aanvulud. Bij changes waar Infrastructuur is ingeboekt, dient de-



tuur Test OK?

4.9

datum 05/06/2013

bladnummer 31

ze te worden opgeleverd. Testresultaten worden afgecheckt en er wordt een oordeel geveld m.b.t. de gevraagde en geleverde functionaliteit.

2.2.5. Proces “Change opleveren” Doel 

Gerealiseerde change opleveren in productie en RFC afsluiten

Input 

Test report van integratie testing



Software- en infrastructuurcomponenten

Triggers 

Realisatie van de change (change plannen en bouw)

Activiteiten 

Aanlevering van softwarecomponenten en infrastructuur componenten in release container

Output 

Change beschikbaar in productie



Afgesloten RFC

Procesflow


Titel Plan release

5.2

Overleg release datum

5.3

Inschrijving in release proces Volg release proces

5.4

Beschrijving Mogelijke release momenten worden nagegaan binnen de release kalender. Statusaanpassing in Service Desk: In uitvoering – UAT aanvraag De release datum wordt bepaald (normale release of urgent release). Business analist checkt voor beschikbaarheid van UAT testers vanuit de business indien nodig. De change wordt ingeschreven in een release (zie release management). Release proces zorgt voor aanlevering van change in productie. Dit kan gaan om een normale release via de



5.5

Bug binnen garantieperiode?

5.6

Afsluiten RFC

datum 05/06/2013

bladnummer 32

release kalender of via een urgent release. Indien er een bug wordt vastgesteld binnen de garantieperiode van 30 dagen, dient de release manager een oplossing aan te leveren. Hiervoor wordt terug het bouwproces gestart zonder dat er een nieuwe RFC dient te worden aangemaakt of goedkeuringen dienen te worden aangevraagd. Na 3 weken en zonder melding van problemen met de opgeleverde change zal de change manager de RFC afsluiten. Hiermee vervalt ook de garantie. Statusaanpassing in Service Desk: Afgesloten – Geimplementeerd



datum 05/06/2013

bladnummer 33

2.3. Release management 2.3.1. Proces “UAT release aaanvraag en planning” Doel 

Uniforme en unieke manier om op een release kalender in te schrijven



Opmaken van de planning van de ingeschreven ICT componenten.



Urgent release aanvraag afhandeling

Input 

Ingevulde (correct en complete) release sjabloon door change manager (voor een wijziging) of projectmanager ICT (voor een project)

Triggers 

Release aanvraag van projectmanager ICT en/of change manager

Activiteiten 

Indienen aanvraag tot inschrijving op releasekalender



UAT release aanvragen verifiëren op volledigheid en inhoud



Opmaken van release planning UAT volgens sjabloon in bijlage



Kort overleg wat de release juist inhoudt, risico‟s, status, gewenste data copies, nodige hardware en applicaties om release onderdeel te kunnen testen. Bespreking van de logistieke acties waarbij ICT/BICC en/of business acties verwacht worden tijdens de release, regeling van testing, toegang tot lokalen, …



In geval van urgent release, verkrijgen van de nodige goedkeuringen

Output 

Release planning voor UAT



Inschatting van de downtimes voor UAT omgeving



Allocatie van resources voor installatie in UAT



datum 05/06/2013

bladnummer 34

Procesflow


Titel Urgent release goedkeuring nodig?

1.2

Goedkeuring vragen aan directeur functioneel domein

1.3

Aanmaak release aanvraag Urgent release?

1.4 1.5

Urgent release goedkeuring nodig?

1.6

Goedkeuringen OK?

Beschrijving Indien een urgent release gewenst is en hiervoor nog geen goedkeuring werd verkregen, moet die aangevraagd worden. N.B.: een goedkeuring voor een urgent change geldt automatisch ook voor een urgent release. Er is een goedkeuring nodig van de directeur van het functioneel domein indien een release gewenst is buiten de releasekalender. Voor projecten is het de projectmanager ICT die de goedkeuring opvraagt; in geval van een change zal de business analist de goedkeuring van de directeur van het functioneel domein vragen (zie change management proces). De release aanvrager dient een release aanvraag in volgens sjabloon release aanvraag. Bij een niet urgente release aanvraag kan onmiddellijk worden overgegaan naar “Evalueren aanvraag”. Wanneer reeds een goedkeuring werd verkregen voor een urgent change kan onmiddellijk worden overgegaan naar “Bepaal releasemoment”. De goedkeuring van de directeur van het functioneel domein moet bijgevoegd worden bij de release aan-



bladnummer 35

vraag. Nu moet ook nog het afdelingshoofd ICT zijn goedkeuring doorgeven aan de release manager. Indien de goedkeuring niet wordt verkregen, wordt de aanvraag verwezen naar de eerstvolgende release periode volgens de release kalender. Indien het afdelingshoofd ICT de urgent release goedkeurt, bekijkt de release manager wanneer de release kan worden uitgevoerd.

1. 7

Bepaal ment

1.8

Evalueren aanvraag

Aanvraag wordt geëvalueerd voor verdere verwerking (correct en volledig).

1.9

Accepteer aanvraag?

Release manager accepteert de aanvraag. Een planning wordt opgemaakt enkel voor de tijdige aanvragen (zie release kalender). Indien onvoldoende informatie beschikbaar is, wordt deze bij de aanvrager opgevraagd.

1.10

Verifieer container beschikbaarheid voor UAT Opleveren release files in container voor UAT Aanvaarden release info (check op volledigheid)? Aanvaarden release info (check op inhoud)?

ICT Bouwer verifieert of men alle bestanden van de container kan plaatsen op de aangeduide plaats.

1.14

Maak release planning voor UAT

De release manager zet voor alle aanvragen de verschillende installatiestappen in een centrale planning met een bepaald volgnummer (zie bijlage). In samenspraak met data center manager wordt de planning zo optimaal mogelijk opgemaakt. Voor elke stap wordt aangegeven welke persoon welke installatie moet uitvoeren op welk platform. Afhankelijkheden van andere installatiestappen worden hierin opgenomen. Voor elke stap wordt een schatting gemaakt m.b.t. de tijd om de installatie en controle te voltooien. Op deze manier kunnen de downtimes van de verschillende services en platformen berekend worden.

1.15

Nakijken afhankelijkheden

Afhankelijkheden tussen verschillende release activiteiten en afhankelijkheden tussen installatiestappen worden uitgeklaard.

1.16

Conflict in planning voor deployment?

Release manager en data center manager kijken na of er conflicten zouden kunnen optreden m.b.t. de gemaakte planning (dry run theoretisch). Indien er conflicten zijn moet de planning worden aangepast.

1.17

Bepalen middelen voor release

De release manager bepaalt de middelen voor de release 10 dagen voor UAT deployment samen met de verschillende aanvragers en uitvoerders (infrastructuur uitvoerders, applicatie bouwers, projectmanager ICT, change manager). In geval van urgent release wordt dit met de hoogste prioriteit georganiseerd.

1.11

1.12

1.13

releasemo-

datum 05/06/2013

ICT bouwer levert de containers met nodige bestanden. Release manager verifieert of de geleverde containers alle nodige documenten bevatten. Data center manager checkt de container op inhoud: volledigheid en correctheid van alle software, documenten (verstaanbaar en haalbaar?).

Voor de resources die belast zijn met uitvoerende taken wordt nagegaan of deze personen dienen aanwezig te zijn (on-site, remote). De nodige toegangen tot de lokalen en regelingen met personeelsadministratie



datum 05/06/2013

bladnummer 36

worden geregeld (overwerk, weekendwerk, …). 1.18

Informeer business analisten en local supports over inhoud UAT release

De release manager bezorgt de business analisten en de local supports een lijst van alle changes en projecten die zijn ingepland voor de UAT release.

2.3.2. Proces “UAT release installatie, testing en bug fixing” Doel 

Installatie van de beschikbare containers in de acceptatie-testomgeving (UAT) waarbij business de nodige testen zal uitvoeren en waarbij infrastructuur en applicaties de nodige bug fixing zullen uitvoeren.

Input 

Aangeleverde containers van changes en projecten



Aanlevering van hardware componenten



UAT release planning

Triggers 

Release kalender UAT

Activiteiten 

Kopiëren van dataset van productie naar UAT



Installatie van containers in UAT omgeving



Uitvoeren testen door ICT klant in UAT volgens master testplan met assistentie van applicatie testers (zie bijlage).



Bug fixing door ICT bouwer

Output 

Per release aanvraag een lijst van succesvolle testing van de ICT klant



Per release aanvraag een lijst van bugs gerapporteerd door de ICT klant



Per release een planning van de verschillende bug fixes met aanduiding wanneer deze beschikbaar zullen zijn in welke IR.



datum 05/06/2013

bladnummer 37

Procesflow


Titel Kopieer test data via aangeleverde scripts

2.2

Update status planning + start installatie

2.3

Voer acties uit volgens planning op UAT Doorgeven timings & succes per container

2.4

2.5

2.6

Update status planning + uitvoeren next step volgens planning Informeer belanghebbenden dat project of RFC in UAT staat

2.7

Einde clus?

planningscy-

2.8

Testing UAT door business

Beschrijving Infrastructuur voert het script uit om de aangevraagde data van productie naar de UAT omgeving te zetten. Scripts maken deel uit van de aangeleverde container. Release manager krijgt status van het kopiëren van de data en geeft officiële GO voor installatie van de acceptatie testomgeving. Infrastructuur voert de volgende stap van de planning uit volgens instructies van de data center manager, die hiervoor overleg pleegt met de release manager. De medewerker infrastructuur geeft de status van de installatie en de doorlooptijd van de installatiestap door aan de data center manager die op zijn beurt synchroniseert met de release manager. Release manager verifieert of er afhankelijkheden zijn voor een volgende stap in de uitvoering en geeft aan welke volgende stap dient uitgevoerd te worden. De release manager brengt voor elke installatiestap de belanghebbenden (door de release aanvrager te vermelden op de release aanvraag) op de hoogte dat hun project of change in UAT werd geïnstalleerd. Tot de belanghebbenden voor een change behoren ook de change aanvragers en de betrokken eerste lijnmedewerkers. De release manager gaat na of er nog een volgende stap is in de planning, indien ja dan wordt de volgende stap uitgevoerd, indien nee is dit het einde van de installatie en kunnen de acceptatietesten plaatsvinden. ICT klanten worden gevraagd de acceptatietesten te starten. De projectmanager ICT (voor de projecten in



datum 05/06/2013

bladnummer 38

de release) en change manager (voor de wijzigingen in de release) zijn verantwoordelijk voor de beschikbaarheid en acties van de ICT klanten, eventueel begeleid door testers. De aanpak van de acceptatietesten is bepaald in het project of de wijziging. De aanpak is besproken met de ICT klanten m.b.t. welke testen op welke manier moeten uitgevoerd worden door wie van de business. 2.9

Aanmaken issue lijst

De business zal de verschillende testen uitvoeren en aangeven welke issues er zich voordoen binnen de projecten/changes.

2.10

Invullen van issues in tracking tool

De ICT klant verwerkt alle testrapporten in de bug tracking tool (Jira).

2.11

Blokkerende bugs voor project of RFC?

Indien er geen blokkerende bugs meer zijn voor project of RFC is de test succesvol en kan men overgaan naar productie, zo niet dient men de bugs op te lossen. De release aanvrager moet hier zijn fiat geven.

2.12

Beslissing over aanpak issue list voor project

De release aanvrager zal de verschillende bug issues doornemen met business. Scope uitbreidingen kunnen niet opgenomen worden; enkel bugs op bestaande scope.

2.13

Opmaken bug fixing

planning

Er wordt een prioriteitenlijst gemaakt m.b.t. bug fixing: wat is de prioriteit van elke bug, wanneer zal welke resource bug fixing uitvoeren met referentie naar bug tracking tool.

2.14

Verwerken bugs volgens planning

Vanuit de bug tracking tool (Jira) worden de ICT bouwers geïnformeerd en worden de bug fixes uitgevoerd. De nodige wijzigingen aan infrastructuur en/of software worden door de ICT bouwers uitgevoerd.

2.3.3. Proces “Intermediate release aanvraag en planning” Doel 

Voor de niet succesvolle testen van de business zal een lijst van bugfixes worden aangeboden door de bouwers aan de release aanvrager. De release aanvrager zal in overleg met de release manager een planning voor de oplevering van de bug fixes op maken. Voor de IR waarin bepaalde bug fixes beschikbaar zijn, zal een intermediate release worden aangevraagd.

Input 

Ingevulde (correct en complete) release sjabloon door release aanvrager.

Triggers 

Release aanvraag van release aanvrager.



Release kalender

Activiteiten 

Intermediate release aanvragen en verifiëren op volledigheid en inhoud



Opmaken van release planning IR volgens sjabloon in bijlage



Kort overleg wat de release juist inhoud, risico‟s, status, gewenste data copies, nodige hardware en applicaties om release onderdeel te kunnen testen. Bespre-



datum 05/06/2013

bladnummer 39

king van de logistieke acties waarbij ICT en/of business acties verwacht worden tijdens de release, regeling van testing, toegang tot lokalen, … Output 

Release planning voor IR



Inschatting van de downtimes voor IR omgeving



Allocatie van resources voor installatie in IR

Procesflow

Procesbeschrijving # 3.1 3.2

Titel Aanmaak release aanvraag Evalueren aanvraag

3.3

Accepteer aanvraag?

3.4

Verifieer container beschikbaarheid voor IR Opleveren release files in container voor IR Aanvaarden release info (check op volle-

3.5

3.6

Beschrijving De projectmanager ICT of de change manager dient release aanvraag in volgens sjabloon release aanvraag. Aanvraag wordt geëvalueerd voor verdere verwerking (correct en volledig). Release manager accepteert de aanvraag. Een planning wordt opgemaakt enkel voor de tijdige aanvragen (zie release kalender). Indien onvoldoende informatie beschikbaar is, wordt deze bij de aanvrager opgevraagd. ICT Bouwer verifieert of de containers kunnen aangeleverd worden. ICT bouwer verifieert of men alle bestanden van de container kan plaatsen op de aangeduide plaats. Release manager verifieert of de geleverde containers alle nodige documenten bevatten.



digheid)? Aanvaarden release info (check op inhoud)?

3.7

datum 05/06/2013

bladnummer 40

Data center manager checkt de container op inhoud: volledigheid en correctheid van alle software, documenten (verstaanbaar en haalbaar?). Indien de container wordt verworpen dient de data center manager zijn beslissing grondig te beargumenteren en te documenteren.

3.8

Maak release planning voor IR

De release manager zet voor alle aanvragen de verschillende installatiestappen in een centrale planning met een bepaald volgnummer (zie bijlage). In samenspraak met data center manager wordt de planning zo optimaal mogelijk opgemaakt. Voor elke stap wordt aangegeven welke persoon welke installatie moet uitvoeren op welk platform. Afhankelijkheden van andere installatiestappen worden hierin opgenomen. Voor elke stap wordt een schatting gemaakt m.b.t. de tijd om de installatie en controle te voltooien. Op deze manier kunnen de downtimes van de verschillende services berekend worden.

3.9



3.10



3.11


De release manager bepaalt de middelen voor de release 1 dag voor de IR deployment samen met de verschillende aanvragers en uitvoerders (infrastructuur uitvoerders, applicatie bouwers, projectmanager ICT, change manager). In geval van urgent release wordt dit ASAP georganiseerd Voor de resources die belast zijn met uitvoerende taken wordt nagegaan of deze personen dienen aanwezig te zijn (on-site, remote). De nodige toegangen tot de lokalen en regelingen met personeelsadministratie worden geregeld (overwerk, weekendwerk, …).

2.3.4. Proces “Intermediate release installatie, testing en bug fixing” Doel 

Intermediate release installatie van de beschikbare containers waarbij business de nodige testen zal uitvoeren en waarbij infrastructuur en applicaties de nodige bug fixing zullen uitvoeren.

Input 







Intermediate release planning

Triggers 

Release kalender IR



Planning voor IR klaar



datum 05/06/2013

bladnummer 41

Activiteiten 

Kopiëren van dataset van productie naar UAT



Installatie van containers in UAT omgeving



Uitvoeren testen door ICT klant in UAT volgens master testplan (zie bijlage).



Bug fixing door infrastructuur en applicaties

Output 

Per release aanvraag een lijst van succesvolle testing van de ICT klant



Per release aanvraag een lijst van bugs gerapporteerd door de ICT klant



Per release een planning van de verschillende bug fixes met aanduiding wanneer deze beschikbaar zullen zijn in UAT (indien er nog IR volgens de release kalender volgen) of PROD.

Procesflow


Titel Kopieer test data via aangeleverde scripts

4.2

Update status planning + start installatie

4.3

Voer acties uit volgens planning op IR

4.4

Doorgeven timings & succes per container

Beschrijving De medewerker infrastructuur voert het script uit om de aangevraagde data van productie naar de UAT omgeving te zetten. Scripts maken deel uit van de aangeleverde container. Release manager krijgt status van het kopiëren van de data en geeft officiële GO voor installatie van de acceptatie testomgeving. Infrastructuur voert de volgende stap van de planning uit volgens instructies van de data center manager, die hiervoor overleg pleegt met de release manager. De medewerker infrastructuur geeft de status van de installatie en de doorlooptijd van de installatiestap door



4.5

4.6

Update status planning + uitvoeren next step volgens planning Informeer belanghebbenden dat project of RFC in IR staat

planningscy-

datum 05/06/2013

bladnummer 42

aan de data center manager die op zijn beurt synchroniseert met de release manager. Release manager verifieert of er afhankelijkheden zijn voor een volgende stap in de uitvoering en geeft aan welke volgende stap dient uitgevoerd te worden. De release manager brengt voor elke installatiestap de belanghebbenden (door de release aanvrager te vermelden op de release aanvraag) op de hoogte dat hun project of change in IR werd geïnstalleerd. Tot de belanghebbenden voor een change behoren ook de change aanvragers en de betrokken eerste lijnmedewerkers. De release manager gaat na of er nog een volgende stap is in de planning, indien ja dan wordt de volgende stap uitgevoerd, indien nee is dit het einde van de installatie en kunnen de acceptatietesten plaatsvinden.

4.7

Einde clus?

4.8

Testing IR door business

ICT klanten worden gevraagd de acceptatietesten te starten. De projectmanager ICT (voor de projecten in de release) en change manager (voor de wijzigingen in de release) zijn verantwoordelijk voor de beschikbaarheid en acties van de ICT klanten, eventueel begeleid door testers. De aanpak van de acceptatietesten is bepaald in het project of de wijziging. De aanpak is besproken met de ICT klanten m.b.t. welke testen op welke manier moeten uitgevoerd worden door wie van de business.

4.9

Aanmaken issue lijst

De ICT-klant zal de verschillende testen uitvoeren en aangeven welke issues er zich voordoen binnen de projecten/changes.

4.10

Invullen van issues in tracking tool

De ICT klant verwerkt alle testrapporten in de bug tracking tool (Jira).

4.11

Blokkerende bugs voor project of RFC?

Indien er geen blokkerende bugs meer zijn voor project of RFC is de test succesvol en kan men overgaan naar productie, zo niet dient men de bugs op te lossen. De release aanvrager moet hier zijn fiat geven.

4.12

Beslissing over aanpak issue list voor project

De release aanvrager zal de verschillende bug issues doornemen met de ICT-klant. Scope uitbreidingen kunnen niet opgenomen worden; enkel bugs op bestaande scope.

4.13

Opmaken bug fixing

planning

Er wordt een prioriteitenlijst gemaakt m.b.t. bug fixing: wat is de prioriteit van elke bug, wanneer zal welke resource bug fixing uitvoeren met referentie naar bug tracking tool.

4.14

Verwerken bugs volgens planning

Vanuit de bug tracking tool (Jira) worden de ICT bouwers geïnformeerd en worden de bug fixes uitgevoerd. De nodige wijzigingen aan infrastructuur en/of software worden door de ICT bouwers uitgevoerd.

2.3.5. Proces “Productie release aanvraag en planning” Doel 

Alle succesvol geteste containers worden in productie gezet via PROD release aanvraag.

Input 

Ingevulde (correct en complete) release sjabloon door de release aanvrager.



datum 05/06/2013

bladnummer 43

Triggers 

Release aanvraag van de release aanvrager.



Release kalender

Activiteiten 

PROD release aanvragen verifiëren op volledigheid en inhoud



Opmaken van release planning PROD volgens sjabloon in bijlage



Kort overleg wat de release juist inhoud, risico‟s, status, gewenste data copies, nodige hardware en applicaties om release onderdeel te kunnen testen. Bespreking van de logistieke acties waarbij ICT en/of business acties verwacht worden tijdens de release, regeling van testing, toegang tot lokalen, …

Output 

Release planning voor PROD



Inschatting van de downtimes voor PROD omgeving



Allocatie van resources voor installatie in PROD

Procesflow


Titel Aanmaak release aanvraag Evalueren aanvraag

Beschrijving De release aanvrager dient release aanvraag in volgens sjabloon release aanvraag. Aanvraag wordt geëvalueerd voor verdere verwerking (correct en volledig).



5.3

Accepteer aanvraag?

5.4

Verifieer container beschikbaarheid voor PROD Opleveren release files in container voor PROD Aanvaarden release info (check op volledigheid)? Aanvaarden release info (check op inhoud)?

5.5

5.6

5.7

datum 05/06/2013

bladnummer 44

Release manager accepteert de aanvraag. Een planning wordt opgemaakt enkel voor de tijdige aanvragen (zie release kalender). Indien onvoldoende informatie beschikbaar is, wordt deze bij de aanvrager opgevraagd. ICT bouwer verifieert of men alle bestanden van de container kan plaatsen op de aangeduide plaats. ICT bouwer levert de containers met de nodige bestanden Release manager verifieert of de geleverde containers alle nodige documenten bevatten. De data center manager checkt de container op inhoud: volledigheid en correctheid van alle software, documenten (verstaanbaar en haalbaar?).

5.8

Maak release planning voor PROD

De release manager zet voor alle aanvragen de verschillende installatiestappen in een centrale planning met een bepaald volgnummer (zie bijlage). In samenspraak met data center manager wordt de planning zo optimaal mogelijk opgemaakt. Voor elke stap wordt aangegeven welke persoon welke installatie moet uitvoeren op welk platform. Afhankelijkheden van andere installatiestappen worden hierin opgenomen. Voor elke stap wordt een schatting gemaakt m.b.t. de tijd om de installatie en controle te voltooien. Op deze manier kunnen de downtimes van de verschillende services berekend worden.

5.9



5.10



5.11


De release manager bepaalt de middelen voor de release 2 dagen voor de PROD deployment samen met de verschillende aanvragers en uitvoerders (infrastructuur uitvoerders, applicatie bouwers, projectmanager ICT, change manager). In geval van urgent release wordt dit ASAP georganiseerd. Voor de resources die belast zijn met uitvoerende taken wordt nagegaan of deze personen dienen aanwezig te zijn (on-site, remote). De nodige toegangen tot de lokalen en regelingen met personeelsadministratie worden geregeld (overwerk, weekendwerk, …).

5.12

Opstellen en versturen release nieuwsbrief

De release manager ziet erop toe dat de release nieuwsbrief wordt samengesteld en verstuurd naar alle business analisten, afdelingshoofden, diensthoofden, expertgebruikers, BICC en local supports.

2.3.6. Proces “Productie release installatie” Doel 

PROD release installatie van de beschikbare containers.



datum 05/06/2013

bladnummer 45

Input 







PROD release planning

Triggers 

Release kalender PROD

Activiteiten 

Installatie van containers in PROD omgeving



Eventueel testing door business na productie-installatie



PROD resultaat van geïnstalleerde componenten op de verschillende platformen in de productieomgeving.

Output

Procesflow


6.3

Titel Update status planning + start installatie Voer acties uit volgens planning op PROD Business testing in PROD nodig?

6.4

Informeer ICT klant

6.5

PROD testing door business Doorgeven timings & succes per container

6.6

Beschrijving Release manager verifieert of alle nodige voorbereidingen zijn getroffen en zorgt voor finale planning. Infrastructuur voert de volgende stap van de planning uit volgens instructies van release manager. Release manager of projectmanager ICT zijn overeengekomen met de business of een test in productie nodig is. ICT klant wordt ingelicht dat de testen kunnen doorgaan. Business voert de nodige testen op productiesysteem door. De medewerker infrastructuur geeft de status van de installatie en de doorlooptijd van de installatiestap door aan de release manager.



datum 05/06/2013

bladnummer 46

6.7

Update status planning + uitvoeren next step volgens planning

Release manager verifieert of er afhankelijkheden zijn voor een volgende stap in de uitvoering en geeft aan welke volgende stap dient uitgevoerd te worden.

6.8

Informeer belanghebbenden dat project of RFC in PROD staat

De release manager brengt voor elke installatiestap de belanghebbenden (door de release aanvrager te vermelden op de release aanvraag) op de hoogte dat hun project of change in PROD werd geïnstalleerd. Tot de belanghebbenden voor een change behoren ook de change aanvragers en de betrokken eerste lijnmedewerkers.

6.9

Einde clus?

De release manager gaat na of er nog een volgende stap is in de planning, indien ja dan wordt de volgende stap uitgevoerd, indien nee is dit het einde van de installatie.

6.10

Update rapport

planningscy-

Release manager maakt een rapport op van alle installaties en testing.



datum 05/06/2013

bladnummer 47

2.4. Test management 2.4.1. Proces “Maken Master Testplan” Doel 

Uitwerken van een volledig testplan voor het project. De verschillende testfases worden beschreven met hun acceptatiecriteria en nood voor resources.



Master testplan toevoegen aan de PID.



Business analyse documentatie



Voorlopig high level design



Voorlopige projectplanning



Raamwerk acceptatiecriteria



Standaard escalatieprocedures

Input

Triggers 

Aanmaak PID

Activiteiten 

Aanmaken van een mastertestplan waarin: o

testaanpak (welke testen in welke fase, hoe deze testen doen, welke testdata nodig,…)

o

verantwoordelijkheden,

o

acceptatiecriteria,

o

escalatieprocedures,

o

resourcenoden

worden vastgelegd 

Valideren van het master testplan



Bezorgen mastertestplan aan PM ICT/business PM voor integratie in PID



Gevalideerd Master Test Plan

Output



datum 05/06/2013

bladnummer 48

Procesflow


Titel Vraag tester ICT om master testplan te maken en geef informatie door

1.2

Bepalen testaanpak

1.3

Bepalen verantwoordelijkheden en escalatieprocedure

1.4

Bepalen acceptatiecriteria

1.5

Bepalen testplanning en workload

1.6

Consolideren

Master

Beschrijving De Business PM en PM ICT organiseren een overlegmoment waarin zij de tester ICT vragen om een master testplan te maken. De nodige informatie (=input processtap)moet hier worden overgedragen aan de tester ICT zodat hij zijn werk kan uitvoeren. Er moet gezegd worden wat er van het testproces en de tester ICT verwacht wordt en wat de belangrijkste vereisten zijn. Afhankelijk van het type oplossing wordt de testaanpak bepaald: eigen ontwikkeling, maatwerk of pakket. Voor elke testfase moet er een verantwoordelijke zijn die de coördinatie op zich neemt. Dit zal meestal een tester ICT zijn. Voor elke testfase is het heel belangrijk om te bepalen wie welke verantwoordelijkheid zal dragen. Wie lijst de bugs op? Wie wijst de op te lossen bugs toe? Wat zijn de bug categorieën? Bij welk type bug moet wie verwittigd worden? … Een standaard escalatieprocedure is ter beschikking en dient als basis voor elk project. Als er geen andere afspraken worden gemaakt, geldt de standaard escalatieprocedure. Het is heel belangrijk om op voorhand te bepalen wat de acceptatiecriteria zullen zijn om een volgende testfase te starten. Elke testfase zal aan deze criteria moeten voldoen alvorens de testfase te kunnen afsluiten. Deze criteria moeten zeer goed afgesproken worden tussen de verschillende betrokkenen om zoveel mogelijk discussie te vermijden achteraf. Deze criteria kunnen meer of minder uitgebreid zijn in functie van de grootte van het project of de change. De acceptatiecriteria voor elke testfase moeten in lijn zijn met de acceptatiecriteria van het project. De nodige tijd per testfase wordt ingeschat. Deze input zullen de business PM en PM ICT dan gebruiken om hun volledig projectplan aan te passen en in te vullen. Voor elke testfase zijn er resources nodig en de nodige workload moet dus ingeschat worden en meegenomen in de algemene resourceplanning van het project. De tester consolideert het master testplan.



Testplan Master testplan ok?

1.7

1.8

Toevoegen master testplan aan PID

datum 05/06/2013

bladnummer 49

De business PM en PM ICT valideren het master testplan. Bij non-validatie moet de tester ICT zijn master testplan aanpassen in functie van de opmerkingen van de PM‟s. Het master testplan wordt toegevoegd aan de PID door de business PM.

2.4.2. Proces “Voorbereiden UAT” Doel 

Begrijpen van de business vereisten en eventueel opmaken van draft testscenario‟s om de latere opmaak van de UAT scenario‟s te vergemakkelijken



De organisatie van de UAT fase voorbereiden

Input 

Business analyse



Projectplanning

Triggers 

Start uitvoeringsfase project

Activiteiten 

Overdragen van de business analyse



Begrijpen van de business vereisten zodanig dat kan vastgelegd worden WAT zal getest worden in de UAT fase



Maken van draft testscenario‟s: dit zijn eerste testscenario‟s waarop verder in het project kan worden gewerkt om te komen tot definitieve testscenario‟s



Voorbereiden van de organisatie van de UAT o

Wie gaat testen?

o

Wanneer testen?

o

Wie maakt de testscenario‟s?

o

Wie zorgt voor de uitnodiging van de UAT-testen?

o

Wie coördineert de UAT-testen?

Output 

Afbakening UAT scope



Draft UAT scenario‟s



Planning en afspraken UAT fase



datum 05/06/2013

bladnummer 50

Procesflow


Titel Organiseer overdrachtsmeeting business analyse

2.2

Voorbereiden en houden overdracht business analyse (= Stap 1.5 Functionele analyse)

2.3

Analyseer business vereisten en leg UAT scope vast Maken draft testscenario‟s

2.4

2.5

Bepaal UAT

2.6

Informeer nen

organisatie

betrokke-

Beschrijving De PM ICT en business PM moeten ervoor zorgen dat de business analyse wordt overgedragen aan de tester ICT en de business testers zodat ze kunnen kennismaken met het project. De business analist is verantwoordelijk voor de organisatie van de overdracht van de business analyse. Hieronder valt het in detail uitleggen van de business vereisten aan de tester ICT en de business testers. Deze stap valt samen met de overdracht van de business analist aan de functioneel analist (zie proces Functionele analyse). De business testers en tester(s) ICT verdiepen zich in de business vereisten zodat ze een goede basis hebben om de UAT scenario‟s uit te werken. Indien mogelijk worden hier al draft testscenario‟s gemaakt. De business testers kunnen hier rekenen op support van de tester ICT. De business PM is verantwoordelijk voor het bepalen van de organisatie van de UAT testen samen met de tester ICT, de business testers en de PM‟s (Taakverdeling, algemene planning, communicatie,…). De business PM kan vragen aan de tester ICT om deze activiteit te coördineren. Hier start een trigger naar het proces “Project & BC Management” om de projectplanning te updaten. De betrokkenen krijgen de testscope voor UAT, de draft testscenario‟s en de UAT planning en afspraken.



datum 05/06/2013

bladnummer 51

2.4.3. Proces “Uitschrijven testscenario’s” Doel 

Specificeren van de testscenario‟s (functionele en niet-functionele) en uitgangssituaties die zullen dienen om de integratie en systeemtesten uit te voeren

Input 

Functioneel ontwerp



High level design

Triggers 

Gevalideerd functioneel ontwerp

Activiteiten 

Overdragen van het functioneel ontwerp en het high level design



Maken van testscenario‟s



Bepalen nodige testdata

Output 

Gevalideerde testscenario‟s



Vereisten voor testdata.

Procesflow


3.2

Titel Organiseren overdracht functioneel ontwerp en high level design Houden overdracht

Beschrijving De PM ICT zorgt ervoor dat het functioneel ontwerp en het high level design worden overgedragen aan de tester ICT. De functioneel analist is verantwoordelijk voor de



functioneel ontwerp (= Stap 1.2 Design) 3.3

Houden overdracht high level design (= Stap 1.3 Design)

3.4

Overdrachten vaard?

3.5

Maak nodige functionele en nietfunctionele testscenario‟s Validatie inhoud (en vorm)

3.6

aan-

datum 05/06/2013

bladnummer 52

overdracht van het functioneel ontwerp aan de tester ICT. Deze moet na de overdracht in staat zijn om de functionele testscenario‟s op te maken. De solution architect is verantwoordelijk voor de overdracht van het high level design aan de tester ICT. Deze moet na overdracht in staat zijn om de nietfunctionele testscenario‟s op te maken. De tester ICT moet beide overdrachten evalueren. Eens aanvaard, maakt hij op basis van de functionele analyse en het high level design de functionele en nietfunctionele testscenario‟s op. De tester ICT maakt alle nodige functionele en nietfunctionele testscenario‟s op die later gebruikt zullen worden voor de integratie- en systeemtesten. De functioneel analist en de solution architect valideren de inhoud van respectievelijk de functionele en niet-functionele testscenario‟s. Deze testscenario‟s moeten het functioneel ontwerp en het high level design volgen. De CCL testen beoordeelt de testscenario‟s naar vorm. Zijn de juiste sjablonen gebruikt en de richtlijnen gevolgd?

3.7

Validatie vorm (en inhoud)

3.8

Validatie ok?

Wanneer de testscenario‟s niet gevalideerd zijn, werkt de tester ICT deze bij. Wanneer de testscenario‟s wel gevalideerd zijn, wordt de nodige testdata bepaald en beschreven.

3.9

Bepaal en beschrijf nodige testdata

De tester ICT bepaalt welke testdata hij nodig zal hebben en zet dit ook op papier.

3.10

Informeer nen

De tester ICT informeert de betrokkenen(zie RASCI) dat zijn testscenario‟s zijn afgewerkt. Hij stelt zijn testscenario‟s ook ter beschikking van deze personen. (PM ICT en CCL Testen)

betrokke-

2.4.4. Proces “Uitvoeren integratietesten” Doel 

De testscenario‟s (functionele en niet-functionele) toetsen op één of meerdere ontwikkelde testobjecten

Input 

Gevalideerde functionele en niet-functionele testscenario‟s



Testomgeving voor integratietesten



Unittestrapporten (vanuit proces „Ontwikkeling‟)

Triggers 

Unittesten op testbaar geheel zijn positief afgerond

Activiteiten 

Testomgeving klaarmaken



Updaten testscenario‟s



Uitvoeren van testscenario‟s



Lijsten, wegen en toewijzen bugs en issues





datum 05/06/2013

bladnummer 53

Acceptatievoorwaarden nakijken en finaal integratietestrapport maken en valideren

Output 

Uitgevoerde testscenario‟s



Integratietestrapport o

Integratietest issueslijsten

o

Testresultaten en scope

Procesflow


Titel Testbaar geheel klaar voor integratietesten?

4.2

Maak klaar

4.3

Testomgeving ok?

testomgeving

Beschrijving De PM ICT overlegt met de analist-programmeur en de tester ICT of de testobjecten klaar zijn voor integratietesten. De unit-testrapporten - waarin de analistprogrammeur zich engageert dat de geleverde testobjecten al de nodige en mogelijke unittesten hebben overleefd - moeten beschikbaar zijn. De analist-programmeur en/of systeembeheerder maakt de testomgeving klaar. Bijkomend test hij/zij of de testomgeving correct functioneert. Afhangende van het type project zal het de taak van de analistprogrammeur en/of de systeembeheerder om de testomgeving klaar te maken. De tester ICT valideert de testomgeving. Indien het



4.4

4.5 4.6

Bekijk testscenario‟s en maak testdata klaar Voer integratietesten uit Lijst eventuele bugs en issues op

datum 05/06/2013

bladnummer 54

niet ok is, moet de analist-programmeur – op basis van de opmerkingen – de testomgeving bijwerken. De tester ICT bekijkt de eerder gemaakte testscenario‟s, werkt ze indien nodig bij en zorgt dat de testdata klaargemaakt wordt. De testscenario‟s worden uitgevoerd. Alle bugs en issues die gevonden worden tijdens het testen worden gelijst en doorgegeven aan de PM ICT voor verdere afhandeling. Bugs en issues worden gelijst in de Test Management Tool. Voor elke bug wordt de impact en de dringendheid bepaald. Op basis van die 2 criteria wordt de prioriteit bepaald. De issues (geen technische fout, enkel functioneel probleem) worden met de business PM besproken. De impact op de scope, de planning en het budget worden bepaald via het project & business case management proces. Voor het bepalen van de impact en de dringendheid van bugs en issues informeert de PM ICT zich bij het ICT projectteam. In veel gevallen zal de functioneel analist hier een belangrijke rol spelen. Best worden tijdens de testfase regelmatige overlegmomenten gepland tussen minstens de PM ICT, de functioneel analist en de tester ICT om dit te bespreken.

4.7

Bepaal impact en dringendheid bug of issue in overleg met betrokkenen

4.8

Wijs oplossing bugs & issues toe

De PM ICT wijst de bugs & issues toe aan de juiste betrokkenen binnen het projectteam ICT. Hij kan deze taak indien nodig delegeren aan de tester ICT.

4.9

Communiceer bug & issue lijst naar betrokkenen

Nadat de bugs/issues zijn toegewezen, worden de betrokkenen in het ICT-projectteam hierover geïnformeerd. Het is ook belangrijk om andere betrokkenen in het project te informeren ivm de stand van zaken rond testen.

4.10

Los bug of issue op

De leden van het projectteam zorgen voor een oplossing voor de bug of issue die hen wordt toegewezen. Eens de bug of issue opgelost, worden de integratietesten opnieuw uitgevoerd.

4.11

Acceptatiecriteria voldaan?

In deze stap worden de acceptatiecriteria nagekeken. Indien ze voldaan zijn, kan de tester ICT overgaan tot het maken van het finale integratietestrapport. Indien niet, moeten de integratietesten verder worden uitgevoerd.

4.12

Maak finaal integratietestrapport

Eens de acceptatiecriteria voldaan zijn, maakt de tester ICT het finale integratietestrapport dat ter validatie wordt doorgestuurd naar de PM ICT en de CCL testen.

4.13

Inhoud (en vorm) ok?

De PM ICT controleert de inhoud van de integratietesten. Is alles wel goed getest? Zijn de testen correct uitgevoerd? Voldoen de testen aan de acceptatiecriteria?

4.14

Vorm (en inhoud) ok?

De CCL Testen kijkt het integratietestrapport na naar vorm en indien nodig naar inhoud.

4.15

Informeer nen

De tester ICT informeert de nodige betrokkenen (zie RASCI) dat de integratietesten voor het geteste deel van de applicatie afgerond zijn.

betrokke-



datum 05/06/2013

bladnummer 55

2.4.5. Proces “Uitvoeren systeemtesten” Doel 

Werkbaar geheel van een applicatie testen na positieve afhandeling van de integratietesten

Input 

Functionele en niet-functionele testscenario‟s



Integratie testrapporten

Triggers 

Acceptatiecriteria integratietesten zijn voldaan

Activiteiten 

Check of testomgeving in orde is



Update testscenario‟s en testdata



Uitvoeren systeemtesten



Lijsten, wegen en toewijzen bugs & issues



Acceptatiecriteria nakijken en systeemtestrapport opmaken



PIT (post-implementatie test) scenario‟s opmaken en toevoegen aan deployment document

Output 

Gevalideerd systeemtestrapport



datum 05/06/2013

bladnummer 56

Procesflow


Titel Systeemtesten dig?

5.2

Testomgeving in orde?

5.3

Pas testomgeving aan Bekijk testscenario‟s en maak testdata klaar Voer systeemtesten uit Lijst eventuele bugs en issues op

5.4

5.5 5.6

5.7

no-

Bepaal impact en prioriteit bug of issue in overleg met betrokkenen

Beschrijving Er wordt nagekeken of systeemtesten nodig zijn. Voor kleine applicaties kunnen de integratietesten overeenkomen met systeemtesten omdat er bijvoorbeeld maar één component is. De tester ICT kijkt na of de testomgeving in orde is. Indien deze niet in orde is, vraagt hij de analistprogrammeur om deze bij te werken. De analist –programmeur past de testomgeving aan in functie van de opmerkingen van de tester ICT. De tester ICT kijkt de functionele en niet-functionele testscenario‟s na, past ze indien nodig aan en maakt ook de nodige testdata klaar. De systeemtesten worden volgens de testscenario‟s uitgevoerd door de tester ICT. Bugs en issues die tijdens het testen worden gevonden, worden gelijst zodat ze verder kunnen worden gewogen, toegewezen en opgelost. Voor elke bug wordt de impact en de dringendheid bepaald. Op basis van die 2 criteria wordt de prioriteit bepaald. De issues (geen technische fout, enkel functioneel probleem) worden met de business PM besproken. De impact op de scope, de planning en het budget worden bepaald via het project & business case management



datum 05/06/2013

bladnummer 57

proces. Voor het bepalen van de impact en de dringendheid van bugs en issues informeert de PM ICT zich bij het ICT projectteam en indien nodig de stuurgroep. In veel gevallen zal de functioneel analist hier een belangrijke rol spelen. Best worden tijdens de testfase regelmatige overlegmomenten gepland tussen minstens de PM ICT, de functioneel analist en de tester ICT om dit te bespreken. 5.8

Wijs oplossing bugs & issues toe

De PM ICT is verantwoordelijk om de bugs en issues toe te wijzen aan de betrokkenen medewerkers van het projectteam ICT. Hij kan deze taak indien nodig delegeren aan de tester ICT.

5.9

Communiceer bugs en issue lijst naar betrokkenen

Nadat de bugs/issues zijn toegewezen, worden de betrokkenen in het ICT-projectteam hierover geïnformeerd. Het is ook belangrijk om andere betrokkenen in het project te informeren ivm de stand van zaken rond testen. Voor de business is het belangrijk om ook over systeemtesten geïnformeerd te worden. Dit geeft namelijk informatie over de voortuitgang van het project.

5.10

Los bug of issue op

De leden van het projectteam die een bug of issue toegewezen krijgen, lossen deze op en sturen deze terug naar de testers ICT, zodat de testen kunnen worden herhaald.

5.11

Acceptatiecriteria voldaan

Alvorens de systeemtesten af te ronden, kijkt de tester ICT na of de acceptatiecriteria zijn voldaan. Indien ze voldaan zijn, gaat men over tot het maken van het finaal systeemtestrapport.

5.12

Maak finaal systeemtestrapport

Eens de acceptatiecriteria voldaan, maakt de tester ICT een finaal systeemtestrapport op dat als formele afsluiting zal dienen voor deze processtap.

5.13

Inhoud (en vorm ok)?

De PM ICT kijkt het systeemtestrapport naar inhoud na. Hij moet zich verzekeren dat de nodige testen uitgevoerd zijn en positief zijn afgerond. Het voldoen van de acceptatiecriteria moet hij ook nakijken.

5.14

Vorm (en inhoud) ok?

De CCL testen kijkt het systeemtestrapport na wat de vorm betreft. Is het juiste sjabloon gebruikt en is deze op de juiste manier ingevuld? Indien hij het nodig acht, kan hij ook de inhoud nakijken.

5.15

Informeer nen

betrokke-

Eens het systeemtestrapport gevalideerd, informeert de tester ICT de verschillende betrokkenen (zie RASCI) dat de systeemtesten positief zijn afgerond.

5.16

Bepaal mentatie rio(PIT)

postimpletestscena-

Infrastructuur is verantwoordelijk voor de voorbereiding van de UAT en PROD omgevingen. Om na te gaan of de productie omgeving correct is opgezet, worden één of meerdere post implementatietesten beschreven in testscenario‟s. Deze testen zullen worden uitgevoerd net nadat de oplossing in productie wordt gereleased. In deze processtap worden de testen voorbereid. Dit gebeurt in nauwe samenwerking tussen de tester ICT en de business tester. De tester ICT moet uiteindelijk de PIT scenario‟s doorgeven aan de analistprogrammeur zodat hij deze kan toevoegen aan het deployment document.



5.17

Voeg PIT instructies toe aan deployment document

datum 05/06/2013

bladnummer 58

In deze stap wordt informatie rond de organisatie van de PIT aan het deployment document toegevoegd. Deze informatie zal infrastructuur toelaten te weten wie er moet worden gecontacteerd bij de uitvoering van de PIT.

2.4.6. Proces “Uitvoeren UAT” Doel 

De business een werkbaar geheel van de ontwikkelde applicatie laten testen

Input 

Business vereisten



Draft business testscenario‟s indien van toepassing



Gevalideerde integratie en systeemtestrapporten

Triggers 

UAT release

Activiteiten 

Nakijken of UAT omgeving in orde is



Organiseren van de UAT



Updaten testscenario‟s en testdata



Uitvoeren van de UAT



Lijsten, wegen en toewijzen van bugs en issues



Controleren dat de acceptatiecriteria voldaan zijn



Maken van het finaal UAT rapport en deze communiceren

Output 

Issues en bugs lijsten



UAT testrapport



datum 05/06/2013

bladnummer 59

Procesflow Proces Testen : 6. Uitvoeren UAT

Business PM

Phase UAT aanvraag

PM ICT

6.2 ICT testen zijn afgerond?

6.13 Bepaal impact en dringendheid bug of issue in overleg met Nee betrokkenen

6.5 Praktische organisatie UAT en info naar business

6.1 Plan UAT en wijs business testers toe

Ga naar « 7. PIT en afwerken testen » 6.20 Validatie UAT rapport ok?

Ja

6.21 Informeer betrokkenen

Ga naar « 5. Uitvoeren systeemtesten » Nee

6.15 Communiceer bugs & issue lijst naar betrokkenen

Projectteam ICT

Ja

6.14 Wijs oplossing bugs & issues toe

Ga naar « 4. Uitvoeren integratietesten »

6.16 Los bug of issue op

Systeembeheer der

Ja

6.3 Maak UAT omgeving klaar

6.4 UAT omgeving ok?

Tester ICT

Nee

6.19 Maak finaal UAT rapport

Ja 6.7 Testscenario’s ok?

Ja

6.8 Controleer testdata

6.9 Houd infosesie en demo voor business testers

6.12 Lijst eventuele Nee bugs en issues op

6.18 Acceptatiecriteri a voldaan?

6.11 Geef eventuele bugs en issues door aan Tester ICT

6.17 Maak UAT rapport

Business Tester

AnalistProgrammeur

Nee

6.9 Houd infosesie en demo voor business testers

6.6 Kijk testscenario’s na en werk ze bij

6.10 Voer UAT uit


Titel Plan UAT en wijs business testers toe

6.2

ICT testen zijn afgerond?

6.3

Maak UAT omgeving klaar

Beschrijving De business PM maakt op basis van de initiële UAT planning een definitieve UAT planning op. Op dit moment moet ook de info/demosessie gepland worden voor de business testers. De business PM beslist ook welke business testers op welk moment zullen deelnemen aan de UAT. De PM ICT kijkt na of de ICT testen correct zijn afgerond zodat de UAT fase kan starten. Dit is normaal gezien een formaliteit maar het zou kunnen dat een UAT aanvraag wordt gedaan zonder dat de ICT testen helemaal afgewerkt zijn. De systeembeheerder van infrastructuur moet de UAT omgeving klaarmaken, de oplossing daarop deployen en de testdata opladen. (zoals beschreven in het release document) Dit gebeurt via het release proces. De systeembeheerder contacteert de tester ICT, de



datum 05/06/2013

bladnummer 60

PM ICT en de PM business. De tester ICT controleert of de UAT omgeving ok is. Indien niet werk de analist-programmeur de UAT omgeving bij. De business PM is verantwoordelijk voor de praktische organisatie van de UAT. De tester ICT is de coördinator van de UAT testen. Er moet voor gezorgd worden dat de testscenario‟s klaar zijn, dat de testdata in orde is, dat de business testers de testprocedures kennen, etc. De tester ICT moet hier goed en op tijd communiceren met de business testers. Indien er al draft testscenario‟s zijn, worden deze bijgewerkt door de business testers om de definitieve testscenario‟s te maken. Indien er nog geen testscenario‟s zijn, worden deze op dat moment volledig opgemaakt. De tester ICT geeft hier support voor. De tester ICT kijkt de testscenario‟s van de business testers na naar coherentie en volledigheid. Indien ze niet in orde zijn, werken de business testers deze bij.

6.4

UAT omgeving ok?

6.5

Praktische organisatie UAT en info naar business

6.6

Kijk testscenario‟s na en werk ze bij

6.7

Testscenario‟s ok?

6.8

Controleer testdata

De testdata wordt gecontroleerd door de tester ICT. De testdata voor UAT is een recente kopij van productie .

6.9

Houd infosessie en demo voor business testers

Het is belangrijk dat de business testers exact weten hoe ze moeten te werk gaan, wat en wanneer ze moeten testen, hoe ze bugs en issues moeten doorgeven, etc. De tester ICT en de analist-programmeur geven een demo van de nieuwe oplossing. Tijdens deze sessie wordt er ook meer praktische informatie gegeven over hoe de UAT praktisch te werk zal gaan.

6.10

Voer UAT uit

De business testers voeren de user acceptance testen uit op basis van de gemaakte business testscenario‟s.

6.11

Geef eventuele bugs en issues door aan tester ICT

Alle bugs en issues die de business testers vinden, worden doorgegeven aan de tester ICT die de verdere opvolging zal verzorgen. Binnen het project moet beslist worden hoe de business testers de melding van de bugs of issues doen. Voor grotere projecten kan het zijn dat de business testers zelf de bugs in de Test Management Tool invoeren, voor kleinere projecten zal het meestal gemakkelijker zijn om de informatie via een ander kanaal aan de tester ICT te bezorgen. De business testers vullen de UAT testscenario‟s documenten aan en geven testrapporten door aan de tester ICT.

6.12

Lijst eventuele bugs en issues op

De tester ICT lijst de bugs en issues op zodat de business PM deze kan toewijzen.

6.13

Bepaal impact en dringendheid bug of issue in overleg met betrokkenen

Voor elke bug of issue moet eerst en vooral de impact bepaald worden. De business PM bespreek dit in samenwerking met de business testers, de PM ICT en de tester ICT. Daarna wordt ook de dringendheid van de bug of het issue bekeken, zodat de prioriteit van de bug of issue kan worden bepaald. Deze prioriteit wordt bepaald door de business PM die hierover indien nodig met de project stuurgroep overlegt. Tijdens de testfase worden regelmatig overlegmomenten gepland tussen de business PM, de business testers, de PM ICT en de tester ICT.

6.14

Wijs oplossing bugs &

De PM ICT wijst de verschillende bugs en issues toe



datum 05/06/2013

bladnummer 61

issues toe

aan de betrokken medewerkers van het projectteam.

6.15

Communiceer bugs & issues lijst naar betrokkenen

Eerst en vooral wordt het projectteam ICT geïnformeerd in verband met op te lossen bugs en/of issues. Bijkomend is het belangrijk om andere betrokkenen bij het project te informeren ivm de stand van zaken rond testen.

6.16

Los bug of issue op

De leden van het projectteam ICT lossen de bug of issue op. Eens deze is opgelost, gebeurt er opnieuw een integratietest door de tester ICT.

6.17

Maak UAT rapport

De business tester maakt een UAT rapport van wat hij heeft getest.

6.18

Acceptatiecriteria voldaan?

De acceptatiecriteria voor de UAT fase moeten voldaan zijn alvorens over te gaan tot de finale UAT rapportering.

6.19

Maak finaal UAT rapport

De tester ICT consolideert de verschillende UAT rapporten et maakt het UAT rapport.

6.20

Validatie UAT rapport ok?

De business PM moet het finale UAT rapport valideren.

6.21

Informeer nen

De business PM informeert de betrokkenen dat de UAT fase is afgerond en dat men zal kunnen overgaan naar productie.

betrokke-

2.4.7. Proces “PIT & afwerken testen” Doel 

Postimplementatietesten (PIT) uitvoeren op de oplossing in productie om eventuele issues bij in productiestelling op te vangen



Bewaren testdocumentatie op de kennisbeheersite ICT

Input 

UAT testrapport



PIT scenario‟s

Triggers 

Oplossing in productie

Activiteiten 

Uitvoeren PIT scenario‟s en oplossen van eventuele problemen



Overdragen testdocumentatie op kennisbeheersite ICT

Output 

Geteste oplossing in productie



Opgeslagen permanente testdocumentatie



datum 05/06/2013

bladnummer 62

Procesflow


Titel Zorg voor uitvoering PIT scenario(„s)

7.2

Output ok?

7.3

Bespreek probleem en zoek oplossing in overleg met release manager en PM‟s Informeer release manager

7.4

7.5

7.6

7.7

Informeer PM ICT oplossing correct in productie Overdragen testscenario‟s en testrapporten aan CCL testen Opslagen testdocumentatie op kennisbeheersite

Beschrijving Na in productiestelling zorgt de systeembeheerder dat de PIT scenario‟s worden uitgevoerd volgens wat is beschreven in het deployment document. In sommige gevallen zal hij dit zelf doen, in andere zal hij de business vragen om deze uit te voeren. De systeembeheerder kijkt na of de PIT scenario‟s positief zijn afgerond. Indien niet moet hij overleg inschakelen met de PM‟s en de release manager. De systeembeheerder moet bij een probleem overleggen met de release manager en de PM ICT en business PM wat de volgende stappen zijn en hoe het probleem opgelost kan worden. Wanneer de PIT positief zijn afgelopen moet de release manager geïnformeerd worden zodat hij op zijn beurt andere betrokkenen kan informeren volgens wat is afgesproken in het release proces. De release manager informeert de PM ICT dat de oplossing correct in productie is gebracht. De PM ICT zorgt voor verdere communicatie binnen het project. Bij het in productie zetten moet de tester ICT de verschillende testscenario‟s en rapporten overdragen aan de CCL testen zodat hij deze kan opslagen op de kennisbeheersite. De CCL testen kijkt de documenten nog eens na en slaagt ze dan op, op de kennisbeheersite van ICT.

DEEL NEGEN REF. 19 ICT PROCESS FLOWS

Recommend Documents