IT-dienstverlening - Wat kost dat wel niet?

Veertig jaar IT-dienstverlening. Wat kost dat wel niet?

Al veertig jaar lang doet Ordina IT-dienstverlening en al veertig jaar lang wordt de vraag gesteld wat dat dan wel niet kost. Veertig jaar geleden was dat een hele lastige vraag. En daarin lijkt niet zoveel veranderd, of toch wel?

Veertig jaar geleden

Toen Ordina 40 jaar geleden begon was IT nog een nouveauté. En het begroten er van dus ook. Er waren nog geen IT studies, dus de IT'ers van het eerste uur waren allemaal begonnen in een ander vakgebied. Iedereen bracht zijn eigen bagage mee en samen ging men aan de slag om de eerste administratieve handelingen te automatiseren, te beginnen met lastige berekeningen, die door computers veel sneller en zonder fouten konden worden uitgevoerd. Projecten werden nog niet begroot, maar werden gewoon uitgevoerd totdat ze klaar waren.
The Mythical Man-MonthToch waren er ook toen al mensen geïnteresseerd in de mechanismen achter het uitvoeren van een project om software te maken. Eén van hen was Fred Brooks. In 1975 publiceerde hij het boek "The Mythical Man-Month" waarin hij liet zien dat het toevoegen van extra mensen op een IT-project niet erg veel hielp. Tegen behoorlijke kosten kunnen meer mensen een IT-project een klein beetje versnellen. Zijn ideeën zijn in de loop van de tijd wel wat aangescherpt, maar de basisprincipes zijn nu, een kleine veertig jaar later, nog steeds van toepassing.
De integrale formule voor inspanning, doorlooptijd en omvang
Een paar jaar later publiceerde Lawrence Putnam een integrale formule waarin hij het verband legde tussen de benodigde inspanning, doorlooptijd en omvang van softwareprojecten. Op basis van zijn ervaringen bij het leger en bij General Electric stelde hij vast dat de bemensing van software veel gelijkenis vertoonde met R&D projecten. Peter Norden had al laten zien dat de bemensing van dat soort projecten door middel van een Rayleigh curve beschreven konden worden. Voor software ziet dat er dan als volgt uit:

Deze software equation werd de basis voor Putnam's Software Lifecycle Model (SLiM) dat hij vercommercialiseerde via zijn bedrijf QSM. Nog steeds is QSM een toonaangevende speler als het gaat om tooling die het begroten van software ondersteunt.

Dertig jaar geleden

Niet iedereen geloofde in de kracht van een enkele formule. Eén van hen was Barry Boehm. Hij bedacht het Constructive Cost Model (COCOMO). COCOMO is gebaseerd op regressieformules die uitgaan van een aantal parameters die vanuit historische projectgegevens zijn bepaald. Door de parameters van nog uit te voeren projecten in te schatten kunnen op basis van de historische gegevens voorspellingen worden gedaan over de benodigde inspanning en doorlooptijd. De huidige versie van dat model, met de verrassende naam COCOMO II, is nog steeds een veel toegepast begrotingsmodel, omdat het met zeer uiteenlopende manieren van software ontwikkelen in alle denkbare omgevingen overweg kan en ook geschikt is voor het begroten van beheer.

Software wordt meetbaarTot nu toe werd de "omvang" van software vooral uitgedrukt in regels code. Voor het begroten van software had dat twee nadelen:

• Door de opkomst van pakketten en hergebruik (ook toen al!) ging niet alles meer om regels code
• Regels code heb je alleen als de software al bestaat en is dus niet toepasbaar bij het begroten van projecten om software te realiseren

Eind jaren zeventig was bij IBM al een methode bedacht om de "omvang" van software uit te drukken in een waarde die losstond van de manier waarop de software tot stand was gekomen of zou komen, de functiepunt. In 1987 werd in de Verenigde Staten de IFPUG opgericht en in 1989 volgde in Nederland de NESMA (toen nog als NEFPUG) en werd dit een veelgebruikte basis voor het begroten van de realisatie en het beheer van software. Doordat de "omvang" van wat de software aan functionaliteit bood werd losgekoppeld van de techniek werd het mogelijk om afwegingen te maken welke technologie gebruikt moest worden. Dit was met name van belang toen niet meer alle software op een mainframe hoefde te draaien.

Twintig jaar geleden

IT begon langzaam zijn magische bijklank te verliezen en werd een vak dat los kwam te staan van de wiskunde en natuurkunde waar het tot dan toe was ondergebracht. Opdrachtgevers begonnen IT projecten ook als gewone projecten te zien en wilden met hun leveranciers vooraf afspraken maken over een vaste prijs voor een project. Het betrouwbaar begroten van IT projecten werd daarmee een belangrijke activiteit voor de IT leveranciers.
Daardoor ontstond behoefte aan ondersteunende tooling die niet alleen een begroting vooraf kon leveren, maar die ook ondersteuning bood bij de planning van dat project en de voortgangsbewaking. In 1988 liet Dan Galorath zijn eerste versie van SEER (naar het woord ziener, de kenner en voorspeller van de toekomst) het levenslicht zien. Hierin werd niet alleen gebruik gemaakt van modellen, zoals die van Boehm en Norden, maar werd ook gebruik gemaakt van kenniselementen, historische gegevens en simulaties. Voor Ordina is dit inmiddels een zeer waardevol hulpmiddel voor het goed begroten van projecten en beheer.
Vanaf 1999 is de geschiedenis van het begroten van software voor mij geen boekenwijsheid meer, maar wordt het mijn dagelijks werk. Eerst in een ondersteunende rol als functiepuntanalist, later langs de lijn als consultant/adviseur en tegenwoordig vooral betrokken aan de startstreep van offertes die projecten of beheerwerk worden.

Tien jaar geleden

Tien jaar geleden was ik zover dat ik publiekelijk durfde te maken wat ik vond en kon en ben ik begonnen met publiceren. Voor mijn eerste artikel moest ik naar Montréal om mijn bevindingen te vertellen voor een publiek met hooggeleerde heren die het hele voorgaande verhaal uit eigen waarneming hadden meegemaakt. Voor wie geïnteresseerd is in de inhoud: het staat op mijn LinkedIn profiel. Ik heb het overleefd en moet er aan gaan wennen dat de groentjes van nu mij soms al zien als één van de ouwe rotten.
Waarde wordt belangrijk
Tot nu toe gaat het vooral over kosten van IT. Natuurlijk is dat belangrijk, zeker in tijden van economische tegenwind. Veel mensen zagen en zien IT ook vooral als kostenpost. In de afgelopen tien jaar zie ik wel langzaam (vooral langzaam) maar zeker het accent verschuiven naar waarde. Natuurlijk kost IT geld - en zal het altijd belangrijk blijven om te weten hoeveel - maar steeds meer verschuift IT in de belevingswereld naar iets dat waarde biedt. Tien jaar geleden moest je nog overal fysiek langs tijdens vaste openingsuren om zaken geregeld te krijgen. Dankzij IT doen we dat tegenwoordig steeds vaker vanaf de bank op een tijdstip waarop het ons uitkomt.

Veertig jaar Ordina heeft heel veel opgeleverd

Als je aan het einde van mijn verhaal een mooi sommetje had verwacht van de miljarden aan projecten en beheerklussen die Ordina in de loop van veertig jaar heeft uitgevoerd, dan moet ik je bij deze teleurstellen. Ongetwijfeld kunnen de jaarverslagen van de afgelopen jaren er bijgehaald worden om te kijken wat het allemaal gekost heeft. Wat uiteindelijk van belang is, is wat het heeft opgeleverd. Ordina heeft de afgelopen jaren haar steentje bijgedragen om het leven makkelijker te maken, om met één van onze bekende klanten te spreken.
Daarbij gaat het er niet om om links en rechts even snel een project te scoren, maar om onze klanten langdurig bij te staan en ze echt verder te helpen. Duurzaam innoveren noemen we dat. Nu onze klanten naast de kosten ook naar waarde gaan kijken, nemen we ook daar onze verantwoordelijkheid in en zorgen we dat bijvoorbeeld onze software voor de inkoop van het Martiniziekenhuis in Groningen zichzelf gaat terugverdienen. Uiteindelijk is het niet belangrijk wat IT kost, maar wat het oplevert.

Oorspronkelijk gepubliceerd als Ordina-blog