Effectiviteit van de IT-afdeling

Van een fabriek kunnen we redelijk precies de effectiviteit meten. We bepalen de kosten van de fabriek, wat er aan halffabrikaten ingaat en vervolgens meten we het aantal opgeleverde producten. Is een fabriek in staat om voor minder kosten meer producten te ontwikkelen, dan verhogen ze hun effectiviteit. 

Ook voor andere soorten bedrijfsonderdelen kunnen we de effectiviteit berekenen. Maar hoe meten wij eigenlijk de effectiviteit van onze automatiseringsafdelingen? Sommige grote banken en verzekeringsmaatschappijen hebben honderden IT-ers op de loonlijst staan. Maar hoe bepaalt men eigenlijk of ze allemaal nodig zijn, of men eigenlijk een te dure hardware/software infrastructuur heeft, en of de kwaliteit van de ontwikkelde software op niveau is? 

We kunnen deze afdelingen uiteraard zien als fabrieken en wel gegevensverwerkende fabrieken. Er komen gegevens binnen (door gebruikers ingevoerd), ze worden bijgewerkt en vervolgens worden de gegevens geproduceerd (bijvoorbeeld, in de vorm van rapporten). En als we ze als fabrieken zien, moeten we ook in staat zijn om de effectiviteit te berekenen.

De productiviteit van programmeurs wordt wel eens gemeten aan de hand van het aantal regels code dat ze per tijdseenheid kunnen schrijven. Hoe meer, hoe beter. Maar is dit wel fair? Hun productiviteit wordt bijvoorbeeld beïnvloed door de kwaliteit van het aangeleverde ontwerp. Wat dat betreft is de programmeur als de spits van een voetbalteam. Zelfs de beste spits zal niet scoren, als hij de bal niet goed aangespeeld krijgt. Een zeer goed doordacht en uitgewerkt ontwerp zal de productiviteit van de programmeur ten goede komen. Daarnaast zegt het aantal coderegels per tijdseenheid niets over de kwaliteit van de ontwikkelde code. Stel dat de ene programmeur er veertig procent langer over doet dan de andere, maar dat de kwaliteit van zijn code veel hoger is. Dit betaalt zich ongetwijfeld terug bij het beheer.

Als we naar effectiviteit willen kijken, dan dienen we de gehele afdeling onder de loep te nemen en niet één speler van het gehele team. Laten we daarom maar kijken naar de totale kosten van de automatiseringsafdeling en deze uitzetten tegen hoeveel gegevens er verwerkt worden, want daar gaat het eigenlijk om. Het gaat niet om de snelheid van het programmeren, het gaat ook niet om de kwaliteit van de software, uiteindelijk gaat het bij doorsnee automatiseringsafdelingen om de hoeveelheid verwerkte gegevens. Dus misschien moeten we gewoon kijken naar het aantal databasetransacties. Hoeveel gegevens worden er per tijdseenheid opgeslagen, bijgewerkt en gerapporteerd?

De effectiviteit van een automatiseringsafdeling wordt dan bijvoorbeeld de totale jaarkosten (hardware, software, personeel) gedeeld door het totaal aantal transacties van alle IT-systemen van datzelfde jaar. Laten we deze meeteenheid voor het gemak afkorten tot de TEM (Total Effectivity Measure).

Hoe goed is deze TEM? Stel dat we van twee concurrerende verzekeringsmaatschappijen de TEM berekenen en dat dan blijkt dat de TEM bij de een twee keer zo hoog is als bij de ander. Dan zal de mindere zich toch afvragen waar ze wat fout doen. Recentelijk was ik betrokken bij een bedrijf dat een ERP-pakket wilde aanschaffen. Na wat studie bleek het om een kleine hoeveelheid gegevens te gaan en een zeer klein aantal transacties. Voor dit bedrijf zou de TEM zeer ongunstig uitpakken. De gegevens handmatig bijwerken op papier zou qua TEM veel goedkoper zijn.

Een kritiek op de TEM zou kunnen zijn dat het ene bedrijf nu eenmaal meer transacties draait dan de ander. Een telefoonmaatschappij zal bijvoorbeeld veel meer transacties draaien dan een tandarts. Uiteraard kan de verzekeringsmaatschappij zijn kosten over een groter aantal transacties verdelen, maar er zullen ook veel meer kosten tegenover staan.

Ik pleit ervoor dat bedrijven gaan onderzoeken hoe het met hun effectiviteit zit. En laten we eens kijken of de TEM een goede meeteenheid is, of dat we nog op zoeken moeten naar een betere. Maar in ieder geval wordt het tijd om de effectiviteit van onze automatisering in kaart te brengen. In vele andere vakgebieden kan het toch ook!