Gestandaardiseerde processen vs creativiteit van de medewerker

8 minuten leestijd

De beloftes van automatisering

“29% verhoging van productiviteit bij gebruik van Salesforce!” (Salesforce op 10 juli 2023), “NetSuite vereenvoudigt het proces van het verplaatsen van goederen of materialen door een uitgebreide toeleveringsketen.” (Netsuite op 10 juli 2023). “Profiteer van bewezen bedrijfsprocessen voor jouw branche: realiseer meer winst… werk beter samen… blijf de marges verbeteren met intelligente automatisering in al je end-to-end operationele processen” (SAP op 10 juli 2023).

Met dit soort uitspraken, wie wil dat nu niet? Automatisering wordt door veel bedrijven gezien als de oplossing en de IT-wereld blijft groeien. Maar levert dit altijd op wat er wordt gehoopt? Is het altijd verstandig om een standaard product aan te schaffen? In dit blog kijken we naar waar automatisering mee begon en welke gedachten hieraan ten grondslag liggen. Is dit dan altijd de beste oplossing?

“The division of labour”

Het implementeren van software lijkt vaak een doel op zich, en soms verliezen we uit het oog waarom we automatiseren en waarom we dit op deze manier doen. Al in 1776 beschreef Adam Smith in zijn boek The Wealth of Nations dat het samenwerken met iemand anders en het vinden van een andere “verdeling van arbeid” veel efficiënter was. Smith legde uit dat we daarmee niet alles meer zelf doen, maar dat we het werk van het bakken van brood en het maken van vlees verdeeld hebben over verschillende mensen. Doordat zij zich specialiseerden, konden ze meer produceren voor minder. Vanaf de industriële revolutie is deze manier van denken over bedrijfsprocessen gemeengoed. Zolang we het slim verdelen, kunnen we meer output genereren en de kosten per eenheid verlagen. Frederick Winslow Taylor ging nog een stap verder in zijn “Principles of Scientific Management” uit 1911. Hij betoogde dat het toepassen van tijd- en bewegingsstudies kon leiden tot het vinden van één beste en superieure werkwijze. Het was niet alleen mogelijk om het werk beter te verdelen, het was zelfs mogelijk om de superieure werkwijze te vinden waardoor iedereen individueel de hoogste output kon halen. Deze filosofie is tot op de dag van vandaag dominant, vooral in het ontwikkelen van software die bedrijfsprocessen automatiseert. Bij het automatiseren van bedrijfsprocessen is het gebruikelijk om eerst door middel van bedrijfsanalyse een processtandaard te vinden en deze vervolgens te automatiseren. Het trainen van het personeel in deze enkele werkwijze leidt tot efficiëntie. Maar klopt dit wel? Is deze aanpak werkelijk overal toepasbaar?

“One man draws out the wire, another straights it, a third cuts it, a fourth points it, a fifth grinds it at the top for receiving the head;… Those persons, therefore, could make upwards of forty-eight thousand pins in a day. But if they had all wrought independently, they certainly could not each of them have made twenty, perhaps not one pin in a day…” – Adam Smith in The Wealth of Nations

Het ultieme bedrijfsproces

In veel software-implementaties heb ik het gezien. Het bedrijf groeit, de kosten lopen op en om schaalbaar te worden wordt een centraal informatiesysteem geïmplementeerd. Soms is het zelfs het middel om tot integratie van bedrijfsonderdelen te komen. Immers, als we ervoor zorgen dat iedereen op dezelfde manier werkt, is dat het bewijs van efficiëntie en integratie toch? Achteraf is het te betwijfelen of dit werkelijk gelukt is. 70 tot 90% van de acquisities faalt, en vooral de integratie van bedrijfsonderdelen is hiervan de oorzaak. Met het gelijktrekken van bedrijfsprocessen en het komen tot een gezamenlijk datamodel, is de hoop dat de efficiëntie behaald wordt. Inmiddels wordt deze aanname zelfs doorgetrokken over verschillende bedrijven heen: waarom zou het proces in bedrijf 1 anders zijn dan in bedrijf 2? Het vereist een geloof in een ultiem bedrijfsproces. Geloof je hierin, dan wil je gebruik maken van de software die dit gebruikt.

Twijfelen aan Taylor

De vraag is echter of de aanname van Taylor in elk proces klopt, is het inderdaad zo dat er voor elk proces één beste manier is om mee te werken? Klopt deze aanname niet, dan zijn veel investeringen heel anders te bezien. En klopt deze aanname niet, dan kan dit in plaats van positieve, sterk negatieve gevolgen hebben. Heb je de processen geautomatiseerd met standaard processen, dan kan dit nadelen brengen. Neem bijvoorbeeld het aanpassen van processen. Als het mensenwerk betreft, is het aanpassen van een werkwijze gemakkelijk. Gaan we terug naar het voorbeeld van Adam Smith: door simpelweg iemand die een nagel maakt anders te instrueren, is een werkwijze aangepast. Mogelijk vereist dit een klein beetje training. Is dit echter in software verwerkt, dan spreken we over een complexere verandering. Een nieuw proces zal bedacht moeten worden, de software ontworpen, gebouwd en getest. Hierna zal de training en verandering in werkwijze nog nodig zijn. Is de schaal groot genoeg, dan kan dit het waard zijn. Hierdoor zijn de kosten over meer transacties of eenheden uit te smeren en daardoor is er grotere winst te behalen. Is het proces dat geautomatiseerd is gecompliceerd of is het verbonden met veel andere processen? Dan zal het aanpassen van deze processen nog duurder zijn. Meestal loopt dit kwadratisch op. Taylor hield hier beperkt rekening mee: de optimale versie was immers al gevonden, medewerkers moesten hier vooral niet zelf over nadenken. De grootste kosten zitten echter in mijn optiek in het komen tot de beslissing. Zo niet is dit de grootste kostenpost: de kosten van niets doen. In plaats van namelijk een afweging in het moment, op de werkvloer in een kort overleg tussen twee mensen, zullen er meer schakels nodig zijn en wordt de overweging complexer. Vaak wordt dit al te moeilijk gevonden. Voordat iemand op een van de werkvloeren die dit gebruikt komt tot het overtuigen van zijn collega’s en daarmee de beslissing tot deze aanpassing, ben je vele schakels verder. Het organiseren van deze continuous improvement cycle lukt weinige bedrijven. Het gevolg is dat eenmaal geautomatiseerd, dit proces slechts zelden nog aangepast wordt. Het idee van de medewerker, of zelfs de manager: de kans dat dit leidt tot een verandering is simpelweg erg klein.

Maar wat nu als in het bedrijfsproces waarde zit in de creativiteit door de mens? Met de komst van AI wordt deze afweging steeds moeilijker, maar nog vaak is het de creativiteit van de mens wat tot waarde of zelfs efficiëntie leidt. De processen die namelijk zonder nadenken gedaan kunnen worden, zullen vaker door AI of automatisering gedaan kunnen worden. Dit is dan ook een veelgehoorde kritiek op Taylor: het neemt aan dat zodra iets in taken uitgedrukt kan worden het slechts uitvoeringen zijn die geen intelligentie kosten. Het bepalen wanneer deze aanname klopt is hiermee cruciaal geworden, maar een afweging die zelden bewust gedaan wordt. Vooral op afdelingen als logistieke planning of verkoop heb ik dit in de praktijk gezien. Hier wordt vaak gedacht dat producten of zelfs teams gelijk zijn. En dan moet het toch mogelijk zijn om altijd alles hetzelfde te doen en de processen te harmoniseren? Het is maar de vraag of deze stappen tot efficiëntie leiden. Bij een voormalige klant hebben deze stappen destijds soms tot bizarre gesprekken geleid. Met slechts enkele medewerkers werd een grote variëteit aan producten, met veel verschillende transporteurs, met veel aanpassingen per dag gepland. Hoe kon dit nu? De verhoudingen klopten simpelweg niet met onze andere klanten. Ook werkten niet alle medewerkers hetzelfde. En toch… de output was niet slecht als je het vergeleek met andere partijen uit de sector. De beste keuze hier bleek om slechts te zorgen dat de medewerker zoveel mogelijk vrijheid had en zo min mogelijk vastlegde. Wij moesten onze automatiseringsbehoefte bijstellen. Er werd een flexibiliteit gevraagd die niet altijd geleverd kan worden. Nu ga ik niet zeggen dat het nooit van toepassing is, maar vaak is het creatief omgaan met een situatie wat tot waarde leidt. Soms helpt het om slechts te accepteren dat bepaalde keuzes of onderdelen van het proces een gezonde “black box” zijn. Duurt het erg lang of is het erg complex om bepaalde informatie vast te leggen of merk je dat medewerkers niet uniform werken: misschien is het dan wel tijd om te twijfelen aan Taylor. Misschien is het beter te zorgen dat het vertrouwen in de medewerker gesteld wordt en diegene vrijheid te bieden in de uitvoering.

Standard, low code of custom

Nu is de keuze gelukkig niet wel of niet informatiseren of automatiseren. Er zijn verschillende keuzes te maken. Door de te automatiseren processen klein te houden, kan al grote winst behaald worden: het aanpassen en ontwikkelen wordt hierdoor kleiner. Ook kan de oplossing waarmee geautomatiseerd wordt helpen: het kiezen van een standaard oplossing is meestal moeilijk aan te passen en dwingt de medewerker in een keurslijf. Het op maat maken van de software aan je eigen bedrijf of zelfs de medewerkers in staat stellen het zelf te maken kan helpen. Low code software of maatwerk software kan hier vaak enorme verschillen opleveren: je zal meer zelf moeten bedenken, maar het gemakkelijker kunnen aanpassen zorgt ervoor dat het vinden van verdere optimalisaties gemakkelijker is. Het kiezen per bedrijfsproces op welk spectrum dit speelt is steeds gemakkelijker. Hier kunnen namelijk specialistische deeloplossingen voor gekozen worden.

In conclusie is het belangrijk om bij het beoordelen van requirements te beoordelen of er sprake is van een te standaardiseren proces en in welke mate. Verschillende softwarepakketten pretenderen dat het gebruik van deze standaardprocessen vele voordelen heeft. Denk hierbij aan de voorwaarden waarop dit zo is: slechts als er geen creativiteit nodig is en de keuzes in het proces geheel standaard zijn is dit het geval. Denk ook na over hoe groot de kans is dat een proces nog kan wijzigen: in het geval van het scannen van een factuur zal dit beperkt zijn, maar in het geval van logistieke planning wil je ruimte laten voor het optimaliseren door mensen op de werkvloer. Organiseer je hiernaar! Zorg dat je dit meeneemt in de bepaling van de requirements.

We hebben meer om te laten zien

Deze website maakt gebruik van cookies

Korte uitleg waar we cookies voor gebruiken, Korte uitleg waar we cookies voor gebruikenKorte uitleg waar we cookies voor gebruiken