‘Het ultieme doel van de it is het ondersteunen van de business’, een open deur voor steeds meer it’ers. De vraag is steeds: hoe krijgen we de it maximaal afgestemd op de behoeften van de business (‘Business-IT Alignment’). Daarbij komt nu de vraag: ‘Maar hoe komen we dan in control van de geïntegreerde informatievoorziening?’ We weten al heel lang dat we it-beheer gestructureerd moeten aanpakken, maar functioneel beheer komt nu steeds meer in beeld als probleemgebied. Hoe integreren we functioneel beheer en it-beheer?
Bij de behandeling van dat vraagstuk wordt steeds vaker gebruik gemaakt van het ‘negenvlaksmodel’, een model dat als blauwdruk dient voor de discussie over verantwoordelijkheden in de informatievoorziening (zie de studie naar vlakkenmodellen in Best Practice – Quarterly review, Jaargang 1, nummer 1, pag. 13-18, 2010, TIEM, itSMF-Nederland). Voor het inrichten van de domeinen in het negenvlaksmodel zijn gestandaardiseerde instrumenten beschikbaar gekomen, die voorspelbare resultaten opleveren. Wie bereid is te herkennen dat het uitvinden van een wiel meestal hoge kosten, veel tijd, en onvoorspelbare uitkomsten oplevert, kan z’n voordeel daar mee doen. Het leven van de cio wordt daarmee een stuk gemakkelijker: hij of zij kan zich eindelijk concentreren op de toegevoegde waarde voor de business.
Het negenvlaksmodel
Er bestaan meerdere negenvlaksmodellen. Eén van de populairste varianten, Strategic Alignment Model Enhanced (SAME), 2007, is gebaseerd op een eenvoudig en breed geaccepteerd controlmechanisme: functiescheiding. Om in control te komen van een domein splits je het in twee delen, waarvan het ene deel het andere aanstuurt. Als gevolg daarvan vindt de uitvoering gescheiden van de aansturing plaats. Op die manier voorkom je dat de slager z’n eigen vlees keurt. Iedere accountant en auditor kent dit mechanisme als de grondslag voor control.
Drievoudig model van beheer
Emeritus professor Maarten Looijen heeft een belangrijke bijdrage geleverd aan de invulling van dit controlmechanisme door in de informatievoorziening onderscheid te maken tussen enerzijds functioneel beheer, en anderzijds technisch beheer en applicatiebeheer. Dat gebeurde echter in de jaren tachtig, een tijdperk waarin systeemgericht denken centraal stond en it-servicemanagement nog geboren moest worden.
De beperking van best practice frameworks
In de jaren negentig werd men zich steeds meer bewust van het feit dat het in de it om de output gaat, de service dus, en niet om de techniek: it bestaat uitsluitend bij de gratie van de klant. Klantgericht denken kwam daarmee in beeld en juist daarin wilde iedere it-dienstverlener excelleren. Om dat te beheersen moest de dienstverlener echter wel onbewust bekwaam worden in het leveren van services. En daar vinden we de eerste bottleneck: de beschikbare instrumenten (ITIL, ASL, en andere frameworks) leverden alleen best practices maar niet het managementsysteem om die best practices mee te realiseren.
Bij gebrek aan managementkwaliteit in de it-sector werd die bottleneck met de beschikbare frameworks te lijf gegaan met alle gevolgen van dien. Dat lag niet aan die frameworks: daarin lag meer dan voldoende wijsheid opgesloten. Het lag vooral aan de consultants die de it-managers enkele decennia lang bij de hand namen en het verkeerde pad op leidden en natuurlijk aan die managers zelf. Je kunt best practice frameworks nu eenmaal niet implementeren. Daar zijn ze ook helemaal niet voor bedoeld. Deze misvatting heeft ons – alleen in Nederland al – talloze miljoenen gekost.
Ondanks deze moeizame weg zijn er toch resultaten geboekt in het domein it-beheer. Het kan met eenvoudige ingrepen nog stukken beter (daarvoor is nu de integrated service management (ISM)-methode beschikbaar), maar er is met al die inspanningen toch iets bereikt. In die situatie wordt nu steeds duidelijker dat er veel winst valt te behalen als it-beheer beter zou worden aangestuurd. De blik richt zich dus steeds meer op het functioneren van functioneel beheer.
De geschiedenis herhaalt zich
In het domein functioneel beheer speelt zich nu echter hetzelfde af als bij it-beheer het geval was. Bij gebrek aan een managementsysteem gaan organisaties over tot het implementeren van frameworks die uit best practices bestaan. De resultaten zijn voorspelbaar. De huidige problemen in het functioneel beheerdomein illustreren dan ook dagelijks de tweede bottleneck. Medewerkers worden naar trainingen gestuurd waar ze vooral veel informatie over best practices voorgeschoteld krijgen. Veelal met de boodschap dat je zowel BiSL als ASL en ITIL moet doen, samen goed voor zo’n 80 ‘processen’. Wie in dat woud dan nog de weg kan vinden moet wel een verdraaid goed kompas hebben. En daar ontbreekt het precies aan.
Kompas van die functioneel beheerder
Hoe krijg je dat functioneel beheerdomein onder controle, opdat aan de doelstelling van een klantgerichte informatievoorziening wordt voldaan? Voor functioneel beheer geldt hetzelfde als voor it-beheer: het is een dienstverlenend domein dat je dus als een bedrijf zou moeten kunnen managen. Daar gelden dus dezelfde spelregels als bij andere dienstverlenende domeinen zoals it-beheer of facility management gelden. Als gevolg daarvan kan het domein functioneel beheer ook dezelfde inzichten en mechanismen toepassen als in die andere domeinen zijn ontwikkeld. De mechanismen die bij de inrichting van functioneel beheer kunnen worden gebruikt zijn dus dezelfde die ook bij de inrichting van it-beheer zijn ontwikkeld. Met de ISM-methode is daarvoor een uiterst effectieve set instrumenten beschikbaar gemaakt, met een bijbehorende invoeringsmethode. Allemaal gestandaardiseerd, dus met voorspelbare resultaten.
Vertrekpunt kan verschillen, doel is hetzelfde
Organisaties die ISM hebben ingevoerd, beschikken dus al over dat instrumentarium. Ze hebben niet alleen de werkwijze geleerd, maar hebben ook de tools die er bij horen. Dat betekent dat een functional service management (FSM)-project met minimale kosten kan worden opgezet, en op een fundament in it-beheer kan doorbouwen. Het spreekt vanzelf dat dit grote voordelen heeft ten aanzien van de effectiviteit en efficiency van zo’n project en dat de cultuurverandering veel eenvoudiger kan verlopen.
Wie niet het voordeel heeft dat er al een ISM-fundament in de organisatie ligt, zal het domein functioneel beheer op dezelfde wijze moeten aanpakken als voor it-beheer geldt: beantwoord de vraag hoe je de organisatie procesmatig ingericht en bestuurbaar krijgt door een standaard-aanpak met de FSM-methode. Als je daarmee functioneel beheer onder controle krijgt zal heel snel duidelijk worden dat daarna it-beheer ‘aan de beurt is’. Daarvoor geldt dan dat het bijbehorende project enorm kan profiteren van het feit dat een groot deel van het instrumentarium al bij het FSM-project beschikbaar is gekomen.
Natuurlijk kan een organisatie ook in één keer functioneel beheer en it-beheer tegelijk aanpakken (en desgewenst facilitair beheer meenemen). Vooral bij een kleinere organisatie is dat een aantrekkelijke optie: er is immers toch al vaak één helpdesk voor al die domeinen. Groot voordeel is dat de communicatie tussen functioneel beheer en it-beheer dan meteen flink wordt versterkt. En als je facilitair beheer hebt meegnomen wordt het voor de klant alleen maar gemakkelijker.
De snelweg of de omweg?
Langs welke weg een organisatie de verbetering opstart is een zaak van lokaal belang. De overwegingen hebben veel te maken met de vraag waar de meeste pijn nu ligt, hoe groot de organisatie is, waar het budget beschikbaar is, waar de macht ligt, waar de cultuur een aanpak met een standaard toestaat, et cetera. In alle gevallen blijft het doel hetzelfde: het onder controle krijgen van de integrale informatievoorziening en de bijbehorende organisatie, door een gestandaardiseerde aanpak met voorspelbare resultaten. Het inzetten van FSM en ISM voor dat doel leidt er toe dat niet alleen de resultaten voorspelbaar zijn, maar dat ook de kortste weg naar het doel kan worden gevonden, de goedkoopste reis kan worden gemaakt en de beste borging van dat resultaat kan worden bereikt.
De hamvraag bij dit alles is natuurlijk of een organisatie:
1. zich wel bewust is van het aloude gegeven dat organiseren vóór automatiseren komt,
2. voldoende ‘organisatiepijn’ heeft,
3. bereid is om te accepteren dat een managementstandaard ook op de eigen organisatie van toepassing is.
Wie er van overtuigd is dat hij/zij in een unieke organisatie werkt waar de ‘normale’ aanpak niet werkt is natuurlijk veroordeeld tot de gebruikelijke maatwerkaanpak. Met alle gevolgen van dien.
Jan van Bon, directeur Inform-IT
Alumni-bijeenkomst
Wie meer wil weten over deze aanpak is van harte welkom bij de Alumni-bijeenkomst van NOVI, op 8 november in Utrecht, waar het negenvlaksmodel, ISM en FSM onderwerp van discussie zijn. Wacht niet te lang met aanmelden want het aantal stoelen is beperkt.
Jan,
Wat je hier allemaal schrijft klinkt logisch en lijkt te kloppen als een bus, in theorie tenminste. Want de praktijk is weerbarstiger omdat niet iedereen meer met de bus gaat.
Zo hebben we tegenwoordig BYOD, Cloud, Het Nieuwe Werken en nog een heleboel andere ontwikkelingen die hun impact hebben op de processen, zowel van de business als het beheer.
Roepen dat je moet organiseren voordat je gaat automatiseren staat bijvoorbeeld dan ook lijnrecht tegenover de eis vanuit de business. Want het moet toch allemaal sneller, goedkoper en mooier?
Op die manier zal er dus altijd een probleem in de afstemming tussen business en IT blijven.
Je hebt helemaal gelijk Ewout – zolang je jezelf niet organiseert loop je altijd achter de feiten aan.
Maar techniek heeft geen invloed op processen, alleen op procedures en werkinstructies. Als je je dus volgens processen organiseert kun je BYOD, HNW en de Cloud veel beter aan. En als je goed georganiseerd bent kun je veel flexibeler en sneller diensten leveren. Was dat niet precies wat de business wilde? Als rechtgeaarde techneuten lopen we echter liever met z’n allen achter die techniek aan. Ken je het houthakkers-syndroom?
NOVI biedt een eendaagse training Procesmatig managen van Functioneel Beheer. Misschien de moeite waard daar die ene dag aan te besteden en de kwestie eens van een heel andere kant te bekijken…
Jan,
We zullen vast een behoorlijke boom op kunnen zetten over procesmatig werken omdat dit niet altijd synoniem is met efficiënter;-)
Erg interessant stuk. De reactie van Ewout, die mogelijk een paar ITIL trajecten te veel heeft gedaan, kan ik me voorstellen. Bij dat soort trajecten geldt al te vaak dat procesmatiger werken niet efficiënter is. Dat komt doordat er te veel processen zijn en, zoals als Jan al stelt, ‘best practices’ niet ingevoerd kunnen worden en er bij ITIL geen sprake is van een management model: de bestaande lijn blijft volledig overeind en clasht op alle fronten met de procesorganisatie.
Hoewel ISM (en ook FSM) een veel natuurlijker en logischer architectuur biedt en wordt ondersteund door een methodische invoering is het niet gezegd dat daarmee alle problemen in een beheersorganisatie als sneeuw voor de zon verdwijnen. De kans is echter vele malen groter dan bij ITIL trajecten en het gaat vele malen sneller. ISM werkt met gestandaardiseerde processen waarbij het adagio geldt: behoudt het goede en concentreer je op wat je wilt verbeteren. Daarmee is de eerste druk van een verandertraject bij de organisatie weggehaald. Waarom zou je meteen veranderen wat goed gaat? Niet doen dus, maar je procedures inpassen in de (ISM) standaard en gaandeweg aanscherpen en ondersteunen met werkinstructies die voor jou organisatie praktisch gezien het beste resultaat geven.
Ik heb bij grote IT beheerorganisaties gewerkt die al jaren bezig waren met ITIL, ASL en/of Bisl en waar de levering van IT services nog steeds een rommeltje was. Ze werd alleen nog overeind gehouden door een handjevol servicedeskmedewerkers en specialisten dat zich iedere keer opnieuw uit de naad werkte om de klant van dienst te zijn. De horde managers die de processen aan het uitdenken waren vroegen deze mensen niet om input, noch om commentaar, met als gevolg onwerkbare processen die vaak per afdeling verschilden en ook per afdeling anders werden aangestuurd. Hoe kun je in zo’n omgeving efficiënt en effectief werken? Niet dus.
ISM (en ook FSM) laat voor de inrichting en vaststelling van de basisprocedures de beheerders zelf aan het woord. Die moeten daar erg aan wennen en zetten in veel gevallen eerst de hakken in het zand. Maar als ze eenmaal doorhebben dat de verandering stapsgewijs en gestructureerd wordt doorgevoerd, vooral wordt gevoed met hun eigen kennis en ervaring en dat er simpelweg afspraken worden gemaakt binnen een logisch samenspel van servicemanagementprocessen, verdwijnt in de meeste gevallen de weerstand vanzelf. En dan kan het hard gaan. Het inzicht wordt verder versterkt door opleiding, inrichting van tooling, rapportage, gestandaardiseerde templates en diverse andere middelen.
Ik ben enthousiast over ISM (en ben dat op voorhand al over FSM). Er is echter een belangrijk risico waar elke organisatie mee te maken krijgt: de onwil om een cultuurverandering door te voeren. Denk aan management dat zich niet 100% committeert aan de nieuw ingeslagen weg en daarmee het delicate veranderproces frustreert. Of kenniseilandjes die niet worden gemanaged op het delen van hun kennis en daarmee standaardisering in de weg staan. Of projectorganisaties die hun invloed (en status) zien afnemen omdat de beheerorganisatie in control komt. Het hoort er allemaal bij. Maar daar waar de lijn in staat is meer verantwoordelijkheden bij procesmanagement te leggen en deze hierbij te faciliteren en te ondersteunen wint iedereen, de business voorop.
Voor de filosofische vrijdagmiddagborrel:
Er wordt enkele malen gesproken over “best practices”
Deze bestaan mijns inziens niet. Dit impliceert namelijk dat het niet beter meer kan……
Hans,
Je kunt nooit een (leer)traject teveel gedaan hebben maar wel het zicht op de werkelijkheid verliezen, door de bomen het bos niet meer zien. En dat kan er vervolgens weer in resulteren dat mensen zich achter processen (voorschriften) gaan verschuilen. Ooit zei een generaal eens tegen mij: “Voorschriften zijn een handleiding, enkel richtinggevend maar niet bedoeld om je hoofd niet meer te gebruiken.”
PaVeKe,
Ik ga met je mee omdat er alleen ‘good practices’ bestaan en de wil om te verbeteren pas voor de overtreffende trap zorgt in ‘Better practices’ *plop*
Ewout,
Precies. En omdat je dat ziet gebeuren zou je ISM op waarde moeten kunnen schatten. De methode helpt je organiseren, inrichten en aansturen van je serviceprocessen. Het gaat dus om het procesmatig inrichten van de werkwijze. De werkwijze zelf (de specifieke werkinstructie) is uniek voor elke organisatie. Voor die inrichting wordt gebruik gemaakt van zes generieke processen in een logische procesarchitectuur. Helder en inzichtelijk voor iedereen.
Jouw generaal zou ISM ook binnen het leger goed kunnen gebruiken en niet alleen voor IT. Juist met ISM zullen beheerders hun hoofd gebruiken, omdat ze door verbeterde afspraken, werkwijze en kennisdeling steeds meer (en dus niet minder!) ruimte krijgen om dat te doen.
Hans,
Die generaal wist trouwens niet waar de afkorting GUP voor stond maar dat terzijde. Ik stel waarde van ISM ook niet ter discussie ik heb alleen enkele kritische noten, bijvoorbeeld op de benadering van de praktijk vanuit een theoretische kader. Misschien ken je de uitdrukking: “Als het boven druppelt, dan regent het beneden” waarmee ik wil zeggen dat er vooral wat schort aan de visie op het beheer van al die techniek die alleen maar complexer wordt en steeds verder en sneller uitdijt.
Je had het over (kennis) eilandjes en laat ik daarover toevallig een aantal opinies geschreven hebben en misschien dat je die eens moet lezen om te begrijpen dat ik enigszins moe wordt van telkens dezelfde verwachtingen die gewekt worden, vooral als er ergens een ‘knip’ gemaakt wordt tussen proces en techniek. Want hoe kun je nu besluiten over iets wat je niet weet of waar je geen weet van hebt?
Een eenvoudige en vaak onbeantwoorde vraag naar aanleiding van alle modellen en architectuur tekeningen die ik zie en stel is: ‘Waar zit de waarde, wat is het risico en hoe garandeer je de dienstverlening’ en dan laat ik in mijn eerste vraagstelling nog de wie, waarom en wanneer vaak weg. Betreffende die weglating is de vraag aan jouw dus wie nu precies voordeel heeft van ISM, waarom ik ISM moet adopteren en wanneer de beloofde waarde werkelijk zichtbaar wordt?
P.S.
GUP staat voor GevechtsUitPutting, een term die voor het op de ‘automatische piloot’ uitvoeren van activiteiten staat waarbij niet meer nagedacht wordt maar vooral reactief gehandeld wordt, bijvoorbeeld door het uitvoeren van ‘Best practices’ die vaak erg tijd en techniek gebonden zijn.
Dat de generaal mij niet ging vertellen hoe ik een geweer moest gebruiken, een peleton moest leiden of de ‘mannen’ kon motiveren zal je hopelijk wel begrijpen;-)
@Ewout
Interessante vergelijking, die denk ik een deel van het pijnpunt van vele procesmodellen weergeeft:
Het kunnen uitvoeren van taken op automatische piloot vergt een stuk training, inzicht en ervaring.
In de ICT sector zien we echter steeds minder mensen die hiertoe in staat zijn. Men verschuilt zich achter processen, definities en SLA’s om onkunde te verbloemen. Meedenken met de klant is er vaak niet meer bij.
Procesbouwwerken zouden bedoeld moeten zijn om werk efficiënter te maken. Vanuit ICT perspectief gedacht lukt dat misschien nog wel, maar vanuit de klant gezien werken ze vooral frustrerend.
Enkele voorbeelden ter illustratie:
– Als gebruiker heb ik een probleem. Ik bel de helpdesk en die administreren mijn verhaal. Enkele dagen later vraag ik of ze al iets aan mijn probleem hebben kunnen doen. Helpdeskmedewerker zoekt en zoekt, maar vindt mijn vraag niet terug. Wat blijkt achteraf: mijn probleem zit in het bakje “incidenten” in plaats van het bakje “problemen”.
– Ik wil een simpel iets veranderd hebben als gebruiker. Dit blijkt 10 dagen te duren eer het gerealiseerd is. Op de vraag waarom dit zo lang duurt: sorry meneer, dit is lage prioriteit, en volgens onze SLA hoeven we dit pas binnen 10 werkdagen op te lossen.
– Ik wil als gebruiker een uitbreiding van 250 GB op mijn opslagcapaciteit. Sorry meneer, dat kan niet. In de SLA is gesteld dat u max. 50GB per keer mag aanvragen. Ok, dan doe maar 5 keer 50 GB. Sorry meneer, dat kan ook niet, want als u al een uitbreiding heeft aangevraagd, mag u er niet nog één aanvragen.
– Ik kan niet inloggen op het netwerk, en mijn collega’s op de afdeling ook niet. Heeft al proberen opnieuw op te starten, zit uw stekker er wel in etc … Ja sorry meneer, deze vragen moeten we standaard stellen