MOF implementatie binnen The Backbone

MOF implementatie binnen The Backbone

Auteur: Datum:

Gert Kienhuis 12 februari 2007


Afstudeerder: Naam: Studie: Studentnummer:

Gert Kienhuis Technische Informatica, Master CS, Track ISE s0027189

Opdrachtgever: Bedrijfsnaam: Eerste begeleider: Tweede begeleider:

The Backbone Gert Kiewiet Nico Kienhuis

Leerinstelling: Instelling: Eerste begeleider: Tweede begeleider:

Universiteit Twente, Faculteit EWI Pascal van Eck Djoerd Hiemstra

Document: Datum:

12 februari 2007


2

Management Summary Doel The Backbone ontwerpt, implementeert en beheert IT infrastructuren voor bedrijven en instellingen. Beheer wordt proactief uitgevoerd met behulp van Microsoft Operation Manager (MOM) 2005, een applicatie die de status en gebeurtenissen van meerdere systemen verzameld en inzichtelijk maakt. Om het beheer efficiënt en effectief uit te voeren en daarnaast beheersbaar te houden is het noodzakelijk de bedrijfsprocessen rondom MOM vorm te geven, de bedrijfsprocessen af te stemmen met de techniek (MOM) en MOM op de juiste wijze in te richten. Het doel van het onderzoek is om met behulp van Microsoft Operations Framework (MOF) de bedrijfsprocessen voor het uitvoeren van beheer in te vullen. Daarbij moet rekening worden gehouden met de afstemming tussen processen en techniek en de invulling van de techniek. Uiteindelijk moet door het vormgeven van de processen een efficiënte en effectieve manier van werken ontstaan.

Aanpak Het onderzoek is in een aantal afzonderlijke stappen uitgevoerd. Allereerst is een theoretisch onderzoek uitgevoerd naar de aanwezigheid en mogelijkheden van verschillende methodieken voor het inrichten van de processen. Gelijkertijd met dit onderzoek is aandacht besteed aan The Backbone als organisatie. Vanuit een intern en extern oogpunt is gekeken naar de dienstverlening die The Backbone levert. De volgende stap in het onderzoek is een bewustwording van de huidige stand van zaken: welke interne processen worden op dit moment gebruikt, welke technische middelen wordt gebruikt, hoe zijn verantwoordelijkheden verdeeld, etc. The Backbone is een organisatie met een omvang van 7 mensen die allemaal geïnterviewd zijn. De interviews zijn vervolgens geanalyseerd en de resultaten zijn vergeleken met wat de methodieken MOF en ITIL voorschrijven. Het onderzoek wordt afgesloten met een advies aan The Backbone. De resultaten die voortkomen uit de vergelijking tussen de interviewresultaten en de methodieken zijn op een overzichtelijke manier gepresenteerd en vervolgens gevalideerd door de organisatie. De gevalideerde resultaten en een door de organisatie opgestelde normstelling zijn de basis geweest voor het schrijven van de aanbevelingen.

Resultaten In het onderzoek zijn stapsgewijze resultaten behaald. Uit de verzamelde data over de huidige inrichting is gebleken dat bepaalde zaken wel aanwezig zijn maar dat hiervan veel impliciet is geregeld en ad-hoc en niet consequent plaatsvindt. Uit de vergelijking van de huidige situatie met de processen beschreven door IT Service CMM en MOF komen deze punten als aandachtspunten naar voren. Een aantal van de door de methodieken beschreven processen en vereisten zijn wel aanwezig maar moeten consequent worden uitgevoerd en gedocumenteerd. Op basis van verkregen aandachtspunten zijn drie aanbevelingen geschreven. De aanbevelingen gaan in op een aangepaste organisatiestructuur met functieprofielen, de inrichting van een aantal processen en een aanpassing in de techniek.


3

Inhoudsopgave Verklarende woordenlijst ........................................................................................................... 5 Voorwoord ................................................................................................................................. 6 1 Inleiding .............................................................................................................................. 7 1.1 Aanleiding ..................................................................................................................... 7 1.2 The Backbone............................................................................................................... 7 2 Projectomschrijving ............................................................................................................ 8 2.1 Probleemstelling ........................................................................................................... 8 2.2 Doelstelling ................................................................................................................... 9 2.3 Onderzoeksvragen ....................................................................................................... 9 2.4 Aanpak onderzoek ........................................................................................................ 9 2.5 Leeswijzer ................................................................................................................... 11 3 Theoretisch raamwerk ...................................................................................................... 12 3.1 Business Process Redesign ....................................................................................... 12 3.2 IT Service Management ............................................................................................. 14 3.3 Raamwerk onderzoek ................................................................................................. 18 3.4 Afbakening onderzoek ................................................................................................ 19 4 Dienstverlening The Backbone ........................................................................................ 20 4.1 De markt volgens The Backbone ............................................................................... 20 4.2 Business Case ............................................................................................................ 22 5 Huidige inrichting van The Backbone ............................................................................... 23 5.1 Opbouw hoofdstuk ...................................................................................................... 23 5.2 Interview ..................................................................................................................... 23 5.3 Team / rol inrichting .................................................................................................... 24 5.4 Procesinrichting .......................................................................................................... 25 5.5 Validatie resultaten ..................................................................................................... 45 5.6 Gebruikte applicaties .................................................................................................. 46 6 Gewenste inrichting .......................................................................................................... 48 7 Conclusie .......................................................................................................................... 49 8 Literatuurlijst ..................................................................................................................... 50 Bijlage 1 Interview ............................................................................................................. 52 Bijlage 2 Interview resultaten ............................................................................................ 68 Bijlage 3 Vergelijking MOF en IT Service CMM ............................................................. 107 Bijlage 4 Validatie resultaten .......................................................................................... 108 Bijlage 5 Aanbevelingen (Vertrouwelijk) ......................................................................... 112


4

Verklarende woordenlijst Business Process Redesign (BPR): Het herontwerpen van bedrijfsprocessen Configuration Item (CI): Een IT component dat beheerd wordt door Configuration Management IT Infrastructure Library (ITIL): IT Service Management methodiek ontwikkeld door de Office of Government Commerce IT Service Capability Maturity Model (IT Service CMM): Een capability maturity model (groeimodel) wat een aantal maturity levels definieerd voor IT service organisaties. Key Performance Indicators (KPI): Prestatie indicator, een cijfer wat de prestatie van een bepaald object beschrijft. Bijvoorbeeld de uptime van een systeem of het percentage vrije ruimte op een hardeschijf. Microsoft Operation Framework (MOF): Een door Microsoft ontwikkeld framework waarin procesinrichtingen en teamrollen beschreven worden aan de hand van best practices voor het inrichten van IT dienstverleners. Microsoft Operation Manager (MOM): System management tool voor het monitoren en beheren van IT omgevingen. Request for Change (RFC): Een formeel verzoek tot het uitvoeren van een wijziging. De RFC beschrijft onder andere de indiener, een beschrijving van de wijziging, de verwachte impact, de verwachte kosten, etc. Service Level Agreement (SLA): Een overeenkomst tussen een dienstverlener en een klant waarbij een minimum aanvaardbaar serviceniveau wordt vastgelegd. [HIL94] System Management Function (SMF): Processen en activiteiten in een MOF quadrant. De processen en activiteiten zijn binnen een quadrant gegroepeerd naar management functie, bijvoorbeeld changes, monitoring en security.


5

Voorwoord Ik had nooit gedacht dat toen ik naar mijn oma zou gaan voor haar verjaardag ik terug zou komen met een stageplek, laat staan met een stageplek waar ik vervolgens een afstudeerplek en baan aangeboden zou krijgen. Toen mijn oma zei dat ze een neef had die ‗iets‘ met computers deed dacht ik ‗het zal wel‘, maar zoals ik mijn oma ken pakte ze gelijk de telefoon. Achteraf ben ik haar daar heel dankbaar voor, het heeft mij een stageplek, afstudeerplek en baan opgeleverd. Oma bedankt!!! Vanaf het eerste gesprek dat plaats vond was er voor mij een gevoel dat dit wel goed zat. De omgang was gemakkelijk en informeel, maar wel professioneel, wat naar mijn idee een zeldzaam gebeuren is. De eerste werkdag verliep vlekkeloos, was snel voorbij en nu ik er bijna een jaar rondloop is dat niet veranderd maar alleen maar beter geworden. Elke dag ga ik met plezier naar Hengelo en dat is niet alleen voor het werk maar ook de collega‘s. De afstudeeropdracht inhoudelijk was voor mij een redelijk onbekend gebied. Bedrijfsprocessen inrichten is niet iets wat een informaticus elke dag doet. Toch heeft mij deze kant van de informatica, de bedrijfskundige kant, ook altijd wel aangetrokken. Zeker met de technische kant die er nog aanzit vanuit de raakvlakken met de techniek. Uiteindelijk is de afstudeeropdracht mij goed bevallen. Dat ik de opdracht nu afrond is dankzij een aantal mensen die ik daarvoor graag wil bedanken. Allereerst de begeleiders vanuit de UT Pascal en Djoerd en de begeleiders van The Backbone Nico en Gert. Dankzij jullie heb ik deze opdracht kunnen uitvoeren. Bij het formaliseren van de opdracht was het even spannend. Djoerd vanuit de database groep wil graag een technisch stuk terugzien en Pascal interesseert zich in de bedrijfskundige kant vanuit de rol die hij binnen de BIT studie uitvoert. Nico als visionair die de bedrijfskundige kant helemaal geweldig vindt en Gert die bekend staat als de technische topper. De verschillen tussen de personen, hun interesses en deskundigheid leidde tijdens het formaliseren van de opdrachtomschrijving en de verschillende voortgangsbijeenkomsten tot leuke discussies waardoor gesprekken nooit binnen de tijd bleven. Maar mede door deze verschillen en de kennis die ze samen hebben staat het onderzoek zoals het nu is. Met elke vraag kon ik bij hen terecht en voor elk probleem hadden ze een oplossing. Ik ben ze dan ook alle vier zeer dankbaar voor de zeer goede begeleiding die ik van ze heb gekregen. Top jongens. Daarnaast wil ik de collega‘s van The Backbone bedanken, Martin, Robert, Thijs, Herman, René en Stephan. Ondanks de eeuwige grapjes over processen als ik met een vraag kwam was er nooit iets teveel. Menigmaal heb ik van jullie input gevraagd voor het onderzoek en altijd zonder moeite gekregen. Een bedankje is dus ook zeker op zijn plaats. Last but not least wil ik Annemarie mijn meisje bedanken voor de steun die ze mij heeft gegeven en het geduld dat ze met mij heeft gehad. Door het afstuderen, ondertussen werken en nog een bijbaantje had ik haast nooit tijd. Ondanks dat alles is ze er altijd voor me, heel erg bedankt liefje.


6

1 Inleiding In opdracht van The Backbone is een afstudeeronderzoek uitgevoerd hoe de interne processen en de techniek aangepast moeten worden voor een meer efficiënte en effectieve inrichting. Het onderzoek is in een afstudeerjasje gegoten en uitgevoerd. Dit document is het eindverslag wat hoort bij het afstudeeronderzoek. Het eindverslag beschrijft het onderzoek zoals dit is uitgevoerd. Achtereenvolgens wordt in de hoofdstukken gesproken over de opbouw van het onderzoek, het theoretische raamwerk, de dienstverlening van The Backbone, de huidige situatie bij The Backbone, de gewenste situatie bij The Backbone en de conclusie. Voordat de bovenstaande hoofdstukken aan bod komen wordt eerst de aanleiding van het onderzoek behandeld en een korte inleiding gegeven op het bedrijf The Backbone.

1.1 Aanleiding De aanleiding voor dit onderzoek was tweeledig. Enerzijds is er bij The Backbone behoefte voor een implementatie van Microsoft Operations Framework voor een meer efficiënte en effectieve procesinrichting met inachtneming van de gebruikte applicatie voor monitoring, Microsoft Operation Manager (MOM). Anderzijds is een afstudeeronderzoek een vereiste voor het afronden van de master Computer Science aan de Universiteit Twente. De vraag van The Backbone en de zoektocht naar een afstudeeropdracht bleken perfect op elkaar aan te sluiten.

1.2 The Backbone The Backbone is een relatief jong bedrijf dat zich bezighoudt met IT Infrastructure Services, het ontwerpen, implementeren en beheren van IT infrastructuren. The Backbone biedt zijn diensten aan voor bedrijven en instellingen in Midden en Oost Nederland. Het bestaansrecht van The Backbone komt voort uit de stijgende complexiteit van IT infrastructuren, verschillende technologieën worden samen ingezet om doelstellingen te bereiken, de complexiteit neemt hierdoor toe, benodigde kennis is niet meer aanwezig en het overzicht raakt verloren. Naast de complexiteit stijgt de behoefte aan beschikbaarheid, betrouwbaarheid en continuïteit, drie eisen die vanuit de organisatie gesteld worden aan de IT infrastructuur maar bedreigd worden door de toenemende complexiteit. The Backbone helpt bedrijven en instellingen om het hoofd boven water te houden met de stijgende complexiteit en de hoge eisen die worden gesteld. The Backbone doet dit door de bedrijven en instellingen bij te staan in beheer en projecten, advies te geven en zonodig beheer tijdelijk over te nemen. Het invullen van de dienstverlening gebeurd voornamelijk door systemen vierentwintig uur per dag en zeven dagen per week te monitoren en met behulp van MOM informatie te verzamelen over de systemen. MOM toont op basis van de informatie waar nodig alerts om The Backbone te alameren. Afhankelijk van de alert wordt op een gepaste wijze gereageerd, bijvoorbeeld door het aanpassen van een configuratie, herstarten van een server of het verhelpen van een storing. Naast het monitoren worden bedrijven en instellingen bijgestaan in projecten en ad-hoc werkzaamheden zoals het ontwerpen en realiseren van een nieuwe infrastructuur, vervangen van kapotte onderdelen of het installeren en configureren van systemen.


7

2 Projectomschrijving 2.1 Probleemstelling The Backbone levert diensten op het gebied van netwerken serverbeheer. Deze diensten zijn door derden vrij af te nemen. Bij afname van één of meerdere diensten wordt een Service Level Agreement (SLA) opgesteld waarmee de invulling van de dienst wordt vastgelegd. Binnen de SLA wordt gebruik gemaakt van key performance indicators (kpi‘s) om te bepalen wanneer The Backbone optreedt. Voor The Backbone heeft het nakomen van SLA‘s een hoge prioriteit. Hierbij komen onder andere de volgende aspecten naar voren: Monitoring van server- en netwerkomgevingen Inventarisatie van server- en netwerkomgevingen Afhandelen van binnenkomende calls en alerts Afhandelen van change request Rapportage naar cliënten Contacten onderhouden met cliënten Procesinrichting binnen de eigen organisatie De IT omgeving die beheerd moet worden voor een bedrijf of instelling is bij het aangaan van de overeenkomst voor The Backbone een blackbox. Door middel van een inventarisatie wordt de IT omgeving in kaart gebracht. Hierbij komen zeer diverse systemen naar voren komen waaronder verschillende operating systems, mail servers, terminal servers, database servers, file servers, firewalls, domain controllers, applicatie servers etc. Doordat The Backbone het beheer van servers en netwerken voor verschillende partijen uitvoert neemt de diversiteit in applicaties en systeem sterk toe. Het verschil tussen Windows Server 2003 en Windows Server 2003 Service Pack 1 is van invloed op het beheer en monitoring. Voor een interne IT afdeling is het over het algemeen voldoende één specifiek geval te kunnen beheren, bijvoorbeeld Windows Server 2003. The Backbone moet echter in staat zijn elke denkbare mogelijkheid te kunnen beheren wat een hoge complexiteit met zich meebrengt. Voor het beheren van IT omgevingen maakt The Backbone gebruik van Microsoft Operation Manager (MOM). MOM is in staat meldingen op te vangen van gemonitorde systemen. Dit kunnen zowel hardwaresystemen als softwarematige componenten en applicaties zijn waarbij geen onderscheid wordt gemaakt tussen leveranciers. MOM biedt onder andere ondersteuning voor systemen en applicaties van Microsoft, HP, Cisco, IBM, Dell en Citrix. Met de huidige klanten van The Backbone genereert MOM per seconde 5 Mbit aan data. De data bevat meldingen van uiteenlopende aard. Voorbeelden van meldingen zijn een heartbeat, vollopende of volgelopen schijf, uptime, services die niet draaien, optredende errors etc. Een melding met informatie over een KPI is voor The Backbone relevant, de overige meldingen kunnen gezien worden als zogenaamde ―ruis‖. MOM moet zo worden ingericht dat, voor elke klant, enkel de meldingen worden weergegeven welke informatie geven over de overeengekomen KPI‘s. Deze finetuning is cruciaal. Wordt hier geen aandacht aan besteed dan zullen relevante meldingen ondergesneeuwd worden door de zogenaamde ―ruis‖ wat het nakomen van SLA‘s moeilijk of wellicht onmogelijk maakt. Alleen een technische inrichting is voor The Backbone niet genoeg voor het nakomen van SLA‘s. MOM verzameld informatie, het afhandelen van de verzamelde informatie gebeurd door processen binnen de organisatie. Naast een proces voor het afhandelen van meldingen zijn er binnen The Backbone processen aanwezig voor onder andere het onderhouden van netwerken serveromgevingen, inventarisatie van nieuwe IT omgevingen, het bijhouden van klantencontacten, het genereren van rapportages, het sturen van de organisatie etc. Bij het nakomen van SLA‘s komen verschillende aspecten kijken zoals hierboven duidelijk is geworden. Hieronder vallen naast technische aspecten ook de inrichting van processen binnen de organisatie. The Backbone wil zijn procesinrichting, zowel technisch als organisatorisch, zo vormgeven dat alle SLA‘s nagekomen worden.


8

2.2 Doelstelling The Backbone streeft er naar om aan de vraag van de klant te kunnen voldoen. Dit houdt in dat overeengekomen SLA‘s 100% nagekomen moeten worden. Om dit eenvoudiger te maken dan op de huidige manier gebeurd wordt er gestreefd naar de meest effectieve inrichting van bedrijfsprocessen. Voor het inrichten van de bedrijfsprocessen heeft The Backbone gekozen voor Microsoft Operation Framework (MOF). Deze keuze is mede gemaakt vanwege de Microsoft oriëntatie binnen The Backbone. MOF komt met een checklist en een lijst met best practices voor het inrichten van processen binnen een organisatie. Met behulp van MOF zullen bestaande processen binnen The Backbone aangepast worden en zullen ontbrekende processen gecreëerd worden. Hiermee ontstaat een situatie waarin The Backbone bedacht is op alle mogelijke gebeurtenissen op het gebied van IT infrastructuur en deze ook goed kan afhandelen. MOF is gebaseerd op ITIL, een wereldwijde geaccepteerde en bewezen standaard, en toegespitst op Microsoft omgevingen. Dit maakt MOF de uitgewezen methodiek voor het efficiënt inrichten van processen binnen een Microsoft georiënteerde IT beheerorganisatie. De door MOF ingerichte bedrijfsprocessen zullen door MOM ondersteund worden. Voor een goede en waardevolle ondersteuning moet MOM zo geconfigureerd worden dat het aansluit op de aanwezige bedrijfsprocessen en opgestelde SLA‘s. Naast MOM zal The Backbone gebruik maken van andere applicaties voor onder andere het bijhouden van meldingen, change requests en klanten contacten. Naast een effectieve inrichting van The Backbone om aan de behoefte van de klanten te kunnen voldoen is een efficiënte inrichting van belang. De effectieve procesinrichting kan bijvoorbeeld uitgaan van vijf mensen echter als dit ook met twee mensen kan is het proces niet efficiënt. Het proces terugbrengen naar twee mensen kan daarentegen ten kosten gaan van de effectiviteit. Er zal continu een afweging gemaakt moeten worden of bij meer efficiëntie dit ten koste zal gaan van de effectiviteit en zo ja of dit acceptabel is.

2.3 Onderzoeksvragen Het gat dat is ontstaan tussen de probleemstelling en de doelstelling wordt door dit onderzoek opgevuld en stelt The Backbone in staat de doelstelling te bereiken. De volgende vraag zal tijdens het onderzoek centraal staan: Hoe moet The Backbone, uitgaande van een keuze voor Microsoft Operation Manager en Microsoft Operation Framework als tool en methodiek, zijn processen inrichten om zijn diensten effectief en efficiënt uit te kunnen voeren? Voor het beantwoorden van de onderzoeksvraag is er een opdeling gemaakt in subvragen. De subvragen worden elk afzonderlijk beantwoord. Met de kennis en antwoorden op de subvragen wordt de onderzoeksvraag beantwoord. De volgende vijf subvragen zijn herleid uit de onderzoeksvraag: 1. Hoe ziet de dienstverlening van The Backbone eruit? 2. Hoe ziet de huidige inrichting van processen binnen The Backbone eruit? 3. Welke processen missen er binnen The Backbone en welke processen kunnen worden verbeterd? 4. Welke ondersteuning biedt Microsoft Operation Manager aan de processen voor The Backbone? 5. Welke stappen moeten ondernomen worden voor een effectieve en efficiënte procesinrichting binnen The Backbone volgens MOF?

2.4 Aanpak onderzoek Geen enkele vraag is hetzelfde, dit geldt ook voor de vijf subvragen die centraal staan in het onderzoek. Hieronder wordt per subvraag kort besproken hoe het onderzoek ingevuld zal worden en welke resultaten verwacht worden.


9

2.4.1 Hoe ziet de dienstverlening van The Backbone eruit? Het eerste onderzoek zal worden uitgevoerd naar de dienstverlening van The Backbone. Welke diensten aangeboden worden en op welke manier is van groot belang voor de invulling van processen. Als de dienstverlening en de processen niet op elkaar aansluiten wordt het voor een bedrijf moeilijk om zijn doelen te halen. Om de dienstverlening in kaart te brengen worden twee activiteiten uitgevoerd. Enerzijds zal intern binnen The Backbone gesproken worden met consultants, account managers en de directie om hun visie op papier te zetten. Anderzijds zal er voor een klant een business case opgesteld worden waarin het probleem en doel van de klant besproken wordt evenals de aanpak om het doel te bereiken, een evaluatie van het project, of aan alle verwachtingen is voldaan etc. Samen geven deze twee activiteiten een beeld over de dienstverlening van The Backbone. 2.4.2 Hoe ziet de huidige inrichting van processen binnen The Backbone eruit? Het beschrijven van de nieuwe procesinrichting kan gebeuren vanuit de bestaande situatie of vanaf een schone lei. In het geval van The Backbone is er voor gekozen rekening te houden met de bestaande processen. Om verder te gaan met het onderzoek is het daarom noodzakelijk de bestaande procesinrichting in kaart te brengen. Gedurende een aantal weken zal geprobeerd worden een zo volledig mogelijk beeld te scheppen van de huidige procesinrichting. Interviews en brainstorm sessies met medewerkers, het observeren tijdens de normale werkzaamheden en het bestuderen van gebruikte resources moet informatie opleveren om de huidige procesinrichting te documenteren. Uit de verzamelde informatie zal beschreven worden hoe de huidige inrichting er uitziet. Een proces beschrijven is moeilijk en mensen zullen de beschrijving verschillend interpreteren. Daarnaast geeft tekst geen duidelijk en samenhangend beeld van een proces. Alle processen worden daarom uitgewerkt in diagrammen, toegelicht door de teksten. 2.4.3

Welke processen missen er binnen The Backbone en welke processen kunnen worden verbeterd? Op basis van de bestaande situatie die in kaart is gebracht kan er worden gekeken naar de aandachtspunten. Hiervoor zal een vergelijking worden gemaakt tussen de aanwezige processen en de beschrijvingen van MOF en IT Service CMM. Een combinatie van beide resultaten moet een lijst opleveren met aandachtspunten voor The Backbone. De vergelijking zal gebaseerd worden op de huidige situatie zoals geschetst in de voorgaande subvraag. Om interpretatiefouten te voorkomen en de betrouwbaarheid van het onderzoek te verhogen zal een validatie van de resultaten plaatsvinden. De gevonden aandachtspunten worden teruggekoppeld naar de organisatie en gevalideerd. 2.4.4

Welke ondersteuning biedt Microsoft Operation Manager aan de processen voor The Backbone? Voor het daadwerkelijk monitoren van IT omgevingen maakt The Backbone gebruik van Microsoft Operation Manager (MOM). In de nieuwe situatie zal deze applicatie blijven bestaan en de invoer leveren aan een groot deel van de processen. De afstemming tussen MOM enerzijds en de processen anderzijds is van groot belang. Aan het begin van het onderzoek zal een labomgeving worden opgezet waarmee de productieomgeving wordt nagebootst. De labomgeving zal tijdens deze fase in het onderzoek gebruikt worden om te kijken hoe MOM de aandachtspunten kan ondersteunen. De resultaten van deze fase zullen bij het schrijven van het advies meegenomen worden. 2.4.5

Welke stappen moeten ondernomen worden voor een effectieve en efficiënte procesinrichting binnen The Backbone volgens MOF? Op dit moment zijn twee zaken duidelijk, de verbeterpunten en de ondersteuning van MOM aan de processen. Wat mist is een beschrijving van de oplossingen voor de verbeterpunten,


10

hoe de processen het beter ingericht kunnen worden voor het halen van de doelstellingen en hoe MOM hierin helpt. Deze onderzoeksvraag levert daarom uiteindelijk een advies op aan The Backbone waarin de bovenstaande punten zijn uitgewerkt met in acht neming van de schaalbaarheid en haalbaarheid van het aangedragen advies.

2.5 Leeswijzer De bovenstaande subvragen worden elk afzonderlijk besproken in het eindverslag. De dienstverlening van The Backbone, subvraag 1, wordt in hoofdstuk 4 behandelt. Hoofdstuk 5 bespreekt de huidige processen en de analyse van ontbrekende processen en processen die verbeterd kunnen worden, subvraag 2 en 3. De laatste twee subvragen, subvraag 4 en 5, die ingaan op de stappen die genomen moeten worden voor een efficiënte en effectieve procesinrichting en de ondersteuning van MOM aan de processen worden in hoofdstuk zes besproken. Het vertrouwelijke document diept subvraag 4 en 5 verder uit.


11

3 Theoretisch raamwerk In dit hoofdstuk wordt een theoretisch raamwerk neergezet voor het onderzoek. In het eerste deel van het hoofdstuk worden Business Process Redesign en IT Service Management behandeld. Het hoofdstuk wordt afgesloten met een raamwerk waarin de beschreven literatuur wordt gekoppeld aan het onderzoek en een ―kijk op de wereld‖ wordt gedefinieerd.

3.1 Business Process Redesign Met regelmaat worden procesinrichtingen binnen organisaties herzien. De oorzaak van de herziening is vaak een bezuiniging of de hogere kwaliteit die gesteld wordt aan geleverde producten en diensten. Het doel van de nieuwe procesinrichting is veelal een meer efficiënte en / of effectieve werkwijze. Het opnieuw inrichten van processen wordt Business Process Redesign (BPR), of ook wel Business Process Change, Business Process Reengineering en Business Process Improvement genoemd. 3.1.1 Definitie Tabel 1 geeft drie definities weer voor Business Process Redesign. In 1990 zijn twee onderzoeken gepubliceerd, één door Hammer en één door Davonport & Short. Beide onderzoeken hebben Business Process Redesign als onderwerp en geven invulling aan de definitie. In de literatuur wordt afwisselend gebruik gemaakt van de definities van Hammer & Champy en Davonport & Short. Herkomst Hammer 1990 [HAM90]

Definitie The fundamental rethinking and radical redesign of business processes to achieve dramatic improvements in critical measures of performance (e.g. cost, quality, capital, service, speed)

Davenport & Short 1990 [DAS90]

The analysis and design of workflows and processes within and between organizations

Tabel 1 - Definities Business Process Redesign Dat er niet één duidelijke definitie bestaat voor Business Process Redesign blijkt uit de twee hierboven genoemde onderzoeken en andere gevonden literatuur. Zo is Grant [GRA02] het niet eens met de definitie van Hammer en bekritiseerd deze in zijn onderzoek. Volgens Grant zijn naast de business processen ook de technologie, communicatie, mensen en structuur belangrijk voor BPR. Grant stelt daarnaast dat BPR projecten op drie verschillende niveaus kunnen plaats vinden, strategisch, management en operationeel niveau. Hammer zag dit blijkbaar ook en heeft in 1993 samen met Champy het stuk Reenginering the Corporation [HAC93] gepubliceerd en daarmee definitie lichtelijk herzien [DST] van ―...redesign of business processes…‖ naar ―…redesign of an entire business system…‖. 3.1.2 Bottlenecks Veel BPR projecten worden niet succesvol afgerond waarvan de oorzaak vaak één van de bekende valkuilen is. Drie van deze valkuilen zijn het gebrek aan commitment vanuit het management, tegenstand vanuit de werknemers en te hoge verwachtingen van het project [MAL98, WEI95]. Het opnieuw inrichten van processen zal snel op tegenstand duiden. Werknemers vrezen voor hun baan en zien niet in waarom veranderingen nodig zijn. In hun ogen lopen de processen goed en bedenken mensen van bovenaf nieuwe processen, mensen die zelf niet met de processen werken. Om deze tegenstand en angst te voorkomen is het van belang dat medewerkers betrokken worden bij veranderingen en de visie van het bedrijf kennen. In geval van tegenstand moeten managers bereid zijn op te treden, commitment van managers is nodig. Daarnaast moeten managers in staat zijn om na het afronden van het


12

redesign plan alle remmen los te gooien en de implementatie door te voeren om te voorkomen dat de implementatie halverwege in het proces blijft hangen waardoor een slechtere situatie kan ontstaan als voor de implementatie. 3.1.3 Methoden Het door Davenport [DAS90] geschreven onderzoek uit 1990 behandelt de ‗waarom‘ vraag voor BPR. Davenport heeft de ‗hoe‘ vraag ingevuld met het boek Process Innovation: Reengineering Work Through Information Technology [DAV92] waarin een zes stappen benadering uitéén wordt gezet. De laatste van de de zes stappen is daarbij optioneel. Davenport gebruikt de volgende vijf stappen voor BPR, de zesde stap is een optionele stap [12MAN]: 1. Ontwikkel de bedrijfsvisie en procesdoelstellingen: De BPR methode wordt gestimuleerd door een bedrijfsvisie welke specifieke bedrijfsdoelstellingen zoals kostenvermindering, tijdvermindering, en verbetering van de outputkwaliteit impliceert. 2. Identificeer de te herontwerpen bedrijfsprocessen: de meeste firma's gebruiken een „hoge-impact― aanpak welke zich op de belangrijkste processen concentreert of op degenen die het meest strijdig zijn met de bedrijfsvisie. Een kleiner aantal firma's gebruiken een „diepgaande aanpak― welke probeert om alle processen te identificeren binnen een organisatie en vervolgens diegenen voorrang te geven in volgorde van herontwerpurgentie. 3. Begrijp en meet de bestaande processen: om het herhalen van oude fouten te vermijden en een uitgangssituatie voor toekomstige verbeteringen te bieden. 4. Identificeer IT hefbomen: bekendheid met de mogelijkheden van IT kan en zou BPR moeten beïnvloeden. 5. Ontwerp en bouw een prototype van het nieuwe proces: het daadwerkelijke ontwerp zou niet als het einde van het BPR proces moeten worden gezien. Eerder, zou het als prototype, met opeenvolgende herhalingen moeten worden behandeld. De metafoor van het prototype combineert het Herontwerpen van Bedrijfsprocessen met de snelle levering van resultaten, en de betrokkenheid en de tevredenheid van klanten. 6. het aanpassen van de organisatorische structuur, en het governance (bestuur)model, naar het zojuist ontworpen primaire proces . Het uitvoeren van BPR projecten gebeurd veelal door consultants in dienst van gespecialiseerde bedrijven zoals PriceWaterHouseCoopers, Capgemini en Ernst &Young. In de praktijk blijkt dat bedrijven eigen methodes ontwikkelen voor Business Process Redesign. Kettinger, Teng en Guha [KTG97] hebben een onderzoek uitgevoerd naar verschillende methoden, technieken en applicaties voor Business Process Change. Figuur 1 is één van de resultaten uit het onderzoek en geeft enkele ontwikkelde methoden weer.


13

Figuur 1 - Business Process Redesign methodieken

3.2 IT Service Management Door de toenemende omvang en complexiteit van IT omgevingen wordt het beheer in toenemende mate uitbesteed aan specialistische bedrijven. Het voortbestaan van een beheerorganisatie is afhankelijk van de tevredenheid van de klanten en of aan de wens van de klant voldaan kan worden. Om dit te bereiken is het noodzakelijk dat intern de dienstverlening op orde is. Het intern organiseren van beheerdiensten op het gebied van IT wordt ook wel IT Service Management genoemd. 3.2.1 Definitie Een algemeen geaccepteerde en gebruikte definitie voor IT Service Management is niet gevonden. In de literatuur en gebruikte methodieken worden verschillende omschrijvingen


14

gebruikt. Sallé [SAL04] heeft in 2004 een vergelijkend onderzoek uitgevoerd en gebruikt hierin de volgende omschrijving voor voor IT Service Management: A set of processes that cooperate to ensure the quality of live IT services, according to the levels of service agreed to by the customer. It is superimposed on management domains such as systems management, network management, systems development, and on many process domains like change management, asset management and problem management. Tabel 2 geeft de gebruikte omschrijving voor IT Service Management weer uit een drietal methodieken. De omschrijving gebruikt door Sallé vergeleken met de andere drie gegeven omschrijvingen komen inhoudelijk sterk overeen. Allemaal benoemen ze de aspecten kwaliteit, het leveren van IT diensten en de afstemming met de klant / business needs. Drie aspecten waar het bij IT Service Management daadwerkelijk om gaat, het leveren van IT diensten welke op kwalitatief niveau aansluiten bij de behoeften van de klant. Herkomst

Omschrijving

ITIL [ITILSM]

IT Service Management is a top-down, business driven approach to the management of IT that specifically addresses the strategic business value generated by the IT organisation and the need to deliver a high quality IT service. IT Service Management is designed to focus on the people, processes and technology issues that IT organisations face.

MOF [MOFSM]

IT service management is concerned with delivering and supporting IT services that are implemented in direct response to the organization‘s business requirements.

HP [HPSM]

A business-driven approach that IT organizations can use to design, build, manage, and evolve quality IT services that: Are customer-focused and process-driven Meet quality, agility, and cost targets Enable the achievement of service-level targets as defined in servicelevel agreements (SLAs) Tabel 2 - Omschrijvingen IT Service Management 3.2.2 Methodieken Vanaf 1980 tot nu zijn door de jaren heen verschillende methodieken gepubliceerd voor IT Service Management. IBM was hiermee de eerste rond 1980 en is begonnen met het documenteren van de interne processen. De UK government Central Computer and Telecommunications Agency (CCTA) heeft dit aan het eind van de jaren 80 gedaan voor de Britse overheid, de uitkomst is gepubliceerd als ITIL wat als eerste standaard voor IT Service Management wordt gezien. Een steeds breder gebruik en grotere vraag naar ITIL heeft een trend gezet in de ontwikkeling van IT Service Management methodieken. Onder andere Microsoft, Hewlett-Packerd en IBM hebben hun eigen methodiek ontwikkeld, veelal gebasseerd op ITIL.


15

Figuur 2 – Overzicht ontwikkeling IT Service Management methodieken Figuur 2 geeft de ontwikkeling van IT Service Management methodieken weer. Te zien is dat na 1990 en de komst van ITIL het aanbod methodieken sterk toeneemt en bedrijven eigen methodieken ontwikkelen. Onder andere HP, Microsoft en IBM zijn terug te zien in het figuur. Voor dit onderzoek zijn de onderstaande methodieken relevant en worden kort toegelicht: ITIL als basis van MOF MOF voor de inrichting van de processen IT Service CMM als ondersteuning van MOF ITIL De IT Infrastructure Library (ITIL) wordt gezien als de standaard voor IT Service Management. ITIL is in de eind jaren 80 uitgebracht door de Central Computer and Telecommunications Agency (CCTA), onderdeel van de Britse regering, om de kosten van IT service delivery omlaag te brengen en management te verbeteren. Tegenwoordig wordt ITIL onderhouden door Office of Government Commerce (OGC) ondersteund door het IT Service Management Forum (itSMF). De huidige versie van ITIL, ITIL 2, is een verzameling van best practices waarin beschreven wordt hoe processen ingericht kunnen worden voor een kwalitatief goede IT dienstverlening. ITIL is opgedeeld in acht delen welke afzonderlijk te verkrijgen zijn. IT Service Delivery en IT Service Support, de twee meest gebruikte delen, beschrijven samen IT Service Management. De overige zes delen beschrijven Application Management, ICT Infrastructure Management, Security Management, Software Asset Management, The Business Perspective en Planning to Implement Service Management. Het ITIL Refresh project [ITILR] moet in februari 2007 een nieuwe versie van ITIL opleveren als gevolg op de veranderende technologie en business requirements. De nieuwe versie van ITIL moet daarnaast makkelijker in gebruik zijn, beter toe te passen en ook geschikt zijn voor organisaties van kleinere omvang. De core van de nieuwe ITIL versie wordt opgedeeld in vijf delen, Service Strategies, Service Design, Service Introduction, Service Operation en Continuous Service Improvement. Daarnaast komt OGC met enkele aanvullende zaken als web-based support voor de vijf core delen, pocket guides, case studies, governance methoden etc.


16

MOF Microsoft Operation Framework (MOF) is de Microsoft variant voor IT Service Management. MOF is gebaseerd op ITIL, toegespitst op Microsoft omgevingen en uitgebreid op basis van de grote hoeveelheid kennis aanwezig binnen de Microsoft organisaties, klanten en partners. Een complete vergelijking tussen ITIL en MOF, vanuit de visie van Microsoft, wordt besproken in MOF - An Actionable and Prescriptive Approach to ITIL [MOFIT]. Binnen MOF zijn processen opgedeeld in 4 kwadranten, Changing, Operating, Supporting en Optimizing. Binnen elke kwadrant zijn processen vervolgens opgedeeld in verschillende Service Management Functions (SMF‘s). Voorbeelden van SMF‘s zijn Change Management, Network Administration, Service Desk, Service Level Management en Financial Management. Het geheel van de 4 kwadranten en in totaal 20 SMF‘s wordt binnen MOF het Process Model genoemd, zie Figuur 3.

Figuur 3 - MOF process model Naast het proces model kent MOF het Team Model en de Risk Management Discipline. Het MOF Team Model is een best practice voor het organiseren van mensen en teams binnen een organisatie. In totaal kent het model 7 teams welke elke hun eigen rollen en verantwoordelijkheden hebben. Het Risk Management Discipline is een proces voor het proactieve signaleren, beheren en evalueren van risico‘s.

IT Service CMM IT Service CMM [ITSCMM] is gebaseerd op het Software Capability Maturity Model (Software CMM) [SCMM]. Software CMM, tegenwoordig bekend als CMM Integrated [CMMI] heeft als doel een organisatie betere controle te geven over de bedrijfsprocessen rond software ontwikkeling. Om aan te geven in welk stadium een organisatie zich begeeft en waar binnen de organisatie aandacht aan besteed moet worden om meer controle te krijgen wordt gebruik gemaakt van vijf maturity levels. Elk level definiëert een aantal processen, Key Processes, die aanwezig moeten zijn om in het desbetreffende level te raken. De volgende vijf levels zijn aanwezig in Software CMM [VSB04]: 1. Initial: een niet geformaliseerd, ambachtelijk proces 2. Repeatable: een herhaalbaar proces. Herhalen van het proces door andere werknemers dan de eerste keer levert een identiek resourcegebruik en eindproduct op.


17

3. Defined: een gedefiniëerd proces, waarbij het volgen van de procedures een garantie is voor het welslagen van het proces. 4. Managed: alle stappen in het proces kunnen worden geanalyseerd, gekwalificeerd en gemeten. 5. Optimizing: de basis is gelegd voor een continue proces(stap)verbetering. IT Service CMM kent dezelfde vijf levels van maturity als het Software CMM en vult de vijf levels met de afzonderlijke processen. Hierbij worden de basis processen voor een beheerorganisatie, zoals Service Commitment Management en Configuration Management, in de laagste levels geplaatst en de meer professionele processen, zoals Problem Prevention en Technology Change Management, in de hoogste levels. Het verschil met een methodiek als ITIL of MOF is dat IT Service CMM voorschrijft welke processen nodig zijn en niks zegt over de invulling. Daarnaast zegt IT Service CMM iets over de noodzaak van de processen door ze in vijf levels in te delen, hier doet ITIL of MOF niks mee.

3.3 Raamwerk onderzoek Business Process Redesign staat centraal in het onderzoek en om invulling te geven aan de nieuwe processen wordt gebruik gemaakt van een combinatie tussen MOF en ITIL. Vanwege de onderlinge verschillen tussen de gebruikte methodieken wordt hieronder een ―kijk op de wereld‖ gedefiniëerd die tijdens het onderzoek gebruikt zal worden. 3.3.1 Business Process Redesign De methode die in het onderzoek gebruikt wordt voor het herinrichten van de processen is analoog aan de vijf stappen die beschreven zijn door Davonport met enkele aanpassingen. Op de onderstaande wijze worden de vijf stappen ingevuld en gekoppeld aan de onderzoeksvragen:

1

BPR stap Ontwikkel de bedrijfsvisie en procesdoelstelling

2

Identificeer de te herontwerpen bedrijfsprocessen

3

Begrijp en meet de bestaande processen Identificeer IT hefbomen

Onderzoeksvraag Hoe ziet de dienstverlening van The Backbone eruit?

Hoe ziet de huidige inrichting van processen binnen The Backbone eruit?

Invulling Opstellen van een business case Beschrijven van de interne visie op de dienstverlening Uitvoeren van een assessment voor het in kaart brengen van alle huidige processen (diepgaande aanpak) Huidige processen vergelijken met MOF en IT Service CMM

Welke processen missen er binnen The Backbone en welke processen kunnen worden verbeterd? 4 Welke ondersteuning biedt Onderzoek naar de Microsoft Operation Manager aan ondersteuning van MOM aan de processen voor The Backbone? de processen 5 Ontwerp en bouw Welke stappen moeten Schrijven van een advies aan een prototype van ondernomen worden voor een The Backbone voor een het nieuwe proces effectieve en efficiënte nieuwe inrichting van de procesinrichting binnen The processen Backbone volgens MOF? Tabel 3 - Relatie tussen de BPR stappen volgens Davenport en de onderzoeksvragen

3.3.2 IT Service Management Vanwege de Microsoft inslag van The Backbone is er gekozen voor het Microsoft Operation Framework. De best practices beschreven binnen MOF zullen worden geïmplementeerd binnen The Backbone op een werkbare manier. Naast het MOF framework zal er gebruik gemaakt worden van IT Service CMM. Het grote verschil tussen IT Service CMM en MOF is het gebruik van maturity binnen IT Service CMM. De maturity geeft aan op welk niveau de processen binnen de organisatie zijn ingericht. De maturity kan daarnaast gebruikt worden voor het prioritiseren van aandachtspunten. Met behulp van een vergelijking tussen de key


18

area‘s in IT Service CMM en de SMF‘s in MOF worden in het advies prioriteiten gegeven gebaseerd op de maturity van IT Service CMM.

3.4 Afbakening onderzoek De door MOF en / of IT Service CMM beschreven processen komen nooit overeen met de processen binnen een organisatie. Elke organisatie is uniek en IT Service Management methoden kunnen enkel als een middel gebruikt worden om de gangbare processen te beschrijven. De processen die voor de organisatie uniek zijn moeten met behulp van andere methoden worden beschreven. Figuur 4 geeft bovenstaande grafisch weer. Het grote rechthoek staat voor een organisatie, bijvoorbeeld The Backbone. De organisatie kan opgedeeld worden in verschillende afdelingen / processen, de vierkante vakken binnen het rechthoek. Elk vierkant staat hierbij voor een afzonderlijk onderdeel binnen de organisatie, één van de vakken zou bijvoorbeeld overeen kunnen komen met de SMF Change Management. De Figuur 4 dekking van MOF en IT Service CMM is weergegeven door de blokken te arceren. Hieruit wordt duidelijk dat bepaalde processen, de witte vlakken, binnen de organisatie niet bekeken zullen worden omdat geen van de methodieken hier iets over zegt. Het doel van dit onderzoek is een efficiënte en effectieve procesinrichting voor het uitvoeren van de diensten met als gekozen middelen MOF en MOM. Dit houdt in dat enkel het gearceerde vak binnen het raamwerk wordt behandeld. Een afdeling zoals sales en de processen rondom de inkoop van hardware zullen hierdoor buiten beschouwing worden gelaten. Aangezien enkele niet door MOF gedekte vlakken, de witte vlakken, wel in aanraking komen met de processen van MOF zal in de gewenste situatie hier rekening mee gehouden worden. In de beschrijving van de gewenste situatie zal dit naar voren komen in de afhankelijkheden van de processen. Bijvoorbeeld Monitoring & Control is afhankelijk van Sales, zonder klanten geen beheer.


19

4 Dienstverlening The Backbone In dit hoofdstuk wordt de dienstverlening van The Backbone behandeld. De dienstverlening is vanuit twee opzichten bekeken, intern en extern. Voor de interne visie zijn interviews afgenomen met directie leden. Om de externe visie vast te leggen is een business case opgesteld van een bestaande klant. Achtereenvolgens worden de resultaten van beide activiteiten behandeld.

4.1 De markt volgens The Backbone Op het niveau van strategisch management speelt de visie van een bedrijf een belangrijke rol. Om de visie te achterhalen wordt regelmatig gebruik gemaakt van een aantal vragen, bijvoorbeeld ―What business are we in?‖, een vraag die in het verleden al menig maal met succes is gebruikt [JOSC93, LEVI60] Mogelijke andere vragen zijn ―What products and services will we offer?‖, ―To whom?‖, At what prices?‖, ―On what terms?‖, ―Against which competitors?‖ en ―On what basis will we compete?‖ [NICK02]. In de interviews zijn drie vragen gesteld, ―What business are we in?‖ is de eerste gevolgd door gevolgd door ―What customers do we have?‖ en als laatste ―What are the demands of the customers?‖. In totaal zijn drie interviews afgenomen, de resultaten zijn samengenomen en uitgewerkt tot een samenvattend verhaal. Voor de betrouwbaarheid heeft er een terugkoppeling naar de geïnterviewden plaatsgevonden. 4.1.1 What business are we in? IT dienstverleners kunnen opgedeeld worden in drie groepen zoals weergegeven in Figuur 5. Bedrijven in de onderste groep hebben een brede dienstverlening, alle facetten van de IT zijn gedekt. Hierbij kan gedacht worden aan diensten als desktop en application management, application development, storage solutions, mobile networking, service oriented architectures etc. Doordat IT afdelingen en IT resources over het algemeen compleet worden overgenomen door de dienstverlener wordt hier over outsourcing gesproken.

Infra structuur Infrastructuur + Bedrijven: Getronics, Centric Alles Bedrijven: IBM, EDS

De middelste laag uit de piramide zijn gespecialiseerder dan de onderste laag. Waar bij de onderste laag alle facetten van de IT Figuur 5 zijn gedekt wordt binnen de middelste laag toegespitst op de meer gangbare diensten zoals de infrastructuur en de werkplekken, zeer specifieke diensten zoals applicatie ontwikkeling worden niet aangeboden.

Ook al zijn de horizontale markten tussen verschillende sectoren gelijk, door het grote aanbod aan verschillende technieken en producten die

Database Operating system Hardware Infrastructuur Figuur 6


20

Bouw

Transport

Financieel

Overheid

Figuur 6 is een aanvulling op de piramide die het verschil tussen de verschillende spelers extra onderstreept. In de markt wordt onderscheid gemaakt tussen verticale en horizontale markten. Verticale markten zijn specifiek per sector, horizontale markten zijn vergelijkbaar bij verschillende soorten sectoren. De onderste laag uit de piramide richt zich op het hele figuur, de verticale en horizontale markten, de middelste laag slechts de horizontale markten en wellicht enkele verticale, de bovenste laag uit de piramide houdt zich alleen bezig met de onderste horizontale markten het beheer van de infrastructuur, hardware en operating systems.

Zorg

In de top van de piramide zitten de bedrijven die zich alleen richten op de infrastructuur. De infrastructuur is, vergeleken met de overige diensten, bij alle klanten aanwezig en ook vergelijkbaar. Afhankelijk van de klant worden bepaalde taken overgenomen door de dienstverlener, bijvoorbeeld het gehele beheer of wellicht enkel het monitoren van de infrastructuur. Het uitbesteden van bepaalde taken aan een dienstverlener wordt vaak outtasking genoemd. The Backbone is één van de bedrijven uit de top van de piramide.

aangeboden kunnen er keuzes gemaakt worden. Reikt de ondersteuning tot de werkplek of alleen de servers, wordt hardware geleverd of wordt dit uitbesteed, is er voorkeur voor één hardwareleverancier of worden meerdere ondersteund, etc. The Backbone staat voor kwaliteit, een brede dienstverlening kan dit in de weg staan. The Backbone heeft er voor gekozen zich te richten op een specifiek aantal diensten en deze met 100% kwaliteit aan te bieden, zie Figuur 7. The Backbone heeft ervoor gekozen alleen Windows, VMWare en Citrix te ondersteunen op het gebied van monitoring, beheer en implementatie. Dit blijkt ook uit de visie van The Backbone: Wij willen de beste zijn in de levering van monitoring, beheer en implementatie diensten voor basis IT infrastructuur op het gebied van Microsoft, VMWare en Citrix.

Storage

Hosted Exchange

Infrastructuur: Windows VMWare Citrix Werkplek beheer

VOIP

Figuur 7

4.1.2 What customers do we have? Potentiële klanten voor een IT infrastructuur dienstverlener kunnen opgedeeld worden naar verschillende maatstaven, bijvoorbeeld de sector, geleverde diensten of producten, geografische ligging, aantal werknemers, etc Als gekeken wordt naar de sector is het niet van belang of een bedrijf een prospect is of niet, bij geleverde diensten of producten wel. The Backbone richt zich namelijk alleen op eindgebruikers van de IT, een bedrijf wat als dienstverlening webhosting aanbiedt zal nooit een klant worden. Bedrijfseigenschappen zoals de geografische ligging, het aantal werknemers, het aantal werkplekken e.d. is niet van toepassing, elke bedrijf kan beheerd worden. Hierbij moet wel de kanttekening gemaakt worden dat dit afhankelijk is van de dienst. Met de huidige mogelijkheden qua verbindingen is monitoring over de hele wereld mogelijk, beheer op locatie is echter een probleem vanwege de aanwezigheid van mensen, reistijden, taalproblemen, etc. 4.1.3 What are the demands of the customers? Alle klanten en potentiële klanten hebben gemeen dat ze een partner zoeken voor het monitoren en / of beheren van de IT omgeving. Daarbij komt dat vaak een tweede en derde support lijn worden afgenomen die in geval van incidenten geraadpleegd kunnen worden. Mochten eigen medewerkers uitvallen is het mogelijk terug te vallen op The Backbone die de werkzaamheden tijdelijk overneemt. Dit alles heeft te maken met de continuïteit van het bedrijf. Door de toenemende complexiteit van IT omgevingen en de verscheidenheid aan producten en oplossingen wordt naast continuïteit kennis steeds belangrijker. The Backbone kan hierbij helpen. Medewerkers van The Backbone krijgen dagelijks te maken met verschillende producten en verschillende versies van producten waardoor ze goed op de hoogte zijn van alle mogelijkheden, afhankelijkheden en valkuilen. Daarnaast is The Backbone dagelijks bezig met de toekomst en doet de organisatie er alles aan om nieuwe technieken zo snel mogelijk op te nemen. Door de aanwezigheid van deze kennis kan The Backbone advies geven en implementaties en migraties uitvoeren. Klant en sector specifiek is de invulling van de dienst vaak verschillend. Bij de invulling van de dienst worden afspraken gemaakt over bijvoorbeeld het service window, de maximale downtime en de reactietijd bij incidenten. Voor een bedrijf in de juridische sector is 7x24 monitoring en een snelle reactietijd een vereiste aangezien de medewerkers dag en nacht werken en zeer afhankelijk zijn van de IT. Voor een scholengemeenschap zal een dienst als deze overkill en te zwaar zijn aangezien hun primaire werkzaamheden niet zeer afhankelijk zijn van de IT.


21

4.2 Business Case De dienstverlening is vanuit het externe oogpunt bekeken door een medewerker van de klant te interviewen. In het interview is ingegaan op de dienst, kwaliteit, tevredenheid en eventuele wensen van de klant. In de onderstaande uitwerking van het interview is de naam van de klant fictief. De geïnterviewde klant, Jansen B.V. was voor The Backbone één van de eerste klanten. De dienst die wordt afgenomen is monitoring en beheer van de IT omgeving. In het geval van Jansen B.V. houdt beheer het complete beheer in, van het wijzigen van wachtwoorden tot het installeren van nieuwe systemen en het uitvoeren van migraties. Voor Jansen B.V. worden naast de servers tevens de werkplekken beheerd. Over de kwaliteit van de dienstverlening heeft de klant niks te klagen. Incidenten en vragen worden door de medewerkers van The Backbone altijd netjes en tijdig afgehandeld. Doordat de dienstverlening van mensen afkomt was dit in het begin wel aftasten. Wat de klant als een positief punt ervaart is de contactpersoon binnen The Backbone voor de klant. Door het toewijzen van een contactpersoon heeft één medewerker binnen The Backbone een grote kennis van de klantomgeving. De tevredenheid van de klant is hoog. In het begin is een migratie uitgevoerd van Windows 98 naar Windows XP. Op dat moment is veel gesproken over security. De doelstellingen zijn niet allemaal gehaald, achteraf is dit niet erg. Dat de tevredenheid hoog is blijkt, naast dat de klant dit benoemd, uit de lange onderlinge relatie en het feit dat de klant nooit de wens heeft gehad over te stappen naar een andere dienstverlener. Normen voor de dienstverlening zijn niet precies vastgelegd met The Backbone en het contract is nooit helemaal doorgespit. Zolang er geen wanprestaties plaatsvinden is deze behoefte er ook niet. Over de wensen heeft de klant slechts één ding te zeggen. Vanaf het begin is gezegd dat er rapportages toegestuurd zouden worden. In de loop van de tijd heeft dit steeds meer vorm gekregen. De klant zou het rapportage verhaal graag terugzien in een webportal waar zelf de rapportages opgehaald kunnen worden op het moment dat de klant dit wil. Het aanspreekpunt binnen de organisatie van de klant geeft dit de mogelijkheid zich te verantwoorden tegenover zijn meerderen.


22

5 Huidige inrichting van The Backbone Om een beeld te krijgen van de huidige procesinrichting is een assessment uitgevoerd. Tijdens het assessement zijn alle medewerkers geïnterviewd, documenten, applicaties en andere informatiebronnen zijn bekeken en als laatste is enige tijd op de werkvloer doorgebracht. In dit hoofdstuk worden de resultaten van het assessment besproken samen met de vergelijking die is gemaakt tussen de resultaten van het assessment en de methodieken MOF en IT Service CMM.

5.1 Opbouw hoofdstuk De beschrijving van de resultaten is opgedeeld in verschillende hoofdstukken. Achtereenvolgens worden besproken De totstandkoming van het interview en de uitvoering van het interview Het team van medewerkers bij The Backbone met een vergelijking met het Team model van MOF De huidige processen binnen The Backbone met een vergelijking met MOF Gebruikte applicaties in de huidige situatie De vragen in het interview zijn ingedeeld per System Management Functie (SMF), deze indeling is in de beschrijving van de resultaten overgenomen. Per SMF wordt de huidige situatie uitgelegd, samengevat wat MOF schrijft over de processen, de eisen gesteld door IT Service CMM en een overzicht van de belangrijkste aandachtspunten die aanwezig moeten zijn volgens MOF en IT Service CMM. In het overzicht wordt met de onderstaande symbolen aangegeven of er binnen The Backbone aandacht aan is besteed. Symbool

Omschrijving Dit aspect is volledig ingedekt binnen de organisatie Aan dit aspect is aandacht besteed binnen de organisatie echter het is nog niet op het niveau zoals dit door MOF wordt beschreven. Dit aspect is niets mee gedaan binnen de organisatie

Voorafgaand aan de beschrijving van de processen per SMF wordt kort ingegaan op de algemene bevindingen over de huidige processen.

5.2 Interview Het doel van het interview was een beeld krijgen van de huidige procesinrichting en gebruikte applicaties bij The Backbone. De verkregen informatie zal gebruikt worden voor het identificeren van knelpunten en het aandragen van verbeterpunten in de procesinrichting. Het aandragen van verbeterpunten wordt gedaan met behulp van MOF en IT Service CMM. Om een goede vergelijking te kunnen maken tussen de huidige situatie aan de ene kant en de MOF best practices en de gestelde eisen door IT Service CMM aan de andere kant is het interview op beide methodieken gebaseerd. Figuur 8 geeft de opbouw van het interview weer. Aan de ene kant staat IT Service CMM samen met de IT Service CMM Questionnaire, een vragenlijst geschreven door de auteurs van IT Service CMM die gebruikt kan worden voor het uitvoeren Figuur 8 - Opbouw interview van assessments op basis van IT Service CMM. Aan de andere kant staat MOF samen met de MOF Self Assessment Tool v1.0 en MOF Self Assessment Tool v2.0, beide uitgebracht door Microsoft. De Self Assessment Tool v1.0 is de oude versie van de tool en kon gebruikt worden voor het


23

opsporen van knelpunten in een procesinrichting. Versie 2.0 is afwijkend van versie 1.0 en kan worden gebruikt om een rapport te genereren dat een specifiek probleem binnen een procesinrichting beschrijft. Versie 2.0 van de MOF Self Assessment Tool is niet gebruikt voor het interview. De release van versie 2.0 vond plaats tijdens het uitvoeren van de interviews en daarnaast bleek de tool zodanig veranderd te zijn dat het doel niet meer aansloot bij de interviews. Het interview is tot stand gekomen door de vragen uit MOF Self Assessment Tool v1.0 over te nemen, hierbij is de scheiding in vragen per SMF behouden. Versie 1.0 van de Self Assessment Tool is gebaseerd op een oudere versie van MOF en sluit niet geheel aan bij de nieuwste versie, versie 3.0, die gebruikt wordt tijdens het onderzoek. Voor een betere aansluiting is de lijst met vragen uitgebreid en zijn er enkele vragen aangepast of verwijderd. De vragenlijst tot dusver is aangevuld met vragen uit de IT Service CMM Questionnaire. De IT Service CMM Questionnaire bevat vragen voor de zeven key area‘s uit level twee, de overige levels worden niet gedekt. Om de vragen op te nemen in het interview is een vergelijking gemaakt tussen MOF en IT Service CMM, zie 0. Aan de hand van de vergelijking zijn vragen uit de IT Service CMM Questionnaire toegevoegd aan de lijst. Om ook level drie te dekken van IT Service CMM zijn vragen toegevoegd gebaseerd op de methodiek. Het complete interview is opgenomen in Bijlage 1 -. Het uitvoeren van de interviews heeft in twee stappen plaatsgevonden. Eén van de geïnterviewden is als testpersoon gebruikt om te kijken of het interview helder, begrijpend en gestructureerd was. Naar aanleiding van gekregen feedback is het interview op een aantal punten aangepast om de kwaliteit van het interview te verhogen. De overige zes medewerkers zijn in week 40 geïnterviewd met één uitzondering in week 41.

5.3 Team / rol inrichting Huidige inrichting Uit het interview blijkt dat er twee verschillende opvattingen bestaan wat betreft de rol en taakverdeling binnen The Backbone. De eerste opvatting is een opdeling per klant. The Backbone beheert op het moment rond de 25 klanten. Elke klant is toegewezen aan een medewerker die als primair contactpersoon fungeert en het dagelijkse beheer uitvoert. In het geval de primaire contactpersoon niet aanwezig is neemt een andere medewerker zijn taken waar. De tweede opvatting is gebaseerd op rol binnen de organisatie. Twee daadwerkelijk benoemde rollen, commercieel directeur en technisch directeur, en één minder zichtbare rol, consultant, zijn te onderscheiden. De twee directie rollen zijn als zodanig benoemd en hebben onderling een takenverdeling. De consultant rol is er door de tijd heen ingeslopen doordat een tweetal medewerkers vergeleken met de overige medewerkers meer buiten de deur opereren. De medewerkers die buiten de consultant rol vallen zorgen voornamelijk voor de interne bezetting. MOF Het MOF Team Model is een best practices waarin onder andere beschreven wordt hoe een operationeel team het beste ingezet kan worden door verschillende subgroepen en rollen te definiëren. In de best practices worden zeven subgroepen beschreven met elk hun elke hun eigen werkzaamheden, verantwoordelijkheden en competenties. Het lijkt erop dat bij het maken van de groepen gekeken is welke rollen in een organisatie dezelfde doelen na streven en deze te groeperen. Bijvoorbeeld de rollen network administration, database operations en availability management vallen onder de groep Operations en hebben allemaal het doel de infrastructuur draaiende te houden middels het dagelijkse beheer. Figuur 9 geeft het Team Model weer.


24

Figuur 9 - Team Model De omvang van een organisatie is van grote invloed op de implementatie van het Team Model. Binnen een grote organisatie is het denkbaar dat elk van de zeven groepen meerdere subgroepen heeft met elke hun eigen werkzaamheden. Bij een kleine organisatie is het echter waarschijnlijker dat verschillende rollen gedeeld worden door één persoon en hiermee groepen samen genomen worden. Bij het samen nemen van de groepen moet gelet worden op tegenstrijdige belangen van verschillende rollen. Om hierbij te helpen en situatie met tegenstrijdige belangen te voorkomen bevat het Team Model een matrix waarin staat welke groepen samen genomen kunnen worden. IT Service CMM Binnen IT Service CMM worden zes rollen gebruikt in de beschrijving van de processen. De zes rollen worden inhoudelijk kort toegelicht waarbij tevens wordt gezegd dat de rollen worden gegeven omdat ze nodig zijn in de beschrijving. Er kan dus gesteld worden dat IT Service CMM buiten het benoemen van enkele rollen niks beschrijft over het inrichten van teams. Overzicht Aspect Werknemers hebben een rol met bijhorende werkzaamheden en verantwoordelijkheden.

Bron

Status

MOF

5.4 Procesinrichting Van een daadwerkelijke procesinrichting binnen The Backbone kan niet worden gesproken. Op dit moment worden alle acties ad-hoc uitgevoerd volgens een impliciet proces wat bestaat uit signaleren, analyseren en oplossen. De invulling van de stappen is afhankelijk van het te bereiken einddoel. Bijvoorbeeld in het geval van de service desk zal het zo zijn dat signaleren bestaat uit het ontvangen van een mail of telefoontje en dat deze melding wordt opgenomen in het helpdeskpakket. Analyseren wordt ingevuld door te kijken waar het probleem precies ligt en wat de oplossing is. Het oplossen wordt ingevuld door het incident te verhelpen en dit terug te koppelen naar de klant. In het recente verleden is aandacht besteed aan een procesinrichting in de vorm van een procesvoorstel voor onder andere Change Management. De geschreven voorstellen zijn echter nooit van de grond gekomen. Onderstaande drie oorzaken zijn tijdens de interviews genoemd: De bekendheid met processen: van de vijf operationele medewerkers bij The Backbone heeft slechts een enkeling ervaring met procesmatig werken, veelal opgedaan bij eerdere werkgevers. De omvang van de organisatie: in de huidige situatie bestaat The Backbone uit vijf operationele medewerkers die samen één kantoor delen. Processen zouden in deze situatie alleen maar extra werk opleveren. Tijd: de zeven mensen die momenteel werkzaam zijn bij The Backbone zijn druk met de dagelijkse werkzaamheden zoals beheer, planning, monitoring, consultancy,


25

commerciële activiteiten en management activiteiten. Daarnaast een procesinrichting opzetten is moeilijk. 5.4.1 Change Management & Release Management Situatie binnen The Backbone Bij The Backbone is de richtlijn dat alle werkzaamheden die niet in het contract zijn benoemd gezien worden als changes, werkzaamheden die wel in het contract zijn benoemd worden aangemerkt als service requests. Voorbeelden van changes zijn de installatie van een nieuwe server of het aanpassen van configuraties. Voor het melden van changes zijn verschillende methoden beschikbaar namelijk, telefonisch, per mail of via een Request for Change (RFC). Uit de praktijk blijkt dat de de telefoon en mail het meest worden gebruikt, de RFC amper. De oorzaak hiervan ligt voornamelijk bij de klant doordat deze RFC‘s niet graag gebruiken door de papieren rompslomp die ze verwachten. Wanneer een change request voor The Backbone duidelijk is zou deze opgeslagen moeten worden, hiervoor is een helpdeskpakket aanwezig. Het pakket heeft hiervoor de benodigde functionaliteiten echter in de praktijk wordt er geen consequent gebruik van gemaakt. Terugkoppeling van een informatie over een change, dan wel ad-hoc of periodiek, vindt mondeling of per mail plaats en is per klant verschillend wat ook geldt voor de precieze informatie die wordt teruggekoppeld. Een voorbeeld van een terugkoppeling is een excelsheet waarin changes worden bijgehouden. Na elke change wordt de excelsheet naar de opdrachtgever gemaild. Onafhankelijk van de wijze en de inhoud van de terugkoppeling is het gewicht en de impact van de change de bepalende factor of een terugkoppeling al dan niet plaatsvindt. Voor intern gebruik worden alle changes per systeem bijgehouden in een tekstbestand wat op de desktop van het betreffende systeem is geplaatst. Release Management is bij The Backbone geïntegreerd met Change Management en samen worden ze gezien als één. Voor het daadwerkelijk uitrollen van de changes is met een aantal klanten een onderhoudswindow afgesproken. Het voordeel van ee onderhoudswindow is dat er niet voor elke release afstemming dient plaats te vinden en daarnaast worden changes automatisch gebundeld. Is er geen onderhoudswindow afgesproken dan wordt de klant op de hoogte gebracht voordat een change wordt doorgevoerd. Het testen van changes is afhankelijk van de grootte en impact van de change en de aanwezige mogelijkheden. Voor The Backbone is het niet werkbaar en haalbaar om van elke externe omgeving een testomgeving bij te houden. Dit maakt het in veel gevallen onmogelijk om een test uit te voeren. Indien geen testomgeving beschikbaar is wordt per change besloten of het nodig is een testomgeving te simuleren, bijvoorbeeld met virtuele systemen. De keuze of dit wel of niet gebeurt is van de medewerker afhankelijk, er is geen vaste richtlijn waar de keuze op wordt gebaseerd. Beschikt de klant over een testomgeving dan worden wijzigingen hierop eerst uitgerold voordat de uitrol plaatsvindt in de productieomgeving, dit is vaak een vereiste van de klant. MOF Change Management beschreven door MOF heeft als doel veranderingen in de IT omgeving gecontroleerd te laten verlopen. Veranderingen zijn in dit geval toevoegingen, aanpassingen of verwijderingen van componenten. Onder componenten worden onder andere hardware, software, services, documenten en processen verstaan. Het Change Management proces beschreven in de SMF bestaat uit zes stappen. Per stap wordt het proces met een flow-diagram weergegeven en vervolgens wordt deze in detail toegelicht. De volgende stappen komen achtereenvolgens aanbod in het proces: Change Request, controleren en vastleggen van de change Change Classification, categoriseren en prioritiseren van de change Change Authorization, in het geval de categorie / prioriteit dit eist wordt de change eerst geauthoriseerd Change Development, ontwikkelen van de change Release Management, implementeren van de change Change Review, terugkoppelen en documenteren van de change


26

Eén van de stappen in het Change Management proces is Release Management. In het proces wordt dit als een stap weergegeven, binnen MOF is dit echter een aparte SMF. Release Management heeft als doel ontwikkelde changes te testen, voorbereiden en te introduceren / implementeren. Tijdens het Release Management proces worden de volgende stappen uitgevoerd: Release Planning, Release Building, Acceptance Testing, Release Preparation en Release Deployment. Gedurende de vijf stappen wordt voor de gevonden oplossing bij Change Management een plan ontwikkeld voor de release, packages en scripts geschreven, de release en alle bijbehorende zaken voor zover mogelijk getest en na goedkeuring door alle betrokken personen wordt de release daadwerkelijk uitgevoerd. IT Service CMM Change Management en Release Management is binnen IT Service CMM verdeeld en ondergebracht in de key area‘s Configuration Management en Service Request and Incident Management en Service Delivery. Het uitvoeren van changes gebeurt binnen Service Request and Incident Management volgens de stappen indentified, recorded, analyzed, reviewed en resolved. De inhoud van de stappen wordt in de key area niet besproken. Configuration Management breidt dit proces op een aantal plekken uit door extra voorwaarden te eisen zoals de authorisatie van changes, het testen van changes, het groeperen van releases en het op de hoogte houden van betrokken personen. Service Delivery uit IT Service CMM level drie zorgt voor meer volwassenheid in het bovenstaande proces. De key area gaat voornamelijk in op releases en minder op changes en incidenten en eist dat elke release uitgevoerd wordt volgens een vooropgesteld en goedgekeurd plan. Het release plan beschrijft onder andere het type release, planning, rollout plan, back-out plan, trainingen etc. Overzicht Aspect RFC‘s worden gebruikt voor het indienen van changes Changes worden gecategoriseerd Changes worden geprioritiseerd Changes worden gescreend op volledigheid en eerder voorkomen Changes worden geauthoriseerd door een Change Manager / Cab / EC Er wordt per change een log bijgehouden waarin alle genomen beslissingen en uitgevoerde activiteiten worden bijgehouden Na het uitvoeren van de changes wordt een review gehouden om te kijken of de change het vooraf gestelde doel gehaald heeft Elke release wordt geprioritiseerd en uitgevoerd volgens een geschreven plan Release Management automatiseert zoveel mogelijk stappen met behulp van applicaties Elke release wordt getest in een testomgeving voordat de daadwerkelijke release plaatsvindt. Voor elke release is een back-out plan aanwezig in het geval een release teruggedraaid moet worden. Voor de daadwerkelijke release vindt een release review plaats met betrokken personen en wordt de ‗go/no-go‘ decision genomen Gebruikers worden op de hoogte gehouden en gebracht van de release Standaard rapportages zijn beschikbaar voor rapportage van activiteiten binnen het proces Het gehele proces van changes en releases is gedocumenteerd


Bron

Status

MOF – CM / ITSCMM MOF – CM MOF – CM / ITSCMM MOF – CM MOF – CM / ITSCMM MOF – CM MOF – CM MOF – RM / ITSCMM MOF – RM MOF – RM / ITSCMM MOF – RM / ITSCMM MOF – RM / ITSCMM MOF – RM / ITSCMM ITSCMM ITSCMM

27

5.4.2 Configuration Management Situatie binnen The Backbone Over het gebruik van Configuration Management binnen The Backbone verschillen de antwoorden tussen de geïnterviewde medewerkers wat ook terug te zien is in de meer gedetailleerde vragen. Het verschil in antwoorden is waarschijnlijk te verklaren door de achtergrond en de verschillende ideeën die de geïnterviewde hebben over Configuation Management. Centraal binnen Configuration Management staat de Configuration Management Database (CMDB). De CMDB wordt gebruikt om configuration items en relaties naar andere items op te slaan. Onderstaande oplossingen zijn genoemd als CMDB bij The Backbone: Een aantal medewerkers ziet MOM als de CMDB of als gedeelde CMDB. MOM houdt van elke gemonitord systeem een aantal gegevens bij waaronder IP-adres, rollen en het operating system. MOM is in staat deze eigenschappen real-time aan te passen. In dit geval kan er dus gesproken worden van een CMDB die wijzigingen automatisch aanpast. Een tweede oplossing die gezien wordt als CMDB zijn Word en Visio documenten. Een enkele keer wordt dit ook genoemd als aanvulling op MOM. De Word en Visio documenten bevatten onder andere een beschrijving van het netwerk, server rollen, server installaties en ip nummer plan. Het bijwerken van deze documenten moet met de hand gebeuren. De medewerkers binnen The Backbone gebruiken de CMDB voor verschillende doeleinden. Enkele genoemde antwoorden zijn bij problemen, voor migraties, opstellen van offertes, de service desk, vooraf aan een bezoek en simpelweg niet. MOF Configuration Management speelt binnen MOF een belangrijke rol door de afhankelijkheid die andere SMF‘s hebben richting Configuration Management. Onder andere Change Management en Release Management gebruiken Configuration Management voor het ontwikkelen van releases en Incident Management en Problem Management gebruiken Configuration Management voor het onderzoeken van incidenten en probemen. Om er voor te zorgen dat de CMDB te allen tijde de juiste informatie bevat is Configuration Management een continu proces wat uit een paar stappen bestaat. Vooraf aan de stappen uit het proces vindt een eenmalige stap plaats waarin de setup en implementatie van de CMDB plaatsvindt samen met het bepalen van de precieze informatie en de hoeveelheid details die opgeslagen zullen worden. Het proces bestaat uit de onderstaande stappen. Per stap is kort toegelicht waarvoor de stap dient. Establish CI: Afhankelijk van de gemaakte keuzes wat betreft de informatie en de hoeveelheid details worden nog niet opgenomen IT componenten in de CMDB gezet met alle bijbehorende attributen en relaties. Access CI: Het opvragen van informatie in de CMDB Change CI: Configuration items worden gedurende de looptijd aangepast. Deze stap houdt aankomende en uitgevoerde changes in de gaten en zorgt ervoor dat dit wordt verwerkt in de CMDB. Review CI: Door het uitvoeren van review op gekozen intervals wordt de correctheid van de informatie in de CMDB gewaarborgd. Een review bestaat uit een scan van de componenten in de CMDB en de resultaten van de scan te vergelijken met de huidige informatie in de CMDB. IT Service CMM Binnen IT Service CMM wordt Configuration Management ingevuld door een gelijknamige key area. IT Service CMM eist in de key area een verscheidenheid aan aspecten waaronder het opzetten van een CMDB, keuzes maken wat betreft de informatie en de hoeveelheid detail in de CMDB, het identificeren en toevoegen van nieuwe items, het volgen van changes en releases en het uitvoeren van audits. Vergeleken met MOF benoemd IT Service CMM precies de stappen die door MOF zijn beschreven. Eén verschil is wel dat binnen IT Service CMM het


28

volgen van changes veel uitgebreider gebeurt en Configuration Management hier ook meer over te zeggen heeft zoals beschreven bij Change & Release Management Overzicht Aspect Er is een keuze gemaakt welke informatie en de hoeveelheid details worden opgenomen in de CMDB Er is een afbakening gemaakt van de IT omgeving die aangeeft welke componenten wel en welke componenten niet door Configuration Management beheerd worden Er is een CMDB aanwezig voor het opslaan van configuration items Alle geïdentificeerde componenten zijn opgenomen in de CMDB De CMDB kan geraadpleegd worden door belanghebbende Changes en releases worden gevolgd en verwerkt in de CMDB Periodiek wordt er een review uitgevoerd om de informatie in de CMDB te waarborgen Configuration Management activiteiten worden gerapporteerd Procedures binnen Configuration Management zijn gedocumenteerd

Bron

Status

MOF / ITSCMM MOF / ITSCMM

MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM ITSCMM ITSCMM

5.4.3 System Administration Situatie binnen The Backbone De manier van dagelijks beheer heeft te maken met de opzet van de IT omgeving. In het geval van The Backbone is deze te kenmerken als een gedistribueerde omgeving. De eigen systemen staan op een secure co-location. Enkele klanten maken gebruik van de locatie waar The Backbone zijn systemen heeft staan en de rest van de klanten hebben een eigen, wellicht meerdere, locaties voor de systemen. Dit heeft als resultaat dat de omgeving verdeeld is over verschillende locaties. Het beheer is opgedeeld in technisch en functioneel beheer. Afhankelijk van de klant neemt The Backbone geen, één van beide of allebei voor zijn rekening. Beheer uitgevoerd door The Backbone gebeurt vanaf één centrale locatie. Met behulp van remote beheer applicaties worden de systemen beheerd. In het geval de hardware fysiek nodig is voert The Backbone de werkzaamheden op locatie uit. Beheer wat niet door The Backbone uitgevoerd wordt is gedelegeerd naar systeembeheerders bij de klant in dienst. Door de combinaties die mogelijk zijn is het beheer aan te merken als gecentraliseerd remote beheer en gedelegeerd beheer. MOF System Administration houdt zich bezig met het dagelijkse beheer en de ondersteuning van de productieomgeving, bijvoorbeeld het aanmaken van user en network accounts. System Administration kan gezien worden als de overkoepelende SMF binnen het Operating Quadranten zorgt voor het dagelijkse beheer en operationele ondersteuning. Specialistische werkzaamheden zijn doorgeschoven naar andere SMF‘s, bijvoorbeeld basis monitoring kan door System Administration worden uitgevoerd. 24x7 monitoring vereist veel meer resources en aandacht en wordt daarom verzorgd door Service Monitoring and Control. In de SMF wordt alleen gesproken over de verschillende waarop een IT beheeromgeving opgezet kan worden. Onderstaande vijf scenario‘s worden besproken met de voor en nadelen. Centralized Administration of Centralized Hardware Centralized / Remote Administration of Distributed Hardware Centralized / Delegated Administration of Distributed Hardware Distributed Administration of Distributed Hardware Distributed Administration of Centralized Data Centers IT Service CMM IT Service CMM heeft geen key area‘s die qua doel overeenkomen met het doel van System Administration. In dit geval is hier dus niets over te zeggen.


29

Overzicht MOF geeft alleen een beschrijving van vijf mogelijke opzetten qua beheer, IT Service CMM doet niets op het gebied van System Administration. Doordat beide methodieken niets zeggen over een proces en geen eisen stellen is er geen overzicht te maken. 5.4.4 Security Administration & Management Situatie binnen The Backbone Security is één van de redenen dat de eigen servers op de huidige locatie staan. Dit geeft ook direct aan dat security aspecten niet onbekend zijn. In gesprekken komt security naar voren in het geval er noodzaak toe is, bijvoorbeeld bij de bouw van een nieuw pand of het uitvoeren van changes. Documentatie over bekende en aanwezige risico‘s en daarop genomen maatregelen om incidenten te voorkomen is niet aanwezig. Qua security implementaties zijn de onderstaande maatregelen genomen: Identification: Voor de identificatie op de eigen systemen en die van klanten is een username vereist. Het aanmaken van de users voor de eigen systemen gebeurt volgens een vaste standaard, in het geval van klantomgevingen is dit niet het geval en is The Backbone meestal afhankelijk van de door de klant gebruikte standaard. Authentication: Authenticatie gebeurd in beide gevallen, intern en bij de klant, doormiddel van een wachtwoord. Uitzondering hierop is één klant waar een smartcard vereist is om toegang te krijgen tot de systemen. Access Control: In principe is iedereen, uitgesloten het management, administrator binnen The Backbone en wordt er vanuit gegaan dat hier vertrouwelijk en verantwoordelijk mee wordt omgegaan. Standaard policies worden daarnaast gebruikt om zaken als een lockout in te stellen. Hierbij moet opgemerkt worden dat door de administrator rechten iedereen in staat is deze instellingen te wijzigen. Confidentiality: Om de vertrouwelijkheid te waarborgen wordt er gebruik gemaakt van twee technieken. Om op afstand toegang te krijgen in het eigen netwerk of die van een klant wordt VPN gebruikt, SSL certificaten worden gebruikt voor de encryptie van webmail. Integrity: Met behulp van virusscans die continu draaien en binnen MOM opgenomen zijn wordt de integriteit van de data verzekerd. Auditing: MOM verzorgt auditing voor de systemen van The Backbone, op wens van de klant worden de systemen juist geconfigureerd waarna auditing mogelijk is. Per klant en per systeem is te configureren wat wel en niet vastgelegd moet worden. Fysieke security: The Backbone maakt voor het hosten van de servers gebruik van een secure co-location. Toegang tot het pand en de servers wordt geregeld met smartcards. In het geval van klanten is er geen eenduidige lijn te trekken. Enkele klanten maken gebruik van het rack waarin The Backbone zijn eigen servers heeft hangen, andere klanten zorgen zelf voor een beveiligde locatie en bij sommige is het mogelijk het pand binnen te lopen regelrecht naar de serverruimte. MOF De manier waarop men over security denkt verschilt per laag in de organisatie wat terug te zien is in MOF. Security Management benadert security op een abstracte manier en gaat inhoudelijk in op onder andere policies en risico management, het zogenaamde ―wat‖ aspect van security. Security Administartion daarentegen gaat in op de mogelijke technieken die gebruikt kunnen worden voor security zoals encryptie en authenticatie. In het geval van Security Administration wordt ook wel gesproken over het ―hoe‖ aspect van security. Het Security Management proces bestaat uit de onderstaande vier stappen in een cyclisch proces. Organizational security policies: Een visie wordt uiteengezet wat betreft de security binnen de organisatie samen met de requirements, verschillende security levels, verantwoordelijkheden, omgang en gebruik van data en maatregelen die genomen moeten worden op verschillende gebieden, bijvoorbeeld netwerk, software, hardware, servers etc. Dit alles kan beschreven zijn in meer dan één policy, een hiërarchie in policies is bijvoorbeeld mogelijk.


30

Security risk management process: Binnen het security management proces is dit een subproces wat periodiek uitgevoerd wordt. Mogelijke risico‘s worden geïdentificeerd en oplossingen en maatregelen worden gezocht om de risico‘s te minimaliseren. Security monitoring and auditing: Monitoren van de omgeving op mogelijke bedreigingen voor de security en daarnaast worden periodiek audits uitgevoerd om te kijken of voldaan wordt aan de voorgeschreven policies. Incident response process: Deze stap beschrijft het proces wat uitgevoerd dient te worden in het geval er zich een security incident voordoet binnen de organisatie. Binnen de Security Administration SMF staan zes aandachtspunten centraal die samen zorgdragen voor de security. De SMF legt per punt uit welke technieken gebruikt kunnen worden voor de implementatie. Hieronder worden de zes punten opgesomd. Identification: Hoe wordt aan de server bekend gemaakt wie de gebruiker is, bijvoorbeeld een username of een smartcard kan gebruikt worden. Authentication: Hoe bewijst een gebruiker dat hij daadwerkelijk de gebruiker is. Mogelijke opties zijn een wachtwoord en een pincode. Access control: Gaat in op rechten, shares, limited session use, etc Confidentiality: Om te voorkomen dat niet geauthoriseerde personen data kunnen zien wordt encryptie gebruikt. Verschillende vormen van encryptie worden beschreven bijvoorbeeld private / public en VPN. Integrity: Integriteit draagt zorg voor de correctheid van data tijdens transmissie en de controlle of data is verzonden door de persoon die zegt dat hij het heeft verzonden. Checksums, virus scans en digitale handtekeningen kunnen hier onder andere bij helpen. Nonrepudiation: Zorgt ervoor dat op latere tijdstippen bewezen kan worden dat data verzonden is. IT Service CMM Security Management en Security Administration hebben beide geen overeenkomende key area‘s binnen IT Service CMM. Overzicht Aspect Policies zijn aanwezig binnen de organisatie waarin verschillende security aspecten zijn vastgelegd Een risico management proces is aanwezig om security risico‘s te minimaliseren Systemen worden gemonitord om eventuele incidenten te identificeren Audits worden uitgevoerd om zorg te dragen voor de implementatie van de aanwezige policies Een security incident proces is aanwezig in geval een incident zich voordoet. Identification technieken zijn geïmplementeerd Authentication technieken zijn geïmplementeerd Access control technieken zijn geïmplementeerd Confidentiality technieken zijn geïmplementeerd Integrity technieken zijn geïmplementeerd Nonrepudiation technieken zijn geïmplementeerd

Bron

Status

MOF MOF MOF MOF MOF MOF MOF MOF MOF MOF MOF

5.4.5 Service Monitoring and Control Situatie binnen The Backbone Voor het monitoren van systemen maakt The Backbone gebruik van Microsoft Operation Manager 2005 (MOM). MOM levert onder andere real-time statussen van systemen, health modellen en informatie over componenten die gemonitord worden. In MOM worden worden management packs gebruikt om mogelijkheden toe te voegen en meer informatie te tonen. Voorbeelden van management packs zijn SQL Server, Active Directory en McAffee.


31

Meldingen die binnenkomen bij MOM worden afhankelijk van de impact overgenomen in het helpdesk pakket, de incident logging tool. Doordat een automatische koppeling tussen beide pakketen mist is het onwerkbaar om alle meldingen die bij MOM binnenkomen over te nemen. Voor het toekennen van statussen en verdelen van meldingen over de medewerkers worden het helpdeskpakket en MOM gebruikt omdat meldingen verdeeld zijn over de systemen. Voor het verhelpen van binnenkomende incidenten zijn verschillende informatie bronnen beschikbaar, de eigen kennis en die van medewerkers, een product en company knowledge base binnen MOM en een knowledge base binnen het helpdeskpakket. Een laatste aspect van Service Monitoring and Control wat binnen The Backbone is vormgegeven is het meten van de performance. Met behulp van performance counters wordt verschillende data opgeslagen, bijvoorbeeld time to resolve over meldingen en de availability van de systemen. De data wordt momenteel alleen gebruikt voor het uitdraaien van rapporten. MOF Monitoring helpt in het proactief beheren van IT omgevingen aangezien het je in staat stelt real-time te zien wat er in de complete omgeving gebeurd. Daarnaast is het mogelijk rapportages te maken en trent analyses uit te voeren door de monitoring data op te slaan. Dit alles komt ten goede aan de stabiliteit en up-time van de IT omgeving. Binnen de Service Monitoring and Control SMF wordt een continu proces beschreven wat vooraf is gegaan door een initiële stap. De initiële stap zorgt ervoor dat alle voorwaarden voor het proces zijn voldaan en requirements zijn opgesteld. Het continue proces heeft natuurlijk als doel de IT omgeving te monitoren. Daarnaast is het proces zo vormgegeven dat door het uitvoeren van de verschillende stappen continu geoptimaliseerd wordt waardoor de efficiency en effectiviteit toenemen. Hieronder worden de stappen uit het proces genoemd met een korte toelichting. Establish: Dit is de initiële stap waarin data wordt verzameld, health modellen worden opgesteld voor componenten, de monitoring tool wordt gekozen en geïmplementeerd en de processen worden vormgegeven. Assess: Assess heeft te maken met het analyseren van de huidige monitor omgeving, dat wil zeggen analyse van binnengekomen requests, data (SLA‘s, Service Catalog, Capacity plans, etc), agent condities, component condities en monitoring rules. Feedback van klant is naast de analyse van data een belangrijke factor. Implement: De assess stap in het proces levert acties en verbeteringen op voor de monitor omgeving. In de implement stap worden de acties uitgevoerd dit kan zijn dat er bijvoorbeeld nieuwe componenten worden gemonitord of rules worden aangepast. Monitor: Dit is de daadwerkelijke stap waarin de monitoring plaatsvindt. Afhankelijk van de gekozen tools die het proces ondersteunen wordt de IT omgeving real-time gemonitord. Control: De laatste stap in het proces is Control. Meldingen die binnenkomen worden afgehandeld. Afhankelijk van de meldingen en de opzet van de IT omgeving kan het zijn dat scripts worden gestart die problemen verhelpen of dat er incidenten worden gemeld bij het Incident Management proces. IT Service CMM Binnen IT Service CMM bestaat er geen key area die zich alleen met Service Monitoring and Control bezighoudt zoals dit binnen MOF bestaat. Monitoring wordt binnen IT Service CMM wel genoemd maar het gewicht dat wordt toegekend is minder vergeleken met MOF. Key area‘s die iets over monitoring schrijven zijn Service Delivery en Resource Management uit level drie. Service Delivery houdt zich bezig met het uitvoeren van custom made processen afgeleid van de standaard processen. Monitoring is hier een onderdeel van. Voor de invulling van monitoring wordt verwezen naar Resource Management.


32

Resource Management houdt zich bezig met het beschikbaar stellen van resources voor het leveren van diensten. Monitoring kan hierbij van waarde zijn bijvoorbeeld door het zetten van thresholds op harde schijven. Dit maakt het mogelijk om de schijven op tijd uit te breiden in het geval ze vollopen. Resources Management noemt monitoring en het reageren op binnenkomende informatie als één van de verplichte onderdelen voor Resource Management. Overzicht Aspect Voor gemonitorde componenten zijn health modellen opgezet Een applicatie is aanwezig voor het daadwerkelijke monitoren van de omgeving Optimalisatie van monitoring vindt plaats door analyse van historie en de implementatie van verbeterpunten Op binnenkomende meldingen wordt geacteerd, dan wel automatisch of doorverwezen naar incident management Key performance indicators zijn opgesteld om service monitoring and control te evalueren

Bron

Status

MOF / ITSCMM MOF MOF / ITSCMM MOF / ITSCMM MOF

5.4.6 Directory Services Management Situatie binnen The Backbone Producten opgenomen in een netwerk zijn onder andere voor identificatie, authenticatie en centraal opslaan van objecten en attributen afhankelijk van directories. Een voorbeeld van een directory die deze functionaliteiten bied is Active Directory. Tijdens het beheren en monitoren van IT omgevingen krijgt The Backbone veelvuldig te maken met directories. Voor het beheren van directories, intern en extern, heeft de The Backbone de volgende zaken geregeld: Voor een aantal klanten is er documentatie aanwezig van Active Directory. De documentatie beschrijft de installatie van de directory, de indeling van de directory en in een enkel geval de indeling van group policies. De documentatie is opgeslagen in de map voor de klant op het netwerk en is voor iedereen toegankelijk. Microsoft heeft een management pack uitgebracht waarmee Active Directory gemonitord kan worden binnen MOM. Voor de interne systemen maakt The Backbone gebruik van dit management pack, voor enkele klanten is dit tevens ingesteld. Iedere dag worden de directories gebackupped, intern en bij de klant. Hiervoor zijn, op enkele klanten na, geen plannen geschreven. In veel gevallen is het zo dat de back-up van de directories geen losstaande back-up is maar in een algemene backup van het systeem wordt meegenomen. MOF Dat directories binnen IT omgevingen een steeds grotere rol spelen is iets wat MOF onderstreept. Wat begonnen is als een opslaglocatie voor namen en locaties van systemen is uitgebreid naar een centrale opslaglocatie in een netwerk van objecten en attributen. Objecten en attributen kunnen veelzijdig zijn, bijvoorbeeld users, systemen, shares, policies, etc. Applicaties en besturingssystemen gebruiken de directories behalve als gedeelde opslaglocatie onder andere voor authenticatie en authorisatie. Directory Services Administration valt onder de Operating Quadrant wat gaat over het dagelijkse beheer. Beheer begint met de kennis over de omgeving en dit is precies waar de Directory Services Administration SMF de meeste aandacht aan schenkt. In de SMF wordt ingegaan op de verschillende soorten bestaande directories, doelen en mogelijkheden, metadirectories, communicatie tussen directories onderling en de documentatie. Naast de voorgenoemde onderwerpen gaat de SMF in op het dagelijkse beheer, onderhoud en troubleshooting van directories. IT Service CMM


33

Directory Service Administration heeft geen overeenkomende key area‘s binnen IT Service CMM. Overzicht Aspect Voor elke directorie is documentatie aanwezig en beschikbaar Cruciale resources voor de directories worden gemonitord Periodiek wordt van elke directorie een back-up gemaakt Er is een data protection plan aanwezig waarin onder andere het maken van een back-up, het restoren van een back-up, kritische data en potentiële gevaren zijn besproken

Bron

Status

MOF MOF MOF MOF

5.4.7 Network Administration Situatie binnen The Backbone Voor het beheren en monitoren van de netwerken vertrouwd The Backbone op MOM. Alle actieve netwerkcomponenten waarop een agent is geïnstalleerd worden gemonitord. Intern komt dit neer op alle servers en één switch, bij de klant op alle servers die in het contract zijn genoemd. De veiligheid van het netwerk wordt beoordeeld met behulp van de Microsoft Baseline Security Analyzer Management Pack. De Baseline Security Analyzer controleert onder andere of bepaalde configuraties zijn uitgevoerd en alle updates zijn geïnstalleerd. Documentatie van het netwerk is, net als bij de documentatie van de directories, per klant geregeld. Voor een groot aantal klanten zijn Visio tekeningen aanwezig met daarin een overzicht van het netwerk met de servers, firewalls, switches e.d. Het netwerkoverzicht wordt in een tweede document toegelicht. In de toelichting worden onder andere de eigenschappen en rollen van de servers vastgelegd. MOF Dagelijkse werkzaamheden van een netwerkbeheerder zijn het aanpassen (changing) en onderhouden (maintaining) van het netwerk en het verhelpen van problemen (support). De Network Administration SMF gaat voornamelijk in op het verhelpen van problemen en onderhouden van het netwerk. Het design en de architectuur vallen buiten de scope en wordt als bekend verondersteld. Support van het netwerk heeft alles te maken met het zo snel mogelijk verhelpen van problemen. Om dit efficiënt uit te voeren schrijft MOF het volgende stappenplan voor: Establish the symptoms, Identify the affected area, Establish what has changed, Select the most probable cause, Implement a solution, Test the results, Recognize the potential effects of the solution en Document the solution. In de SMF wordt per stap beschreven hoe dit gedaan kan worden. IT Service CMM Network Administration heeft geen overeenkomende key area‘s binnen IT Service CMM. Overzicht Aspect Netwerkcomponenten worden gemonitord Netwerkincidenten worden verholpen volgens een vast proces

Bron

Status

MOF MOF

5.4.8 Storage Management Situatie binnen The Backbone Uit de interviews blijkt dat The Backbone over drie soorten data beschikt, MOM data, bedrijfs data en user data. De bedrijfs en user data is fysiek gescheiden van de MOM data door gebruik te maken van aparte schijven. Onderling zijn de bedrijfs data en user data is op een logische manier gescheiden. User data kan opgeslagen worden in de home directory van de user en de bedrijfs data op de gezamenlijke netwerkschijf.


34

Het backuppen van data gebeurt dagelijks. Uitzondering hierop is de MOM data wat een 300 GB database is. Voor het dagelijks backuppen van de database is niet genoeg storage ruimte aanwezig, daarom wordt slechts een deel gebackupped. Na afloop van de back-up wordt een mail verstuurd met informatie over het goed dan wel slecht lopen van de back-up. Elke ochtend worden de binnengekomen mails gecontroleerd en zonodig opgetreden. Over de documentatie en de aanwezigheid van back-up plannen verschillen de meningen, drie medewerkers zeggen van wel, drie medewerkers zeggen van niet en de laatste medewerker heeft geen antwoord gegeven. Op de gezamelijke netwerkschijf, de locatie voor documentatie, is inderdaad voor enkele klanten documentatie te vinden echter niet voor alle klanten. MOF Storage Management valt onder het Operating Quadrant en zorgt voor het dagelijkse beheer van data resources. Het beheer van data kan in twee stukken worden gesplitst, management van data resources en het veiligstellen van data. Beide zijn losse activiteiten echter hebben ze wel met elkaar te maken door de afhankelijkheid van elkaar. Onder het managen van data resources wordt verstaan het beschikbaar stellen van opslag capaciteit aan de organisatie. Resources worden aangeschaft, geconfigureerd, onderhouden en gemonitord. De eerste drie activiteiten zorgen voor de beschikbaarheid van de resources, monitoring zorgt ervoor dat incidenten snel opgemerkt worden, performance bekeken kan worden en trend analyses gemaakt kunnen worden om de toekomst te voorspelen. Het veiligstellen van data houdt zich bezig met het backuppen en eventueel restoren van data. Centraal in de back-up procedure staat de back-up policy. Onderstaande punten kunnen beschouwd worden als aandachtspunten die beantwoord moeten worden in de policy. Classificatie van data (user data, business data, application data, etc) Back-up requirements (back-up frecuency, offsite back-up, archivering, etc) Afhankelijkheden (security policies, netwerk performance, SLA‘s, data resources, etc) Back-up methoden (full back-up, partial back-up, incremental back-up) IT Service CMM De key area Resource Management komt deels overeen met de Storage Management SMF en richt zich op het bewaken van de beschikbare resources voor de organisatie. Resources zijn in dit geval niet enkel data resources zoals bij Storage Management maar bijvoorbeeld ook netwerk bandbreedte en computer capaciteit. Door de hogere abstractie in de key area worden alleen aandachtspunten genoemd waaronder het identificeren en monitoren van resources en de aanwezigheid van een resources management plan. Overzicht Aspect Data is geclassificeerd Periodiek worden backups gemaakt van data Een back-up strategie is ontwikkeld en gedocumenteerd waarin back-up en restore procedures staan beschreven Data resources worden gemonitord Trend analyses worden uitgevoerd voor performance en capacity van data resources Storage Management activiteiten worden gerapporteerd

Bron

Status

MOF MOF MOF MOF / ITSCMM MOF ITSCMM

5.4.9 Job Scheduling Situatie binnen The Backbone Voor het uitvoeren van intensieve taken en periodieke taken zoals het maken van backups, defragmentatie, virus scans en het indexeren van databases maakt The Backbone gebruik van batch jobs. Volgens één geïnterviewde is het beheren van de batch jobs verdeeld. Eén medewerker zou zich richten op de batch jobs binnen MOM, de overige medewerkers op de batch jobs die draaien bij de klanten. Volgens de andere zes geïnterviewden is er geen verdeling aanwezig.


35

Documentatie over de batch jobs met eigenschappen als de locatie waar ze draaien, het tijdstip dat ze draaien, gebruikte accounts, stappen die worden genomen etc, is bij de medewerkers bekend echter is niets vastgelegd. Eén klant is hierop een uitzondering, voor zijn omgeving is een gedocumenteerde schedule aanwezig met de tijden en de servers waarop jobs draaien. Optimalisatie van batch jobs binnen de omgeving van de klanten is niet van belang door het geringe gebruik. Wel wordt er op gelet dat batch jobs elkaar niet tegenwerken en het werk onmogelijk maken. Binnen MOM is optimalisatie wel van belang. Om de huidige set van batch jobs te draaien is meer dan een dag nodig. Om alle batch jobs goed te laten verlopen in zo kort mogelijke tijd en zonder performance verlies wordt er geoptimaliseerd. MOF De Job Scheduling SMF beschrijft vier punten die van belang zijn als er gebruik wordt gemaakt van batch jobs namelijk de batch architectuur, batch processing, job scheduling activiteiten en documentatie en training. Een batch architectuur bestaat uit verschillende componenten waaronder een management server, application servers en een capacity database. Ieder component wordt kort beschreven samen met de batch architectuur. Batch processing gaat in op de uitvoer van de batch jobs. Na het starten van een batch run worden alle batch jobs binnen de batch run achtereenvolgens uitgevoerd. Treed er een fout op tijdens het uitvoeren van een batch job dan wordt er een error gegenereerd waarna de volgende batch job wordt gestart. Naarmate IT omgevingen groter worden neemt het aantal batch jobs toe en wordt optimalisatie belangrijker voor het efficiënt gebruiken van aanwezige resources en geen performance te verliezen. Activiteiten die daarbij kunnen helpen zijn monitoring, event management en data analyse welke in de SMF uitvoerig worden besproken. Naast de drie genoemde activiteiten wordt aandacht besteed aan het maken van backups, draaien van adhoc batch runs en reporting. IT Service CMM Job Scheduling heeft geen overeenkomende key area‘s binnen IT Service CMM. Overzicht Aspect Het draaien van batch jobs wordt gemonitord Batch jobs zijn gedocumenteerd Optimalisatie van de batch job scheduler vindt plaats Procedures voor het job scheduling zijn gedocumenteerd (bv. start en stop van een batch run, afhandelen van errors, aanpassen van de job schedule, etc)

Bron

Status

MOF MOF MOF MOF

5.4.10 Service Desk Situatie binnen The Backbone Eén van de vragen waar alle geïnterviewde gelijk op antwoorden is de aanwezigheid van een service desk. De geïnterviewden zijn het erover eens dat deze aanwezig is. In werkelijkheid kan The Backbone gezien worden als één grote service desk. De vijf operationele medewerkers delen samen één kantoor. Hier komt de telefoon binnen die door iedereen opgenomen kan worden. Naast de telefoon wordt een algemeen mail adres gebruikt die voor iedereen toegankelijk is en ook door iedereen gecontroleerd wordt. Voor het bijhouden van binnen gekomen calls, via telefoon of mail, wordt gebruik gemaakt van een helpdeskpakket. Komt een call binnen dan wordt deze opgenomen in het helpdeskpakket en van daaruit afgehandeld. Uitzonderingen hierop zijn kleine calls met weinig impact. De tijd die het kost om de call op te nemen in het helpdeskpakket is vergeleken met de resolving tijd te groot. Een voorbeeld van een dergelijke call is het resetten


36

van een password. Het beoordelen of een call in het helpdeskpakket opgenomen wordt doet iedere voorzich, er is geen vaste richtlijn. Over de bezetting van de service desk zijn afspraken gemaakt binnen het team. Twee diensten zijn benoemd, de vroege en late dienst. De vroege dienst begint om 7.30 en eindigt om 16.00, de late dienst loopt van 9.00 tot 17.30. De vroege uren worden voornamelijk gebruikt om ‗s nachts binnengekomen mails en meldingen vanuit MOM weg te werken. Over de bezetting van de service desk is afgesproken dat twee mensen de vroege dienst draaien, voor de late dienst is geen afspraak gemaakt. In de praktijk komt het erop neer dat er één of twee medewerkers zitten tot het einde van de dag. Voor het inplannen van de mensen wordt gebruik gemaakt van een planbord, hierop wordt aangegeven wie vroeg begint, wie een late dienst heeft, wie vrij heeft en wie buiten de deur werkt. Het maken van de planning gebeurt gezamenlijk tussen de vijf medewerkers, het management is hierbij niet betrokken en zijn ook niet ingedeeld op het planbord. MOF MOF ziet in de Service Desk een belangrijke toegevoegde waarde voor een organisatie doordat er binnen de organisatie één plek ontstaat waar de klant terecht kan met vragen, incidenten en problemen. Na het aannemen van een call blijft de Service Desk verantwoordelijk en zal zorgen voor het correct afhandelen, terugkoppelen en sluiten van de call. Het proces dat door de medewerkers van de Service Desk uitgevoerd wordt bestaat uit drie stappen, het aannemen en vastleggen van een call, het monitoren van een call en uiteindelijk het sluiten van een call. In de SMF zijn de drie stappen beschreven als een apart proces, binnen MOF maken de drie stappen deel uit van het Incident Management proces. De Service Desk neemt de call op, legt deze vast en probeert waar mogelijk het incident te verhelpen. Is dit laatste niet mogelijk dan wordt dit doorgegeven aan Incident Management en zorgt de Service Desk voor coördinatie en monitoring van de call. Uiteindelijk zal de Service Desk bepalen of het incident verholpen is en de call sluiten. Zoals de Service Desk hierboven is beschreven fungeert deze als aanspreekpunt voor de klant binnen het Incident Management proces. Deze rol voor de Service Desk gaat ook op voor andere SMF‘s. Changes komen bijvoorbeeld binnen bij de Service Desk en worden doorgegeven aan Change Management, de Service Desk zal problemen opmerken en doorgeven aan Problem Management en commerciële vragen worden doorgespeeld naar Service Level Management. Het proces zoals hierboven beschreven is slechts een deel van de SMF. Naast het proces wordt er aandacht geschonken aan de organisatorische kant en de optimalisatie van de Service Desk. Op organisatorisch gebied komen zaken als planning, gebruikte technieken voor communicatie met de klant, kostenbeheersing, rapportage en marketing naar voren. Over optimalisatie schrijft de SMF mogelijke stappen die genomen kunnen worden, bijvoorbeeld de inrichting van de werkruimte, technologie, competenties van werknemers maar ook de mogelijkheid tot outsourcen. IT Service CMM Binnen IT Service CMM is er geen key area die zich specifiek bezig houdt met de Service Desk maar zijn de Service Desk activiteiten opgenomen in Service Request and Incident Management. De achterliggende gedachte en de uitgevoerde activiteiten komen overeen. Binnen MOF is er waarschijnlijk voor gekozen deze beschrijving los te maken van het Incident Management proces vanwege de hoeveelheid informatie die erover te geven is. Dit speelt bij IT Service CMM geen rol door de abstractie die erin zit.


37

Overzicht Aspect Er is een applicatie aanwezig voor het opslaan, monitoren en bijhouden van onder andere incidenten, service requests en changes. Alle binnenkomende calls worden geregisteerd Rapportages zijn aanwezig voor het evalueren van de service desk De activiteiten en opzet van de Service Desk is gedocumenteerd

Bron

Status

MOF / ITSCMM

MOF / ITSCMM MOF / ITSCMM ITSCMM

5.4.11 Service Request & Incident Management Situatie binnen The Backbone Service Request & Incident Management ligt binnen The Backbone dicht tegen Change & Release Management en de Service Desk aan. Alles wat binnenkomt, bijvoorbeeld incidenten, changes, service requests en informatie aanvragen komen op één stapel terecht en worden op dezelfde manier en door dezelfde medewerkers afgehandeld. Incidenten komen in de meeste gevallen binnen via MOM door fouten te detecteren en daar meldingen van te geven. Het komt sporadische voor dat een klant eerder opmerkt dat een fout is opgetreden en dit via de telefoon of mail meldt dan dat MOM een melding geeft. MOM is daarnaast niet in staat alles te monitoren wat kan leiden tot calls door klanten, bijvoorbeeld over printers die niet bereikbaar zijn. Zodra een incident bekend is wordt deze door één van de medewerkers opgepakt, hierbij worden de incidenten verdeeld op basis van de klant of kennis. Afhankelijk van de impact van het incident wordt voordat het incident wordt verholpen een registratie gemaakt in het helpdeskpakket. Is een incident verholpen dan wordt dit teruggekoppeld naar de klant als de medewerker dit nodig acht. In de praktijk is het zo dat incidenten gemeld vanuit een persoon altijd worden teruggekoppeld en incidenten vanuit MOM enkel als de klant van het voorval op de hoogte moet zijn. Het daadwerkelijke terugkoppelen gebeurd telefonisch, per mail of tijdens periodieke gesprekken die met elke klant plaatsvinden. Zoals bij de Service Desk is gezegd zijn er verschillende bronnen die gebruikt kunnen worden voor het oplossen van incidenten. Voordat er aandacht wordt besteed aan het oplossen van een incident wordt gekeken of een incident eerder is voorgekomen. Dit gebeurt veelal op kennis, ‗heb ik een soortgelijk geval eerder gezien?‘, en aan de hand van de repeatcounter binnen MOM die aangeeft hoe vaak een incident al is opgetreden. Als er geen soortgelijk incident gevonden kan worden wordt naar een nieuwe oplossing gekeken. MOF Het Incident Management SMF beschrijft een proces wat gevolgd kan worden voor het verhelpen van incidenten en afhandelen van service requests. Het proces zorgt ervoor dat incidenten snel worden verholpen, gedocumenteerd worden en geen incidenten blijven liggen doordat andere incidenten een hogere prioriteit hebben. Het proces bestaat uit de volgende stappen: Detection, self-service and recording: In deze stap wordt een incident cq. service request opgemerkt en vastgelegd. Voor het vaststellen kan gebruik worden gemaakt van onder andere telefoon, mail, fax en een website. Het vastleggen van een incident cq. service request gebeurd in een applicatie. Het subproces van detection, selfservice and recording wordt uitgevoerd door de Service Desk. Classification and initial support: Is de Service Desk niet in staat het incident te verhelpen en zijn geen soortgelijke incidenten gevonden dan wordt het incident geclassificeerd waardoor een incident een categorie en prioriteit krijgt. Op basis van de categorie en prioriteit komt het incident bij een persoon / team terecht en wordt deze afgehandeld. Investigation and diagnosis: Is geen oplossing of workaround bekend voor het incident dan wordt hiernaar gezocht. Mocht deze niet gevonden worden dan kan het


38

incident worden opgeschaald naar het management team waardoor meer resources vrijkomen of wordt het incident doorgeschoven naar Problem Management. Resolution and recovery: Is een workaround of oplossing bekend dan wordt deze geïmplementeerd. Resolution and recovery zorgt dat dit op de juiste manier gebeurd. Closure: In de laatste stap van het proces wordt de documentatie bijgewerkt en de klant op de hoogte gebracht. In het proces zijn enkele zijsprongen mogelijk. In het geval er een service request binnenkomt dan wordt hiervoor een apart proces opgestart en de service request afgehandeld. Een incident kan aan Problem Management toegewezen worden als daar soortgelijke incidenten openstaan en het incident kan aangemerkt worden als een major incident als aan bepaalde voorwaarden voldaan wordt, bijvoorbeeld hoge impact en een bedreiging van de security. Opschaling naar een major incident zorgt ervoor dat een hogere laag in de organisatie het incident gaat coördineren en meer resources beschikbaar komen. IT Service CMM IT Service CMM heeft een key area die vergelijkbaar is met de SMF, incidenten worden verholpen en service request worden afgehandeld. De key area die binnen IT Service CMM hier zorg voor draagt is Service Reqeust and Incident Management uit Level 2. De key area bespreekt wat nodig is voor het verhelpen van incidenten. Het proces dat hierbij gevolgd wordt is identify, record, track, analyse en resolve. Vergeleken met MOF is er één benoemenswaardig verschil tussen de SMF en de key area namelijk de mogelijkheid tot escalatie naar het management. De key area zegt hier niks over en dat geldt ook voor de aansluiting van het proces met Problem Management. Overzicht Aspect Een applicatie is aanwezig voor het opslaan en bijhouden van incidenten en service requests Incidenten en service request worden opgenomen in de applicatie en van daaruit opgevolgd Incidenten worden geprioritiseerd en geclassificeerd Incidenten met een hoge prioriteit / impact worden afgehandeld volgens een andere procedure (major incident) Incident Management kan gebruik maken van bestaande oplossingen voor incidenten die bekend zijn bij Problem Management Incidenten en service requests worden verholpen volgens een vast proces Het proces voor het verhelpen van incidenten en service requests is gedocumenteerd Betrokken personen worden op de hoogte gehouden van lopende incidenten en service requests Standaard rapportages zijn aanwezig voor Service Request and Incident Management

Bron

Status

MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF MOF

MOF / ITSCMM ITSCMM MOF / ITSCMM ITSCMM

5.4.12 Problem Management Situatie binnen The Backbone Problem Management is bij The Backbone geïntegreerd met incident management. Meldingen die vaker voorkomen krijgen extra aandacht. De gevolgde werkwijze bij het verhelpen van de problemen wijkt niet af van de werkwijze die gevolgd wordt bij het verhelpen van incidenten. MOF Binnen MOF zorgt de SMF Problem Management voor het afhandelen van problemen. Problemen worden binnen MOF omschreven als de onbekende oorzaak van één of meerdere incidenten. Het doel van de SMF is de onbekende oorzaak te achterhalen en hiermee te voorkomen dat de incidenten vaker optreden.


39

Het vaststellen van problemen gebeurt op twee manieren, reactief en proactief. Reactief vindt dit plaats vanuit het Incident Management en de Service Desk proces. Beide processen hebben de mogelijkheid incidenten als problemen aan te merken. Proactief melden en verhelpen vindt plaats binnen het Problem Management proces zelf door onder andere gebruik te maken van trend analyses. Het Problem Management proces zoals beschreven in de SMF bestaat uit de onderstaande vijf stappen: Problem recording and classification: In deze stap wordt de beslissing genomen of de aanvraag wordt gehonoreerd door Problem Management. Zo ja dan wordt het probleem vastgelegd, geclassificeerd en geprioritiseerd. Problem investigation and diagnosis: Het achterhalen van de oorzaak voor een probleem. In de SMF worden verschillende analyse methoden beschreven die hiervoor gebruikt kunnen worden. Error control: Wordt verwacht dat een probleem zich vaker gaat voordoen en is een workaround gevonden dan moeten deze samen opgeslagen worden als een known error, een probleem waarvan de achterliggende oorzaak is achterhaald en een workaround beschikbaar is. Extra details zoals workaround, berekende kosten voor het verhelpen van het probleem en de verwachte tijdsduur worden vastgelegd. Komt het probleem weer voor dan kan Incident Management gebruik maken van deze informatie en het probleem verhelpen. Problem closure: Wordt een probleem gesloten dan wordt gecontroleerd of de documentatie compleet is en wordt een closure code toegekend. Met de closure code kan aangegeven worden of een probleem succesvol is verholpen, SLA‘s zijn overtreden, etc. Proactive analysis and review: Proactief analyseren van data om problemen te voorkomen. Naast het proactief beheren van problemen worden reviews uitgevoerd om problemen en incidenten te evalueren. IT Service CMM IT Service CMM heeft in level drie een key area Problem Management die overeenkomt met de SMF qua doel en werkzaamheden. Het enige verschil tussen beide procedures is error control binnen de SMF. IT Service CMM maakt geen onderscheid tussen problemen en problemen die mogelijk terug zullen komen en behandelt elk probleem hetzelfde. Overzicht Aspect Problemen worden vastgelegd in een applicatie Problemen worden gecategoriseerd en geprioritiseerd Problem Management vindt op proactieve en reactieve wijze plaats Templates en rapportages zijn aanwezig voor Problem Management

Bron

Status

MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM ITSCMM

5.4.13 Service Level Management Situatie binnen The Backbone Met elke klant is een SLA / contract afgestemd waarin onder andere de diensten die The Backbone levert, prijzen, welke werkzaamheden wel en niet voor rekening van The Backbone komen, contactinformatie en service windows worden benoemd. Tijdens de looptijd van de SLA worden periodiek gesprekken gevoerd met de klant. Tijdens de gesprekken staat de dienst inhoudelijk centraal en wordt gesproken over, bijvoorbeeld changes en incidenten die plaats hebben gevonden, dit moment spelen of eraan komen en wensen van de klant. Voor een aantal klanten is de periode waarin de gesprekken plaatsvinden in de SLA opgenomen. Bij een wijziging van de dienst naar aanleiding van een gesprek wordt dit verwerkt in de SLA. Evaluaties van de dienst op een hoger niveau en gesprekken over het voortzetten van de dienst worden niet gevoerd. MOF


40

De Service Level Management SMF richt zich op de zakelijke en commerciële kant van IT Service Management. Het doel van de SMF is het leveren, onderhouden en verbeteren van IT services. De spil in het proces is de Service Level Agreement (SLA) waarin vastgelegd staat wat is overeengekomen betreft de availability, performance en responsiveness van services. Het proces van Service Level Management bestaat uit zes stappen en wordt vooraf gegaan door een eenmalige fase. De eenmalige fase wordt gebruikt om te achterhalen of er een wens is voor Service Level Management. Het continue proces bestaat uit de volgende stappen: Setup activities: voorbereidende werkzaamheden worden gedaan om gebruik te kunnen maken van Service Level Management Service catalog: geleverde diensten worden samengenomen en vastgelegd in niet technische taal Service level agreements: één of meerdere SLA‘s worden afgestemd met de tweede partij Service level monitoring: geleverde services worden gemonitord door overeengekomen thresholds te meten Service level reporting: verzamelde data in de voorgaande stap wordt gerapporteerd Service level agreement review: review waarin het leveren van de dienst en de bestaande SLA‘s worden geëvalueerd IT Service CMM Service Level Management en de hieruit voortkomende activiteiten zoals beschreven door MOF is in IT Service CMM verdeeld over verschillende key areas. Samen dekken de key areas een vergelijkbaar gebied vergeleken met de SMF. De key area Subcontract Management is daarop een uitzondering. Subcontract Management gaat in op contracten afgesloten met derde partijen die nodig zijn voor het leveren van de eigen dienst. MOF schrijft hier vergeleken met IT Service CMM weinig over. Onderstaande key areas zijn betrokken bij Service Level Management en vervullen de benoemde rol in het proces.; Service Commitment Management (Level twee) houdt zich bezig met het opstellen en onderhouden van Service Commitments (SLA‘s) Service Tracking and Oversight (Level twee) zorgt voor monitoring en rapportage omtrent de geleverde services Subcontract Management (Level twee) houdt zich bezig met contracten en overeenkomsten die zijn gesloten met leveranciers. Organization Service Definition (Level drie) is verantwoordelijk voor het opstellen van een service catalog Overzicht Aspect De IT Service behoeften van de klant zijn gedocumenteerd Een service catalog is opgesteld van alle services in gebruik bij een klant Een SLA is opgesteld met de klant waarin de dienst is beschreven Geleverde diensten en services worden gemonitord Monitoring data wordt gebruikt voor rapportage doeleinden Periodiek vindt evaluatie van de SLA plaats Procedures zijn aanwezig waarin wordt beschreven hoe om te gaan met leveranciers / subcontractors (bv selectie, reviews, etc.)

Bron

Status

ITSCMM MOF MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM ITSCMM

5.4.14 Capacity Management Situatie binnen The Backbone


41

MOM verzorgt Capacity Management voor The Backbone op twee manieren. Bij het overtreden van thresholds, bijvoorbeeld schijven die 90% vol zitten, geeft MOM meldingen weer waardoor The Backbone tijdig kan reageren. Daarnaast verzameld MOM performance data waarmee trends uitgezet kunnen worden. Op basis van de trends kunnen beslissingen genomen worden voor de toekomst. Het bewaken van de capaciteit, voornamelijk op de lange termijn, is een continu proces. Uit de interviews blijkt dat één van de operationele medewerkers, vergeleken met de andere medewerkers, zich hier meer mee bezig houdt. Dit is vanuit het verleden zo ontstaan en in de huidige manier van werken gegroeid. MOF MOF ziet Capacity Management als een continu proces wat bestaat uit de volgende stappen: Monitoring: performance en threshold data van resources wordt verzameld Analysis: analyseren van verzamelde data en proactief handelen om incidenten te voorkomen Modelling: modeleren van toekomstige en alternatieve scenario‘s Optimizing: op basis van de verzamelde data in de Analysis stap wordt naar de optimale configuration gezocht Change initiation: de uitkomsten van de analysis en optimizing stap zorgen ervoor dat op deze plek in het proces changes worden geïnitieerd Capacity Management is een onderdeel waarover binnen de organisatie verschillende lagen wat te zeggen hebben. Om problemen te voorkomen door verschil in kennis en communicatie wordt de organisatie door de SMF in drie delen ingedeeld. Business Capacity Management houdt zich bezig met veranderingen vanuit de management laag, aangepaste bedrijfsplannen, nieuwe strategieën, financiële plannen, etc. Service Capacity Management handelt vanuit de laag tussen de IT en de organisatie en gebruikt als input SLA‘s, Service Catalogs, Changes en Service Reviews. Resource Capacity Management richt zich op input vanuit de IT bijvoorbeeld, resource monitoring, incidenten, alerts en ontwikkelplannen. IT Service CMM De key area die het beste aansluit bij de Capacity Management van MOF is Resource Management uit level drie. Resource Management komt overeen met de SMF en houdt zich bezig met monitoren van resources, bekijken van alternatieven en het optimaliseren van componenten op reactieve en pro-actieve wijze. Verschil tussen beide methoden is de scope. De key area richt zich enkel op de laatste twee lagen in de organisatie, service en resource, en doet niks met informatie vanuit het management. Service Delivery is een tweede key area die ingaat op Capacity Management. De key area beschrijft een activiteit waarin voor het leveren van een service gekeken wordt welke en hoeveel resources nodig zijn. Overzicht Aspect Resources worden gemonitord op performance en thresholds Analyse van verzamelde data vindt plaats in het kader van capacity planning Resources worden geoptimaliseerd Een Capacity Database is aanwezig voor het opslaan van capacity data Een capacity plan is aanwezig waarin de benodigde resources zijn afgewogen Periodiek wordt het capacity plan geëvalueerd en herzien door verschillende personen in de organisatie Rapportages zijn aanwezig voor het rapporteren van Capacity Management aangelegenheden


Bron

Status

MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM ITSCMM

42

5.4.15 Availability & IT Service Continuity Management Situatie binnen The Backbone Availability, Continuity en IT zijn drie aspecten die onlosmakelijk met elkaar verbonden zijn en ook binnen de IT omgevingen van The Backbone en zijn klanten speelt. De operationele medewerkers van The Backbone zijn op de hoogte van mogelijke risico‘s en maatregelen om risico‘s te minimaliseren. Afhankelijk van de IT omgeving worden de nodige maatregelen genomen. De risico‘s die bestaan voor de interne omgeving zijn bekend door de algemene kennis, gedocumenteerd zijn ze echter niet. Wel heeft The Backbone bewuste keuzes gemaakt om risico‘s te minimaliseren. Zo worden de servers gehost op een beveiligde locatie en draaien cruciale applicaties op een cluster. Om de availability te bewaken worden de systemen gemonitord door MOM en de data opgeslagen voor trend analyse. Bij klanten komen de twee aspecten in gesprekken naar voren. The Backbone treedt adviserend op en schrijft op wens van de klant een voorstel en kan voor de implementatie zorgen. In het verleden heeft deze situatie zich ook voorgedaan. Een voorstel is geschreven echter door de hoge kosten die eraan gemoeid zijn is afgezien van een implementatie. MOF Availability en Continuity zijn binnen MOF gesplitst in twee aparte SMF‘s Availability Management en IT Service Continuity Management. Availability Management concentreert zich op de dagelijkse risico‘s die de IT omgeving bedreigen, bijvoorbeeld stroomuitval, configuratie fouten en server uitval. Het proces beschreven in de Availability Management SMF identificeert de risico‘s door kritieke services en de SLA‘s van klanten te analyseren en daar de componenten en requirements uit te halen. Vervolgens worden maatregelen genomen om risico‘s te minimaliseren. IT Service Continuity Management houdt zich bezig met de extreme risico‘s zoals brand, inbraak, vallende meteorieten. Komen bij Availiability Management risico‘s naar voren waarvoor geldt dat de maatregelen buiten proportie zijn en de kosten niet opwegen tegen de winst dan worden deze ook door IT Service Continuity Management afgehandeld. IT Service Continuity Management volgt hetzelfde proces als Availability Management, risico‘s worden geïdentificeerd en oplossingen voor het geval een risico optreed worden gezocht. De geïdentificeerde risico‘s en gevonden oplossingen worden verwerkt in een contingency plan. Het contingency plan beschrijft de acties die gevolgd moeten worden wanneer een incident plaatsvindt. IT Service CMM Service Delivery is de enige key area die zich bezig houdt met availability en continuity. Eén van de activiteiten beschreven in deze key area is preventief onderhoud om uitval in de toekomst te voorkomen. Dit is te vergelijken met Availability Management waar maatregelen werden genomen om risico‘s te minimaliseren. Overzicht Aspect Kritieke services en componenten zijn geïdentificeerd en availability requirements zijn hiervoor bekend Availability risico‘s worden geminimaliseerd voorzover de maatregelen binnen proporties zijn Availability risico‘s die niet door Availability Management worden beheerd zijn opgenomen in het contingency plan Continuity risico‘s zijn geïdentificeerd en mogelijke oplossingen zijn gezocht Een contingency plan is geschreven waarin beschreven wordt hoe te handelen in het geval van een incident Het contingency plan wordt periodiek geëvalueerd


Bron

Status

MOF MOF / ITSCMM MOF MOF MOF MOF

43

5.4.16 Workforce Management Situatie binnen The Backbone Binnen The Backbone spelen verschillende aspecten van workforce managent een rol waaronder het aannemen en trainen van personeel. Training is hierbij een belangrijk onderdeel vanwege de kennis die nodig is om een IT omgeving te beheren. Door de veelzijdigheid in IT omgevingen en componenten wordt het belang van kennis nog groter. Om ervoor te zorgen dat mensen werkzaamheden uit kunnen voeren wordt van alle operationele medewerkers een MCSE certificering verwacht. Het traject wat gevolgd moet worden staat niet vast, er is geen opleidingsplan per medewerker. Evaluatie van de medewerkers vindt op twee manieren plaats. Intern wordt er binnenkort begonnen met functionerings- en beoordelingsgesprekken. Per medewerker worden de resultaten hiervan bijgehouden. Extern komt het functioneren van de medewerkers sporadisch ter sprake in een gesprek. MOF In de Workforce Management SMF staat personeel centraal. De SMF is een korte beschrijving van punten die van belang zijn voor het aannemen en behouden van personeel met de juiste kennisniveaus. Dat de juiste mensen en kennis van belang is wordt door de SMF onderstreept. Onder andere het bepalen van requirements voor personeel, het aannemen van personeel, functieomschrijvingen, trainingen, competentie assessments, beoordelingsgesprekken en veiligheid van de werkplek komen aanbod. IT Service CMM Training Program is een key area uit level drie die ingaat op het trainen van personeel binnen de organisatie en dekt daarmee een deel van de SMF. De key area schrijft dat het op peil houden van kennis van belang is en dit onder andere met behulp van trainingen te realiseren is. Een organisatiebreed trainingsplan is hiervoor nodig waarin voor elke geleverde service beschreven is welke trainingen gevolgd kunnen dan wel gevolgd moeten worden. Naast het trainingsplan gaat de key area in op het ontwikkelen van eigen trainingen door de organisatie. Overzicht Aspect Functieomschrijvingen zijn opgesteld voor alle werknemers Benodigde competencites voor het leveren van de services zijn in kaart gebracht De performance van werknemers wordt geëvalueerd De organisatie beschikt over een trainingsplan

Bron

Status

MOF MOF / ITSCMM MOF MOF / ITSCMM

5.4.17 Infrastructure Engineering Situatie binnen The Backbone Standaarden en templates zijn voor verschillende doeleinden aanwezig binnen The Backbone waaronder voor documentatie van serverinstallaties, naamgeving en offertes. De plekken waar standaarden worden toegepast zijn niet bewust gekozen. De gebruikte sjablonen komen van een medewerker en zijn aangepast voor The Backbone. Vanaf een netwerklocatie zijn ze te benaderen en gebruiken. Onderhoud van de sjablonen gebeurt door iedereen. MOF Infrastructure Engineering houdt zich bezig met de standaardisatie binnen de organisatie, hierbij moet gedacht worden aan het opstellen en onderhouden van sjablonen en policies. Het proces voor Infrastructure Engineering is een continu proces wat uit de volgende stappen bestaat: Define infrastructure environment (eenmalig): In deze stap worden de eerste keuzes gemaakt wat betreft standaardisering. De keuze die gemaakt wordt is de scope van Infrastructure Engineering, wat valt hier wel onder en wat niet. Bijvoorbeeld de locatie Hengelo wordt gestandaardiseerd, locatie Enschede niet of alle HP servers wel en alle Dell servers niet.


44

Collect and define policies and standards (eenmalig): Deze stap is een inventarisatie van alle reeds bestaande standaarden en policies en de ontwikkeling van de nieuwe standaarden en policies. Apply policies and standards for infrastructure guidance: Deze stap wordt door de gehele organisatie uitgevoerd. Bij elke change wordt gekeken of er standaarden en policies van toepassing zijn, zo ja dan worden deze toegepast. Maintain policies and standards: In deze stap worden de standaarden en policies onderhouden door evaluaties te houden van de huidige standaarden en policies en zondig wijzigingen door te voeren. Deze stap loopt parallel aan de voorgaande stap. IT Service CMM Infrastructure Engineering heeft geen overeenkomende key areas binnen IT Service CMM. Overzicht Aspect De scope voor standaardisering is vastgesteld Standaarden en policies zijn geïnventariseerd en ontwikkeld Een centrale locatie is aangewezen voor het publiceren van standaarden en policies Periodiek worden standaarden en policies geëvalueerd en zonodig herzien

Bron

Status

MOF MOF MOF MOF

5.5 Validatie resultaten Het verwerken van verzamelde informatie is gebeurd door deze te interpreteren. Om de betrouwbaarheid van de resultaten te verhogen is een validatie uitgevoerd. De resultaten weergegeven in de overzichten zijn teruggekoppeld naar de organisatie en gevalideerd. De overzichten zoals hierboven weergegeven zijn naar drie medewerkers verstuurd. De drie medewerkers is gevraagd voor elk punt na te gaan of de aangegeven status overeenkomt met de werkelijkheid zoals zij dit ervaren. De uitkomsten van de drie validaties zijn samengenomen en opgenomen in Bijlage 4 -. Het oordeel uit de organisatie komt, op enkele punten na, overeen met het eerste gegeven oordeel. Voor de afwijkende punten moet eerst bekeken worden wat de achterliggende oorzaak is van de afwijking voordat het oordeel uit de organisatie wordt overgenomen. De volgende twee oorzaken kunnen hiervoor worden genoemd: De genoemde interpretatiefout. Als tijdens het uitvoeren of verwerken van de interviews een antwoord verkeerd is geïnterpreteerd zal dit terug te zien zijn in de toegekende status welke afwijkt van het oordeel vanuit de organisatie. Afwijkingen die het gevolg zijn van deze oorzaak zijn gemakkelijk te herstellen door het oordeel van de organisatie over te nemen of in samenspraak met de organisatie een oordeel te stellen. Een tweede mogelijke oorzaak die moeilijker is te voorkomen en verhelpen is het gebruikte referentiekader bij het bepalen van de status. Bij het vaststellen van het eerste oordeel zijn als referentiekader de methodieken Microsoft Operation Framework en IT Service CMM gebruikt. Voor het tweede oordeel zal waarschijnlijk een ander referentiekader gebruikt zijn door het verschil in kennis van methodieken tussen de medewerkers uit de organisatie en de afstudeerder. Mocht deze oorzaak te gronde liggen aan de afwijking dan moet worden afgewogen hoe zwaar het oordeel uit de organisatie telt. Het eerste oordeel toelichten binnen de organisatie en eventueel bijstellen in samenspraak met de organisatie is een mogelijke oplossing voor deze oorzaak. Van de in totaal 101 beoordelingen zijn zes beoordelingen te positief ingeschat en vier beoordelingen te negatief. Daarmee is het overgrote deel van de oordelen juist en geven de overzichten een goed beeld van de huidige situatie. Dit maakt het mogelijk de aanbevelingen te schrijven en beargumenteren.


45

5.6 Gebruikte applicaties In de huidige situatie wordt een aantal applicaties gebruikt voor het ondersteunen van de werkzaamheden. De twee belangrijkste daarvan zijn MOM voor het monitoren van systemen en een helpdesk tool voor het vastleggen van calls. Hieronder worden beide applicaties en de inrichting toegelicht. 5.6.1 MOM Voor het monitoren van systemen wordt Microsoft Operation Manager 2005 (MOM) gebruikt. Figuur 10 geeft de opzet van MOM weer. Een windows cluster met twee nodes wordt gebruikt om SQL Server 2000 en SQL reporting te hosten. Daarnaast dient één server als MOM management server. Op locatie van de klant draait op elke gemonitorde server een MOM agent die via het internet data verstuurt naar de MOM management server. Een enkele klant is hierop uitzondering en zal in plaats van de agent op de gemonitorde server een MOM management server op locatie van de klant via een connector de data versturen naar de MOM management server bij The Backbone.

MOM

Firewall

Firewall

Server met MOM agent

Windows cluster

Figuur 10 - MOM opzet Voor het monitoren van de servers worden twee typen consoles gebruikt. Eén is de MOM Operator Console, een stand-alone applicatie gebruikt binnen The Backbone. De console geeft de medewerkers van The Backbone onder andere de mogelijkheid systeem attributen, computer states en events te zien, alerts te bekijken en bewerken en acties uit te voeren. De tweede console is een webconsole die door één klant wordt gebruikt. De klant kan meekijken met The Backbone en zijn eigen events, systeem attributen en alerts zien. Hij is niet in staat om alerts aan te passen. Voor het beheren van MOM wordt de MOM Administor Console gebruikt. Om alerts en events te genereren wordt gebruik gemaakt van management packs, computer groups, rule groups, rules. Hieronder wordt van elk een omschrijving gegeven. Management pack: Een management pack moet gezien worden als een uitbreiding van MOM die ondere andere de volgende componenten bevat: rules, computer groups, reports, computer attributen, alert en event views. Microsoft stelt in het algemeen per product een management pack beschikbaar. Voorbeelden van management packs zijn Active Directory, Windows Base Operating System, Exchange. Naast de Microsoft management packs stellen third party bedrijven management packs beschikbaar, bijvoorbeeld HP, Dell en VMWare. Computer group: Een groep waarin computers met overeenkomende eigenschappen worden verzameld, bijvoorbeeld een groep voor virtuele servers, virtuele hosts, exchange servers, desktop computers, etc. Rule groups worden toegewezen aan een computer groep en op basis van deze toewijzing is de agent op de hoogte van de informatie die verzameld moet worden. Rule groups: Een verzameling van rules Rule: Een rule wordt gebruikt om data te verzamelen en verwerken. Elke rule is verantwoordelijk voor een specifiek stuk data. Voorbeelden van rules zijn percentage vrije schijf, users die een verkeerd wachtwoord invoeren, services die vastlopen, etc. Voor elke rule zijn een aantal instellingen te configureren waaronder de data source (bv de event log, WMI data of een script), of een alert gecreëerd moet worden en of eventuele andere responses moeten worden getriggerd (mail, scripts, etc).


46

In de huidige situatie probeert The Backbone zoveel mogelijk informatie over de klant te verzamelen om niets te missen. Om alle informatie te verzamelen worden bestaande management packs waarnodig opgenomen en waar geen management packs voor bestaand worden deze gecreëerd. Zoals hierboven uitgelegd kan de MOM Operator Console gebruikt worden om verzamelde data in te zien. Om de data begrijpelijk en vindbaar te maken wordt gebruik gemaakt van (recursieve) views. Een view geeft aan welke data getoond moet worden en eventueel welke selectie criteria gebruikt moeten worden. Bijvoorbeeld alle nieuwe alerts die betrekking hebben op Exchange 2003 servers, alle resolved alerts van klant x, of alle computes in een bepaalde groep. Naast de views die met de geïnstalleerde management packs zijn meegekomen worden de onderstaande views gebruikt: Alerts per klant: Toont alle alerts van de betreffende klant Computers per klant: Toont alle gemonitorde systemen van een klant Alerts per medewerker: Geeft alle alerts weer die aan de betreffende medewerker zijn toegewezen en niet zijn resolved Resolved alerts: Alle alerts die de status resolved hebben Information en success alerts: Alle alerts die de status information of success hebben Voor het verwerken van alerts biedt MOM verschillende functionaliteiten. Alerts kunnen naar wens gesorteerd worden met behulp van views zoals hierboven beschreven. Elke alert heeft een status. De status kan gebruikt worden om aan te geven in welk stadium een alert is, bijvoorbeeld nieuw, toegekend, opgelost, etc. Een hoeveelheid custom fields kan gebruikt worden Voor rapportage doeleinden is SQL Reporting Service 2000 geïnstalleerd. De reporting service kan gebruikt worden om op basis van data verzameld door MOM rapportages te genereren. Voorbeelden van rapportages zijn performance analysis, total alert count, top 100 used mailboxes, etc. Om alle klanten maandelijks te voorzien van rapportages is The Backbone op dit moment bezig de rapportages te automatiseren. 5.6.2 Helpdesk Tool In MOM is het alleen mogelijk om door MOM gegenereerde alerts bij te houden en af te handelen. Een helpdeskpakket is aanwezig om deze functionaliteit te bieden voor calls die telefonisch of per mail binnenkomen. Het pakket biedt de mogelijkheid om requests, solutions, inventory, contracten op te slaan en rapportages uit te draaien. Slechts een deel van de functionaliteit die het helpdeskpakket biedt wordt gebruikt door The Backbone. Het requests onderdeel wordt gebruikt om calls die binnenkomen op te slaan. Van elke call wordt onder andere een beschrijving, de naam van de aanvrager, de status en de naam van de medewerker op geslagen. In de praktijk wordt niet consequent elke call die binnenkomt overgenomen, alleen de calls met genoeg impact worden vastgelegd. Het bepalen van de impact en of een call moet worden opgenomen gebeurt door de medewerkers. Naast requests wordt solutions gebruikt om gevonden oplossingen voor incidenten en problemen vast te leggen. MOM biedt deze mogelijkheid ook en is zelfs al deels gevuld door Microsoft. Het verschil tussen beide pakketten is dat MOM oplossingen aan events en alerts koppelt en in het helpdeskpakket oplossingen zijn op te slaan zonder gekoppeld te worden aan een event of alert. In het helpdeskpakket kan een eigen boomstructuur worden opgezet om de oplossingen onder te verdelen in categorieën.


47

6 Gewenste inrichting In het voorgaande hoofdstuk is een gekeken naar de huidige inrichting van The Backbone. Met onder andere interviews is informatie verzameld dat een beeld geeft over de huidige situatie binnen The Backbone. De wens van The Backbone is om de huidige procesinrichting efficiënter en effectiever te maken. Op basis van de verkregen informatie over de huidige inrichting zijn aanbevelingen te schrijven waarmee deze wens wordt ingevuld. The Backbone is een jong en groeiend bedrijf wat impact heeft op de aanbevelingen. Worden de aanbevelingen geschreven voor de huidige omvang van de organisatie dan zal dit resulteren in aanbevelingen die slechts tijdelijk bruikbaar zijn. Aanbevelingen geschreven voor een situatie in de toekomst zullen niet direct bruikbaar zijn. In samenspraak met de directie van The Backbone is een normstelling opgesteld die wordt gebruikt voor het schrijven van de aanbevelingen. De aanbevelingen aan de The Backbone zijn in een vertrouwelijk bijlage geplaatst, Bijlage 5 -. De aanbevelingen opzich zijn niet van vertrouwelijke aard maar geven wel aan hoe The Backbone zich de komende jaren gaat inrichten en positioneren. Voor een concurrent kan de informatie daarom waardevol zijn. Daarom is besloten de aanbevelingen in een aparte bijlage op te nemen. In de aanbevelingen worden achtereenvolgens de volgende punten behandeld: Normstelling: Zoals hierboven is beschreven is de omvang van de organisatie van belang voor de aanbevelingen. De directie van The Backbone heeft hiervoor een normstelling opgesteld. De normstelling beschrijft de hoeveelheid klanten en de omvang van de klanten waar The Backbone naar streeft. Organisatie structuur: Belangrijk binnen elk bedrijf is de organisatiestructuur. Uit de huidige situatie is op te maken dat een structuur aanwezig is maar deze impliciet en niet gedocumenteerd is. De structuur is door de tijd heen ontstaan doordat mensen werkzaamheden opzich namen. Probleem met deze werkwijze is dat niet duidelijk is wie verantwoordelijk is voor welke werkzaamheden. Een nieuwe organisatiestructuur en functieprofielen voor de medewerkers moeten dit verhelpen. In de aanbeveling wordt een nieuwe structuur voorgesteld met zes rollen. Procesinrichting: In het onderzoek staat de procesinrichting van The Backbone centraal. Eén van de aanbevelingen gaat hier op in. Binnen The Backbone is een keuze gemaakt om voor het inrichten van de processen gebruik te maken van MOF. Voor de volgorde van SMF implementaties wordt teruggevallen op IT Service CMM. De SMF‘s zijn vergeleken met de key area‘s van IT Service CMM en krijgen daardoor een prioriteit die gebruikt kan worden voor het bepalen van de volgorde. Het implementeren van de SMF‘s is niet voor elke SMF wenselijk zoals MOF dit voorschrijft. De aanbeveling weegt op basis van de verkregen informatie voor de belangrijkste SMFs af hoe deze het beste kan worden toegepast. Technische inrichting: Efficiëntie en effectiviteit zijn onder andere te behalen door een goede inrichting van de techniek. Daarnaast is de techniek belangrijk als input voor het proces. In deze aanbeveling wordt op de verschillende technische aspecten ingegaan. Op het huidige moment zijn twee pakketen in gebruik, voor beide wordt een aantal voorstellen gedaan voor een aangepaste inrichting. Buiten de twee pakketen om wordt een aanbeveling gedaan voor een nieuwe technische inrichting waarmee de klant beter inzicht krijgt in de afgenomen dienst. Schaalbaarheid: Als laatst wordt ingegaan op de technische schaalbaarheid van de normstelling. Voor het doorrekenen van de schaalbaarheid zijn statistieken verzameld over onder andere de huidige situatie en wordt gekeken wat dit betekend voor de normstelling. De uitkomst is vergeleken met gevonden statistieken van andere omgevingen waaruit onder andere blijkt dat het belangrijk is een aantal van de gedane aanbevelingen door te voeren.


48

7 Conclusie The Backbone als IT dienstverlener heeft de wens om de interne procesinrichting efficiënter en effectiever in te richten. Voor het inrichten van de interne processen is gekozen voor Microsoft Operation Framework (MOF) vanwege de Microsoft oriëntatie binnen de organisatie. Om daadwerkelijk invulling te geven aan de wens heeft The Backbone dit onderzoek opgesteld. Onderstaande vraag heeft tijdens het onderzoek centraal gestaan: Hoe moet The Backbone, uitgaande van een keuze voor Microsoft Operation Manager en Microsoft Operation Framework als tool en methodiek, zijn processen inrichten om zijn diensten effectief en efficiënt uit te kunnen voeren? In het onderzoek is in vijf stappen naar het antwoord op de onderzoeksvraag toegewerkt. In de eerste stap, uitgewerkt in hoofdstuk 4, is ingegaan op de dienstverlening van The Backbone. Vanuit een intern en extern kader is de dienstverlening tegen het licht gehouden. Het interne onderzoek heeft een duidelijk beeld gegeven van de geleverde diensten. Voor het externe oogpunt is met een klant gesproken. Uit het gesprek bleek dat over de kwaliteit en tevredenheid van de dienst niet te klagen valt. In de tweede stap is de huidige procesinrichting van The Backbone bekeken. Door interviews uit te voeren, op de werkvloer te observeren en het bekijken van documenten en applicaties is geprobeerd een duidelijk beeld te krijgen van de inrichting binnen The Backbone. De verzamelde informatie is per SMF uitgewerkt in een beschrijvende tekst. Uit de informatie bleek dat de nodige zaken, bijvoorbeeld applicaties, werkwijzen en documentatie, aanwezig zijn en hier ook aandacht aan is besteed maar dat een groot aantal van deze zaken impliciet en ad-hoc is geregeld en niet consequent wordt uitgevoerd. Op basis van de beschrijvingen over de huidige situatie is gekeken naar de aandacht- en verbeterpunten voor The Backbone. De huidige situatie is hiervoor vergeleken met de methodieken MOF en IT Service CMM. De door de methodieken beschreven processen zijn in het verslag kort samengevat en de status van The Backbone is met overzichten weergegeven. Uit de overzichten blijkt de aandachtspunten voornamelijk liggen in het structureren van werkzaamheden, consequent uitvoeren van werkzaamheden en documenteren van werkzaamheden. Samen met de beschrijving van de huidige situatie is dit uitgewerkt in hoofdstuk 5. Voor het monitoren van IT omgevingen maakt The Backbone gebruik van Microsoft Operation Manager (MOM). MOM geeft The Backbone inzicht in de huidige status en incidenten die plaatsvinden binnen verschillende IT omgevingen. De informatie van MOM is voornamelijk input voor de processen. Voor het verwerken van door MOM gegenereerde meldingen biedt MOM verschillende functionaliteiten die dit ondersteunen, bijvoorbeeld het toekennen van statussen aan meldingen en het toekennen van een melding aan een medewerker. De laatste stap geeft antwoord op de onderzoeksvraag en beschrijft een drie tal aanbevelingen aan The Backbone voor een efficiëntere en effectievere procesinrichting. Uit de verzamelde informatie en opgestelde overzichten blijkt dat op verschillende punten winst behaald kan worden en niet alleen naar de processen gekeken moet worden. De aanbevelingen gaan in op de organisatiestructuur, processen en de techniek. Vanwege de vertrouwelijkheid zijn de aanbevelingen in een aparte bijlage geplaatst.


49

8 Literatuurlijst [12MAN]

[CMMI] [DST]

[DAS90]

[DAV92] [GRA02] [HAC93] [HAM90] [HIL94] [HPSM]

[ITILR] [ITILSM] [ITSCMM] [JOSC93] [KTG97]

[LEVI60] [MAL98] [MOFIT]

[MOFSM]

[NICK02] [SAL04]

[SCMM] [VSB04]

Beschrijving van het door Davonport voorgeschreven vijf stappen plan voor Business Process Redesign, http://www.12manage.com/methods_bpr_nl.html, bezocht op 01/08/2006 Capability Maturity Model Integrated, http://www.sei.cmu.edu/cmm/, bezocht 03/08/2006 Business Process Reengineering and Enterprise Architecture, http://users.iafrica.com/o/om/omisditd/denniss/text/busthem6.html, bezocht op 04/01/2007 The New Industrial Engineering: Information Technology and Business Process Redesign, Davenport T.H., Short J.E., Sloan Management Review, pp. 11-27, 1990 Process Innovation: Reengineering Work Through Information Technology, Davenport T., Harvard Business School Press, 1992, ISBN 0875843662 A Wider View of Business Process Reengineering, Grant D., Communications of the ACM, No 2, Vol. 45, February 2002 Reengineering the Corporation: A manifesto for business revolution, Hammer M., Champy J., Harper Business, 1993 Reengineering work: Don‘t automate, obliterate, Hammer M., Harvard Business Review, Vol. 68, Issue 4, pp. 104-112, July August 1990 Service Level Agreements: Panacea or Pain?, Hiles A.N., The TQM Magazine 2, pp. 14-16, 1994 Omschrijving IT Service Management volgens Hewlett-Packerd HP IT Service Management (ITSM), pag 5, 2003, ftp://ftp.hp.com/pub/services/itsm/info/itsm_businesswp.pdf, bezocht op 01/08/2006 ITIL Refresh: Scope and development plan, OGC, June 2006, http://www.itil.co.uk/scope_web.pdf, bezocht op 02/08/2006 Omschrijving IT Service Management volgens IT Infrastructure Library, http://www.itil.co.uk/faqs.htm#12, bezocht op 01/08/2006 The IT Service Capability Maturity Model, Niessink F., Clerc V., Tijdink T., van Vliet H., Januari 2005, http://www.itservicecmm.org/, bezocht op 03/08/2006 Exploring Corporate Strategy Third Edition, G. Johnson, K. Scholes, Prentice Hall International, 1993, ISBN 013297441X Business Process Change: A study of Methodologies, Techniques and Tools, Kettinger W.J., Teng J.T.C., Guha S., MIS Quarterly, No. 1, Vol. 21, pp. 5580, 1997 Marketing Myopia, Levitt T., Harvard Business Review 38, pp. 45-57, 1960 Business Process Redesign: An Overview, Malhorta Y., IEEE Management Review, No. 3, Vol. 26, 1998 MOF - An Actionable and Prescriptive Approach to ITIL, Microsoft Corporation, November 2005, http://go.microsoft.com/fwlink/?LinkId=56715, bezocht op 02/08/2006 Omschrijving IT Service Management volgens Microsoft Operation Framework, MOF Executive Overview, pag 7, januari 2005, http://www.microsoft.com/technet/itsolutions/cits/mo/mof/mofeo.mspx, bezocht op 01/08/2006 Stategy is…A lot of things, Nickols F., 2000, http://home.att.net/~nickols/strategy_is.htm, bezocht op 07/08/2006 IT Service Management and IT Governance: Review, Comparative Analysis and Impact on Utility Computing, Sallé M., Trusted Systems Laboratory, HP Laboratories Palo Alto, HPL-2004-98, June 2, 2004 Managing the Software Process, Humprey W., Addison-Wesley Longman Publishing Co., Inc., Boston, MA, 1989 Kwaliteitsmanagement van de ICT met CMM, Vreven G., Schiltmans-Bakker H., Academic Service, 2004, ISBN 9039522308


50

[WEI95]

Business Process Reengineering Analysis and Recommondations, Weicher M., Chu W. W., Ching Lin W., Le V., Yu D., Baruch College, City University, New York, 1995


51

Bijlage 1 -

Interview

Introductie Inleiding Voor het in kaart brengen van de huidige organisatie is een interview opgezet gebaseerd op de MOF Self Assessment Tool 1.0 en IT Service CMM Questionnair. Het doel van het interview is een beeld te krijgen over de interne inrichting van de organisatie. Analyze van de uitkomst moet de verbeterpunten binnen de huidige processen opleveren samen met een advies. Het interview is tot stand gekomen door het samenvoegen van de MOF Self Assessment Tool en IT Service CMM Questionnair aangevuld door IT Service CMM whitepaper en de MOF documentatie. Het structuren van de vragen en het interview is gedaan door het process model vanuit MOF te volgen. Microsoft Operation Framework Voor het inrichten van beheerorganisaties zijn verscheidene methodieken ontwikkeld. Eén hiervan is Microsoft Operation Framework (MOF) gebasseerd op het IT Infrastructure Library (ITIL). ITIL is een bewezen en veel gebruikt framework voor het inrichten van IT organisaties. MOF onderscheid zich wat betreft ITIL door de Microsoft inslag die is gemaakt. MOF is ontworpen met in het achterhoofd het beheren van Microsoft IT omgevingen. Microsoft heeft hiervoor ITIL ―adopted en adapted‖ met kennis en ervaring vanuit de eigen organisatie, partners, klanten en andere organsaties. MOF bestaat uit een process model, team model en risk discipline. Het process model is veruit de belangrijkste, het beschrijft de inhoudelijke processen die nodig zijn binnen de organisatie. Het process model is opgedeeld in vier kwadranten met elk hun eigen Service Management Functions (SMF). Figuur 11 geeft een beeld van de vier kwadraten en de SMF‘s.

Figuur 11 - MOF Process Model IT Service CMM IT Service CMM is een groeimodel voor IT beheerorganisaties. Het model onderkent vijf maturity levels, Initial, Repeatable, Defined, Managed en Optimizing. Elk level stelt eisen aan de aanwezige processen op het gebied van IT Services. IT Service CMM is gebasseerd op het Software Capability Maturity Model, een groeimodel voor software ontwikkel bedrijven. Twee grote verschillen tussen IT Service CMM en MOF zijn de achtergrond, Software CMM vs. ITIL, en het doel, IT Service CMM defineerd welke processen er moeten zijn en MOF zegt hoe deze het beste ingericht kunnen worden. Scope MOF bestaat uit eenentwintig SMF‘s, IT Service CMM bestaat uit vijf maturiy levels. Het interview beslaat niet het geheel van beide standaarden. In het interview zijn alle SMF gebieden meegenomen met uitzondering van Financial Management. De aanwezigheid van


52

de benodigde financiele middelen wordt als aanname genomen. Vanuit IT Service CMM zijn alle key area‘s uit het tweede level meegenomen en enkele uit het derde level.

Change Management IT omgevingen zijn onderhevig aan veranderingen. Onderdelen werken niet naar behoren, nieuwe updates zijn aanwezig, requirements aan systemen zijn verandert etc. Het doel van Change Management is het afhandelen van veranderingen met minimale interruptie van de normale gang van zaken. Centraal binnen elke iteratie van het Change Management Process is de Request voor Change (RFC) waarin alle details van de betreffende change zijn opgenomen. RFC‘s worden opgesteld vanuit de organisatie, bijvoorbeeld na aanleiding van een service request, of direct vanuit de klant. Relevante bronnen Systeem voor het opslaan, bijhouden en monitoren van RFC‘s Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van Change Management? 2. Is er een systeem aanwezig voor het opslaan en bijhouden (status, verantwoordelijk persoon, etc) van RFCs? 3. Worden RFCs vooraf gecontroleerd op volledigheid, duplicaten en haalbaarheid en zonodig teruggestuurd naar de initiatiefnemer? 4. Worden RFCs gecategoriseerd en geprioritiseerd (door één vast persoon / team)? 5. Welke triggers worden naast RFCs gebruikt voor uitvoeren van het Change Management Proces (vb nieuwe updates)? 6. Bestaat er een verschil in afhandeling tussen RFCs van verschillende categorie / prioriteit? 7. Worden changes geaccordeerd voor het Change Management proces verder wordt doorlopen? 8. Is er een planning van aankomende changes beschikbaar binnen de organisatie? 9. Zijn templates aanwezig voor Change Management? 10. Worden relevante personen op de hoogte gehouden over de status van RFCs (periodiek / event-driven)? 11. Zijn er processen voor het identificeren, vastleggen, analyseren, implementeren en reviewen van een RFC en zijn deze gedocumenteerd? 12. Wordt het afhandelen van RFCs gemeten en geëvalueerd met SLAs? 13. Is er één persoon / team verantwoordelijk voor Change Management?

Release Management Release Management is verantwoordelijk voor de release van de Changes ontwikkeld onder Change Management. Release Management maakt een planning, ontwikkeld en test een release package en voert de daadwerkelijke release uit. Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van Release Management? 2. Is Release Management geïntegreerd met Change Management binnen de organisatie?


53

3. Wordt er voor iedere release een planning opgesteld? 4. Worden gelijktijdig geplande releases gebundeld? 5. Worden releases getest voor de deployment in de productieomgeving? 6. Is er voor elke release een backout plan aanwezig en is deze getest? 7. Wordt de CMDB aangepast na het succesvol uitrollen van een release? 8. Wordt bij de deployment van releases nagegaan of de nodige licenties aanwezig zijn? 9. Wordt er binnen Release Management gebruik gemaakt van ondersteunende applicaties? 10. Zijn er processen voor het plannen, ontwikkelen, testen en uitrollen van releases en zijn deze gedocumenteerd? 11. Is er één persoon / team verantwoordelijk voor Release Management?

Configuration Management Het doel van Configuration Management is het garanderen dat enkel goedgekeurde componenten, configuration items (hardware, software, documenation, processes, procedures), gebruikt worden binnen de IT omgeving. Gedurende het gebruik van een item worden alle changes opgeslagen en bijgehouden. Binnen het Configuration Management proces worden Configuration Items geïdentificeerd, een Configuration Management Database opgezet en bijgehouden en reviews uitgevoerd om te verzekeren dat de Configuration Management Database overeenkomt met de productieomgeving. Relevante bronnen Bestaande CMDB Bronnen waarin systemen / configuraties worden beschreven Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van Configuration Management? 2. Zijn componenten voor configuration control geïdentificeerdt? 3. Is er een configuration management database (CMDB) aanwezig? 4. Worden de eigenschappen en de status van configuration items (automatisch) bijgehouden? 5. Wordt de productieomgeving op periodieke basis vergeleken met de CMDB en worden veranderingen gerapporteerd? 6. Welke toepassingen kent de CMDB binnen de organisatie? 7. Zijn er processen voor het selecteren, lezen, aanpassen, verwijderen en reviewen van configuration items en zijn deze gedocumenteerd? 8. Is er één persoon / team verantwoordelijk voor Configuration Management?

System Administration System Administration heeft te maken met de Day-to-day Administration van de IT productie omgeving. Hieronder valt het operationele beheer van network accounts (users, groups, distribution lists) en network resources (servers, printers, storage devices).


54

Vragen 1. Welke vorm van systeem opzet wordt binnen de organisatie gebruikt? Centralized Hardware / Centralized Administration Centralized Hardware / Distributed Administration (Follow the sun) Distributed Hardware / Centralized (Remote) Administration Distributed Hardware / Centralized & Delegated Administration Distributed Hardware / Distributed Administration 2. Zijn er processen voor het aanmaken, beheren en verwijderen van network accounts en network resources? 3. Is er één persoon / team verantwoordelijk voor System Administration?

Security Administration & Management De Security Administration & Management SMF‘s dekken samen alle aspecten op het gebied van security. Van Policies tot daadwerkelijke implementaties en maatregelen op het gebied van security. Aspecten die onder andere bij security naar voren komen zijn de Identification, Authentication, Access Control, Confidentiality, Integrity, Nonrepudiation, Auditing en het opstellen van security policies Relevante bronnen Audits Logs Configuraties Geschreven policies Vragen 1. Zijn services en informatie bronnen geïdentificeerd en geclassificeerd in kritische waarde en vertrouwelijkheid? 2. Zijn mogelijke security risks vastgesteld voor services en resources? 3. Zijn bovenstaande punten vastgelegd in een security policy en wordt deze op periodieke wijze geëvalueerd? 4. Welke vormen van security controls zijn geïmplementeerd? Is er een standaard binnen de organisatie voor identification (bijv. usernames)? Welke vormen van authentication worden gebruikt binnen de organisatie (passwords, biometrics, smart cards)? Welke vormen van access control worden binnen de organisatie gebruikt (RBAC, lockout, limited session use, etc) Zijn er technieken geïmplementeerd die confidentiality waarborgen (private key encryption, public key encryption, digitale certificaten, VPN‘s, File system encryption, etc)? Wordt er voorzien in data integrity (checksums, virus scans, etc)? Zijn er maatregelen genomen voor nonrepudiation (digital signatures, ontvangstbevestiging)? Worden uitgevoerde acties gelogd en regelmatig bekeken om ongewenste acties uit te sluiten (auditing)? Welke fysieke security controls worden gebruikt binnen de organisatie?

5. Worden security controls gemonitord en periodiek gecontroleerd (audits, logs etc)?


55

6. Wordt bij het uitvoeren van een change security in acht genomen? 7. Is er een Incident Management proces aanwezig voor security incidenten? 8. Zijn er processen voor het identificeren, monitoren en controleren van security controls en zijn deze gedocumenteerd? 9. Zijn er verantwoordelijke personen / teams aangewezen voor Security Administration & Management?

Service Monitoring and Control Service Monitoring en Control heeft te maken met het controleren of IT omgevingen in een healty staat zijn en zoniet acties te ondernemen. Hierbij wordt onderscheid gemaakt in Reactief en proactief control. Reactief bijvoorbeeld voor het afhandelen van incidenten. Proactief voor het herkennen van potentiële onderbreking en uitval van services. Relevante bronnen MOM Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van Service Monitoring and Control? 2. Zijn services en afhankelijke componenten geïdentificeerd voor service monitoring? 3. Is er een health model opgesteld voor iedere gemonitorde service? 4. Wordt voor het continue monitoren van services gebruik gemaakt van een system management tool of vergelijkbare applicatie? 5. Zijn oplossingen en / of workarounds beschikbaar voor optredende alerts en events? 6. Wordt voor het afhandelen van alerts gebruik gemaakt van een Incident Management proces? 7. Worden alerts automatisch weggeschreven als incident record? 8. Wordt bij het vaker voorkomen van eenzelfde alert / incident een Problem Management proces gestart? 9. Is er een proces aanwezig voor Service Monitoring en Control en is deze gedocumenteerd? 10. Wordt de performance van het monitoren gemeten en geëvalueerd aan SLAs en KPI‘s? 11. Is er één persoon / team verantwoordelijk voor Service Monitoring and Control?

Directory Service Administration Directories worden gebruikt voor het centraal opslaan en doorzoeken van data. Voorbeelden van een directory zijn de telefoongids, de gouden gids, een Active Directory, etc. De Directory Service Administration SMF heeft als doel informatie beschikbaar te maken over het netwerk voor ieder geautoriseerd persoon. Naast het proces voor het zoeken van informatie zijn hiervoor verschillende beheersprocessen nodig. Directory Service Administration geeft hier een invulling aan. Relevante bronnen Gebruikte directories


56

Vragen 1. Zijn gebruikte directories geïdentificeerd en gedocumenteerd (doel, inhoud, locatie, verantwoordelijke personen, etc)? 2. Worden directories gemonitord en incidenten afgehandeld volgens een Incident Management proces? 3. Worden directories periodiek gebackupped? 4. Gebeurd het maken en restoren van een back-up volgens een plan en is deze getest? 5. Zijn er processen aanwezig voor het monitoren en beheren van directories en zijn deze gedocumenteerd? 6. Worden plannen en procedures op periodieke wijze of event-driven geëvalueerd en zonodig aangepast? 7. Is er één persoon / team verantwoordelijke voor Directory Service Administration?

Network Administration Het doel van Network Administration is het aanreiken van enkele best practice processen voor het dagelijkse beheer van netwerkomgevingen. Het dagelijkse beheer omvat het plannen en realiseren van uitbreidingen aan het netwerk en het leveren van support voor het oplossen en repareren van fouten binnen de netwerk omgeving. Vragen 1. Worden alle netwerkcomponenten continue gemonitord en opgetreden indien nodig? 2. Worden netwerkincidenten verlopen volgens een Incident Management proces? 3. Wordt de veiligheid van het netwerk op periodieke wijze of event-driven wijze geëvalueerd? 4. Zijn er processen voor het beheren van het netwerk en zijn deze gedocumenteerd? 5. Is er één verantwoordelijk persoon of team aangewezen voor Netwerk Administration?

Storage Management Storage Management ondersteunt de organisatie met het leveren van ruimte voor opslag van data. Dit brengt verschillende verantwoordelijkheden met zich mee o.a. design en opstellen van plannen voor het opslaan, backuppen en restoren van data, monitoren van data, troubleshooting, garant staan voor de veiligheid van data, etc. Relevante bronnen Batch jobs Procedures Back-up / recovery plannen Vragen 1. Is aanwezige data geclassificeerd (user data / company data, business impact)? 2. Wordt er op periodieke wijze een back-up gemaakt van de data? 3. Is er een voor het maken van backups, restores en recoveries een plan opgesteld en getest (hoeveelheid, locatie, schedules, mogelijke failures, etc)?


57

4. Wordt het maken van backups en de gebruikte back-up resources gemonitord (performance, availability, capacity)? 5. Worden storage incidenten afgehandeld volgens het Incident Management proces? 6. Worden aanpassingen aan de storage infrastructuur afgehandeld door het Change Management proces? 7. Worden storage plannen geëvalueerd en zonodig bijgesteld (perodiek / eventdriven)? 8. Zijn er processen aanwezig voor het monitoren en maken van backups, restoren van data en recovery procedures en zijn deze gedocumenteerd? 9. Is er één persoon / team verantwoordelijk voor Storage Management?

Job Scheduling Batch jobs kenmerken zich in de hoeveelheid benodigde data en resources voor het draaien van de batch job, bijvoorbeeld het maken van rapportages en het uitdraaien van facaturen. Om systemen te ontzien en het gebruikersgemak hoog te houden worden dergelijke jobs veelal in de avond / nacht uren gedraait wanneer de meeste resources beschikbaar zijn. Job Scheduling houdt zich bezig met het beheer, monitoren, analyse en implementatie rondom batch jobs. Relevante bronnen Huidige batch processen en schedules Vragen 1. Wordt er gebruik gemaakt van batch jobs binnen de organisatie? 2. Zijn details van de batch jobs gedocumenteerd / verzameld (beschrijving, eigenaar, stappen, tijd, frequentie, recovery steps, etc)? 3. Wordt er gebruik gemaakt van tools voor het managen van batch processen? 4. Worden incidenten afgehandeld volgens een Incident Management proces? 5. Worden veranderingen in de batch schedule afgehandeld volgens een Change Management proces? 6. Worden resources en de performance van resources gemonitord en gerapporteerd? 7. Worden batch processen en de batch schedule geanalyseerd en geoptimaliseerd? 8. Zijn er processen aanwezig voor het beheren van batch processen en zijn deze gedocumenteerd? 9. Is er één persoon / team verantwoordelijk voor Job Scheduling?

Service Desk Een service desk is een centrale plek voor het afhandelen van contact met de omgeving. Hierbij moet gedacht worden aan contact via de telefoon, internet, fax, een balie etc. Calls komen bij de service desk binnen die vervolgens zorgen voor een juiste afhandeling. Dit kan de service desk zelf afhandelen of toewijzen aan derde personen / teams. Doormiddel van centrale systemen, bijv. CMDB, incident logging, call logging en CRM, blijft de service desk op de hoogte van de nieuwste informatie. Relevante bronnen Call log tools


58

CMDB Incident / Service request tools. Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van een Service Desk? 2. Worden call’s naar de service desk geregistreerd en gemonitord met behulp van een call logging applicatie? 3. Welke methoden kunnen worden gebruikt voor het doen van calls? 4. Worden incidenten door de service desk opgenomen in de incident logging tool? 5. Heeft de service desk de mogelijkheid gebruik te maken van de CMDB en bekende oplossingen en workarounds voor problemen? 6. Rapporteert de service desk over de hoeveelheid binnengekomen calls en hun eigenschappen? 7. Wordt er binnen de service desk gebruik gemaakt van templates (bijv. rapportages, calls, etc)? 8. Wordt er bij het plannen van de service desk rekening gehouden met pieken en dalen van calls en zijn resources aanwezig om dit op te vangen? 9. Zijn er processen aanwezig voor de service desk en zijn deze gedocumenteerd? 10. Wordt de performance van de service desk gemeten en geëvalueerd aan SLA’s en KPI‘s? 11. Is er één persoon / team verantwoordelijk voor de Service Desk?

Service Request & Incident Management Het draaiende houden van een IT omgevingen houdt in dat incidenten verholpen moeten worden en service request afgehandeld moeten worden. Een incident wordt omschreven als een gebeurtenis die niet in het normale verloop van een service thuishoort en oorzaak kan zijn van een onderbreking of vermindering van de kwaliteit van de service. Incidenten moeten zo snel mogelijk verholpen worden om de SLA na te komen. Een voorbeeld van een incident is een server die uitvalt, een restart is snel nodig om de maximale downtime niet te overschrijven. Service Request zijn verzoeken van klanten voor het uitvoeren van bepaalde acties, bijvoorbeeld starten van een batch job, updaten van software, een password reset, een vraag om informatie, installatie van een nieuw system, etc. De mogelijke service requests zijn opgenomen in de SLA. Relevante bronnen Systeem voor het opslaan van incident records en service requests Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van Service Request & Incidentent Management? 2. Is er een systeem aanwezig voor het opslaan, bijhouden en monitoren van incidenten / service requests? 3. Wordt bij binnenkomst van een Incident nagegaan of een dergelijk incident / service request eerder is voorgekomen en een oplossing bekend is? 4. Worden incidenten en service requests geprioritiseerd (impact en urgentie) / geclassificeerd (door één persoon / team)?


59

5. Wordt er binnen Service Request & Incident Management gebruik gemaakt van templates (RFCs, RFIs, rapportages, etc)? 6. Worden incidenten toegewezen aan specifieke personen / teams wanneer geen oplossing voorhad is? 7. Wordt er onderscheid gemaakt tussen normale en major incidenten? 8. Wordt na het afhandelen van een incident / service request contact opgenomen met de initiatiefnemer van het incident? 9. Wordt het afhandelen van incidenten / service requests gemeten en vergeleken met SLA’s en KPI‘s (periodiek / event-driven)? 10. Wordt het afhandelen van incidenten / service requests geëvalueerd met de klant? 11. Is er een proces voor het detecteren, opslaan, classificeren, analyseren en oplossen van incidenten en is deze gedocumenteerd? 12. Is het proces voor het afhandelen van service requests gelijk aan het proces voor incidenten? 13. Is er één persoon / team verantwoordelijk voor de Service Requests & Incident Management?

Problem Management Problem Management heeft te maken met het vinden van oplossingen voor de problemen die te grondslag liggen aan incidenten. Binnen Incident Management wordt een incident binnen zo kort mogelijke tijd verholpen zodat er een minimale onderbreking van de service plaatsvindt. Problem Management analyseert de incidenten en zoekt naar de achterliggende problemen om te voorkomen dat incidenten opnieuw optreden. Relevante bronnen Systeem voor het opslaan van problem records Vragen 1. Worden incidenten of vaak voorkomende incidenten gezien als problemen? 2. Wordt er gebruik gemaakt van een applicatie voor het opslaan, bijhouden, monitoren en raadplegen van problemen? 3. Worden problemen geprioritiseerd (impact / urgentie) / geclassificeerd? 4. Worden nieuwe incidenten gekoppeld aan openstaande problem records? 5. Wordt er binnen Problem Management gebruik gemaakt van templates (beschrijving en status probleem, opsomming van voorgekomen problemen, oplossing voor een probleem, etc)? 6. Wordt er onderscheid gemaakt tussen normale en major problemen? 7. Is er een proces voor het identificeren, opslaan, analyseren, reviewen en oplossen van problemen? 8. Wordt het oplossen van problemen gemonitord en geëvalueerd (periodiek / eventdriven)? 9. Is er één persoon / team verantwoordelijk voor Problem Management?


60

Service Level Management Het doel van Service Level Management is het succesvol aanbieden van IT Services en bestaande overeenkomsten te onderhouden en verbeteren. Centraal in Service Level Management staat de Service Level Agreement (SLA) waarin alle afspraken met de klant zijn opgenomen. Aan de hand van de SLA wordt vervolgens een dienst geleverd en gemeten, rapportages gemaakt en reviews gehouden voor het verbeteren van de dienst. Relevante bronnen Service Level Agreements Rapportages Contracten Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van service level agreements? 2. Zijn de IT service behoeften van de klant gedocumenteerd? 3. Worden de te leveren services en overeengekomen KPI‘s vastgelegd in een SLA? 4. Wordt de SLA met de klant geëvalueerd en herzien (periodiek / event-driven)? 5. Worden geleverde diensten vergeleken met SLA’s en acties ondernomen wanneer nodig? 6. Wordt de levering van diensten gerapporteerd naar klanten (periodiek / eventdriven)? 7. Wordt de levering van diensten geëvalueerd met de klant (periodiek / event-driven)? 8. Is er een proces voor het overeenkomen, uitvoeren en evalueren van SLA’s? 9. Is er één persoon / team verantwoordelijk voor Service Level Management

Capacity Management Het doel van Capacity Management is het optimaliseren van de IT infrastructuur capaciteit en de ondersteunende organisatie zodat een kost efficiënte en constant availability van services gegarandeerd kan worden. Het analyseren en optimaliseren van de IT infrastructuur is een continue proces wat door Capacity Management ingevuld wordt. Relevante bronnen CDB Capacity Plan Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van Capacity Management? 2. Zijn de huidige services geïdentificeerd en details en requirements gedocumenteerd (doel, resources, kosten, workload, plan, etc)? 3. Wordt de capacity van services en componenten gemonitord? 4. Wordt capacity data en incident data geanalyseerd op trends en mogelijke incidenten in de toekomst? 5. Worden aanpassingen aan capacity componenten uitgevoerd onder Change Management? 6. Wordt het capacity plan op periodieke wijze geëvalueerd en herzien?


61

7. Is er één persoon / team verantwoordelijk voor Capacity Management?

Availability & IT Service Continuity Management De eisen aan de beschikbaarheid van IT schieten omhoog. 24x7 is hedendaags een doodnormaal begrip en binnen SLA‘s vreemd. Dit vergt echter de nodige maatregelen om ook daadwerkelijk services 24x7 aan te bieden. Availability management houdt zich bezig met de dagelijks risico‘s die de availability van services bedreigt, bv stroomuitval, hardware failures, etc. IT Service Continuity Management houdt zich bezig met de uitzonderlijke risico‘s, bv brand, aardbevingen, lekkages, diefstal, etc. Relevante bronnen SLA‘s Continuity plan Vragen 1. Wordt er binnen de organisatie aandacht besteed aan availability en continuity? 2. Wordt de availability van geleverde services afgestemd met de klant en opgenomen in de SLA? 3. Zijn availability risico‘s en countermeasures voor services en componenten geïdentificeerd? 4. Worden availability risks op periodieke wijze geëvalueerd en zonodig aangepast? 5. Zijn recovery oplossingen voor geïdentificeerde availability risks aanwezig en getest? 6. Wordt de availability van services gemonitord? 7. Wordt de availability gerapporteerd, geëvalueerd en zonodig actie ondernomen (periodiek / event-driven)? 8. Wordt (historische) availability data opgeslagen voor trend analyse?

9. Wordt er onderscheid gemaakt tussen availability en contingency risks? 10. Zijn contingency risks geïdentificeerd? 11. Is er een contingency plan aanwezig en getest in geval van incidenten? 12. Wordt het contingency plan op periodieke en event-driven wijze geëvalueerd en herzien? 13. Wordt op periodieke wijze het contingency plan getest en geëvalueerd voor het verbeteren van het contingency plan?

14. Is er één persoon / team verantwoordelijk voor Availability & IT Service continuity Management?

Workforce Management Werknemers zijn één van de belangrijkste pijlers voor een organisatie. Hierbij komt het aannemen en behouden van personeel evenals het trainen van competenties e.d. kijken. Workforce Management zorgt ervoor dat binnen de organisatie de juiste hoeveelheid en mensen met de juiste competenties komen te lopen voor het leveren van de services.


62

Relevante bronnen Job descriptions Opleidingsplannen Competentieprofielen Vragen 1. Zijn omschrijvingen en competentieprofielen voor geleverde services opgesteld? 2. Zijn competentieprofielen van de werknemers aanwezig? 3. Zijn bovengenoemde competentieprofielen verwerkt in een matrix en gecontroleerd op gaten? 4. Is voor elke werknemer een opleidingsplan aanwezig? 5. Wordt de performance van werknemers periodiek geëvalueerd? 6. Wordt de performance van werknemers geëvalueerd bij klanten? 7. Zijn er procedures aanwezig voor aanname van nieuwe mensen, mensen die de organisatie betreden, opleidingen, etc? 8. Is er één persoon / team verantwoordelijk voor workforce management?

Infrastructure Engineering Infrastructure Engineering heeft te maken met de ontwikkeling en het gebruik van standaarden en policies binnen een organisatie. Door de ontwikkeling van standaarden binnen een organisatie op een centrale plek af te handelen wordt eenheid en duidelijkheid geschapen en voorkomen dat verschillende standaarden ontstaan. Relevante bronnen Intranet CMDB Service Catalog Gemaakte documenten (facturen, voorstellen, SLA‘s, etc) Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van standaarden en policies? 2. Is de IT omgeving in kaart gebracht en vastgelegd welke onderdelen uitgesloten worden van IE? 3. Is er een centrale locatie voor het opslaan van standaarden en policies? 4. Is er één persoon / team, in combinatie met direct betrokken personen / teams bij de te ontwikkelen of aan te passen standaard / policy, verantwoordelijk? 5. Is er een proces gedefinieerd en gedocumenteerd voor de ontwikkeling van standaarden en policies? 6. Worden policies en standaarden geëvalueerd en zonodig aangepast (periodiek / event-driven)?

Team model Binnen een organisatie worden verschillende rollen onderkend, elke rol heeft zijn eigen taken en verantwoordelijkheden, meerdere mensen kunnen dezelfde rol vervullen en meerdere


63

rollen kunnen door één persoon vervuld worden. Het Team model van MOF reikt een logische opdeling qua rollen aan voor een IT beheerorganisatie. Vragen 1. Wordt er binnen de organisatie gebruik gemaakt van een rol verdeling voor het toekennen van taken aan personen? 2. Welke rollen worden onderkend binnen de organisatie?

Begrippenlijst Begrip

Verklaring

Access Control

Access and privileges granted to users so that they can perform certain authorized functions on a system. A notification that an operational event requiring the attention may have occurred. An alert is generated when monitoring tools and procedures detect that something has happened (at the service, service function, or component level). The amount of time an application is available to perform work, typically measured in percentage uptime. The method by which users prove to the system that they are who they claim to be. Authentication is used in passwords, smart cards, biometrics, and so forth. A documented plan detailing how a specific change, or release, can be undone after being applied, if deemed necessary. The term is most commonly used to refer to a copy of all the files on a computer‘s disks that is made periodically and kept on magnetic tape or other removable medium (also called a ―dump‖). A call is any communication by a customer to the service desk, regardless of the method of communication (telephone, e-mail, voice-mail, and so on). A capability that is required for delivering the agreed-upon performance at the required service level and cost. Contains the detailed technical, business and service level management data that supports the capacity management process. The resource and service performance data in the database can be used for trend analysis and for forecasting and planning. The consolidated output of a capacity management process. The capacity plan documents current levels of resource utilization and service performance. After considering business requirements, it forecasts future resource requirements for IT services to support them. The capacity plan recommends the resource levels and changes necessary to accomplish operating level requirements that support the service level agreement (SLA). The capacity plan includes the cost and benefit of those resources, reports of their compliance to the IT SLA, and the priority and impact of systems and resources on the overall business and the IT infrastructure. Capacity Management Database The administration resources required to perform the tasks and procedures are centrally located. All computing resources being managed are located centrally in the corporate data center (sometimes called the computing center or corporate technology center). All or most of the operations and support functions centrally located in a single site.

Alert

Availability Authentication

Backout Plan Back-up

Call Capacity Capacity Management Database (CDB) Capacity Plan

CDB Centralized administration Centralized hardware Centralized Hardware Centralized Administration Centralized Hardware Distributed Administration Change

Confidentiality

/

/

Administration of centralized data is provided globally seven days a week, twenty-four hours a day by transferring the responsibility for this support to different regions around the world as some offices close for the day and others open. Any new IT component - hardware, software, system components, services, documents or processes - deliberately introduced to the new IT environment that may affect an IT service level or otherwise affect the functioning of the environment or one of its components. A component of encryption. Confidentiality mechanisms help to ensure that only authorized people can see data stored on or traveling across the network.


64

Configuration Control Configuration (CI)

/

For example encryption, digital certificates, VPN, firewalls, etc. Activities that control changes to configuration items. They include evaluation, coordination, approval, or rejection of changes An IT component that is under configuration management control. Each CI can be composed of other CIs. CIs may vary widely in complexity, size, and type, from an entire system (including all hardware, software, and documentation) to a single software module or a minor hardware component. A database that contains all relevant details of each configuration item (CI) and details of the important relationships between CIs. The database can include ID code, copy and serial number, category, status, version, model, location, responsibility, or historical information about the item. The level of detail contained in this database depends either on the aims or on the degree to which information needs to be available. A tested plan, documenting the actions to be taken and implemented in the event of a disaster. Actions taken to prevent or reduce the effect of an identified risk Data recovery is the process of completely restoring data to the state it was in at some prior point in time. Day-to-day administration entails managing and providing operational support for various elements within the environment, such as network accounts (users, groups, distribution lists, and so on) and network resources (servers, printers, storage devices, and so on) The introduction of a release into the IT environment. A collection of computer files. Most common in systems that have a graphical user interface (GUI) and provide a graphical file browser in which directories are traditionally depicted as folders (like small briefcases). Although systems may be distributed to remote locations, all major administrative control remains at the central location.

/ &

The primary administrative function and administrative workforce reside at the corporate (central) data center—all administrative direction and control originate from this function

/

Relies on full support resources located in the remote sites or branch offices to perform the support function of systems distributed to those sites.

item

Configuration Management Database (CMDB)

Contingency plan Countermeasures Data Recovery Day-to-Day Administration

Deployment Directory

Distributed Hardware Centralized (Remote) Administration Distributed Hardware Centralized Delegated Administration Distributed Hardware Distributed Administration Event

Health model

Identification

Impact Incident

Integrity

Job description Job Scheduling

Major Incident

An occurrence within the IT environment (usually an incident) detected by a monitoring tool or an application that is consistent with predefined threshold values (within, exceeding, or falling below) that is deemed to require some sort of response or, at a minimum, is worth recording for future consideration. The definition stating what it means for a system to be healthy (operating within normal conditions) or unhealthy (failed or degraded) and the transitions in and out of such states. Any mechanism used to uniquely identify a user or a set of privileges on a system. Identification can be likened to a key. Access control can be likened to a lock. Both the key and lock must match, or ―fit‖, in order to gain access. A measure of how the incident or service request affects a customer or the business An incident is an event that is not part of the standard operation of a service and which could cause an interruption to or a reduction in the quality of service. Data integrity mechanisms ensure that data is not garbled, modified, or lost during transmission across a network. Data integrity mechanisms also help to ensure that the data is from the intended sender, and not from an impostor. Data integrity mechanisms include checksums and digital signatures. The analysis of the essential factors of a particular job or task and the qualifications and training needed to carry it out. Job Scheduling involves the continuous organization of jobs and processes into the most efficiënt sequence, maximizing system throughput and utilization to meet SLA requirements. An incident with a high impact, or potentially high impact, which requires a response that is above and beyond that given to normal incidents. Typically,


65

Major Problem

Network

Nonrepudation

Policy

Problem RBAC Recovery Release

Request for Change (RFC) RFC RFI Restore Security Controls Security Policy

Security Risk

Service Service Catalog Service Desk

Service Level Agreement (SLA) Service Request

these incidents require cross-company coordination, management escalation, the mobilization of additional resources, and increased communications. A problem with a high impact or potentially high impact, which requires a response that is above and beyond that given to ―normal‖ problems. The timescale available in which to plan a resolution to a major problem is normally longer compared to a major incident, which often requires an immediate response. This means that it is better to treat the issue as a proactive requirement and manage it as a problem management issue. If the problem is left to incident management, there is a risk of it not being progressed since it lacks the immediacy of other incidents. An example of a past major problem is the year 2000 issue. Typically these problems require cross-company coordination, management escalation, the mobilization of additional resources, and increased communications inwardly and outwardly. Techniques, physical connections, and computers programs used to link two or more computers. Network users are able to share files, printer, and other resources; send electronic messages; and run programs on other computers. Nonrepudiation is the security concept that applies to proving the transmission of a particular message. If a system does technical nonrepudiation, then the sender of a message cannot later deny having sent the message. Furthermore, if the message contains contractual information, the presence of a digital signature with the message can often be used to assert that the contractual information was not improperly altered. A defined process or set of procedures within a particular infrastructure category. For example, policies might be established for: hardware purchasing processes, managing change approvals, messaging security. The policies in place will ensure that the infrastructure complies with the overall strategy and accepted procedures of the organization. The undiagnosed root cause of one or more incidents. Role Based Access Control Recovery is the process of completely restoring data to the state it was at some prior point in time. Within the context of MOF, a release is any change, or group of changes, that must be incorporated into a managed IT environment. These changes are packaged into a single release. This is the formal change request, including a description of the change, components affected, business need, cost estimates, risk assessment, resource requirements and approval status. Request for Change Request for information Restore is the process of retrieving data (a single file or many files) from a storage medium to a target location (typically a hard disk). A variety of processes, procedures, or tools for reducing risk to an acceptable level. The term policy represent a variety of written sources that direct security practices within an organization. Policies are statements that reflect an organizations attitude toward security and how it affects the organization, or that detail specific security issues. Policies are usually broad statements that cover general security concerns. The term risk refers to the probability of an event occurring, and its consequences. Risk can be assessed using quantitative or qualitative measures. The process of assessing a risk identifies the risk and its impact on an organization or group. And organization can manage risk by determining an acceptable level of risk, assessing the current level of risk, taking steps to reduce the risk to the acceptable level, and maintaining that level of risk. In the context of the Service Monitoring and Control SMF, a service is a function that IT performs for or with the business. A comprehensive list of services, including priorities of the business and corresponding SLAs. A function that provides the vital day-to-day contact point between customers, users, IT Services, and third-party organizations. The service desk not only coordinates the incident management process, but also provides an interface to many other IT processes. A written agreement documenting the required levels of service. The SLA is agreed on by the IT service provider and the business, or the IT service provider and a third-party provider. A service request is a request for new or altered service. The types of service


66

Solution Standard

Threat Urgency Workaround

requests vary between organizations, but common ones include requests for change (RFCs), requests for information (RFI‘s), and service extensions. A solution / permanent fix is an identified means of resolving an incident or problem that provides a resolution for the underlying cause. A standard within this SMF is defined as a set of criteria or configurations applied within a company. Whereas policies are frequently processes applied to human activities, standards are frequently lists of requirements that apply to technologies. Examples of standards created for specific categories might include: access policies and standards, business case standards, contract policies and standards, etc A potential cause of an unwanted impact to a system or organization. The timescale within which the incident or problem should be resolved. The workaround is an identified means of resolving a particular incident by allowing normal service to be resumed; however, it does not actually resolve the issue that caused the incident in the first place.


67

Bijlage 2 -

Interview resultaten

In deze bijlage zijn de resultaten van de interviews opgenomen. In de onderstaande antwoorden zijn alle namen van medewerkers verwijderd en vervangen door de algemene benamingen, persoon 1..7, operationele medewerker, technische directeur en commercieel directeur.

Change Management IT omgevingen zijn onderhevig aan veranderingen. Onderdelen werken niet naar behoren, nieuwe updates zijn aanwezig, requirements aan systemen zijn verandert etc. Het doel van Change Management is het afhandelen van veranderingen met minimale interruptie van de normale gang van zaken. Centraal binnen elke iteratie van het Change Management Process is de Request voor Change (RFC) waarin alle details van de betreffende change zijn opgenomen. RFC‘s worden opgesteld vanuit de organisatie, bijvoorbeeld na aanleiding van een service request, of direct vanuit de klant. Relevante bronnen Systeem voor het opslaan, bijhouden en monitoren van RFC‘s Vragen 14. Wordt er binnen de organisatie gebruik gemaakt van Change Management? Persoon 1: Persoon 2: Ja Persoon 3: Ja, service request zie ik als request die binnen het contract vallen, RFC zie ik als request die buiten het contract vallen. Persoon 4: Het zit in de manier van werken maar is niet als dusdanig beschreven. Met Ten Cate heb ik een klein proces afgestemd Persoon 5: Niet echt. Er zijn wel RFC templates, deze zijn ook aan de klant gegeven, echter ze worden niet gebruikt. RFC’s zijn meer mondelinge afspraken of mails tussen klanten en The Backbone. RFC’s vallen buiten het contract. Per klant verschillende de changes en worden de changes door verschillende personen afgehandeld. Persoon 6: Nee, niet in de vorm van een proces. Ik werk er niet mee Persoon 7: Ja, er zijn vragen van klanten voor wijzigingen. Er wordt geen gebruik gemaakt van RFC’s, vaak betreft het een mondelinge afstemming. Afhankelijk van de change wordt er overlegd met de commerciële mensen (nieuwe installatie, server) of de change ook daadwerkelijk wordt uitgevoerd. Structurele wijzigingen vallen niet binnen het contract, de overige changes wel. Hierbij moet ik zeggen dat dit wel aan het contract van de klant ligt. 15. Is er een systeem aanwezig voor het opslaan en bijhouden (status, verantwoordelijk persoon, etc) van RFCs? Persoon 1: Ja, sinds kort een freeware helpdeks in gebruik Persoon 2: Ja helpdesk tool, wordt niet consequent gebruikt Persoon 3: Nee Persoon 4: Wordt opgenomen in de helpdesk tool Persoon 5: Nee Persoon 6: Ja, mail (outlook mailbox) Persoon 7: Het helpdesk pakket, ik weet niet of iedereen het doet maar in principe is het zo dat alles wat binnenkomt hierin wordt gezet. 16. Worden RFCs vooraf gecontroleerd op volledigheid, duplicaten en haalbaarheid en zonodig teruggestuurd naar de initiatiefnemer? Persoon 1: Ja Persoon 2: ? Persoon 3: RFC komen vaak tijdens een gesprek met de klant aanbod. Hierbij wordt gelijk de haalbaarheid e.d. besproken. Hierna wordt er geen RFC op papier opgesteld, de RFC blijft in het hoofd zitten.


68

Persoon 4: Nee, mondeling wordt dit afgestemd voordat de RFC in het helpdesk pakket wordt opgenomen. Persoon 5: Was wel de opzet, in praktijk wordt er tijdens mondelinge afspraken over gesproken. Persoon 6: ? Persoon 7: Dit gebeurd tijdens de mondelinge afstemming. 17. Worden RFCs gecategoriseerd en geprioritiseerd (door één vast persoon / team)? Persoon 1: Te weinig, eigenlijk niet. Cultuur probleem Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee, mondeling / informeel gebeurt dit wel Persoon 5: Wat ik mee maak is alles prioriteit 1 Persoon 6: Nee Persoon 7: Ja, categorieën zijn: software, hardware en wijziging in de netwerk structuur. Prioriteiten: hoe dringt is het nodig. Het is niet zo dat op basis van een categorie / prioriteit een persoon wordt toegewezen. 18. Welke triggers worden naast RFCs gebruikt voor uitvoeren van het Change Management Proces (vb nieuwe updates)? Persoon 1: Persoon 2: Ja Persoon 3: Geen, updates e.d. vallen binnen en het contract en zijn daarom geen changes Persoon 4: Updates van Microsoft, fireware en driver update runs zou eigenlijk moeten, zijn we mee bezig in geval van Ten Cate (dit gebeurt meer reactief). Persoon 5: Updates vallen onder het onderhoud dat The Backbone uitvoert voor de klanten. Afhankelijk van de update kan het dan een change of een service request zijn. Persoon 6: Microsoft updates Persoon 7: MOM meldingen, bijvoorbeeld dat een schijf volloopt. 19. Bestaat er een verschil in afhandeling tussen RFCs van verschillende categorie / prioriteit? Persoon 1: Nee Persoon 2: ? Persoon 3: Nee Persoon 4: Kleine changes met weinig impact worden snel uitgevoerd. Bij enkele klanten zijn er onderhoudswindows afgesproken voor het uitvoeren van changes. Persoon 5: Alles heeft dezelfde prioriteit en wordt direct uitgevoerd. Persoon 6: Dit ligt aan de ernst van de change, als het iets eenvoudigs is kan het langer blijven liggen. Belangrijke dingen wordt gelijk gedaan, andere changes worden eerste maandagochtend besproken Persoon 7: Geen verschil, het ligt er maar net aan wie er tijd voor heeft. 20. Worden changes geaccordeerd voor het Change Management proces verder wordt doorlopen? Persoon 1: Persoon 2: Ja, moet afstemming plaatsvinden, consequent is moeielijk te zeggen Persoon 3: De accodatie vindt plaats tijdens het gesprek gelijk plaats Persoon 4: Formeel is hier niks voor geregeld. Mondeling wordt dit wel met de klant afgestemd op het moment dat met de klant wordt gesproken en de klant om de change vraagt. Persoon 5: Nee, in principe gaat alles via de contactpersoon van de klant waardoor de accodatie stap wegvalt. Digid is hierop een uitzondering. Alle gebruikers mailen als ze een change willen, hierop vindt geen accodatie plaats. Persoon 6: Ja, de contactpersoon van de klant Persoon 7: Denk het wel, weet het niet zeker. Er is in ieder geval geen papier wat ondertekend moet worden, het gebeurd eerder via de mail.


69

21. Is er een planning van aankomende changes beschikbaar binnen de organisatie? Persoon 1: Persoon 2: ? Persoon 3: Nee Persoon 4: In het helpdesk pakket zijn dingen opgenomen, voor enkele klanten zijn vaste onderhoudswindows afgesproken. Deze staan op het planbord. Persoon 5: Van een aantal klanten liggen updates e.d. vast in de planning, enkele klanten hebben een onderhoudswindow, en bij andere gebeurd het ad hoc na een melding. Dit is dus per klant verschillend. Persoon 6: Ja, de outlook agenda en daarnaast het plan bord voor vast onderhoud Persoon 7: Ja, als er changes zijn wordt dit ingepland op het planbord (de mensen worden ingepland). 22. Zijn templates aanwezig voor Change Management? Persoon 1: Persoon 2: Nee Persoon 3: Ja voor een RFC Persoon 4: Nee hier wordt geen gebruik van gemaakt. Er is wel een opzet beschreven in een voorstel echter wordt hier geen gebruik van gemaakt. Klanten ervaren het soms ook niet als gewenst door de rompslomp die hierdoor ontstaat. Persoon 5: Niet Persoon 6: Ja deze zijn er wel maar heb ik niet bekeken Persoon 7: Nee 23. Worden relevante personen op de hoogte gehouden over de status van RFCs (periodiek / event-driven)? Persoon 1: Nee, niet tussendoor, aan het einde wellicht Persoon 2: Nee, dingen worden geconstateerd echter terugkoppeling met de klant wordt niet gedaan. Klant weet niet wat er gebeurd. Persoon 3: Niet periodiek, intern wordt er wel over gesproken zodat er ook toetsing plaatsvindt. Bij een klant gebeurt het alleen event-driven. Persoon 4: In het geval van kleine changes wordt er voor Ten Cate een Excel sheet bijgehouden. Deze wordt na elke aanpassingen naar Ten Cate gemaild. Buiten Ten Cate gebeurd dit veelal per mail of tijdens een mondeling overleg. Er is geen standaardisatie hiervoor. Persoon 5: Ja, periodiek en event-driven. Bij sommige klanten worden change besproken tijdens de periodieke gesprekken die plaatsvinden. Het kan echter ook gebeuren dat er pas naar afhandeling contact opgenomen wordt, dit is per telefoon of mail. Persoon 6: Ja, via mail, sommige klanten periodiek en andere event-driven. Het ligt er ook maar net aan wat de klant wil. Wij willen er in ieder geval naar toe dat alles op periodieke basis gebeurd. Persoon 7: Soms, als ik bijvoorbeeld een change overneem van iemand anders houdt ik hem op de hoogte. Sommige klanten vragen er ook om om op de hoogte gehouden te worden, bijvoorbeeld bij Ten Cate wordt bij elke wijziging een CC verstuurd. Alles gebeurd wel event-driven. 24. Zijn er processen voor het identificeren, vastleggen, analyseren, implementeren en reviewen van een RFC en zijn deze gedocumenteerd? Persoon 1: Nee, ad hoc, komt binnen en wordt afgehandeld Persoon 2: Nee Persoon 3: Geen structuur, het is een klein bedrijf wat eigenlijk maar uit één laag bestaat, een proces is dus lastig. Daarnaast zou een proces overkill zijn vanwege de bedrijfsomvang. Afhankelijk van de persoon kan er enige structuur zijn. Persoon 4: Nee, er is een voostel geschreven voor een Change Management Proces echter dit is niet van de grond gekomen binnen de organisatie. Persoon 5: Nee Persoon 6: Op dit moment niet, ad hoc Persoon 7: Nee


70

25. Wordt het afhandelen van RFCs gemeten en geëvalueerd met SLAs? Persoon 1: Niet structureel Persoon 2: Nee, Weinig inzicht in contracten Persoon 3: Nee Persoon 4: Er zijn wel SLA’s deze zijn alleen op een dergelijk hoog niveau dat er niks in staat over responsetijden e.d. Het evalueren van RFC’s aan de SLA is dus niet mogelijk. Persoon 5: Nee Persoon 6: Ja maar niet bewust behalve bij de reclassering Persoon 7: Volgens mij niet 26. Is er één persoon / team verantwoordelijk voor Change Management? Persoon 1: Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee / iedereen is verantwoordelijk. Er is geen sturing alleen het maandagochtend overleg waarin soms changes naar voren komen en er wat advies gegeven wordt. Persoon 5: Nee Persoon 6: Directie, eindverantwoordelijke Persoon 7: De persoon die het uitvoert is verantwoordelijk voor die ene change.

Release Management Release Management is verantwoordelijk voor de release van de Changes ontwikkeld onder Change Management. Release Management maakt een planning, ontwikkeld en test een release package en voert de daadwerkelijke release uit. Vragen 12. Wordt er binnen de organisatie gebruik gemaakt van Release Management? Persoon 1: Persoon 2: Persoon 3: Nee releases worden niet gezien als een afzonderlijk proces maar zijn geïntegreerd bij de changes. Persoon 4: Persoon 5: Nee Persoon 6: Nee Persoon 7: Ja, maar geïntegereerd met Change Management 13. Is Release Management geïntegreerd met Change Management binnen de organisatie? Persoon 1: Persoon 2: Persoon 3: Persoon 4: Zit binnen change management Persoon 5: Ja Persoon 6: Ja Persoon 7: Zie vraag 1 14. Wordt er voor iedere release een planning opgesteld? Persoon 1: Persoon 2: Persoon 3: Ja, voor een aantal klanten zijn er vaste tijden opgesteld (onderhoudswindows). In het geval van andere changes / releases wordt een aparte planning opgesteld. Persoon 4: Voor kleine releases niet (bijvoorbeeld updates), changes met grote impact worden met de klant afgestemd of worden aangekondigd. Persoon 5: Zie de change planning vraag Persoon 6: Ja meestal wel Persoon 7: Dit is hetzelfde als de change planning


71

15. Worden gelijktijdig geplande releases gebundeld? Persoon 1: Persoon 2: Persoon 3: Ja Persoon 4: Soms wel, verschilt per situatie. Bij klanten met een vast onderhoudswindow worden changes soms gecombineerd. Vaak blijven changes wel gescheiden, bij het combineren van changes kan je tegen het probleem aanlopen dat als het misloopt dat het niet duidelijk is welke change precies misloopt. Voor het verhelpen van problemen is dit niet bevorderlijk. Persoon 5: In het geval er met de klant een onderhoudswindow is afgestemd gebeuren alle releases op dat tijdstip. Er kan dus gezegd wordt dat releases gebundeld worden. Bij klanten zonder onderhoudswindow is dit niet zo. Persoon 6: Bij dezelfde klant worden gereleases gebundeld Persoon 7: Ja, ik denk het wel, dit is ook het makkelijkste. Het ligt wel aan de release, maar vaak is het toch zo dat releases worden verzameld en in één keer uitgevoerd 16. Worden releases getest voor de deployment in de productieomgeving? Persoon 1: Nee Persoon 2: Persoon 3: Nee Persoon 4: Waar mogelijk wel, tenzij de impact heel laag is. Leveranciers hebben software en drivers vaak ook al veelvuldig getest. Bij sommige klanten is een test omgeving aanwezig die gebruikt kan worden, zelf beschikt The Backbone niet over een testomgeving. Een concreet voorbeeld, bij Ten Cate is een testomgeving aanwezig, nieuwe updates e.d. moeten hier eerst uitgerold worden voordat dit daadwerkelijk in de live omgeving mag plaatsvinden. Persoon 5: Nee, vaak is het zo dat changes eerst binnen het eigen netwerk, van The Backbone, wordt uitgerold en hierna pas bij de klant. Onze eigen situatie kan gezien worden als een test. In veel gevallen probeer ik een virtueel systeem op te zetten om de impact van de releases te beoordelen. Als er een onzekerheidsfactor is probeer ik de releases altijd te testen. Persoon 6: Ja en nee, software updates worden vaak wel getest, security updates van Microsoft e.d. worden in een keer uitgerold. Testen is ook niet altijd mogelijk omdat niet van elke productieomgeving een testomgeving aanwezig is. Persoon 7: Als het kan wel, lang niet altijd is er een testomgeving aanwezig. 17. Is er voor elke release een backout plan aanwezig en is deze getest? Persoon 1: Beperkt, niet standaard Persoon 2: Persoon 3: In het geval van software releases is het wisselend of er een plan aanwezig is, soms wel soms niet. Zeker is in ieder geval dat de plannen nooit getest worden. Persoon 4: Niet beschreven, bij grote releases wordt het meegenomen. Bij kleine releases niet, vaak volstaat het met een uninstall. Persoon 5: Nee Persoon 6: Nee Persoon 7: Ook niet altijd 18. Wordt de CMDB aangepast na het succesvol uitrollen van een release? Persoon 1: Niet tijdig, wel als het gebeurd is Persoon 2: Persoon 3: MOM vervult de rol van de CMDB. MOM wordt live geupdate dus dit gebeurd. Persoon 4: Nee voorzover een CMDB aanwezig is. MOM past dingen automatisch aan, maar zie ik niet echt als CMDB. Klanten hebben soms zelf een CMDB, hier hebben wij geen controle over. Persoon 5: Naast WSUS is er geen CMDB.


72

Persoon 6: ? Persoon 7: Ja voorzover er een CMDB is wordt deze aangepast. Het wordt wel eens vergeten 19. Wordt bij de deployment van releases nagegaan of de nodige licenties aanwezig zijn? Persoon 1: Wel Persoon 2: Persoon 3: Ja, dit is zeker een belangrijk punt, we leveren geen illegale software Persoon 4: Ja, is vraag één bij software changes Persoon 5: Bij mijn klanten doe ik dit wel. Persoon 6: Ja Persoon 7: Ja 20. Wordt er binnen Release Management gebruik gemaakt van ondersteunende applicaties? Persoon 1: Nee Persoon 2: Persoon 3: Geen afzonderlijke applicaties als SMS, echter waar kan wordt er wel geautomatiseerd bijvoorbeeld met RIS of Group Policy. Persoon 4: Group policy, WSUS. Bij RRS draait volgens mij SMS maar wordt niet gebruikt. Dit is dus erg klant afhankelijk. Persoon 5: WSUS updates, Group policy Persoon 6: WSUS en Group policy Persoon 7: Group policy wordt gebruikt, voor de rest gebeurd alles handmatig. 21. Zijn er processen voor het plannen, ontwikkelen, testen en uitrollen van releases en zijn deze gedocumenteerd? Persoon 1: Nee Persoon 2: Persoon 3: De uitrol zelf is gedocumenteerd echter niet getest. Of er een vast proces is is afhankelijk van de persoon. In het geval van grote releases wordt er in ieder geval gewerkt in twee verband. Persoon 4: Nee, zeker niet beschreven Persoon 5: Wat ik doe bij updates e.d.: a. Ik kijk welke updates er zijn b. Zijn de updates klaar voor de installatie c. In wsus vindt een accodatie plaats d. Ik maak een copy van het aanverwante knowledge base artikel en zet dit in de het changelog bestand wat op de desktop van de server staat. Of iedereen dit zo dit is niet zeker, het is geen vast proces. Groeit er een beetje in Persoon 6: Ja, maar er staat niks van op papier, of te weinig. Per persoon is de werkwijze ook verschillend. Persoon 7: Nee niet echt 22. Is er één persoon / team verantwoordelijk voor Release Management? Persoon 1: Persoon 2: Persoon 3: Dit wordt onderling verdeelt. Ik ben vaak wel aanwezig bij updates. Persoon 4: Nee Persoon 5: In principe is de contactpersoon binnen The Backbone verantwoordelijk voor de releases bij zijn klant. Daarnaast geldt dat de personen die aanwezig zijn de release gewoon uitvoeren. Persoon 6: Zou wel moeten, of dit zo is weet ik niet Persoon 7: Degene die de change uitvoert

Configuration Management Het doel van Configuration Management is het garanderen dat enkel goedgekeurde componenten, configuration items (hardware, software, documenation, processes,


73

procedures), gebruikt worden binnen de IT omgeving. Gedurende het gebruik van een item worden alle changes opgeslagen en bijgehouden. Binnen het Configuration Management proces worden Configuration Items geïdentificeerd, een Configuration Management Database opgezet en bijgehouden en reviews uitgevoerd om te verzekeren dat de Configuration Management Database overeenkomt met de productieomgeving. Relevante bronnen Bestaande CMDB Bronnen waarin systemen / configuraties worden beschreven Vragen 9. Wordt er binnen de organisatie gebruik gemaakt van Configuration Management? Persoon 1: Ja Persoon 2: Ja, vanuit MOM (als er een agent opstaat) Persoon 3: Ja, MOM doet dit voor ons. Persoon 4: Nee, er is nergens een beschrijving. Er is enkele documentatie van servers / mom omgevingen echter dit is niet uitgebreid met vereiste service pack die geïnstalleerd moeten zijn, vereiste software etc. Server changes worden in een notepad bijgehouden op de desktop van de server (bij de meeste klanten, oost, kienhuis), mocht de server uitfikken of een hd crashen dan is niet meer terug te halen in welke staat de server was, welke software geïnstalleerd was, etc. Persoon 5: Half, er is een aanzet maar deze is zeker niet compleet. Voor iedere klant zijn er Visio tekeningen met de netwerk layout en documenten met welke applicaties en services er op de servers draaien. Ik moet wel zeggen dat het heel lastig is om dit ook daadwerkelijk bij te houden met versie nummers e.d. Hiervoor zij de middelen niet toereikend. Persoon 6: Denk het wel, per klant is er een documentatie map, hier staat in welke software er is, de sla, een netwerk layout, licenties, hardware. Persoon 7: Dit wordt wel gedaan 10. Zijn componenten voor configuration control geïdentificeerdt? Persoon 1: Ja Persoon 2: ? Persoon 3: Alles wat MOM ziet wordt daadwerkelijk meegenomen, misschien is dit wel teveel. Persoon 4: Nee Persoon 5: Voor de servers hebben we Visio tekeningen waar alle servers in staan. Of deze na een change worden aangepast weet ik niet zeker. Daarnaast is er niet een lijst met alle componenten die wel onder configuration control vallen en welke niet. Persoon 6: ? Persoon 7: Nee niet specifiek 11. Is er een configuration management database (CMDB) aanwezig? Persoon 1: Excel en Word documenten voor elke klant. Daarnaast helpt MOM een beetje Persoon 2: MOM database Persoon 3: MOM, daarnaast is er van elke netwerk omgeving een netwerk layout aanwezig die een overzicht geeft van het netwerk, ip-nummers, etc. Persoon 4: Nee Persoon 5: Nee Persoon 6: De map, daarnaast is er niks Persoon 7: In de vorm van documenten, Word en Visio. Technische gegevens van het netwerk, aanwezige servers, wat er op servers draait, ip nummers, serverrollen. 12. Worden de eigenschappen en de status van configuration items (automatisch) bijgehouden? Persoon 1: Nee (ja MOM doet het enigszins) Persoon 2: MOM ziet dit, met beperkingen, ligt eraan MOM agent ziet


74

Persoon 3: MOM doet dit zelf, de netwerk layout wordt bijgehouden. Als er een change heeft plaatsgevonden wordt de netwerk layout afgestemt met de nieuwe situatie Persoon 4: Nee, niet verder dan het notepad bestand en de excel sheet (Ten Cate) Persoon 5: Nee Persoon 6: Nee Persoon 7: Niet automatisch, wel met de hand 13. Wordt de productieomgeving op periodieke basis vergeleken met de CMDB en worden veranderingen gerapporteerd? Persoon 1: Ja, incidenteel / direct Persoon 2: ? Persoon 3: Wat MOM zegt klopt, er vindt daarom geen toetsing plaats. Persoon 4: Nee Persoon 5: Voorzover er een CMDB is doet MOM dit. Op basis van events kunnen we bijvoorbeeld zien of er servers bijkomen, verdwijnen etc. Persoon 6: Nee Persoon 7: Nee niet specifiek, als iemand ermee bezig is wordt vaak wel gekeken of het nog compleet is. 14. Welke toepassingen kent de CMDB binnen de organisatie? Persoon 1: Probleem, vooraf aan een bezoek Persoon 2: Bij migraties zou het gebruikt kunnen worden voor offertes etc. Persoon 3: Geen toepassingen Persoon 4: Geen Persoon 5: De documentatie die er is wordt geraadpleegd wanneer nodig. Persoon 6: Er is niet echt een CMDB Persoon 7: De Service Desk gebruikt het op het moment dat er telefoontjes binnen komen en er informatie nodig is over de omgeving. Daarnaast bij Changes en Releases 15. Zijn er processen voor het selecteren, lezen, aanpassen, verwijderen en reviewen van configuration items en zijn deze gedocumenteerd? Persoon 1: Ja, impliciet niet vastgelegd Persoon 2: ? Persoon 3: Op het moment dat er een nieuwe klant bij komt is er een handleiding van 2 á 3 A4tjes aanwezig waarin stappen beschreven staan die uitgevoerd moeten worden. Voor de rest is er niks aanwezig. Persoon 4: Nee Persoon 5: Er is een soort van stappenplan voor nieuwe klanten en er is een template. Van eenheid of een systeem kun je echter niet spreken. De documenten worden bijgehouden, ik doe het in ieder geval, voor de rest kan ik niet spreken. Persoon 6: Nee Persoon 7: Nee 16. Is er één persoon / team verantwoordelijk voor Configuration Management? Persoon 1: Persoon 2: ? Persoon 3: Nee Persoon 4: Nee, komt er een vraag binnen dan gaat alles in overleg Persoon 5: Nee, als je vind dat het moet gebeuren moet je dit doen. Hier is de organisatie veel te klein voor. Iedereen doet hetzelfde. Persoon 6: Niet echt Persoon 7: Nee, degene die een wijziging maakt

System Administration System Administration heeft te maken met de Day-to-day Administration van de IT productie omgeving. Hieronder valt het operationele beheer van network accounts (users, groups, distribution lists) en network resources (servers, printers, storage devices).


75

Vragen 4. Welke vorm van systeem opzet wordt binnen de organisatie gebruikt? Centralized Hardware / Centralized Administration Centralized Hardware / Distributed Administration (Follow the sun) Distributed Hardware / Centralized (Remote) Administration Distributed Hardware / Centralized & Delegated Administration Distributed Hardware / Distributed Administration Persoon 1: Klant 3 á 4, intern 1, nieuwe situatie 2 Persoon 2: 1 Persoon 3: 3&4 Hardware is gedistribueerd doordat het ook op klant locatie staat. Beheer gebeurt vanuit een centrale plek, The Backbone, en remote bij de klant. Sommige taken, bijvoorbeeld het aanmaken van user-accounts, is gedelageerd. Persoon 4: 4 Functioneel beheer is vaak gedelageerd, wij doen het technische beheer Persoon 5: 3&4 Voor bepaalde klanten doen we alleen monitoring, beheer is in dit geval gedelegeerd. Dit zijn er niet veel. Persoon 6: 3&4 Persoon 7: 3&4 Voor één klant geldt dit niet omdat we er remote niet bij mogen. Een deel van de administratie wordt door de klanten gedaan, dit betreft voornamelijk eerste lijns incidenten (printer werkt niet, iemand kan iets niet vinden in word of outlook). 5. Zijn er processen voor het aanmaken, beheren en verwijderen van network accounts en network resources? Persoon 1: Persoon 2: ?, Een medewerker is het aanspreek punt, geen processen Persoon 3: Niet beschreven, proces is wel aanwezig, echter gebeurt het aanmaken van users e.d. vaak door de systeem beheerder bij de klant zelf. Dit soort taken zijn gedelageerd. Persoon 4: Verschilt van klant tot klant, dit is functioneel beheer en ligt dus vaak bij hun administrator. Voor bijvoorbeeld oost is er afgestemd dat user accounts via de contact persoon per mail worden aangevraagd. Hier wordt bij de andere klanten ook op aangestuurd. Persoon 5: Er is geen vast proces, voor mezelf houdt ik de volgende volgorde aan: a. Er komt een mail of telefoon binnen b. Ik neem het op in het helpdeskpakket c. Ik voer de actie uit Ik breng de klant op de hoogte Persoon 6: Allemaal ad hoc Persoon 7: Nee geen processen, maar wij doen dit zeker wel. Als iemand een account of iets dergelijks nodig heeft wordt deze actie gewoon uitgevoerd, soms wordt het ook gezien als een change. Een impliciet proces is: a. Er komt een aanvraag binnen via mail of telefoon b. De aanvraag wordt in het helpdeskpakket gezet c. Binnen het systeem van de klant wordt gekeken naar de standaard in naamgeving d. De account of resources wordt aangemaakt met dezelfde naamgeving en rechten e. Er wordt een terugkoppeling naar de klant gedaan met de gegevens van het nieuwe account / resources. Vaak gebeurd dit via mail. f. De aanvraag wordt gesloten (hierbij wordt niet gewacht op een reactie van de klant). 6. Is er één persoon / team verantwoordelijk voor System Administration? Persoon 1: Ja het hele team Persoon 2: Een van de operationele medewerkers is verantwoordelijk Persoon 3: Iedereen Persoon 4: Nee, per klant is er een vast contactpersoon maar echt verantwoordelijk is deze niet.


76

Persoon 5: Iedereen is verantwoordelijk. Persoon 6: Iedereen Persoon 7: Degene die het uitvoert, iedereen dus

Security Administration & Management De Security Administration & Management SMF‘s dekken samen alle aspecten op het gebied van security. Van Policies tot daadwerkelijke implementaties en maatregelen op het gebied van security. Aspecten die onder andere bij security naar voren komen zijn de Identification, Authentication, Access Control, Confidentiality, Integrity, Nonrepudiation, Auditing en het opstellen van security policies Relevante bronnen Audits Logs Configuraties Geschreven policies Vragen 10. Zijn services en informatie bronnen geïdentificeerd en geclassificeerd in kritische waarde en vertrouwelijkheid? Persoon 1: Nee Persoon 2: Wel bewust van, daarom bij Virtu, geïdentificeerd en geclassificeerd te zwaar Persoon 3: Ja Persoon 4: Met klanten zijn wel overeenstemmingen gemaakt over kritieke systemen. Dit is echter niet beschreven, ook niet in contracten Persoon 5: Niet gespecificeerd Persoon 6: ? Persoon 7: Denk wel dat er onderscheid wordt gemaakt, bijvoorbeeld documenten waar wachtwoorden in staan. Er zit een wachtwoord op het document. 11. Zijn mogelijke security risks vastgesteld voor services en resources? Persoon 1: Nee Persoon 2: Wel bewust van Persoon 3: Ja, de inrichting is ook gedocumenteerd (intern en bij de klant) Persoon 4: Mondelinge afstemming, op het moment dat er veranderingen bij een klant optreden wordt er in gesprekken gewezen op mogelijke risico’s. Hierover is niks vastgelegd en gebeurd enkel reactief. Persoon 5: Nee, behalve een lijst in het hoofd is er niks. Op basis van ervaring zijn risico’s wel bekend. Persoon 6: Nee Persoon 7: Volgens mij niet 12. Zijn bovenstaande punten vastgelegd in een security policy en wordt deze op periodieke wijze geëvalueerd? Persoon 1: Persoon 2: ? Persoon 3: Ja, evaluatie vindt ook plaats, binnen gesprekken worden punten aangekaart en eventueel aangepast. Intern ook, dit is erin gegroeid. Persoon 4: Verschilt per klant, sommige klanten hebben een technische policy, procedurele policies zijn er niet. Persoon 5: Nee Persoon 6: Nee Persoon 7: Het enige wat wij meestal wel doen is dat als we wachtwoorden in stellen dat dit niet te simpel mag zijn. 13. Welke vormen van security controls zijn geïmplementeerd? Is er een standaard binnen de organisatie voor identification (bijv. usernames)? Persoon 1: Ja


77

Persoon 2: Ja Persoon 3: Usernames, volgens een vaste standaard. Persoon 4: Usernames, volgens een standaard, intern en per klant Persoon 5: Ja, er is een standaard voor usernames. Persoon 6: Intern wel, voor klanten geldt dat dit per klant verschillend is. Persoon 7: Usernames, er is ook een standaard voor. Welke vormen van authentication worden gebruikt binnen de organisatie (passwords, biometrics, smart cards)? Persoon 1: Passwords, Smart cards Persoon 2: Passwords, smartcards van Virtu Persoon 3: Passwords Persoon 4: Passwords, kienhuis gebruikt voor VPN smartcards en pins Persoon 5: Passwords Persoon 6: Passwords Persoon 7: Passwords Welke vormen van access control worden binnen de organisatie gebruikt (RBAC, lockout, limited session use, etc) Persoon 1: RBAC, Lockout Persoon 2: Ja, geen policy Persoon 3: Uiteraad, is in user accounts opgenomen Persoon 4: Verschilt per klant, bij sommige klanten worden sessies beëindigd. Intern is iedereen administrator dus kan dit zelf instellen. Er wordt vanuit gegaan at hier vertrouwd mee om wordt gegaan. Persoon 5: Lockout. Op het management na is iedereen administrator. Persoon 6: Per gebruiker is dit in te stellen, er wordt geen gebruik gemaakt van policies o.i.d., zou wel moeten Persoon 7: Lockout Zijn er technieken geïmplementeerd die confidentiality waarborgen (private key encryption, public key encryption, digitale certificaten, VPN‘s, File system encryption, etc)? Persoon 1: Ja, alle bovengenoemde Persoon 2: VPNs, geen codering Persoon 3: VPN, certificates, geen encrypties (ook eigen data niet) Persoon 4: VPN, lokaal op mijn laptop heb ik enkele geëncrypte mappen. Op de servers is er niks geëncrypt behalve de webmail en de mom to mom connector (SSL). Persoon 5: SSL, certificaten (geen publieke certificaten), VPN, encryptie (servers voornamelijk) Persoon 6: Intern is er niks, naar klanten zijn er VPN’s, voor de webmail is er een certificaten. Persoon 7: Intern is er niks, VPN om bij The Backbone binnen te komen, certifcaat voor webmail Wordt er voorzien in data integrity (checksums, virus scans, etc)? Persoon 1: Ja, alle bovengenoemde Persoon 2: Anti-virus etc, kan altijd beter Persoon 3: Virus-scans, MOM staat erboven en houdt dit ook bij (oneigenlijk gebruik van wachtwoorden etc) Persoon 4: Virus scans Persoon 5: Virus scans Persoon 6: Virus scans, backups Persoon 7: Virus scans Zijn er maatregelen genomen voor nonrepudiation (digital signatures, ontvangstbevestiging)? Persoon 1: Nee Persoon 2: Nee


78

Persoon 3: Nee Persoon 4: Nee Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee Worden uitgevoerde acties gelogd en regelmatig bekeken om ongewenste acties uit te sluiten (auditing)? Persoon 1: Ja Persoon 2: ? Persoon 3: Security audit, MOM voert dit uit, intern en extern Persoon 4: Ja, bij bijna alle klanten staat dit aan. De uitvoer hiervan is zichtbaar in MOM. Persoon 5: Wordt vast bij gehouden, MOM ziet dingen, echt vast gelegd is een goede vraag???. Voor klanten is het mogelijk auditing in te schakelen als deze behoefte er is. Het periodiek bekijken gebeurd doormiddel van MOM. Persoon 6: Nee, voorzover het niet MOM zit Persoon 7: Ja, met MOM. Bestanden e.d. worden niet geaudit maar bijvoorbeeld active directory en policies wel. Welke fysieke security controls worden gebruikt binnen de organisatie? Persoon 1: Pas lezers Persoon 2: Virtu, atoombunker Persoon 3: Ja, alle ruimtes zijn afgesloten en enkel met sleutels / smart cards te bereiken. Persoon 4: Intern worden smart cards gebruikt voor de toegang. Per klant is dit verschillend, maar over het algemeen moet je je melden bij de receptie en zijn de server ruimtes afgesloten. Persoon 5: Het betreden van het pand is alleen mogelijk met een smartcard (beveiliging van Virtu). Iedereen die binnen is kan de monitoring ruimte in. Toegang tot de eigen servers is mogelijk, servers van de klant (bij Virtu) niet. Op locatie van de klant zijn security controls onduidelijk. Persoon 6: Intern de Virtu beveiliging, bij klanten is het afhankelijk van de klant. Er zijn klanten waar je bij de deur wordt opgewacht en anders ook niet binnenkomt. Maar dit is lang niet overal zo. Persoon 7: Intern maken we gebruik van de smartcards van Virtu, bij de klant is het afhankelijk van de klant. Er zijn klanten waar je van te voren moet laten weten dat je komt en je ook daadwerkelijk moet registeren, bij andere klanten kan je zo naar binnen lopen tot het serverhok als je wilt. 14. Worden security controls gemonitord en periodiek gecontroleerd (audits, logs etc)? Persoon 1: Ja Persoon 2: Acties van Virtu Persoon 3: Ja, sleutels werken altijd en worden dus niet gecontroleerd, MOM doet een stukje monitoring aangezien binnen MOM gezien kan worden of deuren opengaan, paslezers gebruik etc. Persoon 4: Via MOM Persoon 5: Ja door MOM Persoon 6: Nee, hebben we zelf niet Persoon 7: Ja met MOM, de fysieke controls worden niet gemonitord (uitzondering hierop is de tapestreamer. Als deze geopend wordt meldt MOM dit). 15. Wordt bij het uitvoeren van een change security in acht genomen? Persoon 1: Ja Persoon 2: Ja Persoon 3: Nee Persoon 4: Ja, wel puur reactief. Er is geen checklist, meer een aantal triggers in het hoofd en de ervaring van mensen. Persoon 5: In principe wel Persoon 6: Weinig


79

Persoon 7: Ja 16. Is er een Incident Management proces aanwezig voor security incidenten? Persoon 1: Persoon 2: Nee Persoon 3: Nee Persoon 4: Er is ooit een voorstel gedaan voor Incident Management, echter nooit gebruikt. Er is wel een algemene werkwijze echter niet gedocumenteerd. Er is een besluit geweest dat incidenten geregistreerd moeten worden. Persoon 5: Als er een incident plaatsvindt wordt het zo snel mogelijk dicht gezet. Hierna wordt er gekeken wat er precies is gebeurd. Persoon 6: Nee Persoon 7: Incidenten worden afgehandeld. Hoe dit gebeurd is afhankelijk van het incidenten, er is geen vast proces voor. 17. Zijn er processen voor het identificeren, monitoren en controleren van security controls en zijn deze gedocumenteerd? Persoon 1: Beperkt Persoon 2: ? Persoon 3: Nee Persoon 4: Nee, gebeurd allemaal op algemene ICT kennis Persoon 5: Nee, over het algemeen wordt er opgetreden door je af te vragen “wat is het” en vervolgens “wat gaan we doen”. Persoon 6: Nee Persoon 7: Als iemand een melding ziet binnen MOM wordt deze opgepakt en naar eigen inzicht afgehandeld. 18. Zijn er verantwoordelijke personen / teams aangewezen voor Security Administration & Management? Persoon 1: Persoon 2: Nee Persoon 3: Iedereen, TBB Persoon 4: Nee, iedereen Persoon 5: Iedereen, geen vast persoon. Door de omvang van de organisatie moet iedereen alles kunnen. Persoon 6: Nee Persoon 7: Nee

Service Monitoring and Control Service Monitoring en Control heeft te maken met het controleren of IT omgevingen in een healty staat zijn en zoniet acties te ondernemen. Hierbij wordt onderscheid gemaakt in Reactief en proactief control. Reactief bijvoorbeeld voor het afhandelen van incidenten. Proactief voor het herkennen van potentiële onderbreking en uitval van services. Relevante bronnen MOM Vragen 12. Wordt er binnen de organisatie gebruik gemaakt van Service Monitoring and Control? Persoon 1: Persoon 2: Ja Persoon 3: Ja Persoon 4: Ja Persoon 5: Ja, MOM Persoon 6: Ja, MOM Persoon 7: Ja met MOM 13. Zijn services en afhankelijke componenten geïdentificeerd voor service monitoring? Persoon 1: Ja, impliciet, product knowledge Persoon 2: Ja


80

Persoon 3: Ja, gedocumenteerd, binnen MOM. Daarnaast is het in contracten opgenomen met de klant. Geen interne SLA Persoon 4: Ja, staat in de management packs. Per manamgement pack is er documentatie aanwezig geschreven door de eigenaar. Bij eigen management packs is er geen beschrijving op papier aanwezig. Persoon 5: De vraag is of het überhaupt mogelijk is om alles te monitoren. Je kan eigenlijk wel zeggen dat dit bij iedereen in het hoofd zit, er staat in ieder geval niks op papier. Persoon 6: Ja, gedeeltelijk wel, er is een excel sheet op een netwerkschijf. Hierin staat per systeem wat er gemonitord wordt. Persoon 7: Alles wat MOM kan monitoren wordt gemonitord 14. Is er een health model opgesteld voor iedere gemonitorde service? Persoon 1: Ja, MOM Persoon 2: Nee Persoon 3: Minder dan 100% is unhealty Persoon 4: Dit wordt door de management packs bepaalt (thresholds, consolidations, etc.). Over het algemeen wordt hierop vertrouwd. Persoon 5: Er is niks vastgelegd, alles gebeurd op ervaring en met MOM. We vertrouwen hierbij op het health model van MOM. Op basis van alerts krijg je rode, groene melding e.d. Persoon 6: Nee, dit zit in MOM Persoon 7: Dit is naar eigen inzicht, er is niks voor vastgesteld 15. Wordt voor het continue monitoren van services gebruik gemaakt van een system management tool of vergelijkbare applicatie? Persoon 1: Ja, MOM Persoon 2: MOM Persoon 3: MOM Persoon 4: MOM Persoon 5: MOM Persoon 6: MOM Persoon 7: MOM, de wel of niet goed verlopen van de backups wordt gemaild 16. Zijn oplossingen en / of workarounds beschikbaar voor optredende alerts en events? Persoon 1: Persoon 2: Denk wel dat de jongens het hebben, af en toe naar zoeken Persoon 3: Voor de meeste events zijn oplossingen aanwezig, knowledge base Persoon 4: Een deel van de kennis zit in de management packs ingebakken. Eigen gevonden oplossingen worden hierbij in opgenomen. Persoon 5: In MOM zit een knowledge base van Microsoft. Naast de Microsoft knowledge base is er een optie om zelf een knowledge base op te bouwen binnen MOM. Persoon 6: Soms wel, in MOM zit een oplossingsveld met een standaardoplossingen van Microsoft en een eigen veld dat ingevuld kan worden Persoon 7: Dit zit in MOM zelf, voor een grote hoeveelheid events is een knowledge base van Microsoft aanwezig. Daarnaast kan een eigen knowledge base opgebouwd worden, dit is voor een aantal events gebeurd. 17. Wordt voor het afhandelen van alerts gebruik gemaakt van een Incident Management proces? Persoon 1: Ja, product & company knowledge binnen MOM Persoon 2: Geloof er niks van Persoon 3: Soms wel, bij specifieke alerts wordt er toegewezen, klant niveau of product niveau of basis van foutmelding Persoon 4: Ja en nee. Van hele kleine dingen worden geen incidenten gemaakt, wel binnen MOM aan personen toegewezen. Grote incidenten worden ingevoerd in het helpdesk pakket. Persoon 5: Nee, op ervaring. Er is een proces geweest, één van de operationele medewerkers was verantwoordelijk voor het toedelen van incidenten echter deze


81

was niet altijd aanwezig wat dit weer lastig maakt.. Het is nu zo dat als je iets ziet je dit oppakt. Daarnaast kan het toegewezen worden aan een persoon, wordt het consequent gebruikt, nee. Je bent met een kleine groep en overlegd snel over de tafel. Persoon 6: Ja, het komt er in het kort op neer dat er bekeken wat voor soort alert het is en wie deze het beste kan oplossen, vervolgens wordt de alert toegedeeld aan een expert, hierop wordt de alert afgehandeld en gesloten. Persoon 7: Nee 18. Worden alerts automatisch weggeschreven als incident record? Persoon 1: Nee, komt in de toekomst nu nog handmatig Persoon 2: Nee Persoon 3: MOM is de incident management tool (Eigenlijk niet dus) Persoon 4: Nee, er zijn wel vragen neergelegd voor System Center Service Desk een toekomstige tool van Microsoft. Hierin moet dit beter geregeld zijn. Het streven is ernaar om dit te gaan gebruiken. Persoon 5: Nee, we hebben een helpdesk tool. Het enige wat ik met de helpdesk tool doe is bijhouden van de helpdesk, telefoon beantwoorden. Hierbij moet ik zeggen dat niet alles wordt opgenomen. De lullige dingen zet ik er niet in. MOM incidenten worden niet overgenomen. Technisch is dit ook niet mogelijk, met de hand kost het teveel tijd. Persoon 6: Wordt als hetzelfde gezien. Echt gekke dingen worden in het helpdesk pakket gezet en daarin afgevangen. Het is de bedoeling dat er in de toekomstige MOM dit automatisch gebeurd. Persoon 7: Nee 19. Wordt bij het vaker voorkomen van eenzelfde alert / incident een Problem Management proces gestart? Persoon 1: Ja Persoon 2: Moet zo zijn, kan het niet beamen ste de de Persoon 3: Wisselend, eigenlijk consequent wel. 1 , 2 en 3 lijns wordt ondersteund door MOM. Daarnaast wordt er toegewezen aan een persoon. Echter de meeste omgevingen zijn zo stabiel dat problemen en incidenten zo uit elkaar gehaald worden. Persoon 4: Incidenten en probleem zit binnen hetzelfde proces, er kan beter gesproken worden over issue management dan incidenten en problem management. Alles wat wij meestal krijgen zijn problemen, incidenten worden bij de klant op de helpdesk afgehandeld. Persoon 5: Als er iets vaker voorkomt wordt hier zeker actie op ondernomen. Persoon 6: Dit wordt gedaan er is echter geen apart en vast proces voor. Persoon 7: Ja, op inzicht 20. Is er een proces aanwezig voor Service Monitoring en Control en is deze gedocumenteerd? Persoon 1: Impliciet Persoon 2: Geprobeerd met planning en bezetting, proces niet beschreven, planningsbord staat er, wordt ook wel gebruikt. Persoon 3: Nee, iedereen doet monitoring. ’s Ochtends begint er iemand en wordt de bulk weggewerkt, hier is ene planning voor aanwezig. Persoon 4: Geen proces beschreven, MOM kan gezien worden als ons impliciete proces. Persoon 5: Ligt aan de SLA. Persoon 6: Nee Persoon 7: Als iemand iets ziet pakt deze het op en handelt het naar eigen inzicht af, dit is een beetje de algemene werkwijze. 21. Wordt de performance van het monitoren gemeten en geëvalueerd aan SLAs en KPI‘s? Persoon 1: Ja, Availability reporting


82

Persoon 2: Zou wel moeten, ga ervan uit. Is niet duidelijk wat er hoort te gebeuren, dus dit is heel lastig Persoon 3: Wel gemeten, time to resolve zit in MOM, hier gebeurt echter niks mee. Persoon 4: Nee, in de SLA staat wel dat er rapportages worden gegeven er niks over tijdigheid e.d.. Helpdesk tool kent geen rapportage en is te minimaal (technische mogelijkheden missen). Persoon 5: Het wordt bijgehouden binnen MOM. Bij de reclassering moeten we bijvoorbeeld binnen 2 uur reageren. Een evaluatie vindt er nooit plaats. Persoon 6: Wordt niet gedaan zou wel moeten. Evaluatie wordt mondeling wel een gedaan. Persoon 7: Nee 22. Is er één persoon / team verantwoordelijk voor Service Monitoring and Control? Persoon 1: Persoon 2: Nee, denk het niet Persoon 3: Allemaal Persoon 4: MOM problematiek komt meestal bij één van de operationele medewerkers terecht. Echter hij coördineert niks. Persoon 5: Allemaal Persoon 6: Nee Persoon 7: Nee

Directory Service Administration Directories worden gebruikt voor het centraal opslaan en doorzoeken van data. Voorbeelden van een directory zijn de telefoongids, de gouden gids, een Active Directory, etc. De Directory Service Administration SMF heeft als doel informatie beschikbaar te maken over het netwerk voor ieder geautoriseerd persoon. Naast het proces voor het zoeken van informatie zijn hiervoor verschillende beheersprocessen nodig. Directory Service Administration geeft hier een invulling aan. Relevante bronnen Gebruikte directories Vragen 8. Zijn gebruikte directories geïdentificeerd en gedocumenteerd (doel, inhoud, locatie, verantwoordelijke personen, etc)? Persoon 1: Ja Persoon 2: Niet gedocumenteerd, geïdentificeerd moeilijk Persoon 3: Ja,volgens mij zijn ze ook gedocumenteerd. Persoon 4: Over het algemeen wel. Sommige klanten beschikken over documentatie over OU indelingen e.d. echter niet elke klant heeft dit. Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee, alleen wat er bij microsoft bekend is en wat je als microsoft gecertificeerde weet. Directories worden wel ingedeeld e.d. maar dit wordt niet gedocumenteerd, de indeling is persoonsafhankelijk. 9. Worden directories gemonitord en incidenten afgehandeld volgens een Incident Management proces? Persoon 1: Ja, impliciet Persoon 2: Wel gemonitord, afhandelen incidenten niet Persoon 3: Wel gemonitord, incidenten vinden niet plaats . De afhandeling ligt bij iedereen. Persoon 4: Ja, MOM, afgehandeld volgens de vaste werkwijze Persoon 5: Monitoren van directories kan zeker, dit heeft ook aangestaan. Incidenten zijn lastig, als er iets moet gebeuren wordt dit gewoon opgepakt en afgehandeld. Als het bij de klant ligt zijn wij er niet verantwoordelijk voor. Persoon 6: Ja Persoon 7: AD zeker wel, afhandeling is volgens de algemene werkwijze.


83

10. Worden directories periodiek gebackupped? Persoon 1: Ja Persoon 2: Ja Persoon 3: Ja, dagelijks. Persoon 4: Ja, elke dag (klant en intern) Persoon 5: Intern en bij klanten Persoon 6: Ja, intern en bij de klant gebeurd dit met een back-up schema Persoon 7: Ja, intern en bij de klant. 11. Gebeurd het maken en restoren van een back-up volgens een plan en is deze getest? Persoon 1: Ja Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee, er is niks beschreven. Sommige dingen zijn getest wel getest. Persoon 5: Maken gaat volgens een plan, restoren niet Persoon 6: Per klant en voor onszelf is er een back-up plan of deze getest is twijfel ik over. Voor het restoren van een back-up is tevens een plan aanwezig. Persoon 7: Ja, intern en bij de klant. Het terugzetten van de AD is niet getest en hiervoor is ook geen plan. 12. Zijn er processen aanwezig voor het monitoren en beheren van directories en zijn deze gedocumenteerd? Persoon 1: Impliciet, tussen de oren Persoon 2: Volgens mij niet Persoon 3: Ja, MOM monitord alles, aanmaken van users, weggooien van users etc. Persoon 4: Nee geen procesbeschrijving. Algemene werkwijze wordt gebruikt. We hebben MOM hiervoor, wat een impliciet proces in zich heeft. Persoon 5: Ad hoc Persoon 6: Ja, monitoren gebeurd volgens MOM, back-up / restore staat op papier beschreven of zit het in het hoofd Persoon 7: Gebeurd door MOM, verder niks 13. Worden plannen en procedures op periodieke wijze of event-driven geëvalueerd en zonodig aangepast? Persoon 1: Nee Persoon 2: Geen plannen dus nee Persoon 3: Nee Persoon 4: Geen plannen. We hanteren de methodiek die Microsoft hanteert. Persoon 5: Event-driven Persoon 6: Ja, event-driven, voornamelijk wanneer de opslagcapaciteit kritiek wordt Persoon 7: Evaluatie vindt plaats, event-driven 14. Is er één persoon / team verantwoordelijke voor Directory Service Administration? Persoon 1: De hele organisatie Persoon 2: Een van de operationele medewerkers is verantwoordelijk Persoon 3: Allemaal Persoon 4: Iedereen Persoon 5: Iedereen Persoon 6: Nee, het hele team Persoon 7: Nee

Network Administration Het doel van Network Administration is het aanreiken van enkele best practice processen voor het dagelijkse beheer van netwerkomgevingen. Het dagelijkse beheer omvat het plannen en realiseren van uitbreidingen aan het netwerk en het leveren van support voor het oplossen en repareren van fouten binnen de netwerk omgeving. Vragen 6. Worden alle netwerkcomponenten continue gemonitord en opgetreden indien nodig?


84

Persoon 1: Ja Persoon 2: Switches niet, server e.d. wel Persoon 3: Ja, continue, switches, servers, zeg maar alle active componenten Persoon 4: Intern wel (switches, servers), extern is dit lastig. Persoon 5: Ja, niet alle netwerkcomponenten, servers wel, switches niet Persoon 6: Alle servers en daarnaast onze eigen switches Persoon 7: Nee niet alles, servers wel, switch en verbindingen soms. 7. Worden netwerkincidenten verlopen volgens een Incident Management proces? Persoon 1: Impliciet Persoon 2: Nee Persoon 3: Ad hoc Persoon 4: Algemene werkwijze Persoon 5: Als wij het in beheer hebben gaan we erachteraan, echter altijd ad hoc Persoon 6: Nee Persoon 7: Iemand ziet het, pakt het op en lost het naar eigen inzicht op, de algemene werkwijze 8. Wordt de veiligheid van het netwerk op periodieke wijze of event-driven wijze geëvalueerd? Persoon 1: Ja Persoon 2: Geen details bekend, wel maatregelen Persoon 3: Ja, socks compliant (management packs) Persoon 4: Binnen MOM draait de baseline security analyzer, deze draait periodiek. Op het moment dat er iets gewijzigd moet worden gebeurd het event-driven. Persoon 5: Evaluatie vindt plaats alleen niet periodiek. Fireware updates e.d. bij klanten gebeuren vaak wel maar het is ook mogelijk dat het bij een enkele klant nooit gebeurd is. Persoon 6: Nee, is meer ad hoc Persoon 7: Event-driven 9. Zijn er processen voor het beheren van het netwerk en zijn deze gedocumenteerd? Persoon 1: Persoon 2: Nee Persoon 3: Beheer is niet te documenteren Persoon 4: Er is een algemeen verhaal wat onder beheer valt en wat binnen het contract valt. Persoon 5: MOM wordt hiervoor gebruikt, ad hoc Persoon 6: Nee Persoon 7: Volgens de algemene werkwijze 10. Is er één verantwoordelijk persoon of team aangewezen voor Netwerk Administration? Persoon 1: Organisatie Persoon 2: Eén van de operationele medewerkers is verantwoordelijk Persoon 3: Alle Persoon 4: Nee, verschilt per klant Persoon 5: Allemaal Persoon 6: Nee Persoon 7: Nee niet één specifiek persoon.

Storage Management Storage Management ondersteunt de organisatie met het leveren van ruimte voor opslag van data. Dit brengt verschillende verantwoordelijkheden met zich mee o.a. design en opstellen van plannen voor het opslaan, backuppen en restoren van data, monitoren van data, troubleshooting, garant staan voor de veiligheid van data, etc. Relevante bronnen Batch jobs Procedures


85

Back-up / recovery plannen Vragen 10. Is aanwezige data geclassificeerd (user data / company data, business impact)? Persoon 1: Persoon 2: Moet van ja uitgaan Persoon 3: Ja, company-data en productie data is fysiek gescheiden op disken Persoon 4: Nee Persoon 5: Wel onderscheid, er zijn home directories, echter deze rechten zijn zo ruim dat iedereen erbij kan. Persoon 6: Nee, dit is niet zo van belang Persoon 7: Ja, de medewerkers hebben allemaal een eigen map. Soms worden dingen ook fysiek op andere schijven opgeslagen. 11. Wordt er op periodieke wijze een back-up gemaakt van de data? Persoon 1: Ja Persoon 2: Ja, tuurlijk Persoon 3: De MOM data wordt minder vaak gebackupped dan eigen data. Company /user data dagelijks, business data (MOM) wordt deels gebackupped, probleem is dat de data set te groot is, ook transactie logs e.d. worden niet gebackupped. Wel staat dit allemaal op gemirrorde disken echter als de hele set crashed hebben we een groot probleem. Persoon 4: Ja Persoon 5: Alles wordt op hetzelfde tijdstip gebackupped, dagelijks. Backuppen gebeurd echter niet geweldig, stukje shadow copy. Voor het echte back-up werk missen we een stuk opslag om in staat te zijn een week of een maand terug te gaan. We hebben momenteel een roulatie van een paar dagen. Persoon 6: Ja, per klant is dit afhankelijk, intern gebeurd het in ieder geval dagelijks Persoon 7: Ja, intern en bij de klant wordt dagelijks een back-up gemaakt. 12. Is er een voor het maken van backups, restores en recoveries een plan opgesteld en getest (hoeveelheid, locatie, schedules, mogelijke failures, etc)? Persoon 1: Ja, gedocumenteerd Persoon 2: ? Persoon 3: Bij klanten wordt alles dagelijks gebackupt en is er een plan voor, dit is goed geregeld. Het is natuurlijk wel afhankelijk van kosten en middelen. Intern zijn er wel back-up planen, geen recovery scenario’s Persoon 4: Nee, is niks in beschreven. Wordt wel over gesproken er komt niks van de grond door de tijd die hiervoor nodig is. Persoon 5: Backups zijn gescheduld er is geen vast plan op papier Persoon 6: Voor intern en bij de klant is er een back-up en recovery plan aanwezig. Of deze getest zijn betwijfel ik. Persoon 7: Nee 13. Wordt het maken van backups en de gebruikte back-up resources gemonitord (performance, availability, capacity)? Persoon 1: Ja Persoon 2: Ja, tuurlijk Persoon 3: Ja, MOM, daarnaast wordt er gemailed als de back-up fout gaat en als hij klaar is. Persoon 4: Ja Persoon 5: Ja, we krijgen mail of een back-up gelukt is of niet, waar we volledig beheer doen geldt dit ook voor klanten. Monitoring gebeurd door MOM Persoon 6: Ja, de back-up zelf meldt of deze goed of fout verlopen is. Persoon 7: De uitkomst, succes of failure, van een back-up wordt gemaild, de resources worden met MOM gemonitord. 14. Worden storage incidenten afgehandeld volgens het Incident Management proces? Persoon 1: Impliciet Persoon 2: Wordt afgehandeld, ad hoc


86

Persoon 3: Nee / ja, ad hoc wordt er opgetreden Persoon 4: Algemene werkwijze, je ziet iets (er is een trigger), request in de helpdesk tool, houdt dit bij, bij oplossing wordt er een solutions aangemaakt. Dit gebeurd niet consequent. Persoon 5: Nee Persoon 6: Nee, is klant specifiek, intern gebeurd dit ook niet Persoon 7: Algemene werkwijze 15. Worden aanpassingen aan de storage infrastructuur afgehandeld door het Change Management proces? Persoon 1: Ja, met RFC Persoon 2: Nee Persoon 3: Nee, intern niet bij een klant ook niet. Is het nodig dan gebeurt het gewoon Persoon 4: Ja, voorzover dit proces aanwezig is (geldt voor intern en extern). Storage changes zijn vaak grote changes vandaar. Persoon 5: Intern wordt dit besproken. Extern zal er een RFC komen, of dit op papier is is de vraag Persoon 6: Nee Persoon 7: Ja, voor intern en bij de klant geldt dat er RFC’s worden opgesteld voor changes. 16. Worden storage plannen geëvalueerd en zonodig bijgesteld (perodiek / eventdriven)? Persoon 1: Nee Persoon 2: Ongetwijfeld Persoon 3: Nee Persoon 4: Puur reactief, op het moment dat er iets nieuws moet komen. Er is niks geen perodieke evaluatie. Persoon 5: Ja, event-driven Persoon 6: Ja, ad hoc, voorbeelden van triggers zijn schijven die vollopen of kapot gaan. Dit geldt voor intern en bij de klant. Persoon 7: Nee 17. Zijn er processen aanwezig voor het monitoren en maken van backups, restoren van data en recovery procedures en zijn deze gedocumenteerd? Persoon 1: Ja, MOM Persoon 2: Binnen MOM, niet bekend Persoon 3: Ja, maken van backups, restoren niet Persoon 4: Backups draaien autmatische, de uitslag wordt gemaild. MOM monitord en trend analyze gebeurd volgens MOM reporting. Persoon 5: Vaak is er een stappenplan binnen een pakket, dit is afhankelijk van het pakket. Alles gebeurd wel ad hoc. Persoon 6: Ja, de backups gebeuren ’s nachts en ’s ochtends worden alle mails nagekeken of de backups goed zijn verlopen. Bij problemen wordt er ingelogd, is het probleem waardoor het misging ernstig dan wordt het gelijk opgelost, anders gebeurd er niet veel. Eventueel wordt er met de klant overlegd. Als er actie is ondernomen wordt dit gerapporteerd aan de klant. Persoon 7: Algemene werkwijze 18. Is er één persoon / team verantwoordelijk voor Storage Management? Persoon 1: Team Persoon 2: ? Persoon 3: Alle Persoon 4: Nee, iedereen Persoon 5: Iedereen Persoon 6: Nee Persoon 7: Nee

Job Scheduling


87

Batch jobs kenmerken zich in de hoeveelheid benodigde data en resources voor het draaien van de batch job, bijvoorbeeld het maken van rapportages en het uitdraaien van facaturen. Om systemen te ontzien en het gebruikersgemak hoog te houden worden dergelijke jobs veelal in de avond / nacht uren gedraait wanneer de meeste resources beschikbaar zijn. Job Scheduling houdt zich bezig met het beheer, monitoren, analyse en implementatie rondom batch jobs. Relevante bronnen Huidige batch processen en schedules Vragen 10. Wordt er gebruik gemaakt van batch jobs binnen de organisatie? Persoon 1: Ja, updates, rapportages Persoon 2: Ja Persoon 3: Ja Persoon 4: Ja, backups, MOM availability management, batch jobs voor defragementatie (test fase), scheduled reboots. Per klant zijn er nog wat dingen als file transfers tussen servers Persoon 5: Ja, rapportages van MOM gebeuren elke maand (helaas geen maand maar vier weken), defragmentaties, backups Persoon 6: Ja, back-up, defragementatie, virus scans, de MOM rapportage wordt aan gewerkt Persoon 7: Ja, back-up (sommige), defragementatie, rapportages 11. Zijn details van de batch jobs gedocumenteerd / verzameld (beschrijving, eigenaar, stappen, tijd, frequentie, recovery steps, etc)? Persoon 1: Ja Persoon 2: Nee Persoon 3: Ik weet wat ze doen, documentatie is niet zeker, vast wel Persoon 4: De meeste wel, waar hij voor is, welk account, wat er gebeurd. Ik doe het wel, eigenlijk zou het consequent moeten gebeuren binnen The Backbone. Persoon 5: Nee Persoon 6: Niet gedocumenteerd, wel bekend, dit zit in het hoofd bij iedereen Persoon 7: Nee, volgens mij niet 12. Wordt er gebruik gemaakt van tools voor het managen van batch processen? Persoon 1: Nee Persoon 2: Nee Persoon 3: MOM Persoon 4: Task scheduler, MOM Persoon 5: MOM en task scheduler Persoon 6: Ja, de task scheduler van windows Persoon 7: MOM voor de rapportages, NT back-up wordt gebruikt, task scheduler 13. Worden incidenten afgehandeld volgens een Incident Management proces? Persoon 1: Impliciet Persoon 2: Nee Persoon 3: Ad hoc Persoon 4: Algemene werkwijze Persoon 5: Job gaat mis, je kijkt wat er mis gaat en je lost het op, ad hoc dus Persoon 6: Nee Persoon 7: Naar eigen inzicht en volgens de algemene werkwijze 14. Worden veranderingen in de batch schedule afgehandeld volgens een Change Management proces? Persoon 1: Ad hoc Persoon 2: Geen schedule Persoon 3: Nee, schedule is wel aanwezig Persoon 4: Nee, wordt doorgegeven, documentatie wordt vaak wel aangepast.


88

Persoon 5: Nee, dit gebeurd op gevoel en ervaring. Bij de klant zou het eerder gebeuren maar ook hier gebeurd veel op inzicht en ervaring. Persoon 6: Nee Persoon 7: Nee, dit zijn geen changes. 15. Worden resources en de performance van resources gemonitord en gerapporteerd? Persoon 1: Ja Persoon 2: Ja Persoon 3: Ja, MOM en gerapporteerd Persoon 4: MOM monitord waar mogelijk Persoon 5: Ja Persoon 6: Ja Persoon 7: Ja met MOM, er zijn geen aparte rapportages voor. 16. Worden batch processen en de batch schedule geanalyseerd en geoptimaliseerd? Persoon 1: Ja, zeker Persoon 2: Kan beter, kan het me niet voorstellen Persoon 3: Waar nodig zeker, momenteel komen we tijd tekort voor het draaien van alle jobs, ze duren langer dan de dag. Optimalisatie gebeurd dus zeker wel. Persoon 4: Nee, is het niet intensief genoeg voor. Wellicht dat enkele jobs binnen MOM wel geoptimaliseerd worden, dit doet één van de operationele medewerkers Persoon 5: Ja Persoon 6: Ja Persoon 7: Ja 17. Zijn er processen aanwezig voor het beheren van batch processen en zijn deze gedocumenteerd? Persoon 1: Nee Persoon 2: ? Persoon 3: Nee, ad hoc Persoon 4: Nee, enkel dingen binnen Management packs Persoon 5: Nee Persoon 6: Nee Persoon 7: Niks vastgelegd, geheel naar eigen inzicht. 18. Is er één persoon / team verantwoordelijk voor Job Scheduling? Persoon 1: Organisatie Persoon 2: Nee Persoon 3: Allen, gesplits op applicatie, MOM applicaties doe ik, klanten sites (backups, defragmentatie etc) de rest Persoon 4: Nee Persoon 5: Iedereen Persoon 6: Nee Persoon 7: Nee

Service Desk Een service desk is een centrale plek voor het afhandelen van contact met de omgeving. Hierbij moet gedacht worden aan contact via de telefoon, internet, fax, een balie etc. Calls komen bij de service desk binnen die vervolgens zorgen voor een juiste afhandeling. Dit kan de service desk zelf afhandelen of toewijzen aan derde personen / teams. Doormiddel van centrale systemen, bijv. CMDB, incident logging, call logging en CRM, blijft de service desk op de hoogte van de nieuwste informatie. Relevante bronnen Call log tools CMDB Incident / Service request tools. Vragen 12. Wordt er binnen de organisatie gebruik gemaakt van een Service Desk?


89

Persoon 1: Ja Persoon 2: Ja Persoon 3: Ja Persoon 4: De telefoon, wie tijd heeft neemt op. Persoon 5: Ja, nu wel Persoon 6: Ja Persoon 7: Ja 13. Worden call’s naar de service desk geregistreerd en gemonitord met behulp van een call logging applicatie? Persoon 1: Ja, helpdesk tool Persoon 2: Applicatie is er wel, niet consequent gebruikt Persoon 3: Ja en nee, we hebben een helpdesk pakket (naam onbekend, helpdesk pro?) alleen niet iedere call wordt ingezet vanwege de tijd die het kost. Vaak worden calls direct afgehandeld. Kost gewoon teveel tijd. Gebeurd wel als melding per mail binnenkomen, maar ook afhankelijk van de zwaarte. Persoon 4: Ja, helpdesk pakket, elke call wordt opgenomen. Mocht een call direct worden afgehandeld dan wordt deze achteraf alsnog opgenomen in de tool. Kritische alerts binnen MOM worden ook opgenomen Persoon 5: Ja, een helpdesk tool. Persoon 6: Ja en nee, belangrijke calls worden opgenomen, de kleine calls niet. Voor het opslaan wordt een helpdesk pakket gebruikt (adventnet helpdesk plus) Persoon 7: Helpdesk tool 14. Welke methoden kunnen worden gebruikt voor het doen van calls? Persoon 1: Telefoon, mail Persoon 2: Mail, telefoon Persoon 3: Mail, telefoon Persoon 4: Telefoon, mail, mondeling overleg met de klant Persoon 5: Telefoon, mail (deze het liefste), we zijn om het helpdeskpakket op de website te krijgen Persoon 6: Mail en telefoon Persoon 7: Telefoon, mail, ze kunnen langskomen, toegang op de website zijn we mee bezig. 15. Worden incidenten door de service desk opgenomen in de incident logging tool? Persoon 1: Persoon 2: Niet consequent Persoon 3: Incident logging tool is de helpdesk Persoon 4: Het Helpdesk pakket wordt hiervoor gebruikt. Eigenlijk wordt alles opgenomen, problemen, changes, incidenten, service request. Persoon 5: Het helpdeskpakket is de incident logging tool Persoon 6: In de helpdesk applicatie Persoon 7: De helpdesk tool is tevens de incident logging tool, ja dus. 16. Heeft de service desk de mogelijkheid gebruik te maken van de CMDB en bekende oplossingen en workarounds voor problemen? Persoon 1: Ja Persoon 2: Ja tuurlijk Persoon 3: Nee, kan niet. Helpdesk pakket heeft een eigen database (CMDB), de CMDB van MOM is wel toegankelijk. Persoon 4: Word documenten met documentatie, knowledge base van MOM en oplossingen die in de helpdesk tool staan Persoon 5: Indien aanwezig ja. De Service Desk kan gebruik maken van de knowledge bases in MOM, documentatie van de klant etc. Persoon 6: Nee, er is geen CMDB Persoon 7: Ja, documentatie en de MOM knowledge bases. 17. Rapporteert de service desk over de hoeveelheid binnengekomen calls en hun eigenschappen?


90

Persoon 1: Ja, ook naar de klant Persoon 2: Nee Persoon 3: Kan wel, gebeurd niet Persoon 4: Nee op dit moment niet, er is geen beslissing over genomen wat gerapporteerd moet worden Persoon 5: Kan wel, het is echter niet ingesteld Persoon 6: Nee, dit gebeurd niet, de tool heeft er wel de functionaliteiten voor. Persoon 7: Nee 18. Wordt er binnen de service desk gebruik gemaakt van templates (bijv. rapportages, calls, etc)? Persoon 1: Persoon 2: Persoon 3: Helpdesk pakket, daarnaast geen templates Persoon 4: Nee Persoon 5: Ja, binnen het helpdesk zitten allemaal formulieren voor het inzetten van records. Persoon 6: Nee Persoon 7: Ja, voornamelijk vanuit de helpdesk tool. Deze bevat bijvoorbeeld een mail template voor het versturen van een mail naar klanten met een referentienummer. 19. Wordt er bij het plannen van de service desk rekening gehouden met pieken en dalen van calls en zijn resources aanwezig om dit op te vangen? Persoon 1: Ja, met moeite Persoon 2: Ja, wordt op gepland als organisatie Persoon 3: Nee, standaard zitten we ’s ochtends met 2 man. Verder is er niks geregeld (na een migraties etc) Persoon 4: ’s Ochtends zitten er altijd twee mensen. Daarnaast zijn er geen maatregelen getroffen. Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee 20. Zijn er processen aanwezig voor de service desk en zijn deze gedocumenteerd? Persoon 1: Nee Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee, iedereen zit op hetzelfde kantoor. In het nieuwe pand wordt dit sterker. Persoon 5: Ik heb wel een proces, dit geldt niet in het algemeen. Ik volg de volgende stappen: a. Het komt binnen, vaak via email, desnoods telefoon b. Zet het in het helpdeskpakket c. Als hij in het pakket staat zet ik hem in outlook op afgehandeld d. Eventueel vul ik hem, in het helpdesk pakket, aan met extra informatie e. Handel hem af f. Eventueel een reply Closure Persoon 6: Nee Persoon 7: Nee, hier is ook weer de algemene werkwijze van toepassing: a. Een call komt binnen b. De call wordt in het pakket opgenomen c. De call wordt toegewezen (vaak aan jezelf) d. Het probleem / incident / service request wordt opgelost De persoon die de call heeft opgelost zorgt voor een closure. 21. Wordt de performance van de service desk gemeten en geëvalueerd aan SLA’s en KPI‘s?


91

Persoon 1: Nee Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee, er is geen wachtrij op de telefoonlijn (als de lijn vol zit krijg je een in gesprek toon) o.i.d. er is niks geen rapportage over beschikbaarheid en response Persoon 5: Nee, gebeurd snel kan ik zeggen, opnemen en afhandelen. Bijna alles wat ik binnen krijg wordt dezelfde dag afgehandeld, vaak hetzelfde uur nog. Persoon 6: Nee Persoon 7: Nee 22. Is er één persoon / team verantwoordelijk voor de Service Desk? Persoon 1: Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee Persoon 5: Eén iemand heeft het pakket opgezet en als er wat aangepast moet worden doet hij dat. Als hij er niet is doet iemand anders het. Een algemeen verantwoordelijk persoon is er niet. Persoon 6: Nee, alleen voor de applicatie zelf, dat ben ik. Persoon 7: Nee

Service Request & Incident Management Het draaiende houden van een IT omgevingen houdt in dat incidenten verholpen moeten worden en service request afgehandeld moeten worden. Een incident wordt omschreven als een gebeurtenis die niet in het normale verloop van een service thuishoort en oorzaak kan zijn van een onderbreking of vermindering van de kwaliteit van de service. Incidenten moeten zo snel mogelijk verholpen worden om de SLA na te komen. Een voorbeeld van een incident is een server die uitvalt, een restart is snel nodig om de maximale downtime niet te overschrijven. Service Request zijn verzoeken van klanten voor het uitvoeren van bepaalde acties, bijvoorbeeld starten van een batch job, updaten van software, een password reset, een vraag om informatie, installatie van een nieuw system, etc. De mogelijke service requests zijn opgenomen in de SLA. Relevante bronnen Systeem voor het opslaan van incident records en service requests Vragen 14. Wordt er binnen de organisatie gebruik gemaakt van Service Request & Incidentent Management? Persoon 1: Ja Persoon 2: Persoon 3: Ja Persoon 4: Ja, alles komt op één stapel, changes, service requests en incidenten Persoon 5: Alles gebeurd ad hoc. Alles is één pot nat (changes, service request, incidenten, problems) Persoon 6: Ja, onder service request worden werkzaamheden verstaan die je normaal uitvoert bijvoorbeeld periodiek onderhoud, incidenten zijn problemen die optreden. Persoon 7: Ja, zodra er iets onverwachts gebeurd, bijvoorbeeld een fout, spreken wij van een incident. Een service request is een aanvraag van iets of iemand, advies, change e.d 15. Is er een systeem aanwezig voor het opslaan, bijhouden en monitoren van incidenten / service requests? Persoon 1: Ja, helpdesk tool Persoon 2: Helpdesk tool, verder weet ik het niet Persoon 3: MOM slaat alles op het gebied van servers e.d. automatisch op, daarnaast wordt de helpdesk tool gebruikt voor melding via telefoon / mail Persoon 4: Helpdesk tool Persoon 5: MOM slaat zelf incidenten op, ik zet daarnaast incidenten in de helpdesk tool Persoon 6: Ja, outlook, planningen van onderhoud en agenda Persoon 7: Helpdesk tool


92

16. Wordt bij binnenkomst van een Incident nagegaan of een dergelijk incident / service request eerder is voorgekomen en een oplossing bekend is? Persoon 1: Ja, mens Persoon 2: Ga er van uit Persoon 3: Achter MOM zit een knowledge base, de eigen knowledge base (company knowledge) wordt gevuld met eerder voorgekomen incidenten Persoon 4: Ja, veelvoorkomende zaken weet je de antwoorden voor. Er is de mogelijkheid in de helpdesk tool te kijken naar eerder voorgekomen incidenten, dit is ook wel eens gedaan. Zelf heb ik het nooit gebruikt. Persoon 5: Ja Persoon 6: Ja, als MOM het rapporteert kan er gekeken worden in de MOM history Persoon 7: Voor jezelf ga je na of dat jij of een collega dit eerder heeft gehad. Heb je een vermoede dat dit zo is dan ga je opzoek anders niet. 17. Worden incidenten en service requests geprioritiseerd (impact en urgentie) / geclassificeerd (door één persoon / team)? Persoon 1: Ja, in MOM + helpdesk tool Persoon 2: Nee, mondeling en gevoel Persoon 3: Ja, ze worden aan elkaar toegedeeld echter alles is urgent (urgentie onderscheid kan wel echter wordt niet gebruikt). Persoon 4: Natte vinger werk / onderbuik gevoel. Binnen het helpdesk pakket zijn er 4 statussen, dit wordt niet consequent gebruikt Persoon 5: Nee, niet bewust Persoon 6: Nee Persoon 7: Ja, hetzelfde als bij de changes. Iets met een hogere prioriteit krijgt meer druk achter zich. 18. Wordt er binnen Service Request & Incident Management gebruik gemaakt van templates (RFCs, RFIs, rapportages, etc)? Persoon 1: Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee Persoon 5: We proberen een eenheid te krijgen voor de rapportage Persoon 6: Nee Persoon 7: Nee 19. Worden incidenten toegewezen aan specifieke personen / teams wanneer geen oplossing voorhad is? Persoon 1: Ja Persoon 2: Nee, alleen op gevoel Persoon 3: Nee, persoon houdt een incident bij zich tot het opgelost is (wordt wel in de groep gegooid). Er is een kleine ongeschreven regel qua klanten verdeling Persoon 4: Meer gebasseerd op de klant, elke klant heeft een eigen contactpersoon. Daarnaast probeert iedereen eerst zelf alles op te lossen en anders gebeurd dit in overleg met aanwezige mensen. Persoon 5: Sommige incidenten worden toegewezen aan personen die er beter mee bekend zijn (meer ervaring en kennis) Persoon 6: Ja, hierbij wordt vooral gekeken naar de kennis van de persoon. Het kan ook gebeuren dat het op basis van de klant aan iemand wordt toegedeeld. Persoon 7: Soms vaak is het zo dat als je ergens niet uitkomt het overlegd met je collega’s en vervolgens oplost. 20. Wordt er onderscheid gemaakt tussen normale en major incidenten? Persoon 1: Ja Persoon 2: Uiteraard op het gevoel Persoon 3: Nee is er eigenlijk niet, iedereen kan alle problemen oplossen Persoon 4: Ja, volgens eigen besef en verantwoordelijkheids gevoel. Persoon 5: Ja, tuurlijk


93

Persoon 6: Ja, de manier van terugmelding. Normale incidenten worden met mail of telefoon afgehandeld. Grote incidenten worden met de klant overlegd, dit gebeurd niet vaak. Persoon 7: Er wordt meer druk gezet achter major incidenten maar daar blijft het bij 21. Wordt na het afhandelen van een incident / service request contact opgenomen met de initiatiefnemer van het incident? Persoon 1: Ja Persoon 2: ?, doe zelf de terugkoppeling wel, niet vanuit gaan dat het gebeurd Persoon 3: Terugkoppeling naar de klant vindt plaats, rechtstreeks, als de klant niks merkt is er geen terugkoppeling. Soms wordt er over gesproken tijdens een maandelijks meeting of rapportages (rapportage zeker) Persoon 4: Ja, mails van klanten worden gereplied verder op need to know basis Persoon 5: Ja, we nemen altijd contact. Als het incident vanuit een persoon komt altijd, als incidenten die door MOM gemeld worden belangrijk zijn worden ze ook teruggekoppeld. Persoon 6: Nee, soms weet de klant niet eens dat er een incident is. Persoon 7: Ja 22. Wordt het afhandelen van incidenten / service requests gemeten en vergeleken met SLA’s en KPI‘s (periodiek / event-driven)? Persoon 1: Nee Persoon 2: Zijn aan het groeien, doen ons best, situatie is er niet dat dit kan gebeuren Persoon 3: Nee geen evaluatie, mom houdt de tijd wel bij Persoon 4: Nee, is niet specifiek besproken in de SLA Persoon 5: Nee Persoon 6: Ja wordt wel gemeten maar niet vergeleken Persoon 7: Nee, er is wel een klant waar we binnen 2 uur moeten reageren maar er wordt niet bijgehouden hoe lang een incident open staat. 23. Wordt het afhandelen van incidenten / service requests geëvalueerd met de klant? Persoon 1: Ja, door de commercieel directeur en één van de operationele medewerkers Persoon 2: Ik doe het wel, als ik er niet bij betrokken ben weet ik nergens van, wil graag meer op de hoogte zijn Persoon 3: Ja, mondeling, een keer in de 14 dagen, 4 weken, 6 weken zien we alle klanten doormiddel van een voortgang overleg. Alle problemen etc wordt dan besproken Persoon 4: Ja, dit verschilt per klant. Bijvoorbeeld voor Oost wordt er gerapporteert welke incidenten er zijn via de helpdesk tool. Persoon 5: Mij onbekend, zolang zij niks aangeven ga ik er vanuit dat het goed is Persoon 6: Bij de klanten die ze bezoeken wel, dit gebeurd in het periodieke overleg met de klant Persoon 7: Volgens mij niet. 24. Is er een proces voor het detecteren, opslaan, classificeren, analyseren en oplossen van incidenten en is deze gedocumenteerd? Persoon 1: Nee Persoon 2: Nee Persoon 3: Nee Persoon 4: Is een voorstel toe geschreven, wordt niet daadwerkelijk gebruikt. Komt niet van de grond Persoon 5: Nee Persoon 6: Het meeste gebeurd in MOM, het ligt maar net aan de persoon die erachter zit hoe dit afgehandeld wordt Persoon 7: Algemene werkwijze 25. Is het proces voor het afhandelen van service requests gelijk aan het proces voor incidenten? Persoon 1: Persoon 2: Nee Persoon 3: Nee


94

Persoon 4: Ja, is meer issue management, er wordt geen onderscheid gemaakt tussen beide. Advies aanvragen, rapportage aanvragen e.d. worden niet consequent geregistreerd Persoon 5: Op dit moment wel Persoon 6: Ja Persoon 7: Beide processen gaan volgens de algemene werkwijze 26. Is er één persoon / team verantwoordelijk voor de Service Requests & Incident Management? Persoon 1: Persoon 2: Nee Persoon 3: Allemaal, we zijn te klein voor een proces. Persoon 4: Nee, wordt wel eens geroepen echter wisselt dit per week Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee

Problem Management Problem Management heeft te maken met het vinden van oplossingen voor de problemen die te grondslag liggen aan incidenten. Binnen Incident Management wordt een incident binnen zo kort mogelijke tijd verholpen zodat er een minimale onderbreking van de service plaatsvindt. Problem Management analyseert de incidenten en zoekt naar de achterliggende problemen om te voorkomen dat incidenten opnieuw optreden. Relevante bronnen Systeem voor het opslaan van problem records Vragen 10. Worden incidenten of vaak voorkomende incidenten gezien als problemen? Persoon 1: Ja Persoon 2: Persoon 3: Gebruiken alleen incidenten, probleem is maar een keer voorgekomen. Alles is een incidenten, we hebben geen problemen . Daarnaast is het eigenlijk zo dat bij problemen Microsoft actie moet ondernemen, dit ligt buiten onze macht. Persoon 4: Ja Persoon 5: Ja Persoon 6: Dit hangt van het incident af, het wordt wel opgemerkt dat incidenten vaak voorkomen. Persoon 7: Ja 11. Wordt er gebruik gemaakt van een applicatie voor het opslaan, bijhouden, monitoren en raadplegen van problemen? Persoon 1: Ja, helpdesk tool, MOM, bestanden locatie Persoon 2: Helpdesk applicatie, één van de medewerkers maakt er gebruik van de rest niet Persoon 3: Persoon 4: Ja, helpdesk tool Persoon 5: MOM, en daarnaast bij iedereen in het hoofd Persoon 6: Helpdesk pakket Persoon 7: De helpdesk tool, maar het is niet zo dat er voor problemen aparte records worden aangemaakt naast de bestaande incidenten. 12. Worden problemen geprioritiseerd (impact / urgentie) / geclassificeerd? Persoon 1: Niet Persoon 2: Ongetwijfeld met de losse hand Persoon 3: Persoon 4: Zie incidenten Persoon 5: Niet bewust Persoon 6: Nee, niet bewust


95

Persoon 7: Alles wordt opgepakt en afgehandeld. Sommige problemen zijn belangrijker het wil wel eens voorkomen dat problemen voorgaan ten opzichte van andere dingen. 13. Worden nieuwe incidenten gekoppeld aan openstaande problem records? Persoon 1: Impliciet Persoon 2: ? Persoon 3: Persoon 4: Nee, is niet mogelijk, zou wel handig zijn Persoon 5: Ja, binnen MOM gebeurd dit automatisch Persoon 6: Deze koppeling vindt automatisch plaats via MOM Persoon 7: Nee 14. Wordt er binnen Problem Management gebruik gemaakt van templates (beschrijving en status probleem, opsomming van voorgekomen problemen, oplossing voor een probleem, etc)? Persoon 1: Nee Persoon 2: ? Persoon 3: Persoon 4: Nee, afgezien van wat in het voorstel staat wat niet gebruikt wordt Persoon 5: Ja, in de helpdesk tool en daarnaast in MOM Persoon 6: Nee Persoon 7: Nee 15. Wordt er onderscheid gemaakt tussen normale en major problemen? Persoon 1: Ja, subjectief Persoon 2: Op gevoel wel Persoon 3: Persoon 4: Eigen besef Persoon 5: Voor de klant is elk probleem hetzelfde. Persoon 6: Ja vooral in de hoeveelheid mensen die er mee bezig zijn, in geval van hardware worden er leveranciers bij betrokken. Persoon 7: Er zit meer druk achter verder niet 16. Is er een proces voor het identificeren, opslaan, analyseren, reviewen en oplossen van problemen? Persoon 1: Nee Persoon 2: Nee Persoon 3: Persoon 4: Algemene werkwijze Persoon 5: Er is een soort van impliciet proces, of deze er altijd hetzelfde uitziet is de vraag Persoon 6: Nee Persoon 7: Algemene werkwijze 17. Wordt het oplossen van problemen gemonitord en geëvalueerd (periodiek / eventdriven)? Persoon 1: Nee Persoon 2: Middels helpdesk applicatie wellicht Persoon 3: Persoon 4: Nee Persoon 5: Gemonitord binnen MOM, een repeat count geeft aan hoevaak een incident is voorgekomen. Van een echte evaluatie is geen sprake. Persoon 6: Nee Persoon 7: Nee 18. Is er één persoon / team verantwoordelijk voor Problem Management? Persoon 1: Organisatie Persoon 2: Nee Persoon 3:


96

Persoon 4: Nee Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee

Service Level Management Het doel van Service Level Management is het succesvol aanbieden van IT Services en bestaande overeenkomsten te onderhouden en verbeteren. Centraal in Service Level Management staat de Service Level Agreement (SLA) waarin alle afspraken met de klant zijn opgenomen. Aan de hand van de SLA wordt vervolgens een dienst geleverd en gemeten, rapportages gemaakt en reviews gehouden voor het verbeteren van de dienst. Relevante bronnen Service Level Agreements Rapportages Contracten Vragen 10. Wordt er binnen de organisatie gebruik gemaakt van service level agreements? Persoon 1: Persoon 2: Persoon 3: Ja Persoon 4: Ze zijn er wel, ze staan in het contract. Dit is meer copy paste werk tussen contracten van klanten. Er is meer een service scope, welke dienst er afgenomen wordt. Er is niks per server speficiek met downtime, kritische waarde e.d. opgenomen (bij Ten Cate zijn de servers wel genoemd). Bij sommige contracten is een onderhoudswindow afgesproken, echter is dit ook niet altijd opgenomen. Persoon 5: We hebben SLA’s met de klant Persoon 6: Alleen richting klant Persoon 7: Ja er zijn SLA’s 11. Zijn de IT service behoeften van de klant gedocumenteerd? Persoon 1: Ja, contract Persoon 2: Ja, ligt in de SLA vast Persoon 3: Ja, alles in één SLA en dit is gelijk het contract Persoon 4: Uitgesproken dingen uit gesprekken worden soms wel genoemd in contracten, er is te weinig vastgelegd over beschikbaarheid. Persoon 5: Ja Persoon 6: Ik betwijfel het, betwijfel of het aan de klant gevraagd wordt. Persoon 7: Durf ik niet te zeggen, denk het niet 12. Worden de te leveren services en overeengekomen KPI‘s vastgelegd in een SLA? Persoon 1: Ja Persoon 2: Ja Persoon 3: Er wordt vastgelegd in de SLA wat de klant kan verwachten qua diensten en tijden dat de diensten beschikbaar zijn. Er is niks opgenomen over mogelijke downtime, timeto response, time to resolve Persoon 4: Zie boven Persoon 5: Ja Persoon 6: De te leveren service staat erin, durf niet te zeggen wat er nog meer in staat Persoon 7: Onbekend 13. Wordt de SLA met de klant geëvalueerd en herzien (periodiek / event-driven)? Persoon 1: Ja Persoon 2: Gebeurd Persoon 3: Nee, contacten worden stilzwijgend verlengt Persoon 4: Event-driven gebeurt dit wel eens Persoon 5: Weet ik niet


97

Persoon 6: Ja, event-driven. Bijvoorbeeld wanneer er gekke wijzigingen zijn die vereisen dat de SLA wordt aangepast. Persoon 7: Onbekend 14. Worden geleverde diensten vergeleken met SLA’s en acties ondernomen wanneer nodig? Persoon 1: Ja Persoon 2: Is niet helder, wie moet dat doen, ik ben verantwoordelijk, moet ook gebeuren, geen structuur Persoon 3: Intern wel, er wordt gekeken of er niet teveel of te weinig gebeurd. Persoon 4: Nee, bij Ten Cate misschien binnenkort Persoon 5: Geen inzicht, daar is het bedrijf te jong voor Persoon 6: Te weinig, ik heb bij sommige klanten het idee dat er te veel gebeurd, we zijn te klant vriendelijk Persoon 7: Soms wordt hier wel naar gekeken, bijvoorbeeld voor het uitvoeren van bepaalde werkzaamheden wordt gekeken of de betreffende werkzaamheden binnen de SLA vallen. 15. Wordt de levering van diensten gerapporteerd naar klanten (periodiek / eventdriven)? Persoon 1: Ja Persoon 2: Werkt technisch nog niet Persoon 3: Werkt technisch nog niet Persoon 4: Nee, performance rapportages gebeurd wel, availability reporting zijn we mee bezig Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee 16. Wordt de levering van diensten geëvalueerd met de klant (periodiek / event-driven)? Persoon 1: Ja Persoon 2: Durf het op dit moment niet, gaat wel gebeuren Persoon 3: Ja, in de periodieke gesprekken, bijvoorbeeld kienhuis hoving wekelijks. Echte evaluatie vindt niet plaats, als er iets niet goed is noemen zij het wel. De commercieële directeur gaat daar wellicht anders naar toe Persoon 4: Ja, met elke klant is er een periodiek overleg, gaat het goed, wat komt er aan, wat verwacht je van ons. Dit is echter meer een evaluatie van changes, zeg maar een beheeroverleg. Soms reactief als een klant iets vraagt. Persoon 5: Er wordt gerapporteerd naar klanten, periodiek. Er zijn geen gesprekken met de klant over de SLA, wel over voorgekomen incidenten. Persoon 6: Ja in de periodieke gesprekken neem ik aan Persoon 7: Volgens mij niet 17. Is er een proces voor het overeenkomen, uitvoeren en evalueren van SLA’s? Persoon 1: Ja, ligt vast in het contract Persoon 2: SLA ben ik nog niet mee geconfronteerd, alles gebeurd ad hoc Persoon 3: Nee, er is een standaard SLA Persoon 4: Nee, sowieso niet beschreven. SLA wordt vaak doorgelezen door de mensen na het opstellen (vaak is hij bij elke klant hetzelfde). Persoon 5: Klanten krijgen allemaal een SLA. De technische directeur stelt deze op waarna de SLA wordt opgeslagen op de schijf en door iedereen gebruikt kan worden. Een vast proces, nee. Persoon 6: Nee Persoon 7: Onbekend 18. Is er één persoon / team verantwoordelijk voor Service Level Management Persoon 1: Verschuift, meer persoon dan team Persoon 2: Ik ben daar verantwoordelijk Persoon 3: Commercieële directeur Persoon 4: De commercieële directeur is hier eigenlijk voor verantwoordelijk


98

Persoon 5: Management Persoon 6: Nee Persoon 7: De commercielen

Capacity Management Het doel van Capacity Management is het optimaliseren van de IT infrastructuur capaciteit en de ondersteunende organisatie zodat een kost efficiënte en constant availability van services gegarandeerd kan worden. Het analyseren en optimaliseren van de IT infrastructuur is een continue proces wat door Capacity Management ingevuld wordt. Relevante bronnen CDB Capacity Plan Vragen 8. Wordt er binnen de organisatie gebruik gemaakt van Capacity Management? Persoon 1: Persoon 2: Persoon 3: MOM doet dit voor ons Persoon 4: Ja, wel met de uren registratie, trends analyze met mom, reactief Persoon 5: Er wordt wat mee gedaan, we zien bijvoorbeeld dat de database groeit en de performance zakt Persoon 6: Ja, incidenteel Persoon 7: Ja er wordt wel wat mee gedaan 9. Zijn de huidige services geïdentificeerd en details en requirements gedocumenteerd (doel, resources, kosten, workload, plan, etc)? Persoon 1: Nee Persoon 2: Ga er vanuit dat dit gebeurd Persoon 3: Ja, de rollen van de services zijn gedefinieerd, daar omheen niks (resources e.d.) Persoon 4: Nee, als er iets nieuws komt proberen we het wel, in het verleden gebeurde dit niet. Persoon 5: Voor de monitoring service is dit er wel, verder niks Persoon 6: Nee Persoon 7: Nee niks over gedocumenteerd 10. Wordt de capacity van services en componenten gemonitord? Persoon 1: Ja, MOM Persoon 2: Ja Persoon 3: Ja, storage, CPU, e.d. Zaken als telefoonlijn capaciteit niet. Persoon 4: MOM Persoon 5: Ja, tuurlijk Persoon 6: Nee, niet voor capacity management Persoon 7: MOM doet dit voor ons. Dingen als de telefoonlijn wordt niet gemonitord. 11. Wordt capacity data en incident data geanalyseerd op trends en mogelijke incidenten in de toekomst? Persoon 1: Ja, MOM Persoon 2: Ja, merken performance problemen e.d. Persoon 3: Ja, maar dit is het proactieve beheer wat we doen. Het gebeurd wel ad hoc Persoon 4: MOM Persoon 5: In principe wel, er wordt bijvoorbeeld gekeken of we moeilijkheden krijgen in de toekomst. Persoon 6: Nee Persoon 7: Met report manager worden er wel rapporten gemaakt, bijvoorbeeld over de capaciteit van hardeschijven. Deze rapporten worden vervolgens ook naar klanten gestuurd. Het is zelfs zo dat hier richting de klant meer aandacht in wordt gestoken dan voor intern gebruik.


99

12. Worden aanpassingen aan capacity componenten uitgevoerd onder Change Management? Persoon 1: Ja Persoon 2: Nee Persoon 3: Changes worden ad hoc uitgevoerd, we doen dit gewoon zonder RFC of wat dan ook. Persoon 4: Voorzover change management aanwezig is, het gebeurd niet zomaar, er is enige planning en er wordt over nagedacht. Persoon 5: Nee, er moet ook eerst iets misgaan voordat er wat wordt aangepast. Persoon 6: Ja, dacht het wel, intern en voor de klant Persoon 7: Ja 13. Wordt het capacity plan op periodieke wijze geëvalueerd en herzien? Persoon 1: Ja Persoon 2: Is geen plan, op basis van de praktijk gebeurd dit wel Persoon 3: Nee, geen capaciteit plan Persoon 4: Nee Persoon 5: Ja, dit is een continue proces Persoon 6: Nee Persoon 7: Niet echt 14. Is er één persoon / team verantwoordelijk voor Capacity Management? Persoon 1: Eén van de operationele medewerkers is hiervoor verantwoordelijk Persoon 2: Nee Persoon 3: Nee Persoon 4: Nee, bij de klant een vast contact persoon Persoon 5: Eén van de operationele medewerkers houdt zich hier voornamelijk mee bezig. Deze rol is er door de tijd in gegroeid. Persoon 6: Nee Persoon 7: Nee

Availability & IT Service Continuity Management De eisen aan de beschikbaarheid van IT schieten omhoog. 24x7 is hedendaags een doodnormaal begrip en binnen SLA‘s vreemd. Dit vergt echter de nodige maatregelen om ook daadwerkelijk services 24x7 aan te bieden. Availability management houdt zich bezig met de dagelijks risico‘s die de availability van services bedreigt, bv stroomuitval, hardware failures, etc. IT Service Continuity Management houdt zich bezig met de uitzonderlijke risico‘s, bv brand, aardbevingen, lekkages, diefstal, etc. Relevante bronnen SLA‘s Continuity plan Vragen 15. Wordt er binnen de organisatie aandacht besteed aan availability en continuity? Persoon 1: Persoon 2: Persoon 3: Ja Persoon 4: Allebei wel Persoon 5: Ja Persoon 6: Ja Persoon 7: Ja 16. Wordt de availability van geleverde services afgestemd met de klant en opgenomen in de SLA? Persoon 1: Ja, SLA Persoon 2: In een zeker zin, ik heb het nog niet meegemaakt, ik kan me wel voorstellen dat het moet gebeuren


100

Persoon 3: Zou liegen als ik zeg nee, MOM zorgt voor availability, locatie is specifiek gekozen, Persoon 4: Nee, is niet keihard met cijfers afgestemd. Persoon 5: Of dit echt gezegd wordt weet ik niet, of dit in de SLA staat is mij onbekend Persoon 6: Ja Persoon 7: Onbekend 17. Zijn availability risico‘s en countermeasures voor services en componenten geïdentificeerd? Persoon 1: Impliciet, gesprekken, soms expliciet met advies Persoon 2: Clusters, redundantie, colocatie Persoon 3: Nee, klanten vragen er wel naar. Er is bijvoorbeeld een klant die zegt de beschikbaarheid (van de klant zijn systemen) beter moest. Hiervoor is een voorstel met kostenplaatje de deur uit gegaan echter de klant moet er wel voor bereid zijn. Intern is het allemaal geregeld (monitoren, redundant, ups), er is echter niks hard vastgelegd. Persoon 4: Niet beschreven, in het hoofd zijn deze aanwezig, mede door de ervaring op het gebied van IT Persoon 5: Door de omgevingen zijn veel maatregelen genomen, misschien met Virtu, mij onbekend Persoon 6: Gedeeltelijk maar niet alles denk ik, deels zal het ook wel gedocumenteerd zijn.. Intern is er over nagedacht of het papier staat betwijfel ik. Persoon 7: Nee er is geen identificatie van risico’s geweest 18. Worden availability risks op periodieke wijze geëvalueerd en zonodig aangepast? Persoon 1: Persoon 2: Ad hoc Persoon 3: Nee Persoon 4: Als de klant iets nieuws wil wordt er over gesproken, reactief wordt er intern over gesproken, soms in het maandagochtend overleg Persoon 5: Mij onbekend Persoon 6: Nee Persoon 7: Nee 19. Zijn recovery oplossingen voor geïdentificeerde availability risks aanwezig en getest? Persoon 1: Ja Persoon 2: ? Persoon 3: Nee Persoon 4: Geen disaster recovery plan, is wel een back-up e.d., meer op ervaring Persoon 5: Nee, we hebben wel service packs voor de servers e.d. Persoon 6: Ja, of het ook getest is betwijfel ik. Persoon 7: Nee 20. Wordt de availability van services gemonitord? Persoon 1: Ja Persoon 2: Persoon 3: Ja Persoon 4: Ja, MOM Persoon 5: Ja Persoon 6: Gedeeltelijk, hardware wordt grotendeels gemonitord, Persoon 7: Ja, intern en de klant wordt de availability gemonitord 21. Wordt de availability gerapporteerd, geëvalueerd en zonodig actie ondernomen (periodiek / event-driven)? Persoon 1: Ja Persoon 2: Nee Persoon 3: Ja Persoon 4: Standaard niet, mocht een klant vragen dan kan het wel met availability reporting, technisch is het nog niet 100% betrouwbaar


101

Persoon 5: Ja dat kan wel Persoon 6: Het gaat gebeuren in de rapportages, klanten vragen erom. Persoon 7: Ja, met MOM 22. Wordt (historische) availability data opgeslagen voor trend analyse? Persoon 1: Ja Persoon 2: Ja Persoon 3: Ja Persoon 4: Ja, tot een jaar terug wordt alles opgeslagen Persoon 5: Ja Persoon 6: Ja Persoon 7: Wordt wel opgeslagen, voor trend analyse kan het ook gebruikt worden maar of het ook daadwerkelijk gebeurd is een goede vraag.

23. Wordt er onderscheid gemaakt tussen availability en contingency risks? Persoon 1: Impliciet, kennis Persoon 2: Lastig, tuurlijk, continuitijd worden maatregelen voor genomen, ja Persoon 3: Intern is er niks geregeld Persoon 4: Nee, in het geval van contingency wordt er meer vertrouwt op Virtu, we betalen ervoor. Bij klanten is er niks en gebeurd het meer op ervaring. Persoon 5: Er wordt onderscheid in gemaakt Persoon 6: Nee Persoon 7: Ja 24. Zijn contingency risks geïdentificeerd? Persoon 1: Persoon 2: Op bepaalde manier wel, daarom is het ondergebracht zoals het nu is. Ben er niet bij betrokken geweest Persoon 3: Persoon 4: Nee Persoon 5: We hebben er rekening gehouden, dit is één van de redenen dat we bij Virtu in het pad zitten. Persoon 6: Nee Persoon 7: Nee 25. Is er een contingency plan aanwezig en getest in geval van incidenten? Persoon 1: Impliciet, kennis Persoon 2: Nee Persoon 3: Persoon 4: Nee Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee 26. Wordt het contingency plan op periodieke en event-driven wijze geëvalueerd en herzien? Persoon 1: Beperkt Persoon 2: Kan niet, plan is er niet Persoon 3: Persoon 4: Nee Persoon 5: Zie 11 Persoon 6: Nee Persoon 7: Nee 27. Wordt op periodieke wijze het contingency plan getest en geëvalueerd voor het verbeteren van het contingency plan? Persoon 1: Impliciet Persoon 2: Zie 12


102

Persoon 3: Persoon 4: Nee Persoon 5: Zie 11 Persoon 6: Nee Persoon 7: Nee

28. Is er één persoon / team verantwoordelijk voor Availability & IT Service continuity Management? Persoon 1: Nee Persoon 2: Nee Persoon 3: De technische directeur, risico’s van de continuïteit ligt bij de directeur Persoon 4: Allemaal Persoon 5: Naar mijn weten niet Persoon 6: Zou moeten, als het iemands is zou het de technische directeur moeten zijn Persoon 7: De directie

Workforce Management Werknemers zijn één van de belangrijkste pijlers voor een organisatie. Hierbij komt het aannemen en behouden van personeel evenals het trainen van competenties e.d. kijken. Workforce Management zorgt ervoor dat binnen de organisatie de juiste hoeveelheid en mensen met de juiste competenties komen te lopen voor het leveren van de services. Relevante bronnen Job descriptions Opleidingsplannen Competentieprofielen Vragen 9. Zijn omschrijvingen en competentieprofielen voor geleverde services opgesteld? Persoon 1: Nee Persoon 2: In de kop, weten goed dat een LBOer niet gebruikt kan worden, denk het haast wel, ervaring en gevoel Persoon 3: Nee Persoon 4: Nee Persoon 5: Ze gaan er vanuit dat er kennis is van Microsoft producten. Impliciet is bekend wat er nodig is. Persoon 6: Is wel bekend, niet altijd aanwezig en ook niet altijd gedocumenteerd Persoon 7: Nee 10. Zijn competentieprofielen van de werknemers aanwezig? Persoon 1: Nee Persoon 2: CV’s, in de hoofden van een aantal medewerkers Persoon 3: Nee, niks Persoon 4: Nee, iedereen heeft een CV, Microsoft transcript Persoon 5: Bij Microsoft wordt bijgehouden welke certificeringen je hebt. Buiten microsoft om is er niks. Persoon 6: Ja, men weet wel wat de kennis van elke werknemer is. Neem aan dat het gedocumenteerd is in het personeelsdossier, certificering enzo Persoon 7: CV is aanwezig van iedereen en daarnaast een microsoft profiel 11. Zijn bovengenoemde competentieprofielen verwerkt in een matrix en gecontroleerd op gaten? Persoon 1: Nee Persoon 2: Gebeurd in de praktijk, ad hoc Persoon 3: Nee Persoon 4: Nee


103

Persoon 5: Geen idee Persoon 6: Niet verwerkt, men weet het wel Persoon 7: Nee 12. Is voor elke werknemer een opleidingsplan aanwezig? Persoon 1: Ja is wel opgesteld Persoon 2: Opleidingen moeten gebeuren, wordt over gesproken, bij sommige mensen zijn ze er wel, zijn we te klein voor Persoon 3: Ligt persoonlijk, richtlijn is dat iedereen gecertificeerd is. Op het moment heeft iedereen ook een basis certificering. Persoon 4: Nee, mondeling worden wel eens dingen besproken Persoon 5: Plan is dat iedereen MCSEer is, examens worden geëist, minimaal MCSA Persoon 6: Nee Persoon 7: Een plan is een groot woord. Iedereen moet zelf zorgen dat zijn opleiding wordt bijgehouden. 13. Wordt de performance van werknemers periodiek geëvalueerd? Persoon 1: Ja, functionerings gesprekken Persoon 2: Nee, wel wekelijks overleg, functioneringsgesprekken Persoon 3: Ja tijdens functioneringsgespreken Persoon 4: Nog nooit een functioneringsgesprek gehad. Er is aangekondigd dat er functioneringsgesprekken / evaluatiegesprekken gaan komen. Persoon 5: Ja, beoordelingsgesprekken Persoon 6: Nog niet Persoon 7: Functioneringsgesprekken 14. Wordt de performance van werknemers geëvalueerd bij klanten? Persoon 1: Ja, klant zelf Persoon 2: Ad hoc basis Persoon 3: Nee, zou wel moeten vindt ik Persoon 4: Nee, er wordt wel eens gevraagd of een klant tevreden is. Persoon 5: Onbekend Persoon 6: Weet ik niet Persoon 7: Nee 15. Zijn er procedures aanwezig voor aanname van nieuwe mensen, mensen die de organisatie betreden, opleidingen, etc? Persoon 1: Ja Persoon 2: Geen procedures Persoon 3: Nee Persoon 4: Nee Persoon 5: Onbekend Persoon 6: Nee Persoon 7: Onbekend 16. Is er één persoon / team verantwoordelijk voor workforce management? Persoon 1: Ja, technische directeur Persoon 2: Technische directeur Persoon 3: Technische directeur Persoon 4: Directie Persoon 5: Management / Directie Persoon 6: Directie Persoon 7: Directie

Infrastructure Engineering Infrastructure Engineering heeft te maken met de ontwikkeling en het gebruik van standaarden en policies binnen een organisatie. Door de ontwikkeling van standaarden binnen een organisatie op een centrale plek af te handelen wordt eenheid en duidelijkheid geschapen en voorkomen dat verschillende standaarden ontstaan.


104

Relevante bronnen Intranet CMDB Service Catalog Gemaakte documenten (facturen, voorstellen, SLA‘s, etc) Vragen 7. Wordt er binnen de organisatie gebruik gemaakt van standaarden en policies? Persoon 1: Ja, standaard documenten + beleid Persoon 2: Er zijn een aantal standaarden voor offertes, maar nog niet goed genoeg Persoon 3: Ja, standaarden in de zin van support adres, omgeving van agents is uniform Persoon 4: Ja, servers zijn HP, RIS images, er is een huisstijl (layout / kopjes), we proberen er wat mee te doen. Persoon 5: Ja, er zijn documenten met een vaste layout (SLA, offertes etc), of iedereen zich daar aan houdt en deze daadwerkelijk gebruikt is de vraag. Er is geen bewuste policies. Persoon 6: Ja, voor offertes zijn er templates, er wordt weinig gebruik gemaakt van beleid. De organisatie is daarvoor waarschijnlijk te klein. Persoon 7: Ja, installatiedocumenten en rapportages. Voor documentatie en offertes weet ik het niet zeker. 8. Is de IT omgeving in kaart gebracht en vastgelegd welke onderdelen uitgesloten worden van IE? Persoon 1: Ja Persoon 2: Standaardisatie is nog niet mogelijk vanwege technische realisatie die nog niet goed is en organisatorisch ook nog niet Persoon 3: Nee Persoon 4: Nee Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee 9. Is er een centrale locatie voor het opslaan van standaarden en policies? Persoon 1: Ja Persoon 2: Zie 2 Persoon 3: Centrale locatie op het netwerk, dit geldt in het algemeen voor alle documentatie Persoon 4: Er is een centrale plek voor documentatie templates Persoon 5: Ja Persoon 6: Nee Persoon 7: Map op het netwerk 10. Is er één persoon / team, in combinatie met direct betrokken personen / teams bij de te ontwikkelen of aan te passen standaard / policy, verantwoordelijk? Persoon 1: Nee, organisatie en ad hoc Persoon 2: Zie 2 Persoon 3: Nee Persoon 4: Nee Persoon 5: Nee Persoon 6: Nee Persoon 7: Commerciële voor de offertes etc. Voor de rest is het hele team verantwoordelijk, niet een persoon of team 11. Is er een proces gedefinieerd en gedocumenteerd voor de ontwikkeling van standaarden en policies? Persoon 1: Ad hoc Persoon 2: Zie 2 Persoon 3: Nee


105

Persoon 4: Nee Persoon 5: Nee Persoon 6: Nee Persoon 7: Nee 12. Worden policies en standaarden geëvalueerd en zonodig aangepast (periodiek / event-driven)? Persoon 1: Nee Persoon 2: Zie 2 Persoon 3: Ja, de standaarden worden continue aangepast (hierdoor zijn het eigenlijk niet echt standaarden meer). Persoon 4: Nee Persoon 5: Het wordt wel aangepast echter altijd event-driven. Persoon 6: Nee Persoon 7: Soms, event-driven

Team model Binnen een organisatie worden verschillende rollen onderkend, elke rol heeft zijn eigen taken en verantwoordelijkheden, meerdere mensen kunnen dezelfde rol vervullen en meerdere rollen kunnen door één persoon vervuld worden. Het Team model van MOF reikt een logische opdeling qua rollen aan voor een IT beheerorganisatie. Vragen 3. Wordt er binnen de organisatie gebruik gemaakt van een rol verdeling voor het toekennen van taken aan personen? Persoon 1: Nee Persoon 2: Er is een commercieel directeur, een technische directeur, één medewerker is meer bezig met monitoring dan de rest, echter een daadwerkelijke taakverdeling en rolverdeling is er niet, dit moet veel beter Persoon 3: Directeur, commercieel directeur, beide hebben denk ik een vaste taakverdeling, er is alleen geen functieomschrijving. Verder is er helemaal niks. Er is wel behoefte aan, zeker vanuit mijzelf. Persoon 4: MOM gaat naar één persoon, consultancy naar twee operationele medewerkers, je kan zeggen dat er een rolverdeling is ingeslopen. Daarnaast is er een onderverdeling qua klanten. Op het gebied van functieomschrijvingen en rollen is er helemaal niks geregeld. Persoon 5: Nee Persoon 6: Ja eigenlijk wel, kennis aspect betreft. Exchange kennis zijn mensen voor, sql, mom, helpdesk e.d. zijn specifieke mensen voor. Twee operationele medewerkers buiten de deur buiten de deur, de andere drie haast nooit. Ik heb meer een algemene rol als backoffice ondersteuning, manusje van alles. Persoon 7: Er is misschien wel een rol verdeling maar niet specifiek, de rol verdeling is heel globaal. Een commercieel en een technische rol. Twee operationele medewerkers zitten misschien meer buiten de deur, de andere drie meer binnen maar dit is niet echt vastgelegd. 4. Welke rollen worden onderkend binnen de organisatie? Persoon 1: Persoon 2: Persoon 3: Persoon 4: Nee, geen functieomschrijving Persoon 5: Persoon 6: Persoon 7:


106

Bijlage 3 -

Vergelijking MOF en IT Service CMM

Hieronder wordt de gemaakte vergelijking tussen MOF en IT Service CMM gegeven. Het overzicht is gebruikt bij het opstellen van de interviews en de beschrijving van de huidige situatie. MOF

IT Service CMM Repeatable

Change Management

Configuration Management

IT Service CMM Defined

IT Service CMM Managed

IT Service Optimizing

Service Request and Incident Management Incident Management

Service Request and Incident Management

Service Desk

Service Request and Incident Management

Service Level Management

Service Commitment Management

Organisation Service Definition

Service Tracking and Oversight Subcontract Management System Administration Configuration Management

Configuration Management

Directory Services Administration Network Administration Problem Management Release Management

Problem Management Configuration Management

Service Monitoring and Control

Service Delivery Service Delivery Resource Management

Storage Management

Resource Management

Workforce Management

Training Program

Availability Management

Service Delivery

Infrastructure Engineering IT Service Continuity Management

Service Delivery

Security Administration Security Management Financial Management

Financial Service Management

Job Scheduling Capacity Management

Service Delivery Planning

Resource Management

Service Quality Assurance

Organisation Process Definition

Quantitative Process Management

Process Change Management

Organisation Process Focus

Service Quality Management

Problem Prevention

Intergroup Coordination Integrated Service Management

Bijlage 4 -

Validatie resultaten

Deze bijlage bevat de resultaten van de validatie die is uitgevoerd op de verkregen resulaten. Aan alle tabellen is een vierde kolom toegevoegd waarin het oordeel van de organisatie is opgenomen. Change Management & Release Management Aspect RFC‘s worden gebruikt voor het indienen van changes Changes worden gecategoriseerd Changes worden geprioritiseerd Changes worden gescreend op volledigheid en eerder voorkomen Changes worden geautoriseerd door een Change Manager / Cab / EC Er wordt per change een log bijgehouden waarin alle genomen beslissingen en uitgevoerde activiteiten worden bijgehouden Na het uitvoeren van de changes wordt een review gehouden om te kijken of de change het voorafgestelde doel gehaald heeft Elke release wordt geprioritiseerd en uitgevoerd volgens een geschreven plan Release Management automatiseert zoveel mogelijk stappen met behulp van applicaties Elke release wordt getest in een testomgeving voordat de daadwerkelijke release plaatsvindt. Voor elke release is een backout plan aanwezig in het geval een release teruggedraait moet worden. Voor de daadwerkelijke release vindt een release review plaats met betrokken personen en wordt de ‗go/no-go‘ decision genomen Gebruikers worden op de hoogte gehouden en gebracht van de release Standaard rapportages zijn beschikbaar voor rapportage van activiteiten binnen het proces Het gehele proces van changes en releases is gedocumenteerd

Configuration Management Aspect Er is een keuze gemaakt welke informatie en de hoeveelheid details worden opgenomen in de CMDB Er is een afbakening gemaakt van de IT omgeving die aangeeft welke componenten wel en welke componenten niet door Configuration Management beheerd worden Er is een CMDB aanwezig voor het opslaan van configuration items Alle geïdentificeerde componenten zijn opgenomen in de CMDB De CMDB kan geraadpleegd worden door belanghebbende Changes en releases worden gevolgd en verwerkt in de CMDB Op periodieke wijze wordt er een review uitgevoerd om de informatie in de CMDB te waarborgen Configuration Management activiteiten worden gerapporteerd Procedures binnen Configuration Management zijn gedocumenteerd

Bron

Status

Validatie

Status

Validatie

MOF – CM / ITSCMM MOF – CM MOF – CM / ITSCMM MOF – CM MOF – CM / ITSCMM MOF – CM MOF – CM MOF – RM / ITSCMM MOF – RM MOF – RM / ITSCMM MOF – RM / ITSCMM MOF – RM / ITSCMM MOF – RM / ITSCMM ITSCMM ITSCMM

Bron MOF / ITSCMM MOF / ITSCMM

MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM ITSCMM ITSCMM

System Administration Geen overzicht Security Administration & Management Aspect Policies zijn aanwezig binnen de organisatie waarin verschillende security aspecten zijn vastgelegd Een risico management proces is aanwezig om security risico‘s te minimaliseren Systemen worden gemonitord om eventuele incidenten te identificeren Audits worden uitgevoerd om zorg te dragen voor de implementatie van de aanwezige policies Een security incident proces is aanwezig in geval een incident zich voordoet. Identification technieken zijn geïmplementeerd Authentication technieken zijn geïmplementeerd Access control technieken zijn geïmplementeerd Confidentiality technieken zijn geïmplementeerd Integrity technieken zijn geïmplementeerd Nonrepudiation technieken zijn geïmplementeerd


Status

Validatie

Bron

Status

Validatie

Bron

Status

Validatie

Bron

Status

Validatie

MOF MOF MOF MOF MOF MOF MOF

MOF / ITSCMM MOF MOF / ITSCMM MOF / ITSCMM

MOF

MOF MOF MOF MOF

MOF MOF

Storage Management Aspect Data is geclassficieerd Op periodieke wijze worden backups gemaakt van data Een back-up strategy is ontwikkeld en gedocumenteerd waarin back-up en restore procedures staan beschreven

Bron

MOF

Network Administration Aspect Netwerkcomponenten worden gemonitord Netwerkincidenten worden verholpen volgens een vast proces

Validatie

MOF

Directory Services Administration Aspect Voor elke directorie is documentatie aanwezig en beschikbaar Cruciale resources voor de directories worden gemonitord Op periodieke wijze wordt er van elke directorie een back-up gemaakt Er is een data protection plan aanwezig waarin onder andere het maken van een back-up, het restoren van een back-up, kritische data en potentiele gevaren zijn besproken

Status

MOF

Service Monitoring and Control Aspect Voor gemonitorde componenten zijn health modellen opgezet Een applicatie is aanwezig voor het daadwerkelijke monitoren van de omgeving Optimalisatie van monitoring vindt plaats door analyze van historie en de implementatie van verbeterpunten Op binnenkomende meldingen wordt geacteerd, dan wel automatisch of doorverwezen naar incident management Key performance indicators zijn opgesteld om service monitoring and control te evalueren

Bron MOF

MOF MOF MOF

109

Data resources worden gemonitord Trend analyzes worden uitgevoerd voor performance en capacity van data resources Storage Management activiteiten worden gerapporteerd

MOF / ITSCMM MOF ITSCMM

Job Scheduling Aspect Het draaien van batch jobs wordt gemonitord Batch jobs zijn gedocumenteerd Optimalisatie van de batch job scheduler vindt plaats Procedures voor het job scheduling zijn gedocumenteerd (bv start en stop van een batch run, afhandelen van errors, aanpassen van de job schedule, etc)

Bron

Status

Validatie

Bron

Status

Validatie

Status

Validatie

Status

Validatie

Status

Validatie

MOF MOF MOF MOF

Service Desk Aspect Er is een applicatie aanwezig voor het opslaan, monitoren en bijhouden van onder andere incidenten, service requests en changes. Alle binnenkomende calls worden geregisteerd Rapportages zijn aanwezig voor het evalueren van de service desk De activiteiten en opzet van de Service Desk is gedocumenteerd

MOF / ITSCMM


Service Request & Incident Management Aspect

Bron

Een applicatie is aanwezig voor het opslaan en bijhouden van incidenten en service requests Incidenten en service request worden opgenomen in de applicatie en van daaruit opgevolgd Incidenten worden geprioritiseerd en geclassificeerd Incidenten met een hoge prioriteit / impact worden afgehandeld volgens een andere procedure (major incident) Incident Management kan gebruik maken van bestaande oplossingen voor incidenten die bekend zijn bij Problem Management Incidenten en service requests worden verholpen volgens een vast proces Het proces voor het verhelpen van incidenten en service requests is gedocumenteerd Betrokken personen worden op de hoogte gehouden van lopende incidenten en service requests Standaard rapportages zijn aanwezig voor Service Request and Incident Management

Problem Management Aspect

Service Level Management Aspect behoeften

MOF / ITSCMM MOF / ITSCMM MOF

MOF

MOF / ITSCMM ITSCMM MOF / ITSCMM ITSCMM

Bron

Problemen worden vastgelegd in een applicatie Problemen worden gecategoriseerd en geprioritiseerd Problem Management vindt op proactieve en reactieve wijze plaats Templates en rapportages zijn aanwezig voor Problem Management

De IT Service gedocumenteerd

MOF / ITSCMM

MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM ITSCMM

Bron van

de

klant


zijn

ITSCMM

110

Een service catalog is opgesteld van alle services in gebruik bij een klant Een SLA is opgesteld met de klant waarin de dienst is beschreven Geleverde diensten en services worden gemonitord Monitoring data wordt gebruikt voor rapportage doeleinde Op periodieke wijze vindt evaluatie van de SLA plaats Procedures zijn aanwezig waarin wordt beschreven hoe om te gaan met leveranciers / subcontractors (bijv selectie, reviews, etc)

MOF MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM MOF / ITSCMM ITSCMM

Capacity Management Aspect Resources worden gemonitord op performance en thresholds Analyze van verzamelde data vindt plaats in het kader van capacity planning Resources worden geoptimaliseerd Een Capacity Database is aanwezig voor het opslaan van capacity data Een capacity plan is aanwezig waarin de benodigde resources zijn afgewogen Periodiek wordt het capacity plan geevalueerd en herzien door verschillende personen in de organisatie Rapportages zijn aanwezig voor het rapporteren van Capacity Management aangelegenheden

Bron


Validatie

Status

Validatie

Status

Validatie


Bron MOF MOF / ITSCMM MOF

MOF MOF

MOF

Bron MOF MOF / ITSCMM MOF MOF / ITSCMM

Infrastructure Engineering Aspect De scope voor standardisering is vastgesteld Standaarden en policies zijn geïnventariseerd en ontwikkeld Een centrale locatie is aangewezen voor het publiceren van standaarden en policies Op periodieke wijze worden standaarden en policies geëvalueerd en zonodig herzien

Status

MOF / ITSCMM MOF / ITSCMM

Workforce Management Aspect Functieomschrijvingen zijn opgesteld voor alle werknemers Benodigde competencites voor het leveren van de services zijn in kaart gebracht De performance van werknemers wordt geëvalueerd De organisatie beschikt over een trainingsplan

Validatie

MOF / ITSCMM

Availability & IT Service Continuity Management Aspect Kritieke services en componenten zijn geïdentificeerd en availability requirements zijn hiervoor bekend Availability risico‘s worden geminimaliseerd voorzover de maatregelen binnen proporties zijn Availability risico‘s die niet door Availability Management worden beheerd zijn opgenomen in het contingency plan Continuity risico‘s zijn geïdentificeerd en mogelijke oplossingen zijn gezocht Een contingency plan is geschreven waarin beschreven wordt hoe te handelen in het geval van een incident Het contingency plan wordt op periodieke wijze geevalueerd

Status

MOF / ITSCMM

Bron MOF MOF MOF MOF

111

Bijlage 5 -

Aanbevelingen (Vertrouwelijk)

De aanbevelingen zijn in een vertrouwelijk document geplaatst en beperkt inzichtelijk.


112

MOF implementatie binnen The Backbone

Recommend Documents