MOF: nieuwe papieren tijger?

beheer

f

MOF: nieuwe papieren tijger?

Implementeren van beheer best practice

De IT Infrastructure Library (ITIL) is binnen het werkveld IT-Beheer nagenoeg de leidende referentie ten aanzien van de beschrijving van beheerprocessen. Toch heeft Microsoft zo’n 5 jaar geleden haar Microsoft Operations Framework (MOF) geïntroduceerd. De auteurs gaan in op MOF en op de implementatie-ervaringen met het model. Rudolf Liefers en Marjo van Bergen

informatie / april 2005

1 Voor meer informatie over MOF wordt verwezen naar MOF, a pocket guide.

72

MOF is het antwoord van Microsoft op de vraag hoe ervoor gezorgd kan worden dat de kwaliteit van de it-services, gebouwd op Microsofttechnologie, op het gewenste peil gehouden wordt. MOF bestaat deels uit de ITIL en is verrijkt met een aantal specifieke componenten van Microsoft, die zorgen voor de inrichting van de beheerprocessen. Microsoft bouwt bewust voort op ITIL en stelt dat zij ITIL zowel adopteert als adapteert. Er is dus geen sprake van concurrentie met ITIL. Microsoft 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 afkomstig uit ITIL en hebben deels hun wortels in andere concepten van Microsoft, zoals het Microsoft 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 Workforce Management. Deze SMF richt zich specifiek 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 Microsoft-technologie geënt zijn. Dit diskwalificeert echter het Operating Framework niet voor

Samenvatting Met Microsoft Operations Framework bouwt Microsoft 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.

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 afhandelen’. De Operations-processen binnen MOF geven een concrete invulling aan de voor veel beheerders abstract gebleven processen als Availability Management en Capacity Management. In

Het procesmodel

een aantal implementatietrajecten bleek de herkenbaarheid van MOF enorm wanneer de relatie wordt gelegd naar de infrastructuur, 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 focus toch vooral ligt op het verbeteren van administratieve beheerprocessen in plaats van technische beheerprocessen. Deze andere focus zorgt voor een veel groter urgentiebesef voor verandering en daarmee voor draagvlak onder beheerders.

1


niet-Microsoft-omgevingen. Conform het ‘best practice’-principe worden de voorbeelden immers aangepast aan de organisatie die ze implementeert.

73

beheer

f

MOF en het belang van urgentiebesef Een verandering bewerkstelligen vergt draagvlak. Professor John Kotter heeft hier veel onderzoek naar gedaan en op basis van zijn ervaringen een stappenplan ontwikkeld. Het model bestaat uit de volgende stappen: 1. Urgentiebesef 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 besef dat een verandering noodzakelijk is. Deze stap, create a sence of urgency, wordt vaak overgeslagen, waardoor het moeilijk wordt de verandering door te voeren.

74

Met betrekking tot het implementeren van MOF-practices is in een aantal klantsituaties duidelijk geworden dat de urgentie afkomstig was vanuit een technologieproject; die zou ervoor zorgen dat de beheerwerkwijze ‘nooit meer hetzelfde 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 urgentiebesef 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 backoffice-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 ver-

anderactiviteiten zal vormen. Deze groep zal een aantal snelle successen moeten behalen, wat relatief eenvoudig is. MOF is namelijk onderbouwd met veel standaard hulpmiddelen en documentatie. Een voorbeeld hiervan is de verzameling Product Operation Guides (POG’s). Ieder Microsoft 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 specifieke kwaliteitsdoelstellingen gekoppeld. Deze doelstellingen zijn erop gericht dat de teams hun individuele missies kunnen definië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 fasen 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 blijft 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 gefaseerde 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.

Het teammodel vormt binnen MOF een antwoord op de vraag hoe een beheerorganisatie kan worden vormgegeven, waarbij de nadruk ligt op het opzetten van effectieve 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 gedefinieerd die algemene categorieën van activiteiten beschrijven, waardoor een gemeenschappelijk doel wordt nagestreefd. Figuur 2 geeft de rolclusters weer. De rolclusters zijn allerminst functiebeschrijvingen of 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

Rolclusters in MOF

van en controle op de beveiligingsmaatregelen die door infrastructure-medewerkers kunnen worden uitgevoerd. Het teammodel is bij veel projecten uitermate geschikt, aangezien het de discussie over functiescheiding op gang brengt. In een mainframeomgeving is functiescheiding de normaalste zaak van de wereld. Dit in tegenstelling tot bijvoorbeeld de gedistribueerde softwareomgeving, waar de klassieke indeling ontwikkelomgeving, testomgeving, acceptatieomgeving en productieomgeving nog niet in alle gevallen een vanzelfsprekendheid zijn. Bij het implementeren van een tool als SMS 2003 is al snel gebleken dat onderscheid afgedwongen moet worden tussen degenen die de softwarepackages bouwen en degenen die de software distribueren naar de eindgebruikers en die de software beheren. Dit om te voorkomen dat ontwikkelaars zelfstandig packages in de DSL plaatsen zonder dat dit getest is. En zonder dat er een acceptatie door de beheerder heeft plaatsgevonden (en derhalve niet geaccepteerd is). Het introduceren van het teammodel heeft er in deze gevallen toe bijgedragen dat de ontwikkelaars en beheerders duidelijke rolomschrijvingen krijgen. Daarbij wordt in het bijzonder aandacht geschon-

2


Teammodel

75

beheer

f

»In ITIL ontbreekt een apart model om risico’s te managen«

ken aan de functiescheiding 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 afhankelijk van de omvang van de it-afdeling binnen een bedrijf. (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 softwarepackages gedefinieerd. 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.

76

De vijf stappen binnen het Risicomodel binnen MOF zijn als volgt: 1. Identify: het team identificeert 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 heeft zich dan bewezen, ook al is hier het gevaar dat men doorschiet in ‘alle risico’s moeten teruggedrongen, verzekerd of 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 informatie 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 vooraf op geanticipeerd te hebben – of als het risico zich voordoet een uitwijkmogelijkheid te hebben – scheelt in de gemoedsrust van de beheerafdeling en de cfo en/of cio. Financieel is het ook aantrekkelijker aangezien de bedrijfsprocessen niet, of 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 alsof de it steeds duurder wordt. Het continu communiceren over en het inzichtelijk maken van de baten voor de business versus de kosten van it-benefits 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 fase een wijziging is geconstateerd, wordt van het team verwacht dat hierop actie wordt ondernomen. Een risico kan bijvoorbeeld worden afgevoerd omdat het onbelangrijk is geworden. Het veranderen van de kans of 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 heeft op de it-dienstverlening en daardoor ook op de core business van het bedrijf 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 (financieel, impact voor de business,) is hier het credo, naast voor ieder risico meerdere tegenmaatregelen te definiëren. Het identificeren van risico’s is een continu proactief proces en moet een substantieel onderdeel zijn van iedere rol en functie en past ook in iedere rol (en rolcluster) in het teammodel.

3

De zes stappen in het risicomodel

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 functiescheiding. In veel beheerorganisaties blijkt een goede functiescheiding afwezig. 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


In de praktijk blijkt proactiviteit vaak niet de best herkenbare eigenschap te zijn die een goed werkende beheeromgeving kenmerkt. Het proactief managen van risico’s is echter cruciaal vanwege de essentie van it-services in het bedrijfsleven 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 pof’s (points of failure) dan enige jaren geleden. Er zijn meer componenten die voor verstoringen kunnen zorgen; meer pc’s, meer servers, meer laptops, meer verbindingen, meer interfaces. Risicomanagement is bij projectmanagement en veranderprogramma’s vanzelfsprekend, 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 identificeren 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 risicoprofiel en het benoemen van een risicomanager op de beheerafdeling zijn ook stappen in

77

beheer

f


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 urgentiebesef. 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, of het beschrijven van een procedure’. Hierdoor kan implementatie van MOF succesvol zijn en minder snel verworden tot een nieuwe papieren tijger.

78

Links www.microsoft.com/mof 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: [email protected] Rudolf Liefers MIM is product manager Microsoft manageability solutions. Daarnaast is hij secretaris van het NGI, afdeling Beheer. E-mail: [email protected]

MOF: nieuwe papieren tijger?

Recommend Documents