5. ITIL voor Dorb Logistics
advertisement
ITIL Advies ITIL Advies Eindhoven Schooljaar 2004-2005 10-09-2004 Versie 1.1 Voorwoord Dit rapport is geschreven in opdracht van Dorb Logistic in het kader voor verbetering en kostenbesparing van de IT-infrastructuur in hun organisatie. Het is voor Dorb Logistic voor de hand liggend dat er op beheertechnisch niveau een zo hoog mogelijke kwaliteit aanwezig is. Hierbij moet tevens gekeken worden naar de kosten. De inhoud van dit rapport is informatief. Er worden verschillende adviezen gegeven betreffende ITIL binnen Dorb Logistics. Dit rapport is bestemd voor Dorb Logistic en dient voor verbetering van de ITinfrastructuur binnen hun organisatie m.b.v. ITIL. Dit rapport is tot stand gekomen doordat we een opdracht kregen van de Dorb Logistic. In het bijzonder willen wij de heer H. Chin a Tsjoe en de heer S. Ibanez bedanken, want zonder hun gegevens was het onmogelijk om tot een goed advies te komen voor hun organisatie. Eindhoven, september 2004 3 Inhoudsopgave SAMENVATTING .....................................................................................................................................5 1. INLEIDING ..........................................................................................................................................6 2. WAT IS ITIL? .....................................................................................................................................7 2.1 CONFIGURATIEBEHEER ......................................................................................................................8 2.2 INCIDENTBEHEER ...............................................................................................................................9 2.3 SERVICEDESK ...................................................................................................................................11 2.4 PROBLEEMBEHEER ............................................................................................................................13 2.5 WIJZIGINGSBEHEER .........................................................................................................................14 2.6 UITGAVENBEHEER ............................................................................................................................15 2.7 BEVEILIGINGSBEHEER......................................................................................................................16 2.8 FINANCIEEL BEHEER .........................................................................................................................17 2.9 CONTINUÏTEITSBEHEER ...................................................................................................................18 2.10 BESCHIKBAARHEIDBEHEER ...........................................................................................................20 2.11 CAPACITEITSBEHEER .....................................................................................................................21 2.12 DIENSTENNIVEAUBEHEER .............................................................................................................22 3. DE HUIDIGE SITUATIE DORB LOGISTICS .......................................................................23 4. KNELPUNTEN VAN DORB LOGISTICS ................................................................................24 5. ITIL VOOR DORB LOGISTICS .................................................................................................25 5.1 EISEN AAN OPERATIONELE EN TACTISCHE PROCESSEN ................................................................25 5.2 ADVIES DORB LOGISTIC ..................................................................................................................30 6. TWEE OPERATIONELE PROCESSEN VOOR DORB LOGISTICS ..............................32 6.1 ACTIVITEITEN CONFIGURATIEBEHEER ............................................................................................32 6.2 ACTIVITEITEN INCIDENTBEHEER .....................................................................................................36 7. VOORSTEL OPZET VAN EEN SLA ...........................................................................................40 7.1 INTRODUCTIE ...................................................................................................................................40 7.2. ICT OBJECTEN ................................................................................................................................41 7.3 GEBRUIKERSONDERSTEUNING ........................................................................................................41 7.4 BEVEILIGING.....................................................................................................................................43 7.5 UITWIJK ............................................................................................................................................44 7.6 WIJZIGINGEN ...................................................................................................................................44 8. CONCLUSIES EN AANBEVELINGEN .....................................................................................46 LITERATUURLIJST ..............................................................................................................................47 1. ORGANIGRAM ......................................................................................................................................48 2. ICT MIDDELEN DORB LOGISTICS ®................................................................................................49 3. TOOLS TER ONDERSTEUNING VAN DE BEHEERSOMGEVING .............................................................51 4. CONTACTPERSONEN............................................................................................................................54 5. ONDERSTEUNINGBELEID .....................................................................................................................55 4 Samenvatting Dorb Logistics heeft ons, IT Brabant, ingehuurd om een advies te geven over ITIL voor hun organisatie. Dit rapport behandelt een ITIL advies voor Dorb logistics. De achtereenvolgende hoofdstukken gaan in op huidige IT-infrastructuur situatie en hoe deze situatie verbeterd kan worden. Dit betekent streven naar een betere functionaliteit van de IT-infrastructuur. Doormiddel van het uitvoeren van operationele en tactische processen wordt de IT-infrastructuur van Dorb Logistics verbeterd. De conclusie is dat wanneer ITIL goed wordt uitgevoerd bij Dorb Logistics de functionaliteit stijgt. Tevens worden, door tijdsbesparing, minder noodzakelijkheid van experts, tevreden werknemers en klanten, de kosten geminimaliseerd. 5 1. Inleiding In dit rapport geven we als IT Brabant NV advies aan Dorb Logistics over het in gebruik nemen van ITIL in hun organisatie. Dit is van belang om hun ITinfrastructuur en IT-diensten beter te laten functioneren. In hoofdstuk 2 wordt uitgelegd wat met ITIL wordt bedoeld. Hierbij worden de twee processen, operationele- en tactische processen, beschreven. In hoofdstuk 3 hebben we de huidige situatie van Dorb Logistics grondig onderzocht en beschreven. In hoofdstuk 4 worden de knelpunten beschreven die uit de huidige situatie gehaald kunnen worden. Hierin worden nog geen adviezen gegeven. In hoofdstuk 5 wordt beschreven waarom ITIL belangrijk kan zijn voor Dorb Logistics. Hierin worden de eisen van ITIL voor Dorb Logistics beschreven en er wordt een advies gegeven. Het advies wordt nader uitgelegd m.b.v. een Tool. Wat er met deze Tool wordt bedoeld wordt in dit hoofdstuk beschreven. In hoofdstuk 6 worden de 2 operationele processen, configuratiebeheer en incidentbeheer, nader beschreven. Er wordt gekeken hoe deze processen worden toegepast bij Dorb Logistics, waardoor de kwaliteit en functionaliteit stijgt. In hoofdstuk 7 wordt de opzet van een SLA (Service Level Agreement) beschreven. Hierin komen ICT objecten, gebruikersondersteuning, beveiliging, uitwijk en wijziging aan bod. Tenslotte zijn in de bijlagen ICT middelen, Tools ter ondersteuning van beheersomgeving, contactpersonen en ondersteuningbeleid te vinden. 6 2. Wat is ITIL? In dit hoofdstuk komen alle operationele en tactische processen aan bod. Van ieder proces wordt een kleine omschrijving gegeven wat het doel is binnen de ITinfrastructuur van Dorb Logistics. De afgelopen decennia is de complexiteit van de IT-infrastructuur belangrijk toegenomen. Juist vanwege die groeiende complexiteit is uniformiteit in het beheer noodzakelijk. ITIL staat voor Information Technology Infrastructrure Library. Het is een verzameling boeken waarin processen worden beschreven die uitgevoerd worden voor het beheer van de IT-infrastructuur. ITIL wordt onderverdeeld in 2 lagen, namelijk het tactische beheer en het operationele beheer. Tactisch beheer: - Capaciteitsbeheer; Beschikbaarheidbeheer; Continuïteitsbeheer; Financieel beheer; Beveiligingsbeheer. Operationeel beheer: - Configuratiebeheer; Incidentbeheer; Probleembeheer; Wijzigingsbeheer; Uitgavenbeheer. O p d r a c h t g e v e r G e b r u i k e r s Financieel Beheer Dienstenniveaubeheer ContinuiteitsBeheer Beschikbaarheidsbeheer Capaciteitsbeheer Beveiligings beheer Service Support Set Incidentbeheer Service Delivery Set Wijzigingsbeheer Uitgavenbeheer Probleembeheer Configuratiebeheer Figuur 2.1: geeft de samenhang tussen tactische en operationele processen weer. 7 T o e l e v e r a n c i e r s 2.1 Configuratiebeheer Configuratiebeheer is het proces dat zich enerzijds richt op het onder controle brengen van de veranderde IT-infrastructuur en anderzijds de informatievoorziening hierover verzorgt. Het verschaft een logisch model van de infrastructuur of een dienst door te identificeren, te beheren, te controleren en de versies van bestaande configuratie items (CI’s) te verifiëren. Door configuratiebeheer goed uit te voeren is een organisatie in staat te weten waar wat staat, hoe het met elkaar samenhangt en in welke toestand het zich bevindt. Dit kan gerealiseerd worden als alleen geautomatiseerde componenten deel uitmaken van de IT-infrastructuur en mogen alleen goedgekeurde wijzigingen doorgevoerd worden. CI’s moeten goed geregistreerd worden d.w.z. alle componenten, subcomponenten en alle relaties tussen de twee. Deze gegevens worden allemaal vastgelegd in een zogenaamde configuratiebeheerdatabase (CBDB). Het CDBD is afhankelijk van de volgende zaken: - de omvang van de IT-infrastructuur; - het aantal verschillende soorten systemen; - het bereik van configuratiebeheer - het detailleringniveau en - het aantal attributen en relaties. De CDBD moet alle geregistreerde CI’s en hun relaties bevatten die binnen het verantwoordelijks gebied van configuratiebeheer vallen. Tevens komt in de CDBD informatie te staan over incidenten, problemen, onderkende fouten, wijzigingen en uitgaven die gekoppeld zijn aan CI’s. gepland gerealiseerd getest geimplementeerd operationeel in onderhoud gearchiveerd TIJD Figuur 2.2: geeft beheer van de ci’s weer. Elk punt (groene punten) geeft een fase aan die links staan beschreven. Het valt op dat wanneer een systeem in onderhoud komt dat er een systeem, dat al gearchiveerd is, weer tijdelijk operationeel wordt (blauwe punten). 8 2.2 Incidentbeheer Wanneer zich in een IT-afdeling een probleem voordoet zoals “doet het niet” of als de gebruiker toegang wenst tot een nieuwe IT-dienst, dan zal de IT-afdeling daar snel op moeten reageren. Voor een IT-afdeling is het noodzakelijk om afspraken te maken over de aard, omvang en kosten van de te leveren IT-diensten. Maar ook over hoe gereageerd wordt op afwijkingen in de verwachte IT-dienstverlening. Incidentbeheer zorgt voor de dagelijkse afhandeling van incidenten. Aan de hand van dit proces wordt iedere afwijking van het afgesproken dienstniveau behandeld en, waar mogelijk, wordt het dienstniveau opgelost en hersteld. Het belangrijkste doel van incidentbeheer is het zo snel mogelijk herstellen van de dienstverlening door het minimaliseren van de gevolgen van storingen, zodat gebruikers zo snel mogelijk weer aan het werk kunnen. Als incidentbeheer goed wordt uitgevoerd zal iedere afwijking van het dienstniveau snel geregistreerd en opgelost worden. Door het verbeteren van de ondersteuning van de gebruikers zal verstoring van de primaire bedrijfsprocessen gereduceerd worden, wat de totale organisatie ten goede komt. Het proces draagt zo bij aan het voldoen aan een hoge kwaliteit van de ITdienstverlening. Het is zaak om storingen systematisch af te handelen zodat hooggekwalificeerde medewerkers (experts) alleen gestoord dienen te worden wanneer hun expertise noodzakelijk wordt geacht. Het proces incidentbeheer heeft de taak te reageren op ongewenste storingen. Dit eist snelheid en daarom is het verstandig een formele manier van incidentafhandeling te hanteren. De activiteiten die door incidentbeheer worden uitgevoerd worden onderverdeeld in de volgende deelactiviteiten: - detecteren en registreren; classificeren en toewijzen; onderzoeken en diagnosticeren; oplossen en herstellen; afsluiten en voortgangsbewaking en communicatie. 9 Alle activiteiten samen vormen een incident-levenscyclus (zie figuur 2.3). De status van een activiteit is op te maken uit de huidige positie in die cyclus. Het moet voor iedereen duidelijk zijn wat die status inhoudt om de voortgang van het incident te kunnen bewaken. Incident detecteren en registreren Voortgangsbewaking en communicatie Incident classificeren en toewijzen Ja Procedure serviceverzoek Service verzoek Nee Onderzoek en Diagnose Oplossen en Herstel Incident afsluiten Figuur 2.3: Incident-levenscyclus. Aan incidenten worden prioriteiten gesteld. Deze prioriteiten worden bepaald door de factoren impact, urgentie en verwachte inspanning. Tevens krijgen alle incidenten een nummer zodat alles op een geordende manier kan worden vastgelegd. Het vastleggen van alle incidenten met de daarbij horende status zorgt ervoor dat incidenten sneller kunnen worden hersteld en dus kunnen worden afgesloten. Bij dit afsluiten blijven de gegevens zoals CI-nr, incidentcategorie en impactcode bewaard, zodat probleemidentificatie en diagnose mogelijk blijft. Net zoals bij configuratiebeheer dient de DBD up-to-date te blijven om een goed werkende IT-dienstverlening mogelijk te maken. 10 2.3 Servicedesk De servicedesk is een centraal loket voor gebruikers. Het biedt continuïteit in de ITdienstverlening door het faciliteren van een zo spoedig mogelijk herstel van het afgesproken dienstniveau. Het maakt de IT-afdeling toegankelijk voor klanten. Het is een punt voor dagelijks contact met betrekking tot het gebruik van de IT-infrastructuur. De servicedesk moet niet alleen in staat zijn om te reageren op vragen van klanten, zij dient zich ook actief te richten op de opdrachtgevers om op die manier de totale IT-afdeling te profileren als betrouwbare en flexibele partner in het realiseren van de bedrijfsdoelstellingen. Het professionaliseren van deze contacten moet leiden tot wederzijds begrip tussen directe gebruiker en de IT-afdeling. Verhoging van de toegevoegde waarde van de IT-dienstverlening kan in veel gevallen gerealiseerd worden door te weten wat de wensen en behoeften van de gebruikers van IT-diensten zijn. Anderzijds moeten gebruikers inzicht krijgen in de mogelijkheden en onmogelijkheden. Als de servicedesk deze aspecten goed beheerst, kan dit leiden tot een toenemende gebruikerstevredenheid. Daarom is de servicedesk een van de belangrijkste functies van een IT-afdeling. Door het verbeteren van de ondersteuning aan de gebruiker zal verstoring van de primaire processen gereduceerd worden, wat de totale organisatie ten goede komt. Het is een taak van de servicedesk om gebruikers te informeren over de status eb voortgang van incidenten. Het is belangrijk de scope (bereik) en taken van de servicedesk te definiëren en te communiceren. Medewerkers van de servicedesk en gebruikers die de servicedesk benaderen, horen te weten wat zij van elkaar mogen verwachten. Een manier om de scope van een servicedesk te beschrijven is in termen van taken en activiteiten. Enkele hiervan zijn: - - communicatie en promotie; continuïteit van dienstverlening het bewaken van de incidentafhandeling initiële beoordeling van incidenten en verzoeken bewaken van het dienstniveau coördinatie van activiteiten bijdragen leveren aan probleemidentificatie signaleren van trainingsbehoefte informatievoorziening 11 Gebruiker 1 Gebruiker 2 Gebruiker 3 Servicedesk Tweede lijnondersteuning Externe leverancier Applicatie ondersteuning Netwerk ondersteuning Ondersteuning pc-gebruik Figuur 2.4: Geeft een weergave van een servicedesk Acceptatie van de IT-afdeling is nauwelijks te realiseren als de communicatie tussen de servicedesk en de gebruikers van IT-diensten niet optimaal is. Hiervoor is het noodzakelijk dat de servicedesk inzicht heeft in zowel de verschillende groepen gebruikers als de diensten die door de IT-afdeling geleverd worden. Deze informatie dient geleverd te worden middels correcte en bijgewerkte dienstniveauovereenkomsten, afgesloten tussen opdrachtgevers en de IT-afdeling. 12 2.4 Probleembeheer Probleembeheer streeft naar een zo hoog mogelijke stabiliteit van de ITdienstverlening en het minimaliseren van het nadelige effect op de organisatie van fouten in de IT-infrastructuur door het laten achterhalen, wegnemen en voorkomen van structurele fouten in de infrastructuur. Met de stabiliteit van de dienstverlening wordt bedoeld het met zo min mogelijk verstoringen beschikbaar stellen van de ITinfrastructuur. Op het moment dat zich verstoringen voordoen is het de taak van incidentbeheer de gevolgen van de verstoring zo veel mogelijk te beperken. De belangrijkste bijdrage van probleembeheer is het nemen van structurele maatregelen om (herhaling van) verstoringen te voorkomen. Door de inspanning van de organisatie te verleggen van het reageren op grote aantallen incidenten naar het voorkomen van deze incidenten, kan doelmatiger gebruik worden gemaakt van de beschikbare kennis in de beheerorganisatie. Incidenten die zich op willekeurige momenten voordoen, vergen meer tijd van de beheerorganisatie dan het aanbrengen van een structurele wijziging waarmee deze incidenten voorkomen worden. Dit is met name het geval wanneer zich veel overeenkomstige incidenten voordoen. Tevens kan het gericht zoeken naar structurele verbeteringen van de infrastructuur op een meer planmatige manier plaatsvinden zodat een grotere controle over de werkzaamheden wordt verkregen. Hoewel in eerste instantie een grotere inspanning van de organisatie vereist is, zal na verloop van tijd het aantal incidenten teruglopen of zal de impact van incidenten afnemen als gevolg van een stabieler systeem. Daar waar incidentbeheer zich voornamelijk richt op het oplossen van incidenten, bestaat het doel van probleembeheer uit het wegnemen of voorkomen van fouten in de infrastructuur ten einde een zo hoog mogelijke stabiliteit in de IT-dienstverlening te bereiken. Exploitatie Incidenten Probleem Onderkende fout Beheer Figuur 2.5: Incidenten, problemen en onderkende fouten 13 2.5 Wijzigingsbeheer Wijzigingen in de IT-infrastructuur, zoals een nieuwe functionaliteit of uitbreiding van capaciteit, dienen regelmatig en succesvol te worden aangebracht. Elke wijziging in het systeem is echter een potentiële bedreiging voor de stabiliteit van het systeem. Als de gegevensstructuur in een database wordt veranderd, dan zal de programmatuur die van die gegevens gebruikmaakt, ook gewijzigd moeten worden om te voorkomen dat zij als gevolg van de wijziging niet meer juist functioneert. Het doel van wijzigingsbeheer is de noodzakelijke wijzigingen zodanig uit te (laten) voeren dat verstoringen en afwijkingen van het dienstenniveau als gevolg van de wijzigingen zo min mogelijk voorkomen. Hiertoe wordt er op toegezien dat beproefde methoden en technieken gebruikt worden voor de voorbereiding, bouw, test en implementatie van nieuwe of gewijzigde configuratie-items. In één zin zou het doel van wijzigingsbeheer samengevat kunnen worden als: zeker stellen dat gestandaardiseerde methoden en technieken gebruikt worden voor een efficiënte en directe afhandeling van alle wijzigingen, zodat aan wijzigingen gerelateerde incidenten voorkomen worden. Wijzigingsbeheer beperkt zich niet alleen tot wijzigingen in de programmatuur of de apparatuur waaruit een systeem is opgebouwd. Voor alle componenten van de infrastructuur geldt dat een wijziging die invloed kan hebben op het dienstenniveau, uitgevoerd moet worden onder controle van wijzigingsbeheer. Hieronder vallen dus ook wijzigingen in documentatie, procedures en overeenkomsten met betrekking tot de dienstverlening. Figuur 2.6: Het wijzigingstraject 14 2.6 Uitgavenbeheer Het belangrijkste doel van uitgaven beheer is te kunnen garanderen dat alle aan wijziging onderhevige programmatuur en (gerelateerde) apparatuur traceerbaar en zeker is, en dat uitsluitend correcte, geautoriseerde en geteste versies beschikbaar worden gesteld aan de exploitatieomgeving. Dit hoofddoel brengt enkele afgeleide doelen met zich mee, zoals het plannen en managen van de uitrol van apparatuur en programmatuur, het ontwerpen en invoeren van procedures voor implementatie en distributie van uitgaven met minimale consequenties voor de IT-dienstverlening, het communiceren van en sturen op verwachtingen en het zoeken van toestemming van de opdrachtgever en gebruiker voor een uitgave. Kortom, het gaat om de beveiliging van de exploitatieomgeving en de bijbehorende diensten middels het gebruik van formele procedures en controles, met name tijdens omvangrijke wijzigingen in programmatuur en apparatuur. Het proces uitgavenbeheer richt zich op het wijzigen van (vaak relatief grote hoeveelheden) programmatuur en apparatuur. Dit impliceert een zeer sterke samenhang met wijzigingsbeheer en con6guratiebeheer. Voor het in exploitatie brengen van de programmatuur en apparatuur dient het proces afgestemd te zijn op wijzigingsbeheer. Het implementeren van een uitgave vindt altijd plaats in het kader van een of meer wijzigingen. Het wijzigingsverzoek waarin de uitgave van nieuwe of gewijzigde programmatuur en apparatuur wordt beschreven, dient dan ook als onderdeel van het wijzigingstraject geautoriseerd te worden. Aangezien programmatuur deel uitmaakt van de IT-infrastructuur, is zij ook onderworpen aan het beleid van con6guratiebeheer, hetgeen tot een nauwe relatie tussen uitgavenbeheer en con6guratiebeheer leidt. Om de programmatuur zeker te stellen wordt de inhoud van alle uitgaven bewaard in een programmatuurbibliotheek. De kenmerken van bijbehorende apparatuur worden geregistreerd in de con6guratiebeheerdatabase. In zekere zin delegeren wijzigingsbeheer en con6guratiebeheer de complexe en speci6eke beheersingsfunctionaliteit rond de implementatie van (grote hoeveelheden) programmatuur en (gerelateerde) apparatuur aan een derde proces, genaamd uitgavenbeheer. Het uitgavenbeheer opereert daarom onder invloed van het beleid en staat deels onder controle van con6guratie- en wijzigingsbeheer. Gezamenlijk, in nauwe samenwerking, verzekeren deze drie dat de gedeelde con6guratiebeheerdatabase wordt bijgehouden. Hierboven worden de termen 'grote hoeveelheden' en 'gerelateerde apparatuur' gebruikt om het speci6eke karakter van het proces uitgaven beheer te onderstrepen. Niet elke programmatuur- of apparatuurwijziging valt binnen de scope van uitgavenbeheer. De vervanging van een enkele pc of de invoering van batchprogramma's op een mainframe zullen meestal gewoon direct door wijzigingsbeheer afgehandeld worden. Het proces uitgavenbeheer wordt met name aanbevolen voor het uitrollen (verspreiden) van veel of zeer kritische apparatuur, niet noodzakelijk gecombineerd 15 met programmatuur. Alle gecombineerde programmatuurwijzigingen, met name wanneer er een afhankelijke relatie bestaat met wijzigingen in de programmatuur uit de exploitatieomgeving, vallen tevens binnen de scope van uitgavenbeheer. De vraag welke taak door welk van de drie processen wordt uitgevoerd hangt af van het type en de omvang van de organisatie en de IT-infrastructuur, maar moet in ieder geval van tevoren en eenduidig worden beantwoord. Figuur 2.7: Versiebeheer in gescheiden omgevingen 2.7 Beveiligingsbeheer Vrijwel iedere organisatie is in de loop van de laatste decennia afhankelijker geworden van IT. Tevens is het gebruik van computernetwerken toegenomen; niet alleen binnen organisaties, maar ook tussen verschillende organisaties en tussen organisaties en consumenten. Door de toegenomen complexiteit van de ITinfrastructuur zijn organisaties kwetsbaarder geworden voor technische storingen, (on)bedoelde menselijke fouten, hackers, computervirussen enzovoort. Juist vanwege die groeiende complexiteit is uniformiteit in het beheer noodzakelijk. Beveiligingsbeheer heeft relaties met zowel de tactische als de operationele ITILprocessen. Figuur 2.8 toont deze relaties. Het doel van het proces beveiligingsbeheer is tweeledig: - enerzijds het voldoen aan de beveiligingseisen in de DNO's en andere externe vereisten zoals in contracten, wetgeving en eventueel opgelegd beleid; - anderzijds het realiseren van een zeker basisniveau aan beveiliging. Het is noodzakelijk om de continuïteit van de beheerorganisatie te waarborgen. De invoer van het proces wordt gevormd door de DNO's met daarin de gespecificeerde beveiligingseisen, aangevuld met beleidsdocumenten. Beveiligingsbeheer levert informatie op over de realisatie van de DNO's. De bedrijfsbelangen zijn het uitgangspunt voor een nadere uitwerking van de te nemen beveiligingsmaatregelen op zowel strategisch, tactisch als operationeel niveau. De activiteiten op de verschillende niveaus vereisen samenhang en 16 coördinatie. De huidige praktijk is dat bij veel organisaties beveiliging op strategisch niveau aandacht krijgt in informatiebeleid en informatieplannen. Op operationeel niveau worden veelal technische beveiligingsproducten aangeschaft. Het actief beheren van beveiliging, het continu analyseren en vertalen van het beleid naar technische) alternatieven en het zorgen dat de beveiligingsmaatregelen adequaat blijven, krijgen vaak onvoldoende aandacht. Het gevolg van deze ontbrekende schakel op tactisch niveau is dat veel geld wordt geïnvesteerd in maatregelen die niet meer relevant zijn, terwijl nieuwe, meer effectieve maatregelen, niet worden genomen. Op alle organisatieniveaus moeten beveiligingsmaatregelen zijn genomen om informatie voldoende te kunnen beveiligen. Figuur 2.8: relaties tussen beveiligingsbeheer en andere ITIL processen 2.8 Financieel beheer Financieel beheer heeft als doel het faciliteren van een kosteneffectiefbeheer van ITmiddelen, nodig voor het leveren van IT-diensten. Door dit proces wordt het mogelijk de kosten die worden besteed aan het leveren van IT-diensten te budgetteren, te identificeren en te verrekenen. Het is voor alle betrokkenen, zowel aan de afnemerskant als aan de aanbiederkant, van belang dat de kwaliteit van IT-diensten optimaal is en dat ze tegelijkertijd tegen gerechtvaardigde kosten worden gerealiseerd. Bij de planning en beheersing van de IT-dienstverlening zijn financiële gegevens van onschatbare waarde. Met behulp van de informatie uit financieel beheer kan de leiding de bedrijfsprocessen sturen. Tot de subdoelstellingen van financieel beheer behoren: - berekenen van de kosten van het leveren van IT-diensten; - identificeren en classificeren van de samenstelling van deze kosten; - redelijkerwijs toewijzen van gemaakte kosten aan de IT-diensten die aan zowel interne als externe afnemers worden aangeboden; - introduceren van verrekenmethodes voor het gebruik van de IT-diensten; - op gezette tijden controleren van verrekeningen om zo te bepalen of ze nog reëel en economisch verantwoord zijn. 17 Bij het opstellen van SLA’s (Service Level Agreement) is het afgesproken dienstenniveau van invloed op de kosten. Het verruimen van de openstellingduur van IT-diensten, het uitbreiden van schijfruimte of het verkorten van de responsietijd brengt additionele kosten met zich mee. Het is mogelijk dat de betrokken opdrachtgever afziet van zijn vraag zodra bekend wordt welke kosten daarmee samenhangen. Het proces financieel beheer brengt de kosten van een IT-dienst onder controle. De introductie van financieel beheer is een strategische beslissing van de organisatie die invloed heeft op het leveren van IT-diensten en de perceptie van de IT-diensten door de afnemer. Het proces is als het ware de link tussen de ITdienstenorganisatie en de bedrijfsorganisatie. De IT-dienstenorganisatie moet voldoen aan de behoeften van de organisatie, en het is van belang dat inzichtelijk is wat de kosten zijn die hieraan zijn verbonden. Voordat de organisatie bepaalde keuzes maakt, heeft de organisatie informatie nodig vanuit het proces financieel beheer. Voorafgaand aan de behandeling van de activiteiten binnen financieel beheer, wordt eerst een aantal bedrijfseconomische termen toegelicht. Figuur 2.9: Financieel beheer als brug tussen IT en organisatie 2.9 Continuïteitsbeheer Het proces continuïteitsbeheer heeft als doel het overkoepelende proces continuïteitsbeheer van bedrijfsprocessen te ondersteunen door zeker te stellen dat de IT-infrastructuur en de IT-diensten na een calamiteit worden hersteld binnen de met de afnemer afgesproken tijd. Het aandachtsgebied van continuïteitsbeheer wordt afgeleid van de verzameling geïdentificeerde bedrijfsprocessen. Continuïteitsbeheer van bedrijfsprocessen houdt zich bezig met het beheer van de continuïteit van de gehele organisatie. Dit omvat dus alle diensten waar de organisatie van afhankelijk is, inclusief de IT-diensten. Continuïteitsbeheer van bedrijfsprocessen is betrokken bij het analyseren en beheersen van risico's, zodat de organisatie te allen tijde een minimum aan noodzakelijke productiecapaciteit of dienstverlening kan waarborgen. Continuïteitsbeheer richt zich op calamiteiten die de IT-dienstverlening kunnen verstoren. 18 Tot de subdoelen van continuïteitsbeheer behoren: - het schatten van de gevolgen van een calamiteit voor de IT-dienstverlening; - het opsporen van bedrijfskritieke IT-diensten waarvoor maatregelen moeten worden getroffen; - het nemen van preventieve, detectieve en repressieve maatregelen om calamiteiten te voorkomen of bij het optreden van calamiteiten de gevolgen te verminderen; - het opstellen van een plan waarin wordt weergegeven hoe diensten dienen te worden hersteld na een calamiteit; - het opstellen, testen en onderhouden van een uitwijkplan om een calamiteit te kunnen overleven en de normale IT-dienstverlening te kunnen herstellen. Figuur 2.10: fasen en activiteiten continuïteitsbeheer 19 2.10 Beschikbaarheidbeheer Beschikbaarheidbeheer heeft als doel tegen gerechtvaardigde kosten de met de afnemer overeengekomen beschikbaarheid van IT-diensten te waarborgen door het optimaliseren van de IT-infrastructuur en de beheerorganisatie. Het kwaliteitsaspect dat het proces beschikbaarheidbeheer onder controle brengt, is de beschikbaarheid van een IT-dienst. De eisen en wensen van de organisatie betreffende beschikbaarheid van IT-diensten zijn sturend voor de invulling van het proces beschikbaarheidbeheer. De beschikbaarheid van IT-diensten is van belang voor het realiseren van de bedrijfsdoelstellingen. Om de cruciale elementen van een door een IT-dienst ondersteund bedrijfsproces aan te geven, wordt de term 'bedrijfskritieke componenten (vital business functions) gehanteerd. Vanuit het gezichtspunt van de IT-dienstenorganisatie is het optimaliseren van onderhoud een belangrijk nevendoel. Een optimale beschikbaarheid wordt gekarakteriseerd door een lage storingsgraad van systemen en een snel herstel van de dienstverlening na het optreden van een verstoring. Goed beschikbaarheidbeheer stoelt op een adequate invulling van de operationele beheerprocessen. Incidentbeheer draagt zorg voor een snel herstel van de dienstverlening. Probleem- en wijzigingsbeheer leveren een essentiële bijdrage aan het bereiken van een korte storingstijd. Probleembeheer zorgt daarbij voor het verhelpen en voorkomen van structurele fouten in de ITinfrastructuur. Wijzigingsbeheer draagt bij door de gecontroleerde invoering van wijzigingen. Op deze wijze is het mogelijk om in een vroegtijdig stadium de gevolgen van wijzigingen in de beschikbaarheid van IT-diensten te onderkennen. Figuur 2.11: meetpunten en grootheden bij verstoringen 20 2.11 Capaciteitsbeheer Capaciteitsbeheer heeft als doel blijvend en kosteneffectief de juiste capaciteit aan IT-middelen beschikbaar te stellen, zodat aan de huidige en toekomstige behoeften van de afnemer wordt voldaan. Capaciteit aan IT-middelen is te omschrijven als het totaal aan IT-componenten en IT-diensten dat nodig is om te voldoen aan de met de opdrachtgever overeengekomen prestaties. De prestatie-eisen worden afgeleid uit de kwalitatieve en kwantitatieve normen die binnen het proces dienstenniveaubeheer worden opgesteld. Capaciteitsbeheer is een complex proces, met name door de vele aspecten die gelijktijdig in overweging moeten worden genomen. Enerzijds betreft het de afstemming van de huidige en toekomstige wensen en eisen van de afnemer, anderzijds het sturen en plannen van de huidige capaciteit en prestaties van de ITinfrastructuur. Daarbij wordt continu rekening gehouden met toekomstige technologische ontwikkelingen. Capaciteitsbeheer heeft een planningshorizon van ongeveer twee jaar. Echter, zowel de veranderingen in de bedrijfsprocessen en markten (korte time-to-market) als wel de technologische ontwikkelingen hebben een kortere doorlooptijd dan twee jaar. Dit levert de nodige spanningen op. Om aan de doelstellingen te voldoen, zoekt capaciteitsbeheer steeds naar het optimum in bovenstaande aspecten. De belangrijkste afwegingen dient capaciteitsbeheer te maken tussen kosten en capaciteit enerzijds (met name bij investeringsvraagstukken en wijzigingsverzoeken), en tussen vraag en aanbod anderzijds (bij dagelijkse sturing op gebruik). Het optimum zoeken, houdt in: op de juiste plaats, op het juiste moment, in de juiste hoeveelheid en tegen gerechtvaardigde kosten. Figuur 2.12: samenhang tussen de activiteiten en subprocessen binnen capaciteitsbeheer 21 2.12 Dienstenniveaubeheer Het doel van dienstenniveaubeheer is de kwaliteit van IT-diensten te waarborgen en te verbeteren door middel van een continue cyclus van overeenkomen van dienstenniveaus en het monitoren en rapporteren over de prestaties van de ITdienstenorganisatie. Door dienstenniveaubeheer kan een betere relatie tussen de ITdienstenorganisatie en haar afnemers worden bereikt. Het waarborgen en continu verbeteren van de overeengekomen kwaliteit wordt gerealiseerd door voortdurend te blijven zoeken naar het optimale niveau van ITdienstverlening. Een optimaal niveau van IT-dienstverlening betekent dat wordt voorzien in de wensen en eisen van de afnemers over de tijdigheid, volledigheid en juistheid van ITdiensten. Tegelijkertijd dienen de hiermee gemoeide kosten voor zowel de aanbieder als de opdrachtgever te rechtvaardigen zijn. Goede dienstverlening is het resultaat van effectieve communicatie en een goed samenwerkingsverband. Het optimale niveau van IT-dienstverlening wordt continu beïnvloed door allerlei factoren. Voor de IT-dienstenorganisatie zijn dit onder andere: plannen voor de toekomstige IT-infrastructuur, budgettering, complexiteit en grootte van een organisatie, bedrijfsplanning en de levenscyclus van informatiesystemen. Voor de gehele organisatie zijn dit onder meer: wetgeving, samenleving, arbeidsmarkt en technologische vooruitgang. Het proces dienstenniveaubeheer heeft als doel in deze steeds wijzigende omstandigheden de optimale dienstverlening af te spreken en te borgen. Figuur 2.13: invloeden op het optimale niveau van dienstverlening 22 3. De huidige situatie Dorb Logistics De huidige situatie bij Dorb Logistics is in het komende hoofdstuk beschreven. Bij Dorb zit het zo: Per vestiging van Dorb worden de productiemiddelen apart bijgehouden en onderhouden. Per vestiging zijn er dus verschillende personen aangesteld om dit te doen, de taken van deze IT personen zijn per vestiging verschillend en zijn hieronder beschreven. Directeur en Hoofd centrale ICT-afdeling: ICT beleid maken Hoofd ICT-afdeling Dorb-V: Meedenken met betrekking tot ICT beleid en doen uitvoeren van ICT beleid. Aansturen ICT-organisatie in Venlo, kosten en kwaliteitsbewaking. Netwerkspecialist/hardware services Dorb-V: Hardware onderhoud (oa boordcomputers en RF-apparatuurmagazijn), bekabeling, installatie servers, besturingssoftware, soms telefoondienst, regelen vervangende apparatuur, overal problemen oplossen, ‘brandjes blussen’, het imago van de afdeling oppoetsen, etc. Systeembeheerder Dorb-O: Helpen bij allerhande problemen bij collega’s in Oldenzaal, installeren applicaties/patches, oplossen netwerkproblemen, verzenden RF-apparatuur en boordcomputers naar leveranciers, etc. Aangezien er geen vast aangestelde persoon is die de leiding heeft over de gehele IT-afdeling en de IT-midddelen niet bij elkaar aansluiten over de gehele organisatie ontstaan er een aantal knelpunten binnen de organisatie. De beschrijving van de IT-middelen is te vinden in bijlage 1. 23 4. Knelpunten van Dorb Logistics In dit hoofdstuk komen de knelpunten van zowel de Operationele als de tactische processen aan bod. Per proces zijn de knelpunten zoals ze op dit moment zijn beschreven. Operationele processen 1. Configuratiebeheer - Het beheer van de hardware is niet centraal geregeld - Geen duidelijk overzicht hardware - Geen algemene standaard voor software - Verantwoordelijkheden niet duidelijk beschreven 2. Incidentbeheer - De incidenten worden door de beschikbare personen opgelost, zonder vaste aanstelling hiervoor - Geen centrale servicedesk 3. Probleembeheer - Problemen worden niet vastgelegd voor verdere eventuele raadpleging - Geen aangestelde persoon voor oplossen problemen - Geen centrale servicedesk 4. Wijzigingsbeheer - Geen duidelijke aanvraagprocedure wijzigingen - Wijzigingen worden doorgevoerd zonder (genoeg) overleg 5. Uitgavenbeheer - Uitgaven worden gedaan zonder correcte supervisie Tactische processen 6. Capaciteitsbeheer - Geen duidelijkheid betreft capaciteit ICT-afdeling 7. Beschikbaarheidbeheer - Onduidelijk hoe groot de beschikbaarheid moet zijn - Geregeld geen beschikbaarheid ICT-diensten 8. Continuïteitsbeheer - Geen correcte ondersteuning bedrijfsprocessen voor herstel na calamiteit 9. Financieel beheer - Geen correct budgettering ICT-diensten door grote zelfstandigheid vestigingen - geen centraal overzicht kosten ICT 10. Beveiligingsbeheer - Geen gedefinieerd basisniveau beveiliging - Niet duidelijk of er aan wetgeving voldaan wordt 24 5. ITIL voor Dorb Logistics In dit hoofdstuk wordt advies gegeven. Het advies zal gaan over ITIL. Waarom is ITIL een oplossing voor Dorb Logistics. Wij geven dit advies om Dorb beter te laten functioneren. Hierin komen ook de eisen aan de operationele en tactische processen aan de orde. 5.1 Eisen aan Operationele en tactische processen Om de processen goed te laten verlopen zijn er eisen nodig voor elk proces. Deze eisen worden per proces beschreven. Eisen operationele processen: Configuratiebeheer Om configuratiebeheer goed te laten verlopen zijn de volgende eisen noodzakelijk: - Zorg dragen voor het bepalen van het juiste detailleringniveau. Het zeker stellen dat de CBDB over voldoende en de juiste functionaliteiten beschikt. Het voorzien van procedures waarmee wijzigingen ook in afwezigheid van een configuratiebeheerder worden geregistreerd. Het voorkomen dat de registratie en wijzigingen gezien worden als vertragende factor. Zorgen dat configuratiebeheer door alle IT-medewerkers als noodzakelijk wordt beschouwd. Incidentbeheer Om incidentbeheer goed te laten verlopen zijn de volgende eisen noodzakelijk: - - - Zorgen voor een up-to-date configuratiebeheerdatabase Zorgen voor een nauwe relatie met dienstenniveaubeheer om duidelijkheid te scheppen over gewenste responsetijden voor incidenten en om voor ogen te hebben welke IT-diensten wel/niet ondersteund worden. Zorgen dat de verantwoordelijkheden ondubbelzinnig verdeeld zijn over de service desk en de ondersteunende oplosgroepen. Zorgen voor een incidentenbeheersysteem dat relaties kan leggen met andere operationele processen om zo het incident sneller te kunnen analyseren en op te lossen. Zorgen voor een integratie van het incidentenbeheersysteem en mogelijke telecommunicatiesystemen. Voorkomen dat de service desk door gebruikers ervaren wordt al vertragende factor. Zeker stellen dat de service desk over voldoende communicatiemiddelen beschikt om in elke situatie als contactpunt op te kunnen treden. 25 Probleembeheer Om probleembeheer goed te laten verlopen zijn de volgende eisen noodzakelijk: - - Zorg dragen voor optimale verhouding tussen wijzigingsbeheer, de servicedesk en de ondersteunende afdelingen. Zorgen voor een goede koppeling tussen incidentgegevens en de gegevens over problemen en onderkende fouten zodat incidentbeheer weet welke oplossingen voorhanden zijn en probleembeheer op zijn beurt de status van problemen goed kan volgen en inschatten Het voorkomen dat probleembeheer ondergeschikt wordt aan ad hoc incidentafhandeling. Het voorzien van voldoende hulpmiddelen aan de betrokken medewerkers om het onderzoek en diagnose juist uit te voeren. Het zeker stellen dat in de ontwikkelomgeving onderkende fouten met de nieuwe of gewijzigde programmatuur worden overgedragen aan de beheerorganisatie. Wijzigingsbeheer Om wijzigingsbeheer goed te laten verlopen zijn de volgende eisen noodzakelijk: - Het zeker stellen dat elke wijziging de volledige wijzigingsprocedure doorloopt. Zorg dragen voor acceptatie van wijzigingsbeheer als coördinerende instantie voor elke wijziging. Zorgen dat alle betrokkenen op de hoogte zijn van de wijzigingsprocedure, ook externe toeleveranciers en de interne systeemontwikkelafdeling. Zorgen voor een terugvalprocedure bij een onjuiste implementatie van de wijziging. Voorkomen dat na de implementatie van een wijziging de evaluatie ter zijde wordt geschoven. Zorgen dat bij configuratiebeheer alle statuswijzigingen geregistreerd worden. Uitgavenbeheer Om uitgavenbeheer goed te laten verlopen zijn de volgende eisen noodzakelijk: - Het beschermen van de exploitatieomgeving en de IT-dienstverlening door het gebruik van formele procedures en controles. Het zeker stellen dat de verantwoordelijkheid voor de ontwikkelomgeving, de exploitatieomgeving en de programmatuurbibliotheek juist is verdeeld. Zorg dragen dat het exclusieve beheer van definitieve programmatuuritems geaccepteerd worden door alle betrokkenen. Het definiëren van een duidelijke en hanteerbare versiecodering. Het voorkomen van het in exploitatie brengen van verschillende versies in een gedistribueerde omgeving. 26 Service desk Om service desk goed te laten verlopen zijn de volgende eisen noodzakelijk: - - Zorgen dat de servicedesk bij alle directe gebruikers bekend staat als het contactpunt van de IT-afdeling. Voorkomen dat de servicedesk door gebruikers ervaren wordt als vertragende factor. Het zeker stellen dat de servicedesk over voldoende communicatiemiddelen beschikt om in elke situatie als contactpunt op te kunnen treden. Zorgen dat de verantwoordelijkheden ondubbelzinnig zijn toegewezen aan de servicedesk en de ondersteunende groepen. Rekening mee houden dat goede sociale vaardigheden de belangrijkste eigenschap van de medewerker van de servicedesk vormen. Eisen tactische processen: Dienstenniveaubeheer Het overeengekomen niveau van dienstverlening dient te allen tijde bij te dragen aan het realiseren van de bedrijfsdoelstellingen die een organisatie zich stelt: - Te voldoen aan de vereisten van de opdrachtgever; - Te voldoen aan de richtlijnen die de IT-dienstenorganisatie zich stelt; - De IT-dienstenorganisatie in staat stellen haar doelstellingen te realiseren; - Specifiek, meetbaar, aantoonbaar, realistisch, tijdsgebonden, haalbaar en beïnvloedbaar te zijn. - Zoveel mogelijk gedefinieerd te zijn in gekwantificeerde, en dus meetbare, doelstellingen of normen. Capaciteitsbeheer - meet prestaties vanuit de afspraken met de opdrachtgever in plaats van alle mogelijkheden van monitoring tools te gebruiken. Monitoren legt beslag op de systeemcapaciteit. Dit beinvloedt de prestaties van een systeem. Een tekort aan capaciteit komt vaak pas aan het licht op het moment dat zich prestatieproblemen voordoen. Een goede relatie en overdrachtsprocedure tussen applicatieontwikkeling en technisch beheer is een randvoorwaarde voor het optimaal uitvoeren van activiteiten als applicatiedimensionering en modellering. 27 Beschikbaarheidbeheer Goed beschikbaarheidbeheer reduceert reactief probleembeheer, correctief onderhoud, en de kosten veroorzaakt door storingstijden Verbetering van de beschikbaarheid van IT-diensten is te realiseren door: - de onderhoudbaarheid te verhogen en zo de storingsduur te verkorten; - de betrouwbaarheid te verhogen en zo het aantal verstoringen per tijdsperiode te verminderen; - de diagnosetijden te verkorten m.b.v. analysehulpmiddelen; - goede back-up procedures in verband met herstelacties; - de installatie van fouttolerante systemen, dubbel uitgevoerde processoren, automatische herstartmechanismen of schaduwschijven; - adequaat wijzigingsbeheer Continuïteitsbeheer - - het beschikken over een calamiteitenplan vermindert de risicobronnen niet; uit de praktijk blijkt dat er doorgaans wel technische voorzieningen worden getroffen om de geautomatiseerde gegevensverwerking te continueren, maar dat er onvoldoende rekening wordt gehouden met organisatorische voorzieningen als huisvesting, benodigde werkplekken, transportmiddelen en dergelijke; niet alle schade is direct financieel kwantificeerbaar. Sommige organisaties, zoals banken, worden van overheidswege verplicht te beschikken over een calamiteitenplan. Meestal vinden er dan jaarlijkse audits plaats op dit plan; Financieel beheer Kostenbeheersing brengt kosten met zich mee. Welke methode van kostenbeheersing wordt ingevoerd, zal dus afhangen van kosten-baten overwegingen. Een succesvolle toepassing van een verrekeningsysteem vereist: - voor afnemers begrijpelijke terminologie en tariefseenheden; - een hoge mate van voorspelbaarheid zodat de leiding weet welke financiële gevolgen beslissingen hebben; - tarieven die een afspiegeling van de economische realiteit vormen, met ander woorden: gebaseerd zijn op de daadwerkelijke kostprijs verkregen ui de activiteit kostenbeheersing. Het aanpassen van het verrekeningssysteem zal vanuit beleidsoogpunt zo min mogelijk gebeuren. Het tarief van de diensten is namelijk veelal van invloed op de vraag naar die diensten en vice versa 28 Beveiligingsbeheer - - de veiligheid van informatie moet zijn afgestemd op het belang van de informatie; kosten en baten van beveiliging moeten in evenwicht zijn; betrokkenheid van hoog tot laag is nodig voor succesvolle implementatie; beveiligingsbewustzijn van hoog tot laag draagt bij een goede veiligheid; zorg voor controleerbaarheid van maatregelen; gebrek aan aandacht voor detectiemechanismen bij vooral nieuwe systemen die niet zijn gebouwd om veilig te zijn en ‘inbrekers’ te detecteren; draag zorg voor tijdige detectie van beveiligingsincidenten; merk op dat audits niet worden uitgevoerd door dezelfde werknemers als bij andere subprocessen. Dit in verband met de noodzakelijke functiescheiding. Verder vindt evaluatie plaats op basis van de gemelde beveiligingsincidenten. 29 5.2 advies Dorb Logistic Het uiteindelijke advies is om een servicedesk te implementeren. Omdat alle vestigingen hun eigen IT-afdeling hebben, het soms te lang duurt voordat een incident verholpen wordt en omdat de gebruikers niet weten waar ze naar toe moeten voor een probleem zijn wij tot dit advies gekomen. Servicedesk wordt hier dan een centraal loket (punt) waar alle vragen en problemen van de gebruikers beantwoord en verholpen kunnen worden. Hierbij biedt het continuïteit in de IT-dienstverlening door het faciliteren van een zo spoedig mogelijk herstel van het afgesproken dienstenniveau. De servicedesk richt zich op een brede ondersteuning van de gebruiker. Bij een servicedesk moeten de communicatieve vaardigheden gecombineerd worden met kennis van bedrijfsprocessen en IT-diensten. Ook is er enige specialistische kennis, nodig voor het oplossen van incidenten. Enige taken die uitgevoerd moeten worden zijn, aannemen van wijzigingsverzoeken, informatievoorziening over voortgang van wijzigingen en het administreren van onderhoudscontracten en licenties. Bij servicedesk komen de taken van incidentbeheer, configuratiebeheer en wijzigingsbeheer allemaal aan de orde. Hierdoor moet er goed afgebakend worden tot hoeverre de verantwoordelijkheden van de servicedesk reiken. Om servicedesk goed te kunnen implementeren moeten de bovengenoemde eisen gehanteerd te worden. De medewerkers van de servicedesk en gebruikers die de servicedesk benaderen, horen ook te weten wat zij van elkaar mogen verwachten. Waar kan Dorb Logistics een servicedesk implementeren? Omdat de hoofd ICT afdeling in Nijmegen zit adviseren wij aan Dorb Logistics om daar een servicedesk te implementeren. Deze zal dan in een apart kantoor geplaatst moeten worden, waar alleen de medewerkers van de servicedesk mogen werken. Het zou dan ook beter zijn als er meer dan een medewerker achter de servicedesk beschikbaar is. Dit om een betere en snellere service aan de klanten te bieden. Het is dan de bedoeling dat de servicedesk elke werkdag tijdens kantoor uren beschikbaar zal moeten zijn voor de klanten. Daarom stellen wij aan Dorb Logistics om de servicedesk van 7:30 – 18:00 uur open te hebben. 30 De tool die de medewerkers van de servicedesk zal moeten gebruiken. Wij hebben drie tools onderzocht en van deze drie hebben wij eentje gekozen. De drie tools die wij hebben onderzocht zijn: - Assyst - TOPDesk - Remedy’s Uit deze drie tools hebben wij voor de TOPDesk Professional gekozen, dit omdat hij over meer voordelen beschik dan die andere twee tools. Voor meer duidelijkheid over de na- en voordelen van de tools verwijzen wij naar bijlage 3. Ondersteuningbeleid Het raadplegen van een servicedesk is een van de reden waarom wij weten dat ITIL een goede keuze is om hulp aan Dorb Logistic te bieden. Voor meer ondersteuning aan onze advies waarom ITIL geschikt is voor Dorb Logistic verwijzen wij naar bijlage 5. Hier kan men meer lezen over het ondersteuningbeleid. 31 6. Twee operationele processen voor Dorb logistics In dit hoofdstuk worden de processen Configuratie beheer en Incident beheer volledig uitgewerkt. Deze worden geïmplementeerd bij Dorb Logistics. Met behulp van Topdesk worden deze processen geheel uitgewerkt. 6.1 Activiteiten configuratiebeheer Het proces configuratiebeheer heeft de volgende activiteiten: Plannen van configuratiebeheer Identificatie van configuratie-items Beheer van configuratiebeheerdatabase Statusbewaking van configuratie-items Verificatie van configuratiebeheerdatabase Informatievoorziening Configuratiebeheer kan alleen van goede kwaliteit zijn als al deze activiteiten op een goede en geordende manier wordt gerealiseerd. Tevens is het belangrijk dat configuratiebeheer nauw overleg pleegt met wijzigingsbeheer en uitgavenbeheer. 6.1.1 Plannen van configuratiebeheer Plan waarin omschreven wordt wat missie, strategie, bereik en doelstellingen van het proces configuratiebeheer zijn. Daarnaast dient erin te staan waar de verantwoordelijkheden liggen, wanneer CI’s gearchiveerd worden en voor hoelang, welke basisconfiguratie word gekozen. Dit plan gebaseerd op analyse van de huidige bezettingen, processen, beleid, leveranciers en applicaties in een organisatie, kan dan het vertrekpunt zijn voor implementatie van het proces. 32 Figuur 6.1: Configuratiescherm 6.1.2 Identificatie van configuratie-items Identificeren van CI’s houdt in het selecteren, identificeren en etiketteren van CI’s plus het vastleggen van de eigenaar van het CI en de relaties tussen de CI’s. Onder deze activiteit valt ook het bepalen van gewenste CDBD-detailleringniveau. Eerste stap is alle componenten identificeren, d.w.z. alle fysieke aanwezige als de samengestelde logische configuratie-items moeten worden benoemd en beschreven worden. Ook de nog niet aanwezige maar wel geplande items komen hiervoor in aanmerking. 33 Figuur 6.2: Configuratie hardware Figuur 6.3: Configuratie Software 34 6.1.3 Beheer van configuratiebeheerdatabase Na de identificatie van de configuratie-items mogen alleen geautomatiseerde wijzigingen plaatsvinden. Dit betreft toevoegingen, vervangingen, aanpassingen en verwijderingen. Het is de taak van configuratiebeheer om alleen wijzigingen in de ITinfrastructuur toe te staan die via wijzigingsbeheer zijn geautoriseerd. Alleen dan kan gegarandeerd worden dat de CBDB een correcte weerspiegeling is van de geautomatiseerde IT-infrastructuur. Tot configuratiebeheer behoort ook het definiëren en registreren van een basisconfiguratie. Een basis configuratie is een selectie uit de CBDB die apart wordt opgeslagen voor een bepaald doel. Dit doel kan bijvoorbeeld bestaan uit het castleggen van de opbouw van (een deel van) de IT-infrastructuur in een stabiele situatie, zodat hierop terug gevallen kan worden. Blijkt op een gegeven moment dat IT-diensten om bepaalde reden niet meer op het overeengekomen kwaliteitsniveau gerealiseerd kunnen worden, dan kan de ITinfrastructuur met behulp van de basisconfiguratie teruggezet worden. 6.1.4 Statusbewaking van configuratie-items Om de actuele toestand van een configuratie-item vast te leggen wordt de status van het CI geregistreerd. Een nieuwe CI bevindt zich achtereenvolgens in de volgende toestanden: gepland, getest, operationeel en gearchiveerd. Ook voor dit proces wordt er nauw overlegt met wijzigingsbeheer. De status van het item verschaft informatie over de verantwoordelijkheid in de organisatie en de wijze waarop het kan worden ingezet. Per status kan de datum van ingang bijhouden, zodat de verschillende doorlooptijden berekend kunnen worden. Op die manier kan worden berekend hoe lang besteltijden zijn en hoe lang het duurt voordat een geautomatiseerde CI wordt geïnstalleerd. 6.1.5 Verificatie van configuratiebeheerdatabase Deze activiteit binnen configuratiebeheer bestaat uit het zorg dragen voor de actualiteit van de configuratiebeheerdatabase. Het kan gebeuren dat er iets in de ITinfrastructuur is gewijzigd zonder dat configuratiebeheer daarvan op de hoogte wordt gesteld. Om actualiteit van de gegevens in het CBDB te garanderen is het nodig om deze gegevens te verifiëren met de werkelijkheid. Dit kan jaarlijks, na een grote wijziging, of op een willekeurig moment gebeuren. Een volledige verificatie wordt uitgevoerd door alle gegevens van alle configuratieitems uit de CBDB in de infrastructuur na te lopen en te controleren. Dit proces is erg arbeidsintensief en is niet altijd noodzakelijk. Aan de hand van de resultaten van een steekproef uit de database kan een indicatie gegeven worden van de betrouwbaarheid en volledigheid van de CBDB. Ook kunnen momenten dat problemen of wijzigingen worden onderzocht, afwijkingen worden geconstateerd. Het aantal keren dat zoiets voorkomt is een indicatie van de betrouwbaarheid van de CBDB. 35 6.1.6 Informatie voorziening Het beschikbaar stellen ten behoeven van andere processen is een belangrijke activiteit binnen configuratiebeheer. Configuratiebeheer verzorgt dit door gegevens uit de CMDB te verwerken tot zinvolle informatie zoals rapportages. Deze informatie kan dan worden doorgegeven aan de andere processen binnen de IT-dienstverlening. Voorbeelden kunnen zijn: - de groei van de IT-infrastructuur - het aantal niet-geautomatiseerde wijzigingen - de werk beslasting - trends en toekomstverwachtingen 6.2 Activiteiten Incidentbeheer Het doel van incidentbeheer is het zo snel mogelijk herstellen van de dienstverlening, conform de afspraken die in de dienstenniveau-overeenkomsten zijn gemaakt, door de gevolgen van storingen te minimaliseren, zodat de gebruiker zo weinig mogelijk hinder ondervindt. Dit is mogelijk door de volgende deelactiviteiten te onderscheiden: - Detecteren en registreren - Classificeren en toewijzen - Onderzoeken en diagnosticeren - Oplossen en herstellen - Afsluiten - Voortgangsbewaking en communicatie - Informatievoorziening 6.2.1 Detecteren en registreren Een incident kan op verschillende manieren worden opgemerkt: door een gebruiker, door een systeem, een medewerker van de servicedesk of van een andere ITafdeling. Incidenten ontstaan in verschillende domeinen. Centrale faciliteiten Netwerk & datacom Gebruik en functionaliteit Werkstations en pc’s Organisatie en procedures Beheer en Techniek Gebruikers en organisatie Incidenten Om incidenten zo snel mogelijk op te lossen zal er actief aandacht besteedt moeten worden aan het detecteren van defecten of storingen in alle domeinen van Dorb 36 Logistics. Dit kan bijvoorbeeld worden gedaan met behulp van monitors. Hiermee kan de servicedesk incidenten detecteren voordat ze gemeld worden door een gebruiker. Op het moment dat een afwijking geconstateerd wordt, vindt registratie van het incident plaats. Dit is noodzakelijk om de voortgang te bewaken, om gegevens ten behoeve van diagnose en oplossing ter beschikking te hebben en om de impact van een incident te bepalen. figuur 6.4: Incidentscherm 37 6.2.2 Classificeren en toewijzen De eerste stap na detectie en registratie is een korte analyse van het incident, deze voor het bepalen wat er verder met het incident moet gebeuren. Indien de juiste oplossing van het incident nog niet bekend is, kan eventueel van een tijdelijke herstelactie gebruikgemaakt worden. Ook kan de servicedesk bevoegd zijn door wijzingbeheer om bepaalde incidenten direct op te lossen door het uitvoeren van kleine wijzigingen. Wanneer meerdere, niet direct op te lossen incidenten tegelijkertijd bij de servicedesk in behandeling zijn, zullen er prioriteiten moeten worden gesteld. De prioriteiten geeft het onderlinge, relatieve belang aan van de incidenten met betrekking tot de afhandeling. De prioriteiten van incidenten wordt na een korte analyse bepaald door de volgende factoren: Impact, urgentie, verwachte inspanning Impact Bij het bepalen van de impact van een incident spelen de relaties tussen de verschillende componenten in de infrastructuur een belangrijke rol. Met behulp van de CBDB kan men achterhalen hoeveel gebruikers getroffen zullen worden door het incident. Urgentie De urgentie is de mate waarin de oplossing van een incident uitstel kan verdragen. Aspecten die de urgentie beïnvloeden zijn bijvoorbeeld de beschikbaarheid van een tijdelijke oplossing of mogelijkheid tot het gepland uitstellen van een oplossing. Verwachte inspanning In de praktijk blijkt dat de prioriteiten niet alleen door impact en urgentie wordt bepaald maar dat ook de verwachte inspanning een rol speelt. Een incident met een lage impact en middelmatige urgentie dat echter met relatief weinig inspanning direct verholpen kan worden, wordt in veel gevallen direct verholpen. Voor incidenten die niet direct verholpen kan worden, worden deze toegewezen aan functionarissen buiten de servicedesk. 6.2.3 Onderzoeken en diagnosticeren Incidentbeheer wordt voornamelijk gekenmerkt door snelheid in het oplossen van incidenten. Op basis van de classificatie en de registratie vindt het diagnosticeren en zo spoedig mogelijk oplossen van incidenten plaats. Om de voortgang van de incidentafhandelingen te bewaken is registratie van het oplossingstraject noodzakelijk. Wanneer een incident niet binnen de gestelde tijd opgelost kan worden, dienen meetregelen genomen te worden om de incidentafhandeling te bespoedigen. Dit is mogelijk door het inzetten van escalatie. Hierbij wordt onderscheid gemaakt tussen functionele en hiërarchische escalatie. Bij functionele escalatie wordt beroep gedaan op de organisatie om meer gedetailleerde kennis of expertise ter beschikking te stellen. Bij een hiërarchische escalatie wordt een beroep gedaan op de organisatie omdat de bevoegdheid om de benodigde beslissing te nemen niet op de servicedesk aanwezig is. 38 6.2.4 Oplossen en herstellen Na onderzoek en diagnose moet de oplossing nog worden geïmplementeerd. Afhankelijk van het type incident wordt door de eerste-, tweede-, derdelijnsondersteuning de oplossing gegeven. Naarmate het onderzoek vordert, kan ook in probleembeheer een tijdelijke oplossing of oplossing gevonden worden die dan weer aan incidentbeheer beschikbaar wordt gesteld. Het is belangrijk dat een oplossing naar tevredenheid van de gebruiker is. Als de implementatie van een oplossing meer tijd nodig heeft, dan moet de gebruiker van de voortgang en ondernomen acties op de hoogte worden gehouden. 6.2.5 Afsluiten Afsluiting van het incident kan pas plaatsvinden op het moment dat een voor de gebruiker bevredigende oplossing is gevonden en doorgevoerd. Bij afsluiting hoort ook het coderen van de incidenten zodat analyse van de incidentgegevens door probleembeheer mogelijk gemaakt wordt. Vervolgens wordt bij de aanmelder geverifieerd of het incident daadwerkelijk is opgelost. Indien de gebruiker akkoord gaat met de oplossing kan het incident daadwerkelijk worden afgesloten. 6.2.6 Voortgangsbewaking en communicatie Gedurende de levenscyclus van een incident blijft de servicedesk verantwoordelijk als eigenaar van het incident en zal de servicedesk de voortgang van het incident moeten blijven volgen en bewaken. Daarnaast dient de aanmelder over de voortgang op de hoogte te worden gesteld, zodat de status bekent is en welke acties zijn ondernomen. Het incidentnummer is hier de eenduidige referentie naar het incident. 6.2.7 Informatievoorziening De informatie die door incidentbeheer geleverd wordt, heeft tot doel inzicht te geven in het functioneren van het proces incidentbeheer en in de kwaliteit van de dienstverlening. Door de incidenten te groeperen op basis van de impact en te combineren met de hersteltijd kan inzicht verkregen worden in het effect van de verstoring van het bedrijfsprocessen. Om inzicht te krijgen in de kwaliteit van de dienstverlening kunnen de volgende gegevens in de rapportage worden verwerkt: - aantallen incidenten - gemiddelde en maximale storingstijd - verdeling storingstijd - bestede tijd/kosten als gevolg van incidenten 39 7. voorstel opzet van een SLA 7.1 Introductie Dit hoofdstuk bevat het voorstel voor de afspraken die gemaakt kunnen worden tussen de opdrachtgever en de opdrachtnemer. De opdrachtgever is in dit geval de centrale directie en de opdrachtnemer is de centrale ICT-afdeling met de ondergeschikte afdelingen. De hiërarchie in het bedrijf wordt duidelijk aan de hand van het gemaakte organigram, zie bijlage 1. Het is een bijlage bij het verslag voor invoering van ITIL en vormt daar een integraal onderdeel van. Hierdoor weten beide partijen wat wederzijds verwacht wordt en waaraan moet worden voldaan. Door periodieke evaluaties wordt gecontroleerd of de hier vastgelegde afspraken daadwerkelijk worden nagekomen. De geldigheidsduur van deze Service Level Agreement bedraagt een volledig jaar, met elke drie maanden een complete evaluatie van de overeenkomst. 7.1.2 Opbouw SLA Hoofdstuk 2 geeft een overzicht van de functionaliteit, de beschikbaarheid, de prestatie en de capaciteit van de ICT-objecten. In hoofdstuk 3 wordt de gebruikersondersteuning uitgediept, de functionaliteit, beschikbaarheid, prestatie en de capaciteit hiervan worden bekeken. Hoofdstuk 4 beschrijft de functionaliteit van de beveiliging evenals de beschikbaarheid, de prestatie en de capaciteit. Hoofdstuk 5 beschrijft de uitwijk, de functionaliteit, beschikbaarheid, prestatie en capaciteit hiervan. Het laatste hoofdstuk, hoofdstuk 6, beschrijft de aspecten van de wijzigingen: functionaliteit, beschikbaarheid, prestatie en de capaciteit hiervan. Als laatste zijn er nog een aantal bijlagen bijgevoegd 7.1.3 Doel SLA De SLA beschrijft het niveau van dienstverlening voor het beheer daarnaast zorgt deze SLA voor een gemeenschappelijk referentiekader voor de verwachtingen van de dienstenniveaus en vormt deze een normstelling (benchmark) voor prestatiemetingen. 7.1.4 Contactpersonen Bij deze twee partijen zal een contactpersoon aangewezen worden voor SLA. Informatie uitwisseling tussen beide partijen verloopt via vastgestelde personen. De namen, telefoonnummers en e-mailadressen van deze personen en plaatsvervangers zijn opgenomen in bijlage 4. Deze contactpersonen zullen het aanspreekpunt zijn voor de SLA en de afspraken hierin gemaakt. 40 7.2. ICT Objecten 7.2.1 Functionaliteit ICT Object Opsomming van de functies die het ICT object de gebruikers biedt. Raadplegen/aanpassen database Orderverwerking Email Voorraadplanning Tekstverwerken/printen 7.2.2 Beschikbaarheid ICT Object Servicetijd / openingstijd: 7:00 uur – 19:00 uur Onderhoudstijd: maximaal 2 uur per filiaal per week Gemiddelde tijd tussen storingen: van zware tot lichte storingen, een maand tot twee dagen Gemiddelde beschikbaarheid: Maximale storingsduur: van zware tot lichte storingen, vier uur tot een uur Minimale hersteltijd: 30 minuten Gemiddelde hersteltijd: een uur Maximaal verloren gebruikerstijd: vier uur Maximaal aantal storingen per periode: van zware tot lichte storingen, drie tot 40 per drie maanden 7.3 Gebruikersondersteuning 7.3.1 Functionaliteit gebruikersondersteuning De ondersteuning die aan de gebruikers geboden wordt, wordt geleverd door, of uitbesteedt door de servicedesk. Alle IT-objecten binnen Dorb Logistics, de werkstations, servers, netwerk, programmatuur, randapparatuur, boordcomputers en verder apparatuur behoren tot het ondersteuningsdomein van de servicedesk. Binnen deze afdeling zullen er mensen aanwezig moeten zijn die, tezamen, voldoende kennis moeten hebben om ondersteuning te kunnen bieden. Is het expertiseniveau te laag dan zullen deze personen geschoold moeten worden. De taal die op de servicedesk gesproken wordt is Nederlands, maar de medewerkers zullen ook correct Engels en Duits moeten spreken, vanwege het feit dat er veel zaken gedaan worden met buitenlandse klanten en medewerkers. Nog een onderdeel waarvoor de ondersteunende medewerkers zorg moeten dragen is het verzorgen van gebruikersopleidingen, voor zowel de gebruikers als de eigen medewerkers. 41 7.3.2 Beschikbaarheid gebruikersondersteuning De openingstijden van de servicedesk, voor de ondersteuning van de gebruikers, zijn op werkdagen van 9:00 tot 17:00. Deze tijden moeten gehanteerd worden omdat de meeste gebruikers ook op deze tijden werken en er dus om ondersteuning gevraagd moet kunnen worden. Er geldt nog een aantal specifieke eis hieraan: de bereikbaarheid, er moet altijd iemand aanwezig zijn en deze moet ook direct reageren op de gebruikers die ondersteuning nodig hebben. Per email moet er direct een ontvangstbevestiging gestuurd worden en de telefoon mag niet meer dan twee maal overgaan. Tevens mag er per dag niet meer dan een gemiste melding zijn, dit om het niveau van de dienstverlening constant hoog te houden. 7.3.3 Prestatie gebruikersondersteuning De snelheid waarmee problemen en incidenten opgelost worden moet ook standaard een hoog niveau hebben. De problemen waarvoor direct een oplossing voor te geven is moet boven de 50% liggen en er mogen (per filiaal) maximaal 5 open problemen bestaan. De snelheid waarmee een probleem verholpen wordt mag maximaal 7 dagen bedragen, een probleem wordt geïdentificeerd als er meerdere dezelfde incidenten voorkomen binnen een kort tijdsbestek. Een incident wat één of twee maal voorkomt dient opgelost te worden binnen 24 uur. Kan er niet aan deze eisen voldaan worden dan zullen de medewerkers bijgeschoold moeten worden of zullen er meerdere ondersteunende medewerkers moet komen. 7.3.4 Capaciteit gebruikersondersteuning Het maximaal te ondersteunen gebruikers moet rond de 1000 liggen, alle gebruikers (inclusief chauffeurs ivm boordcomputers) moeten contact op kunnen nemen bij het constateren van problemen. Per gebruiker moet er een maximaal aantal keren, dat deze de helpdesk gebruikt, afgesproken worden van twee maal per dag. Dit om te voorkomen dat er voor elk (klein) probleem de helpdesk belast wordt. 42 7.4 Beveiliging 7.4.1 Functionaliteit beveiliging Per medewerker is er sprake van een fysieke beveiliging. Deze beveiliging zorgt voor de bescherming van deze persoon zijn gegevens. De gegevens die ‘op het netwerk’ aanwezig zijn zullen ook per categorie beveiligd moeten worden, bijvoorbeeld: de salarisgegevens moeten alleen toegankelijk zijn voor de afdeling financiën en notulen van stafvergaderingen moet alleen toegankelijk zijn voor managers. Het veiligstellen van gegevens moet dagelijks gebeuren, dit wil zeggen dat alle gegevens op de zogenaamde servers dagelijks gebackupt moeten worden, om actualiteit en bescherming te waarborgen. 7.4.2 Beschikbaarheid beveiliging De beschikbaarheid van de zogenaamde servers moet beginnen om 7:00 en eindigen om 19:00, dit om te bewerkstelligen dat elke medewerker toegang heeft zolang deze aan het werk is. De ‘sluiting’ om 19:00 is nodig om alles te backuppen en zo alle gegevens en de actualiteit te waarborgen. 7.4.3 Prestatie beveiliging Indien er sprake is van een calamiteit en er gegevens verloren gaan is het van uitermate belang dat deze gegevens binnen het uur hersteld worden en ook weer toegankelijk zijn voor de medewerkers. Het gegevensverlies per periode (3 maanden) mag niet hoger liggen 0,05%, dus 99,95% van de gegevens moet bewaard blijven. Per gebruiker kunnen er autorisatieverzoeken ingediend worden voor een deel van de gegevens. Per gebruiker is het maximale aantal verzoeken per periode vastgesteld op drie stuks. Uiteraard zullen er ongeautoriseerde toegangspogingen zijn tot de gegevens, dit kan voor komen door fouten van medewerkers, maar het aantal pogingen van medewerkers mag niet boven de 40 per afdeling uitkomen. Worden er per periode meer dan 20 pogingen geconstateerd zal er ook onderzoek ingesteld moeten worden. 7.4.4 Capaciteit beveiliging Er zit een limiet aan de tijdsduur van de opslag van de gegevens, zijn er gegevens en bestanden die meer zes maanden niet gebruikt worden zullen deze verplaatst worden naar een centrale opslagplaats, met behoud van bescherming. Mocht na nog een keer zes maanden nog geen (her)gebruik hebben plaatsgevonden dan zullen de gegevens verplaatst worden naar het archief, waar deze na 2 jaar verwijderd zullen worden, aangezien 3 jaar een acceptabele periode is. 43 7.5 Uitwijk 7.5.1 Functionaliteit uitwijk Bij uitwijksituaties zijn er een aantal functies die moeten blijven functioneren: Het wijzigen en plaatsen van orders Het wijzigen van de voorraad, inventarisatie Contact (email en telefonisch) voor de klanten Beveiliging gegevens 7.5.2 Beschikbaarheid uitwijk Een uitwijksituatie kan beschikbaar worden wanneer een (of meerdere) ICT-diensten falen. Als bijvoorbeeld het netwerk (lokaal) uitvalt zullen bovenstaande functies (8.5.1) toch moeten blijven functioneren. Er is nog een eis waaraan voldaan moet worden: Alle gegevens die opgeslagen zijn op de aparte vestigingen (Venlo, Oldenzaal en Nijmegen) moeten elke tweede werkdag verzonden (per koerier, eigen vervoer medewerkers of vrachtvervoer) naar de twee andere filialen. Dit moet gebeuren om een uitwijksituatie in een korte tijd te bewerkstelligen en de gegevens up-to-date te houden. 7.5.3 Prestatie/capaciteit uitwijk De snelheid waarmee de beschikbaarheid hersteld moet zijn ligt aan de situatie, maar bij meest ernstige situatie, het uitvallen van het gehele netwerk inclusief werkstations, mag het maximaal 48 uur duren voordat het probleem hersteld is. 7.6 Wijzigingen 7.6.1 Functionaliteit wijzigingen Het gebied waarop de wijzigingen betrekking heeft zijn alle IT-objecten binnen Dorb Logistics. Er zijn verschillende categorieën te onderscheiden: Lokaal, binnen een afdeling Vestiging, binnen een vestiging Bedrijf, binnen het hele bedrijf 44 7.6.2 Beschikbaarheid wijzigingen De manier waarop wijzigingen aangevraagd moeten worden is per categorie hetzelfde. Het wijzigingsvoorstel moet schriftelijk of per e-mail doorgegeven worden aan de servicedesk, waarvan een onderdeel wijzigingsbeheer deze zal ontvangen. Deze zal bij binnenkomst een ontvangstbevestiging sturen en zal daarna het voorstel bekijken en besluit vormen. Mochten er wijzigingen doorgevoerd worden dan zal de betreffende afdeling hierover bericht worden. 7.6.3 Prestatie wijzigingen De reactiesnelheden van wijzigingen verschillen per categorie omdat er verschillende uitgaven gedaan moeten worden en hier personen over mee moeten beslissen. Lokaal: er wordt nagekeken of het alleen bij deze afdeling nodig is en zonodig wordt de categorie bijgesteld. Indien het alleen lokaal gewenst is dan zal er uitsluitsel gegeven worden binnen vijf werkdagen. Vestiging: er wordt nagekeken of het alleen bij dit filiaal nodig is en zonodig wordt de categorie bijgesteld. Indien het alleen op deze vestiging gewenst is dan zal er uitsluitsel gegeven worden binnen 15 werkdagen. Bedrijf: er wordt uitsluitsel gegeven worden binnen 30 werkdagen. De snelheid van de wijzigingen verschilt uiteraard ook per categorie: Lokaal: wijziging moet binnen 2 werkdagen doorgevoerd zijn Vestiging: wijziging moet binnen 10 werkdagen doorgevoerd zijn Bedrijf: aangezien er per vestiging aparte doorvoering mogelijk is zal de wijziging binnen 15 werkdagen doorgevoerd moeten zijn Zoals bij elke wijziging kunnen er verstoringen optreden, wederom verschilt dit per categorie en is er een maximum aantal verstoringen vastgesteld. Lokaal: 2 stuks Vestiging: 10 stuks Bedrijf: 40 stuks Bij de wijzigingen die doorgevoerd zullen worden bij de laatste twee categorieën zullen meerdere personen betrokken zijn die hierover iets te zeggen hebben. Hiervoor zullen ook wat grotere uitgaven gedaan moeten worden en kan er dus bij het uitsluitsel geven wat langer over gedaan worden. 7.6.4 Capaciteit wijzigingen De omvang van de verschillende wijzigingen verschilt wederom per categorie en valt niet duidelijk te omschrijven, behalve welke personen er allemaal mee te maken hebben. Wat varieert van vijf tot tien personen tot 500 en meer, daarom kan er geen duidelijke maximale omvang vastgesteld worden. Wat er wel vastgesteld kan worden, wederom per categorie, zijn de maximale aantal wijzigingen per periode van 3 maanden. Lokaal: maximaal 3 wijzigingen per periode Vestiging: maximaal 1 wijziging per periode Bedrijf: maximaal 1 wijziging per periode 45 8. Conclusies en aanbevelingen Zoals we in hoofdstuk 5.2 beschreven is het bekend dat we Dorb Logistics aanraden om ITIL (Information Technology Infrastructure Library) te implementeren. Dit is aan de hand van veel onderzoeken gedaan, waarbij we aanraden een servicedesk bij Dorb Logistics Nijmegen te plaatsen. Door ITIL te implementeren kan Dorb Logistics kosten besparen. Om ITIL en het desbetreffende tool (Topdesk) te implementeren zal wel duur zijn, maar op langer termijn zal Dorb Logistics ervan profiteren. Kosten besparen aan de hand van minder in zetten van experts als het niet nodig is. Men kan een beter beeld krijgen van wat er allemaal aan IT-apparatuur en/of diensten er bij Dorb Logistics aanwezig zijn en ook het beheren daarvan. Om dit te kunnen doen moeten de eisen met betrekking ITIL doorlopen worden en kijken of alles min of meer behandeld is. Ten slotte: De toekomstige Ondersteuningbeleid van Dorb Logistics kan doormiddel van ITIL bereikt worden. 46 Literatuurlijst Laar, S. van en Vleugel, K, Casus Dorb – ITIL Laar, S. van, ITIL- Beheer van ICT en de ITIL-methodiek Koppens, S., Operationeel beheer van informatiesystemen Bladergroen, D., Planning en beheersing van IT-dienstverlening Internet: http://www.ictforyourbusiness.nl/ Wat is ITIL 47 Bijlagen 1. Organigram 48 2. ICT Middelen Dorb Logistics ® Alle ‘trekkende eenheden’ van Dorb hebben boordcomputers van ICS. De transport gedeeltes van Dorb-V en Dorb-O gebruiken dezelfde applicaties: - Het transport management systeem ‘Plan & Go’ van Plus Software BV, het basispakket en de aanvullende pakketten Mobile, Net en Planning. - Web en EDI om orders door te geven. Hermans, een onderdeel van Dorb, gebruiken ook applicaties die gericht zijn op het optimaliseren van de fijndistributie. Hierbij is een koppeling gerealiseerd met ‘Plan & Go’. De interne transportmiddelen van deze twee bestaan uit scanners en RF-terminals gekoppeld aan het pakket ‘W-AIS’ van Zetes. Deze twee onderdelen gebruiken verschillende applicaties voor ‘het warehouse’. Dorb-O - Warehouse management systeem ‘In & Out’ van Plus Software BV - Eigen applicaties die in functionaliteit lijken op de applicaties van Plus Software BV - HRM Module (Human Resource Management) - Financieel onderdeel van ERP packet ‘Global2000’ - MS Office 2000 Dorb-V - Eigen applicaties met dezelfde functionaliteit als ‘Plan & Go’ van Plus Software BV - ERP pakket ‘Axapta’(financiële, HRM, Warehouse Management Systeem modules) Dorb-SCM is gebruikt over het algemeen andere applicaties dan de andere twee onderdelen. - Pakket ASW5 van IBS - IBM Global Services (meedraaiend als ondersteuning) - Financiële module Oracle ERP pakket + HRM module - Zelfgemaakte tools voor database benadering - MS Office 2000 49 ICT Middelen Dorb Logistics ®, Hardware Dorb-O Het netwerk draait op Microsoft Server 2003. De database is van Oracle en de hardware bestaat uit een 100MB Cisco netwerk met Dell PC’s en Windows XP. Dorb-V Het netwerk draait op Windows-NT servers, de database is van Oracle. De hardware bestaat verder uit een 10MB Cisco netwerk met Dell PC’s waarop nog Windows 98 draait. Dorb-SCM Alle applicaties draaien op IBM-hardware. De i-serie, voorheen AS400, met daarbij alle netwerk- en back-upvoorzieningen, waarbij SAN-storage. De database is van Oracle. De infrastructuur van de vestiging bestaat uit een 100MB Wireless Cisco netwerk met Microsoft Windows Server 2003 servers. De PC’s zijn IBM PC’s met Windows XP. 50 3. Tools ter ondersteuning van de beheersomgeving Tools ter ondersteuning van een beheersomgeving Tools: 1. Assyst 2. Topdesk 3. Remedy’s 1. Assyst (http://www.axiossystems.com/home.php) Assyst levert de volgende functies: Help Desk Incident Management Problem Management Asset & Config Availability Management Change Management Contingency Management Capacity Management Cost Management Service Level Management Release Management Workflow & Process Management 2. TOPdesk (http://www.topdesk.nl/EN/index.php) TOPdesk levert de volgende functies: Incident Management Configuratie Service Level Problem Change E-mail integration PC Scan Knowledge Bases Fuzzy Search engines TOPdesk levert twee software pakketten: TOPdesk Professional Deze is voor organisaties met een aantal gebruikers tussen de 200 en de 15000. - TOPdesk Professional IS → Internal IT Support - TOPdesk Professional ES → External IT Support TOPdesk Lite Deze is voor een organisatie met een aantal gebruikers tot en met 200. 51 3. Remedy’s (http://www.remedy.com) Remedy’s levert de volgende functies: Remedy Helpdesk o Incident Management o Problem Management Remedy Change Management o Change Management Remedy Asset Management o Configuration Management Service Level Agreements Availability Management 52 Hieronder zijn de nadelen en voordelen van de tools/software die wij eerder hadden gekregen. Van deze drie is uiteindelijk een tool gekozen die het beste past en dus ook geadviseerd wordt aan Dorb Logistics. De ITIL Tools die wij hebben onderzocht zijn: - Assyst - TOPDesk - Remedy’s Waarom niet de Assyst of de Remedy’s tool? Voordelen: De Assyst en Remedy’s Tools zijn goedkoper dan de TOPDesk. Nadelen: Na enig onderzoek hebben wij gemerkt dat de Assyst en Remedy’s tools niet helemaal in een pakket geleverd worden. Misschien is dit wel handig voor andere bedrijven, maar voor Dorb Logistics denken wij dat het handiger is om een tool te gebruiken die alles heeft onder een pakket. Waarom wel de TOPDesk tool? Voordelen: Nadelen: - E-mail integration - Kan duurder zijn dan de andere tools, - PC Scan d.m.v. TOPsis hangt af wat voor pakket men kies. - User friendly - Alle tools onder een pakket - Kan kiezen uit 2 verschillende pakketten TOPDesk levert 2 verschillende pakketten: TOPdesk Professional Deze is voor organisaties met een aantal gebruikers tussen de 200 en de 15000. - TOPdesk Professional IS → Internal IT Support - TOPdesk Professional ES → External IT Support TOPdesk Lite Deze is voor een organisatie met een aantal gebruikers tot en met 200. 53 4. Contactpersonen Directie Directeur Plaatsvervanger ICT afdeling Hoofd ICT Plaatsvervanger Naam & Adres Henry Chin a Tsjoe [email protected] Frits Fictief [email protected] Naam & Adres Sancho Ibanez [email protected] Thea Dobs [email protected] 54 Telefoonnummer Telefoon: 040-2430781 Mobiel: 06-53174610 Telefoon: 040-2430782 Mobiel: 06-15783403 Telefoonnummer Telefoon: 040-2430783 Mobiel: 06-24775598 Telefoon: 040-2430784 Mobiel: 0645744644 5. ondersteuningbeleid Bij de toekomstverwachtingen en het beleid van DORB kunnen we uit de volgende lijst opmaken of ITIL wel een hulp biedt. a) Bij dit punt kan ITIL zeker van toepassing zijn. Dit kan door het beheren van Internet en software. Hierbij hoort ook het beheren van de licenties en het bewaken of alles goed beveiligd is door beveiligingsbeheer. b) Bij dit punt kan ITIL hulp bieden bij het beheren van intranet en extranet, wanneer er iets niet goed werkt. Ook voor het behouden van de dienstverlening zodat er zo min mogelijk verstoringen zijn voor de gebruikers. Door registreren van de verstoringen en informatie kan kennisuitwisseling mogelijk worden. c) Dit is een onderdeel van ITIL. Als ITIL gebruikt wordt krijgt men dit vanzelf. d) Door ITIL te handhaven kan men dit bereiken omdat alles wat te maken heeft met IT, geregistreerd moet worden en zo kan men eenvoudig kennis uitwisselen. e) Hier helpt ITIL bij het beheren van de middelen. Dus zodanig dat men weet wat voor middelen die heeft. Ook kan ITIL zo overzichtelijk laten zien wat voor middelen men heeft en wat nog veranderd moet worden. f) Door middel van SLA kan ITIL een uitweg zijn zodat elke dag of week er een back-up en recovery gemaakt wordt. Ook kan men een uitwijk procedure opstellen zodat als er iets gebeurt alle back-ups ook op een ander plek bewaard zijn. g) Bij dit punt kan ITIL door financieel beheer te gebruiken inzicht gekregen worden van de kosten. Ook kan men vaststellen wat de taak is van iedereen waarbij experts niet onnodige dingen gaan doen waarbij Dorb Logistics meer moet uitgeven. h) ITIL geeft aan hoe men op een structurele manier het ICTservicemanagement kan optimaliseren. i) Doormiddel van ITIL kan men de RFID beter beheren en ook een beeld krijgen van hun status en dergelijke informatie. Ook kan men zien of het handig is om het te gebruiken. 55
![Curriculum Vitae van [Voornaam] [Achternaam] - Find](http://s1.studylibnl.com/store/data/000698347_1-b7da8be49da17f0c6cf6a56b6e6aa1cf-300x300.png)
