Door onkunde, gebrek aan een lange termijn visie en een ambivalente houding jegens automatisering, staat management een optimale inzet van it in de weg. Dit wordt niet erkend; een stuk eigenaarschap en verantwoordelijkheid wordt afgeschoven op de it-organisatie of op een leverancier. Wanneer wordt it nu eindelijk eens beschouwd als een onderdeel van de core business in plaats van een lastige kostenpost.
In elk denkbare bedrijfstak kan de vervaardiging van goederen of diensten niet zonder een solide parallelle informatievoorziening. Dit is nogal een open deur. Echter nog steeds wordt er een kunstmatig, geforceerd, onjuist en hierarchisch onderscheid gemaakt tussen de core-business (‘waar het geld verdiend wordt’) en de it-infrastructuur (‘..die alleen maar geld kost’). Terwijl informatie en het strategisch inzetten daarvan een essentieel onderdeel vormt van de core-business.
Korte termijn visie
Op alle terreinen in de samenleving wordt de scope van beleid korter. Bonuscultuur, aandeelhoudersvalue en de voorkeur aan zichtbare resultaten zijn hiervan de oorzaak. De organisatie is daarom voortdurend onderhevig aan ingrijpende beslissingen; fusies, afstoten van bedrijsonderdelen, outsourcing, off-shoring, et cetera… Voor een it-infrastructuur betekent dit een voortdurende aanpassing van het basisontwerp en een voortdurende stroom van verstorende wijzigingen en projecten.
Een infrastructuur, de kennis ervan en de processen er omheen kennen echter een andere, veel tragere dynamiek. Er is sprake van een natuurlijke inertie. Een solide it-infrastructuur heeft misschien wel vijf tot zeven jaar jaar nodig om goed en doordacht ontworpen te worden, te worden gebouwd en geïmplementeerd, te integreren in de organisatie, om de kennis ervan te borgen en, niet op de laatste plaats, om ervan te genieten en ervan te profiteren gedurende de periode na voltooiing. Waarom wordt een fabriekshal wel gebouwd met een scope van tien jaar en een it-infrastructuur niet?
Het adagium van de steeds sneller veranderende samenleving en de behoefte van ultieme flexibiliteit is naar mijn mening doorgeschoten. De balans is zoek tussen stabiliteit en betrouwbaarheid enerzijds en flexibiliteit en aanpasbaarheid anderzijds.
Het gevolg is dat de it-infrastructuur een onsamenhangende lappendeken wordt. Oude, nog niet eens voltooide omgevingen blijven voortbestaan in een sub-optimale status. Nieuwe segmenten worden gebouwd en om het oude toch met het nieuwe te verbinden worden ’tijdelijke’ specials bedacht. Oude apparatuur wordt niet weggehaald: ‘het werkt toch?’; ‘we weten eigenlijk niet wat we onderuit halen..’; ‘geen tijd voor Life Cycle Mgt.; doen we wel als het wat rustiger is..’. Delen van de infrastructuur worden uitbesteed aan verschillende externe partijen en mensen worden herplaatst naar ander plekken in de organisatie, de externe partijen nemen mensen over, of mensen worden ontslagen.
Actuele kennis en kennis over historie van het it-landschap, wordt zo verspreid of verdwijnt zelfs. Niemand heeft meer inzicht en overzicht en niemand voelt zich meer eigenaar en verantwoordelijk voor de uiteindelijke it-dienstverlening. Nieuwe implementaties van projecten en ketens kosten onnodig veel tijd omdat informatie bij vele verschillende afdelingen moet worden gehaald. Wijzigingen worden zeer riskant en hebben veel tijd nodig om te worden beoordeeld door diverse Change Advisory Board’s omdat niemand echt kan overzien welke diensten er allemaal geraakt worden. Storingen duren onnodig lang om te worden opgelost omdat op allerlei plekken in de organisatie maar ook daarbuiten er dingen moeten worden onderzocht en op knoppen moet worden gedrukt.
Nadat enkele specialisten van de oude garde er na ettelijke nachtelijke uren in slagen om de storing op te lossen, begint op de middle management laag het ‘zwarte pieten spel’ en worden de techneuten lastig gevallen met vragen van ‘de planning’ waarom ze afgelopen maand zoveel overuren hebben geschreven op een projectcode. Dit moet anders; we gaan de processen verbeteren..Er komen service-managers en proces-coördinatoren bij. Nog meer Chiefs en de laatste Indians (techneuten) raken zwaar gefrustreerd…
Werkvloer als sluitpost
De eersten in de rij maken het grootste deel van de koek op…Een voorbeeld uit de praktijk. Er moeten datacenters worden uitgefaseerd. Alles moet worden gemigreerd naar andere, bestaande datacenters. Hiervoor moet een infrastructuur ontworpen worden die als tussenstap fungeert om de applicaties om te vormen om ze te kunnen laten landen in hun nieuwe omgeving. Het loopt tegen het einde van een boekjaar en nog voordat er ook maar een schets is, wordt er al een partij hardware besteld om nog gebruik te kunnen maken van het budget in dit lopende jaar.
In de eerste maanden van het nieuwe jaar wordt er op allerlei niveaus vergaderd en overlegd tussen architecten, de businessmanagers van de vragende partij en de projectleiders van de leverende partij. Na vier maanden is er een zeer globaal document, in de vorm van een high level design (hld). Ondertussen is de planning niet aangepast en zijn de oorspronkelijke deadlines gewoon blijven staan. De technisch specialisten die de infrastructuur moeten gaan bouwen krijgen enerzijds een draft versie van het hld en anderzijds een setje pakbonnen met het verzoek om uit te zoeken wat er voor hardware is geleverd en waar het eigenlijk staat. Er is al veel tijd verstreken en de druk om concrete resultaten te kunnen laten zien wordt alsmaar groter.
Naar alle eer en geweten puzzelen de techneuten een detailontwerp bij elkaar met behulp van het summiere hld en de beschikbare ‘lego-blokjes’ aan hardware. Maanden zijn er opgegaan aan politiek getouwtrek en discussies over architecturele keuzes; het echte bouwen en realiseren is een sluitpost geworden in de tijdsplanning. Om nog maar te zwijgen over kennisborging in de vorm van documentatie en overdracht, dat al helemaal in de verdrukking komt op het einde van een project.
Wel de lusten niet de lasten
Als er één gebied is waarin management een, op zijn zachtst gezegd, ambivalente houding laat zien is dat wel (it-)security. Natuurlijk wordt er wel geïnvesteerd in technologie en processen. Er moet immers voldaan worden aan diverse normen (ISO,pciI, et cetera) om sowieso ‘in business’ te blijven. Ook is men huiverig voor (externe) audits en is men gevoelig voor eventuele imagoschade als een security incident breed in de publieke belangstelling komt te staan. Maar ik betwijfel of men intrinsiek is begaan met it-security; ‘Om te kunnen voldoen aan de norm moeten we het minimale doen, rijden we een partij firewalls en ids/ips-systemen binnen en gaan we iets doen met toegangscontrole en authorisatie en authenticatie. Maar eigenlijk hebben we er alleen maar last van. Security doet vaak moeilijk en het kost weken om een firewall poort geopend te krijgen. Onze klant wil connecteren op een bepaalde poort dus ze moeten gewoon die firewall openzetten..Het duurt veel te lang zo..’.
Dus, na een intern escalatie traject staat er aan het bureau van de argeloze firewall beheerder een ‘stropdas’ die een verkeersstroom er doorheen duwt. Dat daarmee de veiligheidsstandaarden worden geschonden is op dat moment even niet belangrijk. En als het dan mis gaat, bij een incident of na een audit, wordt er van hogerhand gezegd: ‘Dat moeten ‘we’ (lees: jullie techneuten) beter doen in het vervolg..’.
Hoe kan de kloof tussen ‘business’ en it worden overbrugd. Ik heb daar eigenlijk geen pasklaar antwoord op. Wel denk ik dat het moet beginnen bij besef en inzicht bij de beslissers, dat it veel meer is dan de simplificatie van ‘water uit de kraan’ en dat het veel dichter tegen ‘de business’ aan staat dan wordt gedacht. Een optimale inzet van it is toch vaak maatwerk en is niet zonder ingrijpende gevolgen inwisselbaar of uitbesteedbaar. Daarbij moet een it-infrastructuur de kans krijgen om zich over een langere periode uit te kunnen kristalliseren. Hierdoor is het rendement van investering hoog en houdt je als bedrijf goede technisch specialisten binnenshuis en daarmee hun kennis en ervaring van en met het it-landschap.
@verzyden
Blijkbaar is de kern van mijn boodschap niet geheel op jou overgekomen;
De kern is dat ‘de business’ niet het eigenaarschap neemt van de consequenties van hun eigen beslissingen.
Natuurlijk is het doel niet een mooi netwerk of infra maar een goede en optimale ondersteuning van ‘de business’.
Zodra management beseft dat een majeure organisatie verandering verregaande consquenties heeft op het IT-landschap en die extra kosten herkent en erkent, dan zijn we al een stuk verder
Ha, Bart, ik denk dat ik (na 25 jaar IT) precies weet waar het over gaat en maak dit, als informatiemanager, dagelijks mee. Als je met je management hetzelfde doet als met mij, hierboven, dan gaat het ook zeker niet lukken. Het is mijn ervaring dat luisteren naar elkaars problemen, zoeken naar gezamenlijke knelpunten en echt begrip voor de situatie van de andere kant absolute voorwaarden zijn voor een goed gesprek. Dat vraagt iets van hen, maar je moet je realiseren dat het heersende beeld over IT (arrogant, betweters, bureaucratisch en complex) niet meehelpt. Daar moet je dus iets op verzinnen, je moet ze overtuigen en mee krijgen; hoe maak je het gesprek aantrekkelijk en gewenst, met zicht op een oplossing waar zij iets aan hebben. Dat gaat eerst over motieven achter beslissingen en het weerleggen van heersende opinies, pas daarna over IT oplossingen. Buitengewoon lastig omdat je ook jezelf voortdurend kritisch moet afvragen of je begrijpelijk overkomt. Maar dat is wel waar het volgens mij om gaat…
@verzyden
Bedankt in ieder geval voor jouw (positieve) invulling op mijn vraag hoe we de kloof tussen management en IT kunnen overbruggen. Het begint inderdaad met luisteren naar elkaar; zeer met je eens.
Het moeilijke is wel dat daarvoor een enigszins gelijkwaardige relatie nodig is. Terwijl de IT organisatie toch vaak als nevendienst wordt gezien (‘betaald door de business’) en dat ik de indruk heb dat cio’s nog niet de volle invloed hebben op het hoogste niveau.
Bart,
opnieuw valt het mij op dat je opiniestukken een hoog Rijnlands gehalte hebben; om die reden spreekt ook dit betoog mij weer zeer aan. Je pleidooi voor kennis(borging), inzicht en overzicht en het behoud van kennis en ervaring van loyale en betrokken mensen kan ik alleen maar onderschrijven.
Toch vraag ik mij af of je hier niet met de juiste munitie op het verkeerde doel aan het schieten bent.
In de eerste plaats, verwijzend naar de klassieker van PaVaKe: kun je in z’n algemeenheid van “HET” management spreken (ofwel: bestaat “DE” manager wel)?
In de tweede plaats: als je zelf stelt geen pasklaar antwoord te hebben op de vraag hoe de kloof tussen business en IT kan worden overbrugd, hoe is dan van managers te verwachten dat zij hierin wel steeds de juiste beslissingen nemen? Is een bijkomend probleem niet dat managers zich laten informeren door architecten die ook al niet het juiste antwoord op deze vraag hebben (wat een crisis in Enterprise Architectuur genoemd mag worden)?
Het wil maar niet tot (veel!) managers en (veel!) architecten doordringen dat we in de onwikkeling van bedrijfstechnologie allang aanlopen tegen “the End of Control as we know it”; managers en architecten blijven elkaar vinden in hun gemeenschappelijke fascinatie voor een wetenschappelijk, Anglo-Amerikaans geinspireerd, denken in modellen, feiten, regels en processen.
De Duitse filosoof Martin Heidegger (1889 – 1976), overigens DE filosoof van de twintigste eeuw, heeft onderscheid gemaakt tussen een rechnend Denken en een besinnliches Nachdenken.
Dit onderscheid zien we, mijns inziens, precies terug in de tegenstelling tussen Anglo-Amerikaans en Rijnlands denken.
Je stelling “Management maakt IT kapot” moet mijns inziens dus aangescherpt worden tot
“Anglo-Amerikaans denken maakt IT kapot”.
Maar lees voor “Anglo-Amerikaans denken” gerust wetenschappelijk denken, technisch denken, formeel denken, voorstellend denken, logisch denken, exact denken, macht, status, controle, etc, etc. Zoals “Rijnlands denken” – in mijn optiek – ook kan worden omschreven met aanduidingen als: filosofisch denken, zijnsdenken, architecturaal denken, eigenlijk denken, oorspronkelijk denken, meditatief denken, innovatief denken, Europees denken, etc, etc..
En eigenlijk moet “denken” binnen het Anglo-Amerikaans paradigma tussen aanhalingstekens, want Heidegger heeft zeer terecht gesteld: “Die Wissenschaft denkt nicht”.
Dus: IT maakt zichzelf kapot, doordat zij, gevangen in het Anglo-Amerikaans paradigma, niet in staat is adequate, op SOA gebaseerde, 5GL programmeertalen te ontwikkelen, die specifiek voor de business zijn bedoeld. Waar 3GL- en 4GL-omgevingen nog inzetten op een zo optimaal mogelijke samenwerking tussen ICT en Business (via agile/scrum of waterval), zal in een 5GL SOA/Cloud-omgeving de rol van ICT worden beperkt tot het leveren van componenten/services, die aan businesszijde zullen worden geassembleerd tot door de (interne en externe) klant gewenste functionaliteit.
De huidige softwarecrisis is met wetenschappelijke middelen niet op te lossen; hier is een filosofisch denken noodzakelijk. En dat durf ik gerust te zeggen tegen een auteur die één van zijn opiniestukken eindigde met: “geef weer ruimte aan dagdromen, denken, filosoferen en mijmeren..”.
@Jack
Filosofen en modellen zijn prachtig maar ook weer vaak selectief shoppen en ik denk dat daar ook nog wel wat over te zeggen valt. De vraag waar ik nu dus mee zit is of het systeem nu de manager maakt of de manager het systeem?
Een heel goed artikel. De kop is natuurlijk opgeklopt, doch helaas wel heel herkenbaar. De meeste projecten verlopen behoorlijk tot gewoon heel goed. Er kan een kink in de kabel komen, maar meestal werkt een goed gesprek over het zoeken naar oplossingen (in plaats van naar schuldigen).
Een enkele gaat het goed mis en daarbij is meestal het niet de techniek maar het management die faalt en vooral het business management. Dat blijkt uit diverse onderzoeken.
Het business management faalt zelden doordat deze niet voldoende capabel is. Het spreekwoordelijke domme niet gemotiveerde zoontje van de baas dat de leiding krijgt, dat komt zelden voor. Meestal is de boosdoener gewoon een machtswellustige saboterende manager. Die gebruikt ICT-gerelateerde projecten als hefboom om andere managers willens en wetens tegen te werken. Het ICT-project en dus de ICT-ers worden dan de zondebok en de saboterende manager wast zijn handen in onschuld.
Uit onderzoek is gebleken dat ongeveer de helft van de managers asociale trekken heeft of zelfs ronduit een sociopaat is. De laatsten manipuleren, demotiveren, saboteren graag en zijn daarin ook erg bedreven. Bedrijfsbelangen, formele posities en rationaliteit, zijn bij hen ondergeschikt aan hun persoonlijke wensen en vooral gevoelens. Lees bijvoorbeeld het boek “Hoe word ik een rat” van Joep Schrijvers. Zijn stelling om zelf een politieke rat te worden onderschrijf ik weliswaar niet, maar het kan wel zinvol zijn om mensen zo nodig een koekje van eigen deeg te geven. Nog beter zijn de tips van “Hoe vang ik een rat? – de kunst van het konkelen en samenzweren” van Richard Engelfriet en Peter van der Geer.
De hele foute managers moet je als “ratten” bestrijden (sorry rattenliefhebbers). Daarbij zul je extra bagage moeten bezitten. Je moet een ervaren projectmanager zijn met veel soft skills en hoog EQ. Je moet voorkomen dat jouw ICT-projectgroep of ICT-afdeling slachtoffer wordt van een “ratten”. Geef “ratten” het respect dat ze verdienen, oftewel marginaliseer ze. En laat ze verder over aan de organisatie. Het is niet jouw taak als ICT-er om dit organisatieprobleem op te lossen
“Ratten” zijn vaak te herkennen omdat ze hun genoegen tonen bij het commanderen van werknemers; boos worden over onbelangrijke details; medewerkers plotseling openlijk bekritiseren; zichzelf rustig tegenspreken; arrogant overkomen; complimenten geven aan iedereen behalve die zij piepelen; van je willen winnen, desnoods door je in de rug aan te vallen; een kort lontje hebben; steeds vaker expres te laat komen. Ze hebben ook vaak alcohol en andere verslavingsproblemen en allerlei gedragsproblemen.
Je moet het karakter, de tactieken en de belangen van “ratten” kunnen analyseren om sabotageacties te kunnen pareren. Je moet kunnen doorzien dat “ratten” je elke dag een beetje verder van het afgesproken doel proberen te brengen.
Gebruik countertechnieken. Heb je bijvoorbeeld te maken met een zeer luide bazige manager, vraag degene waarom hij zo schreeuwt en gebruik dan de stilte waar sleutelfiguren bij zijn.
“Ratten” kunnen abnormaal vertrouwenwekkend lijken en je vragen om geen afspraken vast te leggen vanwege de onderlinge vertrouwensband. Dat leidt uiteindelijk tot CYA van de manipulator. Dus leg rustig vast wat nodig is.
En wil de “rat” het systeem nog vandaag geleverd hebben en pas morgen vertellen wat het systeem moet kunnen en het volgend jaar pas testen; vraag dan met een glimlach of deze de acceptatie van het systeem wil ondertekenen met een antidatering voor gisteren. Kinderlijk, ja, maar ook effectief.
Soms moet je een opdracht accepteren terwijl je de vertegenwoordiger van de organisatie niet kan vertrouwen. Dan moet je het ICT-deel van het project zoveel mogelijk isoleren van de organisatiepolitiek. Zorg er voor dat je de ICT-collega’s afschermt van de “ratten”. Zorg er ook voor dat interne en externe ICT-ers niet tegen elkaar uitgespeeld worden. ICT-ers moeten zich kunnen richten op wat ze zo graag doen en wat ze zo goed kunnen. Maak bijvoorbeeld alleen het business deel van de risicoanalyse, de business eisen van het systeem, et cetera openbaar. De “ratten”moeten wegblijven bij de interne ICT-processen.
In het ergste geval wordt het dan ICT-operatie geslaagd, organisatiepatiënt overleden. De ICT-ers krijgen hun beloning, de “ratten”niet.
Ten slotte, doe alles wat het succes van het geheel kan opleveren. Succes heeft vele vaders, ook “ratten”. Maar alleen mensen die aan het succes hebben gewerkt, worden er ook blij van; dus “ratten” niet.
By the way, als je het boek “Hoe word ik een rat” nauwelijks of niet begrijpt, dan is er niks mis met je. Er zijn allerlei kwaliteiten. Je bent alleen niet geschikt om als projectmanager tussen “ratten” te werken.
@JohanVanVoren. Wat een verhaal schrijf je daar. Als ik het goed begrijp gaat maar een enkel project mis en dat komt dan door de rat: die manager waarin alles samenkomt. Een alcoholistische bazige sociopaat slechts uit op het eigenbelang. Is dit niet een wat kort door de bocht redenatie? Ik denk dat het niet een enkel project is wat mis gaat. Projecten lopen zelden soepel. Er is een veelheid aan redenen is te bedenken waarom projecten mislopen. Wel wil ik geloven dat iedere organisatie een rat heeft. De naarling zeg maar. Net als de schophond: de kluns die alles fout doet. Ook de clown man niet ontbreken. Om de stemming erin te houden. Zo zijn er vele rollen te bedenken maar om het moeizaam lopen aan 1 persoon (type) op te hangen daar geloof ik niets van.
Management maakt IT kapot. Dat is ook weer zo een boude bewering. Het lijkt me wel handig dat voor het nemen van IT gerelateerde beslissingen de beslissers de meningen van de IT-ers serieus neemt, van die groep mag je een inhoudelijk oordeel verwachten. Als het om de inhoud gaat natuurlijk.
@Ewout,
Hoewel systeemdenken misschien niet helemaal tot het Anglo-Amerikaans paradigma gerekend kan worden – het is eerder synthetisch/holistisch dan analytisch/reductionistisch – kan het, mijns inziens, wel helemaal tot het wetenschappelijk/technisch denken worden gerekend. Zodoende levert het geen kennis van de mens op, zodat je vraagstelling al onjuist is. Binnen systemen is geen ruimte voor menselijke vrijheid.
Voor zover organisaties nog gedomineerd worden door triple C (Command => Communication => Control => Information) kun je wel stellen dat managers het systeem maken.
Een organisatie kan niet meer als systeem/machine worden opgevat zodra wordt overgeschakeld op triple V: Vakmanschap => Verbinding => Vertrouwen => Inspiratie/Passie; of op triple R: Richting geven, Ruimte bieden en Resultaat vragen (naast Rust, Reinheid en Regelmaat).
Overigens, zelfs binnen de ICT spreken we tegenwoordig niet meer van systemen, maar van applicaties.
Wat betreft het zijnsdenken is slechts één filosoof relevant, dus van selectief shoppen is geen sprake 🙂
@Louis Kossen, projecten lopen zelden soepel. Dat is namelijk de aard van echte projecten. Want het gaat niet om de reguliere koop van een Off-the-shelf product, maar om een uniek geheel van activiteiten, mensen en soms ook technieken buiten de gewone bedrijfsvoering om. Er zijn dus nieuwe risico’s en hindernissen. Situaties en inzichten kunnen veranderen en dus ook de eisen en planningen. Problemen zijn vaak talrijk en kunnen bij alle partijen in elke projectfase voorkomen. Maar die worden meestal door de actoren opgelost of omzeild, uit aller belang.
Maar soms zoekt men de confrontatie. Lees bijvoorbeeld het artikel “Provincie Groningen staakt zaaksysteem Circle“ van computable.nl d.d. 07-10-2013. Het betrokken zaaksysteem Verseon, wordt in diverse varianten al jaren door zo’n 150 grote klanten van Circle Software gebruikt. Volgens Groningen zou Verseon onvoldoende gebruiksvriendelijk zijn; zou het niet efficiënt zijn; zou het niet veilig genoeg zijn. Circle zou ook geen goede planning kunnen geven om hun problemen op te lossen. En ja, dat ontdekken ze pas nadat er een jaar aan de implementatie van Verseon gewerkt is plus een jaar van vooronderzoek met bezoeken aan referentie sites en een Europese aanbesteding met nota bene een uitgebreide Proof-of-Concept.
Het grootste probleem hier was de georganiseerde tegenwerking binnen de provincie Groningen. De provincie zegt zelf: ‘De invoering van zaakgericht werken blijkt een langdurig en ingrijpend proces te zijn, de overgang naar het nieuwe zaaksysteem bleek een te grote stap in dit proces.’ Ze willen daarom ‘een nieuwe opzet bedenken voor het alsnog invoeren van zaakgericht werken’.
Na het staken van het project geven de “ratten” de schuld aan de ICT / Circle Software. En dan kom je weer uit bij het onderwerp van dit artikel.
Louis, er zijn allerlei soorten “ratten” en niet per se alcoholistisch. Verder spelen “ratten” zeker geen rol binnen een team volgens het model van Raymond Belbin, waar je op een wat vreemde wijze naar refereert. Elke teamrol moet namelijk meerwaarde hebben en dat bieden “ratten” niet.
@Jack
Ik denk dat ik het met je oneens ben, wat genuanceerder omdat je hier meer in gaat op de organisatievormen gaat dan het systeem als geheel.
Je triple-C heeft naar mijn mening ook meer met corporate governance te maken dan de verschillen tussen culturele modellen en waar inderdaad nog weleens gezocht wordt naar de makkelijk meetbare KPI’s, applicaties die vooral consumeren en uiteindelijk weinig produceren.
Stellen dat organisaties geen systeem zijn als overgeschakeld wordt op Triple-V of Triple-R lijkt me te kort door de bocht, een bondscoach blijft niet lang in functie als hij alle spelers maar wat laat doen. Met je drie R’s van Spock geef je volgens mij ook al aan dat er altijd grenzen zijn en iemand die dus moet bewaken en zodat niemand buitenspel loopt.
En hier kom ik terug op de essentie van mijn eerste vraag omdat – heel wetenschappelijk – de wet van Archimedes nog weleens van toepassing is in je geliefde Rijnlandse model;-)