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 is raadzaam om dit samen met een ervaringsdeskundige te doen.
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 twee: 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.
Als de kosten inzichtelijk worden gemaakt kan de potentie van de besparing gedimensioneerd worden. Als deze bewustwording er is komt stap twee: Het rationaliseren van het applicatielandschap.
Je moet weten hoeveel die ICT zooi kost en kan
dan bepalen of je misschien ergens op kan besparen.
Briljant idee, inhuren die consultants, heb je wat aan 😉
De eerste helft van het verhaal is zeer herkenbaar
Maar wat ik mis is hoe dit te voorkomen.
Hoe vaak komt het niet voor dat één of andere groenteboer, alias SLA-manager, denkt te weten hoe de mensen in zijn afdeling werken en op basis daarvan afspraken maakt.
Dito voor allerhande adviesorganen voor de applicaties die gebruikt worden binnen een bedrijf. Men denkt te weten hoe de mensen werken, terwijl ze zelden of nooit met die mensen praten.
Gevolg: applicaties worden geïmplementeerd of doorgedrukt op basis van oneigenlijke aannames; de gebruikers zijn ontevreden; er is geen geld meer voor aanpassingen aan de applicaties, dus …. zie inleiding van het artikel.
PaVaKe, mooie reactie en wat je schrijft gebeurt ook vaak. Vitamine A, ofwel Aandacht, is iets wat er bij veel organisaties ontbreekt. Gewoon even met wat mensen zitten die het uiteindelijk doen levert al zeer veel zinvolle informatie op.
SLA’s hebben niets met kosten te maken en zorgen voor schijnveiligheid. Beschikbaarheid, performance en dergelijke gaat dit stukje niet over, hoewel deze ook leiden tot verborgen kosten.
Voorkomen van uitwassen is alleen mogelijk met sterk leiderschap, visie en bewustwording welke ondergebracht is in een stukje governance. Dat heeft weer te maken met volwassenheidstadia. Het gevaar daarvan is weer dat je de mate van volwassenheid volstrekt verkeerd kan uitoveren waardoor het leidt tot extra kosten in plaats van besparingen.
Wat ik zelf veel merk als ik de standaard in het oog houdt is dat het heel veel pijn en moeite kost. Soms denken mensen dat je star bent en geen consessies wilt doen, de winst op korte termijn wordt namelijk wel aangetoond. Alleen die “verbeteringen” op korte termijn leiden tot meer kosten op lange termijn.
Zachte meesters maken stinkende wonden is in dit verband een sterk gezegde.
Inderdaad: flexibiliteit wordt maar al te vaak gezocht in uitbreiding van keuzemogelijkheden. Hoe verhelderend hier bevestigd te krijgen dat flexibiliteit (in de geschetste context) eerder te vinden is in het beperken van die keuze. Maar let op: flexibiliteit zit daarbij vooral in het maken van de juiste keuze. Het maken van de juiste keuze doe je op basis van commitment. Van onderaf als het even kan en van business naar (IT) oplossing. Eerst organiseren, dan automatiseren. Maar vanaf dan is het ook: stick to the plan. En daar is dat leiderschap weer voor nodig (dat plotseling veel makkelijker wordt vanwege dat commitment).
Wat kan het ICT leven toch mooi zijn…
Helaas denken veel zittende ICT managers dat ze belangrijker zijn naarmate de ICT omgeving ingewikkelder is. Hoe ga je daar mee om, Henri?
Je leest hier zo vaak leuke verhalen over besparen dit en besparen dat. Maar als het over kwaliteit gaat dan lees je daar bijzonder weinig over. Dat mis ik hier ook wel een beetje. Vooral als het om maatwerk gaat is kwaliteit erg belangrijk. Wat dat betreft heb ik genoeg rampprojecten van dichtbij gezien en een paar daarvan helaas genoeg moeten opruimen en dat was idd een lange en dure klus. Vaak is de reden van die puinhoop het feit dat de partij die het gemaakt heeft te weinig tijd had om iets duurzaam te maken en/of ze onervaren mensen erop hebben gezet. En ik durf ook wel te beweren dat er soms met opzet zeer moeilijk te onderhouden maatwerk wordt afgeleverd en ze zeker weten dat zij de support hierop mogen leveren.
Als je wilt dat maatwerk goed wordt uitgevoerd laat het controleren door de directe concurrent van de partij die het maatwerk uitvoert. Die mag er dan op schieten en bij duidelijk aantoonbare gebreken mogen zij de uiteindelijke support gaan leveren. Komen ze er niet uit dan gaat het support naar een derde partij.
@Peter, als besparen ten koste gaat van de kwaliteit is het geen besparen. In het geval van rationaliseren zal de kwaliteit toenemen omdat je minder elementen hebben die de kwaliteit negatief beinvloeden.
Kwaliteit in IT mist vaak omdat de mensen die erover gaan eigenlijk niet geintresseerd zijn in de techniek. technische mensen zijn vaak niet zo geintreseerd in de business (lekker generaliseren), dit brengt risico’s met zich mee. Dit stukje is vooral opinie. Echt in details duiken is vaak maar voor een klein groepje mensen interessant.
@hk: Hoe ga je om met een managers die zich belangrijker voelen als de IT omgeving ingewikkelder wordt? Ik zeg: belonen voor rationalisaties. Dus belonen als het nodige ICT budget krimpt. Stimuleren om IT simpeler te maken.