Archive by Author

Dramadriehoeken in servicemanagement, en hoe je ze vermijdt

Dramadriehoeken leiden tot gebrekkige samenwerking tussen partijen. De klant c.q. de gebruikersorganisatie is daarvan de dupe. Een methodische aanpak helpt je om dat effect te voorkomen.

Een dramadriehoek is een relatie tussen drie partijen, waarbij het in de samenwerking mis gaat. Elk van die drie partijen heeft eigen belangen, waardoor het stelsel (de driehoek) faalt.

De oorzaak van een dramadriehoek is te vinden in slecht afgestemde relaties tussen in ieder geval twee van die drie partijen. Het falen van de samenwerking uit zich dan in communicatie- en coördinatieproblemen, die leiden tot slechte prestaties.

Outsourcing

Onderstaande figuur illustreert een dramadriehoek bij outsourcing. De rood gestippelde pijl duidt de relatie aan waar het mis gaat. De zwarte schaduwrand duidt op de noodzakelijke regietaak van de opdrachtgever.

Als de afspraken tussen de opdrachtgever en beide toeleveranciers/oplosgroepen niet voorzien in een effectieve samenwerkingsrelatie, dan hoef je vaak niet lang te wachten op problemen. Zodra de demarcatielijn tussen de uitvoerende partijen voor minimaal één van beide niet meer helemaal helder is, en er doet zich een situatie voor waarin een issue ‘tussen wal en schip valt’, dan gaat die issue pingpongen tussen de beide uitvoerders:

“Je moet bij de één zijn.”

“Nee, je moet bij de ander zijn.”

De opdrachtgever is dan de dupe van zijn eigen (gebrekkige) afsprakenstelsel.

Omdat de verschillende uitvoerders sturen op verschillende belangen en doelen, ontstaat een integrale service (prestatie) die niet goed past op de belangen van de opdrachtgever c.q. de gebruikersorganisatie.

Voorbeeld. Een opdrachtgever heeft een deelservice “cloud hosting” uitbesteed aan leverancier 1. Deze leverancier heeft de overeenkomst afgestemd op een optimale dienstverlening vanuit zijn eigen verdienmodel, waarbij volume en onderhoudskosten de belangrijkste drivers zijn.

Een tweede deelservice “applicatiebeheer” is uitbesteed aan leverancier 2. Deze leverancier heeft de overeenkomst geoptimaliseerd naar het aspect “urenbesteding”.

Er ontstaat een belangenconflict tussen beide leveranciers als er een issue ontstaat over de cloud-omstandigheden van leverancier 1, waarbij er een effect optreedt op de urenbesteding van leverancier 2. De opdrachtgever wordt daarvan dan de dupe.

Dramadriehoeken komen ook in andere situaties voor, niet alleen buiten maar ook binnen organisaties.

Leverancier en gebruikers

Er kan bijvoorbeeld een belangentegenstelling ontstaan tussen de klant/opdrachtgever en z’n eigen gebruikers. De rood gestippelde pijl duidt weer de relatie aan waar het mis gaat.,

Een voorbeeld: De klant besteedt een service uit op basis van kosten, en verklaart dat naar de gebruikers toe met de mededeling dat ze de dienstverlening nu ‘eindelijk’ eens goed gaan regelen.

De leverancier levert de service inderdaad tegen lagere kosten, om aan de overeenkomst te voldoen. Hij dient daarmee het belang van de klant, maar snijdt daarvoor wel in de overeengekomen functionaliteiten.

De gebruikers verliezen functionaliteiten waar ze nou juist belang bij hadden.

Functioneel beheer en IT-beheer

Belangentegenstellingen ontstaan ook tussen domeinen/taakgebieden binnen een organisatie. Een bekend voorbeeld uit de IT-wereld is de tegenstelling tussen functioneel beheer en IT-beheer.

Functioneel beheerders voelen zich vaak “onderdeel van de gebruikersorganisatie”, terwijl ze ook gewoon interne dienstverleners zijn, met een eigen bijdrage aan het facilitaire taakgebied ‘informatievoorziening’. Probeer hen daar echter maar eens op af te rekenen…

De IT-beheerders stellen zich veel meer op als dienstverleners, maar zijn veelal meer ‘op afstand’ gezet en deels geoutsourcet. Hoewel de functiescheiding die de grondslag voor dit onderscheid levert, op zich een waardevolle interventie is, levert de praktijk nogal eens problemen. Functioneel beheerders proberen zich regelmatig te bemoeien met de keuzes die binnen het domein IT-beheer vallen, en ze hebben nogal eens de neiging “om het zelf te doen”. Probeer maar eens alle functioneel beheerders de toegang tot de productieomgeving te ontzeggen… Omgekeerd, IT-beheerders die zélf de specificaties voor hun IT-voorzieningen opstellen veroorzaken vergelijkbare problemen.

Applicatiebeheer en systeembeheer

Hetzelfde geldt in de IT voor de dramadriehoek tussen applicatiebeheer en systeembeheer. Applicatiebeheer is gewoon een onderdeel van IT-beheer, net als de rest van het infrastructuurbeheer, maar mede door de opkomst van ASL en BiSL naast ITIL is toch vooral de tegenstelling tussen deze domeinen onderstreept.

Moderne technieken zoals agile en DevOps dragen weliswaar hier en daar bij aan een beter samenwerkingsverband, maar er is nog steeds sprake van een stevige kloof tussen deze domeinen.

Een oplossing o.b.v. universele bouwblokken: LEGO met USM

Dramadriehoeken zijn illustraties van eiland-denken. Elk van de betrokken partijen beschouwt de wereld vanuit een eigen belang en perspectief, en de aansturende partij is niet in staat de spelers voldoende bij elkaar te brengen.

De oplossing voor deze problematiek is te vinden bij de oorzaak: een combinatie van gebrekkige aansturing en geïsoleerde oplossingen. De USM-methode levert een eenvoudig leerbaar en effectief instrument om dit probleem aan te pakken. De opdrachtgever krijgt met de denk- en zienswijze van USM meer inzicht in, en grip op de dienstverlening, en kan de werkwijzen van de ‘spelers’ eenvoudig standaardiseren met de toepassing van USM.

Op die manier ontstaat het beeld van LEGO: een aantal bouwblokken om alle denkbare constructies op te zetten, maar wel op één gemeenschappelijke grondslag: de nokjes van het ene blokje passen altijd in de gaatjes van het andere blokje.

Dat LEGO-effect is mogelijk met de USM-servicemanagementarchitectuur: USM levert de bouwblokken voor het managementsysteem van elke serviceorganisatie. In de laatste figuur is dan ook – voor het maximale LEGO-effect – bij iedere ‘speler’ in het netwerk de USM-werkwijze als verbeterstrategie aangegeven.

Hoe meer spelers het spel met dezelfde spelregels spelen, hoe beter het resultaat van het spel.

Weg met CIO Office en PMO – leve het SMO…

Een Project Management Office (PMO) is een bekende organisatorische constructie voor het managen van projecten. De laatste jaren zijn echter ook Service Management Offices (SMO’s) in opkomst. Wat is het verschil? Wat is de overeenkomst? En kan de één wel naast de ander bestaan? En wat doet een CIO Office dan nog?

Het managen van dienstverlening vergt overzicht over die dienstverlening en toezicht op de manier waarop die diensten worden geleverd. Een Service Management Office (SMO) is een team dat zich met dat overzicht en toezicht bezig houdt en zorg draagt voor de optimale afstemming tussen de behoeften van de klant en de prestatie van de serviceorganisatie (‘business IT alignment’, BITA). Het SMO fungeert daarbij als een staf-orgaan of een Center of Excellence (zie de figuur boven deze blog).

Taken van een SMO

In het SMO staat governance centraal, maar het team houdt zich ook bezig met het managen van de dienstverlening. Een SMO kan een strategische focus hebben, maar ook de operationele contacten van bijvoorbeeld de Servicedesk omvatten. Het SMO treedt bij verregaande outsourcing op als regieorganisatie.

Het SMO brengt dus de verantwoordelijkheid voor de dienstverlening vanuit verschillende perspectieven en op verschillende niveaus bijeen. In die zin is het SMO de bindende factor voor het samenhangend managen van die dienstverlening, op strategisch, tactisch en operationeel niveau.

Daarmee is het SMO een kruispunt van governance en management.

Zo’n kruispunt bestaat al in de vorm van de hoogste in rang in de IT-serviceorganisatie: de IT-directeur of de CIO die in principe eindverantwoordelijk (accountable) is voor alle taken en prestaties van de serviceorganisatie. Met het SMO krijgt deze een apparaat ter beschikking dat handen en voeten geeft aan het besturen van de dienstverlening. Het SMO neemt daardoor een deel van die eindverantwoordelijkheid (accountability) over. Een RACI demonstreert dan in detail in hoeverre en waarvóór het SMO accountable is.

Ieder taakgebied in een organisatie kan een eigen SMO instellen. De combinatie van meerdere taakgebieden in één SMO is dan de volgende stap naar Enterprise Service Management.

De taken van het SMO omvatten daarmee potentieel een breed spectrum van activiteiten:

de servicemanagemenstrategie
de servicemanagementarchitectuur
het toezien op het opleiden van alle medewerkers t.a.v. hun kennis van de werkwijzen
het beheren van de functionaliteit van de workflowtool
het initiëren van verbeteringen in de dienstverlening en in het managementsysteem
tot aan een hele reeks meer operationele taken uit de koker van de servicemanager, de kwaliteitsmanager en de Servicedesk…

De mate waarin een SMO daadwerkelijk in ál deze taken voorziet varieert per organisatie. Een SMO kan dus ook best een beperkte taakstelling hebben, met slechts een deel van de opgesomde taken.

Voorbeeld. Het proces Contract Management (CTM) omvat het maken van de afspraken met klanten en toeleveranciers, en het onderhouden daarvan. Het belangrijkste profiel dat deze taken uitvoert is servicemanager. Dat profiel kan worden ‘opgedeeld’ in deelprofielen, die bijdragen aan de uitvoering van deze taken. Denk aan het profiel van inkoper. Een breed SMO omvat al deze profielen. In een wat smaller gedefinieerd SMO vallen de profielen van de inkopers onder een separaat team.

CIO Office

Een deel van de servicemanagementtaken is vaak al ondergebracht in een CIO Office, en dan vooral het strategische deel. Eén van de grootste problemen van deze CIO Offices is de afstand tot de werkvloer. Een CIO Office heeft nogal eens de neiging zich vooral met ‘belangrijke’ (strategische) zaken te bemoeien. Dat zijn dan vaak zaken die onder ‘programmamanagement’ of ‘portfoliomanagement’ vallen. Of nog fraaier: onder ‘de digitalisering van de business’ of een ander modeverschijnsel. Zo’n focus op het veranderen van de technologische voorzieningen gaat vaak ten koste van de kerntaak van de IT: het duurzaam ondersteunen van bedrijfstaken met behulp van een passende informatievoorziening.

Een organisatie die de taken van zo’n CIO Office onderbrengt in een SMO brengt daarmee de verbinding aan tussen de strategische en de tactisch/operationele taken van de dienstverlener. Het gevolg is dat die organisatie meer met beide voeten op de grond komt te staan, en daarmee beter aansluit bij de praktische behoeften van de business.

Bij zo’n combinatie hoort een waarschuwing: vanuit het oogpunt van functiescheiding is het van belang om bepaalde taken niet in één hand te leggen. Binnen een SMO moet worden gewaakt voor het vermengen van specificeren en realiseren (de essentie van functiescheiding). Die regel gold echter ook al voor alle andere situaties en organisatievormen, dus daarmee is er niets nieuws onder de zon.

Project Management Office (PMO)

Procesmatig werkende organisaties die een Project Management Office (PMO) hebben en een SMO willen inrichten, kunnen de taken van het PMO integreren in de nieuwe werkwijze en organisatiestructuur.

Projecten volgen immers processen (of liever gezegd workflows). Dat betekent dat het hanteren van een projectmatige werkwijze onderdeel is van de reguliere, procesmatige werkwijze. Projecten bestaan dus niet naast processen, maar zijn werkwijzen die het uitvoeren van activiteiten in processen mogelijk maken. Voor die situaties moet dan wel gelden dat de projectmatige uitvoering tot meerwaarde leidt, en tegelijkertijd geen afbreuk doet aan de afgesproken dienstverlening…

Voor het leeuwendeel van de activiteiten van een serviceorganisatie geldt dat ze niet projectmatig worden uitgevoerd.

Er is dus blijkbaar sprake van criteria, waarvoor geldt dat activiteiten die daaraan voldoen projectmatig worden uitgevoerd. Iedereen weet wel welke criteria dat zijn:

hoge kosten
veel complexiteit
er zijn veel organisatorische eenheden bij betrokken
etc.

Elke organisatie bepaalt voor zichzelf wáár ze de grens legt om te beslissen of een activiteit projectmatig wordt uitgevoerd. Projecten bestaan dus niet naast processen, maar zijn manieren om activiteiten in processen uit te voeren.

Alle projecten passen dus in het procesmatige besturingsmodel van de organisatie. Het SMO borgt dat de prestaties van de organisatie optimaal ten dienste staan van de afgesproken ondersteuning van de business. Projectmanagers maken dan deel uit van de bestaande teams. Een organisatie die veelvuldig gebruik maakt van projectmatige werkwijzen, kan dan eventueel de gekwalificeerde resources nog in één team in de lijnorganisaties onderbrengen.

De noodzaak van een PMO verdwijnt.

Een procesmatig werkende organisatie die een SMO inricht, heeft dus geen behoefte meer aan een PMO. Sterker nog: de focus op services reduceert het begrip project tot een nuttig instrument – om de dienstverlening mee te ondersteunen. Maar de klant en de dienstverlening staan dan wel centraal, en niet de verandering via projecten.

Deze aanpak is een standaard onderdeel van de methode USM – Universeel Service Management, die snel aan belangstelling wint en al onderdeel is van hbo- en mbo-opleidingen. Met die methode zijn nog veel meer van dit soort misverstanden op een eenvoudige en consistente manier te lossen. USM helpt procesmatig werkende organisaties aan gestandaardiseerde werkwijzen en een standaard servicemanagementsysteem.

Een uitgebreidere beschrijving van het inrichten van een SMO, met inbegrip van de traditionele PMO-functies, is onderdeel van de middelen die Stichting SURVUZ gratis aan USM-gebruikers beschikbaar stelt.

[aanvulling 2-9-2019: Ik kreeg zojuist een artikel onder ogen van een partij die het instellen van een BRMO – een Business Relationship Management Office – promoot, en daar een reeks prijzige trainingen voor aanbiedt. Het lijkt me logisch dat bovenstaande blog nog een kleine uitbreiding kan gebruiken…. En mochten er nog meer aanbieders van versplintering en complexiteit worden gevonden, dan zou ik zeggen: “gewoon toevoegen aan de strekking van de blog”]

Misverstanden rond de rol “Proceseigenaar”

Op GEMMA online is een artikel te vinden over dit thema. Dat artikel vraagt om een reactie: het illustreert de veelvuldige misinterpretaties van begrippen zoals proceseigenaar, procesmanager en procescoördinator.

Het onderwerp van het genoemde artikel is proceseigenaarschap. De uitwerking daarvan demonstreert twee opvallende, gangbare invalshoeken:

Het artikel gaat helemaal niet over processen maar over practices: de praktische handelingen die een gemeentelijke organisatie voor bepaalde doelen op een bepaalde manier uitvoert. De verantwoordelijkheid voor de aansturing van die activiteiten (in de vorm van een gemeentelijk ‘proces’) is onderwerp van de analyse.
De aansturing van die handelingen valt volgens de auteur onder proces-eigenaarschap, terwijl het gaat over het aansturen van de uitvoering. De auteur heeft het dus in feite over procescoördinatie: de (procesmatige) aansturing van de uitvoering van de activiteiten die – in dit geval – in de practice beschreven zijn.

Het artikel demonstreert daarmee een gangbare misinterpretatie van het begrip proces in combinatie met het begrip management. De conflicten die de auteur in het artikel aan de orde stelt zijn de gangbare gevolgen daarvan: wie is nou de baas, de proceseigenaar of de lijnmanager? En is er wel verschil tussen die twee rollen? En wie escaleert er nou naar wie?

Spraakverwarring

De spraakverwarring over de gehanteerde begrippen is gelukkig eenvoudig te repareren als je een eenduidige definitie hanteert. Neem de volgende zaken maar eens in overweging:

Eigenaarschap duidt eerder op accountability dan op responsibility. Eigenaarschap heeft dus niet per definitie iets te maken met de hiërarchische aansturing (het coördineren), ook al heet een (proces)eigenaar in de praktijk vaak wel (proces)manager. Je mág de verantwoordelijkheid voor eigenaarschap en coördinatie wel in één persoon combineren, maar het verdient de voorkeur (vanwege de voordelen van functiescheiding) om dat juist niet te doen.
Coördinatie kan langs twee wegen plaatsvinden: langs de logica van de organisatorische hiërarchie of langs de logica van de samenhang van activiteiten (fundamentele processen, of daarvan afgeleide practices).

Een conflict in de zin van hiërarchische aansturing vindt altijd plaats tussen coördinatoren. En daar kun je onderscheid maken tussen teamcoördinatoren en procescoördinatoren. Die twee staan echter geheel los van de rol van proceseigenaar. Het is zelfs uiterst onverstandig om één van die rollen te combineren met de rol van proceseigenaar. De waan van de dag wint het dan namelijk altijd.

De meeste “procesmanagers” zijn vooral (en vaak alléén) managers van de uitvoering. Denk maar aan de gangbare “changemanager”, de “incidentmanager”, de “problemmanager”: zij coördineren de afhandeling van changes, incidenten, problems…

Wie is dan de baas?

De vraag wie ‘de baas’ is, is nu teruggebracht tot de vraag: welke coördinator heeft de meeste aansturende bevoegdheden over het werk van uitvoerders?

Elke organisatie kan daarin z’n eigen keus maken, afhankelijk van de mate waarin die organisatie met het begrip ‘proces’ om kan gaan. Veruit de meeste organisaties kunnen dat nog niet, en kiezen dus voor lijnmanagement bóven procescoördinatie.

En de proceseigenaar dan?

En als de procescoördinator en de teamcoördinator uitmaken wie de baas is, wat doet een proceseigenaar dan nog? Dat is eenvoudig: die rol zorgt voor de kwaliteit van het ‘proces’. Dat houdt concreet de volgende zaken in:

De proceseigenaar stimuleert de awareness in de organisatie t.a.v. de betekenis van het proces.
De proceseigenaar maakt afspraken met (coördinatoren van) uitvoerders over de te volgen werkwijzen.
De proceseigenaar ziet toe op het naleven van die afspraken.
De proceseigenaar rapporteert over de prestaties van het proces.
De proceseigenaar stelt verbetervoorstellen op en ziet toe op de uitvoering daarvan.
De proceseigenaar zorgt voor de ondersteuning van de medewerkers die het proces uitvoeren (tooling, opleiding, etc.).
De proceseigenaar legt verantwoording op stafniveau, over de bijdragen van het proces aan de prestaties van de organisatie.

Daar heeft zo’n proceseigenaar de handen wel vol aan. En als die functionaris dat gemakkelijk aan kan, dan is er vast nog wel een tweede proces dat ook nog ‘gemanaged’ moet worden… (en dan bedoel ik dus niet ‘gecoördineerd’).

Hiermee is een heel andere rol voor proceseigenaar gedefinieerd, dan de aansturende lijnmanagement-rol die in het genoemde artikel aan de orde kwam. Bovendien geeft deze definitie concrete inhoud aan de niet te onderschatten betekenis van proceseigenaarschap, terwijl meteen de voordelen van functiescheiding worden verzilverd.

Iedere organisatie moet dus kiezen

Een organisatie die procesmatig wil werken moet dus een paar dingen regelen:

Stel voor ieder proces een proceseigenaar aan die zich niet bemoeit met de hiërarchische aansturing van de uitvoering, maar juist met de functionele ondersteuning van die uitvoering. Noem dat desgewenst een ‘faciliterende manager’ of een ‘procesmanager’, maar maak duidelijk dat die persoon alleen de specificatie van het proces managet en niet de uitvoering daarvan coördineert.
Bepaal de machtsverhouding tussen de managers die de uitvoering van dat proces coördineren. Maak daarbij onderscheid tussen teamcoördinatoren en procescoördinatoren. Bepaal vervolgens wie van beide ‘de macht heeft’, oftewel: naar wie de operator moet luisteren als beide coördinatoren (‘managers’) het niet met elkaar eens zijn over de prioritering van werkzaamheden. Daarmee zijn meteen de escalatiepatronen bepaald.

Iedere organisatie die op de één of andere manier gebruik wil maken van de voordelen van procesmatig werken zal de keus over die machtsverhouding moeten maken. Er is daarbij sprake van een kantelpunt (zie figuur). Van oudsher beginnen organisaties ergens in het rechter segment, als een hiërarchische organisatie. Organisaties die de voordelen van procesmatig werken willen benutten schuiven stapje voor stapje op naar het linker segment.

Deze aanpak is een standaard onderdeel van de methode USM – Universeel Service Management, die snel aan belangstelling wint en al onderdeel is van moderne hbo- en mbo-opleidingen. Met die methode zijn nog veel meer van dit soort misverstanden op een eenvoudige en consistente manier te lossen. Had de auteur van het genoemde artikel de kans gehad om zich daar eerst in te verdiepen, dan had dat artikel er ongetwijfeld heel anders uitgezien. De auteur had zich dan niet hoeven te beperken tot het beschrijven van problemen, maar hij had een eenvoudige oplossing kunnen aanreiken…

Arsenaal van de falende manager

Als er íets tot ons nationaal erfgoed behoort, dan is het wel reorganiseren. Een prachtige bliksemafleider, die tot het standaardarsenaal van de ervaren manager behoort. Vooral van de interimmer, die er een ware kunst van heeft gemaakt. Als je de volgende reorganisatie afkondigt, ben je geheid een jaar uit de wind. Iedereen is druk bezig z’n huid te redden in de nieuwe organisatie, en je hebt een prachtige bliksemafleider om je eigen falen als management te maskeren. Maar de falende manager heeft nog een paar ‘gouden grepen’ ter beschikking.

Je geeft de schuld aan je voorganger. Da’s makkelijk scoren en het leidt de aandacht af. Puinruimen! Wat een zooitje heeft de voorganger ervan gemaakt… Tjonge! Het roer moet om! Met vereende krachten gaan we een nieuwe koers inzetten! De woorden verschillen niet van wat de vorige manager riep, alleen de koers is deze keer anders. Vooral interim-managers kunnen op die manier jarenlang bouwen aan het ontwikkelen van een indrukwekkend cv: directeur dit, directeur dat, en allemaal na een jaartje of iets langer weer ingewisseld voor een nieuwe uitdaging. Met zo’n cv moet het wel een goeie manager zijn… De volgende opdracht in het vriendennetwerk ligt dus steeds voor het oprapen.

De envelop met deze strategie komt meestal als eerste in beeld, gevolgd door de envelop met ‘reorganiseer’. Ook de derde envelop is een leuke.

Je roept: “Het ligt aan de tool!”. Alweer een jaar uit de wind. De (management)tool van de it-beheerorganisatie is altijd onderwerp van discussie. Slechts zelden kom ik bij een organisatie waar men helemaal blij is met de tool. Dat ligt dan vaak niet aan de kwaliteiten van de tool – die zijn op hoofdlijnen vaak wel hetzelfde als de vorige en de volgende. Het gaat vooral om de manier waarop de tool wordt gebruikt. Als je geen architectuur in je proces- en organisatiedomein hebt aangebracht, hoe wil je dan van een tool verwachten dat die effectief en efficiënt je werkzaamheden ondersteunt?

Ik houd een lijst van ‘ITIL’-tools bij op list.ly, en daar staan momenteel 415 tools in. Als ik de lokale, landelijke tools en mijn lijst van gratis tools zou meerekenen, kom ik gemakkelijk op een paar honderd extra. Gartner gebruikt die lijst zelfs voor haar magisch kwadrant. Voor een manager is dat een snoepwinkel: er is altijd wel een ‘veel betere’ tool waarmee je een jaar uitstel kunt kopen.

De drie enveloppen met bovenstaande strategieën kun je nog uitbreiden met een vierde. Dat pakketje geef je als vertrekkende manager dan aan je opvolger, met de mededeling dat hij de vierde envelop pas mag openen als de eerste drie gefaald hebben.

Wat er in de vierde envelop staat?

“Schrijf vier enveloppen voor je opvolger en maak dat je wegkomt.”

Deze column verscheen ook in ICT/Magazine.

Het vluchtsyndroom van de it’er

In tijden waarin complete volkeren op de vlucht zijn voor oorlog en geweld, valt me steeds weer op dat ook it’ers veelvuldig op de vlucht zijn. Maar waar ik bij Syrische en Noord-Afrikaanse vluchtelingen goed kan begrijpen wat hen drijft, is mij dat bij it’ers vaak een raadsel.

Toen ik onlangs een LinkedIN-blog schreef over SIAM (‘SIAM is a hoax’), viel bijna de hele gevestigde orde van ITIL-experts over me heen en moest ik onderduiken om niet gelyncht te worden.

De onderbouwing voor het gebruik van de term ‘hoax’ was eenvoudig: als je willens en wetens doorbouwt op iets wat zogenaamd solide is, maar dat niet is, dan misleid je je publiek. De auteurs van het eerste SIAM-boek schreven net zo expliciet als de criticasters van mijn blog dat ze doorbouwden op ITIL – waarvan ze tegelijkertijd zeiden dat je dat niet kunt implementeren. Er was een nieuwe blikvanger gecreëerd, waarin veel energie moest worden gestopt, en waarmee we veel oude problemen zouden oplossen. De eerste SIAM-consultants waren al geboren, de eerste seminars waren gepland, en een nieuw businessmodel lonkte voor de experts. Mijn stelling dat je niet kunt bouwen op de brokstukken van je vorige niet-werkende oplossing, paste niet in dat plaatje.

Je kunt om twee redenen lijden aan dit vluchtsyndroom:

Je hebt 30 jaar niet opgelet en weet dus niet beter.
Je weet het wel, maar je sluit je ogen ervoor.

Optie 1 is een typisch geval van ‘jammer’. Bij optie 2 weet je verdraaid goed dat je niet op beton bouwt, maar op drijfzand: in mijn ogen verwijtbaar gedrag. Daar sprak ik de auteurs op aan. En dat heb ik geweten… Binnen een week had ik 2000 lezers en spatten de vonken van LinkedIn en Facebook. Blijkbaar had ik een zenuw geraakt.

De hoax-blog stelde een merkwaardig fenomeen in de it-markt aan de orde: it’ers blijven ‘naar voren vluchten’, naar ‘nieuwe oplossingen’, zonder de vorige oplossing te hebben geborgd in een duurzaam beheerbare omgeving. Nog steeds maken we ons druk over het gebrek aan ‘alignment’ tussen IT en ‘de business’. Nog steeds zie ik zelden een SLA of een servicerapportage die in businesstermen is uitgedrukt – als je ze al tegenkomt. En opdrachtgevers zijn net zo besmet met het syndroom. Zodra er een nieuwe techniek aangeboden wordt, willen ze het hebben ook.

Er is weinig veranderd sinds ik begin jaren negentig zag dat een verplaatsing van ontwikkeling naar beheer werd beleefd als degradatie. Geen sexy vernieuwingsprojecten meer, maar ‘op de winkel passen’. Jakkie! Zal er ooit een kuur voor dat syndroom gevonden worden?

Deze column verscheen ook in ICT/Magazine