beheer MOF: nieuwe papieren tijger? Implementeren van beheer best practice De IT Inrastructure Library (ITIL) is binnen het werkveld IT-Beheer nagenoeg de leidende reerentie ten aanzien van de beschrijving van beheerprocessen. Toch heet Microsot zo n 5 jaar geleden haar Microsot Operations Framework (MOF) geïntroduceerd. De auteurs gaan in op MOF en op de implementatie-ervaringen met het model. Rudol Lieers en Marjo van Bergen 72 1 Voor meer inormatie over MOF wordt verwezen naar MOF, a pocket guide. MOF is het antwoord van Microsot op de vraag hoe ervoor gezorgd kan worden dat de kwaliteit van de it-services, gebouwd op Microsottechnologie, op het gewenste peil gehouden wordt. MOF bestaat deels uit de ITIL en is verrijkt met een aantal speciieke componenten van Microsot, die zorgen voor de inrichting van de beheerprocessen. Microsot bouwt bewust voort op ITIL en stelt dat zij ITIL zowel adopteert als adapteert. Er is dus geen sprake van concurrentie met ITIL. Microsot wil met haar beheerstrategie serieus genomen worden en tot een belangrijke speler uitgroeien in de beheermarkt. Dit wordt mede ingegeven door de huidige spelregels op het gebied van governance, beheerbaarheid en kosten. Het Operations Framework bestaat uit drie modellen: het procesmodel, het teammodel en het risicomodel. Deze modellen zijn alledrie»mof sluit beter aan bij de verandering die technologie teweegbrengt«deels akomstig uit ITIL en hebben deels hun wortels in andere concepten van Microsot, zoals het Microsot Solutions Framework. 1 Procesmodel Dit model bevat 21 beheerprocessen, die zijn gebundeld in kwadranten: Changing, Operating, Supporting en Optizimizing. De processen, in MOF-jargon Service Management Functions genoemd, zijn grotendeels gelijk aan de ITIL-processen, die model hebben gestaan voor het merendeel van de MOF-processen. Daarnaast hebben de vier kwadranten van MOF een aantal nuttige toevoegingen meegekregen. De belangrijkste toevoeging in het Optimizing-kwadrant is Workorce Management. Deze SMF richt zich speciiek op de opleidings- en kennismanagementaspecten van beheerders. De grootste aanvulling op de ITIL-processen zit in het Operating-kwadrant, waarin processen als Security Administration en Storage Management een belangrijke rol spelen. Het Operatingkwadrant levert dus een belangrijke toevoeging, met de kanttekening dat de processen sterk op Microsot-technologie geënt zijn. Dit diskwaliiceert echter het Operating Framework niet voor
Samenvatting Met Microsot Operations Framework bouwt Microsot bewust voort op ITIL. Met name het operationele beheer is in MOF meer concreet gemaakt. Daarmee maakt MOF een verbinding met het werk en de problemen van beheerders. In een aantal implementatietrajecten blijkt dat de herkenbaarheid van MOF ervoor zorgt dat de betrokken beheerders beter gemotiveerd zijn om veranderingen in te gaan. niet-microsot-omgevingen. Conorm het best practice -principe worden de voorbeelden immers aangepast aan de organisatie die ze implementeert. Herkenbare processen Wat MOF sterk maakt, is de herkenbaarheid van de operationele beheerprocessen. Voor veel beheerders bestaat procesmatig werken immers vaak alleen uit calletjes lopen en RFC s ahandelen. De Operations-processen binnen MOF geven een concrete invulling aan de voor veel beheerders abstract gebleven processen als Availability Management en Capacity Management. In een aantal implementatietrajecten bleek de herkenbaarheid van MOF enorm wanneer de relatie wordt gelegd naar de inrastructuur, die uiteindelijk de serviceketens vormt en die procesmatig moet worden beheerd. Daarmee maakt MOF een verbinding met het werk en de problemen van beheerders. Dit is een redelijk groot verschil met ITIL, waarin de ocus toch vooral ligt op het verbeteren van administratieve beheerprocessen in plaats van technische beheerprocessen. Deze andere ocus zorgt voor een veel groter urgentiebese voor verandering en daarmee voor draagvlak onder beheerders. Het procesmodel 1 73
beheer MOF en het belang van urgentiebese Een verandering bewerkstelligen vergt draagvlak. Proessor John Kotter heet hier veel onderzoek naar gedaan en op basis van zijn ervaringen een stappenplan ontwikkeld. Het model bestaat uit de volgende stappen: 1. Urgentiebese vestigen 2. Een leidende coalitie vormen 3. Een visie en strategie ontwikkelen 4. De veranderingsvisie communiceren 5. Een breed draagvlak voor de verandering creëren 6. Kortetermijnsuccessen genereren 7. Verbeteringen consolideren en meer verandering tot stand brengen 8. Nieuwe benaderingen verankeren in de cultuur Het plan begint met het bewust creëren van draagvlak vanuit het delen van het bese dat een verandering noodzakelijk is. Deze stap, create a sence o urgency, wordt vaak overgeslagen, waardoor het moeilijk wordt de verandering door te voeren. Met betrekking tot het implementeren van MOF-practices is in een aantal klantsituaties duidelijk geworden dat de urgentie akomstig was vanuit een technologieproject; die zou ervoor zorgen dat de beheerwerkwijze nooit meer hetzelde zou kunnen zijn. Dit raakte de technisch beheerders direct, omdat het ingrijpt in hun operationele werk. Daarmee ontstond de kans om op dit niveau in de organisatie het urgentiebese te vestigen. Op een dergelijk moment van relatieve onrust de toekomst is immers onzekerder geworden kan het MOFprocesmodel bij een aantal sleutelpersonen geïntroduceerd worden als structuurbrenger. Daarbij is het belangrijk om de aandacht bij het inrichten van het procesmodel te doen uitgaan naar het Operating-kwadrant, waarmee de backoice-beheeractiviteiten ingericht kunnen worden. Hiermee kan onder de technisch beheerders een guiding coalition ontstaan, wat volgens Kotter de groep is die de bron van alle veranderactiviteiten zal vormen. Deze groep zal een aantal snelle successen moeten behalen, wat relatie eenvoudig is. MOF is namelijk onderbouwd met veel standaard hulpmiddelen en documentatie. Een voorbeeld hiervan is de verzameling Product Operation Guides (POG s). Ieder Microsot Server-product wordt onder andere geleverd met de beheerhandleiding, de Product Operation Guide. In deze handleiding staan, in MOF-jargon, de beheerhandelingen en -procedures vermeld die van toepassing zijn voor dat product. Hiermee kunnen dus de operationele beheeractiviteiten pragmatisch en herkenbaar ingevuld worden. Aan ieder rollencluster is een aantal speciieke kwaliteitsdoelstellingen gekoppeld. Deze doelstellingen zijn erop gericht dat de teams hun individuele missies kunnen deiniëren en helpen hen ook bij de uitvoering ervan. Door het creëren van dit gemeenschappelijke doel in het team wordt de noodzaak van verandering opnieuw nadrukkelijk naar voren gebracht. De interactie tussen stap 1 en 2 van het model van Kotter en het nadrukkelijk doorlopen (en tijd nemen voor en prioriteit geven aan) van deze asen zijn bij het implementeren van MOF zeer welbesteed gebleken. De tijd die er in het begin in gestoken is, is na verloop van tijd ruimschoots terugverdiend. Zodra deze eerste veranderbewegingen concreet gemaakt zijn en succesvol blijken, ontstaat een geschikt moment voor het doorvoeren van meer verandering. Het schetsen van de mogelijke toekomstbeelden (concreet, helder en vooral enthousiasmerend) helpt het team een team te blijven. Het team blijt hierdoor ook de noodzaak van de verandering zien en is blijvend in staat deze boodschap uit te dragen. Zodra de invoering van MOF-onderdelen (team/proces/risico) aantoonbaar en bijvoorkeur op korte termijn successen genereert, is de eerste stap gezet naar generating more change. In het stappenplan van Kotter wordt dit onder stap 7 genoemd. De geaseerde opbouw van MOF maakt het bij de invoering van het procesmodel mogelijk om kwadranten van het procesmodel stap voor stap in te voeren in de organisatie, op basis van urgentie. Deze urgentie wordt per organisatie bepaald. 74
Teammodel Het teammodel vormt binnen MOF een antwoord op de vraag hoe een beheerorganisatie kan worden vormgegeven, waarbij de nadruk ligt op het opzetten van eectieve operations-teams. Uitgangspunt hierbij is dat een operations-team (beheeraandachtsgebied) alleen succesvol kan zijn indien een aantal kernkwaliteitsdoelen bereikt worden. Binnen MOF zijn daarvoor zeven rolclusters gedeinieerd die algemene categorieën van activiteiten beschrijven, waardoor een gemeenschappelijk doel wordt nagestreed. Figuur 2 geet de rolclusters weer. De rolclusters zijn allerminst unctiebeschrijvingen o hiërarchische verhoudingen. Voor iedere rol (rolcluster) worden de activiteiten en vaardigheden beschreven. Daarnaast wordt aangegeven hoe de teams in relatie tot elkaar staan en in relatie tot elkaar het best kunnen opereren. De gekozen indeling zorgt voor meer helderheid in een beheerorganisatie, onder voorwaarde dat mensen ook daadwerkelijk binnen de kaders van hun rol hun taken uitvoeren. Een release-medewerker is bijvoorbeeld meer projectgedreven en houdt zich niet bezig met operations-taken. De security-medewerker zorgt voor de vormgeving van en controle op de beveiligingsmaatregelen die door inrastructure-medewerkers kunnen worden uitgevoerd. Het teammodel is bij veel projecten uitermate geschikt, aangezien het de discussie over unctiescheiding op gang brengt. In een mainrameomgeving is unctiescheiding de normaalste zaak van de wereld. Dit in tegenstelling tot bijvoorbeeld de gedistribueerde sotwareomgeving, waar de klassieke indeling ontwikkelomgeving, testomgeving, acceptatieomgeving en productieomgeving nog niet in alle gevallen een vanzelsprekendheid zijn. Bij het implementeren van een tool als SMS 2003 is al snel gebleken dat onderscheid agedwongen moet worden tussen degenen die de sotwarepackages bouwen en degenen die de sotware distribueren naar de eindgebruikers en die de sotware beheren. Dit om te voorkomen dat ontwikkelaars zelstandig packages in de DSL plaatsen zonder dat dit getest is. En zonder dat er een acceptatie door de beheerder heet plaatsgevonden (en derhalve niet geaccepteerd is). Het introduceren van het teammodel heet er in deze gevallen toe bijgedragen dat de ontwikkelaars en beheerders duidelijke rolomschrijvingen krijgen. Daarbij wordt in het bijzonder aandacht geschon- Rolclusters in MOF 2 75
beheer»in ITIL ontbreekt een apart model om risico s te managen«76 ken aan de unctiescheiding tussen de bouwers en distributeurs. Dit leidt bij een organisatie bijvoorbeeld tot twee organisatieonderdelen, waarbij één onderdeel verantwoordelijk wordt voor het maken en onderhouden en het andere onderdeel voor de distributie. Uiteraard is dit ahankelijk van de omvang van de it-adeling binnen een bedrij. (In kleinere it-organisaties zal een persoon waarschijnlijk meerdere rollen vervullen.) Met behulp van het MOF-teammodel zijn in bovenstaand voorbeeld vervolgens rollen en kernprocedures voor het release-management van de sotwarepackages gedeinieerd. Deze procedures maken duidelijk waar de samenwerking en communicatie tussen de verschillende teams noodzakelijk is, een van de kernpunten van het MOF-teammodel. Risicomodel Het MOF-risicomodel voorziet in een kader voor het managen van risico s, dat kan worden geïntegreerd in andere it-operations-processen. Hierdoor kan het model een geïntegreerd deel binnen de business worden. De vij stappen binnen het Risicomodel binnen MOF zijn als volgt: 1. Identiy: het team identiiceert de situatie, de gevolgen, de bron en de vormen van verstoring gekoppeld aan het risico. De ervaring leert dat hiermee vaak gestart wordt na een calamiteit. Dit zorgt ervoor dat de voedingsbodem voor risicomanagement zeer nadrukkelijk aanwezig is. De noodzaak om het risicomodel in te voeren heet zich dan bewezen, ook al is hier het gevaar dat men doorschiet in alle risico s moeten teruggedrongen, verzekerd o met noodscenario s ondervangen zijn. De kans dat het risico optreedt, en wat dan de eventuele schade (en vervolgschade) zou kunnen zijn, is doorslaggevend. 2. Analyse: op basis van de onderkende risico s vindt een analyse plaats van de kansen de bedreigingen en de impact daarvan. Deze analyse leidt naar inormatie om beslissingen op te baseren. 3. Action planning: het opstellen van een planning, rekening houdend met prioriteiten en uiteraard rekening houdend met onvoorziene omstandig- heden. Ervaring leert dat niet altijd alles gaat zoals gepland, maar het onderkennen van risico s en daar voora op geanticipeerd te hebben o als het risico zich voordoet een uitwijkmogelijkheid te hebben scheelt in de gemoedsrust van de beheeradeling en de co en/o cio. Financieel is het ook aantrekkelijker aangezien de bedrijsprocessen niet, o minder lang, verstoord zijn door uitval van it-diensten. De inzichtelijkheid in die kosten en baten is niet in alle gevallen transparant, waardoor het lijkt also de it steeds duurder wordt. Het continu communiceren over en het inzichtelijk maken van de baten voor de business versus de kosten van it-beneits zijn hiervoor de enige mogelijkheden. 4. Tracking: het bewaken van de risico s en de veranderingen daar rond omheen is een belangrijke controlestap die vaak wat minder aandacht krijgt dan wenselijk is. 5. Controlling: als er in de vorige ase een wijziging is geconstateerd, wordt van het team verwacht dat hierop actie wordt ondernomen. Een risico kan bijvoorbeeld worden agevoerd omdat het onbelangrijk is geworden. Het veranderen van de kans o de impact is een signaal dat dit risico opnieuw door de analysestap heen moet. Risico = kans * impact Een risico is de kans dat het zich voordoet maal de impact. Voor ieder risico wordt bepaald wat de kans is dat het zich voordoet, welke impact het risico heet op de it-dienstverlening en daardoor ook op de core business van het bedrij en op welke termijn een risico zich voordoet. Een kleine kans met een beperkte impact vergt andere maatregelen dan een vrijwel zekere kans met een hoge impact. Passende maatregelen variëren van voorkomen, reduceren, overdragen, calamiteitenplan opstellen tot accepteren. Het zoeken naar de gulden middenweg (inancieel, impact voor de business,) is hier het credo, naast voor ieder risico meerdere tegenmaatregelen te deiniëren. Het identiiceren van risico s is een continu proactie proces en moet een substantieel onderdeel zijn van iedere rol en unctie en past ook in iedere rol (en rolcluster) in het teammodel.
De zes stappen in het risicomodel 3 In de praktijk blijkt proactiviteit vaak niet de best herkenbare eigenschap te zijn die een goed werkende beheeromgeving kenmerkt. Het proactie managen van risico s is echter cruciaal vanwege de essentie van it-services in het bedrijsleven en de potentiële schade die verstoringen op de business kunnen hebben. Daarnaast zijn er door de toegenomen complexiteit en variatie in de it-omgeving meer po s (points o ailure) dan enige jaren geleden. Er zijn meer componenten die voor verstoringen kunnen zorgen; meer pc s, meer servers, meer laptops, meer verbindingen, meer interaces. Risicomanagement is bij projectmanagement en veranderprogramma s vanzelsprekend, in beheeromgevingen staat dit echter nog in de kinderschoenen. In ITIL is een model om risico s te managen binnen Security Management opgenomen. Het is daardoor dusdanig diep verstopt dat weinig beheerders zich eigenaar voelen van het concept risicomanagement. Dit is een issue op zich, dat ook nog eens zichtbaar wordt binnen de huidige SOX-hausse. Een van de aspecten waarop SOX zich richt, is het identiiceren en managen van IT Controls. Hiermee wordt een begin gemaakt met risicomanagement op het gebied van it-dienstverlening. In de praktijk blijkt het lastig om met beheerders te praten over risicomanagement vanwege het gebrek aan herkenning en eigenaarschap. In zo n geval kan een meer pragmatisch risicomodel, zoals dat uit MOF, een opening bieden. Het opstellen van een risicoproiel en het benoemen van een risicomanager op de beheeradeling zijn ook stappen in de goede richting, naast het meer resultaatgericht werken en denken. Conclusie Is MOF nu beter dan ITIL? Nee, MOF is in bepaalde opzichten anders dan ITIL en sluit soms beter aan bij de verandering die technologie teweegbrengt. Ten aanzien van het MOF-model kan gesteld worden dat het operationele beheer in MOF meer concreet gemaakt is. MOF werkt duidelijker aan een end-to-end-oplossing en het wordt ondersteund door beschikbare en betaalbare tooling. Het biedt technisch beheerders derhalve meer concrete handvatten om mee aan de slag te gaan. Het teammodel blaast een soms vergeten onderwerp weer nieuw leven in: taak- en unctiescheiding. In veel beheerorganisaties blijkt een goede unctiescheiding awezig. Het teammodel maakt dit weer bespreekbaar. Dit deel van MOF vormt een belangrijke meerwaarde ten opzichte van ITIL, want ITIL zegt, op de processen na, weinig tot niets over de organisatiemodellering. Ook is binnen MOF het risicodenken goed uitgewerkt, een andere meerwaarde ten opzichte van ITIL. Met betrekking tot de implementatie van beheer best practice op basis van MOF blijkt dat de verhoogde herkenbaarheid en de daardoor zichtbare aha-erlebnis ervoor zorgt dat de betrokken beheerders beter gemotiveerd zijn om de verandering in te gaan. De ervaring leert dat veel organisaties minder goede ervaringen hebben met het implementeren van ITIL en het hebben zien uitgroeien tot een papieren tijger. De relatie 77
beheer van MOF met de technologie zorgt ervoor dat MOF eerder pragmatisch ingezet kan worden. Echter, invoering van nieuwe technologie vereist meer dan alleen nieuwe tools. MOF sluit goed aan bij het verandermanagement, dat nieuwe technologie vereist. Het teammodel past op stap 2 van Kotter, het vormen van een leidende coalitie. Het procesmodel, en de mogelijkheid tot sequentiële invoering, zorgt voor de noodzakelijke wake-up-call, het vestigen van het urgentiebese. Ervaring leert dat door deze betere inbedding van de noodzaak tot verandering en het vormen van de leidende teams de veranderingen verder gaan dan het invoeren van een procesje, o het beschrijven van een procedure. Hierdoor kan implementatie van MOF succesvol zijn en minder snel verworden tot een nieuwe papieren tijger. Links www.microsot.com/mo Literatuur Hedeman, B., H. Fredriksz & G. Vis van Heemst (2004). Projectmanagement, een introductie op basis van PRINCE2. Zaltbommel: Van Haren Publishing. Kotter, J.P. & D.S. Cohen (2002). Het hart van de verandering. Schoonhoven: Academic Service. Pultorak, D., P. Quagliariello & R. Akker (2003). MOF, a pocket guide. Zaltbommel: Van Haren Publishing. Marjo van Bergen is projectmanager bij Capgemini met als specialisme verandermanagement. E-mail: marjo.van.bergen@capgemini.com Rudol Lieers MIM is product manager Microsot manageability solutions. Daarnaast is hij secretaris van het NGI, adeling Beheer. E-mail: rudol.lieers@capgemini.com 78