Over groots denken en klein acteren

We denken graag groots. Zeker als we iets willen bouwen en het papier geduldig is, komen schijnbaar onmogelijke luchtkastelen met groot gemak in een uitvoeringsfase. Vooral wanneer we te maken hebben met mensen met een hoog ambitieniveau maar gebrek aan veranderingservaring.

Soms is dat goed, zoals het besluit van de Nederlandse regering om na de Watersnoodramp van 1953 met een Deltaplan het kwetsbare laagland te beschermen. Soms is groots denken twijfelachtig. Zoals de Amsterdams gemeenteraad, die eind vorige eeuw op basis van een gebrekkig kostenplaatje besloot tot een bouwen van de nieuwe metrolijn door de drassige Hollandse bodem. Dat is een twintig-jaar-lang hoofdpijndossier geweest met ingestorte zeventiende-eeuwse huisjes. Dat metroproject heeft gelukkig nog de eindstreep gehaald, in tegenstelling tot een vergelijkbaar project in Luik. Daar ligt al bijna vijftig jaar een half afgebouwd netwerk in de bodem verscholen.

Ook in de it denken we graag groots. We benaderen veelal systemen als grote bouwwerken die gecreëerd of vervangen moeten worden met grote oplossingen. En dat heeft in de eerste decennia van deze eeuw tot wat, nou ja, mislukkingen geleid. Dat heeft ons heel veel geld gekost. Bestaande bedrijfsprocessen moesten in systemen worden gevat. En dat moest vaak groots. Op veel terreinen loopt de vergelijking tussen het bouwen van it en het bouwen van fysieke gebouwen of infrastructuur snel spaak, maar als het aankomt op die grootheidswaan dan zijn er flinke parallellen. Gelukkig lijkt die trend te keren, want het denken in grote systemen raakt een beetje uit. Dat kon ook niet anders dan na twintig jaar lang elke keer weer onze neus stoten.

Obsoleet

Heel simpel gezegd: het probleem was eigenlijk dat we dachten onze it te kunnen verbeteren door het ene systeem door het andere te vervangen. Er was dan ook altijd sprake van een migratie van het ene systeem naar het andere. Het oude systeem werd gaandeweg obsoleet en toen het echt niet langer meer kon werd er door it-architecten op papier een nieuw systeem ontworpen. It’ers ging code schrijven of we kochten een standaardpakket als we het vermoeden hadden dat het wel zou passen. Vervolgens werd er een big-bang-moment bepaald wanneer alles van A naar B ging. We vervingen systemen door systemen die min of meer hetzelfde proces ondersteunden. Vergelijkbaar eigenlijk zoals we in de begintijd van de it-systemen ontwierpen, die de toen bekende processen digitaliseerden. (Even tussendoor: dat heette dan ‘innovatie’, maar dat was eigenlijk onzin, want er veranderde niets in de business, toch?)

Steevast gingen er dingen fout tijdens die migraties. Waarom? Omdat je te maken hebt met een omgeving met heel veel factoren en actoren die allemaal weer relaties met elkaar hebben. Bij de overschakeling van het ene systeem naar het andere heb je van doen met ‘high dependencies’ zoals dat heet. Ofwel grote afhankelijkheden. Het systeem dat je wilt vervangen ‘leeft’ in een context waar je mee dient te dealen.

Vergelijk het weer even met de Deltawerken. Als je besluit dat deze waterwerken niet meer voldoen omdat (bijvoorbeeld) de zeespiegel stijgt, ga je stapsgewijs de dijken hoger maken, toch?  En niet een compleet nieuw systeem ontwerpen dat in één klap de werking van de oude Deltawerken moeten overnemen? Dan weet je zeker dat het Hollandse en Zeeuwse laagland onderstroomt.

Omgedraaid

De moeilijke beslissing voor organisaties is sowieso: wanneer is verandering nodig? Gelukkig zien we daarin ook een ontwikkeling. Qua it liepen bedrijven en organisaties altijd flink vooruit op de samenleving. Dat is sinds een paar jaar omgedraaid. De maatschappij waarin wij als burger steeds meer ondersteuning gebruiken in álles wat wij doen, is richtinggevend voor de enterprise geworden. De verandering is daar constant en is vraag-gestuurd vanuit de burger. Zo zien we het ook steeds meer binnen organisaties. Wat ondersteunen we eigenlijk? En met welk it-product? De vraag naar nieuwe it komt niet vanuit een technologische benadering waarin je in het oude denken al snel bij een nieuw systeem belandt, maar vanuit productinnovatie. En die komt vanuit de business zelf.  Zolang de oude systemen de ondersteuning kunnen leveren voor de gevraagde businessinnovatie is het aan de optimalisatie van het systeem. Er kan eventueel wel voor alleen deze specifieke innovatie gewerkt worden met een nieuw technologisch basis.

In werkelijkheid is het de enterprise zelf die moet transformeren om de digitalisering te kunnen bijbenen. En op veel meer vlakken dan alleen it, technologie of infrastructuur. Digitale transformatie zit ‘m echt niet in het gaan toepassen van artificiële intelligentie, in het toevoegen van blockchain aan het landschap of het kunnen uitvoeren van een betaling zonder tussenschakel. Het zit veel meer in de mens zelf en in de organisatie. In de vraag vanuit de business. In groot denken maar klein acteren. Wat dat betreft hoeven bestuurders alleen maar iets beter om zich heen te kijken. De digitaal transformerende burger is een goede casestudie.

(Dit artikel staat ook in Computable-magazine #05/06-22.)