DEEL NEGEN REF. 19 ICT PROCESS FLOWS

Transcriptie

1 PG E1 05/06/ 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.

2 PG E1 05/06/ INHOUDSTAFEL 1. Scope van deze bijlage Beschrijving ICT processen Incident management Proces aanmaken service call Proces verwerken incident geïntegreerde helpdesk Proces Verwerken major incident Proces verwerken incident 1 e lijn Proces Verwerken incident 2 e lijn Proces Verwerken service request geïntegreerde helpdesk Proces Verwerking request volgens SOP Proces Afsluiten service call Proces Knowledge database aanvullen Change management Proces Change aanvraag indienen Proces RFC voorbereiden voo CAB Proces RFC prioritiseren voor uitvoering Proces Change plannen en uitvoeren Proces Change opleveren Release management Proces UAT release aaanvraag en planning Proces UAT release installatie, testing en bug fixing Proces Intermediate release aanvraag en planning Proces Intermediate release installatie, testing en bug fixing Proces Productie release aanvraag en planning Proces Productie release installatie Test management Proces Maken Master Testplan Proces Voorbereiden UAT Proces Uitschrijven testscenario s Proces Uitvoeren integratietesten Proces Uitvoeren systeemtesten Proces Uitvoeren UAT Proces PIT & afwerken testen... 61

3 PG E1 05/06/ Beschrijving ICT processen 2.1. Incident management Proces aanmaken service call Doel Input Opnemen, evalueren, registreren en categoriseren van de service call. Zorgen voor complete en kwaliteitsvolle service call informatie. 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 Output 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 Gecategoriseerde, geregistreerde en gedispatchte service call (incident of service request of change aanvraag) Geweigerde afgesloten service call Procesflow

4 PG E1 05/06/ Procesbeschrijving # Titel Beschrijving 1.1. Oproep of Web logging 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 ICT-klant belt geïnte- De ICT-klant belt de geïntegreerde helpdesk waar greerde helpdesk 1.3. ICT-klant registreert zelf zijn call in de Service Desk 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 1.8. Service call aanvaarden 1.9. Valideren en registreren van service call in Service Desk Incident of Service Request of change aanvraag ICT-klant informeren over weigering aanvraag/ Dispatchen naar andere dienst 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 hij de service call en zal de 1 ste of 2 de 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 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

5 PG E1 05/06/ service call heeft gemeld Afsluiten service call 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 Proces verwerken incident geïntegreerde helpdesk Doel Input 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 Geregistreerd incident Triggers Helpdeskmedewerker die de service call dispatcht Activiteiten Output 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 Opgelost incident Log voor knowledge database Geëscaleerd incident

6 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 2.1. Major or Minor? 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 Dispatch major incident naar Incident Manager De helpdeskmedewerker stuurt het major incident verder door naar de Incident Manager Prioriteren incident 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 helpdesk, 1 ste lijn of 2 e lijn medewerker binnen de af te handelen incidenten beslissen waarmee hij begint Grote impact en nood aan communicatie? 2.5. Communiceer naar de betrokken medewerkers 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

7 PG E1 05/06/ Incident op te lossen door geïntegreerde helpdesk? 2.7. Incident oplossen, documenteren en testen binnen SLA 2.8. Opgelost binnen SLA? 2.9. Aanvullen knowledge database Log voor knowledge database Escaleren naar 1 ste of 2 de Lijn direct een 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, escaleert hij het incident onmiddellijk naar de 1 ste 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 helpdesk naar 1 ste Lijn en van 1 ste Lijn naar 2 de Lijn. In het geval van een incident waarvoor een SOP bestaat waarin staat beschreven dat het incident door de 2 de Lijn behandeld moet worden kan het incident direct worden geëscaleerd naar 2 de Lijn door de geïntegreerde helpdesk Dispatch naar 1 ste lijn De helpdeskmedewerker dispatcht het incident naar een 1 ste lijn Dispacth naar 2 de lijn De helpdeskmedewerker dispatcht het incident naar een 2 de lijn. Kan enkel indien er een SOP bestaat Proces Verwerken major incident Doel Opvolging afhandeling van een major incident Input Gelogd incident na behandeling door geïntegreerde helpdesk Triggers Dispatching incident door geïntegreerde helpdesk

8 PG E1 05/06/ 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 # Titel Beschrijving 3.1. Diagnose Major Incident De Incident Manager evalueert het incident en beslist of het om een major incident gaat of niet Validatie als Major Incident 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 3.3 Aanvullen knowledge database? 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.

9 PG E1 05/06/ Log voor knowledge database 3.5. Opzetten Major Incident Team in samenwerking met ICT hoofden 3.6. Communicatie naar alle betrokkenen 3.7. Oplossingsplanning opmaken 3.8. Dispatch naar 1 ste afhandelaar (1 ste of 2 de lijn) 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 1 ste Lijn medewerker, een 2 de Lijn mederker of een externe partij zijn Oplossen incident De verantwoordelijke afhandelaar zoekt naar een oplossing en implementeert deze Testen oplossing De verantwoordelijke afhandelaar test altijd zijn oplossing voor hij deze terugstuurt naar de Incident Manager. Hij kan hiervoor alle nodige personen inschakelen Valideren oplossing De Incident Manager kijkt na of de oplossing en/of work-around in orde zijn Incident opgelost? 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 Communiceren oplossing incident en of work-around naar betrokkenen Geleerde lessen rapport opmaken. Log voor knowledge database Status incident aanpassen? 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.

10 PG E1 05/06/ Aanpassen status incident Communiceren naar betrokkenen over statusverandering Planning opvolgen/ Crisis Team meeting Dispatch naar volgende afhandelaar (1 ste of 2 de lijn) Trigger voor change aanvraag of Probleem? Dispatch naar geïntegreerde helpdesk 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 afhandelaar kan zowel een 1 ste Lijn medewerker, een 2 de 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 Proces verwerken incident 1 e lijn Doel Input Afhandeling van een incident door 1ste lijn of escalatie naar 2de lijn of doorsturen naar change proces Gelogd incident na behandeling door geïntegreerde helpdesk of incident manager Triggers Escalatie incident door geïntegreerde helpdesk Activiteiten Output Diagnose en eventuele vraag voor bijkomende informatie om incident te kunnen oplossen Oplossen incident en indien nodig escalatie naar 2de lijn Afgehandeld incident Geëscaleerd incident naar 2de lijn Trigger voor change aanvraag

11 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 4.1. Diagnose Incident De afhandeling van een incident start altijd met een diagnose. Dit helpt de 1 ste lijn medewerker om het incident te begrijpen en te evalueren of hij over genoeg informatie beschikt. Via de knowledge database kan de 1 ste lijn medewerker alle nodige informatie vinden om een zo precies mogelijke diagnose te stellen Nood aan bijkomende informatie? De 1 ste lijn medewerker kan beslissen dat hij meer informatie nodig heeft Neem contact met Om meer informatie te krijgen neemt hij contact op met ICT-klant voor bijkomende de ICT-klant. De 1 ste lijn medewerker is vrij om zijn informatie communicatiekanaal te kiezen Aanleveren bijkomende De ICT-klant geeft de nodige bijkomende informatie informatie door aan de 1 ste lijn medewerker Escalatie naar 2 de Op basis van een eerste diagnose dient de 1 ste lijn medewerker Lijn? te beslissen of hij het incident zelf kan oplos- sen, dan wel beter onmiddellijk escaleert naar de tweede lijn Escaleer naar 2 de Lijn De 1 ste lijn medewerker stuurt het incident door naar 2 de 4.7. Oplossen, documenteren en testen Incident lijn. De 1 ste lijn medewerker lost het incident op en vergeet niet de oplossing zo goed mogelijk te documenteren. De 1 ste 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 Incident opgelost? 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.

12 PG E1 05/06/ Aanvullen knowledge database? Log voor knowledge database Dispatch naar geïntegreerde helpdesk voor afsluiting Nood aan change aanvraag als oplossing? 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 naar 2 de lijn Proces Verwerken incident 2 e 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 Trigger voor change aanvraag Afgehandeld incident

13 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 5.1. Diagnose Incident De afhandeling van een incident start altijd met een diagnose. Dit helpt de 2 de 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 database kan de 2 de lijn medewerker alle nodige informatie vinden om een zo precies mogelijke diagnose te stellen Nood aan nieuwe dispatching? 5.3. Terugsturen naar 1 ste Lijn? 5.4. Dispatch naar 1 ste lijn afhandelaar 5.5. Dispatch naar volgende 2 de lijn afhandelaar 5.6. Nood aan change aanvraag als oplossing? De 2 de 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 1 ste lijn ofwel doorsturen naar een andere 2 de lijns afhandelaar. Hij moet zijn beslissing wel documenteren. (Men kan niet dispatchen naar een externe partij, de 2 de lijn medewerker blijft altijd verantwoordelijk, maar hij kan wel beroep doen op hulp van een externe partij.) Opsplitsing om ofwel naar 1 ste lijn terug te sturen ofwel door te sturen naar 2 de lijn. De 2 de lijn medewerker moet het incident terugsturen naar de 1 ste lijn en dispacht dus het incident naar de 1 ste lijn. De 2 de lijn medewerker moet het incident doorsturen naar een andere 2 de 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

14 PG E1 05/06/ Nood aan bijkomende informatie? 5.8. Neem contact met ICTklant voor bijkomende informatie 5.9. Aanleveren bijkomende informatie Oplossen, documenteren en testen incident het change management proces. Indien geen change aanvraag nodig is wordt het incident verder afgehandeld volgens het normale traject. De 2 de lijn medewerker kan beslissen dat hij meer informatie nodig heeft. Om meer informatie te krijgen neemt hij contact op met de ICT-klant. De 2 de lijn medewerker is vrij om zijn communicatiekanaal te kiezen. De ICT-klant geeft de nodige bijkomende informatie door aan de 2 de lijn medewerker. De 2 de lijn medewerker lost het incident op en vergeet niet de oplossing zo goed mogelijk te documenteren. De 2 de 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. Indien de 2 de lijn medewerker nood heeft aan een externe partij moet hij dit zelf opvolgen en blijft hij verantwoordelijk. (Enkel externe partijen onder contract met kunnen als 3 de lijn support gebruikt worden.) Incident opgelost? Na het testen is het incident ofwel opgelost ofwel niet. Indien het incident niet opgelost is, wordt gekeken of een volgende 2 de 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 Aanvullen knowledge database? Log voor knowledge database Dispatch naar geïntegreerde helpdesk voor afsluiting 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 Proces Verwerken service request geïntegreerde helpdesk Doel Input Evaluatie en verwerking van een service request Nakijken aanwezige goedkeuringen en dispatching naar de correcte afhandelaar 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

15 PG E1 05/06/ Output Gedispatchte service request Voorstel SOP voor nieuwe standaard service request Geweigerde niet-standaard service request Geweigerde standaard service request Afgehandelde service request Procesflow Procesbeschrijving # Titel Beschrijving 6.1. Standaard service request? 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 Evaluatie request Indien het gaat om een niet standaard service request evalueert de coördinator support de service request Niet standaard? De coördinator support beslist of het al dan niet om een niet standaard service request gaat Aanvaarden als service request? 6.5. Dispatchen naar verantwoordelijke afhandelaar 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 1 ste of 2 de lijn medewerker die dit zal afhandelen.

16 PG E1 05/06/ Afhandelen service request 6.7. Aanmaken voorstel SOP voor nieuwe standaard service request 6.8. Dispatch naar geïntegreerde helpdesk voor afsluiting 6.9. Communiceer weigering naar ICT-klant Dispatch naar geïntegreerde helpdesk voor afsluiting Goedkeuring hiërarchie nodig? Goedkeuring hiërarchie aanwezig? De verantwoordelijke 1 ste of 2 de lijn medewerker moet een oplossing vinden om dit nieuwe request af te handelen. Op basis van de oplossing die de 1 ste of 2 de 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 Proces Verwerking request volgens SOP Doel Input Afhandeling van een service request volgens de SOP (standaard operationele procedure) Gelogde en goedgekeurde service request na behandeling door geïntegreerde helpdesk Triggers Dispatching service request door geïntegreerde helpdesk Activiteiten Output Afhandelen service request volgens SOP Afgehandelde service request Doorgestuurde service request

17 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 7.1. Afhandelen service Het afhandelen van een service request verloopt altijd request volgens SOP volgens een SOP. In de SOP staat alles stap voor stap beschreven. De afhandelaar kan een helpdesk, 1 ste lijn of 2 de lijn medewerker zijn en voor sommige service requests zullen meerdere personen van verschillende niveaus moeten deelnemen SOP nog up to date? 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, 1 ste of 2 de lijn medewerker een log maken voor de knowledge database Log voor knowledge database/ SOP aanpassing 7.4. Dispatch naar geïntegreerde helpdesk voor afsluiting Proces Afsluiten service call Doel Input 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. Resultaat afhandeling service call communiceren naar de ICT-klant Tevredenheid van de ICT-klant meten Afsluiten van de service call 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

18 PG E1 05/06/ Output Heropende service call Afgesloten service call Communicatie over afgesloten incident met grote impact Procesflow Procesbeschrijving # Titel Beschrijving 8.1. ICT-klant vragen om validatie De helpdeskmedewerker moet de ICT-klant vragen oplos- om de oplossing van zijn incident of de afhandeling sing/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 Evaluatie oplossing/afhandelindent De ICT-klant evalueert de oplossing van zijn inci- of de afhandeling van zijn service request OK met oplossing/afhandeling? 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 Feedback tevredenheid De ICT-klant geeft zijn tevredenheid over de afhandeling van zijn service call door Afsluiten service call 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 Incident met grote impact en nood aan com- Indient dit incident initieel werd gecatalogeerd als met grote impact en nood aan communicatie dient

19 PG E1 05/06/ municatie? 8.7. Communiceren naar betrokkenen over oplossing incident 8.8. Diagnose reden van ongenoegen 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 Gegronde reden? 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 Terugsturen naar verantwoordelijke oplossing/afhandeling Evaluatie reden van ongenoegen Wanneer het incident inderdaad niet is opgelost of de service request niet is afgehandeld, wordt de service call teruggestuurd naar de verantwoordelijke afhandelaar (helpdesk, 1 ste of 2 de 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 Gegronde reden? 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 Communicatie naar de ICT-klant Proces Knowledge database aanvullen Doel Input 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. Knowledge database continu verbeteren en aanvullen op basis van de afgehandelde incidenten 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

20 PG E1 05/06/ Output Aangevulde knowledge database Procesflow Procesbeschrijving # Titel Beschrijving 9.1. Oplijsten voorstellen voor knowledge database 9.2. Categoriseren, aanvullen en valideren voorstellen 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 Is voorstel een SOP? 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 Geïmpacteerde helpdesk niveau s moeten SOP testen en valideren De medewerkers van de geïmpacteerde helpdesk niveau s testen de aangepaste SOP om zeker te zijn dat deze ook werkbaar is SOP ok? 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 Aanvullen knowledge database 9.7. Communiceren over aanvullingen knowledge database 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. ( , meeting, nieuwsbrief, )

21 PG E1 05/06/ Change management Proces Change aanvraag indienen Doel Input Een change aanvraag evalueren en klaarstomen tot een RFC Een change aanvraag Triggers Medewerkers die een idee hebben voor een change Incidenten die enkel ten gronde kunnen worden opgelost via een change Activiteiten Output Het aanmaken van een change aanvraag d.m.v. een service call (verplicht voor medewerkers van ; 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 Ingevuld RFC document waarbij business analist een omschrijving geeft van de functionaliteit. Een registratie van de RFC in de servicedesk

22 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 1.1 Aanmaken service De change aanvrager heeft een idee voor een change call 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 1.2 Beoordeling service call 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. 1.3 Opname 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

23 PG E1 05/06/ deze door naar tweede lijn (resp. dienst infrastructuur of dienst applicaties in de centrale diensten). 1.4 Change? 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. 1.5 Opstellen RFC document De eerste lijn stelt een RFC document op in samenwerking en overleg met de business analist. 1.6 Opname tweede lijn De tweede lijn (dienst infrastructuur voor technische materies of dienst applicaties voor functionele materies) zal een doorgestuurde call bekijken. 1.7 Bug? 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. 1.8 Opstellen RFC docu- De tweede lijn stelt een RFC document op in samen- ment 1.9 Terechte change aanvraag? 1.10 Informeer aanvrager en eerste lijn werking en overleg met de business analist. De business analist evalueert de aanvraag op duidelijkheid, meerwaarde voor 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 Analyse en business vereisten opmaken 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) 1.12 Urgent en geen bug? 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 Goedkeuring vragen aan directeur functioneel domein 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 Aanmaak RFC 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 Informeer aanvrager en eerste lijn 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. 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.

24 PG E1 05/06/ Proces RFC voorbereiden voo CAB Doel Input Aanleveren van alle nodige informatie om een beslissing te laten nemen door de CAB. Ingevuld RFC document Resource planning Triggers De registratie van de RFC in de service desk Activiteiten Output 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 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

25 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 2.1 Urgent change procedure? Indien het om een urgent change gaat, besluit de change manager dat de urgent change procedure zal 2.2 Analyseer impact en vraag inschattingen 2.3 Vraag nodige goedkeuringen 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. 2.4 Bug? 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. 2.5 Geef goedkeuring? De change manager geeft al dan niet zijn goedkeuring voor urgent change die ook een bug is 2.6 Geef goedkeuring Het hoofd infrastructuur geeft al dan niet zijn goedkeuring voor urgent change die ook een bug is 2.7 Geef goedkeuring Het afdelingshoofd ICT geeft al dan niet zijn goedkeu-

26 PG E1 05/06/ ring voor een urgent change. 2.8 Goedkeuringen OK? 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. 2.9 Verzamel en evalueer RFC s 2.10 Analyseer impact en vraag inschattingen 2.11 Verzamel bijkomende RFC info 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 Vervolledig RFC Samenbrengen van alle inschattingen van de verschillende resources + duidelijke afbakening van scope en vereisten RFC volledig en correct? 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) RFC annuleren? 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 Informeer aanvrager en eerste lijn 2.16 Promoveren tot project? 2.17 Informeer aanvrager en eerste lijn 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 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.

27 PG E1 05/06/ Proces RFC prioritiseren voor uitvoering Doel Input Beslissing over de RFC o o o vraag voor bijkomende informatie afwijzing + argumentatie goedkeuring van RFC + prioriteit voor latere inplanning Afweging of change binnen een bestaand project kan worden genomen of bundeling van changes in een project Ingevulde en gevalideerde RFC documenten Resource capaciteit (ICT en BICC) Triggers Eén week voor de CAB meeting Activiteiten Output 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 Goedkeuring van voorgestelde RFC Vraag tot opmaken van een project mandaat Prioriteiten voor planning van changes Procesflow

28 PG E1 05/06/ Procesbeschrijving # Titel Beschrijving 3.1 Prioriteren RFC s binnen domein 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 3.2 Bepaal prioriteit (urgentie en belangrijkheid) 3.3 Bijkomende info nodig? 3.4 Bundeling van changes? 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. 3.5 Bundel changes 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. 3.6 Promoveren tot project? 3.7 Informeer aanvrager en eerste lijn 3.8 Goedkeuring RFC voor uitvoering? 3.9 Informeer aanvrager en eerste lijn 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 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.

29 PG E1 05/06/ 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 Output Aanvragen resources Architectuur uitwerken Infrastructuur uitwerken Functionele analyse Technische analyse Ontwikkeling Testing BICC uitwerken Kwalitatieve realisatie van software en/of hardware volgens de scope beschreven in de RFC. Testrapport

30 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 4.1 Coördineer uitvoering De change manager zal de nodige profielen aanvragen bij de desbetreffende diensthoofden. 4.2 Inboeken resources Change manager zal de verschillende betrokken profielen inboeken volgens de opgegeven inschattingen. Zie het resource management proces voor meer detail. 4.3 Informeer betrokkenen change 4.4 Opvolgen uitvoering change + testen 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 4.5 Uitvoeren architectuur Bij changes waar Architectuur is ingeboekt, dient eerst een oplossing te worden voorgesteld. 4.6 Uitvoeren A, D & T en bouw 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. 4.7 Uitvoeren BICC Bij changes waar BICC is ingeboekt dient de nodige rapportering worden aangemaakt of aanvulud. 4.8 Uitvoeren infrastruc- Bij changes waar Infrastructuur is ingeboekt, dient de-

31 PG E1 05/06/ tuur ze te worden opgeleverd. 4.9 Test OK? Testresultaten worden afgecheckt en er wordt een oordeel geveld m.b.t. de gevraagde en geleverde functionaliteit Proces Change opleveren Doel Input Gerealiseerde change opleveren in productie en RFC afsluiten Test report van integratie testing Software- en infrastructuurcomponenten Triggers Realisatie van de change (change plannen en bouw) Activiteiten Output Aanlevering van softwarecomponenten en infrastructuur componenten in release container Change beschikbaar in productie Afgesloten RFC Procesflow Procesbeschrijving # Titel Beschrijving 5.1 Plan release Mogelijke release momenten worden nagegaan binnen de release kalender. 5.2 Overleg release datum 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). 5.3 Inschrijving in release proces 5.4 Volg release proces Release proces zorgt voor aanlevering van change in productie. Dit kan gaan om een normale release via de

32 PG E1 05/06/ Bug binnen garantieperiode? 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. 5.6 Afsluiten RFC 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

33 PG E1 05/06/ Release management Proces UAT release aaanvraag en planning Doel Input 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 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 Output 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 Release planning voor UAT Inschatting van de downtimes voor UAT omgeving Allocatie van resources voor installatie in UAT

34 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 1.1 Urgent release goedkeuring nodig? Indien een urgent release gewenst is en hiervoor nog geen goedkeuring werd verkregen, moet die aangevraagd worden. N.B.: een goedkeuring voor een urgent 1.2 Goedkeuring vragen aan directeur functioneel domein 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). 1.3 Aanmaak release De release aanvrager dient een release aanvraag in aanvraag volgens sjabloon release aanvraag. 1.4 Urgent release? Bij een niet urgente release aanvraag kan onmiddellijk worden overgegaan naar Evalueren aanvraag. 1.5 Urgent release goedkeuring nodig? Wanneer reeds een goedkeuring werd verkregen voor een urgent change kan onmiddellijk worden overgegaan naar Bepaal releasemoment. 1.6 Goedkeuringen OK? De goedkeuring van de directeur van het functioneel domein moet bijgevoegd worden bij de release aan-

35 PG E1 05/06/ Bepaal releasemoment 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.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 Verifieer container beschikbaarheid voor UAT 1.11 Opleveren release files in container voor UAT 1.12 Aanvaarden release info (check op volledigheid)? 1.13 Aanvaarden release info (check op inhoud)? 1.14 Maak release planning voor UAT 1.15 Nakijken afhankelijkheden 1.16 Conflict in planning voor deployment? 1.17 Bepalen middelen voor release ICT Bouwer verifieert of men alle bestanden van de container kan plaatsen op de aangeduide plaats. 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?). 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. Afhankelijkheden tussen verschillende release activiteiten en afhankelijkheden tussen installatiestappen worden uitgeklaard. 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. 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. 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

36 PG E1 05/06/ Informeer business analisten en local supports over inhoud UAT release worden geregeld (overwerk, weekendwerk, ). 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 Proces UAT release installatie, testing en bug fixing Doel Input 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. Aangeleverde containers van changes en projecten Aanlevering van hardware componenten UAT release planning Triggers Release kalender UAT Activiteiten Output 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 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.

37 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 2.1 Kopieer test data via Infrastructuur voert het script uit om de aangevraagde aangeleverde scripts data van productie naar de UAT omgeving te zetten. 2.2 Update status planning + start installatie 2.3 Voer acties uit volgens planning op UAT 2.4 Doorgeven timings & succes per container 2.5 Update status planning + uitvoeren next step volgens planning 2.6 Informeer belanghebbenden dat project of RFC in UAT staat 2.7 Einde planningscyclus? 2.8 Testing UAT door business 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

38 PG E1 05/06/ 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 Invullen van issues in tracking tool 2.11 Blokkerende bugs voor project of RFC? 2.12 Beslissing over aanpak issue list voor project 2.13 Opmaken planning bug fixing 2.14 Verwerken bugs volgens planning De ICT klant verwerkt alle testrapporten in de bug tracking tool (Jira). 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. De release aanvrager zal de verschillende bug issues doornemen met business. Scope uitbreidingen kunnen niet opgenomen worden; enkel bugs op bestaande scope. 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. 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 Proces Intermediate release aanvraag en planning Doel Input 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. 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-

39 PG E1 05/06/ 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 # Titel Beschrijving 3.1 Aanmaak release De projectmanager ICT of de change manager dient release aanvraag aanvraag in volgens sjabloon release aanvraag. 3.2 Evalueren aanvraag Aanvraag wordt geëvalueerd voor verdere verwerking (correct en volledig). 3.3 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. 3.4 Verifieer container beschikbaarheid voor IR 3.5 Opleveren release files in container voor IR 3.6 Aanvaarden release info (check op volle- 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.

40 PG E1 05/06/ digheid)? 3.7 Aanvaarden release info (check op inhoud)? 3.8 Maak release planning voor IR 3.9 Nakijken afhankelijkheden 3.10 Conflict in planning voor deployment? 3.11 Bepalen middelen voor release 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. 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. Afhankelijkheden tussen verschillende release activiteiten en afhankelijkheden tussen installatiestappen worden uitgeklaard. 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. 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, ) Proces Intermediate release installatie, testing en bug fixing Doel Input 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. Aangeleverde containers van changes en projecten Aanlevering van hardware componenten Intermediate release planning Triggers Release kalender IR Planning voor IR klaar

41 PG E1 05/06/ Activiteiten Output 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 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 Procesbeschrijving # Titel Beschrijving 4.1 Kopieer test data via aangeleverde scripts 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 aangele- 4.2 Update status planning + start installatie 4.3 Voer acties uit volgens planning op IR 4.4 Doorgeven timings & succes per container verde 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

42 PG E1 05/06/ Update status planning + uitvoeren next step volgens planning 4.6 Informeer belanghebbenden dat project of RFC in IR staat 4.7 Einde planningscyclus? 4.8 Testing IR door business 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. 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 Invullen van issues in tracking tool 4.11 Blokkerende bugs voor project of RFC? 4.12 Beslissing over aanpak issue list voor project 4.13 Opmaken planning bug fixing 4.14 Verwerken bugs volgens planning De ICT klant verwerkt alle testrapporten in de bug tracking tool (Jira). 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. De release aanvrager zal de verschillende bug issues doornemen met de ICT-klant. Scope uitbreidingen kunnen niet opgenomen worden; enkel bugs op bestaande scope. 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. 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 Proces Productie release aanvraag en planning Doel Input Alle succesvol geteste containers worden in productie gezet via PROD release aanvraag. Ingevulde (correct en complete) release sjabloon door de release aanvrager.

43 PG E1 05/06/ Triggers Release aanvraag van de release aanvrager. Release kalender Activiteiten Output 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, Release planning voor PROD Inschatting van de downtimes voor PROD omgeving Allocatie van resources voor installatie in PROD Procesflow Procesbeschrijving # Titel Beschrijving 5.1 Aanmaak release De release aanvrager dient release aanvraag in volgens aanvraag sjabloon release aanvraag. 5.2 Evalueren aanvraag Aanvraag wordt geëvalueerd voor verdere verwerking (correct en volledig).

44 PG E1 05/06/ 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. 5.4 Verifieer container beschikbaarheid voor PROD 5.5 Opleveren release files in container voor PROD 5.6 Aanvaarden release info (check op volledigheid)? 5.7 Aanvaarden release info (check op inhoud)? 5.8 Maak release planning voor PROD 5.9 Nakijken afhankelijkheden 5.10 Conflict in planning voor deployment? 5.11 Bepalen middelen voor release 5.12 Opstellen en versturen release nieuwsbrief 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?). 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. Afhankelijkheden tussen verschillende release activiteiten en afhankelijkheden tussen installatiestappen worden uitgeklaard. 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. 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, ). 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 Proces Productie release installatie Doel PROD release installatie van de beschikbare containers.

45 PG E1 05/06/ Input Aangeleverde containers van changes en projecten Aanlevering van hardware componenten PROD release planning Triggers Release kalender PROD Activiteiten Output 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. Procesflow Procesbeschrijving # Titel Beschrijving 6.1 Update status planning + start installatie Release manager verifieert of alle nodige voorbereidingen zijn getroffen en zorgt voor finale planning. 6.2 Voer acties uit volgens Infrastructuur voert de volgende stap van de planning planning op uit volgens instructies van release manager. PROD 6.3 Business testing in Release manager of projectmanager ICT zijn overeengekomen PROD nodig? met de business of een test in productie no- dig is. 6.4 Informeer ICT klant ICT klant wordt ingelicht dat de testen kunnen doorgaan. 6.5 PROD testing door Business voert de nodige testen op productiesysteem business 6.6 Doorgeven timings & succes per container door. De medewerker infrastructuur geeft de status van de installatie en de doorlooptijd van de installatiestap door aan de release manager.

46 PG E1 05/06/ Update status planning + uitvoeren next step volgens planning 6.8 Informeer belanghebbenden dat project of RFC in PROD staat 6.9 Einde planningscyclus? 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 PROD 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 Update rapport Release manager maakt een rapport op van alle installaties en testing.

47 PG E1 05/06/ Test management Proces Maken Master Testplan Doel Input Triggers Activiteiten 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 Aanmaak PID Aanmaken van een mastertestplan waarin: o o o testaanpak (welke testen in welke fase, hoe deze testen doen, welke testdata nodig, ) verantwoordelijkheden, acceptatiecriteria, Output 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

48 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 1.1 Vraag tester ICT om master testplan te maken en geef informatie door 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. 1.2 Bepalen testaanpak Afhankelijk van het type oplossing wordt de testaan- 1.3 Bepalen verantwoordelijkheden en escalatieprocedure 1.4 Bepalen acceptatiecriteria 1.5 Bepalen testplanning en workload pak 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. 1.6 Consolideren Master De tester consolideert het master testplan.

49 PG E1 05/06/ Testplan 1.7 Master testplan ok? 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. 1.8 Toevoegen master testplan aan PID Het master testplan wordt toegevoegd aan de PID door de business PM Proces Voorbereiden UAT Doel Input 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 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 o o o o Wie gaat testen? Wanneer testen? Wie maakt de testscenario s? Wie zorgt voor de uitnodiging van de UAT-testen? Wie coördineert de UAT-testen? Output Afbakening UAT scope Draft UAT scenario s Planning en afspraken UAT fase

50 PG E1 05/06/ Procesflow Procesbeschrijving houden overdracht business analyse (= Stap 1.5 Functionele analyse) 2.3 Analyseer business vereisten en leg UAT scope vast 2.4 Maken draft testscenario s 2.5 Bepaal organisatie UAT 2.6 Informeer betrokkenen # Titel Beschrijving 2.1 Organiseer overdrachtsmeeting De PM ICT en business PM moeten ervoor zorgen dat busi- ness analyse de business analyse wordt overgedragen aan de tester ICT en de business testers zodat ze kunnen kennismaken met het project. 2.2 Voorbereiden en 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.

51 PG E1 05/06/ Proces Uitschrijven testscenario s Doel Input Specificeren van de testscenario s (functionele en niet-functionele) en uitgangssituaties die zullen dienen om de integratie en systeemtesten uit te voeren 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 Procesbeschrijving # Titel Beschrijving 3.1 Organiseren overdracht De PM ICT zorgt ervoor dat het functioneel ontwerp functioneel en het high level design worden overgedragen aan de ontwerp en high level tester ICT. design 3.2 Houden overdracht De functioneel analist is verantwoordelijk voor de

52 PG E1 05/06/ functioneel ontwerp (= Stap 1.2 Design) 3.3 Houden overdracht high level design (= Stap 1.3 Design) 3.4 Overdrachten aanvaard? 3.5 Maak nodige functionele en nietfunctionele testscenario s 3.6 Validatie inhoud (en vorm) 3.7 Validatie vorm (en inhoud) 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.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 3.10 Informeer betrokkenen De tester ICT bepaalt welke testdata hij nodig zal hebben en zet dit ook op papier. 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) Proces Uitvoeren integratietesten Doel Input De testscenario s (functionele en niet-functionele) toetsen op één of meerdere ontwikkelde testobjecten 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

53 PG E1 05/06/ Output Acceptatievoorwaarden nakijken en finaal integratietestrapport maken en valideren Uitgevoerde testscenario s Integratietestrapport Procesflow o o Integratietest issueslijsten Testresultaten en scope Procesbeschrijving # Titel Beschrijving 4.1 Testbaar geheel klaar voor integratietesten? 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. 4.2 Maak testomgeving De analist-programmeur en/of systeembeheerder klaar 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. 4.3 Testomgeving ok? De tester ICT valideert de testomgeving. Indien het

54 PG E1 05/06/ Bekijk testscenario s en maak testdata klaar 4.5 Voer integratietesten uit 4.6 Lijst eventuele bugs en issues op 4.7 Bepaal impact en dringendheid bug of issue in overleg met betrokkenen 4.8 Wijs oplossing bugs & issues toe 4.9 Communiceer bug & issue lijst naar betrokkenen 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. 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. 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 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 Acceptatiecriteria voldaan? 4.12 Maak finaal integratietestrapport 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. 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 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 Informeer betrokkenen De tester ICT informeert de nodige betrokkenen (zie RASCI) dat de integratietesten voor het geteste deel van de applicatie afgerond zijn.

55 PG E1 05/06/ Proces Uitvoeren systeemtesten Doel Input Werkbaar geheel van een applicatie testen na positieve afhandeling van de integratietesten Functionele en niet-functionele testscenario s Integratie testrapporten Triggers Acceptatiecriteria integratietesten zijn voldaan Activiteiten Output 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 Gevalideerd systeemtestrapport

56 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 5.1 Systeemtesten nodig? Er wordt nagekeken of systeemtesten nodig zijn. Voor kleine applicaties kunnen de integratietesten overeen- komen met systeemtesten omdat er bijvoorbeeld maar 5.2 Testomgeving in orde? 5.3 Pas testomgeving aan 5.4 Bekijk testscenario s en maak testdata klaar 5.5 Voer systeemtesten uit 5.6 Lijst eventuele bugs en issues op 5.7 Bepaal impact en prioriteit bug of issue in overleg met betrokkenen éé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

57 PG E1 05/06/ Wijs oplossing bugs & issues toe 5.9 Communiceer bugs en issue lijst naar betrokkenen 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. 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. 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 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 Acceptatiecriteria voldaan 5.12 Maak finaal systeemtestrapport 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. Eens de acceptatiecriteria voldaan, maakt de tester ICT een finaal systeemtestrapport op dat als formele afsluiting zal dienen voor deze processtap 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 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 Informeer betrokkenen 5.16 Bepaal postimplementatie testscenario(pit) Eens het systeemtestrapport gevalideerd, informeert de tester ICT de verschillende betrokkenen (zie RASCI) dat de systeemtesten positief zijn afgerond. 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.

58 PG E1 05/06/ Voeg PIT instructies toe aan deployment document 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 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

59 PG E1 05/06/ Procesflow Proces Testen : 6. Uitvoeren UAT Phase Business Tester Tester ICT PM ICT Business PM Projectteam ICT Systeembeheer der Analist- Programmeur UAT aanvraag Nee 6.1 Plan UAT en wijs business testers toe 6.2 ICT testen zijn afgerond? Ja 6.3 Maak UAT omgeving klaar 6.4 UAT omgeving ok? 6.6 Kijk testscenario s na en werk ze bij Nee Ja 6.5 Praktische organisatie UAT en info naar business 6.7 Testscenario s ok? Nee Ja 6.15 Communiceer bugs & issue lijst naar betrokkenen 6.16 Los bug of issue op 6.8 Controleer testdata 6.14 Wijs oplossing bugs & issues toe 6.9 Houd infosesie en demo voor business testers 6.9 Houd infosesie en demo voor business testers 6.10 Voer UAT uit 6.13 Bepaal impact en dringendheid bug of issue in overleg met betrokkenen 6.12 Lijst eventuele bugs en issues op 6.11 Geef eventuele bugs en issues door aan Tester ICT Nee Nee 6.20 Validatie UAT rapport ok? 6.19 Maak finaal UAT rapport Ja 6.18 Acceptatiecriteri a voldaan? 6.17 Maak UAT rapport Ja 6.21 Informeer betrokkenen Ga naar «7. PIT en afwerken testen» Ga naar «5. Uitvoeren systeemtesten» Ga naar «4. Uitvoeren integratietesten» Procesbeschrijving # Titel Beschrijving 6.1 Plan UAT en wijs business testers toe 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 deel- 6.2 ICT testen zijn afgerond? 6.3 Maak UAT omgeving klaar nemen 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

60 PG E1 05/06/ PM ICT en de PM business. 6.4 UAT omgeving ok? De tester ICT controleert of de UAT omgeving ok is. Indien niet werk de analist-programmeur de UAT omgeving bij. 6.5 Praktische organisatie UAT en info naar business 6.6 Kijk testscenario s na en werk ze 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. 6.7 Testscenario s ok? 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.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 Voer UAT uit De business testers voeren de user acceptance testen uit op basis van de gemaakte business testscenario s Geef eventuele bugs en issues door aan tester ICT 6.12 Lijst eventuele bugs en issues op 6.13 Bepaal impact en dringendheid bug of issue in overleg met betrokkenen 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. De tester ICT lijst de bugs en issues op zodat de business PM deze kan toewijzen. 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 Wijs oplossing bugs & De PM ICT wijst de verschillende bugs en issues toe

61 PG E1 05/06/ issues toe 6.15 Communiceer bugs & issues lijst naar betrokkenen aan de betrokken medewerkers van het projectteam. 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 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 Maak UAT rapport De business tester maakt een UAT rapport van wat hij heeft getest Acceptatiecriteria voldaan? 6.19 Maak finaal UAT rapport 6.20 Validatie UAT rapport ok? 6.21 Informeer betrokkenen De acceptatiecriteria voor de UAT fase moeten voldaan zijn alvorens over te gaan tot de finale UAT rapportering. De tester ICT consolideert de verschillende UAT rapporten et maakt het UAT rapport. De business PM moet het finale UAT rapport valideren. De business PM informeert de betrokkenen dat de UAT fase is afgerond en dat men zal kunnen overgaan naar productie Proces PIT & afwerken testen Doel Input Postimplementatietesten (PIT) uitvoeren op de oplossing in productie om eventuele issues bij in productiestelling op te vangen Bewaren testdocumentatie op de kennisbeheersite ICT UAT testrapport PIT scenario s Triggers Oplossing in productie Activiteiten Output Uitvoeren PIT scenario s en oplossen van eventuele problemen Overdragen testdocumentatie op kennisbeheersite ICT Geteste oplossing in productie Opgeslagen permanente testdocumentatie

62 PG E1 05/06/ Procesflow Procesbeschrijving # Titel Beschrijving 7.1 Zorg voor uitvoering PIT scenario( s) 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. 7.2 Output ok? 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. 7.3 Bespreek probleem en zoek oplossing in overleg met release manager en PM s 7.4 Informeer release manager 7.5 Informeer PM ICT oplossing correct in productie 7.6 Overdragen testscenario s en testrapporten aan CCL testen 7.7 Opslagen testdocumentatie op kennisbeheersite 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.