Het kosten effectiviteit model
Het kosten effectiviteit model is bedoeld om gestructureerd toe te werken naar een situatie waarin u alleen voor die IT middelen betaalt die u ook daadwerkelijk nodig heeft. Veelal zijn er een viertal stappen nodig om dit stadium te bereiken. In de eerste stap wordt in beeld gebracht waarvoor u betaald. In stap 2 wordt de vergelijking gemaakt met wat er oorspronkelijk gepland was. In stap 3 wordt het daadwerkelijke gebruik gemeten. Tot slot wordt in stap 4 nog eens gekeken wat de klant nu daadwerkelijk nodig heeft.
IT kosten effectiviteitmodel
Stap 1. Waar betaal je voor
De eerste stap betreft het creëren van transparantie in de huidige facturatie van leveranciers.
Infrastructuur
Vooral bedrijven die het beheer en onderhoud van de IT infrastructuur hebben ge-outsourced hebben vaak moeite om te bepalen waarvoor zij betalen. Dit wordt veelal veroorzaakt doordat bij de outsourcing het beheer van de Configuration Management Database (CMDB) naar de outsourcingspartner is overgegaan. Als hierbij geen periodieke onafhankelijke controles zijn ingebouwd en/of als het contract management onvoldoende sterk is dit de bron van te hoge kosten en te lage kwaliteit. Voorbeelden hiervan zijn:
• Er is geen duidelijke relatie tussen servicelevels en omgevingen doordat de door de leverancier aangeleverde informatie onvoldoende specifiek is. Resultaat is dat onbedoeld voor 7×24 ondersteuning wordt betaald op een test of ontwikkel omgeving.
• Er staan teveel items in de CMDB. De contracteigenaar moet nadrukkelijk sturen op het verwijderen van items uit de CMDB. Veelal wordt ieder afzonderlijk item in de CMDB door de leverancier gefactureerd. Indien u niet aangeeft dat bepaalde servers of databases verwijdert dienen te worden blijven deze tot in lengte van dagen in de facturatie zitten (dezelfde problematiek doet zich ook veelvuldig voor bij het beheer van werkplekken).
• Er staan te weinig items in de CMDB. Het kan ook voorkomen dat een leverancier vergeet om items in de CMDB op te nemen. Dit heeft als voordeel dat de directe rekening lager is dan dat deze zou moeten zijn, maar als nadeel heeft dat als er een incident is het zoeken naar de oorzaak aanzienlijk wordt bemoeilijkt en weleens tot een veelvoud aan kosten kan leiden.
Applicatiebeheer
Ook hier geldt dat bij outsouricngscontracten veelal door procurement een megadeal wordt bereikt door een fixed price contract af te sluiten voor het beheren en ontwikkelen van applicaties. Een fixed price deal kan in een bepaald stadium erg voordelig zijn, maar heeft grote nadelen in tijden van krimp. Het is immers niet meer duidelijk wat de leverancier voor dit geld doet. Zaak is om voldoende informatie afspraken met een leverancier te maken over verantwoording van uren en inzichten (met name handboeken), zodat bij contract verlenging of nieuwe aanbesteding een betere vraag kan worden gesteld. In een krimpende of zich snel ontwikkelende omgeving kan het op lange termijn zelfs veel voordeliger zijn om contracten meer variabele elementen te geven. Hiervoor dient dan wel een hogere prijs te worden betaald, maar doordat deze contracten sneller afgeschaald kunnen worden zijn dit soort contracten op langere termijn veelal voordeliger.
Stap 2. Wat was er oorspronkelijk gepland
De tweede stap is om te kijken wat er oorspronkelijk was gepland voor een applicatie.
Infrastructuur
Alvorens wordt begonnen met het ontwikkelen en/of installeren van een applicatie wordt er veelal door IT architecten een design gemaakt. In dit design zijn gegevens opgenomen over het gebruik van omgevingen, benodigde rekencapaciteit, databases, platforms en connecties met andere applicaties. Dit is de basis om de hardware voor de applicatie in te richten. Wanneer een applicatie (deels) zelf wordt ontwikkeld wordt er in projectfase vaak additionele hardware en/of databases neergezet teneinde sneller en met meer mensen te kunnen ontwikkelen en testen. Na afloop van het project wordt deze additionele infrastructuur vaak niet opgeruimd.
Applicatiebeheer
Veel bedrijven maken voor hun IT business cases. Hierin zijn een aantal verwachtingen opgenomen over de terugkerende kosten. Het linken van terugkerende kosten aan de oorspronkelijke businesscase levert vaak al veel inzicht op. Ook de meer technische informatie kan leiden tot besparingsopties. Bijvoorbeeld als er veel meer maatwerk is gebouwd dan dat er was gebudgetteerd zal de beheerlast stijgen. Het belonen van het terugdringen van het maatwerk in een beheer contract kan dan op langere termijn een groot positief financieel effect hebben.
Stap 3. Wat wordt er gebruikt
De derde stap meet gebruiksgegevens. Het geplande gebruik en daadwerkelijke gebruik lopen nogal eens uit elkaar doordat gebruik te optimistisch wordt geschat.
Infrastructuur
In de architectuur van een applicatie wordt uitgegaan van bepaalde uitgangspunten voor gebruik. Dit heeft betrekking op aantallen gebruikers, aantallen transacties, de hoeveelheid data die moet worden opgeslagen, etc. Bij het ontwerpen van de infrastructuur wordt deze aantallen vaak veilig geschat. Dat betekent dat bij meting zomaar kan blijken dat meer dan de helft van de beschikbare rekencapaciteit niet wordt gebruikt of dat de toegewezen hoeveelheid terabytes opslagruimte de feitelijk benodigde opslagruimte ver overstijgt. Resultaat van een dergelijke meting is dat er behoorlijk kan worden afgeschaald.
Applicatiebeheer
Voor applicatiebeheer geldt eigenlijk eenzelfde verhaal als hierboven beschreven. Toch is de variantie hier groter. Afhankelijk van de cultuur van de organisatie zie je dat in de ene organisatie het aantal gebruikers (en dus het aantal benodigde licenties) wordt overschat, terwijl dit in de andere organisatie structureel het gebruik te conservatief wordt geschat. In het ene geval betekent dit dat er jaarlijks teveel aan licentiekosten wordt betaald, in het andere geval te weinig en hangt het zwaard van Damocles voor wat betreft incompliancy claims als een zwaard boven de markt.
In applicatiebeheer contracten wordt daarnaast veelal geen onderscheid gemaakt in de feitelijke beheer taken en het doen van changes. Tevens is er in beheer contracten geen aandacht voor de relaties tussen problems, incidenten en beheerlast. De praktijk laat zien dat als het aantal incidenten afneemt de beheerlast daalt. De twee grootste veroorzakers van incidenten zijn changes/projecten en slecht opgeleide key users. Door aandacht te geven aan de goede variabelen kan de applicatiebeheer last fors worden gereduceerd. In het meest extreme geval van een zeer goed werkend Agile team zou je kunnen stellen dat het applicatiebeheer een overbodige activiteit wordt.
Stap 4. Wat is er nodig
De vierde stap betreft de analyse van de functionaliteit in het applicatielandschap. Een applicatie wordt vaak om een bepaalde reden aangeschaft, maar biedt vaak meer functionaliteit dan waarvoor deze wordt gekocht.
Infrastructuur
Binnen de infrastructuur is er vaak geen actief beleid in het opschonen en archiveren van data. Conform de archiefwet moet data gedurende langere tijd bewaard worden. Echter, de gebruikers hebben deze informatie niet voor het dagelijks werk nodig. Het archiveren van de betreffende data kan dan tot aanzienlijke kostenbesparingen leiden, omdat dit de systeembelasting verminderd (zoek queries worden korter omdat de database kleiner is) en zullen leiden tot verlaging van het SAN verbruik.
Applicatiebeheer
Vooral bij bedrijven die veel met fusies en overnames te maken hebben gehad komt het regelmatig voor dat er applicaties in het landschap staan met min of meer dezelfde functionaliteit. Het in kaart brengen van benodigde functionaliteit en de beschikbare functionaliteit kan in dit geval tot opmerkelijke resultaten leiden. Door slim te kijken kan vaak een groot aantal applicaties worden uitgezet. Een bijkomend voordeel hiervan is dat bij het ontwikkelen van BI-systemen er minder applicaties ontsloten hoeven te worden en dat dus ook op dit gebied fors bespaard kan worden en de “time-to-market” verkort.
Het koppelen van informatiestromen uit het “kosten effectiviteit model” aan die van het “IT toegevoegde waarde model” heeft nog additionele voordelen. Zo wordt de gebruiker van de IT middelen duidelijk wat de kosten van de gevraagde functionaliteit zijn (dit kan leiden tot andere afwegingen). Daarnaast krijgt de gebruiker meer mogelijkheden om een afweging te maken tussen hogere performance met hogere kosten of een lagere performance tegen lagere kosten. Hierover later meer.