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