It-managers bevinden zich al jaren in een spagaat tussen it en de business en in de huidige economie neemt die druk zeker nog niet af. Aan de ene kant wil de directie dat de it-manager meer doet met minder, aan de andere kant moet de it-manager nog teveel tijd besteden aan operationele zaken. Hij wil immers te allen tijde grip houden op zijn it-organisatie.
Hoe kun je it nu zo op de business afstemmen dat duidelijk is wat de it-afdeling kan leveren en zorg je er tegelijkertijd voor dat it kan voldoen aan de wensen van de business? Wat voor invloed heeft dit op de te leveren diensten en de kwaliteit van de dienstverlening? Zou het niet beter zijn als de it-manager zich kan focussen op het daadwerkelijk afstemmen van it op de business in plaats van zijn tijd te verliezen aan het blussen van operationele brandjes?
De ideale wereld
Uit de CIO Study 2011 van IBM bleek dat cio's wereldwijd vinden dat ict-medewerkers niet alleen verstand moeten hebben van techniek, maar ook over vaardigheden moeten beschikken om (bedrijfs)processen te snappen. In de bijbel aller it-procesbeschrijvingen – Itil v3 – zijn 29 processen beschreven. Geen makkelijke opgave dus, die de cio hier bij de it-afdeling neerlegt. Er is wereldwijd – zeer waarschijnlijk – geen bedrijf dat al deze 29 processen heeft ingericht. Zelfs al zou dit het geval zijn, dan nog is het lastig of onmogelijk om ermee te werken. Het uitgangspunt van Itil is namelijk ‘de ideale wereld'. Omdat 29 processen gewoonweg erg veel is en in veel kleinere bedrijven de meeste processen vaak niet voorkomen, is het lastig om aan dit ideaal te voldoen. Bovendien hebben bedrijven vaak moeite met het in stand houden van gemaakte afspraken en procedures, zeker als het er veel zijn. Dat de it-manager vaak moet bijspringen om de operationele zaken in goede banen te leiden, is hierdoor ineens wel een stuk makkelijker te verklaren.
De juiste keuze
Bij de implementatie van Itil beginnen bedrijven vaak helemaal vanaf het begin. In de meeste gevallen wordt dan alles opnieuw ingericht. Dat is niet efficiënt, want in veel gevallen hebben organisaties zelf al wel een aantal processen ingericht die prima functioneren. De meeste bedrijven blijven echter steken bij de implementatie van vier tot zes processen. De belangrijkste vraag hierbij is: heeft de it-manager met deze vier tot zes processen voor de juiste processen gekozen? Met andere woorden: zijn dit de processen waarmee je de kostenbesparingen realiseert die beoogd zijn en die er tegelijkertijd voor zorgen dat de it-manager meer tijd krijgt voor het ontwikkelen van langetermijnstrategieën?
Standaard zonder discussies
Enkele jaren geleden is er op basis van Itil een nieuwe methodiek ontstaan: ISM, oftewel Integrated Service Management. In het ISM-procesmodel worden in slechts zes elementaire processen de werkzaamheden volledig geïntegreerd beschreven. Deze zes processen, die tot op activiteitenniveau zijn uitgewerkt, sluiten aan op de Itil-processen. En anders dan alleen een omschrijving van best practices, legt ISM uit wat er nodig is voor de inrichting en verbetering van het it-beheer. Door beperking van het aantal processen en het nemen van de huidige situatie als uitgangspunt is ISM in de praktijk veel beter realiseerbaar dan Itil. Steeds meer organisaties kiezen dan ook voor deze methode. Door gebruik te maken van een standaard worden discussies vermeden en ontstaat er duidelijkheid voor alle betrokkenen. En – zeker niet onbelangrijk – het zorgt ervoor dat de it-manager zich kan focussen op zijn primaire taak: het optimaal laten functioneren van de business met behulp van it, in plaats van het blussen van brandjes in de operationele sfeer.
Ik ga met je mee als je het over het verbeteren van processen heb. Deze verbetering kan in de vorm van verkorten of verminderen van het aantal processen zijn of iets anders.
Ik denk dat deze verbetering weinig effect heeft op het aantal brandjes dat de ict-manager moet nog blussen. De brandjes zijn ontstaan door een opsomming van kennis te kort (van nieuwe producten en ontwikkelingen) op interne beheerafdeling, gebrek aan ict-visie binnen het bedrijf( veranderen van ict in ict-oerwoud), verkeerde aanpak en uitvoering van interne projecten en nog een aantal van dit soort zaken.
Als voorbeeld, hoe vaak zijn virtualisatie-trajecten (desktop, applicatie, server) verkeerd ingeschat, aangepakt en uitgevoerd zodat de ict-manager en de beheerafdeling na de afronding van het traject lang bezig waren met het blussen van virtuele brandjes!!
@Reza: Bedankt voor je reactie. Er zijn zeker meerdere factoren die invloed hebben op het fenomeen brandjes blussen. Een deel daarvan is ook te relateren aan het werken volgens de juiste procedures. Bij veranderingen wordt het change proces gebruikt waar relevante stappen in zitten die moeten borgen dat er volgens de juiste kwaliteitsnormen wordt gewerkt.Hieronder vallen goede voorbereidingen – denk aan het opleiden, vaststellen van de scope en kwaliteitscriteria -, het testen – dit kan zowel intern als met de klantorganisatie en implementeren. Door deze stappen goed te beschrijven, in te voeren en te bewaken zullen er zich minder en minder grote problemen voordoen tijdens de operatie.
@Reza. Je geeft het juiste voorbeeld om te ondersteunen waarom ISM een verbetering is. Behalve dat ISM de processen heeft geïntegreerd (ISM = Integrated Service Management) wordt het vergezeld van een complete set hulpmiddelen die er aan bijdragen dat aan basale voorwaarden voor gestructureerd en procesmatig werken wordt voldaan. ISM legt de nadruk op de keuzes die je als organisatie moet maken nog voordat je überhaupt met het inrichten van de processen begint. Maak je die keuzes namelijk niet dan ben je er als organisatie gewoon (nog) niet aan toe. Zo simpel is dat. En dat verklaart de terugkerende fouten, het slecht naar elkaar luisteren, de eilandcultuur bij veel organisaties en zo verder.
ISM stelt je van te voren cruciale vragen en dwingt je na te denken over de toekomstige inrichting en uitvoering van de dienstverlening. Die dienstverlening is gebaseerd op simpele principes: Afspreken, leveren, herstellen, wijzigen, informeren en voorkomen/verbeteren.
Een van de belangrijkste plussen van ISM is dat managers eigenaar worden van een of meer processen en daar dus daadwerkelijk verantwoordelijk voor worden. En wie zich niet meer kan verschuilen achter hiërarchie en politiek wordt gedwongen zijn werk te doen zoals het hoort en te leveren wat is afgesproken.
Michiel,
Terecht om te stellen dat het rationaliseren van processen meer oplevert, wat ook de basis is van het kiss-principe. En om complexe materie te vereenvoudigen gebruiken we daarom modellen, wat dus een versimpelde weergave is van de werkelijkheid. We hebben in ITSM dus veel, heel veel raamwerken (~63) die ieder hun sterke en zwakke punten hebben maar vaak weer een afgeleide zijn van ITIL. En allemaal hebben ze tot doel om procesmatig en gestructureerd te werken. Structuur is tenslotte onze houvast in de complexe wereld van IT waar alles tegenwoordig snel veranderd en met elkaar verbonden is.
Nu zijn al deze raamwerken geen doel maar een middel wat nog weleens vergeten wordt. Terecht dus om te stellen dat de huidige situatie het uitgangspunt moet zijn om te voorkomen dat energie gestoken wordt in processen die geen toegevoegde waarde hebben. Ook goed is het geven van richtlijnen om de processen in te richten, wat zeker bij ITIL nog weleens ontbreekt omdat beschrijvingen te abstract zijn. Maar het is een droom om te denken dat invoer van een methodiek een reactieve beheerorganisatie op slag zal veranderen in een volwassen business partner. Je veranderd namelijk makkelijker de middelen dan de mensen.
Neem als voorbeeld de ingezette trend van virtualisatie, wat eigenlijk niet veel anders is dan het oude dozenschuiven dat we al deden in de gedistribueerde Windows omgevingen. Als configuraties toen al vastgelegd werden dan was het enkel summier en dus was er door de snelle wijzigingen in releases en infrastructuur altijd een gat tussen theorie en praktijk. Nu veel platformen virtuele entiteiten zijn geworden lijkt het wel of de CMDB alleen nog maar gevuld wordt met informatie uit de pakbonnen. Dat IT-managers dan brandjes moeten blussen zoals patchen van systemen of zoeken naar applicaties die in mistwolken verdwenen zijn is dus een logisch gevolg van de dynamiek die er is in de architectuur. Onder architectuur werken is trouwens ook zo’n mythe omdat er vaak niet alleen legacy in te vinden is maar het ook meestal de business is die dicteert. Uitzonderingen bepalen de regels maar vaak wordt hier door IT een vinger gegevens en eist de business even later de hele hand op.
Zo moeten opeens applicaties altijd beschikbaar zijn, willen gebruikers overal kunnen werken en ook nog het liefst met hun favoriete speeltjes. De business wil dus steeds meer tegen minder kosten want door virtualisatie en cloud is techniek tenslotte bijna gratis maar worden de verborgen kosten van gebruik en onderhoud niet zelden vergeten. Gelukkig hebben we tools nog, waaraan we net als processen ook geen gebrek hebben binnen IT want elk stukje techniek komt met zijn eigen beheermiddelen. Daardoor onstaan eilandjes die organisatorisch vaak ingericht zijn naar de lagen van het ISO model zoals opslag, platformen, netwerk en applicaties. De IT manager mist hierdoor het overzicht omdat een geconsolideerde view die gevuld wordt vanuit de werkelijkheid ontbreekt. Natuurlijk zijn er de architectuur platen, de tekeningen met ‘black boxes’ die ook vanuit een theoretische werkelijkheid worden gemaakt en waardoor changes doorgevoerd worden die nieuwe brandjes veroorzaken. Zoals tegenvallende responses of plotseling uitvallende services omdat even niet rekening gehouden was met de capaciteit van de infrastructuur.
Rationaliseren van (beheer)processen begint dus inderdaad met kijken naar wat je hebt en wat er aanvullend nodig is om te kunnen doen waar behoefte aan is. Procesbeschrijvingen zijn hierbij een goed uitgangspunt, een handleiding bij de inrichting van IT en de keuze van je beheermiddelen. Helaas worden beheermethodieken echter als techniek onafhankelijk gepositioneerd waardoor latere automatisering hiervan een onmogelijke opgave blijkt. Of er moet gekozen worden voor een leverancier afhankelijke vertaling hiervan in bijvoorbeeld MOF met Service Center van Microsoft. Nadeel daarvan is dat daarmee een ‘vendor-lock’ geïntroduceerd wordt die vaak weer voor oplopende kosten en eilanden in de architectuur zorgt waardoor uiteindelijk toch weer veel handmatig gedaan moet worden. Zoals het vullen en inrichten van de database die onder allerlei servicedesk tools ligt omdat deze vaak interfaces missen naar de verscheidenheid in gebruikte techniek. De vraag die dan ook bij mij naar boven komt is in hoeverre de oplossing van Mproof afwijkt van de andere 13 in een dozijn oplossingen.
Ik stel deze vraag omdat ik in de praktijk nog weleens dezelfde beloften tegen kom waarna een handvol ingehuurde mensen manueel alle informatie in zitten te typen of de invoer een meerjaren project is. Denk dat het onnodig is om te zeggen dat afspiegeling dan een momentopname is omdat de infrastructuur ondertussen al 3 keer gewijzigd is. Net als ITIL zelf welke al meer dan twee decennia bestaat maar blijkbaar nog steeds niet de verwachtingen waarmaakt als ik kijk naar de problemen die er nog zijn in Business-IT alignment. Misschien komt dat wel omdat IT niet zo gestructureerd meer is maar bijna organisch is geworden en services à la carte samengesteld worden uit de vele mogelijkheden die er tegenwoordig zijn. En met de cloud kan de business ook kiezen voor een afhaalrestaurant om zijn honger naar IT snel te bevredigen. In theorie zullen de processen hier wel een antwoord op hebben maar in praktijk zit de IT manager later toch met de shit omdat weer niet aan de beheermogelijkheden is gedacht.
Dergelijke artikeltjes als deze strelen mijn professionele oog. Men verwijt mij, en met mij ongetwijfeld gelijkdenkende professionals, dat wij soms wat ‘ouderwets’ zijn, ‘Het niet helemaal snappen’, ‘Niet met de tijd mee gaan’…. Enfin bedenkt u er zelf ook nog maar een paar.
Reden dit soort uitspraken te doen was het gegeven dat men telkens weer ‘nieuwe’ dingen bedacht, die helemaal niet zo nieuw waren overigens, en telkens een beetje de fout maakte dit een beetje verder van de materie IT weg te trekken. Daar had men overigens hele grappige NLP achtige trucjes voor om mensen van ‘iets’ te overtuigen.
Ik kan alleen al Het Nieuwe Werken even aanhalen dat allerminst Nieuw is. Waarom niet? Omdat de gedachte achter dat Nieuwe Werken een volkomen idioot idee is. Men denkt te vinden dat het erg leuk is om thuis te werken en zo mobiel mogelijk zou moeten zijn. Jammer genoeg leest niemand andere goede onderzoeken en onderbouwingen dat dit volkomen ‘kwatz’ is.
Niet alleen ben je op de zaak stukken productiever, je wordt daar tenminste niet door allerlei afleidingen beperkt of vertraagd, iets wat thuis vaker wel gebeurd. Een tweede is, en dat is meteen de basis van Mobiel Werken, dat je wat flexibeler kunt zijn in je productiviteit.
We hebben laptops zodat we onderweg ook nog productief kunnen zijn en tegenwoordig met wifi en modemsticks kun je altijd mailen en onderweg bij blijven. Een dagje thuis voor de kinderen blijven wordt wat makkelijker want je kunt gewoon beschikbaar en productief zijn.
Wat men niet verteld is dat gewoonweg niet iedereen geschikt is voor deze materie want het vraagt namelijk enig discipline, iets wat overigens lang niet iedereen bezit.
Het artikel streelt mijn ook omdat ISM namelijk een beroep doet op IT principes waarvan menig lezer, waarschijnlijk de maker van het artikel ook niet, niet eens weet wat de IT als materie is en hoe het zich beweegt. Er zijn namelijk ook wetmatigheden die de IT heeft en belangrijk zijn te weten maar het artikel stelt het al volkomen juist.
IT is bedoeld om repeterende processen te vereenvoudigen en te versnellen, met minder inspanning. En ISM is daar een heel mooi voorbeeld van. Wil je begrijpen hoe de IT werkt met processen in meest simpele vorm? Denk dan niet aan iets ingewikkelds maar dat ook dat op gaat voor de in te regelen processen van en voor IT.
Voor de happy IT-er en IT project manager, free of charge. :O)
http://www.numoquest.nl/civilematrix.html
ISM is tov ITIL inderdaad een hele stap voorwaarts. Wat echter voor alle implementaties van dit soort processen geldt is dat de implementatiepartner al snel de echte klant uit het oog verliest. Ook in dit stuk vind ik de echte klant er wat mager van afkomen.
Te vaak heb ik meegemaakt dat dit soort processen vanuit een “moeten” worden gedaan. Externe toezichthouders, auditafdeling en dergelijke. De kracht bij de implementatie bij onze ICT-organisatie dat we de processen inrichten op basis van betekenisvolle diensten in klanttermen.
Ook is nadrukkelijk de auditafdeling mee aan boord en geeft ons praktische normenkaders mee in plaats van achteraf vertellen dat we het niet goed doen. Bijzonder! Ook helpt het om de directie niet lastig te vallen met lastige procesplaten en pijlen maar in business taal uit te leggen welke bijdrage goed ingerichte processen kunnen leveren bij het behalen van hun doelstellingen. Of beter gezegd, een betere nachtrust.
ISM is wat de processen betreft terug in de tijd van nog voor ITIL versie 1??!!
De manager heeft het te druk. En dat komt omdat hij/zij teveel processen heeft in te richten en bewaken. Dat is de stelling van dit artikel. En de oplossing: minder kleine en globale processen, maar slechts een paar grote. Maar dan wel helemaal uitgeschreven tot op het niveau van werkinstructies.
Ik heb hele grote twijfels of dit het ei van Columbus is. Het komen met andere processen zal geen radicale verbetering opleveren voor de oververmoeide IT-manager, die niet toekomt aan wat er echt toe doen: business IT alignment realiseren.
Nee, volgens mij ligt de oplossing niet in wat de medewerkers doen (het uitvoeren van processen), maar het managen van de manager. Volgens Michiel is de manager te veel tijd kwijt aan het ‘blussen van brandjes in de operationele sfeer’. En juist dat zou de manager van nu veel meer moeten durven delegeren aan zijn teams. En die teams ook echt ‘empoweren’. En laat dan die teams zelf bepalen hoe zij vinden dat ze hun werk moeten organiseren. Kortom: transformeer managers tot regisseurs en werknemers tot empowered teams.
Laat de teams met de resultaten komen, niet de processen.
Aan de reacties te zien leeft het onderwerp. Vele bedrijven en IT managers hebben dezelfde uitdagingen. Ondertussen ben ik geïnspireerd voor een volgend artikel waarin ik zal uitleggen hoe het mogelijk is om met 6 kernprocessen toch de gehele dienstverlening georganiseerd te krijgen.
To be continued…