Hoe synergetisch is synergie?

Binnen alle grote organisaties speelt redundantie van IT natuurlijk een rol. Iedereen lijkt voetstoots aan te nemen dat je altijd synergie hebt door redundante IT projecten bijeen te harken, en de zaak dan in 1 keer te doen, en dan goed. Laat duidelijk zijn dat als twee projecten exact hetzelfde beogen, dat je dan inderdaad twee keer zo goedkoop uit bent als je maar een van die twee systemen gaat maken. Maar stel nu eens, dat je wat informatiesystemen hebt die veel gemeen hebben maar niet exact hetzelfde zijn. Deze situatie is vrijwel altijd aan de hand bij redundantie. Laten we eens een vergelijkend warenonderzoekje doen: er zijn twee IT projectvoorstellen die ongeveer hetzelfde informatiesysteem willen implementeren. Ze hebben dus veel overeenkomsten, maar zijn niet exact hetzelfde. Laten we even aannemen dat die projecten bijvoorbeeld allebei 12 maanden duren. Als je kijkt naar wat dat gemiddeld zou moeten kosten, dan is 780.000 Euro per project volgens benchmark gegevens niet zo heel gek. Daarbij neem ik aan dat een IT-er in totaal 1000 Euro per dag kost, en dat er 200 werkdagen in een jaar zitten. Dus als je klakkeloos die twee projecten gaat doen ben je 1.56 miljoen Euro kwijt. Stel nu eens dat we die projecten in elkaar schuiven, en ze als een gezamenlijk project gaan uitvoeren. Nu is een relevante vraag, wat besparen we ons als we dat zouden doen? Laten we eerst eens kijken hoe lang dat project mag duren als het ene project even duur wordt als de twee afzonderlijke. Dan hebben we dus 1.56 miljoen om te verspijkeren in deze joint effort. En daarvoor kun je een IT project doen van ongeveer 14.5 maand. Ja u leest het goed, een IT project van 14.5 maand is volgens benchmark gegevens twee keer zo duur als een IT project van 12 maanden. Dat betekent dat je de eventuele kostenbesparing die je beoogde door de projecten bijeen te voegen, alleen bereikt als je zeker weet dat de verschillen die de twee systemen kennen in minder dan 2.5 maand op te lossen zijn. Lukt dat? Er is natuurlijk een toename van het aantal stakeholders, maar er zijn nu ook meerdere sponsors. Wat vinden die van het idee dat de deadline van het gezamelijke project verder weg in de toekomst ligt? Meer stakeholders, betekent meer eisen. Hoeveel? Nog een mooie: wie wordt er nu eigenlijk eigenaar van het gezamenlijke systeem? Is de organisatie daarop ingericht? Welke overeenkomsten zijn er? En, wat zijn de variatiepunten van het gezamenlijke systeem? Kunnen die variaties wel eenvoudig ingebracht worden in de software architectuur van de afzonderlijke systemen? Of is er een nieuwe architectuur nodig? Okay, dus kostenbesparen voor development ziet er goed uit op management charts, maar is niet zomaar duidelijk. In ieder geval ben je af van de redundatie, en dat scheelt natuurlijk in de onderhoudskosten. Laten we daar ook nog even naar kijken. Stel dat de ene sponsor een update wil hebben die niet nuttig is voor de andere, is de andere sponsor dan verplicht een update af te nemen, en dus een dure productie-acceptatietest uit te voeren? En als het systeem er, bij de sponsor waarvoor de update niet relevant is, niet door komt: wie betaalt dan die aanpassing? In de praktijk zal een niet belanghebbende simpelweg de update niet installeren, waardoor de joint effort op termijn weer uitgroeit naar twee verschillende, redundante maar niet exact dezelfde systemen. Was dat nu niet net wat zo’n gezamenlijk project probeerde te voorkomen? Chris Verhoef Prof. dr. Chris Verhoef is hoogleraar informatica aan de Vrije Universiteit in Amsterdam. Hij schrijft maandelijks een column in AG II.