Ik heb een aantal artikelen geschreven over het rationaliseren van het applicatielandschap. In deze artikelen ging ik niet dieper in op de praktijk met voorbeelden. Daarom beschrijf ik hier een concrete case waarin duidelijk wordt wat ik met rationaliseren bedoel en waarom het best lastig is.
De case: Productiviteit
Bij een grote opdrachtgever kreeg ik de opdracht om productiviteit inzichtelijk te maken. Veel medewerkers werkten met een administratief systeem. Handelingen hadden een nummer en voor elke handeling stond het aantal minuten dat er over die handeling gedaan mocht worden. Dat lag in waardes tussen de 2 en 20 minuten. Per dag had een medewerker dus een aantal handelingen verricht en door dat te vermenigvuldigen met de normtijd kon je uitrekenen hoeveel werk een medewerker had verricht. Voor de berekening van productiviteit was dit niet genoeg. De input van het werkelijke aantal gewerkte uren was nodig om te kijken hoe de werkelijke productie was. Mensen hadden meer taken en variabele werktijden. Als iemand volgens de norm 6 uur had gewerkt, maar in de werkelijkheid 8 uur was beziggeweest, lag diens productiviteit dus onder de norm.
Overigens is dit een vereenvoudiging van de werkelijke opdracht, ik houd me aan het noodzakelijke voor dit stuk.
Om de berekening te kunnen maken had dus ik de werkelijk gewerkte uren nodig. Deze konden (met enige moeite en autorisatie) uit een centraal managementsysteem verkregen worden. Daar zaten echter twee nadelen aan: De output was op weekniveau, en er was geen onderverdeling in het soort uren (administratieve handelingen en al het andere). Als iemand een vergadering of studiedag had of telefonische werkzaamheden verrichtte, dan kon dit niet herleid worden. Daarmee werd een berekening waardeloos.
Uitwerking van de case
Voor deze opdracht heb ik een tool ontwikkeld. Deze las dagelijkse de afgewerkte handelingen af van medewerkers en controleerde die op veranderingen in de normtijden. Nu had ik nog de input nodig van de medewerkers die aan konden geven hoeveel uur ze op het administratieve systeem hadden gewerkt. Om dit zo eenvoudig mogelijk te maken konden roosters eenvoudig ingevoerd worden. Deze werden naar een planning in tijd geëxtrapoleerd. Alleen de afwijkingen invoeren volstond.
Nu was de output zuiver als mensen op tijd hun uren hadden ingevoerd. Diverse rapporten gaven inzicht op medewerker- en afdelingsniveau, afgezet tegen een periode van tijd.
Door teamleiders aan te sturen kon de tool per afdeling worden uitgerold.
De teamleiders waren blij omdat ze nu ook op getallen konden sturen, de opdrachtgever omdat een probleem was opgelost.
Als je dit echter bekijkt in het kader van rationaliseren, was dit helemaal niet goed. Het applicatielandschap was namelijk ingewikkelder geworden. Bij veranderingen had dit mogelijk ook impact op de tool en mensen moesten weer extra handelingen verrichten. Bovendien heeft een tool ook onderhoud nodig als iets niet werkt of als er een fout hersteld moet worden. De it-kosten zijn dus toegenomen.
Hoe de case uitgewerkt had moeten worden
Allereerst moest besloten worden of het een probleem was dat uren op weekniveau binnenkwamen, zoals beschreven in de case. Als dit geen probleem was, konden de uren geautomatiseerd worden ingelezen. Ik denk dat het geen probleem was. Je stuurt niet op wat er op een dag is gebeurd. Een slechte dag wordt misschien weer gecompenseerd met een goede dag later in de week. Je wilt niet sturen op microniveau, maar op trends. Welke afdeling zit onder de norm, en daarna: welke medewerker zit onder de norm? In mijn ogen gebeurt dit niet op dagniveau.
Het eerste probleem dat er alleen een geautomatiseerde input op weekniveau beschikbaar was lijkt dus niet het grote probleem te zijn. De specificatie van de uren was dat wel. Door te kijken wat er mogelijk was aan de invoerkant, namelijk dat uren beter gespecificeerd moeten worden bij invoer, zou dit opgelost kunnen worden. Ik had kort onderzoek gedaan en zag dat er wel wat meer mis was met de invoer. Zo boekte de ene afdeling reistijdcompensatie netjes, bij de andere afdeling werd alleen het totaal ingevoerd. Hier zat dus al een vervuiling die organisatorisch opgelost kon worden. Ook dat is rationaliseren: processen uniform maken levert economisch voordeel op.
Door dus de wijziging in de manier van registreren te veranderen (een organisatorische uitdaging) zou de berekening geautomatiseerd kunnen verlopen. Dit zou het systeem veel eenvoudiger maken. Wellicht is er dan helemaal geen tool nodig en kan het met slimme rapportages worden uitgevoerd.
Deze manier van uitvoeren is wel lastiger, omdat meer mensen op één lijn moesten komen en er meer mensen bij het proces betrokken zijn. Er was dus minder input van techniek nodig en meer input van de organisatie.
Conclusie
De case is in mijn ogen een goed voorbeeld over de subtiliteit van rationalisatie en het nemen van goede, maar moeilijke beslissingen. De case was goed uitgewerkt en heeft geleid tot een goed resultaat. De gekozen oplossing was dus helemaal niet fout en mogelijk de enige mogelijkheid. Maar op de langere termijn en met een visie van vereenvoudiging was de case niet goed uitgewerkt. De investering lag nu meer in techniek, terwijl deze in de organisatie had moeten zitten. Dit is in mijn ogen een heel goed voorbeeld hoe het er in de praktijk aan toe gaat. Er wordt een technische oplossing gezocht terwijl een voornamelijk organisatorische oplossing had kunnen volstaan. En als je aan een techneut of leverancier een probleem beschrijft, zal deze in de regel zoeken naar een technische oplossing, omdat dit namelijk geld oplevert en met de minste weerstand kan worden uitgevoerd. De gerationaliseerde oplossing zou de leverancier overbodig maken, en als de trend doorzet voor omzetverlies zorgen. Maar dan moet er wel goed leiderschap aanwezig zijn.
Rationaliseren is zeker niet (in alle gevallen) slecht voor een leverancier, maar dit voorbeeld illustreert wel wat ik bedoel met rationaliseren en dat dit meer vergt van een organisatie dan een besteding van geld.
Wat laatste gedachten
Uiteraard is niet alles zwart-wit. In het beschreven geval was rationaliseren misschien niet goed mogelijk geweest. Een andere oplossing was wellicht dat de administratieve software zou registreren wanneer een gebruiker inlogt en uitlogt, maar dan heb je weer de mogelijke afwijking dat iemand niet netjes afsluit voordat hij of zij een vergadering in gaat. Punt blijft wel dat als je een ontwikkelaar vraagt naar een oplossing, deze vaak gevonden wordt in het maken van een tool.
Het rationaliseren van productiviteit? Zoals het hier wordt uitgelegd lijkt het eerder te gaan over controle: ik betaal je acht uur, maar werk je wel acht uur en hoe houd ik dat in de gaten?
Vraag is: wat wil je bereiken met rationalisatie? Ik zou denken dat je wilt bereiken dat uit verschillende werkwijzen de meest effectieve werkwijze wordt gedestilleerd. Ofwel: je zoekt naar best practices. Maar dan niet de best practises van andere bedrijven – gegoten in een framework of “standaard”. Die doen het niet altijd even goed in jouw omgeving en cultuur. Een tool, hulpmiddel of aanpak vinden die je helpt om je organisatie te verbeteren en de kennis en kunde van jouw eigen medewerkers effectiever in te zetten t.b.v. verhoogde productiviteit, dat lijkt mij, binnen de context van één bedrijf een interessante uitdaging. En dat dit dan op natuurlijk wijze plaatsvindt, dus zonder dat mensen onevenredige prestatiedruk ervaren of het idee of gevoel krijgen dat ze daar(nog) harder voor moeten werken. Maar ja, dat laatste zal wel niet rationeel zijn.
Dag HK (dat zijn mijn initialen ook)
Het gaat hier niet om de opdracht. Het gaat om de manier waarop de opdracht is uitgevoerd. Namelijk op traditionele wijze; er is een vraag en een technisch antwoord.
Wellicht een betere keuze was geweest om te kijken naar wat er al is en of dat niet anders gebruikt kan worden om de vraag te beantwoorden.
Hoe meer techniek, hoe hoger de kosten.
Rationaliseren = economischer maken
Door organisatorische aanpassingen door te voeren (en hier is leiderschap voor nodig) kun je met minder techniek hetzelfde blijven doen.
Kosten van automatisering blijven daardoor lager, de organisatie wendbaarder en dat is een goed ding.
Het inzetten van cloud computing kan dit nog eens heel erg versterken.
Dat zou de essentie van het artikel moeten zijn. Misschien had ik het beter moeten toelichten. Bedankt voor je reactie!