Ken jij de ROAO van je applicatie landschap?
Heb je wel eens onderzocht hoe (in)efficiënt je applicatie landschap is? Nog los van de hoeveelheid ergernis en frustratie wat dat oplevert voor je medewerkers … je laat waarschijnlijk erg veel geld op de tafel liggen door je applicaties niet te optimaliseren. Gedurfde uitspraak? Misschien … Vooral ervaring van 25+ jaar in de keuken kijken bij organisaties en al die verloren euro’s van vergeten applicatie optimalisatie.
Applicatie optimalisatie klinkt misschien als een technische term, maar in essentie gaat het om iets heel simpels: het verbeteren van de digitale tools die we dagelijks gebruiken. Het doel? Een soepelere, snellere en minder frustrerende werkervaring voor iedereen binnen de organisatie. Én ... kostenbesparing. Want dat laatste … daar hebben we het veel te weinig over.
In deze blog duik ik dieper in de wereld van applicatie optimalisatie. Ik onderzoek hoe het de dagelijkse ergernissen van medewerkers kan verminderen, productiviteit kan verhogen en zelfs kan bijdragen aan een betere werk-privébalans. De financiële voordelen zijn groot en er zit veel winst zit in de verbeterde gebruikerservaring en medewerkerstevredenheid.
Facturen stroom kost extra FTE's
Voorbeeld: Bij een klant van ons met een digitale facturenstroom zit aan het eind een handmatige controle. Bij uitrol stonden de facturen snel op het scherm, maar in de loop van de tijd is het 60 seconden gaan duren tussen het opvragen van een factuur en het kunnen beoordelen van die factuur. Gebruikers wenden hier vanzelf aan. Wij deden onderzoek en vonden wat de oorzaak was van die 60 seconden wachttijd. Na het inzichtelijk maken van de wachttijd konden we de oorzaken aanpakken en de wachttijd zeer snel terugbrengen naar 20 seconden. De medewerkers die de factuur controles doen zijn een ergernis kwijt. Voor elke honderd facturen scheelt dat 4000 seconden ofwel ruim een uur werktijd, voor elke 800 facturen per dag kon een medewerker – we hebben het hier over een hele FTE - aan ander werk gezet worden.
Inloggen op BI omgeving kost minuten
Nog een voorbeeld uit onze brede praktijk: Een BI omgeving op een data warehouse heeft minuten nodig om gebruikers in te laten loggen. Ze kunnen letterlijk koffie gaan halen (dat doet men dus ook), opdrinken en net als ze overwegen om de volgend bakkie leut te halen is er eindelijk een menu met rapporten. Elke 2 uur is er een periode van ca 10 minuten dat het nóg trager is, twee keer zo traag als gedurende de rest van de dag. De ergernis bij de gebruikers laat zich raden. Met 250 gebruikers betekent elke 2 minuten wachten dat er 1 persoon, 1 FTE, een volle werkdag betaalt wordt voor … wachten. Anders gezegd, voor elke 2 minuten winst heb je een medewerker (een volle FTE) minder nodig. Dat is serieus geld!
Analyse van de omgeving door de medewerkers van Sciante geeft 3 oorzaken van de vertragingen:
- De BI software probeert bij het inloggen een groot deel van de database vast te cachen om later snel te zijn. Er wordt veel data opgehaald die door de medewerker nooit nodig heeft in zijn rapporten. Die extra data vertraagt het inloggen dus alleen maar.
- De virusscanner scant alle data die uit het data warehouse gelezen wordt. Scannen van data is niet nodig omdat data geen uitvoerbaar programma is. Virusscannen van data maakt het opvragen van data tientallen keren zo langzaam.
- Elke 2 uur vindt er een dataverversing plaats die ca 10 minuten duurt. Verversen van data trekt zo'n grote wissel op het data warehouse dat het nog maar half zo snel is.
Oplossen van die bottlenecks versnelt het inloggen naar 13 seconden. Tegelijkertijd is ook de gemiddelde render tijd van rapporten teruggebracht van 20 naar 2 seconden. Ergernis opgelost. Financiële winst is een half uur per medewerker per dag. Elke 2 minuten is een FTE, dus dat scheelt 15 FTE. Alleen op deze ene BI omgeving.
Het is níet normaal
Als inefficiënties lang genoeg duren dan wennen we er aan en gaan we ze zelfs normaal vinden. Maar wachten op IT is níet normaal. Niet nodig ook, en al helemaal niet gewenst. Als Google binnen een seconde pagina's aan zoekresultaten uit kan spugen en als ChatGPT en Claude binnen een paar seconden hele boekwerken kunnen produceren, waarom zou het dan normaal zijn jouw applicaties 10, 20 of zelfs 60 seconden nodig hebben om een rapport of een factuur te produceren? Ik zeg het vaker, en ik zeg het nog eens: software slijt. En als je het niet bijhoudt dan krijg je last van die slijtage. Google, OpenAI en Anthropic houden hun software bij en lossen slijtage op. Ze meten hoe snel hun toepassingen zijn en komen in actie als die snelheid terugloopt. En niet alleen door er limietloos hardware tegenaan te gooien, maar door hun software te optimaliseren. En denk nou niet, “ja luister eens Hugo, efficiëntie is op hun schaal heel belangrijk, wij zijn veel kleiner”. Bij hen betekent het soms verschil tussen winst en verlies, voortbestaan of verdwijnen. Voor de iets kleinere organisaties kan het het verschil tussen concurrerend zijn en de concurrentie voor laten gaan betekenen. Lijkt me toch een winstpunt!
De route naar efficiëntie
Als je een kaart of plattegrond hebt, dan moet je niet alleen weten waar je heen wilt, maar ook waar je nu bent. Anders kun je nooit je route bepalen. Ook applicatie optimalisatie begint met vaststellen waar je nu bent.
Bepaal eerst welke applicaties je in je landschap hebt, welke daarvan kritisch zijn voor je organisatie en hoeveel medewerkers daar gebruik van maken. Dan ga je meten hoe lang medewerkers moeten wachten en waar ze precies op moeten wachten. Dat geeft je een beeld of je een probleem hebt en hoe groot dat probleem precies is. Je kunt dan ook berekenen hoe groot de te verwachten winst is, in verminderde ergernis en in bespaarde kosten. Wij kunnen je in 1-4 uur per applicatie dat inzicht geven.
De volgende stap is het vinden van de oorzaken van de wachttijden en de oplossingen daarvoor. Dat doe je door (technische) metingen uit te voeren op problematische applicaties. Dat kan heel snel. Als het goed aangepakt wordt kun je met 1-2 weken de grootste pijnpunten boven water hebben en weten hoe ze aangepakt moeten worden. Wij hebben daar een speciale dienst voor die dit soort pijnpunten zonder gedoe razend snel boven water tilt. Zonder dat je zelf kennis van IT performance nodig hebt of moeilijke dashboards moet lezen. En met direct implementeerbare oplossingen als resultaat.
De laatste stap is natuurlijk het implementeren van de oplossingen. Als het een in huis gebouwde applicatie is, dan zet je je mensen aan het werk. Als het een gekochte of SAAS applicatie is, dan heb je vaak, maar zeker niet altijd, de leverancier nodig.
Op deze manier krijg je een hoge return on application optimization (ROAO).
Zorg dat de ergernis wegblijft
Als de applicatie die ooit na uitrol fluitend werkte, nu een ergernis is voor je medewerkers, dan is het tijd voor optimalisatie. Als je dat nu eenmalig oplost is de kans groot dat je binnen afzienbare tijd weer een probleemgeval hebt. En dat is het laatste wat je wil. Je kunt je investering in verbetering veilig stellen door de verbeterde applicatie continu, of op zijn minst maandelijks, te beoordelen op efficiëntie. Dat gaat veel sneller dan je wellicht denkt. Doe een nulmeting na de verbetering en blijf – geautomatiseerd natuurlijk - in de gaten houden of de applicatie op niveau blijft of verslechterd. Als de applicatie meetbaar maar nog niet merkbaar verslechtert, dan hebben je gebruikers er nog geen last van en kun je ingrijpen voor er een mopperend geroezemoes in je organisatie hoorbaar wordt.
Wij helpen je graag
Applicatie landschappen van vandaag en de onderliggende technologie is ingewikkeld. Ik help je graag om die horde stap voor stap te overwinnen. Dat begint met vrijblijvende Zoom afspraak van 15 minuten met mij. Na die afspraak weet je hoe je er achter komt waar je staat en waar je heen wilt. En of je onze hulp wilt bij het uitvoeren en het vervolg.