Het hebben en beheren van software kost veel geld. Vooral als dit maatwerk is of maatwerk op standaard software. Dit kom ik zeer veel tegen in de praktijk en de werkelijke kosten hiervan zijn nog hoger dan een optelling van de uren die besteed worden aan externe consultants, licentiekosten en kosten die gepaard gaan met het upgraden van deze niet meer zo standaard software. Deze kosten stijgen nog sneller als de software al langer mee gaat. Een ander fenomeen is dat er door de tijd steeds meer software bij komt.
Naast al deze zichtbare kosten zijn er ook onzichtbare kosten die niet direct gekoppeld worden aan het hebben beheren en onderhouden van deze software. Dit zijn kosten zoals de uren die vanuit de eigen organisatie besteedt worden aan deze software, bijvoorbeeld die van de IT afdeling. Maar de vergaderingen, testen en overleg uren van niet IT mensen over de software problematiek zijn per definitie onzichtbaar en worden niet toegekend aan de total cost of ownership (TCO).
Hoe groter het applicatielandschap hoe meer verborgen kosten er zijn en de grootte is nauwelijks vast te stellen. Vraag er eens naar binnen de organisatie. Kansen zijn zeer groot dat mijn stelling direct bewezen wordt. Klopt dit niet? Gefeliciteerd, u bent echt de eerste!
Hoe kunnen die kosten verlaagd worden? Hoe kan er op software bespaard worden?
Dit is geen gemakkelijke taak en het inhuren van een ervaringsdeskundige is een goede beslissing (hint: check de schrijver van dit artikel).
Een belangrijke eerste stap is bewustwording. Als de kosten inzichtelijk worden gemaakt kan de potentie van de besparing gedimensioneerd worden. Als deze bewustwording er is komt stap 2: Het rationaliseren van het applicatielandschap; of in mensen taal economischer maken.
Een aantal acties die onder rationaliseren vallen zijn: Pensioneren, Consolideren, vervangen, verbouwen, bevriezen, virtualiseren, ontsluiten, et cetera.
Voor elke voorbeeld geldt dat sommige manieren veel beter zijn dan andere manieren en foute toepassing leidt tot meer kosten. Onderschat interne politiek en gebrek aan consensus niet.
Praktische voorbeelden van rationaliseren zijn dat aanvragen op het gebied van aanpassingen scherp onder de loep genomen worden en dat een organisatorische wijziging verkozen wordt boven een software aanpassing. Dat er serieus gekeken wordt om een applicatie met pensioen te sturen of te verplaatsen naar een gevirtualiseerde server. Uiteindelijk wil je het applicatie landschap eenvoudiger maken en zoveel mogelijk aan laten sluiten op standaard software. Als een ander bedrijf in dezelfde branche het met standaard software kan, waarom uw organisatie niet?
Hoe slanker de software, hoe minder er over gesproken hoeft te worden, hoe minder incidenten plaats vinden en hoe makkelijker de software mee groeit met de nieuwe ontwikkelingen. Less is more. En hoe minder er is om rekening mee te houden hoe flexibeler uw organisatie wordt.