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.)
Goed verhaal, maar hier en daar wel wat kort door de bocht. Soms worden de IT dijken inderdaad stapsgewijs verhoogd. Het oude pakket wordt aangepast, krijgt een moduletje hier en een moduletje daar erbij. Het ‘werkt’, zegt men dan, maar inmiddels begint de praktijk de IT-oplossing in te halen.
Ik noemde dat altijd het ’torentje-bussekruit’ principe: men bleef maar net zo lang aan een pakket sleutelen en aanpassen tot het bij wijze van spreken van kauwgum en plakband aan elkaar hing. Soms is dan rigoureuze herbouw uiteindelijk tóch de beste oplossing. Terug naar de tekentafel met de kennis van nu. Nee, dat is lang niet altijd een verkeerde gedachte. Behalve als het werkzaamheden van de overheid betreft: dan gaat dat geheid fout door kortzichtige aanbestedingen en incapabel voortgangsmanagement…
Het vervangen van systemen door systemen schiet inderdaad niet op; de clou is juist het vervangen van systemen door applicaties (en dus afscheid nemen van systemen, inclusief het bijbehorende systeemdenken).
@Jack Jansonius. Zit wat in, alleen ben ik dan wel bang voor ‘versnippering’, teveel losse items en applicaties die het werken omslachtig maken. Centralisatie van gegevens en handelingen maakt over het algemeen het werk overzichtelijker. Maar eens vanuit een ander perspectief naar de oplossing en vervanging kijken, kan uiteraard geen kwaad…
Uit stof zijt gij geboren, tot stof zult gij wederkeren geeft hetzelfde rondje om de kerk van Jack door systemisch te vervangen door systemen stof tot denken. Systemisch denken in een circulair systeem bleek het Deltaplan impact op allerlei ecologische systemen te hebben zoals dat de herinrichting van het landschap als gevolg van veenwinning een lappendeken aan Natura2000 gebieden geeft met een stikstof problematiek:
“Het systeem dat je wilt vervangen ‘leeft’ in een context waar je mee dient te dealen.”
Het consuminderen van informatie door alleen te dealen met de context waarin je leeft gaat om een situational awareness. En het verhogen van de zeedijken terwijl de emmer langzaam volstroomt via de rivieren geeft wel aan dat de context nog even goed bekeken moet worden. In geouwehoer kun je niet wonen want zolang de digitaal transformerende burger onveranderlijke fysieke behoeften heeft blijft het dweilen met de kraan open.
En meteen de volgende dag in Computable een artikel over een ministerie dat zowaar dergelijke adviezen nog lijkt over te nemen ook! https://www.computable.nl/artikel/nieuws/overheid/7440578/250449/om-zat-met-ict-project-op-de-verkeerde-weg.html
@Fred, heel scherp opgemerkt; was ook mijn eerste gedachte toen ik dit artikel las!
Al in de openingszin gaat het mis: “Beslag Informatie Systeem (BIS)”.
Uiteraard is het ontwerp “onnodig ingewikkeld”.
Direct gevolgd door de parel:
“ In het systeem werd veel te veel informatie over in beslag genomen spullen gestopt die ook elders beschikbaar is.”
En ook op “complexiteit van de ketenvoorziening” kun je wachten.
Zou het nu zo moeilijk zijn om in plaats van “Het nieuwe systeem .. “ te spreken van “De nieuwe applicatie..” 🙂