Het zijn lastige en moeilijke tijden. De business moet steeds sneller inspelen op marktontwikkelingen en eist dat de it daarbij ook sneller, beter en kosteneffectiever ondersteunt. De it-organisatie heeft echter de handen vol met de operationele problemen en probeert ondanks de druk op het budget, met man en macht de kwaliteit van de dienstverlening op peil te houden. In dit artikel wordt voor organisaties die het operationeel beheer binnen de eigen organisatie uitvoeren, een insteek beschreven waarin de mens ofwel het individu meer verantwoordelijkheid krijgt.
Businessbehoeften wijzigen tegenwoordig snel(ler) en it-omgevingen zijn niet altijd in staat om daar adequaat op in te spelen. Hiermee wordt het beeld geschapen en soms bevestigd dat de it-organisatie meer en meer de bottleneck gaat worden. Vanwege de druk van de business wordt de it-organisatie vaak gedwongen om korte termijn acties te ondernemen. Deze korte termijn acties resulteren echter na verloop van tijd in een slechte prijs/prestatieverhouding van de diensten en daardoor onbegrip bij de business over de (te) hoge it-kosten. Last but not least, de eigen it-medewerkers raken gefrustreerd omdat hun inzet niet of nauwelijks gewaardeerd wordt.
Hoe kunnen beide extremen, te weten de business met haar voortdurende eisen en wensen en de beheerorganisatie met haar natuurlijke weerstand tegen veranderingen, elkaar beter vinden? Uiteraard begrijpt de business dat kwaliteit geld kost en dat het ter beschikking stellen van nieuwe of zelfs verbeterde functionaliteiten niet binnen een dag te regelen is. Anderzijds ziet de beheerorganisatie ook de klantbehoeften sterk veranderen waardoor de business van hen verlangt dat zaken flexibel, snel en goedkoop te regelen zijn.
Problematiek
Welke mogelijkheden zijn er binnen de organisatie beschikbaar om uit deze gechargeerde patstelling te komen? Alvorens gelijk naar de oplossingen te schieten, is een analyse van de achterliggende problematiek van belang. Weliswaar is deze analyse bij elke organisatie anders, maar de terugkerende problemen liggen vooral op de inrichting van de it-organisatie en infrastructuur. De it-organisatie is niet van de een op de andere dag opgezet. Vaak is deze over de jaren geëvalueerd totdat het een stabiele toestand heeft bereikt. De ene it-organisatie is daarbij strakker ingericht dan de andere.
Bij strakker ingerichte organisaties zijn de rollen meer ingevuld en processen beschreven. De gelijke ontwikkeling zie je bij de it-infrastructuur. Deze is ook niet van de een op de andere dag ontstaan. En het doorvoeren van veranderingen betekent dan ook dat je rekening moet houden met de bestaande infrastructuur. Per definitie betekent dit dat de it-organisatie door zijn ‘verleden en bezit‘ tijd nodig heeft om veranderingen door te voeren.
Als korte termijn acties worden doorgevoerd om de business ten dienste te staan, verdwijnt het gevoel van ‘onder controle hebben' bij de it-organisatie. Als de it-organisatie er daarintegen in slaagt om stand te houden tegen deze druk, dan onstaat er bij de business het gevoel dat de it-organisatie geen partner en/of dienstverlener is.
Processen en procedures
De meest toegepaste aanpak bij het gebrek aan ‘controle' is dat men nog meer terug gaat vallen op processen en procedures. De achterliggende gedachte daarbij is dat de it-organisatie een beter voorspelbaar gedrag en reactietijden gaat tonen. Bij ‘extreem' doortrekken van deze benadering, resulteert dit veelal in de volgende symptomen:
– Hokjes cultuur. ‘Ik doe mijn onderdeel, volg de procedure nauwgezet en accepteer geen afwijkingen.' Input wordt alleen geaccepteerd als het volledig is (‘als ik het OK vind') en na voltooiing ‘draag ik het over aan de volgende proceseigenaar'. Iedere vorm van flexibiliteit en klantgerichtheid is dan ver te zoeken;
– Procesdenken is tot doel verklaard, hetgeen kan leiden tot het ‘Operatie geslaagd, patiënt overleden-syndroom'. Terwijl de business echt een probleem heeft dat ook niet opgelost kan worden;
– Een grote hoeveelheid projecten die uitlopen of mislukken;
– Vaak heeft men sommige beheeractiviteiten bij een externe leverancier ondergebracht waar men ook niet tevreden over is;
– En als het nog in house operationeel beheerd wordt, is de betrokkenheid van de eigen beheerder ver te zoeken. De beheerder voelt de pijn niet meer, want hij is ook niet verantwoordelijk voor het totaal.
Met het laatste symptoom wordt een gevoelig punt geraakt. Een goede beheerder wil zich juist verantwoordelijk voelen en zijn vakmanschap inzetten. Of kortweg gezegd, de beheerder wil zich (weer) trots en gerespecteerd voelen .
Kortom, een it-omgeving waarin het proces leidend is, heeft als grootste nadeel dat de betrokken- en klantgerichtheid van de beheerder laag is. Dit leidt tot een hoog personeelsverloop en vaak een matige klanttevredenheid.
Persoonlijke verantwoordelijkheid
Een volstrekt andere benadering is die van de vrije inrichting. Het procesdenken is losgelaten, alles draait om het persoonlijke individu. Laat de beheerders zich weer eigenaar voelen van alle it, of zij nu een systeem, applicatie of netwerk beheren. Samenwerken met elkaar is hierin het devies. Deze ‘hippie'-achtige of meer modern empowerment benadering gaat uit van de verantwoordelijkheid beleggen op het laagste niveau van de it-organisatie en maakt dat alle medewerkers zich betrokken voelen bij de organisatie en in controle zijn over de it-omgeving.
Het grootste bezwaar van deze aanpak is dat dit eigenlijk alleen goed werkt in een kleine it-omgeving. Voor een bank of een ander groot bedrijf leidt deze mensgerichte aanpak niet tot het gewenste resultaat en wordt de organisatie te afhankelijk van individuele medewerkers. Bovendien vereist wet- en regelgeving in vele situaties dat het beheer procesmatig ingevuld wordt waarbij alle processen, procedures en rollen gedefinieerd zijn zodat borging en traceerbaarheid gegarandeerd zijn. Kortom, een volledig vrije inrichting kenmerkt zich vaak tot een zeer hoge betrokkenheid maar leidt tot individuele willekeur en afhankelijkheid die vanuit bedrijfseconomisch standpunt niet gewenst is.
Structuur en persoonlijke inbreng
Beide uitersten bieden dus elk afzonderlijk niet het gewenste resultaat. De uitdaging is nu juist hoe je ‘best of breed' kunt bewerkstelligen. Hoe kan je als bedrijf je continuïteit borgen zonder afhankelijk te worden van individuen terwijl de menselijke betrokkenheid van de medewerker bovengemiddeld is. De praktijk laat zien dat dit zeer goed mogelijk is. De essentie van deze verandering is dat de beheerder meer ruimte en verantwoordelijkheid krijgt om zijn kennis en ervaring in te zetten. Concreet:
– Betrek de beheerders al bij de ontwerpfase opdat hun kennis van de omgeving en ervaring over de systemen en eerdere implementatietrajecten al in een vroeg stadium ten positieve gebruikt wordt. Beheerders zijn geen ontwerpers of specifiers. Zij zullen dan vaak ook niet in staat zijn om bijvoorbeeld specificaties op te stellen. Maar wanneer aan hen gevraagd wordt waarom het vorige systeem zo slecht functioneerde, is het alsof een waterkraan wordt opengezet;
– Betrek de beheerder ook bij de uitvoeringsfase. Wanneer het nieuwe systemen en/of applicaties betreft, dient geïnvesteerd te worden in een opleidingstraject. Natuurlijk kan dat door een training aan te bieden. Op zich is daar niets verkeerd aan. Echter de training vindt vaak plaats nadat het systeem al geïmplementeerd is. Misschien is een parallelle training on the job mogelijk. In eerste instantie kijkt de beheerder mee, in tweede en derde instantie gaat hij steeds meer zelf doen en wordt gecontroleerd. De beheerder heeft vaak de nodige basiskennis en ervaring die kan dienen als basis. Het resultaat is dat de op te leveren en te beheren systemen en/of applicaties al meteen een ‘onderdeel' zijn van de it-omgeving.
Door bovenstaande acties krijgt de beheerder het gevoel dat zijn kennis en ervaring gewaardeerd wordt en dat hij ook daadwerkelijk een bijdrage kan leveren. Er komt weer trots en verantwoordelijkheid terug. Initieel kost het betrekken van de beheerder in eerdere fasen meer tijd, maar het resulteert in meer betrokkenheid met als gevolg dat men meer in control is. Deze hogere controle stelt de it-organisatie vervolgens in staat om voortaan adequater te reageren op veranderende businessbehoeften. En op termijn levert dit alleen maar winst op. De business is meer tevreden over de it, de it voelt zich terecht meer betrokken bij de business en richting de klant kun je meer ‘value for money' leveren. En daar draait het eindelijk allemaal echt om.
Resumé
Het eerder betrekken van de beheerders bij projecten is op zich geen ‘rocket science'. En in principe kan geen enkele organisatie daar op tegen zijn. In de praktijk zien we echter dat projecten onder tijdsdruk staan, waardoor het eerder betrekken van beheerders als niet handig of te omslachtig wordt gezien. Vaak is er ook een schroom bij de beheerders om deze rol op te eisen, de huidige situatie is weliswaar minder productief maar wel veiliger en vertrouwder. Deze impasse kan daarom alleen doorbroken worden door het ‘forceren' en enthousiasmeren van de beheerders. Want eenmaal de schroom overwonnen, zien we dat de uiteindelijke doorlooptijd van het op te leveren systeem en/of applicatie korter is geworden en de kwaliteit hoger.
Wanneer deze investering in de beheerders structureel gedaan wordt, keert de mens weer terug in de it-organisatie. Daarmee komt de betrokkenheid en trots weer terug, wat resulteert in meer controle en regie en daardoor meer succes. Projecten, releases, wijzigingen en dergelijke worden sneller en succesvoller doorgevoerd, klanttevredenheid schiet omhoog en de operationele kosten gaan zeker dalen.
Herold Kroon, managing consultant bij Strict, en Edward Clarenbach, business development director bij Ordina
Herold & Edward,
Laten we eerlijk zijn, veel van wat jullie hier beschrijven komt min of meer ook herkenbaar terug in de Dilbert strips van Scott Adams. Zoals een herkenbaar gebrek aan eigenaarschap welke mede door (gedeeltelijke) uitbesteding is verdwenen. Of het verloren gegane initiatief omdat we dociel systemen bevredigen en gedwee de processen volgen. Enthousiasmeren van beheerders en eigenlijk de gehele ‘service support lijn’ vraagt dan ook niet alleen een mentaliteitsverandering bij uitvoerenden maar ook van leidinggevende. Laatsten moeten bijvoorbeeld wat meer vertrouwen op de kennis, kunde en inzet van mensen in plaats van hun excelsheets en rapportages. Daarin zit tenslotte alleen maar het verleden want de toekomst zit in de ‘ideenbus’ op de gang.
Stellen dat de operationele kosten omlaag gaan ligt misschien niet voor de hand als er gekozen wordt voor ‘skilled’ beheer in plaats van ‘knoppenbonkers’ omdat ervaring nu eenmaal geld kost. Maar ervaring zorgt er wel voor dat er niet telkens tegen dezelfde gestoten wordt en maakt beheer dus doelmatig in plaats van enkel doeltreffend. Hoe graag we het ook willen, ervaring zit niet in processen of systemen maar in mensen, meer menselijkheid komt dus zeker de kwaliteit ten goede. En als behandelaars in plaats van een nummer met een metalen stem weer een gezicht krijgen dan is de kans groot dat ook de klanttevredenheid toeneemt.
Wat willen de schrijvers nu benadrukken? Dat beheerders eerder betrokken moeten worden in projecten of dat beheerders niet in een procedureel keurslijf gedwongen moeten worden? Ik houd het even bij het laatste. En daarbij ben ik benieuwd welke processen de schrijvers in gedachten hadden en vooral vanuit welk raamwerk er is gedacht. Lees ik hier dat de overkill aan procesmatig en gestructureerd werken, bijvoorbeeld volgens ITIL, funest is voor individualiteit, zelfwerkzaamheid en zelfredzaamheid in ITSM?
“Te” is nooit goed, maar de vraag is volgens mij vooral of je überhaupt in staat bent je service en beheer goed te leveren zonder deze goed te organiseren en te structureren. Want slaag je daar namelijk wel in, dan ontstaat er per definitie ruimte voor het individuele aspect en voor het (verder) ontwikkelen en toepassen van kennis en ervaring. Met 26 ITIL “processen” lukt dat in de meeste gevallen maar ten dele, wat zich uit in een krampachtig vasthouden aan gammele processen die niet worden gedragen door het gros van de serviceorganisatie en voortdurend zorgen voor conflicten over en tussen taken, bevoegdheden en verantwoordelijkheden.
ITIL levert, daar waar het min of meer succesvol is, in 80% van de gevallen vrijwel gelijke mainstream processen. Dit inspireerde tot een procesarchitectuur die niet alleen logisch en consistent is, maar bovendien methodisch kan worden ingevoerd, terwijl er toch een grote vrijheid is in de invulling die daar per organisatie op procedure en instructie niveau aan gegeven kan worden.
We hebben het over ISM. Want wat doe je als ICT service organisatie: je spreekt af met de klant wat je levert, je levert dat, herstelt indien nodig en wijzigt waar noodzakelijk of gevraagd. Niets meer en niets minder: afspreken, leveren, herstellen en wijzigen. Hoe simpel kan het zijn en hoe eenvoudig het werk van een beheerder die volgens deze basisprincipes alle vrijheid heeft om vervolgens vast te leggen wat hij doet, hoe hij dat doet, waarvoor hij dat doet en wanneer hij dat doet. Doet hij dat niet of onvoldoende dan zitten we in no time weer in de kenniseilandjes cultuur, helpen we elkaar niet verder, moet ieder voor zich steeds het wiel weer uitvinden en kan het hele proces de prullenbak in. En daar, zo weten we allemaal, wordt uiteindelijk niemand wijzer van. Goed procesmanagement heeft alles te maken met slimmer werken.
Daar waar organisaties er met behulp van ISM wel in slagen hun processen daadwerkelijk in te richten en afspraken en werkinstructies vast te leggen en na te leven, blijft er wel degelijk ruimte over voor de vrije invulling. Sterker, er zal een 1+1 = 3 ontstaan. Gestandaardiseerde werkzaamheden die door vrijwel iedereen uitgevoerd kunnen worden scheppen ruimte bij degenen die hun skills voor specifieke problematiek kunnen inzetten. Goed georganiseerd en goed gedocumenteerd zorgt voor goed geïnformeerd, waar iedereen van leert, zogezegd.
Daarbij speelt ook de gebruikersorganisatie een belangrijke rol. Een ongecoördineerde, ongestructureerde vraag die niet getoetst kan worden aan eerder met de ICT organisatie gemaakte afspraken, zal leiden tot inefficiënte en ad hoc dienstverlening, met alle risico’s van dien. Dit creëert serviceorganisaties waar de waan van de dag regeert en waar de medewerker die op eigen houtje, naar eigen inzicht en zonder zijn werkwijze vast te leggen, oplost waar hij zin in heeft of op het moment dat de klant daar om vraagt “omdat dat zo klantgericht is”, doorgaans weinig benul heeft van de gevolgen van de keuzes die hij maakt. Lastige zaken blijven onnodig lang liggen, structurele oplossingen komen niet van de grond, er is onvoldoende communicatie en afstemming en nauwelijks control. Het maakt daarbij niet uit of er sprake is van een grote of kleine ICT service organisatie.
Overigens zijn projecten meestal changes op bestaande services. Indien het gaat om nieuwe services zal de aanvraag ervan via het SLM proces moeten lopen. Daarmee is (binnen ISM) de actieve rol van beheer al in het vroegste stadium belegd. Maar ook binnen het Change proces dient altijd getoetst te worden of een RFC binnen de SLA valt. Overigens kun je zelf afspraken maken over de inzet en rol van beheerders en deze simpelweg binnen het proces in de door jouw organisatie vastgestelde procedures en werkwijzen vastleggen.
Dit ongetwijfeld gechargeerde artikel schetst wat dat betreft een niet helemaal correct beeld van wat goed procesmanagement een organisatie zowel als haar medewerkers kan brengen. Mensen hebben enerzijds behoefte aan vrijheid, dat is waar. Ze moeten bewegingsruimte hebben en verantwoordelijkheid krijgen om op natuurlijke wijze hun kennis en ervaring te kunnen toepassen en uitbreiden. Anderzijds hebben mensen behoefte aan structuur, handvatten en hulpmiddelen, zeker in samenwerkingsverbanden en bij uitwisselbare rollen. Het gaat om de juiste dosering, de bereidheid om kennis te delen en met elkaar te zoeken naar efficiënt en effectief (samen)werken. Niet omdat dat moet, maar omdat we daar het nut van inzien, we het onszelf daarmee gemakkelijker maken en de klant beter van dienst kunnen zijn.
Als in dit artikel wordt betoogd dat ict-beheerorganisaties niet voldoende zouden kunnen inspelen op business vragen omdat ict-beheerders onvoldoende verantwoordelijkheid zouden hebben, dan kan ik me daar zeker iets bij voorstellen. Wel vooropgesteld dat dit niet de enige en al zeker niet de belangrijkste factor is voor gebrek aan business-it-alignment.
Dat de hedendaagse ict-beheerorganisaties een zekere mate van massatraagheid hebben ontwikkeld als het gaat om het reageren op businessvragen, lijkt me overduidelijk. Praat hierover met een willekeurige vertegenwoordiger van de business, en ook hier zal de spreekwoordelijke kraan opengaan. Ict-beheerorganisaties hebben nu eenmaal te maken met een bestaande infrastructuur en een bestaand applicatielandschap dat in de loop der jaren is ontstaan als gevolg van besluiten op bestuurlijk niveau die niet altijd voldoende zijn doordacht of waarbij bewust is gekozen voor sub-optimale oplossingen. Ga er maar aanstaan als beheerder, om met enige regelmaat tegen beter weten in veranderingen te moeten doorvoeren, en graag nog een beetje rap ook. Beheerders ondervinden als geen ander (als laatste in de ‘voedselketen’) de negatieve gevolgen van de genomen besluiten. Eerder betrekken van beheerders in projecten kan echter alleen een bijdrage leveren aan een oplossing als beheerders een (mede)beslissende stem krijgen. Gebeurt dat niet, dan zal de vaak aanwezige frustratie bij beheerders alleen nog maar toenemen. Daarnaast zijn beheerders ook nog eens vrijwel altijd structureel overbelast. Als zodanig zal er bij beheerders niet veel ruimte noch veel animo zijn om ook nog eens in projecten te gaan meedraaien. Het betreft hier mijns inziens dus een volledig andersoortige impasse dan die in het resumé van het artikel wordt aangegeven. Oplossing ligt dan ook niet in ‘forceren’ (…) en enthousiasmeren van beheerders, maar in het scheppen van de omstandigheden waarbinnen beheerders hun verantwoordelijkheid kunnen nemen en kunnen waarmaken. Een managementuitdaging dus, die al begint bij het nemen van besluiten over de manier waarop business vragen moeten worden aangevlogen.