Incident Management in de GrexxBoxx

Incident Management in de GrexxBoxx Door Dennis van Roy [email protected] 0491570

Begeleiders: Ir. W.F. Rietveld (TU/e) Prof. Dr. K.M. van Hee (TU/e) (TU Dr. S. Angelov (TU/e) Drs. P.G.M. .G.M. Hufen (Grexx) Eindhoven, April 2010

Dennis van Roy - Incident Management in de GrexxBoxx Opleiding: g: Business Information Systems TU/e

Samenvatting Dit rapport beschrijft de ontwikkeling van het incident management systeem bij Grexx. Grexx Grexx ondersteunt sinds 1999 bedrijven bij organisatieveranderingen op het gebied van strategie, besturing, processen, ocessen, systemen en cultuur. Grexx is begonnen als consultancybureau, maar heeft in de loop der jaren de dienstverlening uitgebreid en is in 2007 Grexx gestart met een nieuwe dienstverlening: dienstverlening de GrexxBoxx. Dit is een online workflowomgeving omgeving gebaseerd op servicegeoriënteerde technologie, die te gebruiken is voor alle soorten bedrijfsprocessen. Deze workflowomgeving omgeving wordt op een SaaS-platform aangeboden en dient momenteel al ter ondersteuning van tientallen bedrijfsprocessen bij onder andere Air France KLM, KLM, KPN, Robeco en SOS International. Het Incident Management Proces dat de incidenten omtrent deze GrexxBoxx Gr implementaties ondersteund is erg ad-hoc. ad hoc. Aangezien Grexx een groeiend bedrijf is en naar verwachting steeds meer GrexxBoxxen onder zijn beheer krijgt, krijgt, is het van belang dit proces te structureren. In dit rapport wordt de d aanpak van het project beschreven evenals een uitgebreid ontwerp van het nieuwe Incident Management Proces en het systeem dat ter ondersteuning hiervan in de GrexxBoxx wordt geïmplementeerd.

Dennis van Roy (0491570) Incident Management in de GrexxBoxx

2

Voorwoord Dit afstudeerrapport sluit een periode af van de studie Business Information Systems binnen de vakgroep Informatiesystemen van de faculteit Wiskunde en Informatica aan de Technische Universiteit Eindhoven. Het ontwerp en de implementatie implementat die worden beschreven in dit verslag zijn uitgevoerd in opdracht van Grexx, Grexx als onderdeel van een professionaliseringsslag in de organisatie. Mijn speciale dank gaat uit naar mijn begeleider Pieter Hufen, afstudeerbegeleiders afstudeer Erica Rietveld en Kees van Hee voor hun kritische blik en inspirerende ideeën.. Als laatste wil ik alle andere collega’s bij Grexx bedanken voor de ondersteuning en samenwerking tijdens het traject. 07 April, 2010 Dennis van Roy


3

Inhoudsopgave Samenvatting.............................................................................................................................. ................................ .............................. 2 Voorwoord ................................................................................................................................ ................................ ................................. 3 Inhoudsopgave ................................................................................................ ................................ ........................................................... 4 1

Inleiding ............................................................................................................................... ................................ ............................... 6 1.1

Grexx ................................................................................................ ................................ ............................................................ 6

1.1.1

Ambitie ................................................................................................ ................................ ................................................. 6

1.1.2

GrexxBoxx ................................................................................................ ................................ ............................................. 6

1.1.3

SaaS ................................................................................................ ................................ ...................................................... 7

1.2

Kritieke Succes Factoren Grexx ................................................................ ................................................. 10

1.3

Huidige Werkwijze Incident Management Manage bij Grexx ................................................. ................................ 10

1.3.1 1.4

Initiële Probleemstelling ............................................................................................ ............................ 12

1.4.1 1.5 2

Leeswijzer ................................................................................................ ................................ .................................................. 13 Information Technology Infrastucture Library (ITIL) ................................................. ................................ 14

2.1.1

Release 1 ................................................................................................ ................................ ............................................ 14

2.1.2

Release 2 ................................................................................................ ................................ ............................................ 15

2.1.3

Release 3 ................................................................................................ ................................ ............................................ 16

2.2

Waar te beginnen ................................................................................................ ................................ ...................................... 19

2.3

Incident Management ............................................................................................... ............................... 19

2.3.1 2.4

Verschil Incident Management in ITILv2 en ITILv3 ............................................ ................................ 20

Servicedesk ................................................................................................ ................................ ................................................ 23

Incident Management ent bij Grexx ................................................................ ....................................................... 25 3.1

Goed Incident Management voor Grexx ................................................................ ................................... 25

3.2

Evaluatie Huidige Situatie ................................................................ .......................................................... 26

3.3

Verscherpte definitie van de probleemstelling ......................................................... ................................ 26

3.3.1 3.4 4

Randvoorwaarden: ............................................................................................. ............................. 12

Theoretisch Onderbouwing .............................................................................................. .............................. 14 2.1

3

Groeiscenario’s ................................................................................................ ................................ ................................... 11

Randvoorwaarden .............................................................................................. .............................. 26

Doelstelling ................................................................................................ ................................ ................................................ 27

Business Ontwerp in het kader van Incident Management ............................................. ................................ 28 4.1

Governance Architectuur ................................................................ .......................................................... 28

4.2

Business Architectuur ................................................................................................ ................................ 30

4.2.1

Toelichting per partij in de context ................................................................ .................................... 31 Dennis van Roy (0491570) Incident Management in de GrexxBoxx

4

5

4.3

Incident Management Platform ................................................................ ................................................ 47

4.4

Operationele Proces ................................................................................................ .................................. 47

4.4.1

Besturing ................................................................................................ ................................ ............................................ 47

4.4.2

Statussen ................................................................................................ ................................ ............................................ 47

4.4.3

Casedata ten behoeve van het Incident Management Proces .......................... 53

4.5

Dashboards ................................................................................................ ................................ ................................................ 54

4.6

Beheer Proces ................................................................................................ ................................ ............................................ 54

4.7

Ontwikkel Proces ................................................................................................ ................................ ....................................... 54

Ontwerp in de GrexxBoxx ................................................................................................ ................................. 55 5.1

Formulier voor de case-objecten case ................................................................ .............................................. 55

5.2

Vertaling GrexxBoxx naar Petrinet ................................................................ ............................................ 58

5.2.1

Triggers ................................................................................................ ................................ ............................................... 58

5.2.2

Cancel met behulp van triggers................................................................ triggers .......................................... 60

5.2.3

Status ................................................................................................ ................................ .................................................. 61

5.2.4

Uniforme vertaling ............................................................................................. ............................. 62

5.3

Configuratie keuzes ................................................................................................ ................................ ................................... 65

5.4

Case-objecten ................................................................................................ ................................ ............................................ 66

5.4.1

Niveau van een GrexxBoxx ................................................................ ................................................. 66

5.4.2

Niveau van een incident ................................................................ ..................................................... 68

5.4.3

Automatische acties ........................................................................................... ........................... 85

5.5

Verificatie en validatie ............................................................................................... ............................... 86

6

Evaluatie Incident Management Proces ................................................................ ........................................... 87

7

Oordeel GrexxBoxx ................................................................................................ ................................ ........................................... 89 7.1

Ondersteuning procesconfiguratie................................................................ ............................................ 89

7.2

Ondersteuning Operationeel Proces ................................................................ ......................................... 89

Literatuur ................................................................................................................................ ................................ .................................. 91


5

1

Inleiding

In dit hoofdstuk wordt een inleiding gegeven van het bedrijf Grexx, waar het onderzoek wordt verricht. Er wordt uitgelegd in welke markt Grexx opereert en wat de gevolgen hiervan zijn voor het Incident Management. Vervolgens worden de probleemstelling robleemstelling en de opbouw van het rapport behandeld. 1.1

Grexx

Grexx is een innovatief bedrijf dat sinds 1999 bedrijven bij organisatieveranderingen ondersteunt op het gebied van strategie, besturing, processen, systemen en cultuur. Grexx is gestart als consultancybureau, bureau, maar heeft de dienstverlening in 2001 verder uitgebreid met het leveren van software ter ondersteuning hiervoor. De ontwikkelingen werden doorgezet en in 2007 is Grexx gestart met een nieuwe dienstverlening: dienstverlening de GrexxBoxx. Het is een online workflowomgeving omgeving gebaseerd op servicegeoriënteerde service technologie, die te gebruiken is voor alle soorten bedrijfsprocessen. Deze workflowomgeving wordt op een SAAS-platform aangeboden. Omdat het systeem wordt aangeboden op een SaaS-platform S platform en het systeem vitale v bedrijfsprocessen van andere organisaties ondersteunt zijn vertrouwen en beschikbaarheid belangrijke factoren. Dit zal in sectie 1.1.3 verder worden uitgewerkt. Om het vertrouwen van klanten te vergroten, de klanttevredenheid klanttevredenheid hoog te houden en de continuïteit te blijven garanderen wil Grexx een Incident Management Systeem invoeren om de incidenten met betrekking tot de GrexxBoxx implementaties te ondersteunen. ondersteunen Dit Incident Management Systeem ysteem omvat de totale afhandeling van incidenten op de GrexxBoxx implementaties en heeft als doel om een duidelijk overzicht te geven van de incidenten en de impact van deze incidenten te minimaliseren.. Definities van een incident en Incident Management worden gegeven in sectie 2.3. 1.1.1 Ambitie De ambitie van Grexx is het realiseren van verbetering in performance van alle soorten maar, vooral complexe, bedrijfsprocessen. Met complexe bedrijfsprocessen worden processen bedoeld die: • Aan veel verandering onderhevig zijn • veel actoren hebben • veel scenario’s hebben • veel regie vereisen Hierbij neemt Grexx zowel de rol van consultant, consultant bouwmeester als platform provider op zich, wat een vrij nieuwe vorm van dienstverlening is. Voor de klant heeft dit dus als voordeel dat er één leverancier is voor zowel de consultancy als de implementatie, wat de doorlooptijd verkort,, communicatie vergemakkelijkt en kosten vermindert. De Grexx-propositie propositie luidt dan ook: BPM-SaaS: één oplossing met één aanpak, één team en één platform. 1.1.2 GrexxBoxx Het platform dat is ontwikkeld voor het realiseren van de propositie is de GrexxBoxx. In de GrexxBoxx staat niet langer het bedrijfsproces centraal, maar de activiteiten die worden uitgevoerd. Medewerkers krijgen in de GrexxBoxx een overzicht van de cases waar zij bij betrokken zijn en de taken die uitgevoerd moeten worden. Alle informatie en tools die nodig Dennis van Roy (0491570) Incident Management in de GrexxBoxx

6

zijn voor het uitvoeren van deze taken worden gegeven. Werk wordt als het ware gezien als een behandeling van cases. De doelstelling van het werk is hett succesvol afhandelen afhandel van deze cases,, wat voor elke soort case anders kan worden gedefinieerd. gedefinieerd Voor de afhandeling van deze cases zijn bepaalde acties nodig. Deze acties kunnen via een strak geregistreerd proces verlopen, maar de volgordelijkheid van de acties a s kan ook voor elke case uniek zijn. Een caseklasse is een verzameling cases die dezelfde karakteristieken hebben. Deze caseklasses worden beschreven in de GrexxBoxx. Voor Voor een verder uitleg van de casegeoriënteerde visie van Grexx verwijs ik naar de white paper van (Ton Romeyn, 2009). 2009) Van de caseklassen wordtt onder andere de volgende data vastgelegd: • Casedata: Dit zijn de attributen van een case. Deze attributen kunnen gestructureerde en ongestructureerde informatie bevatten. bevatten. Gestructureerde informatie zoals integer, float, datetime en ongestructureerde informatie zoals text en file, wat gebruikt wordt voor vrije tekst en het invoegen van documenten. documenten • Actierepertoire: Dit is een beschrijving van de mogelijke acties die uitgevoerd uitgevo kunnen worden op een case. Deze acties kunnen als verplichte taken of als optionele taken worden aangeboden. De verplichte taken worden aangeboden op basis van het triggermodel. Dit wordt gebruikt als vastligt welke acties op elkaar moeten volgen. Optionele onele taken zijn taken die worden aangeboden en geïnitieerd kunnen worden door de gebruiker. • Rollen: In de definitie van een rol wordtt bepaald welke personen rechten hebben op het zien van informatie of het uitvoeren van activiteiten. De GrexxBoxx regelt de authenticatie op basis van een inlognaam en wachtwoord. Autorisatie kan in de GrexxBoxx voor een gehele caseklasse of voor individuele cases worden bepaald. • Triggermodel: In dit model wordt aangegeven wat de gevolgen zijn als een bepaalde state is bereikt. kt. Verschillende states zijn bijvoorbeeld dat een bepaalde actie is uitgevoerd, maar het kan ook een zelf gedefinieerde state zijn die de status s van een case representeert.. Aan triggers kunnen condities worden verbonden die bepalen of een trigger al dan niet iet wordt uitgevoerd. Door deze triggers is het mogelijk om acties volgens een vaste procedure te laten verlopen. verlopen Door het weglaten van deze triggers, kan ruimte worden gelaten aan gebruikers om hun eigen werk te organiseren. In sectie 5.1 wordt een ontwerp gegeven van een formulier om deze case-objecten case te definiëren. Daar zal ook meer gedetailleerde informatie worden gegeven van deze objecten. 1.1.3 SaaS Het platform wordt aangeboden als een Software as a Service (SaaS)-dienst dienst wat inhoudt dat de software als een online dienst via internet wordt aangeboden. De klant hoeft de software niet aan te schaffen, maar betaalt abonnementskosten voor het gebruik. Grexx zorgt verder voor de installatie, het onderhoud en het beheer. De service wordt extern gehost op de servers van Grexx-partner partner SaaSPLAZA (Siennax BV). BV) Voor de klant blijft deze externe partij echter onzichtbaar en is Grexx de enige contactcontact en contractpartij. Door deze vrij nieuwe manier van dienstverlening is het belangrijk dat de continuïteit van de SaaS-infrastructuur SaaS kan worden verzekerd. SaaSPLAZA heeft hiervoor voor de bedrijfsvoering en infrastructuur een SAS 70 Type II certificering. SAS 70 staat voor 'Statement on Auditing Standards number 70, Service Organizations'. Het is een internationaal geaccepteerde auditingstandaard die is ontwikkeld en wordt onderhouden door het American Institute of Certified Public Accountants (AICPA). Dit houdt in dat het operationeeloperationeel en risicomanagement via Dennis van Roy (0491570) Incident Management in de GrexxBoxx

7

standaardprocedures procedures wordt uitgevoerd. uitgevoer Dagelijks maken meer dan een miljoen eindgebruikers in 50 landen gebruik van bedrijfskritische SaaS oplossingen geleverd via SaaSplaza. In gesprekken met werknemers en het management van Grexx is gebleken dat vertrouwen en beschikbaarheid voor de SaaS-dienstverlening SaaS belangrijke factoren factor zijn. Zonder vertrouwen van de klant zal deze meer geneigd zijn voor zekerheid te kiezen en dus voor een aanpak die zich in de praktijk al heeft bewezen. Het Incident Management Proces is het proces dat het meest zichtbaar baar is voor de klanten. Hierdoor is het voor voor Grexx belangrijk om te zorgen en dat het Incident Management proces professioneel wordt ingericht. In sectie 2.3 wordt behandeld welke voordelen de invoering van een goed Incident Management M Systeem kan hebben. Op basis van drie veel voorkomende vormen van IT-dienstverlening IT dienstverlening wordt hieronder beschreven wat de gevolgen zijn van het type dienstverlening voor de incidentafhandeling. Dit om aan te geven waarom een goed incident management bij het SaaS-model SaaS extra belangrijk is. Traditioneel model In het traditionele model wordt software software (eventueel van externe leverancier) door de eigen IT afdeling van een organisatie beheerd. De software staat fysiek op de servers van de klant. De IT-afdeling ing kan zowel intern als extern zijn gepositioneerd. De klant (de business) communiceert alleen met de eigen IT-afdeling. IT In Figuur 1-1 is dit illustratief weergegeven.

gebruiker

IT

2de-lijns lijns incident afhandeling Software Leverancier

IT-afdeling (klant)

Klant (Business Business) 1ste-lijns incident afhandeling

gebruiker

IT

gebruiker

Figuur 1-1 Incidentafhandeling bij het traditionele model

In bovenstaande figuur zijn de communicatielijnen voor de incidentafhandeling weergegeven. Incidenten die de gebruikers ervaren worden eerst geanalyseerd en veelal opgelost door de eigen IT-afdeling. afdeling. Alleen in het geval dat er een fout in de software wordt geconstateerd, zal de IT-afdeling afdeling contact opnemen met de software leverancier. ASP model In het ASP model wordt de software door een Service Provider rovider aangeboden. De software bevindt zich fysiek op de servers van de Service Provider rovider en is via het internet beschikbaar. De ASP is voor de klant contactcontact en contractpartij en is verantwoordelijk voor de software. In Figuur 1-2 is dit illustratief weergegeven. weergegeve


8

gebruiker Internet 2de-lijns lijns incident afhandeling 3th party software

1ste-lijns incident afhandeling Service Provider

gebruiker Gebruikers (klanten klanten)

gebruiker

Figuur 1-2 incidentafhandeling bij het ASP model

Incidentmeldingen van gebruikers worden rechtstreeks aan de Service Provider gericht. De Service Provider neemt dus de 1ste-lijns jns incidentafhandeling voor zijn rekening. rekening Wanneer nodig zal de Service Provider escaleren naar de leverancier van de software, maar de Service Provider blijft verantwoordelijk voor de afhandeling. SaaS model odel biedt de softwareleverancier softwareleverancier zijn software aan als een service. Bij Grexx is In het SaaS-model de infrastructuur uitbesteed aan een host. De host van het SaaS-platform platform is voor de klant onzichtbaar en de klant communiceert alleen met de Saas-leverancier Saas zoals in Figuur 1-3 is weergegeven. Het grote verschil met het ASP model is dat de communicatie rechtstreeks verloopt van de gebruikers naar de SaaS-leverancier, SaaS , waarbij de host wordt overgeslagen. overgeslagen De 1ste-lijns lijns incidentafhandeling zal dus uitgevoerd worden door de SaaS-leve SaaS leveranciers ongeacht of de oorzaak bij de software of de infrastructuur van de host ligt. Als de oorzaak bij de host ligt, zal de SaaS-leverancier leverancier het probleem escaleren naar de host, host, maar zelf het contact onderhouden met de klant. Het is hierdoor belangrijk bij het Incident Management proces rekening te houden met de mogelijkheid dat de incidenten regelmatig door een externe partij (de host) wordt veroorzaakt. Deze incidenten worden ook door de externe ext partij opgelost zonder direct contact tussen de klant en deze partij.

Figuur 1-3 Incidentafhandeling bij het SaaS model


9

1.2

Kritieke Succes Factoren Grexx

Zoals eerder aangegeven is Grexx een dienstverlener die ondersteunende software als een SaaS-dienst aanbiedt. Hierdoor zijn de factoren Vertrouwen en Beschikbaarheid specifiek voor hen van essentieel tieel belang. Vertrouwen is een belangrijke factor omdat een klant zonder vertrouwen eerder geneigd is om te kiezen voor zekerheid en voor een aanpak die zich in de praktijk tijk al heeft bewezen. Beschikbaarheid is bij een SaaS-dienst dienst belangrijk omdat in tegenstelling tot het traditionele model, waar de software in de eigen organisatie is geplaatst, de klant hiervoor totaal afhankelijk is van de softwareleverancier. Hierdoor is het belangrijk te onderzoeken wat het Incident Management Proces voor positief resultaat kan hebben op deze twee factoren. De theoretische verdieping in hoofdstuk 2 behandelt de voordelen van een goed Incident Management Proces. Vervolgens zal in hoofdstuk hoofds 3 worden beschreven wat deze voordelen voor effect hebben op de Kritieke Succesfactoren van Grexx. 1.3

Huidige Werkwijze Incident Management bij Grexx

Door eigen ervaring bij de Grexx Servicedesk en gesprekken die ik heb gevoerd met klanten, werknemers en het management van Grexx is een duidelijk beeld verkregen over de huidige situatie van het Incident Management bij Grexx. Deze bevindingen worden hieronder kort uiteengezet. De klant maakt gebruikt van an de GrexxBoxx die gehost wordt op het platform van Siennax Si en via het internet wordt aangeboden. De klant heeft geen contact met de hostingpartij Siennax. In Figuur 1-4 is grafisch weergegeven hoe de incidentafhandeling verloopt.

Figuur 1-4 Huidige werkwijze

Incidenten worden gemeld via mail en/of telefoon. De mail wordt naar de servicedesk gestuurd of naar de betreffende consultant die de applicatie heeft geïmplementeerd. De mail van de servicedesk wordt vervolgens automatisch doorgestuurd doorgestuurd naar zes mensen, waaronder de servicedeskmedewerker, de technisch echnisch consultant, de Chief Technical Officer (CTO) en de configuratieconsultants. consultants. Het gevolg hiervan is dat er geen overzicht is wie de mail van de servicedesk afhandelt. Dit kan de servicedeskmedewerker vicedeskmedewerker zijn, zijn, maar veelal wordt het snel opgepakt door de consultants die de mail ook binnen krijgen in de mailbox.


10

Vervolgens wordt er vaak via de telefoon en/of mail gecommuniceerd wie er met het incident bezig is. De enige documentatie van het incident bevind zich in de mailbox van degene die het incident heeft opgepakt, opgepak , waardoor verbeteringen slecht te realiseren zijn. Bij telefonische meldingen wordt gebruikelijk direct naar de betrokken consultant gebeld. Ook in dit geval is er nagenoeg geen een documentatie en is mailcorrespondentie achteraf de enige manier om bepaalde gegevens en afspraken terug te zoeken. Doordat de incidenten door verschillende personen worden opgepakt, bestaat er ook de kans dat er op elkaar wordt gewacht. Dit heeft negatieve ieve gevolgen voor de reactietijd en de snelheid waarmee het incident kan worden opgelost, opgelost, maar is door de huidige omvang bij Grexx nog goed te overzien. De huidige situatie zorgt ook voor onwenselijke situaties als personen met vakantie gaan. De servicedeskmedewerker eskmedewerker is namelijk onvoldoende op de hoogte van de standaardincidenten en is daardoor onbekend met de gebruikelijke afhandeling hiervan. Dit kan extra vertraging in de incidentafhandeling veroorzaken. veroorzaken. Incidenten die gemeld worden door eigen medewerkers worden op dit moment ook niet geregistreerd en worden al dan niet in samenspraak met een collega direct door de desbetreffende medewerker of CTO opgelost. Incidenten die worden geïnitieerd vanuit automatische controlescripts, controlescripts komen op dit moment ook via ia de mail binnen. Hiervan wordt de afhandeling ook door verschillende mensen uitgevoerd, zonder regie en registratie. Ondanks bovenstaande werkwijze blijkt uit de feedback van klanten dat de klanttevredenheid erg hoog is. Dit komt doordat Grexx een klein team heeft met hoge professionaliteit. Dit komt terug in zowel de attitude als in kennis. De consultants hebben een hoge inzet en zijn daardoor ook buiten werktijd bereid om incidenten snel op te lossen. Verder bezit het kleine team alle kennis om de incidenten inci die niet het gevolg zijn van storingen door de hostingpartij zelf op te lossen. Hiervoor zijn ze dus niet afhankelijk van anderen, waardoor zowel de communicatielijnen als de reactietijden kort zijn. Dit neemt niet weg dat verbetering noodzakelijk is is om in de toekomst de klanttevredenheid hoog te houden. Bij verdere groei van Grexx zal de huidige werkwijze met betrekking tot Incident Management niet meer voldoen. Dit op zowel operationeel niveau als op het niveau van de sturing. Om de kwaliteit en klanttevredenheid klanttevredenheid bij verdere groei minimaal op hetzelfde niveau te houden,, moet de effectiviteit en de efficiëntie gewaarborgd blijven. Hiervoor moet het proces explicieter worden gedefinieerd. 1.3.1 Groeiscenario’s Er zijn twee groeiscenario’s bij Grexx die van invloed kunnen zijn op het Incident Management proces. Een eerste scenario is het opleiden van configuratiepartners. configuratie Deze partners zijn externe bedrijven die worden opgeleid tot GrexxBoxx configuratieconsultants. configuratie Dit houdt in dat deze partners ingeschakeld ingeschakeld worden om GrexxBoxxen voor klanten te configureren.. Deze partners zijn bij aanvang en wellicht langer het contactpersoon van de klant. Het verschil ten opzichte van de huidige situatie is dat de communicatie verloopt tussen de klant lant en de configuratiepartner. configuratiepar Bepaalde incidentmeldingen meldingen ontstaan namelijk door fouten in de configuratie en zullen wellicht ook door deze partners (moeten) worden opgelost. Dit is een belangrijk aspect waarbij tijdens het Incident Management proces rekening gehouden moet worden. worden Zowel de besturing als het proces zullen zodanig moeten worden ingericht dat dit mogelijk is. Dennis van Roy (0491570) Incident Management in de GrexxBoxx

11

Een andere mogelijkheid is om het proces door de klant zelf te laten configureren in de GrexxBoxx.. Op dit moment wordt de interface voor configurators van de GrexxBoxx G eenvoudiger en intuïtiever gemaakt, zodat dit in de toekomst mogelijk is voor de klanten. Dit zal ook een duidelijke verandering in de afhandeling van incidenten betekenen. betekenen De oorzaak van eventuele configuratiefouten fouten kan bij de klant zelf liggen. Dit houdt net als bij het vorige scenario in dat na een incidentmelding onderzocht moet worden of een configuratiefout hiervan de oorzaak is. In sectie 4.1 wordt beschreven hoe de besturing wordt ingericht om dit probleem te ondervangen. ndervangen. 1.4

Initiële Probleemstelling

Hoe kan Grexx het Incident Management Proces inrichten inrichten om bij verdere groei de kwaliteit te garanderen en de klanttevredenheid hoog te houden. 1.4.1 Randvoorwaarden: Bij aanvang van het project zijn de d volgende randvoorwaarden door Grexx met betrekking tot de oplossing opgelegd: • Het ontwerp twerp moet ITILv2ITILv2 en/of ITILv3-compliant nt worden ingericht. Dit omdat een hogere professionaliteit de geloofwaardigheid van de incidentafhandeling afhandeling vergroot wat met name bij een klein bedrijf als Grexx extra van belang is. • Implementatie van de het Incident Management systeem geschiedt in de GrexxBoxx. Grexx gebruikt dus het eigen product wat participatie van klanten in het Incident Management Proces mogelijk maakt. Als eerste zal hiervoor in hoofdstuk ofdstuk 2 een literatuuronderzoek gedaan worden naar ITIL ten einde te bepalen wat de verschillen tussen de twee versies met betrekking tot het Incident Management Proces zijn en welke versie als leidraad dient voor het proces. Vervolgens worden in hoofdstuk 3 de factoren beschreven waaraan een goed Incident Management Proces moet voldoen. Op basis van deze eisen zal een meer gedetailleerde probleemstelling probleemstel worden gedefinieerd gevolgd door de doelstelling van dit project.


12

1.5

Leeswijzer

De opbouw van het onderzoek erzoek en de aanpak wordt in Figuur 1-5 op een grafische manier weergegeven.

Figuur 1-5 Leeswijzer


13

2

Theoretisch Onderbouwing bouwing

In dit hoofdstuk is als eerste rste het ontstaan en de betekenis van de Information Technology Infrastructure Library uitgewerkt gewerkt. Daarna zijn kort de verschillende versies besproken, besproken gevolgd door verdieping van het Incident Management proces en de functie servicedesk. 2.1

Information Technology ology Infrastucture Library (ITIL)

In de jaren 80 van de vorige eeuw kwam het besef en de erkenning dat organisaties in toenemende mate afhankelijk werden van IT om doelstellingen te bereiken. Hierdoor werd de kwaliteitbeheersing van de IT-dienstverlening IT belangrijk. De Central Computer en Telecommunications Agency (CCTA) heeft destijds in opdracht van de Britse overheid onderzoek gedaan om een efficiënte en effectieve ve inzet van IT middelen bij organisaties orga van de Britse overheid te bewerkstelligen. bewerkstelligen Het resultaat ultaat van het onderzoek is gedocumenteerd in de Information Technology Infrastructure Library (ITIL). Deze reeks gepubliceerde gepubli boeken is een raamwerk van best practices voor IT Service Management. ITIL geeft als definitie voor IT Service Management: ‘het geheel van capabilities waarmee een organisatie met haar ITIT diensten waarde levert aan de klant’ (L. Peeters, 2008). Een goed IT Service Management leidt volgens (H. Kisters, 2003) onder andere tot de volgende voordelen: • Toename van efficiëntie en effectiviteit • Betere afstemming van ICT op de wensen van de business • Betere inzicht in de IT dienstverlening • Betere communicatie tussen business en IT • Duidelijke gedefinieerde rollen en verantwoordelijkheden verantwoordelijkhede ITIL is gebaseerd op best practices uit de praktijk en de bibliotheek is gepubliceerd in een reeks boeken die sinds de invoering zijn opengesteld opengestel voor publiek. publiek Het biedt een gestructureerde aanpak voor IT Service Management en wordt wereldwijd erkend als al de standaard voor het inrichten voor kwalitatief goed IT Service Management. ITIL is bedoeld als raamwerk voor het inrichten van IT Service Management en wordt voortdurend aangepast aan de behoeften van de industrie. Door de nieuwe behoeften en het voortschrijdend inzicht zijn er van ITIL al 3 versies uitgebracht, die telkens aan nieuwe behoeften voldoen. ITIL moet dus absoluut niet worden gezien als kant en klare oplossing, oplossing wat meteen de kracht en de zwakte van de bibliotheek bloot legt. Het raamwerk biedt bie best practices, waarbij voor elke specifieke organisatie moeten worden bekeken welke onderdelen van belang zijn en hoe deze moeten worden aangepast. Hierdoor is ITIL op elke organisatie toepasbaar, maar moeten de bedrijven zelf de vertaling maken van abstracte ab processen naar de eigen concrete operatie, wat veelal een tijdrovend implementatietraject inhoudt. 2.1.1 Release 1 De eerste versie van ITIL, ontstond in 1988 198 in de UK onder de naam: Government Infrastucture Management Method (GITMM). De focus lag hierbij hierbij op het Service Level Management, maar al snel werd het raamwerk uitgebreid met de functie Helpdesk, Contingency Planning en Change hange Management. anagement. Een jaar later (1989) werden hier de processen Problem Management, Configuration Management en Cost Management aan


14

toegevoegd. In 1991 werd de bibliotheek uitgebreid met Software Control and Distribution en een jaar later werd ook Capacity en Availability Management toegevoegd. De bibliotheek met best practices groeide op deze manier uit tot een veertigtal boeken en e begon ook gedaante te krijgen buiten overheidsinstellingen. Mede hierdoor, maar ook omdat de Central Computer and Telecommunications Agency (CCTA) de boeken als richtlijn in plaats van een formele methode wilde neerzetten, werd de GITMM hernoemd naar ITIL IT (wik09). De focus van deze eerste versie lag voornamelijk op het bieden van een functiegerichte aanpak op het gebied van operationele beheerprocessen. beheerprocessen De kern bestond hierdoor uit een twintigtal boeken die de Service Support en de Service Delivery processen beschreven. 2.1.2 Release 2 Om ITIL toegankelijker en beter betaalbaar te maken, werd de bibliotheek in 2000 herzien en opnieuw uitgegeven. Deze nieuwe ni uitgave werd verkleind tot 11 boeken met een procesgerichte aanpak die het gat gat tussen technologie en business dichtte door zich sterk te concentreren op processen voor effectieve dienstverlening aan de klanten ((OGC), 2007). Steeds meer bedrijven schaarde zich achter het gedachtegoed van ITIL, waardoor ITIL vooral in Nederland is uitgegroeid tot een defactostandaard voor het invullen van de technische beheerprocessen (Janssen, 2003). 2003) De 11 boeken van ITILv2 zijn: 1. Introduction to ITIL 2. Service Support 3. Service Delivery 4. Security Management 5. Business Perspective Volume 1 6. Business Perspective Volume 2 7. Planning to Implement Service Management 8. Application Management 9. Software Asset Management 10. ICT Infrastructure Management 11. Small Scale Implementations De kern van deze versie bestaat net als bij versie 1 uit de onderwerpen Service Support en Service Delivery. Dit is terug te zien in de ITIL trainingen, die behandelen alleen de onderwerpen uit deze twee boeken. boeken In het onderstaande schema staan de onderwerpen die in de twee kernboeken kern aan bod komen. De functie Servicedesk esk en het proces Incident Management worden in secties sectie 2.3 en 2.4 van dit rapport verder uitgewerkt. Service Support: Service Delivery: Servicedesk (functie) Service ce Level Management Incident Management Availability Management Problem Management Capacity Management Change Management IT Service Continuity Management Release Management Financial Management for IT Services. Configuration Management Dennis van Roy (0491570) Incident Management in de GrexxBoxx

15

2.1.3 Release 3 ITILv2 v2 geeft een gedetailleerde en effectieve omschrijving omtrent de support en delivery van diensten aan de business, maar heeft weinig aandacht voor het ontwerpen van diensten die voldoen aan de behoeften van de business. V2 geeft verder advies over het managen ma van de servicelevels, maar mist advies over het verbeteren van de kwaliteit. Behalve de verbetering op deze punten, is in ITILv3 ook rekening gehouden met hedendaagse uitdagingen zoals outsourcing, off-shoring off en het gebruik van internet. Om te voldoen doen aan bovenstaande eisen is ITILv3 uitgegaan van een lifecycle benadering en is ITILv3 geëvolueerd van een procesgeoriënteerde aanpak naar een servicegeoriënteerde aanpak. Niet het invoeren van een bepaald proces staat centraal, maar de zorg dat de services ices die een organisatie aanbiedt continu worden verbeterd. Verder is er ook meer nadruk op de Return On n Investment (ROI), waardoor het voor IT-managers IT managers gemakkelijker wordt om investeringen aan de business te verklaren. De lifecycle van een IT-dienst dienst wordt wordt geïntroduceerd met 4 fasen en de Continual Service Improvement (CSI). De CSI zit, zoals in figuur 2.1 te zien is, als een schil om de 4 fasen heen. De vijf fasen van de lifecycle benadering zijn: •

•

•

•

•

Service Strategy: beschrijft strategieën en policies om IT Service ervice Management in te voeren die in lijn is met de globale business strategie. strateg Service Design: beschrijft hoe de strategie gebruikt moet worden om ontwerpen en specificaties es voor de service te ontwerpen Service Transition: nsition: beschrijft hoe de transitie transiti van specificatie naar een live omgeving moet gebeuren. Service Operation: beschrijft hoe het dagelijkse verloop in een live omgeving van de service geregeld moet worden. worden Continual Service Improvement (CSI): Deze wordt in elke fase bekeken en gemeten om ervoor rvoor te zorgen dat IT aansluit bij de behoefte van de business. Waarnodig worden er aanpassingen gedaan om te zorgen dat IT blijft bl aansluiten bij de business. business

Van elk van deze fasen is een boek verschenen. Hiermee is de nieuwe release redelijk compact gehouden houden ten opzichte van zijn voorgangers. In Tabel 2-1 is weergegeven waar de processen van ITILv2 gepositioneerd zijn in ITILv3 en in welk deel de nieuwe processen van ITILv3 zich bevinden. Zoals te zien is in het schema, zijn dee processen uit ITILv2 in ITILv3 overgenomen en zijn er in de lifecycle fasen nog enkele nieuwe onderwerpen toegevoegd. Versie 3 is dus geen herschrijving, maar een effectieve reorganisatie van alle V2 onderwerpen met als aanvulling het concept van Service Lifecycle. Hierin wordt de service ondersteund van aanvang tot “pensionering”.. Verder zijn een aantal Dennis van Roy (0491570) Incident Management in de GrexxBoxx

16

processen, waaronder Incident Management, Management, opgesplitst in meerdere processen omdat uit de praktijk blijkt dat het overzichtelijker is om deze los te herkennen. herkennen. De grootste verschuiving is echter dat de focus niet meer ligt op de efficiëntie en de kosten, maar op het ontwerpen van de waarde van de service en het verbeteren van de kwaliteit van de service. ITILv3 is behalve in het Engels ook beschikbaar in meerdere erdere talen waardoor deze versie een stuk toegankelijker voor IT-managers managers in i niet-Engels sprekende gebieden.


17

Processen/Functies in ITILv2:

Fasen In ITILv3: Service Strategy

Service Design

Servicedesk Configuration Management Incident Management

Service Transition

Continual Service Improvement

Servicedesk Service Asset & Configuration Management Incident Management Problem Management

Problem Management Change Management Release Management

Change Management Release & Deployment Management

Service Level Management

Service Level Management Availability Management Capacity Management

Availability Management Capacity Management Financial Management for IT Services IT Service Continuity Management Security Management

Service Operation

Financial Management

Service Portfolio Management Demand Management

IT Service Continuity Management Information Security Management Service Catalogue Service Validation & Testing Management Supplier Transition Planning & Support Management Service Portfolio Knowledge Management Management

Access Management Event Management Request Fulfillment

The 7-step improvement process Service Measurement

Tabel 2-1 Verschilllen tussen ITILv2 en ITILv3 (L. Peeters, 2008)


18

2.2

Waar te beginnen

ITIL is een set van best practice aanbevelingen, die je kan aannemen en aanpassen zodat ze aan de specifieke ke wensen van je bedrijf voldoen. voldoen. Hierdoor kunnen bedrijven zich nog steeds richten op de elementen die voor hen het meest waardevol zijn. Pink Elephant (bedrijf dat ITIL introduceerde in Nederland) adviseert om ondanks de nieuwe lifecycle benadering van ITILv3 eerst de pijnpunten te analyseren en op basis van quick quick wins te beginnen met de implementatie van een aantal basisprocessen. basis Deze snelle verbeteringen zijn noodzakelijk om de motivatie op peil te houden (Peeters, 2003). Volgens (H. Kisters, 2003) wordt bij de inrichting van ITIL-processen processen vaak gestart met het Incident Management Proces. Het is een front-office proces ces dat wordt gezien als visitekaartje visite van het achterliggende IT-beheer IT omdat het erg zichtbaar is voor de business. business Hierdoor is de waarde van een goed Incident Management systeem eenvoudiger aan te tonen dan bij andere processen in de Service Operation. Verder kan het Incident Management Proces roces gebruikt worden om verbeterpunten van andere processen boven water te krijgen en te onderbouwen met data d (Commerce, 2007). In sectie 2.3 wordt de meerwaarde van een goed Incident Management Proces in het algemeen verder uitgewerkt en vervolgens zal in hoofdstuk 3 worden bekeken wat een verbeterd Incident Management Proces voor Grexx kan betekenen. betekenen 2.3

Incident Management

Het Incident Management Proces roces omvat de totale afhandeling van incidenten. incidenten Daarbij kan een incident worden gedefinieerd als een ongeplande interruptie of kwaliteitsreductie van een IT-dienst (Bon, 2007). Het doel van Incident Management is het zo snel mogelijk herstellen van de IT-service service ten einde de impact van het incident op de bedrijfsprocessen te minimaliseren. Een goed ingericht Incident Management Proces kan onder andere de volgende nde voordelen opleveren: • Betere en snellere afhandeling van incidenten. Dit zorgt voor een verminderde business impact door minder downtime en dus een hogere bereikbaarheid van de geleverde diensten. • Kostenreductie door het efficiënter inzetten van IT-medewerkers werkers in het kader van het Incident Management Proces. P • Betere managementinformatie doordat incidentenregistratie zinvolle rapportages oplevert. Een duidelijk overzicht van de incidenten en de data van de incidenten, geeft een goede basis voor verbeteringstrajecten. verbeterin Het is belangrijk dat voldoende rollen worden gespecificeerd om zodoende de verantwoordelijkheden duidelijk aan te geven. De verschillende rollen in het Incident Inc Management Proces roces zijn: de Incident Manager, Manager, eerste lijnmedewerkers (servicedeskmedewerker), medewerker), tweede lijnmedewerkers en bij grote organisaties N-de N lijnmedewerkers. De verantwoordelijkheden van de Incident Manager zijn: • De efficiëntie en effectiviteit van het proces bewaken en verbeteringen aandragen • Het leveren van managementinformatie management • Besturen van de werkzaamheden van de lijnmedewerkers • Het onderhouden van het incident management proces en ondersteunende systemen • Afhandelen van Major Incidenten Dennis van Roy (0491570) Incident Management in de GrexxBoxx

19

De verantwoordelijkheden van de eerste lijnmedewerkers variëren sterk per organisatie. Er kunnen niet-vakkundige mensen werken waarvan de werkzaamheden zich beperken tot het registreren van incidenten, toewijzen aan een oplosgroep, communiceren met de klant en het afsluiten van een incident. Vakkundig personeel kan werkzaamheden als classificatie, classificati oplossen van incidenten en het escaleren ervan voor zijn zijn rekening nemen. In hoofdstuk 4 wordt uitgelegd voor welke vorm bij Grexx wordt gekozen en wat de specifieke verantwoordelijkheden per rol zijn. Aan de hand van ITIL (Commerce, Commerce, 2007) zijn de volgende eigenschappen van belang om de efficiëntie en de effectiviteit van het Incident Management Proces de controleren: • Totaal aantal Incidenten • Aantal Incidenten per stadium • Totaal aantal Incidenten, en, onderverdeeld per categorieklasse categori • Gemiddelde doorlooptijd van incidenten, incidenten, onderverdeeld per prioriteitsklasse prioriteits en aangevuld met de spreiding. • Aantal en percentage incidenten opgelost binnen afgesproken tijd • Aantal en percentage incidenten dat heropend is • Aantal en percentage incidenten inciden dat verkeerd wordt toegewezen • Aantal en percentage incidenten dat verkeerd wordt gecategoriseerd • Aantal en percentage incidenten dat door de Servicedesk wordt opgelost zonder hulp van andere oplosgroepen De kritieke succesfactoren van Incident Management zijn (Commerce, 2007): 2007) • Servicedesk waarbij de rollen en verantwoordelijkheden duidelijk gespecificeerd zijn • Duidelijke doelen, die beschreven zijn in de Service Level Agreements (SLAs) • Klantgericht en goed onderlegd personeel personeel in alle stadia van het proces • Ondersteunende software om o het proces te begeleiden • Operational Level Agreements (OLAs) en Underpinning Contracts (UCs), die het handelen van het ondersteunend personeel bepalen Omdat een goede Servicedesk esk essentieel is voor voor het goed functioneren van een Incident Management Proces,, zal de afdeling servicedesk serviced in sectie 2.4 worden behandeld. 2.3.1 Verschil Incident Management in ITILv2 en ITILv3 Het Incident Management Proces van ITILv2 is in ITILv3 opgesplitst pgesplitst in twee processen, namelijk Incident Management en Request Fulfillment. De meldingen van beide processen process komen binnen via de servicedesk. serviced Bij Request Fulfillment betreft het echter geen acute verstoring van de dienstverlening. Het zijn verzoeken die in tegenstelling tot incidenten gepland kunnen worden afgehandeld. afgehandeld. Onder Service Requests vallen verschillende verzoeken van de gebruikers aan de IT-afdeling. IT afdeling. Over het algemeen zijn dit kleine veel voorkomende aanpassingen met lage risico’s zoals het wijzigen van een paswoord. Door het behandelen van deze verzoeken in een ander proces dan Incident Management, wordt het Incident Management Proces niet ‘vervuild’ met standaardverzoeken. In tegenstelling tot het proces Request Fulfillment is het h Incident Management Proces is namelijk niet bedoeld voor deze verzoeken en er ook o niet optimaal voor ingericht. Het doel van de Request Fulfillment is: (Commerce, 2007) • Het bieden van een kanaal voor gebruikers waar waar ze standaarddiensten standaard kunnen aanvragen en ontvangen Dennis van Roy (0491570) Incident Management in de GrexxBoxx

20

Het bieden van informatie aan gebruikers en klanten over de beschikbaarheid van diensten en de procedure om deze te verkrijgen • Het maken en leveren van v de componenten van standaarddiensten diensten • Het verschaffen van algemene informatie, informatie, helpen bij klachten of opmerkingen Verder is er bij het Incident Management Proces Proces een aparte procedure gemaakt voor de afhandeling van major incidenten. Dit zijn de incidenten met de hoogste impactcategorie en dus de hoogste prioriteit. Deze procedure procedure houdt rekening met kortere tijdslimieten, tijdslimieten een hogere urgentie en extra communicatie. communicatie •

Zowel bij de major incidenten als de service requests wordt gekozen voor een aparte afhandeling. Rationale hiervoor is dat bij major incidenten extra terugkoppeling naar de klanten en het management gewenst is. Verder heeft Grexx voor service requests al een apart proces ingericht dat afwijkt van het Incident Management Proces doordat deze verzoeken gefactureerd worden. Hierdoor nemen we het Incident Management Proces zoals het in ITILv3 is beschreven als leidraad. In Figuur 2-1 is dit Incident Management Proces weergegeven.


21

Figuur 2-1 ITILv3 Incident Management Proces


22

2.4

Servicedesk

In sectie 2.3 is behandeld dat een e servicedesk met duidelijk gespecificeerde rollen en verantwoordelijkheden essentieel is voor het optimaal functioneren van het Incident Management Proces. De servicedesk speelt een belangrijke rol in de ondersteuning van de klant en behandelt alle incidenten, ncidenten, serviceverzoeken en overige verzoeken die via telefoon, internet, mail e.d. binnenkomen. Verder dient de servicedesk esk als enige aanspreekpunt binnen organisaties voor ondersteuning van een ee geleverde dienst. Hierdoor is het belangrijk om bij het invoeren van een nieuw Incident Management Systeem te controleren of de servicedesk adequaat is ingericht. De verantwoordelijkheden woordelijkheden van de servicedesk serviced zijn volgens (L. Peeters, 2008) en (Bon, 2007): 2007) • Registratie van alle incidentincident en service request-details • Leveren van eerste rste lijnsonderzoek en diagnose • Escaleren scaleren van incidenten en service requests die niet binnen de afgesproken termijn (SLA) kunnen worden opgelost o • Oplossen en afsluiten van incidenten en service requests • Voortgangsbewaking naar eindgebruikers • Communicatie met eindgebruikers over de voortgang van incidenten en service requests • Klanttevredenheidsonderzoek en surveys houden Bovenstaande verantwoordelijkheden ordelijkheden geven duidelijk aan dat een groot deel van het Incident Management Proces zal worden uitgevoerd door de servicedesk esk en waarom de servicedesk esk voor het Incident Management Proces van belang is. Enkele voordelen van een goede servicedesk volgens (Commerce, 2007) zijn: • Verhoogde service en klanttevredenheid • Verbeterde bereikbaarheid door een duidelijk aanspreekpunt • Verbeterde en snellere afhandeling van incidenten en verzoeken • Verbeterde communicatie en teamwork • Verhoogde ogde proactieve benadering van de service voorziening • Verminderde negatieve business impact • Verbeterde informatievoorziening als basis voor beslissingen en verbetertrajecten Vanwege de importantie ie van de servicedesk voor het Incident Management Management Proces worden de rollen hieronder ook uitgewerkt. Behalve de in sectie 2.3 genoemde servicedeskmedewerker zijn ook de volgende rollen te onderscheiden bij en rond de afdeling servicedesk: Servicedesk esk Manager, Manager Servicedesk Supervisor en de Super Users (Commerce, 2007). De verantwoordelijkheden woordelijkheden van de Servicedesk Serviced Manager zijn: • Het besturen van alle servicedesk servicedesk activiteiten, inclusief de activiteiten van de Supervisor • Dienen als escalatiepunt voor de Supervisors • Bijwonen van bestuursvergaderingen bestuursvergaderingen over adviezen van wijzigingen • Verantwoordelijkheid nemen voor de afhandeling van alle incidenten incident en service requests bij de servicedesk serviced De verantwoordelijkheden woordelijkheden van de Servicedesk Serviced Supervisor zijn: • Zorg dragen n dat tijdens operationele uren de bezetting en kennis van het personeel voldoende is • Zorg dragen voor de uitvoering van het personeelsbeleid (indien nodig) nodig Dennis van Roy (0491570) Incident Management in de GrexxBoxx

23

Als eerste escalatiepunt dienen bij service requests of incidenten Maken van managementrapportages en statistieken De servicedesk esk vertegenwoordigen vertegenwoo bij vergaderingen Trainingen e.d. laten verzorgen voor servicedeskmedewerkers Samenwerken met senior management en change management Doorkoppelen van veranderingen ver e.d. aan de servicedeskmedewerkers medewerkers die impact kunnen hebben op het aantal meldingen • Bijstaan ijstaan van de eerste lijnmedewerkers bij drukte Super Users zijn gebruikers van de business die bijgeschoold worden om ondersteuning te bieden aan de IT-afdeling ing en in het bijzonder aan de servicedesk. servicedesk. Omdat de kennis van de business bij deze gebruikers zeer groot is, zijn ze een waardevolle aanvulling aanvull op de ITmedewerkers. De verantwoordelijkheden van de Super Users zijn: • Communicatie tussen IT en business vergemakkelijken • Het verduidelijken wat de verwachtingen zijn van de klant ten opzichte van de afgesproken sproken service levels • Trainen van medewerkers in hun expertisegebied • Ondersteuning bieden bij kleine incidenten en simpele service requests • Betrokkenheid bij nieuwe releases • • • • • •

Bij het ontwerp van het Incident Management Proces roces in hoofdstuk 4 worden ook de benodigde rollen voor de servicedesk serviced bepaald, om zodoende een goed functionerend Incident Management te verkrijgen. verkrijgen


24

3

Incident Management bij Grexx

In dit hoofdstuk wordt bepaald wat specifiek voor Grexx een goed Incident Management Proces inhoudt. Hierbijj worden de factoren gegeven die hiervoor van belang zijn en wordt op basis van deze factoren de huidige situatie nogmaals geëvalueerd. 3.1

Goed Incident Management voor Grexx

In de theoretische verdiepingg zijn de voordelen van een goed Incident Management Proces behandeld. De factoren die verbeterd kunnen worden zijn: snellere afhandeling incidenten, incidenten kostenreductie en verbeterde managementinformatie. managementinformatie De Kritieke ritieke Succes Factoren die voor Grexx expliciet van belang zijn, zijn Beschikbaarheid en Vertrouwen. Een snellere nellere afhandeling van incidenten komt de beschikbaarheid direct ten goede. Vertrouwen is echter lastiger te verbeteren aangezien dit een gevoel is dat klanten hebben. In de onderstaande lijst volgen aspecten die, met betrekking ing tot het Incident Management, Managemen de beschikbaarheid en het vertrouwen positief kunnen beïnvloeden. De lijst bestaat uit de aspecten die zijn behandeld in de theoretische verdieping, maar is bovendien nog aangevuld met aspecten die op basis van gesprekken met werknemers en het management van Grexx van belang zijn geacht. Deze aspecten zijn transparantie, transparantie overdraagbaarheid, en schaalbaarheid. Omdat de nadruk in dit project ligt op het ontwerpen en implementeren van het Incident Management Proces, zijn onderstaande staande punten niet getoetst met klanten en wordt aangenomen dat de kwaliteit van het Incident Management getoetst kan worden aan de hand van deze punten. Onderstaand worden de aspecten kort uitgewerkt: • Snelle reactie- en oplostijden: Resulteert esulteert in directe feedback, feedback wat het vertrouwen kan n vergroten en minder downtime voor klanten waardoor de beschikbaarheid wordt vergroot. vergroot • Klantinteractie: Duidelijk aanspreekpunt tijdens operationele uren neemt bezorgdheid voor incidenten weg. • Goede Documentatie:: Door goede documentatie en managementrapportages managementrapp kan op basis van historische gegevens worden aangetoond wat de beschikbaarheidniveaus in het verleden zijn geweest. Het tonen van historische historische gegevens kan bij goede resultaten leiden tot een groter vertrouwen. • Goede monitorring: Verhoogd de beschikbaarheid ikbaarheid doordat incidenten tijdig opgespoord en opgelost kunnen worden. Tevens kan een proactieve benadering het vertrouwen vergroten doordat incidenten opgelost kunnen worden alvorens de klant hinder heeft ondervonden. Ook kan een klant geïnformeerd worden worden alvorens zij de klacht ervaart. • Transparantie: Geeft eeft de klant inzicht in de voortgang van incidenten. incidenten Dit is een aspect die volgens Grexx extra van belang is voor een SaaS-leverancier leverancier omdat wordt aangenomen dat real-time time inzage in de incidentafhandeling, incidentafhandel het vertrouwen vergroot. • Overdraagbaarheid: Hierdoor kan het serviceniveau tijdens vakantieperiodes en ziektes gewaarborgd blijven, wat de beschikbaarheid vergroot. Het is ook belangrijk voor een klant dat zij niet afhankelijk zijn van één persoon voor voor de goede afhandeling van incidenten.


25

Schaalbaarheid: Zorgt dat bij groei de huidige serviceniveaus behouden kunnen blijven, blijven wat uiteindelijk positief is voor de beschikbaarheid en het vertrouwen. Voor Grexx is commercieel gezien kostenreductie natuurlijk jk ook een belangrijk aspect. Dit kan bereikt worden door de efficiëntie e in kwaliteitsgebruik te verbeteren zodat het h inzetten van gespecialiseerde dure werknemers op eenvoudige incidenten minder voorkomt. voorkomt •

3.2

Evaluatie Huidige Situatie

Er is in de huidige situatie ituatie geen documentatie van de incidenten waardoor er geen nulmeting kan worden gedaan om te bepalen hoe goed bepaalde factoren zoals reactietijden en oplostijden nu zijn. Op basis van feedback van klanten en de ervaring bij de servicedesk is bepaald dat in de huidige situatie zoals in sectie 1.3 is beschreven de volgende factoren met betrekking tot het Incident Management bij Grexx goed gaan: gaan • Vertrouwen van de Klant: is hoog mede door snelle en adequate reacties van consultants. • Reactietijd: is kort door 24-7 inzet van consultants. • Oplostijd: is kort door 24-7 inzet van consultants. • Klantinteractie: klant heeft 06-nummer 06 nummer van consultant. Hierdoor kan de klant altijd de consultant bereiken, wat positief is voor de beschikbaarheid d en het vertrouwen. Op basis van de klantcontact en de eigen inzichten op de servicedesk ervicedesk blijkt dat de d volgende aspecten nog niet goed gaan in de huidige situatie: • Documentatie: is nagenoeg niet aanwezig, dus geen rapportages en ook geen overzicht of SLA’ss worden gehaald. gehaal • Monitoring: er is geen totaalinzicht totaali in incidenten die spelen. • Efficiëntie ficiëntie in kwaliteitsgebruik: eenvoudige incidenten worden door inzet inze van dure consultants opgelost. • Transparantie: het communiceren van de status met de klant, gebeurt niet ni op structurele wijze. • Overdraagbaarheid verdraagbaarheid van de kennis: moeilijk door het gebrek aan documentatie en registratie. • Schaalbaarheid: omdat de huidige manier van werken erg ad hoc is, is de verwachting dat bij verdere groei de afhandeling te chaotisch wordt en de huidige klanttevredenheid zal afnemen doordat bovenstaande positieve punten hierdoor hie negatief worden beïnvloed. 3.3

Verscherpte definitie van de probleemstelling

Hoe kan Grexx het Incident Management Proces inrichten om bij verdere groei de factoren beschreven chreven in sectie 3.1 minimaal op hetzelfde niveau te houden. 3.3.1 Randvoorwaarden De randvoorwaarden van Grexx met betrekking tot de oplossing zijn: • Het ontwerp moet ITILv3 compliant worden ingericht. • Implementatie van de het Incident Management systeem geschiedt geschiedt in de GrexxBoxx. Dennis van Roy (0491570) Incident Management in de GrexxBoxx

26

3.4

Doelstelling

Het doel is het ontwerpen en implementeren van een Incident Management systeem voor Grexx ten einde bij verdere groei de factoren beschreven in sectie 3.1 minimaal op hetzelfde niveau te houden. Daartoe worden de volgende onderzoeksonderwerpen behandeld: • Bepalen welke versie van ITIL als leidraad dient voor het proces.. Om tot dit advies te komen wordt een literatuuronderzoek iteratuuronderzoek naar ITIL gedaan. • Bepalen op basis van welke welke factoren bepaald kan worden of het Incident Management nt Proces voldoet aan de verwachtingen. • Maken van een generiek Business Ontwerp inclusief besturing van het Incident Management Proces roces bij Grexx. • Ontwerp en beschrijving eschrijving van implementatieobjecten (case-objecten) die als bouwstenen dienen voor de implementatie implementa in de GrexxBoxx. • Implementatie van het ontwerp in de GrexxBoxx. • Onderzoeken of de GrexxBoxx een adequate ondersteuning biedt voor de implementatie van het Incident Management Systeem bij Grexx. Grexx


27

4

Business Ontwerp in het kader van Incident Management

Alss eerste zal de Governance Architectuur in het kader van Incident Management worden behandeld. Het doel hiervan is een generiek ontwerp te maken welke in de groeiscenario’s relevant blijft. De Governance Architectuur beschrijft de hiërarchische decompositie decompositi van een onderneming. Daarna zal de Business Architectuur in het kader van het Incident Management behandeld worden. Hierin wordt aangeven wat de onderlinge relaties zijn tussen de verschillende domeinen die in de Governance Architectuur zijn behandeld ten te einde te bepalen wat het doel van het domein is en welke aspecten ondersteund moeten worden door het platform.. Het Incident Management Platform (IMP) is het platform dat ontwikkeld en gebruikt wordt om het Incident Management Proces te ondersteunen. 4.1

Governance ernance Architectuur

In Figuur 4-1 is de Governance overnance Architectuur weergegeven. Hierin wordt aangegeven welke verschillende domeinen van toepassing zijn voor het ontwerp en hoe deze intern dan wel extern gelokaliseerd kunnen zijn. Dee Governance Architectuur is hier beperkt tot de domeinen die relevant zijn voor het Incident Management. Ook de partijen die nodig zijn voor de toekomstscenario’s zijn weergegeven. Deze partijen zijn dus niet in alle scenario´s noodzakelijk. Het IMPO-domein ein in de figuur staat voor het domein: Incident Management Proces Ontwerpers. Zoals aangegeven in de inleiding worden de de domeinen evenals de onderlinge relaties in sectie 4.2 verder uitgewerkt.

Figuur 4-1 Governance Architectuur

Om het ontwerp generiek te maken zijn een aantal ontwerpprincipes van belang: • Elke partij die configureert maakt gebruik van het Incident Management Platform om de Incidenten af te handelen.


28

•

• • •

Elke partijj die configureert heeft een Lokale GrexxBoxx Unit, dit houdt in dat zij de volgende domeinen moeten benoemen: o ‘GrexxBoxx Management’ o ‘Oplosgroep Configuratie’ o ‘GrexxBoxx Servicedesk’ GrexxBoxx Servicedesks van alle partijen rapporteren bevindingen aan het IMPOdomein. Een incident hoort altijd maar bij één GrexxBoxx Servicedesk, één Oplosgroep Configuratie en bij één domein GrexxBoxx Management. Een Gebruiker heeft contact met lokale GrexxBoxx Unit.

Het doel achter deze principes is de d schaalbaarheid van het ontwerp zodat het in alle drie de scenario´s toegepast kan worden. Verder V zorgt het gebruik van hetzelfde zelfde platform ervoor dat er een maximale case-base base ontstaat van incidentcases, incidentcase wat: • het delen van ervaringen mogelijk maakt doordat alle medewerkers toegang to hebben tot de cases. • een en positief effect heeft op het leerproces doordat IMPO door de grotere hoeveelheid gegevens een betere basis heeft voor procesverbetering. Ook de escalatie van incidenten naar andere oplosgroepen kan eenvoudig worden geregeld doordat oordat alle cases op dezelfde manier worden opgeslagen op hetzelfde systeem. De Software Groep is bij Grexx gelokaliseerd. Aangenomen wordt dat deze niet dusdanig in omvang gaat groeien dat deze gesplitst wordt. Huidige Situatie: Omdat er momenteel geen configuratiepartners zijn en de klant ook niet zelf configureert, vindt de incidentafhandeling grotendeels bij Grexx plaats. Alleen de oplosgroep Infrastructuur is extern gelokaliseerd. Configuratiepartner: In het geval er een configuratiepartner is, zal de lokale GrexxBoxx Unit zich bij de Configuratie Partner bevinden. Voor incidenten op GrexxBoxxen die zij hebben geconfigureerd, voeren zij alle taken van de Lokale GrexxBoxx unit uit.. Hierdoor is er bij elke incidentcase maar één lokale GrexxBoxx Unit betrokken. betrokken. Grexx zal bij een incident alleen betrokken worden als er escalatie naar de Software Groep plaatsvindt. Klant configureert zelf: In dit geval is de lokale GrexxBoxx Unit bij de klant gelokaliseerd. Hierdoor zal er voor de incidentafhandeling alleen een escalatie plaatsvinden naar de oplosgroep Infrastructuur en de Software Groep.


29

4.2

Business Architectuur

Als eerste worden alle partijen weergegeven die gebruik maken van het Incident Managementt Platform. Daarna zal voor elk van deze partijen de bijdrage bijdrag aan het Incident Management Proces en de communicatie met de andere partijen worden behandeld. Context van Incident Management Platform:

In de bovenstaande figuur zijn de partijen weergegeven die een relatie hebben met het Incident Management Platform. rm. In de pijlen is weergegeven of er één of meerdere gelijke partijen mogelijk zijn. In de volgende sectie worden de individuele partijen toegelicht.


30

4.2.1 Toelichting per partij in de context In deze sectie zal per partij een contextdiagram worden gegeven. Hierin erin wordt vanuit hun perspectief aangegeven hoe de communicatie verloopt met de andere partijen en wat deze communicatie inhoudt. In de onderstaande contextdiagrammen wordt gebruik gemaakt van twee soorten relaties. Dit zijn de samenwerkingsrelatie en de servicerelatie.. Bij de samenwerkingsrelatie werken de partijen samen aan een incidentcase en wordt door middel van rechten en plichten bepaald wie welke acties kan uitvoeren. Deze samenwerkingsrelatie zal door middel van een doorgetrokken pijl in de onderstaande onder diagrammen worden weergegeven. weergegeven In een servicerelatie zijn twee mogelijkheden qua communicatie: • De input wordt door de aanvrager naar de serviceverlener gestuurd en indien aanwezig wordt het resultaat als output teruggestuurd naar de aanvrager. • De serviceverlener krijgt ‘Read-Only’ ‘Read rechten op een case die via het platform benaderd kan worden.. De partij waarbij de communicatie alleen een servicerelatie betreft, wordt als een ‘Black‘Black Box’ weergegeven in de onderstaande contextdiagrammen en de relaties worden door een onderbroken pijl aangegeven. 4.2.1.1 Contract Partij Bijdrage: Controleren of de GrexxBoxx voldoet aan de verwachtingen en SLA’s.

Communicatie met GrexxBoxx Servicedesk: De GrexxBoxx Servicedesk is verantwoordelijk voor het leveren van de rapportages rapp aan de Contract Partij om de kwaliteeitt van de GrexxBoxx inzichtelijk te maken en te controleren of SLA’s in het geding komen. Dit wordt door het platform ondersteund door dashboards weer te geven met de desbetreffende informatie, waar de Contract Partij Partij ‘Read-Only’ ‘Read rechten op heeft. Het dashboard moeten tenminste de volgende informatie bevatten: Informatie:

Rationale:

Aantal gemelde incidenten (per prioriteitsklasse)

Dit geeft de Klant lant een totaaloverzicht van de hoeveelheid incidenten en kijk op de d kwaliteit van het product. De doorlooptijd geeft aan hoe adequaat Grexx omgaat met incidenten. Dit geeft de Klant inzicht in welke incidenten nog niet zijn opgelost. Door middel van de totale downtime kan o.a. bekeken worden of SLA’s zijn behaald.

Doorlooptijd van incidenten (per prioriteitsklasse) Openstaande Incidenten Totale downtime wntime (Som van de doorlooptijd van het aantal incidenten met prioriteitsklasse 1)


31

Bij deze dashboards moet het mogelijk zijn om de bijbehorende incidentcases te zien door deze op een grafiek te selecteren. Ook moet een individuele incidentcase geselecteerd kunnen worden om de specifieke casedata te bekijken. Er moet dus als het ware doorgeklikt kunnen worden op het platform naar de individuele cases. Deze eigenschap zal ook gelden voor alle dashboards die in het vervolg van dit hoofdstuk worden behandeld. 4.2.1.2 Gebruiker Bijdrage: Melden van Incidenten en indien nodig tijdig verstrekken van aanvullende informatie.. Verder zijn ze verantwoordelijk voor het tijdig beoordelen en accepteren van gereedmeldingen. Contextdiagram:

Communicatie met GrexxBoxx Servicedesk: De Gebruiker ebruiker kan een Incident melden bij de GrexxBoxx Servicedesk. Een incidentmelding moet hierbij ten minste bestaan uit de volgende gegevens: • Naam • Emailadres • Onderwerp • Omschrijving tijd te verkorten: De volgende gegevens kunnen ook worden toegevoegd om de oplostijd • Telefoonnummer • CaseId • Proces • URL • Bijlage (Screenshot o.i.d.) Een incident moet via het platform kunnen worden gemeld, maar de Gebruiker heeft ook de mogelijkheid heid om een incident via de telefoon en/of email aan de GrexxBoxx Servicedesk Serviced te melden. In deze gevallen zal de Servicedeskmedewerker het incident voor de Gebruiker aanmaken in de GrexxBoxx, op dezelfde manier als de gebruiker dit doet. De GrexxBoxx Servicedesk cedesk kan op deze manier alle acties voor de Gebruiker op het platform uitvoeren. Het aanmelden van een incident is een standaardactie die voor alle gebruikers hetzelfde zal zijn. Als het incident direct op het platform wordt aangemeld door de gebruiker wordt w er een automatisch gegenereerde email gestuurd naar de GrexxBoxx Servicedesk met de gegevens van het incident en een URL naar de desbetreffende melding. Buiten kantoortijden wordt dit ondersteund door een SMS-bericht bericht als een incident is aangemeld zodatt incidenten met hoge prioriteit altijd opgemerkt worden. Dennis van Roy (0491570) Incident Management in de GrexxBoxx

32

Het is mogelijk dat een incident onterecht als incident is gemeld. In dit geval zal na de registratie van een incident een automatische mail naar de Gebruiker worden gestuurd waarin dit wordt medegedeeld. deeld. Dit bericht bevat tevens de reden van de omzetting. De Gebruiker zal moeten bevestigen of dat zij akkoord gaat met de omzetting. Als de gebruiker akkoord is, zal de case automatisch worden afgesloten en zal een serviceverzoekcase s worden gestart. Als de gebruiker niet akkoord gaat, zal hiervoor de reden moeten worden gegeven en zal het incident opnieuw beoordeeld en geregistreerd moeten worden. De gegevens die benodigd zijn voor de registratie worden hierbij automatisch ingevuld op basis van de eerder ingevulde gegevens en kunnen worden gewijzigd. Hierdoor hoeft niet de gehele data opnieuw te worden ingevoerd. ingevoerd De Gebruiker kan ook via het platform op een case aanvullende informatie geven. Dit kan uit zichzelf of als er aanvullende informatie wordt gevraagd. aagd. De aanvullende informatie die de gebruiker kan geven is: • Aanvulling op incidentmelding in een tekstveld • Extra document Ook hierbij is het mogelijk dat dit via de telefoon en/of en/of email wordt gecommuniceerd en de GrexxBoxx Servicedesk de registratie op het platform voor zijn rekening neemt. oplossing De Gebruiker zal geïnformeerd worden door de GrexxBoxx Servicedesk over de oplossing. Een oplossing van een incident bestaat altijd uit de volgende gegevens: • oorzaak orzaak van het probleem • de stappen die zijn genomen om het het incident te verhelpen en wanneer van toepassing ook de stappen die onnodig zijn doorlopen, zodat er geleerd kan worden van eerdere fouten • eventueel ventueel een bijlage voor aanvullende informatie (denk hierbij aan queries om het probleem te verhelpen of documenten waar achtergrondinformatie informatie in staat). Van bovenstaande informatie worden alleen de oorzaak orzaak en de stappen die zijn doorlopen om het incident te verhelpen aan de Gebruiker medegedeeld. De Gebruiker kan een gemeld incident ook altijd voortijdig afsluiten. Dit om te voorkomen dat er onnodig tijd gestoken wordt in een melding die achterhaald of onterecht blijkt te zijn. Hiervoor moet altijd een reden worden gegeven en n dit wordt via een automatisch gegenereerde email gemeld aan de GrexxBoxx Servicedesk en eventueel eventueel aan de oplosgroep die bij het incident is betrokken. Verder wordt in de data bijgehouden op wiens initiatief een incident voortijdig is gesloten, zodat hier altijd een overzicht van is. Als een incident is opgelost, moet de oplossing altijd door de Gebruiker aan de GrexxBoxx Servicedesk worden bevestigd alvorens een incident daadwerkelijk wordt afgesloten. Als een Gebruiker akkoord is, wordt het incident automatisch afgesloten. Wanneer dit niet het geval is wordt hiervan de reden gevraagd en zal het incident opnieuw beoordeeld en geregistreerd moeten worden door de GrexxBoxx Servicedesk. De reden hiervoor is dat het incident waarschijnlijk onjuist is ingeschat waardoor de gegevens van de registratiestap opnieuw geëvalueerd dienen te worden.


33

De Gebruiker wordt door de GrexxBoxx Servicedesk op de hoogte wordt gehouden van de voortgang van de incidenten. Dit wordt onder andere gedaan door automatisch gegenereerde mails vanuit het platform wanneer een incident is geregistreerd en zodra een incident is opgelost. pgelost. De automatisch gegenereerde mail na de registratie bevat de volgende informatie: • Id • Naam Melder • Email Melder • Telefoonnummer Melder • Onderwerp • Omschrijving • Prioriteit • Status • Link naar de incidentcase op de GrexxBoxx De Gebruiker kan ook tussendoor extra extra geïnformeerd worden door de GrexxBoxx Servicedesk. Hierbij wordt vanaf het platform een emailbericht verstuurd met de volgende gegevens: • Id • Informatiegegevens • Link naar de incidentcase op de GrexxBoxx De gebruiker moet via het platform toegang hebben tot de eigen incidentcases. Dit vergroot de transparantie en geeft de Gebruiker altijd de gelegenheid om te controleren wat de status van de melding is. Hiervoor moet de status en de historie altijd ‘real-time’ ‘real bekeken kunnen worden.. De gegevens die de Gebruiker Geb per case minimaal moet kunnen zien zijn: • Naam melder • Email Melder • Telefoonnummer Melder • Onderwerp • CaseId (indien bekend) • Omschrijving • Prioriteit • Diagnose • Status • Oorzaak (indien bekend) • Oplossing (indien bekend) • Historie (Welke handelingen zijn wanneer er en door welke partij uitgevoerd)

Communicatie met het GrexxBoxx Management: De Gebruiker moet een incident kunnen escaleren naar het GrexxBoxx Management. Dit in het geval dat de klant niet tevreden is over de afhandeling van het incident. Hiervoor dient een reden gegeven te worden en eventueel de gewenste actie. Deze activiteit initieert een automatische tische emailmelding naar het GrexxBoxx Management met de gegevens van de escalatie en een link naar de incidentcase. incidentcase Verder kan het GrexxBoxx Management op elk moment de klant informeren over een incidentcase.


34

4.2.1.3 GrexxBoxx Servicedesk Bijdrage: Het zo goed en snel mogelijk (laten) afhandelen van incidenten. Hiervoor zijn zij verantwoordelijk voor oor de registratie, eerstelijnsonderzoek, eerstelijnsonderzoek, de initiële diagnose en het he afsluiten van incidenten. Verder zijn zij verantwoordelijk voor de voortgangsbewaking van incidenten en de communicatie naar eindgebruikers. Contextdiagram:

Communicatie met Contract Partij: De GrexxBoxx Servicedesk is verantwoordelijk voor het leveren leveren van de rapportages aan de Contract Partij. artij. De Servicedesk zal deze middels dashboards beschikbaar stellen, waar de Contract Partij ‘Read-Only’ Only’ rechten op heeft. De informatie die het dashboard moet bevatten is reeds bij de ‘Contract Partij’ besproken. Communicatie met Gebruiker: De GrexxBoxx Servicedesk ontvangt een Incident via de email en/of telefoon van een Gebruiker. Dee Servicedeskmedewerker maakt het incident namens de Gebruiker aan op het platform.. De GrexxBoxx Servicedesk communiceert verder de oorzaak o en oplossing met de Gebruiker en zal ook als contactpersoon dienen voor aanvullende informatie. De GrexxBoxx Servicedesk is er tevens verantwoordelijk voor dat de Gebruiker op de hoogte wordt gehouden van de voortgang van de incidenten. Dit wordt ondersteund ndersteund op het platform door een automatisch gegenereerde email aan de Gebruiker wanneer een incident is geregistreerd en als een incident is opgelost. Het registreren van een incident is de eerste Dennis van Roy (0491570) Incident Management in de GrexxBoxx

35

stap die wordt genomen in het proces na het starten van een case. Na de registratie wordt de gebruiker automatisch gemeld dat de melding in behandeling is genomen. De deadline voor deze reactietijd wordt op basis van het SLA bepaald. Als deze niet is gespecificeerd wordt een standaard reactietijd van 1 uur genomen. gen Voor het registreren van een incident worden de gegevens van de melding aangevuld met de volgende gegevens: • Serviceverzoek: Hier wordt aangegeven of de melding terecht als incident is aangemeld of dat de melding een serviceverzoek betreft dat gefactureerd gefactu kan worden. In het geval dat een melding een serviceverzoek betreft, wordt er een automatisch gegenereerde mail naar de Gebruiker gestuurd ter bevestiging dat dit juist is. Bij de context van de Gebruiker is dit in meer detail behandeld. • Categorie: De verschillende categorieën die bij de incidenten worden onderscheiden zijn: Software, Software Hardware en Infrastructuur.. Door middel van de rapportages aan IMPO kan periodiek periodiek worden bekeken of er voldoende categorieën zijn en of dat de verdeling nog adequaat is. is • Bekend probleem: Hier wordt aangegeven of de oorzaak van het incident een bekend probleem is. Als dit het geval is, kan op basis van voorgedefinieerde problemen worden geselecteerd welk probleem het betreft. De diagnose en oplossing wordt dan automatisch automatis ingevuld, zodat de servicedeskmedewerker de stappen in de oplossing kan volgen en zonder hulp van andere oplosgroepen het incident kan oplossen. • Prioriteit: Voor de prioritering van de incidenten wordt onderscheid gemaakt in 3 prioriteitsklassen. De oplostijden op worden op basis van de SLA’s bepaald. Indien deze (nog) niet gespecificeerd zijn in het systeem worden de volgende oplostijden gebruikt: Prioriteit 1: < 2 uur Prioriteit 2: < 3 dagen Prioriteit 3: wordt in samenspraak met de Gebruiker gepland Alss een incident de prioriteit 1 krijgt zal, zoals in ITIL is beschreven, een aparte afhandeling volgen. Dit houdt in dat er een automatische escalatie naar het management plaats vindt en zal er extra terugkoppeling naar de klant zijn. Verder verloopt het proces hetzelfde als andere incidenten. In onderstaande schema worden de prioriteitsniveaus verder uitgewerkt. Impact: Prioriteit 1: Kritiek Incident

Prioriteit 2: Niet Kritiek Generiek Incident

Omschrijving: Omschrijving Eén of meer van de volgende gevallen is waar: • Utility of Dienst van Afnemer is niet beschikbaar. • Er is een directe bedreiging voor Veiligheid, Integriteit of Privacy. Het Incident In is niet kritiek en generiek: • Incident heeft betrekking op de functionaliteit of performance voor een groep gebruikers. • Utility of Dienst is beschikbaar maar gebruikers ervaren ongemak.

Actie: Het Incident wordt onmiddellijk behandeld en er vindt automatische escalatie naar het GrexxBoxx Management plaats.

In samenspraak met gebruiker wordt nadere actie gepland. Afhankelijk elijk van de mate waarin de productiviteit wordt beïnvloed zal een work--around voor het Incident worden gezocht of zal het aan Incident ten grondslag liggende Probleem worden verholpen.


36

Prioriteit 3: Niet Kritiek Specifiek Incident

Het Incident is niet kritiek en specifiek: • Incident heeft betrekking op de functionaliteit of performance voor specifieke gebruikers. gebruikers • Utility of Dienst is beschikbaar maa specifieke gebruikers maar ervaren ongemak.

In samenspraak met gebruiker wordt nadere actie gepland. Afhankelijk jk van de mate waarin de productiviteit wordt beïnvloed zal een work--around voor het Incident worden gezocht of zal het aan Incident ten grondslag liggende Probleem in de eerstvolgende productierelease worden verholpen.

De Servicedeskmedewerkers beslissen naar aanleiding van een melding wat de prioriteit van een incident is. Als een deadline is verstreken zal er een automatische escalatie naar het GrexxBoxx Management plaatsvinden door een geautomatiseerd emailbericht. Dit bericht heeft dezelfde inhoud als als de andere escalatieberichten. • Diagnose: Hier kan een initiële diagnose beschreven worden in een tekstveld. • Oplosgroep: Hier wordt geselecteerd wie vermoedelijk voldoende kennis bezit om het incident op te lossen. De verschillende groepen zijn: GrexxBoxx GrexxBox Servicedesk, Oplosgroep Configuratie, Software Groep of Oplosgroep Infrastructuur. De diagnose en oplossing worden gecommuniceerd naar de Gebruiker middels een automatische emailmelding als deze door de GrexxBoxx Servicedesk worden geregistreerd. ge De GrexxBoxx xxBoxx Servicedesk heeft verder nog de mogelijkheid om de Gebruiker extra te informeren en kan de taken die de Gebruiker kan uitvoeren op het platform overnemen indien de klant dit niet zelf wenst te doen. Op initiatief van de Gebruiker kan de GrexxBoxx Servicedesk rvicedesk ook een incidentcase heropenen als blijkt dat het incident niet naar tevredenheid van de Gebruiker is opgelost. Hiervoor zijn de volgende gegevens van belang: • Reden heropenen • Prioriteit • Oplosgroep die het incident in behandeling moet nemen Bij hett heropenen van een incident worden de deadlines weer opnieuw ingesteld aan de hand van de prioriteit. De GrexxBoxx Servicedesk kan op initiatief van de Gebruiker of uit zichzelf gegevens van een incident wijzigen. Dit om foutieve gegevens aan te passen of of om de gegevens aan te vullen. Hiervoor dient altijd een reden te worden gegeven. Bij het wijzigen van de incidentgegevens kan de volgende data worden aangepast: • Naam melder • Email melder • Telefoonnummer melder • Onderwerp • CaseId • Proces • Omschrijving • URL • Categorie • Diagnose • Oplossing


37

Communicatie met Oplosgroep Configuratie: Een incident kan worden doorgezet naar de Oplosgroep Configuratie, als de GrexxBoxx Servicedesk onvoldoende kennis bezit om het incident op te lossen en verwacht wordt dat het incident wordt ordt veroorzaakt door een configuratiefout. De servicedeskmedewerker zal dit aangeven door in het registratieformulier de Oplosgroep ‘Configuratie’ te selecteren. Het platform zal vervolgens automatisch een vervolgtaak voor de Oplosgroep Configuratie klaar klaa zetten om de casedata in te zien en de toewijzing al dan niet te accepteren. Als een toewijzing niet wordt geaccepteerd, moet worden aangegeven wat hiervan de reden is en moet het incident worden toegewezen aan een andere oplosgroep. Als een toewijzing wel w wordt geaccepteerd kan de Oplosgroep vervolgens een oplossing registreren en terugkoppelen naar de GrexxBoxx Servicedesk. Dit wordt ondersteund ondersteun op het platform door bij het invullen van een oplossing automatisch een vervolgtaak voor de GrexxBoxx Servicedesk klaar te zetten met de betreffende gegevens en de mogelijkheid om dit terug te koppelen naar de Gebruiker. Omdat de GrexxBoxx Servicedesk verantwoordelijk is voor de voortgang van incidenten zal tijdens het gehele proces de mogelijkheid bestaan om incidenten identen toe te wijzen aan een (andere) oplosgroep. Communicatie met Oplosgroep Infrastructuur: Een incident kan worden doorgezet naar de Oplosgroep Infrastructuur als de GrexxBoxx Servicedesk onvoldoende kennis bezit om het incident op te lossen en verwacht verwac wordt dat het incident wordt veroorzaakt door de beschikbaarheidsproblemen van de servers waarop de GrexxBoxx staat. Omdat dit een externe oplosgroep betreft, die niet op het platform participeert, is dit aangegeven in een servicerelatie. Als vermoed wordt rdt dat de oorzaak van een incident bij de oplosgroep infrastructuur ligt, zal het incident worden aangenomen door de GrexxBoxx Servicedesk. De reden hiervoor is dat de verantwoordelijkheid van de voortgang van incidenten bij de GrexxBoxx Servicedesk ligt en zij hierdoor zicht hebben op de incidenten die uitstaan bij een externe partij. Als een incident in behandeling is door de GrexxBoxx Servicedesk moet er altijd een mogelijkheid zijn om deze door te zetten naar de oplosgroep infrastructuur. Dit wordt doorr het platform ondersteund door een automatisch gegenereerde mail naar deze oplosgroep te sturen. sturen De oplossing die wordt gecommuniceerd gecommu via mail en/of telefoon zal door de GrexxBoxx Servicedesk worden genoteerd op het platform. Hiervoor zal een verslag van het gesprek of de inhoud van de mail ingevuld worden in een formulier op het platform. Ook tussentijdse ussentijdse communicatie dient door de Servicedeskmedewerker te worden bijgehouden op het platform. Het platform moet hiervoor ondersteunen dat emails als bestand aan een case worden toegevoegd. Alleen de GrexxBoxx Servicedesk kan incidenten escaleren naar de oplosgroep Infrastructuur. Ook als een andere oplosgroep verwacht dat het incident wordt veroorzaakt door de infrastructuur, zal de escalatie via de GrexxBoxx Servicedesk moeten verlopen. Hierdoor verloopt communicatie naar een externe partij altijd via de GrexxBoxx Servicedesk. Communicatie met Software Groep: Een incident kan worden doorgezet naar de Software Groep als de GrexxBoxx Servicedesk te weinig kennis bezit om het incident op te lossen en verwacht wordt dat een fout in de Software de oorzaak is voor het incident. De servicedeskmedewerker zal dit aangeven door in het registratieformulier als Oplosgroep ‘Software’ te selecteren. Het platform moet vervolgens automatisch matisch een vervolgtaak voor de Software Groep klaar zetten om de casedata in te zien en de toewijzing al dan niet te accepteren. Als een toewijzing niet wordt Dennis van Roy (0491570) Incident Management in de GrexxBoxx

38

geaccepteerd, moet worden aangegeven wat hiervan de reden is en moet het incident worden n toegewezen aan een andere oplosgroep. Als een toewijzing wel wordt geaccepteerd kan de oplosgroep vervolgens een oplossing terugkoppelen naar de GrexxBoxx Servicedesk. Dit moet ondersteund worden door het platform door bij het invullen van een oplossing automatisch een vervolgtaak voor de GrexxBoxx Servicedesk klaar te zetten met de betreffende gegevens en de mogelijkheid om dit terug te koppelen naar de Gebruiker. Communicatie met Incident Management Proces Ontwerpers (IMPO): De GrexxBoxx Servicedesk is verantwoordelijk voor rapportages aan IMPO. Deze rapportages dienen als input voor het leerproces zodat IMPO het proces en systeem kan analyseren en waar nodig verbeteren. Het platform ondersteunt dit door dashboards ter beschikking te stellen voor IMPO. Het dashboard moet tenminste de volgende informatie bevatten: Informatie:

Rationale:

Totaal aantal Incidenten, onderverdeeld Hierdoor kan gecontroleerd worden of de per prioriteitsklasse en categorieklasse categorie onderverdeling in categorieën nog adequaat is. Aantal openstaande Incidenten per status Dit geeft inzicht of er een mogelijke bottleneck is in de incidentafhandeling. Gemiddelde emiddelde oplostijd en spreiding van Dit geeft inzicht welke type incidenten meer tijd incidenten per categorie en prioriteit vergen om m opgelost te worden. Hierdoor kunnen bottlenecks worden ontdekt en kan het proces en/of systeem gerichter worden verbeterd. Aantal incidenten dat heropend is Dit geeft inzicht in de kwaliteit van de oplossingen. Op basis van deze gegevens kan bijvoorbeeld eeld bepaald worden of extra uitleg bij de taken nodig is. Aantal en percentage incidenten dat Op basis van deze gegevens kan bijvoorbeeld verkeerd wordt toegewezen bepaald worden of instructies bij de taken onduidelijk zijn. Aantal en percentage incidenten incid dat Op basis van deze gegevens kan bijvoorbeeld verkeerd wordt gecategoriseerd bepaald worden of instructies bij de taken onduidelijk zijn. Om het IMPO een volledig inzicht te geven in i de activiteiten die op een case uitgevoerd zijn, is het van belang dat zij volledige audit trails kunnen inzien. Dee dashboards en de audit trails bieden een goede basis voor verbeteringen. Communicatie met Collega GrexxBoxx Servicedesks: In het geval er configuratiepartners zijn of klanten zelf processen configureren, zijn er meerdere GrexxBoxx Servicedesks. Voor de incidentafhandeling van een case, is er altijd maar één GrexxBoxx Servicedesk verantwoordelijk, maar er kan wel communicatie onderling plaatsvinden om kennis over te dragen. Het platform kan dit ondersteunen ondersteune door middel van een chat op een case tussen de Servicedesks. Chat via het platform heeft als voordeel dat de communicatie wordt opgeslagen bij een case, waardoor geen informatie verloren gaat. De chat kan vanuit elke incidentcase worden geopend.


39

Communicatie nicatie met GrexxBoxx Management: De GrexxBoxx Servicedesk is verantwoordelijk voor het beschikbaar stellen van rapportages ten behoeve van het GrexxBoxx Management. Hierdoor heeft het management overzicht op de kwaliteit van de dienstverlening en op het behalen behalen van de SLA’s. Het platform ondersteunt dit door Dashboards beschikbaar te stellen voor het GrexxBoxx Management. Deze Dashboards moeten tenminste de volgende informatie bevatten: Informatie:

Rationale:

Het et aantal gemelde incidenten (per prioriteitsklasse sklasse en categorieklasse)

Geeft een totaaloverzicht van de hoeveelheid incidenten en dus indirect de kwaliteit van het product. Geeft het management inzicht in de openstaande incidenten, zodat het management op de hoogte is als er contact is tussen het management en de Contract Partij en wanneer nodig is overzicht heeft op de incidenten en kan interveniëren. De doorlooptijd geeft aan hoe adequaat er omgegaan wordt rdt met incidenten. Geeft het management inzicht in de kwaliteit van de medewerkers. Geeft het management inzicht in de kwaliteit kwali van de medewerkers. Geeft het management inzicht in de totale kwaliteit van de oplossingen. Geeft het management ent inzicht of SLA’s in het geding komen.

Openstaande incidenten

Doorlooptijd van incidenten (per prioriteitsklasse en categorieklasse) Aantal en percentage incidenten dat verkeerd wordt toegewezen Aantal en percentage incidenten dat verkeerd wordt gecategoriseerd Aantal en percentage incidenten dat heropend is Totale downtime (Som van de doorlooptijd van het aantal incidenten met prioriteitsklasse 1)

Bovenstaande informatie kan door het GrexxBoxx Management opgevraagd worden per GrexxBoxx of als overkoepelend dashboard met een totaaloverzicht van de geaccumuleerde incidentgegevens van al hun klanten. Verder iss het GrexxBoxx Management de uiterste escalatiemogelijkheid van de GrexxBoxx Servicedesk. Het platform ondersteunt dit door automatische escalatieberichten te genereren als deadlines niet gehaald worden. De escalatie kan ook geïnitieerd worden op het platform form door medewerkers als er bijvoorbeeld conflicten ontstaan. Deze taak moet tijdens het hele proces door alle medewerkers uitgevoerd kunnen worden. Een escalatiebericht naar het GrexxBoxx Management bevat de volgende informatie: • Naam melder • Reden escalatie • Link naar de incidentcase case Op het platform is voor de GrexxBoxx Management altijd een mogelijkheid om te interveniëren. Dit wordt mogelijk gemaakt door de link naar de case in het escalatiebericht te volgen, maar dit kan ook door via de dashboards naar de de desbetreffende case te gaan. Op een case is altijd een interventietaak aanwezig voor de manager. Deze interventietaak genereert een automatische email naar de persoon die het incident dient te behandelen. behandelen De taak behoeft de volgende informatie: Dennis van Roy (0491570) Incident Management in de GrexxBoxx

40

• Email geadresseerde(n) dresseerde(n) • Reden interventie • Link naar de desbetreffende case Een meer directe vorm van interventie is voor het GrexxBoxx Management mogelijk door een incident dat al in behandeling is toe te wijzen aan een andere oplosgroep. Hiervoor zal een reden gegeven ven moeten worden en deze actie initieert een automatisch emailbericht naar de betreffende oplosgroepen met de reden van interventie en een link naar de case. Om het GrexxBoxx Management een volledig inzicht te geven in de activiteiten die op een case uitgevoerd evoerd zijn is het van belang dat zij volledige audit trails kunnen inzien. Deze audit trails bieden een goede basis om te onderzoeken of eventuele fouten zijn gemaakt en waar verbeteringen mogelijk zijn. Communicatie met Algemeen Management: De Servicedesk esk is verantwoordelijk voor de rapportages voor het Algemeen Management. Dit betreft een Servicerelatie want het Algemeen Management kan niet participeren op de case. Het platform ondersteunt dit door Dashboards beschikbaar te stellen voor het Algemeen Management. nagement. De informatie die de dashboards moet bevatten is gelijk aan de Dashboards van het GrexxBoxx Management. 4.2.1.4 Oplosgroep Configuratie Bijdrage: Tweedelijns onderzoek van incidenten die te wijten zijn aan configuratiefouten. Dit betekent zowel het oplossen van incidenten als de registratie van de diagnose en oplossing in het systeem. Verder hebben zij ook de mogelijkheid om incidenten te melden die nog niet door klanten zijn opgemerkt. Contextdiagram:

Communicatie met GrexxBoxx Servicedesk: Een incident ent kan geëscaleerd worden door de GrexxBoxx Servicedesk naar de Oplosgroep Configuratie als er specifieke kennis is vereist van de configuratie. De Oplosgroep Configuratie kan een incident melden bij de GrexxBoxx servicedesk en een oplossing terugmelden aan an de GrexxBoxx Servicedesk. De details van deze communicatie en hoe dit wordt ondersteund door het platform is behandeld bij het GrexxBoxx Servicedesk domein. Dennis van Roy (0491570) Incident Management in de GrexxBoxx

41

Een Incident kan ook weer teruggezet worden naar de Servicedesk als de Oplosgroep Configuratie van an mening is dat met behulp van extra informatie de Servicedesk het incident op kan lossen. Communicatie met Software Groep: De Oplosgroep losgroep Configuratie kan een incident doorverwijzen naar de Software Groep als deze verwacht dat een incident het gevolg is van een fout in de Software. Bij het doorverwijzen van een incident moet altijd de reden worden beschreven waarom het incident verwezen wordt naar een andere oplosgroep. Het platform ondersteunt dit door na het toewijzen aan een andere oplosgroep osgroep een vervolgtaak vervo voor de Software Groep klaar zetten om de casedata in te zien en de toewijzing al dan niet te accepteren. Als een toewijzing niet wordt geaccepteerd, moet worden aangegeven wat hiervan de reden is en moet het incident worden toegewezen aan een andere andere oplosgroep. Als een toewijzing wel wordt geaccepteerd kan de oplosgroep vervolgens een oplossing terugkoppelen naar de GrexxBoxx Servicedesk. Communicatie met Collega Oplosgroepen Configuratie: In het geval er configuratiepartners zijn of klanten zelf processen configureren, zijn er meerdere Oplosgroepen Configuratie. Om kennis over te dragen wordt onderling contact tussen deze Oplosgroepen ondersteund op het platform door middel van een chat op een case tussen de Oplosgroepen. Hierdoor wordt de communicatie communicatie ook opgeslagen bij een case, waardoor geen informatie verloren gaat. De chat kan vanuit elke incidentcase worden geopend. Communicatie met het GrexxBoxx Management: De Oplosgroep Configuratie kan een incident escaleren naar het GrexxBoxx Management. Het GrexxBoxx Management kan via interventie een bericht sturen naar de oplosgroep of een incident toewijzen aan deze oplosgroep. De escalatie en interventie zijn in meer detail behandeld bij de GrexxBoxx Servicedesk. 4.2.1.5 Oplosgroep Infrastructuur Bijdrage: Tweedelijns onderzoek van incidenten die te wijten zijn aan de infrastructuur bij de Service Provider. Dit betekent zowel het oplossen van incidenten als het terugkoppelen van de oorzaak en oplossing van het incident. Contextdiagram:


42

Communicatie met GrexxBoxx Servicedesk: Een incident kan worden doorgezet naar de Oplosgroep Infrastructuur, als in de GrexxBoxx Servicedesk groep te weinig kennis is om het incident op te lossen en verwacht wordt dat het incident wordt veroorzaakt door een fout bij de Service Provider. De servicedeskmedewerker zal dit aangeven door het incident toe te wijzen aan deze oplosgroep. Het platform zal vervolgens automatisch een mail sturen naar de Service Provider en een vervolgtaak voor de GrexxBoxx Servicedesk klaar zetten zette om de oplossing van de Service Provider vast te leggen in het systeem. Omdat het een servicerelatie betreft, moet dit door de servicedeskmedewerker servicedeskmedewerker worden opgeslagen in het systeem. De automatisch gegenereerde mail bevat de volgende input: • Id • Onderwerp • Omschrijving De oplosgroep Infrastructuur communiceert vervolgens via email of telefoon de oplossing en de oorzaak ak aan de GrexxBoxx Servicedesk. De GrexxBoxx Servicedesk kan deze oplossing door middel van de taak die klaar staat noteren bij de case. 4.2.1.6 Software Groep Bijdrage aan het Proces: Tweedelijns onderzoek van incidenten die te wijten zijn aan fouten in de software. Dit betekent zowel het oplossen van incidenten als de registratie van de diagnose en oplossing in het systeem. Verder hebben zij ook de mogelijkheid lijkheid om incidenten te melden die nog niet door klanten zijn opgemerkt. Contextdiagram:

Communicatie met GrexxBoxx Servicedesk: De Software Groep krijgt incidenten van de GrexxBoxx Servicedesk toegewezen als de Servicedesk onvoldoende kennis heeft om het incident op te lossen en verwacht wordt dat een incident het gevolg is van een fout in de Software. Bij het doorverwijzen doorverwijze van een incident moet altijd worden beschreven waarom het incident verwezen wordt naar de oplosgroep. Een Incident kan ook weer teruggezet worden naar de Servicedesk als met Dennis van Roy (0491570) Incident Management in de GrexxBoxx

43

behulp van extra uitleg deze voldoende informatie heeft om het incident op te lossen. Het platform ondersteunt dit door na het toewijzen aan een oplosgroep een vervolgtaak klaar te zetten voor deze oplosgroep zodat z deze verder kan werken aan de case. Communicatie met Oplosgroep Configuratie: De Software Groep kan een incident doorverwijzen naar de Oplosgroep Configuratie als deze verwacht dat een incident het gevolg is van een fout in de Configuratie. Bij het doorverwijzen oorverwijzen van een incident moet altijd worden beschreven waarom het incident verwezen wordt naar de oplosgroep. Communicatie met het GrexxBoxx Management: De Software Groep kan een incident escaleren naar het GrexxBoxx Management. Het GrexxBoxx Management ment kan via interventie een bericht sturen naar de oplosgroep of een incident toewijzen aan deze oplosgroep. De escalatie en interventie zijn in meer detail behandeld bij de GrexxBoxx Servicedesk. 4.2.1.7 Incident Management Proces Ontwerpers (IMPO) Bijdrage: Ontwerpen twerpen en optimaliseren van het Incident Management Proces en ontwerpen en leveren van het platform ter ondersteuning van dit proces. Contextdiagram:

Communicatie met Algemeen Management: Het IMPO ontvangt van het Algemeen Management een set van requirements rements waaraan het procesontwerp ontwerp moet voldoen. Voorbeelden hiervan worden bij de contextdiagram van het Algemeen Management gegeven. Communicatie met GrexxBoxx Management: IMPO levert aan het GrexxBoxx Management het proces en de ondersteunende tools (platform) latform) om de incidentafhandeling te ondersteunen. Dennis van Roy (0491570) Incident Management in de GrexxBoxx

44

Communicatie met GrexxBoxx Servicedesk: IMPO krijgt rapportages van de GrexxBoxx Servicedesk. Servicedesk. Deze rapportages dienen als input voor het leerproces zodat IMPO het proces en systeem kan analyseren en waar wa nodig verbeteren. Het platform ondersteunt dit door dashboards ter beschikking te stellen voor IMPO. De eisen aan het dashboard worden bij de GrexxBoxx Servicedesk behandeld. 4.2.1.8 GrexxBoxx Management Bijdrage: Controleren of de incidentafhandeling goed verloopt verloopt en wanneer nodig tijdig interveniëren om problemen te voorkomen. Ze dienen ook als escalatiepunt voor de GrexxBoxx Servicedesk en de oplosgroepen. Het et GrexxBoxx Management is ook verantwoordelijk voor de bezetting van de GrexxBoxx Servicedesk en de Oplosgroep plosgroep Configuratie. Behalve voor het zorgen van voldoende capaciteit zijn ze ook verantwoordelijk voor de kwaliteit en kennis van de medewerkers. Omdat hier in de nabije toekomst geen problemen worden verwacht, ligt dit niet in de scope van het project en wordt dit it vooralsnog niet op het platform ondersteund. Contextdiagram:

Communicatie met IMPO: Het GrexxBoxx Management ontvangt van het IMPO het proces en de ondersteunende tools (platform) om de incidentafhandeling te ondersteunen. Communicatie met GrexxBoxx Servicedesk: Het GrexxBoxx Management ontvangt rapportages van de de GrexxBoxx Servicedesk. Servicedesk Het doel van de rapportages is het GrexxBoxx Management inzicht geven in de kwaliteit van de dienstverlening en inzicht in het behalen van de SLA’s. SLA’s Dit wordt ondersteunt op het platform door Dashboards beschikbaar te stellen voor het GrexxBoxx Management. De eisen van deze Dashboards zijn bij de GrexxBoxx Servicedesk behandeld. Verder is het GrexxBoxx Management de uiterste escalatiemogelijkheid van de GrexxBoxx GrexxBoxx Servicedesk. Ook heeft het GrexxBoxx Management altijd een mogelijkheid om te interveniëren. Hoe het platform deze activiteiten ondersteunt is bij de GrexxBoxx Servicedesk behandeld. Dennis van Roy (0491570) Incident Management in de GrexxBoxx

45

Communicatie met de Gebruiker: Gebruiker Het GrexxBoxx Management dient als als laatste escalatiemogelijkheid voor de Gebruiker. Ook kan de Gebruiker door het GrexxBoxx Management worden geïnformeerd over een incidentcase. Hierbij kan gedacht worden aan genomen acties naar aanleiding van een escalatie. De gegevens die hierbij van belang belang zijn, zijn bij de context van de Gebruiker behandeld. Communicatie met de Software Groep: Het GrexxBoxx Management ontvangt escalatieberichten van de de Software Groep. Het GrexxBoxx Management kan vervolgens via interventie een bericht sturen naar de oplosgroep of een incident toewijzen aan deze oplosgroep. De escalatie en interventie zijn in meer detail behandeld bij de GrexxBoxx Servicedesk. Configuratie Communicatie met de Oplosgroep Configuratie: Het GrexxBoxx Management ontvangt escalatieberichten van de Oplosgroep osgroep Configuratie en kan vervolgens via interventie een bericht sturen naar de oplosgroep of een incident toewijzen aan deze oplosgroep. De escalatie en interventie zijn in meer detail behandeld bij de GrexxBoxx Servicedesk. 4.2.1.9 Algemeen Management Bijdrage: ge: Bedenken en uitdragen van het beleid wat als kader dient voor het Incident Management Proces en Platform, Platform zoals: • Het ITIL-compliant compliant inrichten van het Incident Management Proces • Rekening houden met het toekomstige scenario van configuratiepartners Contextdiagram:

Communicatie met IMPO: Het Algemeen Management geeft aan IMPO een set van requirements waaraan het ontwerp moet voldoen. Dit wordt niet door het platform ondersteund, maar zijn eisen waaraan het systeem moet voldoen. voldoen


46

4.3

Incident Management Platform

Het Incident Management Platform wordt ontwikkeld om bovenstaande communicatie en proces te faciliteren. De processen die zich op het platform afspelen zijn: • Het operationele proces met betrekking tot het afhandelen van de incidenten • Dashboards • Beheer Proces • Ontwikkel Proces Het vervolg van dit hoofdstuk geeft een meer gedetailleerde beschrijving van deze processen. 4.4

Operationele Proces

Als eerste onderdeel in deze sectie worden kort de rollen die op het operationele proces kunnen acteren gegeven. Dit it proces wordt gestart als er een incident wordt aangemeld op het platform. Om inzicht te krijgen in de voortgang van incidenten is er voor gekozen om van een incident bepaalde statussen te onderscheiden. onderscheiden. Met behulp van de status kan worden aangegeven in welk stadium de incidentafhandeling zich bevindt. bevind . Op basis van de status wordt bepaald welke acties door welke personen kunnen worden uitgevoerd en worden de dashboards gegenereerd. 4.4.1 Besturing De rollen die ondersteund worden in het operationele proces zijn in Tabel 4-1 weergegeven. De verantwoordelijkheden van de rollen zijn kort in sectie 4.2.1 beschreven. De rollen en functies zijn hierbij ontkoppeld. Dit houdt in dat een werknemer met een bepaalde functie meerdere rollen kan bekleden. kleden. Hierdoor ben je flexibel met betrekking tot de organisatie wat mogelijk maakt dat het ontwerp ook gemakkelijk in andere organisaties, zoals partners, gebruikt kan worden. Omdat de GrexxBoxx Servicedesk een kleine organisatie is, is worden de in ITIL bespoken espoken rollen: Service Desk Manager, Service Desk Supervisor en Incident Manager bij Grexx samengevoegd en door de rol GrexxBoxx Manager uitgevoerd. Het is zeer onwaarschijnlijk dat in de nabije toekomst een verder opsplitsing van deze rol noodzakelijk is. De volgende domeinen zijn betrokken in i het operationele proces: Domein: Contract Partij Gebruiker GrexxBoxx Servicedesk Oplosgroep Configuratie Software Groep IMPO GrexxBoxx Management

Rol: Contractant Klant Servicedeskmedewerker Configuratieconsultant Ontwikkelaar Procesontwerper Manager Tabel 4-1: Rollen

4.4.2 Statussen Met behulp van statusindicatie kan worden aangegeven in welk stadium een incident zich bevind. Een incidentcase kan hierbij maar één status status tegelijkertijd hebben. Ook wordt dit attribuut gebruikt om aan te geven welke rollen aan de case kunnen participeren en wat de bijbehorende acties zijn die uitgevoerd kunnen worden. worden Dennis van Roy (0491570) Incident Management in de GrexxBoxx

47

In het onderstaande schema worden alle mogelijke statussen weergegeven. weergegeven. Status Nr 11 21 22 23 31 32

Status Aangemeld Toegewezen aan servicedesk Toegewezen aan oplosgroep configuratie Toegewezen aan software groep In behandeling door servicedesk

41

In behandeling door oplosgroep configuratie In behandeling door de software groep In behandeling door externe oplosgroep Wachten op aanvullende informatie

51

Opgelost

91

Omzetting naar Service Verzoek

1000

Afgesloten

1010

Voortijdig afgesloten

1020

Afgewezen

33 34

Omschrijving Incident is aangemeld. Incident toegewezen aan oplosgroep servicedesk. Incident toegewezen aan oplosgroep configuratie. Incident toegewezen aan software groep. Incident geaccepteerd en in behandeling door servicedesk. Incident geaccepteerd en in behandeling door oplosgroep configuratie. Incident geaccepteerd en in behandeling door de software groep. Incidentafhandeling vereist kennis/handelingen van een externe oplosgroep. Voor de afhandeling van het incident is aanvullende informatie van de klant vereist. Incident is opgelost volgens de oplosgroepen. De klant heeft dit in dit stadium echter nog niet bevestigd. Het incident wordt door de servicedeskmedewerker als service verzoek gecategoriseerd. De klant heeft dit echter in dit stadium nog niet bevestigd. Incident is opgelost en de oplossing is geverifieerd door de klant. Incident is door servicedeskmedewerker of gebruiker voortijdig afgesloten Incident is door de servicedeskmedewerker ervicedeskmedewerker omgezet naar het Service Verzoek Proces. Proces De klant heeft dit bevestigd.

De flow van het operationele proces is in de Figuren 4.2 en 4.3 grafisch weergegeven. Elke state in Figuur 4-2 representeert een status waarin een incident kan verkeren. De figuren zijn gemaakt met Yasper: Yet Another Smart Process Editor, ontwikkeld door de Technische Technisch Universiteit Eindhoven (TUe). Vanwege de leesbaarheid is gekozen om hiervoor twee figuren te gebruiken. Figuur 4.2 geeft de flow weer, maar mist de optionele acties die vanuit elke state uitgevoerd kunnen worden en geen invloed hebben op de state. Na het uitvoeren van deze acties bevindt een incidentcase zich weer in dezelfde state als van waaruit de actie werd geïnitieerd. Deze acties zijn in Figuur 4.3 4 weergegeven.


48

Figuur 4-2 Incident Management Proces

Zoals te zien in bovenstaande figuur zijn meerdere activiteiten uit het ITIL proces samengevoegd. Als eerste zijn de activiteiten: ‘identificeren’, ‘registreren’, ‘categoriseren’, ‘prioriteren’ en de ‘initiële diagnose’ samengevoegd. Deze acties worden bij Grexx allen door de dezelfde rol: servicedeskmedewerker gedaan. Tevens kunnen ze gelijktijdig worden uitgevoerd. Doordat zowel het tijdstip als de rol gelijk blijven en de activiteiten kort en niet complex zijn, hebben we deze ze activiteiten samengevoegd. Doordat deze activiteiten nu door dezelfde persoon worden uitgevoerd, verlaagt het samenvoegen van de activiteiten volgens (Reijers, et al.) de set-up up tijden en kan het de kwaliteit verhogen. Aangezien Aangezi de samengevoegde taak nog steeds redelijk eenvoudig is, zijn de negatieve effecten zoals vermindering van flexibiliteit en lagere kwaliteit door de grotere complexiteit te verwaarlozen. Ook worden de activiteiten ‘onderzoek en diagnose’’ en ‘oplossen en Dennis van Roy (0491570) Incident Management in de GrexxBoxx

49

herstellen’ qua ondersteuning voor het systeem in één actie samengevoegd. amengevoegd. Het uiteindelijke onderzoeksproces is namelijk ‘brainwork’ waarvan alleen de uitkomst en stappen in het systeem worden geregistreerd. Verder wordt de mogelijkheid voor escalatie, zowel zow functioneel als hiërarchisch, tijdens de gehele oploscyclus mogelijk gemaakt. gemaakt

Figuur 4-3 Optionele taken

Om aan te geven wie in welke status is geautoriseerd om activiteiten uit te voeren wordt in de onderstaande tabellen hiervan een overzicht gegeven. De eerste tabel bevat de optionele taken die op elk moment in het proces mogelijk zijn zoals beschreven in Figuur 4.3. Activiteiten die altijd mogelijk zijn op een open case: Activiteiten: Aanvullen Incidentmelding Chatten Wijzigen Incidentgegevens Bestand Toevoegen Informeren Klant Interveniëren Escaleren

Door wie: Klant, Servicedeskmedewerker Servicedeskmedewerker, Configuratieconsultant, Ontwikkelaar Servicedeskmedewerker Klant, Servicedeskmedewerker, Configuratieconsultant, Ontwikkelaar Ontwikkela Servicedeskmedewerker, Manager Manager Klant, Servicedeskmedewerker, Configuratieconsultant, Ontwikkelaar

In de onderstaande tabellen wordt per status behandeld welke activiteiten uitgevoerd kunnen worden en welke rollen geautoriseerd zijn om deze acties uit te voeren. Status 11: Nieuw Activiteiten: Registreren en Toewijzen Incident Voortijdig Afsluiten

Door wie: Servicedeskmedewerker Klant, Servicedeskmedewerker

Status 21: Toegewezen aan Servicedesk Activiteiten: Accepteren Incident Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Servicedeskmedewerker Manager Klant, Servicedeskmedewerker


50

Status 22: Toegewezen aan oplosgroep Configuratie Activiteiten: Accepteren Incident Aanvullen incidentmelding Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Configuratieconsultant Servicedeskmedewerker Configuratieconsultant, Klant, Servicedeskmedewerker Manager Klant, Servicedeskmedewerker

Status 23: Toegewezen aan Software Groep Activiteiten: Accepteren Incident Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Doo Software Groep, Groep Servicedeskmedewerker Manager Klant, Servicedeskmedewerker

Status 31: In behandeling door Servicedesk Activiteiten: Registreren Diagnose en Oplossing Aanvullende informatie vragen Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Servicedeskmedewerker Servicedeskmedewerker Manager Klant, Servicedeskmedewerker

Status 32: In behandeling door oplosgroep Configuratie Activiteiten: Registreren Diagnose en Oplossing Aanvullende informatie vragen Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Configuratieconsultant Servicedeskmedewerker Configuratieconsultant, Servicedeskmedewerker, Configuratieconsultant Manager Klant, Servicedeskmedewerker

Status us 33: In behandeling door Software Groep Activiteiten: Registreren Diagnose en Oplossing Aanvullende informatie vragen Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Ontwikkelaar Servicedeskmedewerker Ontwikkelaar, Servicedeskmedewerker, Ontwikkelaar Manager Klant, Servicedeskmedewerker


51

Status 34: In behandeling door Externe Oplosgroep Activiteiten: Registreren Diagnose en Oplossing Aanvullende informatie vragen Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Servicedeskmedewerker Servicedeskmedewerker Manager Klant, Servicedeskmedewerker

Status 41: Wachten op aanvullende informatie Activiteiten: Registreren aanvullende informatie Toewijzen aan andere oplosgroep Voortijdig Afsluiten

Door wie: Klant, Servicedeskmedewerker Manager Klant, Servicedeskmedewerker

Status 51: Opgelost Activiteiten: Toewijzen aan andere oplosgroep Afsluiten Incident

Door wie: Manager Klant, Servicedeskmedewerker

Status 91: Omzetting mzetting naar Service Verzoek Activiteiten: Accepteren omzetting

Door wie: Klant, Servicedeskmedewerker

Status 1000: Afgesloten Activiteiten: Heropenen Incident

Door wie: Servicedeskmedewerker

Status 1010: Voortijdig Afgesloten Activiteiten: Heropenen Incident


Status 1020: Incident Afgewezen Activiteiten: Heropenen Incident



52

4.4.3 Casedata ata ten behoeve van het Incident Management Proces In Figuur 4.4 staat het datamodel atamodel behorend bij het Incident Management Proces. Proces Hierin wordt aangegeven welke attributen van het casetype incident van belang zijn en wat de relatie is tot andere objecten. Eerst volgt een korte tekstuele beschrijving: Op het platform bestaan klanten lanten die één of meerdere GrexxBoxxen hebben. Op elke GrexxBoxx worden één of meerdere medewerkers medewerkers geregistreerd. Verder hoort er één SLA bij een GrexxBoxx. Op een GrexxBoxx kunnen serviceverzoeken en incidenten worden gemeld. Een incident ncident hoort altijd bij een probleem. Een probleem robleem heeft dus altijd één of meerdere m incidenten. Als er van een incident ncident nog geen onderliggend probleem probleem is vastgelegd, wordt deze aangemaakt. Medewerker Klant Id Naam Voornaam Contactpersoon Achternaam Contactpersoon Email Contactpersoon Telefoonnummer

Id Voornaam Achternaam Telefoonnummer Emailadres

Probleem Id Categorie Onderwerp Omschrijving Oplossing

GrexxBoxx

Incident

Id Naam Applicatie Locatie Database Locatie VersieNummer Naam Contactpersoon Email Contactpersoon Telefoonnummer Contactpersoon

SLA Id Beschikbaarheidspercentage Aantal Dagen Tijdstip Van Tijdstip Tot Reactietijd (uren ) Oplostijd Prio 1 Oplostijd Prio 2 Bijlage

Service Verzoek Id Datum/Tijd Contactgegevens Omschrijving File Prioriteit Status Categorie Soort Verzoek Toelichting Verzoek Aanvullende Vraag Aanvullende Informatie Reden Vroegtijdig Sluiten Bevestiging Afsluiten Vereist Opgelost Reden niet Opgelost

Id Naam Melder Email Melder Telefoonnummer Melder Datum Datum/Tijd vd Melding Onderwerp Omschrijving CaseId Proces URL Bijlage Categorie Prioriteit Diagnose Bekend Probleem ? OplosGroep Status Deadline Aanvullende Vraag Aanvullende Informatie Informatie aan Klant Akkoord Klant Reden niet Akkoord Reden voortijdige Afsluiting Reden niet Opgelost Reden Wijziging Melding Reden Aanvullen Melding Reden Heropenen Melding Accepteren Toewijzing Reden Afwijzing Repeterend Karakter Initiator Voortijdig Sluiten Reden Interventie Reden Escalatie

Figuur 4-4 Datamodel


53

4.5

Dashboards

Het inzien van real-time time rapportages wordt op het platform ondersteund ondersteun door het gebruik van dashboards. Het starten van de dashboards is een optionele taak die op elke GrexxBoxx uitgevoerd kan worden. In onderstaande tabel staat beschreven welke dashboards er zijn en wie geautoriseerd is om deze in te zien. Activiteiten:

Rollen:

Inzien dashboards Contractant Inzien dashboards GrexxBoxx Management Inzien dashboards IMPO

Contractant, Servicedeskmedewerker Manager, Servicedeskmedewerker

4.6

Procesontwerper, ntwerper, Servicedeskmedewerker

Beheer Proces

Dit proces is een al bestaand proces pr wat op elke GrexxBoxx is ingericht. Dit is onderverdeeld in autorisatiebeheer en contentbeheer. Omdat het een bestaand taand proces is op de GrexxBoxx wordt alleen een overzicht gegeven van de mogelijke acties en de rollen die erbij betrokken zijn. Activiteiten:

Door wie:

Rol toevoegen/verwijderen Rechten toevoegen aan rol Personen toevoegen aan of verwijderen bij een rol Emailteksten aanpassen Instructies aanpassen

Manager Manager Manager

4.7

Manager Manager

Ontwikkel Proces

Dit proces is een al bestaand nd proces wat op elke GrexxBoxx is ingericht. In dit proces kan onder andere het case-object object formulier ingevoerd worden in de GrexxBoxx. Verder wordt ook de ‘look and feel’’ hier bepaald. Omdat het een bestaand proces is op de GrexxBoxx wordt alleen een overzicht rzicht gegeven van de mogelijke acties en de rollen die erbij betrokken zijn. Activiteiten:

Door wie:

Toevoegen en aanpassen van formulieren Aanpassen Procesflow waaronder triggers, statussen, activiteiten en rechten Wijzigen indeling van de webapplicatie

Configuratieconsultant Configuratieconsultant Configuratieconsultant


54

5

Ontwerp in de GrexxBoxx

In dit hoofdstuk wordt het ontwerp van de eerste versie van het systeem in de GrexxBoxx beschreven. Het ontwerp wordt gemaakt aan de hand van een formulier dat in sectie 5.1 zal worden beschreven en toegelicht. toegelicht De ontwikkeling van dit formulier is onderdeel van dit project om een uniforme manier te bedenken waarin een GrexxBoxx ontwerp kan worden beschreven. In het formulier kunnen alle aspecten die in de GrexxBoxx de flow afdwingen worden beschreven. De werking van de GrexxBoxx zal in sectie 5.2 op basis van enkele vertalingen naar Petrinetten worden toegelicht. Het daadwerkelijke ontwerp van het operationele proces in de GrexxBoxx Grexx wordt in sectie 5.4 behandeld. Omdat dit een eerste versie is, zal niet de gehele functionaliteit van het ontwerp dat is beschreven in het Business Architectuur worden geïmplementeerd. De configuratiekeuzes hiervan worden in sectie 5.3 behandeld. 5.1

Formulier voor de case--objecten

Het onderstaande formulier is ontworpen om het GrexxBoxx-ontwerp ontwerp op een intuïtieve manier te beschrijven, zoals deze ook wordt geïmplementeerd in de GrexxBoxx. Er is geabstraheerd straheerd van de applicatie die de ‘look and feel’ bepaalt bepaal en weergeeft hoe en wanneer bepaalde attributen worden weergegeven. Zo’n applicatie tie is als het ware een layer over de case die bepaald hoe en wat er wordt getoond aan de klant. Hiervoor kan gebruik gemaakt worden van vooraf gedefinieerde blokken zodat een relatief mooi resultaat snel te behalen is. In het formulier kunnen alleen de gegevens worden vastgelegd die de flow tussen activiteiten bepalen. Naam: Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam:

Type:

V/O

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities

Naar:

Operatie:

Van:

Triggers: Naam:

Rechten: Rol:

Wanneer: Conditie:

Status vanaf:

Status tot en met:

Type:

Type:


55

Voor oor elk van de elementen zal een korte beschrijving worden gegeven van de betekenis en de mogelijke waarden die kunnen worden ingevuld. Docin, Docout In de Docin en Docout worden en de data weergegeven die voor een gebruiker van belang zijn voor het uitvoeren van een activiteit op een case. Deze gegevens worden aan de gebruiker in een formulier op het scherm getoond. Van deze attributen wordt bepaald of ze verplicht ingevuld moeten worden om de activiteit succesvol te beëindigen of optioneel zijn. In de eerder er genoemde applicatie kan ook nog worden bepaald of bepaalde optionele attributen verplicht worden afhankelijk van de ingevulde waarden van andere attributen. Een Docin wordt gebruikt als een formulier als input voor een case dient. Een Docout wordt gebruikt gebru als het een atomaire activiteit betreft die door het invullen van het formulier al wordt beëindigd. Het type geeft aan van welk type het attribuut is. Hierbij kan geselecteerd worden uit boolean, case, check, date, file, time, datetime, text, integer, float, money, HTML, HTML picklist of image. Mapin, Mapout In de Mapin wordt aangegeven welke waarden worden gemapt naar de attribuutwaarden van het Docin formulier. Deze waarden kunnen op basis van de casedata zijn, maar hier kunnen ook handmatig ingevulde constanten co en java functies worden ingevuld. In de Mapout wordt aangegeven welke waarden worden gemapt naar de casedata. Hier wordt aangegeven welke waarden van de casedata moeten worden geupdate. Deze waarden kunnen worden bepaald door andere casedata, handmatig matig ingevulde constanten of java functies. De standaard aard operaties die op de data kunnen ku worden uitgevoerd zijn: *= (vermenigvuldigen van getallen), getallen) /= (delen van getallen),+= (optellen van getallen of concateneren van text), -= (aftrekken van getallen), getallen) add timeunit (waarbij voor timeunit timeuni minuten, uren, dagen etc. kan worden gekozen). Standaard wordt aangegeven bij een taak dat alle Casedata automatisch wordt gemapt naar de attributen van een inputformulier en dat alle ingevulde attribuutwaarden van een formulier automatisch worden en gemapt naar de casedata. Wanneer dit niet gewenst gewe is kan dit worden uitgezet. Aan de Mapin en Mapout kunnen condities worden verbonden die beïnvloeden of een attribuut daadwerkelijk wordt gemapt. De condities kunnen worden bepaald be op basis van attribuutwaarden van de casedata. De mogelijke operaties hierbij zijn ‘<, <=, =/=, ==, >=, >, in’ en kunnen gecombineerd worden met ‘and’ en ‘or’ functies. Triggers ordt een lijst bijgehouden met alle gedefinieerde activiteiten activiteiten genaamd het In de GrexxBoxx wordt ‘actierepertoire’. In het actierepertoire kan met behulp van een waarde Aan of Uit bepaald worden welk van deze activiteiten op dat moment uitgevoerd kan worden. Bij elke activiteit wordt bijgehouden welke activiteiten hij triggert. Deze D triggers worden niet verzameld in een overall procesmodel, maar worden dus alleen gerelateerd aan de individuele activiteiten. Zodra een activiteit is uitgevoerd wordt deze automatisch op de waarde Uit gezet. Dit neemt niet weg dat een activiteit hiernaa nogmaals kan worden uitgevoerd. Bij elke activiteit wordt namelijk bijgehouden welke activiteiten hij triggert, triggert, dit kan dus ook zichzelf Dennis van Roy (0491570) Incident Management in de GrexxBoxx

56

zijn. De triggermogelijkheden zijn Execute, Enable en Cancel. De Execute en Enable triggers zetten een verplichte of optionele vervolgactiviteit vervolg klaar. Het verschil tussen verplicht en optioneel geeft de gebruiker inzicht of dat bepaalde taken naar eigen inzicht kunnen worden uitgevoerd, of taken (altijd) uitgevoerd moeten worden. De GrexxBoxx presenteert deze ook aan de gebruiker in verschillende werkbakken. De Cancel trigger zorgt juist dat een activiteit niet meer uitgevoerd kan worden. worden Op triggers kunnen vervolgens ook nog condities worden gezet die waar moeten zijn voordat de trigger ook echt wordt uitgevoerd. De condities kunnen net als bij de mappings worden bepaald op basis van attribuutwaarden van de casedata. De mogelijke operaties hierbij zijn ‘<, <=, =/=, ==, >=, >, in’ en kunnen gecombineerd worden met ‘and’ en ‘or’ functies. In sectie 5.2 wordt een voorbeeld gegeven van de betekenis aan de hand van een vertaling naar Petrinetten. Bij een trigger kan ook nog worden ingesteld wanneer deze moet worden uitgevoerd. De keuzemogelijkheden zijn hierbij: Bij Start, Indien gereed, Indien Deadline verstreken, verstreken Indien Gecancelled en Wacht …,, waarin kan worden aangegeven hoeveel maanden, dagen, uren en minuten gewacht moet worden alvorens al de trigger te activeren. In sectie 5.2 wordt het gebruik van triggers aan de hand van voorbeelden uitgelegd. Status Status is een variabele die een speciale betekenis heeft in de GrexxBoxx. Met behulp van een status kunnen bepaalde fasen die een case kan doorlopen worden opgesplitst. De opsplitsing kan vervolgens gebruikt worden voor rapportages, maar ook om personen te autoriseren voor bepaalde acties op basis van deze status. Bij elke activiteit kan je aangeven bij welke statussen deze uitgevoerd kan worden. In principe kan je hierdoor met behulp van status, hetzelfde bewerkstelligen lligen als met de triggers. Het gebruik van status en triggers kan dus door elkaar gebruikt worden naar gelang de voorkeur. In het algemeen wordt de status gebruikt in het geval er een activiteit altijd kan worden uitgevoerd, zodat deze niet na elke taak getriggert etriggert hoeft te worden. Dit komt in de praktijk vooral voor bij optionele taken. Alleen het gebruik van status om een flow af te dwingen is veelal niet wenselijk omdat dit bij complexe gevallen met veel statussen geen inzicht geeft in de volgordelijkheid. volgordelijkhei Rechten Geeft aan welke rollen bij deze activiteit betrokken zijn. Per type recht wordt aangegeven welke mogelijke acties een rol kan vervullen. Dit zijn: Uitvoeren Deze taak wordt voor personen met een bepaalde rol klaargezet als een verplichte taak. De persoon heeft het ‘recht’ en de ‘plicht’ deze taak uit te voeren, en krijgt daarbij toegang tot alle benodigde gegevens en tools. Aanvragen Deze activiteit wordt voor personen met een bepaalde rol getoond in het actierepertoire als optionele taak. De persoon rsoon heeft de keuze om deze taak uit te voeren, en krijgt daarbij toegang tot alle benodigde gegevens en tools. Cancellen Deze taak wordt teruggetrokken zodat personen met een bepaalde rol de activiteit niet meer kunnen uitvoeren.


57

Zien

5.2

De data en historie (audit trail) van een case kan bekeken worden door personen met een bepaalde rol. Dit wordt o.a. ingesteld als deze personen geen rechten hebben om taken op een case uit te voeren, maar wel de data en voortgang mogen inzien. Vertaling GrexxBoxx naar Petrinet Pet

Eerst wordt met behulp van enkele voorbeelden weergegeven hoe specifieke onderdelen in de GrexxBoxx vertaald kunnen worden naar een Petrinet. Hierdoor wordt ook de betekenis van de formulieren verduidelijkt. verduidelijkt 5.2.1 Triggers Met behulp van voorbeelden worden wor in deze sectie de triggers van de GrexxBoxx behandeld. 5.2.1.1 Or-split split met behulp van Triggers

Figuur 5-1 Or-split

Naam: Activiteit A Triggers: Naam: B C

Wanneer: Indien gereed Indien gereed

Conditie: X<=10 X>10

Type: Execute Execute


58

5.2.1.2 Or-join join met behulp van Triggers

Figuur 5-2 Or-join

Naam: Activiteit A Triggers: Naam: B

Wanneer: Indien gereed

Conditie:

Type: Execute

Wanneer: Indien gereed

Conditie:

Type: Execute

Conditie:


Naam: Activiteit B Triggers: Naam: C

5.2.1.3 And-split split met behulp van Triggers

Figuur 5-3 And-split

Naam: Activiteit A Triggers: Naam: B C

Wanneer: Indien gereed Indien gereed


59

5.2.1.4 And-join join met behulp van Triggers Een and-join join is op deze manier niet rechtstreeks te implementeren. Dit kan met behulp van data-elementen elementen worden nagebootst. Omdat dit een veelvoorkomend patroon is, is er in de GrexxBoxx een extra tra service gedefinieerd genaamd de Group-And. Dit it is een object dat net als andere activiteit kan worden aangeroepen en een and-split en and-join join combineert. combineert

Figuur 5-4 And-split/join

Naam: Activiteit A Triggers: Naam: Group And

Wanneer: Conditie: Bij Start

Type: Execute

Wanneer: Bij Start Bij Start Indien Gereed

Type: Execute Execute Execute

Naam: Group And Triggers: Naam: B C D

Conditie:

Als er in de praktijk veel dezelfde patronen voorkomen voorkomen en er behoefte is aan een service die deze versimpelt, worden deze aan de GrexxBoxx toegevoegd. In sectie 5.2.4 wordt de werking van de GrexxBoxx verder uitgewerkt waaruit blijkt dat dit eenvoudig toe te voegen is. 5.2.2 Cancel met et behulp van triggers

Figuur 5-5 Cancel

Waarbij tau1 een hogere prioriteit heeft om te vuren dan tau2.


60

Naam: Activiteit B Triggers: Naam: C D

Wanneer: Conditie: Indien gereed Indien gereed

Type: Execute Cancel

5.2.3 Status Met behulp van voorbeelden worden in deze sectie alleen de activiteiten activiteiten met behulp van de status van de GrexxBoxx behandeld. Het attribuut status kan op twee manieren worden gebruikt. Als eerste kan de waarde die het attribuut status heeft net als alle andere casedata als conditie bij de triggers worden gebruikt. Ten tweede kan bij de rechten worden aangegeven dat een taak uitgevoerd kan worden door personen met een bepaalde rol tussen bepaalde statussen. Dit wordt in Figuur 5-6 uitgelegd.

Figuur 5-6 Status

Naam: Activiteit A Rechten: Rol: Servicedeskmedewerker

Status vanaf: 10

Status tot en met: 10

Type: Enable

Status vanaf: 10


Type: Enable

Naam: Activiteit B Rechten: Rol: Servicedeskmedewerker

Het is overigens ook mogelijk om bij deze ‘optionele’ taken ook weer andere taken te triggeren, zodat een case niet altijd in dezelfde state terugkeert. Dit wordt in Figuur 5-7 weergegeven.


61

Figuur 5-7 Status v2

Naam: Activiteit A Triggers: Naam: B C Rechten: Rol: Servicedeskmedewerker

Wanneer: Conditie: Bij Start Bij Start Status vanaf: 10

Statuss tot en met: 20

Type: Execute Execute Type: Enable

5.2.4 Uniforme vertaling Na het starten van een case, wordt de casedata gecreëerd en worden alle gedefinieerde activiteiten op een case (het actierepertoire) mogelijk om uit te voeren. Er kunnen echter wel constraints zijn of een case al dan dan niet mag worden uitgevoerd. Deze constraints zijn op basis van de speciale data-elementen elementen die hierboven zijn beschreven zoals triggers en status. De GrexxBoxx kan hierdoor gezien worden als een Petrinet waar alle activiteiten activ aan één state zitten. In Figuur 5-8 is dit ‘bloemmodel’ weergegeven. De flow door de activiteiten wordt op basis van data bepaald. Elke activiteit kan de casedata manipuleren. Door de GrexxBoxx op deze manier te vertalen naar n een Petrinet, wordt de aanpasbaarheid van de GrexxBoxx duidelijker aangegeven. aangegeven


62

Figuur 5-8 Petrinet van de GrexxBoxx

Alle activiteiten manipuleren de casedata, waardoor een bepaalde flow door het proces proc afgedwongen kan worden. Zoals eerder beschreven, is heet actierepertoire is een lijst met alle activiteiten die uitgevoerd kunnen worden op een case. Met behulp van een waarde Aan of Uit kan bepaald worden welk van deze activiteiten op een bepaald moment nt uitgevoerd kan worden. Bij het uitvoeren van een activiteit tiviteit wordt deze lijst geüpdate, geüpdate, waardoor een flow mogelijk wordt gemaakt. Op basis van het actierepertoire wordt een andere lijst samengesteld, genaamd actieve lijst. De actieve lijst bevat de activiteiten iviteiten die op dat specifieke moment in het proces uitgevoerd kunnen worden. Als een activiteit in deze lijst voorkomt, kan deze dus uitgevoerd worden. Een constraint op elk van de pijlen in het Petrinet is dus dat de desbetreffende activiteit een elementt is van de actieve lijst. Als dit niet het geval is, kan de activiteit niet worden uitgevoerd. De statussen worden ook in een lijst bijgehouden met per status alle mogelijke Activiteiten die uitgevoerd kunnen worden. Als een case in een bepaalde status is, i worden de activiteiten die op basis van deze status kunnen worden uitgevoerd toegevoegd aan de actieve lijst.


63

Figuur 5-9 geeft aan hoe het eerste statusvoorbeeld uit sectie 5.2.3 op deze manier kan k worden gemodelleerd in een Petrinet.

Figuur 5-9 Status Bloemmodel


64

5.3

Configuratie keuzes

Doordat de GrexxBoxx nog volop in ontwikkeling is, is ontbreken momenteel nog enkele functionaliteiten. De functionaliteiten functiona die als gevolg hiervan niet in deze versie, maar in een volgende release worden geïmplementeerd zijn de chat-functionaliteit en de ondersteuning o voor sms-berichten. Verder zijn momenteel de GrexxBoxx contracten met bijbehorende SLA’s niet vastgelegd vastgele in de GrexxBoxx. Hierdoor wordt de automatische koppeling naar de SLA’s nog niet meegenomen en worden er standaard reactiereactie en oplostijden gebruikt zoals in de Business Architectuur beschreven. Verder worden tegelijk met dit project andere ITIL-processen ITIL geconfigureerd waaronder het Problem Management. Omdat dit nog in ontwikkeling is, is wordt gewacht met de koppeling totdat deze is geïmplementeerd. Doordat incidenten in de tussentijd al worden geregistreerd, kan op basis van die gegevens bij invoering van n het Problem Management Proces al de ‘bekende problemen’-database problemen’ worden gevuld. In de GrexxBoxx zijn koppelingen naar andere processen eenvoudig te configureren. Hierdoor kunnen deze koppelingen zonder grote wijzigingen achteraf worden geconfigureerd en n is er voor gekozen om deze koppelingen pas te realiseren als de andere processen zijn geïmplementeerd. Het proces Service Verzoeken is al ontworpen en geïmplementeerd in de GrexxBoxx. Deze koppeling wordt hierdoor wel meegenomen in de implementatie.


65

5.4

Case-objecten

De start van het operationele incidentproces proces gebeurt door het aanmelden van een incident. Het aanmelden kan door een klant worden gestart vanuit een specifieke GrexxBoxx van een klant.. Op dit niveau kan ook de inzage van dashboards worden gestart. gest De andere activiteiten van het operationele proces worden op het niveau van een incident uitgevoerd. Als eerste worden de activiteiten beschreven die vanuit het niveau van een specifieke GrexxBoxx kunnen worden uitgevoerd. Daarna worden de activiteiten activiteiten behandeld die vanuit een incidentcase kunnen worden gestart. In de formulieren van de case-objecten objecten wordt door middel van onderstreepte activiteiten bij de triggers aangegeven welke activiteiten automatische taken zijn.. Dit zijn activiteiten die door het systeem worden afgehandeld zoals automatisch verzonden emailberichten, emailberichten, het omzetten naar een Serviceverzoek en het activeren en deactiveren van rollen. Deze activiteiten worden in sectie 5.4.3 behandeld. 5.4.1 Niveau van een GrexxBoxx GrexxB Onderstaande dashboards zijn aan te roepen als er op een GrexxBoxx is ingelogd. Het inzien van de dashboards is een optionele taak. ta Deze taak heeft geen formulieren, mappings mapping of triggers, waardoor hiervan alleen de rechten hoeven te worden bepaald. De data die wordt getoond, wordt in de applicatie bepaald. Hierbij wordt gebruik gemaakt van specifieke ‘jsp’pagina’s die elk gebruik maken van queries op de Database. De getoonde data in de dashboards wordt behandeld in sectie 4.2. Naam: Inzien Dashboards Contractant Rechten: Rol: Contractant Servicedeskmedewerker

Status vanaf:

Status tot en met:

Type: Enable Enable

Status vanaf:

Status tot en met:

Type: Enable Enable

Status vanaf:

Status tot en met:

Type: Enable Enable

Naam: Inzien Dashboards GrexxBoxx Management Rechten: Rol: Manager Servicedeskmedewerker

Naam: Inzien Dashboards IMPO Rechten: Rol: Procesontwerper Servicedeskmedewerker


66

Het starten van een incidentmelding gebeurt door een optionele optionele taak te starten genaamd: Aanmelden Incident. Naam: Aanmelden Incident Docin: Attribuutnaam: Naam melder Email melder Telefoonnummer melder Onderwerp CaseId Proces Omschrijving URL Bijlage

Type: text text Integer text text text text text File

V/O V V O O O O V O O

Docout: Attribuutnaam:

Type:

V/O

Map in: Condities

Map out: Condities

Naar: status

Operatie: =

Van: 11

Naar:

Operatie:

Van:

Triggers: Naam: Registreren en Toewijzen Informeer Servicedesk Herinnering registratietaak Rechten: Rol: Servicedeskmedewerker Klant Configuratieconsultant Ontwikkelaar Manager

Wanneer: Indien Gereed Indien Gereed Indien Deadline Verstreken (1 uur) Status vanaf:

Conditie:

Status tot en met:

Type: Execute Execute Execute Type: Enable Enable Enable Enable Enable


67

5.4.2 Niveau van een incident Alle objecten die in dit gedeelte worden beschreven worden gestart vanuit een incidentcase. Dit houdt in dat er een en incidentcase moet worden gestart alvorens deze activiteiten beschikbaar worden. Naam: Registreren en Toewijzen oewijzen Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Naam melder Email melder Telefoonnummer melder Onderwerp CaseId Proces Omschrijving URL Bijlage Service Verzoek Categorie Prioriteit Diagnose Oplosgroep Reden Factureerbaar

Type: text text integer text text text text text File Ja/Nee text text text text text

V/O V V O V O O V O O V V V O V O

Map in: Condities

Naar:

Operatie:

Map out: Condities Oplosgroep==Servicedesk /\ Service Verzoek == Nee Oplosgroep==Consultancy /\ Service Verzoek == Nee Oplosgroep==Ontwikkeling /\ Service Verzoek == Nee Service Verzoek == Ja Prioriteit== Prioriteit1 Prioriteit== Prioriteit2 Triggers: Naam: Accepteren Incident Accepteren Omzetting Automatische Escalatie Notificatie Omzetting Verzend ontvangstbevestiging Set/Delete CaseRoles

Van:

Naar: status status status status deadline deadline

Wanneer: Indien Gereed Indien Gereed Indien Gereed Indien Gereed Indien Gereed Indien Gereed

Operatie: = = = = = =

Conditie: Serviceverzoek == Nee Serviceverzoek == Ja Deadline Verstreken Serviceverzoek == Ja Serviceverzoek == Nee

Van: 21 22 23 91 2 72 Type: Execute Execute Execute Execute Execute Execute


68

Rechten: Rol: Servicedeskmedewerker

Status vanaf:

Status tus tot en met:

Type: execute

Naam: Accepteren Omzetting Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Reden Facturabel Akkoord omzetting Reden niet akkoord omzetting

Type: Text Ja/Nee Text

V/O V V O

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities Akkoord omzetting==Ja Akkoord omzetting==Nee

Naar: status status

Operatie: = =

Van: 1020 11

Triggers: Naam: Registreren en Toewijzen Omzetting naar Serviceverzoek

Rechten: Rol: Klant Servicedeskmedewerker

Wanneer: Indien Gereed Indien Gereed

Status vanaf:

Conditie: Status==11 Status== 1020

Status tot en met:


Type: Execute Enable


69

Naam: Accepteren Incident Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Accepteren Toewijzing Reden Afwijzing Oplosgroep

Type: Ja/Nee Text Text

V/O V O O

Map in: Condities

Naar:

Operatie:

Map out: Condities Status==21 /\ Accepteren Toewijzing==Ja Status==22 /\ Accepteren Toewijzing ==Ja Status==23 /\ Accepteren Toewijzing ==Ja Accepteren Toewijzing ==Nee /\ Oplosgroep==Servicedesk Accepteren Toewijzing ==Nee /\ Oplosgroep==Consultancy Accepteren Toewijzing ==Nee /\ Oplosgroep==Ontwikkeling Triggers: Naam: Registreren Diagnose en Oplossing Accepteren Incident Set/Delete CaseRoles Rechten: Rol: Servicedeskmedewerker Servicedeskmedewerker Configuratieconsultant Ontwikkelaar

Wanneer: Indien Gereed Indien Gereed Indien Gereed

Van:

Naar: Status Status Status Status Status Status

Operatie: == == == == == ==

Conditie: Accepteren Toewijzing== Ja Accepteren Toewijzing ==Nee

Status vanaf: 22


Van: 31 32 33 21 22 23


Type: Aanvragen Uitvoeren Uitvoeren Uitvoeren


70

Naam: Registreren Diagnose en Oplossing Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Diagnose Opgelost Oplossing Reden niet opgelost Oplosgroep

Type: Text Ja/Nee Text Text Text

V/O V V O O O

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities Opgelost==Ja Opgelost==Nee /\ Oplosgroep==Servicedesk Opgelost==Nee /\ Oplosgroep==Consultancy Opgelost==Nee /\ Oplosgroep==Ontwikkeling

Naar: status status status status

Operatie: == == == ==

Van: 51 21 22 23

Triggers: Naam: Accepteren Incident Accepteren Oplossing Informeer Klant over Oplossing Set/Delete CaseRoles

Wanneer: Indien Gereed Indien Gereed Indien Gereed Indien Gereed

Rechten: Rol: Servicedeskmedewerker Configuratieconsultant Ontwikkelaar Servicedeskmedewerker

Conditie: Status =/= 51 Status == 51 5 Status == 51

Status vanaf:

Status tot en met:

32

33

Type: Execute Execute Execute Execute

Type: Execute Execute Execute Enable


71

Naam: Accepteren Oplossing Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Akkoord Klant Reden Niet akkoord

Type: Ja/Nee Text

V/O V O

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities Akkoord klant == Ja Akkoord klant == Nee

Naar: Status Status

Operatie: == ==

Van: 1000 11

Triggers: Naam: Registreren en Toewijzen

Wanneer: Indien Gereed

Rechten: Rol: Servicedeskmedewerker Klant

Status vanaf: 51 51

Conditie: Status =/= 1000

Status tot en met: 51 51

Type: Execute

Type: Enable Execute


72

Naam: Heropenen Incident Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Reden Heropenen Incident Oplosgroep

Type: Text Text

V/O V V

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities Oplosgroep == Servicedesk Oplosgroep == Consultancy Oplosgroep == Ontwikkeling

Naar: Status Status Status

Operatie: == == ==

Van: 21 22 23

Triggers: Naam: Accepteren Incident Set/Delete CaseRoles

Wanneer: Indien Gereed Indien Gereed


Status vanaf: 1000

Conditie: ditie:



Type: Aanvragen


73

Naam: Toewijzen aan Externe Oplosgroep Oplosgr Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Onderwerp Omschrijving

Type: Text Text

V/O V V

Map in: Condities

Map out: Condities

Naar:

Operatie:

Van:

Naar: status

Operatie: ==

Van: 34

Triggers: Naam: Meld incident bij oplosgroep infrastructuur



Status vanaf: 31

Conditie:


Type: Execute

Type: Enable

Omdat het onderwerp en de omschrijving omschrijving automatisch worden verstuurd naar de oplosgroep infrastructuur, kan het gewenst zijn om deze velden iets aan te passen. Deze aanpassing zal echter niet worden doorgevoerd op de casedata omdat de automatische mapping zoals beschreven in sectie 5.1 bij dit object uitgezet is.


74

Naam: Aanvullende informatie vragen Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Aanvullende Vraag

Type: Text

V/O V

Map in: Condities

Map out: Condities

Naar:

Operatie:

Van:

Naar: status

Operatie: ==

Van: 41

Triggers: Naam: Registreren aanvullende informatie Registreren diagnose en oplossing Verzend aanvullende vraag


Rechten: Rol: Servicedeskmedewerker Configuratieconsultant Ontwikkelaar

Status vanaf: 11 31 32

Conditie:

Status tot en met: 51 31 32

Type: Execute Cancel Execute

Type: Enable Enable Enable


75

Naam: Registreren aanvullende informatie Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Aanvullende Informatie

Type: Text

V/O V

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities Oplosgroep == Servicedesk Oplosgroep == Consultancy Oplosgroep == Ontwikkeling

Naar: status status status

Operatie: == == ==

Van: 31 32 33

Triggers: Naam: Registreren diagnose en oplossing



Status vanaf: 41 41

Conditie:


Type: Execute

Type: Execute Enable


76

Naam: Toewijzen aan andere oplosgroep Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Oplosgroep Reden Escalatie

Type: Text Text

V/O V V

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities Oplosgroep==Servicedesk Oplosgroep==Consultancy Oplosgroep==Ontwikkeling

Naar: status status status

Operatie: = = =

Van: 21 22 23

Triggers: Naam: Accepteren Incident escalatiemelding Set/Delete CaseRoles


Conditie:


Rechten: Rol: manager

Status vanaf: 21


Type: Enable


77

Naam: Aanvullen Incidentmelding Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Aanvullende Informatie

Type: Text

V/O V

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities

Naar:

Operatie:

Van:

Triggers: Naam:


Wanneer:

Status vanaf: 11 11

Conditie:


Type:

Type: Enable Enable


78

Naam: Bestand Toevoegen Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Bestand

Type: File

V/O V

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities

Naar:

Operatie:

Van:

Triggers: Naam:

Wanneer:

Rechten: Rol: Klant Servicedeskmedewerker Configuratieconsultant Ontwikkelaar

Status vanaf: 11 11 32 33

Conditie:

Status tot en met: 91 91 32 33

Type:

Type: Enable Enable Enable Enable


79

Naam: Escaleren Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Reden Escalatie Gewenste Actie

Type: Text Text

V/O V O

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities

Naar:

Operatie:

Van:

Triggers: Naam: Escalatiemelding

Rechten: Rol: Klant Servicedeskmedewerker Configuratieconsultant Ontwikkelaar


Conditie:

Status vanaf:

Status tot en met:

Type: Execute

Type: Enable Enable Enable Enable


80

Naam: Wijzigen Incidentgegevens Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Naam melder Email melder Telefoonnummer melder Onderwerp CaseId Omschrijving URL Categorie Diagnose Oplossing

Type: text text integer text text text text text text text

V/O O O O O O O O O O O

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities

Naar:

Operatie:

Van:

Triggers: Naam:


Wanneer:

Status vanaf:

Conditie:

Status tot en met:

Type:

Type: Enable


81

Naam: Informeren Klant Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Id Informatie aan Klant

Type: Integer Text

V/O V V

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities

Naar:

Operatie:

Van:

Triggers: Naam: Extra melding aan klant


Rechten: Rol: Servicedeskmedewerker Manager

Status vanaf: 11 11

Conditie:


Type: Execute

Type: Enable Enable


82

Naam: Interveniëren Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Email Reden Interventie

Type: Text Text

V/O V V

Map in: Condities

Naar:

Operatie:

Van:

Map out: Condities

Naar:

Operatie:

Van:

Triggers: Naam: Interventiemelding


Rechten: Rol: Manager

Status vanaf: 11

Conditie:


Type: Execute

Type: Enable


83

Naam: Voortijdig afsluiten Docin: Attribuutnaam:

Type:

V/O

Docout: Attribuutnaam: Reden voortijdige afsluiting

Type: Text

V/O V

Map in: Condities

Map out: Condities

Triggers: Naam: Notificatie voortijdige afsluiting


Naar:

Operatie:

Van:

Naar: Status

Operatie: ==

Van: 1010


Status vanaf: 11 11

Conditie:


Type: Execute

Type: Enable Enable


84

5.4.3 Automatische acties Deze acties worden automatisch door het platform uitgevoerd en hebben geen gevolgen voor de status. Omdat deze eze acties geen meerwaarde hebben voor de flow en geen duidelijke variabelen gebruiken omdat het generieke voorgedefinieerde services zijn, wordt hier alleen tekstueel uitgelegd wat deze objecten bewerkstelligen. Naam: Omzetting naar ServiceVerzoek Dit object roept een case-object object aan dat vanuit het niveau van een GrexxBoxx een Serviceverzoek case start. De variabelen Naam Melder, Email Melder, Telefoonnummer Melder en Omschrijving worden bij het starten tarten van deze case meegegeven, zodat de benodigde informatie tie voor het starten van een serviceverzoek bekend is. Naam: Set/Delete CaseRoles: Dit is een object dat een standaard service aanroept van de GrexxBoxx om rollen op een case te activeren of te deactiveren. Op basis van de status wordt bekeken welke rollen rolle aan of uit moeten staan. Hierdoor wordt het mogelijk om bijvoorbeeld de activiteit accepteren incident één keer te definiëren en op basis van de status te bepalen welke rol deze activiteit kan uitvoeren. Zodoende worden de verplichte taken alleen verplicht verplicht voor de rol die deze taak op dat moment moet uitvoeren. De rol van de Servicedeskmedewerker wordt geactiveerd als de status 21, 31 of 34 is. Voor alle andere waarden wordt deze rol gedeactiveerd. De rol van de Configuratieconsultant wordt geactiveerd alss de status 22 of 32 is en voor alle andere waarden gedeactiveerd. De rol ontwikkelaar wordt geactiveerd als de status 23 of 33 is en voor alle andere waarden gedeactiveerd. mailberichten Automatisch gegenereerde email Ook voor de automatisch gegenereerde email worden case-objecten objecten in de GrexxBoxx aangemaakt. Dit is ook een standaard service in de GrexxBoxx waarbij de volgende gegevens gegeven worden meegegeven bij het starten van de service: service • Afzender • Ontvanger(s) • Onderwerp • Welk template moet worden gebruikt. Hier kan zowel een html-template html als een plain-text versie (box box adres template) template worden gegeven. In de templates kan de casedata worden gebruikt door deze variabelen aan te geven tussen procenttekens. De bijbehorende waarde wordt dan da automatisch ingevuld. De data die d van belang is in de emailberichten ailberichten is behandeld in de business architectuur in sectie 4.2. De volgende activiteiten zijn automatisch gegenereerde emailberichten: • Informeer Servicedesk • Herinnering Registratietaak • Verzend Ontvangstbevesti vangstbevestiging • Notificatie Omzetting • Verzend Aanvullende Vraag • Informeer Klant over Oplossing Dennis van Roy (0491570) Incident Management in de GrexxBoxx

85

• • • • • • 5.5

Escalatiemelding Meld incident bij oplosgroep infrastructuur Interventiemelding Extra melding aan klant Automatische Escalatie Notificatie voortijdige afsluiting afsluiti Verificatie en validatie

Om de correctheid van het model aan te tonen wordt aangegeven dat het model voldoet aan de procesdefinitie van een workflow-net workflow en dat het model sound is. De procesdefinitie definitie van een workflow houdt in dat de workflow één startconditie start ‘i’ en één eindconditie ‘f’ heeft en dat de workflow geen nutteloze activiteiten bevat, bevat ofwel dat elke activiteit op een pad van ‘i’ naar ‘f’ ‘ ligt. Soundness van een workflowmodel houdt verder nog in dat: - Een case altijd moet kunnen eindigen. - Als een n case is beëindigd moet er één token in de eindplaats zijn en alle andere plaatsen zijn leeg. - er geen ‘dode’ activiteiten zijn, dat wil zeggen dat elke activiteit uitgevoerd kan worden Voor de formele definitie van de eigenschappen zie (Aalst, 1998). Geabstraheerd van de geautomatiseerde taken die geen invloed hebben hebben op het proces zoals de emailberichten is het et proces is een State Machine Workflow Net. Dit houdt in dat het model één starten eindplaats heeft en dat elke transitie nsitie één inkomende en één uitgaande pijl heeft (Isaac Corro Ramos, 2006). 2006) Dat het model één starten één eindplaats heeft is in Figuur 4-2 te verifiëren is. Verder kan het gehele model door exclusivee or’s gemodelleerd worden.. In dat geval heeft de workflow transities met alleen één inkomende en één uitgaande pijl. Doordat het model een state machine workflow net is, is het net 1-bounded bounded wat inhoudt dat als een case is geëindigd alle andere plaatsen leeg zijn. Verder is in Figuur 4-2 te zien dat er geen dode activiteiten zijn en alle activiteiten op een gericht pad van ‘i’ naar ‘f’ ‘ liggen. Het model voldoet al aan de soundness-eigenschappen soundness en is dus sound. Om te valideren of er geen fouten zijn gemaakt in de vertaling naar de GrexxBoxx zal het systeem drie maanden worden getest. In deze periode zal aan alle betrokken partijen worden gevraagd om verbeterpunten te verzamelen.. Na deze periode zal indien nodig op basis van deze punten een tweede versie van het Incident Management Systeem worden geconfigureerd.. In deze tweede versie zullen ook de missende onderdelen zoals besproken in sectie 5.3 zoveel mogelijk geïmplementeerd worden.


86

6

Evaluatie Incident dent Management Proces

Op basis van de factoren uit sectie 3.1 wordt behandeld of dat het nieuwe ontwerp bijdraagt aan het vertrouwen van de klanten en de beschikbaarheid van de GrexxBoxxen. GrexxBoxxen Zoals aangegeven was er in de initiële initië situatie geen registratie en overzicht van de incidenten. Hierdoor is ook geen nulmeting meting gedaan waardoor het lastig is te bepalen of de aspecten zijn verbeterd. Het is wel mogelijk te bepalen wat de bijdrage is van het nieuwe ontwerp om deze factoren te verbeteren. Deze worden hieronder kort samengevat. • Snelle reactie- en oplostijden: In het nieuwe ontwerp is duidelijkheid verschaft wie verantwoordelijk is voor de voortgang van de incidenten. Verder zijn deadlines duidelijk zichtbaar en wordt er automatisch sch geëscaleerd als deze zijn verlopen, verlopen wat resulteert in snelle reactiereactie en oplostijden. Dit kan de beschikbaarheid van de service voor de klanten verhogen en het vertrouwen vergroten door de directe feedback. • Klantinteractie: Doordat alle communicatie verloopt verloopt via de GrexxBoxx Servicedesk is er duidelijkheid bij de klanten waar ze incidenten kunnen aanmelden. Hierdoor weten klanten altijd via welk kanaal incidenten kunnen worden aangemeld om deze zo snel mogelijk te verhelpen. Dit kan het vertrouwen in vakantietijd vakantietijd en in de weekenden vergroten. • Goede documentatie: Het nieuwe ontwerp bevat dashboards dashboards die de behaalde resultaten kunnen aantonen. Hierdoor kan worden aangetoond of SLA’s gehaald worden. worden Het tonen van goede behaalde resultaten en referenties kan het vertrouwen bij nieuwe klanten vergroten. • Goede monitorring: Doordat alle incidenten worden geregistreerd is er een totaaloverzicht van de incidenten en kan snel worden ingegrepen als incidenten niet tijdig worden opgelost. Deze proactieve benadering zorgt voor een hogere beschikbaarheid en kan het vertrouwen vergroten. • Transparantie: Het nieuwe ontwerp geeft de klant inzicht in de voortgang van individuele incidenten en geeft door middel van dashboards een totaaloverzicht van incidenten over bepaalde periodes. Door een klant inzicht te geven in de status en de voortgang, kan het vertrouwen worden vergroot. • Overdraagbaarheid: Doordat alle incidenten op een uniforme manier worden geregistreerd, geregistreerd kan bij ziekte of vakantie een andere medewerker de incidentafhandeling inciden afhandeling van een case overnemen. Ook wordt kennis over alle incidenten opgeslagen in het systeem zodat deze niet verloren gaat en door werknemers kan worden teruggezocht. Hierdoor kan tijdens vakantieperiodes en ziektes het serviceniveau gewaarborgd blijven bl wat de beschikbaarheid verhoogd en het vertrouwen kan vergroten. • Schaalbaarheid: Doordat de werkwijze en de rollen duidelijk gespecificeerd zijn, is het mogelijk om bij verdere groei de kwaliteit minimaal gelijk te houden. Ook bij de groeiscenario’s kan de huidige manier van werken blijven bestaan, waardoor dit geen grote impact op de incidentafhandeling heeft.


87

Kostenreductie: Doordat alle incidenten bij de GrexxBoxx Servicedesk binnenkomen, kunnen eenvoudige incidenten meteen door de Servicedesk worden opgelost. Hierdoor worden de duurdere specialisten niet betrokken bij de relatief eenvoudige incidenten wat voor kostenreductie kan zorgen. Op basis van de documentatie kan in de toekomst worden bekeken of SLA’s behaald worden en welke factoren nog verbetering behoeven. behoeven •


88

7

Oordeel GrexxBoxx

Grexx wil graag een oordeel of dat de GrexxBoxx een adequate ondersteuning biedt voor de implementatie van het Incident Management Systeem. Dit kan worden onderverdeeld in de ondersteuning voor de configuratie van de GrexxBoxx en de ondersteuning voor de uitvoering van het operationele proces. proces In dit hoofdstuk beschrijf ik daarom kort mijn bevindingen over de GrexxBoxx over deze twee onderwerpen. 7.1

Ondersteuning procesconfiguratie

De flow kan door middel van status, door middel van triggers en door een combinatie van deze twee worden afgedwongen. Hierdoor heeft de configurator de mogelijkheid om de oplossing te kiezen die het minste configuratiewerk vraagt en daardoor vaak ook overzichtelijker is. Dit zorgt er vooral voor dat processen die niet volgens een vaste procedure verlopen, maar waar ruimte is voor uitvoerders om hun eigen werk te organiseren, eenvoudig kunnen worden ingericht. Des te meer ruimte er gelaten wordt voor eigen organisatie, des te minder er namelijk namelijk in de GrexxBoxx geconfigureert hoeft te worden. Door de vele optionele taken in het h Incident Management Proces is er veel ruimte voor eigen organisatie. Doordat er ook een duidelijke hoofd-flow in het proces is, kan er optimaal gebruik gemaakt worden van van de twee mogelijkheden om de flow af te dwingen. Verder kan door middel van rechten eenvoudig worden bepaald wie op welk moment het recht heeft om een activiteit uit te voeren, waardoor activiteiten zoals ‘Accepteren Incident’, maar één keer gedefinieerd hoeft te worden en met behulp van rollen en rechten bepaald wordt wie op dat moment de activiteit moet uitvoeren. Verder is de GrexxBoxx dusdanig ontwikkeld dat het erg eenvoudig is om lopende processen aan te passen. Dit komt onder andere doordat de flow niet in een overall procesmodel wordt opgeslagen, maar op basis van activiteiten wordt bepaald. Ook is de GrexxBoxx eenvoudig uitbreidbaar wanneer behoefte is aan extra functionaliteit. Een goed voorbeeld hierbij is de ‘Group-And ‘Group Service’ die later is toegevoegd evoegd om de And-constructie And constructie uit Petrinetten na te bootsen. Dit soort services kunnen generiek worden gedefinieerd, waardoor ze eenvoudig te hergebruiken zijn. Een negatief punt voor de configuratie is dat de GrexxBoxx nagenoeg niet gedocumenteerd is en niet iet erg intuïtief is. Hierdoor gaat veel tijd verloren om bekend te raken met de configuratiemogelijkheden van de GrexxBoxx. GrexxBoxx. Momenteel wordt er hard aan gewerkt om de GrexxBoxx intuïtiever te maken en het formulierontwerp is al een eerste opzet naar de documentatie umentatie die de GrexxBoxx nodig heeft. Ook gaat de keuze voor een generiek en makkelijk aanpasbaar ontwerp ten koste van de verificatiemogelijkheden. mogelijkheden. Bij de complexe modellen die in de GrexxBoxx worden ontworpen, is het moeilijk aan te geven en vooral om te bewijzen dat alle mogelijke flows eindigen en er dan geen activiteiten meer uitgevoerd kunnen of moeten worden. Hierdoor is validatie een erg belangrijk onderdeel in het ontwikkelproces van configuraties. Na het opleveren van elke versie, wordt eerst een en acceptatieversie voor de klant klaargezet die getest moet worden. 7.2

Ondersteuning Operationeel Proces

Door de combinatie van verplichte en optionele taken in de GrexxBoxx wordt, wordt ondanks dat de verplichte procedure duidelijk wordt aangegeven, toch duidelijk duidelijk gemaakt welke keuzes de uitvoerder heeft. De verplichte taken worden in de GrexxBoxx in een duidelijk blok weergegeven en door middel van het openen van bepaalde cases kan bekeken worden welke optionele activiteiten mogelijk zijn. Hierdoor kunnen alternatieve tieve flows worden Dennis van Roy (0491570) Incident Management in de GrexxBoxx

89

gekozen die misschien zelfs efficiënter blijken te zijn. Door dit via een volledige audit trail bij te houden, kan hiervan uiteindelijk geleerd worden. Het uitvoeren van cases gebeurt hierdoor op een zeer intuïtieve manier, waarbij een korte korte uitleg voldoende is voor uitvoerders.


90

Literatuur Best practices in business process redesign: an overview and qualitative evaluation of sucessful redesign heuristics [Journal] / auth. Reijers H.A and Mansar S. Liman. - [s.l.] : Omega ga The International Journal of Management Science. - 33 : Vol. 2005. De kleine ITIL V3 [Book] / auth. L. Peeters M. Bordewijk, J. Ermers. - Den Haag : Sdu uitgevers b.v., 2008. GrexxBoxx, A foundation for Cloud Collaboration [Book] / auth. Ton Romeyn Erica Eric Rietveld. - Naarden : [s.n.], 2009. Implementatie IT service management [Book] / auth. Peeters L.. - Den Haag : ten Hagen en Stam uitgevers, 2003. ITIL en dienstverlening [Book] / auth. H. Kisters E. van Kollenburg. - Schoonhoven : Academic Service, 2003. ITIL Service Operation [Book] / auth. Commerce Office of Government. - [s.l.] : Stationary Office Books, 2007. IT-Service Service Management volgens ITIL [Book] / auth. Janssen Peter. - Benelux : Pearson Education, 2003. IT-servicemanagement servicemanagement op basis van ITIL V3 - een pocketguide [Book] / auth. Bon J. van. Zaltbommel : Van Haren Publishing, 2007. Official Introduction to the Itil Service Lifecycle [Book] / auth. (OGC) Office of Government Commerce. - [s.l.] : TSO, 2007. Synthesis and Reduction of State Machine Workflow Nets [Journal] / auth. Isaac Corro Ramos Alessandro Di Bucchianico, Lusine Hakobyan, Kees van Hee. - Eindhoven : Technische Universiteit Eindhoven, 2006. The Application of Petri Nets to Workflow Management [Journal] / auth. Aalst W.M.P. van der /// The journal of Circuits, Systems and COmputers. - 1998. - pp. 21-66. 66. wikipedia [Online] // Information Technology Infrastructure Library. - 06 25, 2009. http://en.wikipedia.org/wiki/Information_Technology_Infrastructure_Library. Yasper Process Modeling Software [Online] / auth. TUe. - Technische Universiteit Eindhoven. - 01 25, 2010. - http://www.yasper.org/.


91

Incident Management in de GrexxBoxx

Recommend Documents