Innovatie & Strategie

Zakelijke software
informatie

Te weinig I in IT

Technologie is niet de succesbepalende factor

© CC0 Public Domain Geralt
3 juni 2022

De Belastingdienst gaf kabinet en kamer onlangs een ‘winstwaarschuwing’: voor 2026 hoeven ze niet met grote belastinghervormingen op de proppen te komen, de systemen kunnen zelfs een marginale verandering als afschaffing van de jubelton nauwelijks aan. Dat zet een sterke rem op nieuwe wetgeving. En voordat u denkt ‘ja hoor, weer de Belastingdienst’: het is in uw eigen bedrijf waarschijnlijk niet anders. 

In gesprek met de techondernemer Peter Hinssen over dit onderwerp vertelde hij mij: in de IT draait het nog altijd teveel om de T en te weinig om de I van informatie. In de nieuwe, snel veranderende wereld, die Hinssen ‘The Never Normal’ noemt, is niet langer de technologie de succesbepalende factor, maar de informatievoorziening.

En juist daar worstelen bedrijven die een lange historie hebben mee: banken, verzekeraars, OV, industrie. Zij draaien in de core van hun landschap nog altijd op systemen die dertig, veertig jaar geleden zijn ontworpen. Destijds waren die state-of-the-art en gaven ze de bedrijven een geweldige voorsprong. Omdat de systemen zo verschrikkelijk robuust zijn, doen ze nog altijd hun werk. Ze hebben echter ook nadelen: ze geven niet de benodigde klant- en medewerkerervaring en je kunt ze niet makkelijk aanpassen. Daar zijn ze namelijk nooit voor ontworpen.

Oplossingsrichtingen

Je zult het radicaal anders moeten aanpakken. Daar is geen pasklare, ‘one size fits all’- oplossing voor, maar Hinssen geeft wel suggesties voor oplossingsrichtingen:

  1. Stel een CIO aan die The Never Normal ziet als kans, als een ‘force of change’ om af te stappen van oude denkwijzen en gewoontes;
  2. Investeer in ‘re-skilling’ van de IT-afdeling en focus daarbij op de I, niet op de T. Verhuis de infrastructuur naar de cloud; neem data scientists en analisten aan en geef hen moderne tooling op het gebied van softwareontwikkeling en analytics;
  3. Breng eindelijk de verbinding tot stand tussen business en IT en zorg ervoor dat IT-wensen van de business veel sneller worden ingewilligd. Nieuwe technologieën zoals low-code software-ontwikkelplatformen leveren hier een belangrijke bijdrage aan;
  4. Durf risico te nemen. Je zult fouten maken als je je aanpak rigoureus wijzigt. Systemen zullen kinderziekten hebben en zullen af en toe down gaan. Maar dat gebeurt ook als je door blijft gaan op de oude weg.

Technologie als versneller

Hoe je deze oplossingsrichtingen in de praktijk kunt brengen, laat de ANWB zien. Een traditioneel bedrijf met een traditioneel IT-landschap dat echter voor radicale vernieuwing koos en middels een start-up aanpak de dienst ANWB Reisopmaat ontwikkelde. Dit is een platform dat de wereldwijde voorraad aan accommodaties, vluchten en huurauto’s samenbrengt, zodat mensen op één plek hun eigen pakketreis kunnen samenstellen.

Hoewel het technisch complex was om honderden systemen van derden te ontsluiten op de eigen ANWB backoffice, is dat toch binnen een jaar gelukt. Het geheim? Een focus op nieuwe businessmodellen en data science en technologie gebruiken als versneller. Zou de Belastingdienst dit ook durven?

Reactie toevoegen
2
Reacties
RBx 08 juni 2022 17:29

Bij deze mijn visie: Ik heb altijd al graag mijn steentje willen bijdragen aan de IT systemen van de Belastingdienst en ik denk dat er nog wel meer professionals met 20-25+ jaar ervaring zijn die dit zouden willen. Het punt is alleen dat er velen zoals ik zelfstandigen zijn en constant deze opdrachten voorbij zien komen waarbij zij mededelen dat ZZP-ers niet hoeven te reageren!

Waarschijnlijk is dit het resultaat van de plannen van Koolmees maar voor die tijd kwam je als zelfstandige ook niet echt aan opdrachten voor ZZP-ers bij de Belastingdienst omdat het contractueel helemaal dichtgetimmerd was. Niet iedere ZZP-er is Integer maar het is toch echt noodzakelijk om ook mensen buiten de vaste commerciële group in te huren omdat deze "zelfstandige" ook daadwerkelijk zelfstandig zijn veel ervaring hebben en vaak objectief zijn. Ik kreeg geen instructies mee wat ik moet zeggen en hoe ik mij moet gedragen bij complexe vraagstukken nog volg ik de standaard aanpak die wordt meegegeven.

Het ging een tijdje goed doordat veel partijen toegang kregen om zzp-ers aan te stellen bij onze overheid maar de laatste paar jaren merk ik weer dat de toegang wordt afgesneden en compleet eenzijdige, homogene teams van de bekende commerciële partijen met de scepter zwaaien op IT gebied.

Ik ben van mening dat onze overheid zelfstandig besluiten dient te nemen en gebruik maakt van een diverse group van technische experts voor advies en zich niet constant laat inpalmen door snelle gasten en meiden met mooie pakjes. Je moest eens weten hoe vaak ik technische stukken lees of meetings bijwoon waar technische oplossingen worden ingezet op basis van argumenten die helemaal niet valide zijn en waarschijnlijk gewoon van een of ander forum zijn gehaald terwijl wij allemaal een WO of minimaal HBO hebben gevolgd en bijna niemand heeft het gewoon door! Ik zou er wel een boek over kunnen schrijven :)

Peter Manz 04 juni 2022 23:08

Er is ook nog een andere kant aan de focus op de I.
Ook de I kan worden opgebouwd uit kleine onafhankelijke processen. Wat nu veel te gebeurt is het aanroepen en starten van processtappen te veel in elkaar haken. De I wordt complex en dat leidt bijna vanzelf tot T die ook complex is.
Een voorbeeld: Het nodig om een bepaalde set van gegevens te valideren en op basis daarvan te besluiten of iets wel of niet mag gebeuren. De validatie regel aan de voorkant (wat de gebruiker ziet) en de achterkant zou het zelfde moeten zijn. Het effect van de validatie is echter anders.
Aan de kant van de I zou er informatie moeten komen over wat er mis is en wat er nu gedaan moet worden. Aan de kant van de I moet een bepaalde status worden vastgelegd of een mutatie niet worden doorgevoerd. Voor de validatie moet het uitgangspunt zijn dat deze slechts op een plaats mag bestaan. Het effect voor de I en voor de T moet ontkoppeld zijn.
Dit ontkoppelen gebeurt vaak niet. Veel problemen met privacy zijn hier een gevolg van. Je moet privacy gevoelige informatie vastleggen om een bepaald bedrijfsdoel te bereiken. Ontsluiten van deze informatie vraagt andere regels. Doordat het waarom van de gegevens niet vastgelegd bij het gegeven gaat het mis bij het verstrekken van het gegeven. De regels waarom je iets vastlegt en wat je ermee mag doen liggen te ver uit elkaar en niet duidelijk gekoppeld. Daardoor ontstaan problemen die op het eerste gezicht geen verband houden.
Het inbrengen van andere skills zou dus ook dit moeten omvatten. Maak dingen eenvoudiger, zorg dat ontwerpers en ontwikkelaars uitgaan van ontkoppelen en duidelijke koppelpunten, scheidt wat je wil bereiken van hoe je dingen maakt.
Een timmerman gebruikt toch ook niet alle spullen uit zijn gereedschapskist omdat die er nu eenmaal zijn.