Blog
De verborgen productiviteitskiller: hoe groei je ondanks personeelstekort?
Weet je wat één van je grootste productiviteitsremmers is? Slechte software. Slechte software stagneert economische groei. Dat hebben niet alle bedrijven door maar het is makkelijk aantoonbaar. Én op te lossen.
Omdat je personeel niet door kan werken, onnodig moet wachten op software, gaat er kostbare tijd verloren. In 2012 werd nog ¼ werkdag per week verspild aan wachten op applicaties, in 2023 was dat al ½ tot een hele werkdag per week. Per medewerker dus. En hoe meer je digitaliseert, hoe erger het wordt. Dat was nou net niet jouw bedoeling met digitaliseren.
Je kunt met dezelfde groep medewerkers dus tot wel 25% productiever worden. Zonder dat het je een cent extra loon kost. Of (iets meer dan wat) cent(en) wervingskosten. En zonder dat je je medewerkers het vuur aan de schenen hoeft te leggen om harder te werken.
Waarom de kwaliteit van software al jaren terug loopt
De software die je gebruikt is te langzaam, te duur en te complex. Dat is een vrij heftige uitspraak maar … het is helaas wel waar. Goed nieuws is er ook: het kan beter. Veel beter.
Ergens in de jaren 90 is de IT-industrie programmeerkosten en time-to-market belangrijker gaan vinden dan kwaliteit. Toen was dat een soort van logische beslissing; hardware werd steeds goedkoper en de vraag naar IT-personeel nam snel toe waardoor salarissen snel opliepen.
De sterke vraag naar IT-personeel zorgde er ook voor dat je makkelijker aan een baan in de IT kwam zelfs zonder IT-opleiding. Met minder goede kwalificaties dus. Omscholingstrajecten waren aan de orde van de dag. Daar kwamen zeker goede - en meer dan soms uitstekende - programmeurs uit, maar het grootste deel van de uitstroom was middelmatig. Veel mensen lieten zich omscholen omdat er in hun droom beroep geen werk was en in de IT wel.
Inmiddels zijn we, 30 jaar later, volkomen doorgeslagen. De kosten van software-bouw zijn leidend, niet meer de kwaliteit. Tot een bepaald punt is het zinvol om de kosten in de hand te houden. Maar als er balkons van een flatgebouw af vallen omdat de balkons goedkoper konden dan accepteren we dat niet. Waarom accepteren we hetzelfde in de IT dan wel? Ja maar Hugo, een balkon gaat over een levensbedreigende situatie. Klopt, je hebt helemaal gelijk. In de IT is het gelukkig niet altijd levensbedreigend alhoewel het ook daar tot slachtoffers kan leiden, denk aan de Boeing 737 Max – software die een ramp moest voorkomen veroorzaakte er juist één.
24.000.000 keer zo snel
Laten we teruggaan naar applicatie-snelheid, of liever, naar een gebrek ervan. Bij applicatie-snelheid gaat het niet om een paar procent, of om enkele tientallen procenten. Een voorbeeld: een van onze klanten had een query in zijn datawarehouse die een groot deel van de ochtendverwerking in beslag nam. Uren draaitijd waar de gebruikers op moesten wachten. Die query is met een factor 24.000.000 versneld en opereert nu binnen een seconde. Het opladen van het data warehouse is nu uren eerder klaar. Onze klant dacht dat het datawarehouse wel zo ongeveer optimaal was, want dat hadden ze hen verteld ...
Een ander voorbeeld: een verhuursysteem dat als SAAS afgenomen wordt. Een misconfiguratie in CloudFlare zorgt ervoor dat niet alleen de veranderde pagina-componenten, maar álle pagina-componenten elke keer overgestuurd worden. Voor de technische mensen, er was geen enkele caching. Oplossen van de misconfiguratie decimeerde het verkeer tussen de SAAS-omgeving en de browser van de medewerkers. Tientallen secondes per pagina worden enkele secondes. Elk scherm opnieuw. Dat scheelt een uur per medewerker per dag. Ga je uit van gemiddeld 260 werkdagen per jaar, dan bespaart dit bedrijf 260 uur per medewerker per jaar wat ca 30 werkdagen is. Je leest het goed, 6 werkwerken, inderdaad 30 werkdagen.
Het geld hoost de ramen uit – en bij jou?
Mensen wennen aan wachten. Veel mensen staan elke ochtend weer in dezelfde file. Die steeds een beetje langer wordt. Op dezelfde manier wennen je medewerkers aan een applicatie die steeds een beetje langzamer wordt. En omdat ze al jaren gewend zijn om met trage software te werken denkt iedereen dat het een soort van zo hoort. Met waarschijnlijk het gevolg dat je medewerkers traagheid niet - of niet meer - melden. En dat jij dus niet weet dat er een probleem is. Of wat de oorzaak is. En dat het op te lossen is. En hoe dan. Bij eigenlijk iedere klant waar we aan tafel komen druipt de frustratie eraf maar is de verrassing wanneer we het oplossen des te groter. Lossen we het vrijwel altijd op? Nee. We lossen het ALTIJD op.
Het is niet de verantwoordelijkheid van de IT-afdeling
Je IT-afdeling is verantwoordelijk voor goed werkende, veilige infrastructuur. Voor snelle netwerken en snelle servers. Maar niet voor snelle applicaties. Dat is de verantwoordelijkheid van de software-bouwer. Ruim 90% van de bottlenecks die wij in applicaties vinden wordt veroorzaakt door slecht geschreven applicaties. Het ligt bijna nooit aan de IT-infrastructuur. Als het al in de infrastructuur terug te vinden is dan ligt het meestal aan verkeerd gebruik van de infrastructuur door de applicatie. Dat betekent niet dat slechte software niet met een betere infrastructuur op te lossen is. Zeker als het om tijdelijke oplossingen gaat die de boel draaiend houden terwijl het echte probleem opgelost wordt. Het oplossen van dit soort ‘gedoe’ daar maak je meer mensen mee blij dan je denkt!
Meer hardware dan maar?
De standaard oplossing wanneer een applicatie zo traag geworden is dat het niet meer te ontkennen valt, is hardware bijplaatsen. Of meer cloud-resources als je al gemigreerd bent. Los van de kosten daarvan - zeker in de cloud - lost meer hardware het probleem vaak niet op. Of maar tijdelijk. Veel van de problemen zitten in de schaalbaarheid van de software. Software die voor 10 of zelfs 100 gebruikers goed werkt zal bij 200 of 500 gebruikers met 100% zekerheid wel een keer omvallen. Omdat de architectuur van de software de schaal niet aan kan.
De meeste software-bouwers bouwen op functionaliteit, niet op snelheid en zeker niet op schaalbaarheid. Ze denken onvoldoende na over wat er nodig is om de software met 100 gelijktijdige gebruikers ook nog goed te laten functioneren. En zeker niet met 500 of 1000. En ze hebben ook niet de mogelijkheid om op die schaal te kunnen testen. Dus bouwen en testen ze voor een veel kleinere schaal. Hun software werkt misschien wel op jouw schaal, maar verspilt veel tijd van je medewerkers omdat de optimalisatie voor jouw schaal ontbreekt.
Hoe ontdek ik of ik dit probleem heb?
De kans dat je dit probleem wél hebt is groter dan dat je het niet hebt. Dat weet ik uit ervaring. De enige manier om objectief te weten hoeveel tijd je medewerkers kwijt zijn aan kostbaar wachten op applicaties is het uitvoeren van een meting. Dat gaat razendsnel. Je weet dan niet alleen waar je een probleem hebt, maar ook hoe groot het is en in welke richting de oplossing ligt. Je weet dus hoe je je medewerkers zonder extra loonkosten productiever maakt. En blijer.
Maak vrijblijvend een afspraak met mij en binnen een kwartier heb je de oplossing in handen.