Slim is dom

019-Thumbnail elektriciteit
Toen wij ons huis kochten, was het een opknappertje, zoals dat heet.
En dat niet alleen, we wisten ook al dat er op enthousiaste maar weinig deskundige wijze in was verbouwd.
We waren dus voorzichtig toen we in een van de kamers de stroom er af moesten halen. Niet één, maar diverse stopcontacten controleerden we voordat we ervan uit durfden te gaan dat de elektriciteit werkelijk was uitgeschakeld.
Ja hoor, alles in orde!
We konden aan de slag.
Maar net toen we niet meer op onze hoede waren – TSJAK! – kregen we alsnog een schok.
Een van de stopcontacten, midden in de kamer, bleek niet te zijn aangesloten op de uitgeschakelde groep, maar doorgelust vanuit een stopcontact in de kamer recht eronder.
En terwijl we nog na zaten te sidderen, van de schok en van de schrik, zagen we voor ons geestesoog onze knutselende voorganger, innig tevreden met zichzelf en met zijn oplossing: ‘Slim!’
 
Zulke ‘slimme oplossingen’ zijn helaas niet voorbehouden aan amateuristische huisverbouwers.
Ook in de ICT kom je ze regelmatig tegen.
 
Zo was er het geval van de softwarerelease die, eenmaal in productie, een fout bleek te bevatten. Dat was vervelend voor de gebruikers, maar niet meer dan dat; hinderlijk was een groot woord, blokkerend was niet aan de orde en van een calamiteit was al helemaal geen sprake.
Dat er niet veel aan de hand was, was vooral omdat de betreffende functionaliteit op dat moment nog niet gebruikt hoefde te worden; een aantal weken later zou dat anders zijn. We konden daarom niet op de volgende reguliere release van de software wachten, maar hadden wel de tijd om het probleem netjes op te lossen.
Gelukkig was de leverancier in staat en bereid om binnen twee dagen nieuwe software te leveren waarin de fout zou zijn hersteld. Uitstekend!
Toen we de gebruikersorganisatie daarvan op de hoogte brachten, kregen we al snel een belletje van een danig met zichzelf ingenomen functioneel beheerder. Onze oplossing was niet meer nodig, meldde hij, want twee hele dagen, zo lang kon hij natuurlijk niet wachten. Gelukkig had hij goede contacten bij technisch beheer, dus hij had het allemaal al geregeld.
Allemaal al geregeld?
Ja, wat piefjes en palletjes omgezet in het rekencentrum en alles draaide nu als een zonnetje. Klaar!
Toen onze beller hoorde dat hij de wijzigingen weer terug moest laten draaien, was hij daar bijzonder verontwaardigd over.
Wat nou terugdraaien! Het werkte toch?
Ja, op dat moment wel. Waarschijnlijk.
Maar het was zeer de vraag wat er zou gebeuren bij een toekomstige release van de software of een technische update in het rekencentrum. Zouden de piefjes en palletjes dan nog in de juiste stand staan en de gewenste functionaliteit geven? En zo nee, zou er dan nog iemand weten wat er was gebeurd (over documentatie maken we ons maar helemaal geen illusies)? En daarmee dus ook hoe het ontstane probleem moest worden opgelost?
 
‘Slimme oplossingen’ kun je overal tegenkomen, maar een gebied waar ze zeker welig plegen te tieren is dat van de koppelingen, ofwel de gegevensleveringen tussen applicaties.
Want voor gegevensleveringen moet worden afgestemd.
Niet alleen inhoudelijk – wat wordt er precies geleverd en hoe gaat dat in zijn werk? – maar vooral ook tijdig, zodat de een klaar is om te leveren als de ander wil ontvangen of, andersom, de een klaar is om te ontvangen als de ander moet leveren.
 
Maar ja, afstemming hè.
 
Altijd lastig.
 
Gelukkig is er vaak nog wel een handige oplossing te verzinnen!
En dat resulteert dan bijvoorbeeld in een koppeling waarbij de benodigde gegevens niet worden gehaald uit het eigenlijke bronsysteem (want ja, dat onderhoud je als ICT-er toevallig niet zelf), maar uit een applicatie die ze weer uit dat bronsysteem ontvangt (want die onderhoud je toevallig wel zelf! Wat een mazzel!).
Een doorgeluste gegevenslevering, zeg maar.
Die werkt meestal heus wel, totdat er iets gebeurt.
Totdat bijvoorbeeld het laatst ontvangende systeem extra gegevens wil, die wel in het bronsysteem zitten, maar die het tussenliggende systeem niet nodig heeft.
Of de beide applicaties functioneel een heel verschillende richting op gaan.
Of de tussenliggende applicatie wordt uitgefaseerd, zonder dat  bekend is dat er nog andere software van afhankelijk is. Want dit soort oplossingen wordt meestal niet aan de grote klok gehangen.
 
Als je hier draait en er valt daar met een daverende klap iets om, dan heb je vaak te maken met een ‘slimme oplossing’.
Weliswaar lukte het met die oplossing om snel iets aan de praat te krijgen, maar wel door gebruik te maken van iets dat daar niet voor bedoeld was of door een aanpassing te doen op de verkeerde plek.
En wat heb je dan: een ICT-landmijn.
Zolang zulke potentiële explosieven niet worden geraakt, is er niets aan de hand. Maar op zekere dag wordt er druk op uitgeoefend en voordat iemand het doorheeft gaan ze dan af, met wie weet hoeveel schade tot gevolg.
Het kan jaren duren voordat dat gebeurt – totdat er niemand meer is die nog weet waar ze liggen en hoe ze onschadelijk kunnen worden gemaakt.
Juist dat maakt ze zo riskant.
 
‘Slimme oplossingen’ zijn daarom helemaal niet slim.
Die zijn kortzichtig en ontzettend dom.
 
Dus hoor je om je heen de woorden ‘slim’, ‘handig’ en ‘effe snel’, maar ook termen als ‘pragmatisch’ of ‘oplossingsgericht’, dan zouden al je alarmbellen moeten afgaan.
Je zou zomaar getuige kunnen zijn van de voorbereidingen voor toekomstige ellende.
In dat geval: doe iets!
 
Maar misschien drukken de sprekers in kwestie zich alleen een beetje ongelukkig uit en bedoelen ze eigenlijk ‘intelligent’, ‘goed doordacht’ en ‘elegant’.
Laat ze dan vooral ongestoord doorwerken.
Want dan zijn ze écht slim bezig.
 
019-Elektriciteit

Zoek de verbinding

018-Thumbnail aan elkaar gegroeide bomen
Wij ICT-ers zijn net mensen.
En mensen hebben de onbedwingbare neiging om te classificeren, in te delen, te ordenen en te categoriseren. Dat kan reuze handig zijn en allerlei interessante inzichten opleveren.
Niet echter als we ons ordeningstalent inzetten om de wereld te verdelen in ‘wij’ en ‘zij’.
De wetenschapper Philip Zimbardo heeft in zijn Stanford-gevangenisexperiment al laten zien tot welke uitwassen dat kan leiden, in een mum van tijd.
 
Misstanden als in Zimbardo’s experiment zijn in onze brave kantooromgeving gelukkig niet zomaar te verwachten. Dat neemt niet weg dat ook bij ons de samenwerking niet bevorderd wordt door een houding van:
‘We werken weliswaar bij dezelfde organisatie, maar zij zijn gebruikers en wij ICT-ers.’
‘We zijn weliswaar allemaal ICT-ers, maar zij zijn van het rekencentrum en wij van de software.’
‘We houden ons weliswaar allemaal bezig met software, maar zij zijn beheerders en wij ontwikkelaars.’
‘We zijn weliswaar allemaal ontwikkelaars, maar zij ontwikkelen in Java en wij in .Net.’
Enzovoorts…
Het zou natuurlijk prima zijn als de onderliggende gedachte daarbij was: ‘en dus hebben zij allerlei kennis en vaardigheden waar wij profijt van kunnen hebben’, maar meestal komt die eerder neer op: ‘en dus weten zij er niets van’.
 
Dat dit een algemeen menselijk trekje is, betekent nog niet dat er verder niets meer aan te doen valt.
Laten we zorgen dat iedereen die kan bijdragen aan een goed eindresultaat, verandert van ‘zij’ in ‘wij’!
Bijvoorbeeld door mensen in persoon te ontmoeten, al is het maar één keer. Door niet te mailen of te bellen naar collega’s die in de buurt zitten, maar even bij ze langs te lopen. Door eens een praatje te maken over onderwerpen die niet met het werk te maken hebben. Door te bedanken als iemand iets voor je heeft gedaan. Door een compliment te geven als dat op zijn plaats is.
En vooral: door nooit te luisteren naar negatieve verhalen die over iemand worden verteld, maar je eigen oordeel te vormen.
 
Een afdeling waar ik werkte, had veel externe softwareleveranciers, en helaas verliepen die contacten niet altijd probleemloos.
Met één leverancier was de verstandhouding echter wel bijzonder moeizaam.
Daar was dan ook alle reden toe, want als zij hun software aan ons opleverden, zat die doorgaans nog vol fouten en was er veel tijd en herstelwerk nodig voordat die in productie kon worden genomen. Resultaat: boze opdrachtgever, chagrijnige technisch beheerders, mopperende functioneel beheerders, klagende eindgebruikers en hoge kosten. Elke release opnieuw.
Toen ik deze applicatie op een dag tot mijn werkpakket mocht gaan rekenen, bekeken mijn collega’s mij dan ook met een mengeling van opluchting en medelijden. Daar ging ik nog wat mee beleven! Vooral omdat de eerste opdracht was om de leverancier op het matje te roepen en eens stevig de waarheid te zeggen.
Een typisch gevalletje ‘nou, lekker dan’.
 
Ik zag nog niet zo voor me hoe ik het zou gaan aanpakken, maar in ieder geval had ik er weinig zin in om wie dan ook op het matje te roepen voordat ik precies wist wat er aan de hand was. Daar bleek echter moeilijk achter te komen, want behalve het contract waren er nauwelijks onderlinge afspraken te achterhalen. Wel werd me al snel duidelijk dat we zelf ook een aantal flinke steken hadden laten vallen.
En daardoor wist ik ineens wat ik zou gaan doen.
 
Korte tijd later zaten twee vertegenwoordigers van de leverancier  – die ik die dag voor het eerst ontmoette – tegenover onze applicatiebeheerder en mij. Met strakke gezichten, want ze hadden allang begrepen dat ze waren uitgenodigd met het doel ze eens flink de mantel uit te vegen.
‘Ik zal het meteen maar zeggen,’ zei ik, ‘ik heb de verschrikkelijkste dingen over jullie gehoord.’
Gezichten nog strakker.
‘Maar ik ben er vrij zeker van,’ ging ik verder, ‘dat jullie op precies dezelfde manier praten over ons.’
Twee lachjes die net niet meteen onderdrukt konden worden.
‘En volgens mij hebben jullie daar wel gelijk in.’
Verbaasde blikken opzij.
En ik begon uit de doeken te doen wat wij als opdrachtgever zoal verkeerd hadden gedaan.
Het effect was verbluffend. Toen ik klaar was, vertelden mijn gesprekspartners ongevraagd welke fouten zij zelf hadden gemaakt. Daarna was de sfeer zo ontspannen dat we, zonder verwijten over en weer, de belangrijkste pijnpunten onder de loep konden nemen. Die bleken toen niet eens zo moeilijk op te lossen; binnen een half uurtje bedachten we met ons vieren een aantal maatregelen. Vervolgens maakten we nog wat andere werkafspraken, onder andere over wekelijks telefonisch contact, en daarna gingen we in opperbeste stemming uit elkaar.

Met de implementatie van de maatregelen begonnen we nog diezelfde dag.
De eerstvolgende softwarelevering was vlekkeloos en kon zo worden geïnstalleerd en in productie genomen.
Daarna hebben we nog jaren tot volle tevredenheid met elkaar samengewerkt.
Topleverancier.
 
Dus wat ik maar zeggen wil: zoek de verbinding.
Dat kan zomaar leiden tot geweldig mooie resultaten.

018-Aan elkaar gegroeide bomen

Maak eens wat af

017-Thumbnail halve trap
Het is maar goed dat niet alle veranderingstrajecten tot het beoogde resultaat leiden.
Nee zeg, stel je voor in wat voor omgeving je nu zou moeten werken als alle doldwaze vernieuwingsactiviteiten daadwerkelijk effect hadden gehad! Een mens moet er toch niet aan denken.
Maar soms is het jammer dat de goede bedoelingen en de initiële inspanningen niet even zijn doorgezet, totdat ze echt wat opleverden.
 
Ook ‘gewone’ opdrachten halen niet altijd de eindstreep, maar zeker trajecten die zich richten op bijvoorbeeld vernieuwing van de werkprocessen, verandering van de organisatiecultuur, verbetering van de communicatieve vaardigheden van het voltallig personeelsbestand en andere pogingen om de werknemer te verheffen, gaan nogal eens als een nachtkaars uit.
 
Hoe komt het eigenlijk dat dat lot zoveel veranderprogramma’s treft?
In veel gevallen gaat het al mis bij de start:
 
Vernieuwing is een doel op zich
‘Vernieuwing is een gebrek aan zelfbeheersing,’ aldus Jan Fischer, decennialang de uitbater van het befaamde Hotel van der Werff op Schiermonnikoog. Een boude stelling, waar ik toch wel eens aan moet denken op momenten dat vernieuwing wel heel erg een doel op zichzelf lijkt te zijn.
Zo kreeg ik eens een nieuwe leidinggevende die zich vol bravoure presenteerde als verandermanager, en die meteen aankondigde dat hij binnen de kortste keren alles onherkenbaar zou veranderen en vernieuwen.
‘Zo,’ zei ik (want op het werk is populair worden niet altijd mijn voornaamste doel), ‘en kom je misschien ook nog wat verbeteren?’
Het zal geen verbazing wekken dat deze veranderaar al vertrokken was voordat er ook maar iets was veranderd of vernieuwd, en daarmee kwamen we vermoedelijk goed weg, maar wat was hier nu eigenlijk de bedoeling van, behalve vernieuwen-om-het-vernieuwen?
 
Er wordt niet geleerd van eerdere ervaringen
Als je als organisatie al een paar verbetertrajecten achter de rug hebt, dan ligt het toch voor de hand dat je eerst gaat kijken wat je daarin goed en minder goed hebt gedaan voordat je je weer in het volgende stort. Dat gebeurt echter lang niet altijd.
Ik ken een organisatie waar, na een aantal minder geslaagde pogingen, onder luid tromgeroffel opnieuw een zeer ambitieus traject werd gestart. Toen daar door de collega’s enigszins smalend op werd gereageerd, meldden de projectleden opgewekt dat de zaken weliswaar al een paar keer niet helemaal volgens plan verlopen waren, maar dat het nu zonder enige twijfel beter zou gaan.
O? Wat gingen we nu dan doen dat voorgaande keren niet was gebeurd?
Nou, dat wisten ze niet zo precies, maar echt hoor, dit keer was alles anders en ging dus ook alles lukken.
(Is er nog iemand die wil weten hoe het afgelopen is?)
 
Goede ideeën worden niet omgezet in een goed plan
Een verbeteridee, zelfs een heel goed verbeteridee, is op zichzelf nog niet voldoende om een organisatie in een andere richting te manoeuvreren. Wil er iets van terechtkomen, dan zal men het eens moeten worden over wat er precies bereikt moet worden en waarom, hoe dat kan worden gedaan en door wie, hoe de betrokkenen op de hoogte worden gebracht en enthousiast gemaakt, wat het mag kosten en hoe een en ander wordt betaald, eventueel wat er nu niet kan worden gedaan, en nog een heleboel zaken meer.
Kortom: de ideeën moeten worden vertaald naar een helder doel en een redelijkerwijs uitvoerbaar plan.
 
Zijn zo’n doel en zo’n plan er niet, dan komt het traject vaak al snel na de start in de problemen.
Want het blijkt lastig om door te gaan, als aan het begin eigenlijk al niet helemaal duidelijk was wat het traject uiteindelijk moet opleveren. In het enthousiasme van de beginperiode kon nog over het hoofd gezien (of genegeerd) worden dat de beelden over het te bereiken resultaat uiteenlopen, maar dat komt pijnlijk aan het licht als er concrete stappen moeten worden gezet.
Bovendien blijkt het verbetertraject na verloop van tijd soms wel erg ambitieus; in de euforie van het begin heeft men zich niet voldoende gerealiseerd dat er binnen de organisatie nog een aantal andere verbeteractiviteiten lopen en dat daarnaast het eigenlijke werk natuurlijk ook gewoon door moet gaan.
Als dan ook nog de prioriteiten een beetje verschuiven, binnen of buiten de organisatie, en men merkt dat het nieuwe wel anders is, maar nauwelijks beter, dan heeft dit vernieuwingstraject zijn langste tijd wel weer gehad.
En dan wordt het vaak niet formeel afgesloten en grondig geëvalueerd, maar verdwijnt het stilletjes van de radar.
 
Maar niet getreurd: er is binnen de organisatie altijd wel weer iemand met een ander vernieuwingsidee…
 
Is dit een pleidooi tegen verbeterideeën?
Natuurlijk niet, en trouwens ook niet tegen wilde verbeterideeën; daar kunnen de mooiste dingen uit voortkomen.
Tegen het stoppen van trajecten dan?
Ook niet; er kunnen buitengewoon goede redenen zijn om ergens mee op te houden.
Maar wel tegen het starten van half doordachte, veel te veel omvattende veranderactiviteiten, die ongemerkt doodbloeden voordat ze ook maar iets hebben opgeleverd behalve kosten, onrust en negativiteit. En zonder dat er iets van geleerd is.
En ook tegen het starten van veelbelovende vernieuwingen die vervolgens net niet lang genoeg worden doorgezet, en daardoor stranden in het zicht van de haven. Terwijl we er zoveel aan hadden kunnen hebben, als we er maar even mee waren doorgegaan!
 
Laten we daar nou eens mee ophouden.
En dan maken we de andere dingen die we doen, gewoon af.
 
017-Halve trap