De kostprijs berekenen van ICT uitgaven

Momenteel groeit het aandeel ICT in producten, diensten en services  meer en meer. De vraag, zoals in een eerder gepubliceerd artikel gesteld: ‘Hoeveel ICT zit er in een flesje bier?’, wordt steeds prangender.

Organisaties kunnen er niet meer omheen dat voor een goede kostprijsberekening de ICT kosten ook correct moeten worden meegenomen.  De controller zal daarom samen met de ICT afdeling zo nauwkeurig mogelijke deze ICT uitgaven moeten berekenen. De vraag ‘hoe’ gaan we in dit artikel verder bekijken.

Vaak zijn er al diverse pogingen geweest om de ICT kostprijs te bepalen. Helaas leidde dat veelal tot een behoorlijke hoofdpijn.

Want organisaties lopen in het algemeen tegen drie problemen aan:

1. Hoe verzamel ik alle ICT kosten inclusief de indirecte en verborgen.

2. Hoe rubriceer ik de ICT-uitgaven zo dat ik ze kan gebruiken bij het verdelen over producten en diensten.

3. Hoe bereken ik de kostprijs per product en dienst.

In eerdere artikelen gepubliceerd op deze website hebben we al aangegeven hoe alle ICT kosten worden verzameld en op een logische manier geplaatst in de Ratio Kostenkubus. 

Samengevat, we maken een zogenaamde TOF-analyse: 

– De Technische analyse behelst het opbouwen van een helder beeld van de aanwezige en gebruikte middelen: van vloeren en servers via databases tot de applicaties zelf. Deel van deze fase is het vaststellen van alle users en de faciliteiten waar zij toegang toe hebben.

– De Organisatorische analyse omvat een identificatie van alle medewerkers, afdelingen, divisies etc. De medewerkers worden gekoppeld aan de users, zodat we weten welke gebruikers in welk deel van de organisatie werken.

– In de Financiële analyse tot slot, koppelen we alle gemaakte kosten in detail aan de technische middelen enerzijds en aan de organisatie anderzijds. Zo zien we wie er kosten heeft gemaakt, voor welke delen van de ICT-omgeving.

ICT diensten zijn opgebouwd uit een samenstelsel van subdiensten en ICT-(sub)componenten, die vervolgens ook weer uit onderliggende componenten (kunnen) bestaan.

Een dienst bestaat op die manier uit bouwblokken die samenwerken zoals hardware, systeemsoftware, applicatiesoftware, netwerkverbindingen, switches, servers, databases, beheer, onderhoud, licenties, ondersteuning, et cetera. 

Elk genoemde component heeft een eigen (kost)prijs. Het totaal van deze kostprijzen vormt de uiteindelijke kostprijs van de dienst.

Neem bijvoorbeeld een applicatie met als kostprijs de softwarelicentie. Deze draait op een server waar ook weer aanschafkosten en onderhoudskosten aan zitten. Deze server staat op het rekencentrum waarvan de kosten bestaan uit ruimte, koeling, beveiliging, stroom, et cetera.
 

Zoals genoemd bestaat een Stack uit logisch bij elkaar horende (ICT) bouwblokken die bij elkaar de dienst of applicatie vormen. De eerste stap is per dienst of applicatie bepalen uit welke (deel) bouwblokken deze bestaat.

Het is daarbij evident dat er een goed beeld is wat de dienst inhoudt en welke Service Levels van toepassing zijn. Dezelfde dienst kan worden geleverd met verschillende Service Levels waar verschillende prijzen aan zitten. Zo kan gedifferentieerd worden op uptime (99,5%) en  op beschikbaarheid (7*24 uur).

Elk component binnen de infrastructuur moet minstens één keer worden gebruikt. U moet echter niet verbaasd zijn als blijkt dat sommige componenten in geen enkele Stack voorkomen. Deze kunt u dan gerust uitzetten en het financiële voordeel in uw zak steken. Ook kan het gebeuren dat u componenten in gebruik hebt waar geen kosten tegenover staan. Klinkt fijn, maar vergis u niet in de consequenties van bijvoorbeeld naheffingen op licenties (true up counts).

Wanneer er slechts één gebruiker is, die één applicatie gebruikt die op een ‘dedicated’ server draait dan is het eenvoudig om de kosten toe te wijzen. Namelijk alle kosten van de server en applicatie worden dan één op één toegewezen aan deze gebruiker.

In de praktijk zal deze situatie niet optreden, maar zullen er meerdere gebruikers zijn die meerdere applicaties gebruiken. En op de servers zullen meerdere applicaties draaien. Nu wordt de verdeling en toewijzing van de kosten aan de eindgebruiker aanzienlijk complexer.

Zo zullen de componenten die ‘onderin’ de Stack liggen zoals centrale server en het rekencentrum, doorgaans door meer bovenliggende componenten gedeeld worden. Dit hoeft echter niet noodzakelijkerwijs een evenredige verdeling te zijn. Een kostenverdeling op basis van evenredigheid is vaak onterecht. Er moet een verdeling komen die recht doet aan het gebruik (geleverde capaciteit) en de kosten van het component.

 Vaststellen van de ‘costdriver’

Het uitgangspunt bij de verdeling is de ‘costdriver’ per component. Er moet een directe relatie zijn tussen het gebruiksvolume en de kosten die daar het gevolg van zijn (cost driver). Bijvoorbeeld bij data-opslag is dat het aantal MB, op de servicedesk is dit het aantal meldingen waarbij u ‘Critical’ meldingen zwaarder kunt laten meewegen dan ‘Low’ meldingen. Bij het rekencentrum is dit dan weer het aantal M2 vloeroppervlakte, terwijl bij een Mainframe het aantal cycles de bepalende factor (cost driver) is. Let wel, dit zijn voorbeelden die in specifieke situaties anders kunnen zijn. U zult binnen uw organisatie per situatie moeten kijken wat de beste passende ‘costdriver’ is.

Een waarschuwing is hierbij wel op zijn plaats. Want hoe nauwkeuriger de verdeling wordt des te meer neemt de complexiteit toe. Dit leidt tot grotere administratieve lasten en zelfs onwerkbaarheid als u hier geen goede hulpmiddelen bij heeft of een gespecialiseerde dienstverlener.

Nu kan de prijs per ‘costdriver’ worden berekend. In het voorbeeld van een opslagmedium waar de ‘costdriver’ MB is, deelt u de kosten van het opslagmedium door het aantal MB’s. Zo is de prijs per MB bekend en kunt u doorrekenen hoeveel MB’s door een gebruiker/afdeling/proces gebruikt wordt en wat de kosten hiervan zijn per gebruiker/afdeling/proces per maand. Dit herhaalt u voor elke component.

Kostprijzen en kostprijsberekeningen liggen volledig in het aandachtsgebied van de controller. Het mag dan ook verwacht worden dat de controller in dit proces een initiërende, sturende en bewakende rol heeft. Echter voor het samenstellen van de Stack is de technische kennis en inzicht van de ICT-afdeling onontbeerlijk. Succes komt echter alleen wanneer dit vanuit een samenwerkingsverband wordt aangevlogen.

De keuze voor doorbelasten van ICT-kosten is aan het hoger management. Vaststellen van de kostprijzen van ICT-diensten moet elke organisatie doen. De controller zal in dit proces een rol spelen als initiator, richting bepaler en bewaker van het proces.

Voor het vaststellen van de juiste kostprijs zijn drie elementen van belang: 

1. Kostprijs van alle ICT-componenten

2. Vaststellen van de Stacks

3. Doorrekenen van de verdeling van de kosten van gedeelde componenten naar gebruiker, afdeling en proces.

Nu u een handvat heeft voor het berekenen van de kostprijs van ICT uitgaven, behoeft dit geen hoofdpijndossier meer te zijn maar een stuurmiddel om tot betere financiële resultaten te komen.

Eerder verschenen de volgende gerelateerde artikelen op de website van Financieel Management

14-05-2013: Hoeveel ICT zit er in een flesje bier?

17-07-2013: Top 3 verborgen ICT-kosten

02-12-2013: 5 voorwaarden voor een succesvolle ICT-kostendoorbelasting

Wat zijn u ervaringen met het berekenen van de kostprijs van ICT uigaven? Laat een reactie achter onderaan of doe mee aan de discussie in de LinkedIn-groep Finance Professionals Netherlands.