Angst of arrogantie van de IT manager? Over belangrijke drempels bij de implementatie van alom bekende processtandaarden.
Processtandaarden helpen bij ons streven naar efficiency.
In ons streven naar efficiency gaan veel organisaties over tot centralisatie en standaardisatie van hun it-beheer: IT moet haar diensten leveren als een operational excellence organisatie. Dat betekent een PDC (Producten en Diensten Catalogus) met een beperkt aanbod aan standaard producten en diensten, soepel geleverd tegen een lage prijs. En door die standaardisatie van producten en diensten kunnen ook de achterliggende processen worden gestandaardiseerd.
De facto processtandaarden en met name ITIL, maar ook ASL en BiSL, bieden daarvoor de handvatten. Om te toetsen of er professioneel wordt gewerkt, (lees, of er volwassen met die processen wordt omgegaan) wordt CMMi als toetssteen ingezet.
Het gaat nog te vaak mis
Veel invoeringstrajecten van dit type processtandaarden lopen spaak, ondanks uitgewerkte procesplaten, mooie handboeken, externe hulp, daarvoor gebudgetteerde middelen en veel goede bedoelingen: wat zien we?
Uiteindelijk zien we veel pogingen om werkprocessen te standaardiseren en te professionaliseren doodbloeden. Een desinvestering van vaak honderden interne en externe uren. Los van de frustraties van alle medewerkers die erin in geloofden en er hard aan hebben getrokken.
Als we iets verder kijken zien we dat IT-managers nog al eens in een grote boog om die processtandaarden heen lopen. Ze claimen, ogenschijnlijk arrogant, dat ITIL “meer iets is voor de werkvloer”. Geven wel toe dat ITIL prima is, maar “dat het vooral niet moet leiden tot extra bureaucratie, want wie zit daar nou op te wachten?”. Kunnen ook moeilijk anders, want de opmars van deze processtandaarden is niet meer te stuiten. Je kan je er dus niet openlijk tegen verzetten. Maar, maar weinig IT-managers gaan er echt vol voor.
De procesmanager is dan de kop van jut. We zien vaak een conflict tussen de IT-manager en de procesmanager.
Iets meer over de procesmanager
Met de introductie van het ITIL gedachtegoed is er binnen IT meer aandacht gekomen voor procesmanagement. Procesmanagement is de taak om te letten op de werking van processen die horizontaal over afdelingen heen lopen en op de resultaten van die processen. Doel is processturing. De procesmanager heeft de verantwoordelijkheid om te letten op de juiste werking van het proces en op de targets die zijn gesteld voor de resultaten van zijn proces. Als hij afwijkingen vaststelt, de medewerkers lappen het proces aan hun laars of komen de afspraken over de doorlooptijd van een change niet na, rapporteert hij dit aan zijn opdrachtgever en stelt herstelacties voor. Hij meet dus voortdurend hoe het met zijn proces en de resultaten daarvan gaat. Hij meet bijvoorbeeld hoeveel incidenten eruit een change voortkomen (NB een lastige maar zeer waardevolle meting).
Een lijnmanager is meestal zijn opdrachtgever. Die lijnmanager is dan formeel de proceseigenaar van zo’n proces. De procesmanager helpt de lijnmanager om het proces aan te sturen. Procesmanagement wordt soms als rol en soms als functie aangetroffen en kan er zijn in meerdere gradaties. De procesmanager kan alleen signaleren, maar ook kan het zijn dat hij processen ontwerpt, medewerkers in het proces opleidt en geheel zelfstandig corrigerende actie uitvoert die hij achteraf bij een lijnmanager verantwoord. Lijnmanager en procesmanager kunnen elkaar uitstekend aanvullen. Maar er komt nog veel onbegrip tussen deze twee partijen voor.
De lijnmanager wordt overspoeld door alle rapportages van de procesmanager. Hij krijgt de indruk dat de procesmanager een deel van zijn lijnmanagementtaken overneemt. En zo komt het voor dat, na een aanvankelijk succesvolle start, de procesmanager na anderhalf jaar afgezonderd in zijn proceslaboratorium zit en, ver van de wereld, verder aan zijn ITIL-proefballonnetjes bouwt. Alle goeie bedoelingen ten spijt drijven de IT manager en de procesmanager steeds verder uit elkaar.
Wat is er aan de hand, waarom die ogenschijnlijke arrogantie en waarom die angst voor de procesmanager? Hoe komt dat?
Een andere manier van sturen
Met ITIL, BiSL, ASL, sluipen de principes van de matrix-organisatie, het procesgericht denken en werken, de IT-organisatie impliciet binnen.
Dat wordt bij weinig procesimplementaties aan de IT-lijnmanagers duidelijk gemaakt.
Sturen op processen is een ander en vaak nieuw aandachtsgebied. Je kan het vergelijken met een estafette waarbij iemand er op moet letten dat het stokje steeds goed en op tijd moet worden doorgegeven. Traditioneel worden afdelingen verticaal aangestuurd. De IT-afdelingsmanager let op het wel en wee van zijn afdeling. Heeft hij zijn deel van de race goed gelopen, dan is zijn klus geklaard. Maar tussen die verticale afdelingen kan het stokje op de grond vallen en er is niemand die daar op let.
De meeste IT-managers realiseren zich onvoldoende dat er horizontaal op processen gestuurd moet gaan worden. Zij realiseren zich niet dat ze met ITIL een ander sturingsparadigma binnenhalen: naast het traditionele “verticale” sturen op afdelingen (op indicatoren als ziekteverzuim, fte’s, externe kosten en te blussen branden), moet er horizontaal op processen gestuurd gaan worden. Processen, die horizontaal over alle onderafdelingen van IT heen lopen. Ze realiseren zich vaak evenmin dat de ITIL-procesmanagers hen daarbij kunnen en moeten ondersteunen.
Stuur je op processen dan let je, naast op je verticale management taken, ook op het proces dat horizontaal over verschillende afdelingen heen loopt. De IT-manager neemt naast zijn afdelingstaken, ook de verantwoordelijk op zich dat de estafette, van bv het incidentmanagement proces, binnen de afgesproken tijd, volledig en volgens de afgesproken route wordt afgelegd. De IT-manager is, als het spel goed wordt gespeeld, tot eigenaar benoemd van een van de ITIL processen. De procesmanager gaat hem helpen met inzicht in de manier waarop de IT-organisatie omgaat met het proces zelf en de resultaten van het proces.
Procesmanagers zijn geen lijnmanagers maar regelaars. Ze regelen dat het nieuwe proces goed in elkaar zit en blijft passen op de organisatie. Ze regelen dat alle medewerkers het proces blijven volgen. Ze regelen dat het proces blijft lopen, dat bv changes en incidenten op tijd door de medewerkers van alle betrokken afdelingen worden opgepakt. Dat klanten daarvan op de hoogte gehouden worden. Ze regelen dat de IT-manager, die proceseigenaar is, op basis van een paar cijfers kan zien hoe het met zijn proces gaat en doen voorstellen wat er moet verbeteren als nog niet alles op rolletjes loopt.
Begrip van de werking van de best practices
Het is niet eenvoudig om alle ontwikkelingen rond zaken als ITIL-2, ITIL-3, ASL, BiSL en CMMi goed te volgen. Er gebeurt veel en daarnaast maken de procesdeskundigen dit soort zaken voor de IT manager niet veel helderder. Zij rollen over elkaar heen met de meest ingewikkelde schema’s en vakterminologie. Ze trekken onbedoeld een mist op die de essentie van het procesgerichte denken en werken tot een hyperspecialisme lijkt te maken. En een hyperspecialisme hoort natuurlijk ook in een laboratorium thuis.
Daarbij is het lastig, om duidelijk voor de geest te krijgen hoe al die processen chronologisch samenhangen. In uitbundige schema’s worden allerlei relaties neergezet, maar zelden is in een oogopslag te zien waar je moet beginnen om waar uit te komen. Die helderheid is de voorwaarde voor een goed begrip van het aansturen van een op standaardprocessen gebaseerde beheerorganisatie.
Het dilemma voor iedere IT-manager van stand is, dat hij toe moet geven dat hij hulp nodig heeft om de theorie van al die “alom bekende” best practices goed te interpreteren. En wie durft openlijk te roepen dat hij niet precies weet wat de ITIL processen in hun samenhang doen? Omdat onbekend nog steeds onbemind maakt, knaagt een dergelijk tekort aan inzicht, aan de managementdrive en daarmee aan de basis van veel implementaties.
Dus moet iedereen zijn steentje bijdragen.
Het lijkt op arrogantie als een IT-manager hij zegt dat “die ITIL processen meer iets zijn voor de werkvloer”. Maar eerder is het de angst hoe het hem lukt, zich zonder gezichtsverlies in de essenties van de facto processtandaarden en best-practices te verdiepen.
Het is aan de IT-manager zelf om die drempel te nemen en zijn kennisvacuüm goed en afdoende te willen vullen.
Het is de taak van de (interne of externe) adviseurs, die te hulp worden geroepen bij de implementaties van best practices, om de IT-manager erop te wijzen welke andere (horizontale) manier van sturen er impliciet de organisatie binnenkomt. Ook moeten zij de IT-manager gidsen bij zijn tocht door het woud aan schema’s en procedures, op weg naar de essenties van het werken met een set van samenhangende best practices. Daarmee wordt de basis gelegd voor een goede relatie met zijn procesmanager.
Tot slot is het de taak van de procesmanager om zijn IT-manager beknopt te informeren over de juiste werking van de best practices, zijnde de processen, de resultaten daarvan en de verbetermogelijkheden.
Als dat allemaal lukt hoeft geen IT-manager bang te zijn dat de procesmanager delen van zijn taak als bestuurder van de IT-organisatie overneemt. Integendeel, hij zal blij zijn met zijn hulp.
