Ik heb een aantal artikelen geschreven over het rationaliseren van het applicatie landschap. 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 werkte met een administratief systeem. Handelingen hadden een nummer en voor elke handeling stond het aantal minuten hoelang 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 werkelijk 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 bezig geweest, dan was 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 dus te kunnen maken had ik de werkelijk gewerkte uren nodig. Deze konden (met enige moeite en autorisatie) uit een centraal management systeem 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 vergadering, studiedag 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 uit van medewerkers en controleerde op veranderingen in de norm tijden. 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 afdeling niveau afgezet tegen een periode van tijd.
Door teamleiders aan te sturen kon de tool per afdeling worden uitgerold.
Teamleiders blij omdat ze nu ook op getallen konden sturen, opdrachtgever blij omdat een probleem was opgelost.
Alleen als je dit 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 en een tool heeft 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 was een besluit nodig of het een probleem was dat uren op week niveau binnen kwamen 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, en 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 en 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.