Er is reden voor een feestje: het Microsoft s Operations Framework

Methodieken Ervaringen in de praktijk met het Microsoft Operations Framework

5.3

Ervaringen in de praktijk met het Microsoft Operations Framework

285

r is reden voor een feestje: het Microsoft’s Operations Framework (MOF) mag naar de basisschool, want het is onlangs 5 jaar oud geworden. Een leeftijd van 5 jaar betekent ook een lustrum en daarmee is er reden voor een terugblik. Dit doen we door in te gaan op de achtergrond van MOF, de diverse versies en de toekomst. Belangrijker dan de theorie is de terugblik op het gebruik van MOF, met de nadruk op cases die zich buiten Microsoft zelf afspelen. Dit artikel kiest dan ook een pragmatische benadering en zal aan de hand van enkele (anonieme) cases de praktische kant belichten. Maar eerst een korte inleiding op de actuele zaken rondom MOF.

E

Auteurs: Rudolf Liefers, Marjo van Bergen, Martin Sih, Caro Vermeule - Capgemini

KORTE INTRODUCTIE MOF Ontstaan MOF zag het levenslicht in de laatste jaren van de vorige eeuw. Het was het antwoord van Microsoft op de vraag hoe de IT-organisatie ervoor kan zorgen dat de kwaliteit van haar op Microsoft technologie gebouwde services op het gewenste peil blijft. In Redmond groeide het besef dat voor een goede IT-dienstverlening meer nodig was dan goed werkende technologische oplossingen. Hiertoe werd, samen met diverse grote en kleine marktpartijen, een framework specifiek voor beheer en exploitatie van Windows technologie ontwikkeld. Het Microsoft Operations Framework levert concrete bouwstenen (zoals kant-en-klare procesdocumentatie), waarmee organisaties hun beheer voor bedrijfskritische omgevingen kunnen inrichten en daardoor die omgevingen beter kunnen beheren. MOF bestaat deels uit een aantal componenten van ITIL en is verrijkt met een aantal specifieke componenten van Microsoft voor de inrichting van de beheerprocessen. Microsoft bouwt bewust voort op ITIL en stelt dat het ITIL

zowel adopteert als adapteert. MOF is ontworpen om breed te kunnen worden ingezet en zou dus ook geschikt zijn voor andere omgevingen dan die van Microsoft. Structuur Het Microsoft Operations Framework bestaat uit drie modellen: het procesmodel, het Team Model en het Risicomodel. Alledrie hebben ze enerzijds veel raakvlakken met ITIL en anderzijds deels hun wortels in andere concepten van Microsoft, zoals het Microsoft Solutions Framework. In voorgaande edities van dit boek is dit al uitvoerig belicht en we verwijzen dan ook naar die artikelen, of naar www.microsoft.com/mof voor details.

5

Nieuwe versie Medio 2004 is versie 3.0 van het MOF verschenen. Deze versie is een majeure update van de vorige versie. Er is veel aangepast, en er zijn praktijkervaringen opgenomen in het model. Ook zijn er wijzigingen voortgekomen uit wijzigingen in andere modellen van Microsoft, zoals het Microsoft Solutions Framework (MSF).

IT Service Management, best practices Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net

MODEL

Aanpassingen in versie 3

Procesmodel

Aangepaste Service Management Functions: • Security Management is toegevoegd, als aanvulling op het reeds bestaande Security Administration. • Infrastructure Engineering is toegevoegd, als aanvulling op een “witte plek” en om consistent te blijven met ITIL. • Print & Output Management is onderdeel geworden van Storage Management.

286

Aangepaste Quadrants/Reviews: • De namen van de Reviews zijn aangepast. Team Model

• Er is een Role Cluster Team toegevoegd, namelijk ‘Service’. Dit bevat taken en rollen voor het management van zowel interne als externe klantrelaties. • Er is een extra matrix toegevoegd die mensen, Team Roles en SMF’s beter met elkaar verbindt.

Risicomodel

Het Risk Model is hernoemd naar Risk Management Discipline, waardoor het meer generiek toepasbaar wordt. Ook is een betere relatie gelegd naar/met MSF, doordat de koppeling met Risk Management uit MSF is aangebracht. Hierdoor is MSF overigens ook meer in lijn met Prince2.

Tabel 1 Wijzigingen in de derde versie van het MOF

De bovenstaande wijzigingen laten zien dat het MOF een levend model is. MOF wordt binnen Microsoft zelf op grote schaal toegepast en de ervaringen uit deze praktijk worden beschreven in het model. Daarnaast is

Change Initiation Review

Release Readiness Review

ing

MOF

rt ing

at

Opt im

ing

po Sup

Service Desk Incident Management Problem Management

Change Management Configuration Management Release Management

Ch a

ing iz

ng

Service Level Management Financial Management Capacity Management Availability Management IT Service Continuity Mgmt. Workforce Management Security Management Infrastructure Engineering

SLA Review

een groot aantal partijen betrokken bij de verdere ontwikkeling ervan en zorgt de alignment met ITIL ervoor dat MOF regelmatig wordt aangepast.

e Op

Operations Review

r

System Administration Security Administration Service Monitoring & Control Directory Services Administration Network Administration Storage Management Job Scheduling

Figuur 1 Het MOF Proces Model en MOF in IT service management functies (SMF’s)

Copyright protected. Use is for Single Users only via a VHP Approved License. For information and printed versions please see www.vanharen.net


Change Management Release Engineering Configuration control / asset management Intellectual property protection Software distribution/licensing Network and system security Quality assurance Intrusion detection Virus protection Audit and compliance administration Release Contingency planning

SLA drafting / negotiation Service catalog management SLA review Service improvement initiation Customer relationship management Service level management

Security

Service

Partner

Infrastructure

Managed service outsourcers Software / hardware suppliers Maintenance vendors Environment support Training partners

Operations Messaging operations Database operations Network administration Monitoring / metrics Availability management

Support

287

Enterprise architecture Infrastructure / systems engineering Capacity management Cost / IT budget management Resource and long-range planning

Service desk / help desk Production / production support Problem management Service level management

Figuur 2 MOF team-rollenclusters en hun afbeelding op het MOF Proces Model

Status in de markt Een aantal organisaties is bezig met de implementatie van MOF en zij worden bijgestaan door partijen als PinkRoccade, Capgemini en Fujitsu. De begin 2004 verwachte ‘MOF-boost’ is nog even uitgebleven, althans in Nederland. In andere landen begint MOF meer aan te slaan. De Nederlandse ‘voorsprong’ op ITIL-gebied lijkt hier de wet van de remmende voorsprong te bewijzen.

• Microsoft is bezig met het verder uitbouwen van haar Dynamic Systems Initiative. Hierin moeten uiteindelijk alle beheeroplossingen, zowel tools als procesmodellen, van Microsoft gaan samenkomen. Tools mogen hierin niet gaan overheersen ten nadele van de procesmatige benadering van beheer. Het is dan ook aan de service managers om hier de vinger meer dan goed aan de pols te houden.

BESCHRIJVING CASES Toekomstige ontwikkelingen Ontwikkelingen die verwacht worden in de komende 12-18 maanden zijn o.a.: • Een uitbreiding/aanpassing van de EXINcertificatie voor de ITIL-kwalificaties. Deze worden momenteel herzien en de ordening van het MOF Procesmodel vormt hiervoor een belangrijk uitgangspunt. Overigens wordt verwacht dat Microsoft zelf ook met een MOF Certificaat zal komen. • ITIL ondergaat in 2005/2006 een belangrijke update en het valt te verwachten dat veel MOF-content terug zal komen in ITIL versie 3. MOF heeft immers op het gebied van IT Operations veel toegevoegd aan het beheerwerkveld en ITIL moet een weerspiegeling van de markt vormen.

5

Case: “Onderhoudsbedrijf” Probleemstelling Een onderhoudsbedrijf met meerdere vestigingen in Nederland verrichtte diverse soorten klein en groot onderhoud aan haar transportmiddelen. Dit gebeurde 24 uur per dag en 7 dagen per week, zowel gepland als ongepland. Daarnaast diende het onderhoudsbedrijf ervoor te zorgen dat het juiste onderdeel op het juiste moment op de juiste locatie is, met de juiste monteurs. Dit stelde hoge eisen aan de logistiek van het bedrijf. Deze kernactiviteit werd ondersteund door de afdeling IT-beheer.


288

De IT-infrastructuur werd totaal gerenoveerd. Daarnaast werd het IT-beheer gecentraliseerd met het oog op kostenbesparingen. De invoering van de nieuwe infrastructuur moest een hoger dienstverleningsniveau opleveren, wat gewaarborgd moest worden door Service Level Agreements. De afdeling ITbeheer, die ook de huidige infrastructuur beheerde, ging de nieuwe infrastructuur vanaf één centrale locatie beheren. De behoefte aan een sterke, goed geëquipeerde beheerafdeling was dus zeer groot, niet in het minst gezien de hoge investeringen in de renovatie en de centralisatie. Bovengenoemde doelstellingen waren ambitieus te noemen, omdat de IT-afdeling op het gebied van kennis en kwaliteit van dienstverlening nog niet op het gewenste niveau was. Bij de IT-beheerders bestond geen gemeenschappelijk beeld over het gewenste serviceniveau en dat werd versterkt door de klant, die geen toereikend beeld had van de kwaliteit die IT zou kunnen leveren of zelfs daadwerkelijk leverde. Dat de IT-beheerafdeling meerdere keren met wisselend succes met ITIL had gewerkt was een extra complicerende factor. Bovendien bestonden er de nodige twijfels over het niveau van het beheer van de infrastructuur, zowel bij de beheerders zelf, als bij het management en bij klanten. Keuze voor MOF De keuze voor MOF was ingegeven door het daarin goed beschreven operationele deel, de goede aansluitmogelijkheden op al ingerichte ITIL-processen bij andere afdelingen en de beschikbaarheid van (betaalbare) tools. Heel bewust werd ervoor gekozen om te starten met het procesmodel, vanwege de goede aansluiting met het huidige, grotendeels operationele werk van de beheerders. Het Team Model en het Risicomodel leken in eerste instantie te ver van de beheerders af te staan. Aanpak Om een gemeenschappelijk draagvlak te creëren bij de beheerders werd gekozen voor het ‘neuzen richten’ aan de hand van een

aantal workshops. Hierin kwamen alle partijen tot een top 3 van prioriteiten, namelijk monitoring, diagnose en communicatie. Zowel de klanten, het management als de beheerders hadden belang bij inzicht in de status van applicaties en infrastructuren (monitoring). Alle partijen wilden weten wat nu waardoor werd veroorzaakt en hoe dat kon worden verbeterd (diagnose). De klanten en het management hadden een zeer sterke wens om op tijd de juiste informatie over de IT-infrastructuur te ontvangen. De beheerders zelf hadden dringend behoefte aan informatie van voornamelijk de klanten over hun bedrijfskritische momenten en applicaties (communicatie). Deze conclusies bevestigden de initiële beelden die de partijen van elkaar hadden en gaven eens te meer aan dat het opstellen van service level agreements zeker ging helpen. Op het moment dat bij deze partijen in grote lijnen dezelfde eisen en wensen bestonden ten aanzien van de IT-beheeromgeving, werd hen gevraagd om deze zaken voor zichzelf verder in te vullen. Tevens werd hen gevraagd aan te geven hoe zij de andere partijen van de voor hen noodzakelijke informatie konden voorzien. Dit artikel gaat verder niet in op de eisen en wensen van klanten en management, maar focust op de situatie rondom de IT-beheerders. Workshops In de workshops werden diverse risico’s en bekende calamiteiten met het management, de klanten en de beheerders besproken. Door deze confronterende aanpak werd een aantal opgebouwde ‘muren’ geslecht. Voor de beheerders volgde na de eerste workshop een aantal ‘eigen’ workshops. Hierin was het aan de beheerders, samen met externe consultants, om aan te geven wat zij nodig dachten te hebben om hun eigen werk te kunnen doen en de juiste informatie aan klanten en management te verstrekken. De workshops gingen expliciet in



op het procesmodel. De andere twee modellen werden niet bewust uitgewerkt, maar waar het ter sprake kwam werd wel een aantal teamrollen uit het Team Model ingevuld. In deze workshops kwamen ook de al eerder vermelde risico’s en calamiteiten aan de orde en werd voor een meer probleemgestuurde oplossingsmethode gekozen. De praktijkbenadering had de voorkeur boven de theorie. Voor elk geïdentificeerd probleem werd onderzocht hoe dit met delen van het procesmodel zou kunnen worden opgelost en welke tooling daarvoor nodig was. In deze workshops lag daarom de nadruk op het operating- en het supporting kwadrant, en het configuratiemanagement (uit het changing kwadrant). Structuur MOM (Microsoft Operations Management) Workshop Bespreek hier welke services geleverd worden, en welke vorm van monitoren hierop van toepassing is. Dit is een goede insteek om feeling te krijgen met het systeem, voor detailniveau kunnen het beste de management packs van MOM worden gebruikt. Welke service leveren we? - Inventariseer de te leveren services. Te denken valt aan Network Devices, Firewall Services, en Applicatie Services.

Wat willen we per service weten? - Welke informatiebehoefte is er? (CPUgebruik, schijf vol, et cetera) - Welke servers betreft dit? - Boven welke waarde is de informatie relevant, met andere woorden wat is de threshold? Bijvoorbeeld als de schijf voor 90% vol is. - Wanneer en met welke frequentie is monitoren wenselijk? Bijvoorbeeld alleen tijdens kantooruren en dan ieder uur.

289

In de workshops werd gewerkt met het generieke procesmodel Operational Management zoals in figuur 3 wordt weergegeven. Van diverse kanten komen gebeurtenissen en vragen op het Operational Managementproces af. Enige voorbeelden ter verduidelijking: • Incident - er is een hardware-storing op een server. Zoiets gebeurt onverwacht (monitoring ontdekt deze gebeurtenis). Afhankelijk van welke server het is en wat er aan de hand is (analyse), wordt een bepaalde actie gestart (actie). Uiteraard moet vastgelegd worden dat het incident is opgetreden, hoe lang het heeft geduurd en welke acties zijn ondernomen (rapportage). • Dagelijks - er komt een nieuwe user bij. Het verzoek komt binnen op de service

5 Dagelijks beheer

Monitoring Handmatig

Automatisch

Analyse

Inc

ide

nt

Handmatig

Automatisch

Actie Handmatig

Automatisch Beleid

Rapportage Handmatig

Automatisch

Processondersteuning Operationeel Management

Figuur 3 Generiek proces van Operational Management


290

desk (monitoring). Er wordt gekeken wat er precies gedaan moet worden (zijn alle gegevens bekend, moet er ook een mailbox komen). Vervolgens wordt de nieuwe user aangemaakt (actie), en wordt teruggekoppeld dat de nieuwe gebruiker is aangemeld en aan het werk kan (rapportage). • Beleid - het beleid rondom diskquota wordt gewijzigd. Dit resulteert in een Request For Change (RFC), die vervolgens moet worden uitgevoerd. Wat er gedaan moet worden, en of zoiets zomaar kan, moet worden uitgezocht (analyse), en daarna uitgevoerd (actie). Daarnaast vindt rapportage plaats over de wijziging. Vervolgens moet gemonitored worden of een en ander goed is verlopen. • Rapportage - vanuit het Service Level Management proces komt de vraag naar de performance van de afgelopen maand. Deze vraag kan alleen maar beantwoord worden als er gemonitord is, en de resultaten daarvan zijn vastgelegd. Sommige acties kunnen van invloed zijn op de performance en daarom is het van belang te weten welke acties hebben plaatsgevonden.

de applicatie traag reageert, en bedenken en beslissen hoe een nieuwe applicatie beschikbaar gesteld zal worden.

Al deze zaken doorlopen, al dan niet geautomatiseerd, het proces van monitoring, analyse, actie en rapportage, waarbij op diverse punten de stap van automatisch naar handmatig en vice versa kan worden gemaakt.

Op basis van een aantal specificaties werden tools, zoals MOM voor monitoring en Spotlight voor diagnose geselecteerd en aangeschaft. MOM en Spotlight werden gekozen vanwege hun goede aansluiting met de MOF-processen en omdat zij de omgeving die voornamelijk uit Microsoft componenten bestaat kwalitatief goed en proactief kunnen beheren. Deze tools werden nu door de beheerders geïmplementeerd. Ook deze implementaties vonden plaats in de vorm van workshops. Voor de Microsoft specifieke zaken (MOM) is daarnaast ook de hulp ingeroepen van een Microsoft consultant. Leerpunt hieruit was onder andere dat de voorgeschreven implementatiestrategie voor MOM niet goed bruikbaar was. Deze strategie werd aangepast tot een voor deze situatie meer succesvolle werkwijze.

De monitoring fase zal zoveel mogelijk geautomatiseerd verlopen. Gezien de omvang van de omgeving, meer dan honderd servers, 1350 gelijktijdige gebruikers, 7 keer 24 uur ondersteuning voor bepaalde services en applicaties, is handmatig monitoren ondoenlijk. Afhankelijk van hoe een en ander wordt ingericht, zal analyse in meer of mindere mate geautomatiseerd verlopen. Dit geldt ook voor de actiefase. Sommige zaken kunnen automatisch worden geanalyseerd en afgehandeld, zoals blokkering van het opslaan van ongeoorloofde bestandsformaten en het verwijderen van virussen uit email. Andere zaken dienen grondig te worden geanalyseerd en handmatig afgehandeld. Bijvoorbeeld uitzoeken waarom een bepaal-

Uit bovenstaande blijkt dat het inrichten van Operations Management heel dynamisch is, wat niet hetzelfde is als chaotisch. Door het proces goed te structureren, en de discipline op te brengen om gestructureerd te werken, blijft het goed beheerbaar en beheersbaar en wordt proactief beheer mogelijk. Goede tooling helpt mee om die beheerbare, beheersbare en proactieve omgeving te creëren. Toolselectie en –inrichting Bij de invoering van het procesmodel stond ondersteuning door tooling centraal en werd met de beheerders een toolselectie uitgevoerd. Cruciaal bij de implementatie van de monitoring tooling was de vraag: “Wat is er nodig om te voorkomen dat jij als beheerder uit bed wordt gebeld?” Dit had tot gevolg dat er meer naar proactief beheer werd gekeken en het zorgde voor een focus op de dienstverlening en de verbetering daarvan.

De implementatietijd van de gekozen tools was relatief kort, wat ten goede kwam aan het veranderingsproces en de flexibiliteit



waar de beheerders, de klanten en het management om vroegen. De gekozen implementatievorm aan de hand van workshops verlengde wel de korte implementatietijd van de gekozen tools. Deze tijd werd echter dubbel en dwars terugverdiend door de hogere acceptatiegraad en een beter begrip van de tools. Het nut van beheerprocessen Gaandeweg realiseerden de beheerders zich dat een bepaalde mate van structuur en, ondanks hun wisselende ervaringen met ITIL, het herinrichten van hun werk met behulp van best practice beheerprocessen toch best zinvol zou zijn. Dit draaide later nog bij naar een (gematigd) enthousiasme voor het volledige procesmodel van MOF. Langzaam ontstond aandacht voor andere kwadranten en de wisselwerking daartussen. Deze vooruitgang maakte het ook mogelijk om de stap naar het Team Model te maken. Dit werd onder andere duidelijk bij het samenstellen van checklists, bijvoorbeeld die in onderstaande tabel.

1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14.

De combinatie van het procesmodel met de monitoring en diagnose-tooling versterkte dit nog meer. Daarnaast was het voor de beheerders mogelijk met MOF, MOM, Spotlight (en andere tooling) de communicatie een heel stuk duidelijker en tijdiger te verschaffen. De beheerders kwamen ‘in control’.

291

Resumerend Net als in veel ITIL-trajecten werd MOF ingezet als verzameling ‘best practices’ en werd van MOF alleen gebruikt wat echt nodig was, gelet op de problemen, de wensen op korte termijn en de veranderingen op langere termijn. Cruciaal in dit hele traject was het verbeteren van de dienstverlening, met, door, en voor de beheerders, de klanten en het management. MOF kon daar goed voor worden gebruikt omdat MOF en daarin opgenomen modellen voor iedere groep herkenbare aspecten en praktische waarde hadden. Door de gevolgde methode waren de beheerders steeds meer in staat om zelf de dienstverlening te verbeteren. Periodiek werd geëvalueerd wat binnen het proces goed ging en wat verbeterd kon worden. In eerste instantie werden deze evaluaties en de daar-

System administation taken Frequentie Tijd benodigd Beheer delegate control van AD en Exchange en CTX Nieuw te beheren componenten accepteren en toevoegen op de diverse aspecten van beheer Oude compenten verwijderen op de diverse aspecten van beheer Procedure beheren: nieuwe componenten toevoegen en oude componenten verwijderen Versiebeheer testomgeving Versiebeheer acceptatieomgeving Software library beheer bijhouden Beheer delegate control van AD en Exchange en CTX Opleveringen van releases accepteren Oude server verwijderen op de diverse aspecten van beheer Verantwoordelijk voor operations review Contact met supporting en changing quadrant en andere ITIL processen Rapportage operations review Operations review vanuit andere processen via SMO naar service manager

5

Tabel 2 Voorbeeld van een checklist


292

uit voortvloeiende verbeteracties door externe consultants geleid, maar gaandeweg werden deze initiatieven meer door de beheerders zelf opgepakt en verder uitgevoerd. De beheerders kregen ook de taak deze verbeteracties met de klant te overleggen en voor en na de uitvoering te communiceren. Het Team Model heeft bij het begin van dit traject niet de hoogste prioriteit gekregen. Maar door het inrichten van het procesmodel zijn diverse delen van het Team Model zeer nuttig gebleken. Van het Team Model zijn de Team Rollen operations, support, partner, security, en infrastructuur voor 80% geïmplementeerd. Ook het Risicomodel is niet als zodanig benoemd, maar bij de gekozen vorm van workshops is consequent een risico (of calamiteit) als voorbeeld genomen. Dit heeft gezorgd voor een beperkte introductie van dit model. Case 2: consumer products bedrijf Introductie De tweede case betreft de Europese verkooporganisatie van een multinational in consumer products. De organisatie bestond uit een Europees hoofdkantoor en nationale verkooporganisaties in vrijwel alle Europese landen. Tot voor kort opereerden de landenorganisaties vrijwel geheel zelfstandig, ook op ITgebied. Tot dan toe had iedere nationale organisatie gewerkt met eigen processen en procedures toegespitst op de eigen specifieke omgeving. Voor de kleinere vestigingen ontbraken duidelijk omschreven procedures en verantwoordelijkheden meestal geheel. In het kader van het verlagen van de kosten was men bezig om de IT-omgeving te stroomlijnen en het beheer te centraliseren in het hoofdkantoor. Er was besloten een geheel nieuwe IT service management organisatie op te zetten, die gebaseerd was op ITIL. In dit streven paste de invoering van een gecentraliseerde kantoorautomatiseringinfrastructuur gebaseerd op de Microsoft productlijn: Active Directory, SMS 2003, MOM en MIIS.

De pan-Europese invoering van Active Directory werd begin 2004 zo goed als afgerond. Daarna zou worden gestart met de invoering van SMS 2003. Dit pakket zou moeten worden gebruikt voor gecontroleerde OS installatie en software distributie, ter ondersteuning van asset management en ter ondersteuning van de IT service desk (remote control). Probleemstelling Evenals bij eerdere infrastructuurprojecten lag de nadruk bij het SMS 2003 project in eerste instantie op de techniek. Vrij snel na de start werd onderkend dat ook de processen en de beheerorganisatie belangrijke aspecten waren die moesten worden meegenomen. De reden dat de beheerorganisatie voor SMS extra aandacht kreeg was grotendeels te danken aan de opgedane ervaringen met het kort daarvoor geïmplementeerde pan- Europese Active Directory. In dat traject was het opzetten van een beheerorganisatie niet meegenomen, dat wil zeggen: het bevond zich wel in het ontwerp maar werd niet concreet uitgewerkt en geïmplementeerd. Redenen hiervoor waren de abstracte ontwerpen voor de beheerorganisatie en een tekort aan draagvlak voor gecentraliseerd beheer. Omdat de beheerorganisatie voor Active Directory niet goed van de grond kwam, werden de beheerverantwoordelijkheden niet belegd en ervaren. De overdracht van beheer van het projectteam naar de beheerafdeling vond derhalve niet goed plaats. Hierdoor werd het projectteam genoodzaakt om langer te blijven opereren. Men was vastbesloten om eenzelfde situatie bij de invoering van SMS te voorkomen. De invoering van SMS 2003 met de bijbehorende geïntegreerde aanpak van techniek, processen en organisatie was in dit kader een belangrijke testcase. Vooral release management van nieuwe software en patches werd gezien als een belangrijk proces, omdat tot op dat moment binnen de organisatie nog geen formeel en centraal release management proces bestond voor dit type omgevingen, feitelijk de kantoorautomatisering-applicatielaag.



Het voor dit doel inrichten van release management leek op het eerste gezicht schieten met een kanon op een mug. Maar het beheer van 10.000 werkplekken vergde nu eenmaal een andere aanpak dan het beheer van 100 werkplekken.

Hierbij kregen vooral release management en het inrichten van operationeel beheer van de SMS infrastructuur prioriteit. Randvoorwaarde was dat het ontwerp voor het beheermodel zoveel mogelijk zou aansluiten bij de bestaande beheerorganisatie.

Eerdere ervaringen Binnen een andere projectstream was al gestart met het opzetten van een geheel nieuwe IT service management organisatie. Daarbij werd begonnen met het inrichten van incident management. Hierbij bleek dat de invoering van de processen werd gefrustreerd. De lokale werkwijzen bleken bijvoorbeeld niet te vertalen naar bruikbare processen en procedures in pan-Europees verband. Ook boden de nationale organisaties de nodige weerstand, wat onder andere veroorzaakt werd door culturele verschillen en het gebrek aan vermogen om over de landsgrenzen heen te kijken.

Voor het uitwerken van de beheerprocessen, taken en rollen kwam men al snel uit bij MOF. Belangrijk argument hierbij was dat de MOFmethodiek reeds de juiste handvatten bevat om deze zaken snel en concreet in te vullen. Vooral het Team Model en de change management SMF’s bleken goed toepasbaar te zijn. Ook was het vrij gemakkelijk om met behulp van het Team Model gedefinieerde rollen te beleggen bij de diverse beheerteams. Dit laatste was een belangrijk pluspunt gezien de in de nabije toekomst geplande reorganisaties.

Uiteindelijk werd een model gekozen waarbij vier op taal gebaseerde regio’s werden gedefinieerd: Latin, Nordic, Germanic en UK, met ieder hun eigen virtuele serviceorganisatie, waarbij de teamleden zich over het algemeen in hun land van herkomst bevonden. Eenduidige procesinrichting was echter nog steeds een wens. Keuze voor MOF Op basis van de hiervoor beschreven ervaringen werd besloten dat het beheer en de bijbehorende processen van de SMS-omgeving een belangrijk onderdeel van de implementatie zou worden. Daarna werd gezocht naar een passende methodiek. In eerste instantie wilde men aansluiten bij het lopende project voor het opzetten van een nieuwe IT service management organisatie. Dit bleek niet de gewenste aansluiting op te leveren. Een tweede insteek moest het beheervraagstuk breder neerzetten, omdat snel bleek dat op meer onderdelen binnen de organisatie beheer niet voldoende ingericht bleek. Deze insteek werd snel te omvangrijk, waarna de scope van het ‘beheerproject’ werd beperkt tot die aspecten die direct aan SMS 2003 gerelateerd waren.

293

Aanpak Omdat het MOF gedachtegoed relatief onbekend was binnen de organisatie werd een workshop georganiseerd om een en ander te verduidelijken. Dit betrof vooral het MOF Team Model en een aantal MOF-begrippen zoals de Definitive Software Library (DSL). Vervolgens werd in een serie workshops het organisatorische deel uitgewerkt. OTAP en beheer van gedistribueerde systemen als SMS2003 Waar de beheerorganisatie voor SMS 2003 in het begin als één geheel werd beschouwd, kwam men al snel tot de conclusie dat er onderscheid moest worden gemaakt tussen degenen die de software packages bouwen en degenen die de software distribueren naar de eindgebruikers en zorgen voor het beheren van SMS. Immers, het zou onwenselijk zijn dat een ontwikkelaar zelfstandig packages in de DSL kan plaatsen, zonder dat er operationele tests hebben plaatsgevonden en de beheerder de packages geaccepteerd heeft. Dit moest in samenwerking gebeuren met degenen die verantwoordelijk zijn voor het beheer van de SMS-omgeving. Het scheiden van omgevingen in de klassieke

5


294

indeling ‘ontwikkelomgeving’, ‘testomgeving’, ‘acceptatieomgeving’ en ‘productieomgeving’ mag dan in de mainframe- en midrange-werelden gemeengoed zijn, in de wereld van gedistribueerde systemen bleek op dit gebied vaak nog veel te leren. Bij het inrichten van de organisatie werd dus in het bijzonder aandacht geschonken aan de functiescheiding tussen de makers van de software packages en de verantwoordelijken voor de distributie. Dit resulteerde in twee organisatieonderdelen, één voor het maken en onderhouden van software packages en één voor het distribueren van software naar eindgebruikers en het beheer van de SMSomgeving. Ieder organisatieonderdeel op zich bestond weer uit een aantal functionele teams. Het organisatiemodel is weergegeven in de onderstaande figuur. In deze afbeelding valt de duidelijke scheiding op tussen een ontwikkelgroep voor de software packages en een beheerunit, die zorgt voor distributie en support. Daarbij is de afgebeelde Service Desk ‘virtueel’ ingetekend, daar van de reeds bestaande regionale service desks gebruik wordt gemaakt. De strikte functionele scheiding tussen het maken en onderhouden van packages en het

beheer van de SMS-omgeving stuitte wel op praktische bezwaren. De benodigde kennis voor beide functies bleek vaak verenigd in één en dezelfde persoon. Uiteindelijk zou dit waarschijnlijk geen rol spelen, omdat het maken van packages werd uitbesteed aan een externe partij. Met behulp van het MOF Team Model werden vervolgens rollen gedefinieerd, met de bijbehorende taken en verantwoordelijkheden specifiek voor SMS en het packagen. Deze werden daarna toegewezen aan de beheerteams. Als laatste werd een aantal kernprocedures met betrekking tot release management van software packages gedefinieerd. Hierin kwam duidelijk naar voren waar interactie tussen de verschillende teams noodzakelijk was en waar dus gecommuniceerd moest worden. Dit sloot aan bij een van de kernpunten van het MOF Team Model, het centraal stellen van goede communicatie tussen de beheerafdelingen en -processen. Als voorbeeld is het patch management proces weergegeven (figuur 5). Resumerend Een belangrijk effect van al deze aandacht voor het aspect ‘organisatie van beheer’ tijdens de ontwerpfase was dat tijdens de uit-

SMS Systeem Owner

Software Distribution

PACKAGING

DSL ORGANISATION

ORGANISATION

PROCESSES

Packaging Manager

Authenticated Request Work Package Production Build Standards Test Standards / Plans Promotion to DSL Feedback to requester

PROCESSES

Laptop computer

Packaging Technicians X 4

SMS Enterprise Administrator X 3

IBN Compatible

Service Desk

Confirmation of Package in DSL Confirm AD compliance for package Push process / Authority Remote Control / Authority

Level 2 Support

Figuur 4 Organisatiemodel



rol van een tool niet alleen werd gekeken naar technische implementatie. Er werd nadrukkelijk overlegd met de lokale beheerorganisatie, over hun toekomstige taken en verantwoordelijkheden. Ook werden de procedures aangepast en kwamen er nog steeds nieuwe procedures bij. Het initiatief werd hier genomen door de leden van het projectteam, die later ook het beheer op zich zouden nemen.

Dit is een bewijs dat het MOF gedachtegoed goed aansloot bij de dagelijkse praktijk van de beheerders. Bij deze groep is duidelijk geworden dat een goed operationeel beheer niet alleen bestaat uit de juiste tools, maar ook uit communicatie, duidelijke procedures en processen. Met het MOF model kon de vertaalslag eenvoudig worden gemaakt.

Change Management

Start

New Patch Released

NO

Packaging Team

295

Release Management

Systeem Operations

Is the Patch Relevant

YES Incident Management

Test Patch on Standard Workstation

Was test Successful

NO

Analyse Problem

YES Inform PE Pilot Group and Help Desks

Deploy Patch to PE Pilot Group

Was Patch Deployment successfull

5 NO

Analyse Problem

YES SMS Enterprice Administrators and Level 2 Support

RFC Passed by CAB

Inform Users and Help Desks

Deploy Patch

END

Figuur 5 Patch management proces


Technologie

296

Geografische spreiding

Bekendheid met ITIL

Nut van Operating Quadrant

Zo ging de implementatie van MOF altijd gepaard met de uitrol van een technologisch product van Microsoft. Ook bleek een duidelijke, formele taakscheiding afwezig. Deze was vaak informeel en op basis van persoonlijke interesses en kennis. Beide organisaties kenden sublocaties, waar IT-beheer plaatsvond. De organisatiestructuur van deze sublocaties bleek vaak niet homogeen. Ook was in beide gevallen sprake van een sterke focus op de technologie en was er weinig aandacht voor het beter organiseren van beheer. Verschillen zijn er ook: de ene organisatie is in Nederland gevestigd, terwijl de andere geografisch over diverse landen is verspreid. Dit laatste leidt weer tot cultuurverschillen. Beide aspecten zijn, zoals bekend, van grote invloed op de resultaten van een procesverbeteringstraject. Verder was de Nederlandse organisatie al langere tijd met ITIL bezig, waardoor ITIL (en daarmee helaas ook MOF) ‘besmet’ bleek. De bekendheid met ITIL en MOF van de Europees opererende organisatie was wisselend, maar tijd om diepgaand aan deze kennislacune te werken ontbrak. De waarde van MOF bleek hier door de concepten eruit te gebruiken, maar de naam ‘MOF’ achterwege te laten. Wat in beide cases opvalt, is dat de aandacht vooral moet uitgaan naar het Operating Quadrant en het Team Model. De Service Management Functions uit het Operating Quadrant bieden (eindelijk) een handreiking naar beschrijving van backoffice beheeractiviteiten. De taakbeschrijvingen uit het Team Model blijken waardevol om ordening en daarna harmonisering van taken bespreekbaar te maken. Beide onderwerpen ontbreken echter in ITIL. Hieruit volgt dat de pragmatische waarde van MOF vooral in materie zit, die ITIL niet beschrijft.

Tabel 3 Analyse van de cases

PRAKTISCHE BRUIKBAARHEID De ervaringen bij beide situaties hebben laten zien dat bepaalde elementen van MOF zeer bruikbaar zijn en dat bepaalde aspecten minder handig zijn. Om met het laatste te beginnen: MOF telt een groot aantal processen. Dit leidt tot dezelfde valkuil als bij het oude ITIL: ieder proces lijkt een procesmanager nodig te hebben, wat een hoge hindernis opwerpt met betrekking tot het organisatieontwerp en de bezetting. Om in hetzelfde aandachtsgebied te blijven: MOF biedt nog geen handreiking of voorbeeldberekening voor de tijd die een procesmanager zou moeten c.q. mogen besteden aan zijn taak. De in de praktijk bruikbare zaken zijn de volgende: • Het Team Model, dat een soms vergeten onderwerp weer nieuw leven inblaast: taaken functiescheiding. In veel beheerorganisaties blijkt een goede functiescheiding afwezig, met alle bekende gevolgen voor bijvoorbeeld change management. Het Team Model maakt dit weer bespreekbaar.

• De Service Management Functions uit het Operating Quadrant, die zeer concreet beschreven zijn in de whitepapers. • De Product Operations Guides (POGs). Dit zijn ‘beheerhandleidingen’, die bij producten zoals SMS, MOM en Active Directory horen. In deze POGs staan opsommingen van beheertaken, die weer te herleiden zijn naar de diverse service management functions. Ook bieden de POGs rapportagesuggesties. • De aanvullende literatuur, zoals de MOF pocket guide.

CONCLUSIE BRUIKBAARHEID Werkend met MOF blijken de volgende conclusies te kunnen worden getrokken: • Procesverbetering als op zichzelf staand fenomeen blijkt vaak geen reden om met MOF aan de slag te gaan. In sommige gevallen wordt in MOF gezocht naar de materialen voor de ‘basisinrichting van beheer’. Dit kan worden verklaard doordat MOF-projecten vaak gestart worden vanuit of naast de implementatie van een ander



•

•

•

Microsoft produkt. Dit betekent dat toolimplementaties kunnen leiden tot organisatievraagstukken, die in een aantal gevallen met MOF kunnen worden beantwoord. Voor meeste beheerders is het operationele werk hun kernactiviteit. Het verbeteren hiervan moet snel, effectief en zonder franje plaatsvinden. Koppeling met tooling is een randvoorwaarde. Het nauwgezet volgen van de best practices en modellen uit MOF biedt onvoldoende soelaas. Dit is geen nieuwe bevinding, maar eerder een bekend fenomeen uit implementaties van ITIL, CMM, etc. Zoals bekend uit ITIL-trajecten is het niet mogelijk om slechts één van de modellen van MOF in te voeren, vanwege de onderlinge verbondenheid. Het is mogelijk om met één model te starten mits de wisselwerking met de andere modellen niet uit het oog wordt verloren. Het regelmatig opnieuw bepalen van de prioriteiten en aandacht blijven vragen voor continue verbetering zijn ook bij een framework als MOF voor de hand liggende aandachtspunten. Daarnaast is het belangrijk om op een gegeven moment te accepteren dat 80% goed ook goed is. Het blijft een ‘best practice’ en geen wet die ingevoerd wordt. De MOF-materialen (whitepapers, cursussen, et cetera) vormen geen losstaand geheel. Zij hebben een nauwe relatie met andere Microsoft documentatie, zoals Product Operations Guides. Dit maakt de bruikbaarheid van MOF voor andere platforms lastiger.

selwerking van interactieve implementatiewerkwijzen (workshops!) en het direct in de praktijk toepassen van het procesmodel, gecombineerd met de benodigde tooling, kunnen (delen van) het Team Model en het Risicomodel worden meegenomen. Hierdoor wordt MOF, mits in delen ingevoerd en ondersteund met de juiste tooling en een gezamenlijke aanpak (actieve bijdrage van management en klanten), niet zomaar een nieuwe hype. Het is een bruikbaar framework om het operationele beheer in te richten. Dit is naast de ‘leeftijd’ van MOF een tweede reden voor een feestje.

TOT SLOT: AANBEVELINGEN

Hints en tips Met de implementatie-ervaringen van MOF in het achterhoofd willen de auteurs u nog enige wijsheden meegeven. Het lijstje bevat zaken die niet gloednieuw zijn, dus wellicht moet u hier de kracht in de herhaling van de boodschap zoeken: - Probeer bestaande taken en activiteiten in te passen in de SMF’s in plaats van de SMF’s ‘op te leggen’. - Implementeer met MOF een taakgerichte organisatie. Dat kan een goede tussenstap zijn naar de vaak gewenste resultaatgerichte organisatie. - Wees voorzichtig met het inzetten van zware AO- en andere processpecialisten. Hierdoor wordt soms een te sterke theoretische invalshoek gekozen als pragmatiek gewenst is. - Werk interactief en organiseer doelgerichte workshops. - Ga niet vanuit de ivoren toren proceshandboeken rondmailen.

Samenvattend blijkt MOF met haar drie modellen goed toepasbaar in een operationele beheeromgeving. Een implementatieplan moet wel plaats bieden aan een sequentiële invoering, waarbij gestart moet worden met het model waar op dat moment de meeste behoefte aan is en waar de meeste sponsors voor zijn. Snelheid is een belangrijke factor, want voor de meeste beheerders is het operationele werk hun kernactiviteit en dat moet zo snel en zo goed mogelijk geïmplementeerd kunnen worden. Door de wis-

Marjo van Bergen werkt bij Capgemini als projectmanager in complexe technische en organisatorische projecten. Haar expertise ligt op het vlak van verandermanagement in organisatorisch lastige situaties. Rudolf Liefers MIM werkt namens Capgemini aan IT Transformation en Governance trajecten bij diverse klanten en is Product Manager Microsoft Manageability Solutions. Daarnaast is hij secreta-

•

297

5


298

ris van het NGI, afdeling Beheer. Martin Sih is werkzaam als senior consultant bij Capgemini en gespecialiseerd in Microsoft infrastructuren. Hij heeft in die hoedanigheid reeds vele implementaties van Microsoft producten begeleid, inclusief het opzetten van de beheeromgeving. Caro Vermeule is werkzaam bij Capgemini. Zij is vanuit de techniek doorgegroeid naar consultant op IT Service Management trajecten met een focus op inrichting van processen en implementatie van tooling.


Er is reden voor een feestje: het Microsoft s Operations Framework

Recommend Documents