Wat de lepeltheorie ons leert over ERP
Mijn partner heeft in de twaalf jaar dat we samen zijn zes knieoperaties gehad. Zelf kom ik qua blessures niet verder dan een gestoten teen. In die jaren leerde ik wel een begrip kennen dat volgens mij iedereen zou moeten kennen.
De lepeltheorie komt uit de wereld van chronische aandoeningen, waar energie een schaars goed is. Elke dag begin je met een beperkt aantal “lepels” energie en elke taak kost er een of meer. De kunst is om de hele dag zuinig met die lepels om te gaan, zodat je vooral energie kan steken in de dingen die ertoe doen.
Dat kost lepels
De lepeltheorie is verrassend goed toe te passen op software. Het navigeren van traditionele ERP-systemen kost namelijk teveel van die lepels. Dat komt omdat de software is ontworpen om zo breed mogelijk inzetbaar te zijn, voor zowel de HR-afdeling als voor finance. Daardoor houdt het systeem geen rekening met de context van iemands dagelijkse werk. Het resultaat is generieke software die nauwelijks echte efficiëntiewinst oplevert.
Regels zonder begrip
Wat generieke software mist, is context. Dat verschil werd me ooit duidelijk in een hotel in India, waar ik bij het inchecken te horen kreeg dat we de ramen dicht moesten houden als er eten op de kamer stond. De reden werd er niet bij verteld. Een ochtend later haalde een troep apen de hele kamer overhoop. We hadden regels gekregen, maar geen context. Hadden we geweten dat er hongerige apen in de buurt waren, dan hadden we het zelf bedacht.
'Het ERP-systeem vertelt wat je moet doen, maar begrijpt niet waarom'
-
ERP werkt al tientallen jaren op dezelfde manier. Het systeem vertelt je wat je moet doen en blokkeert je als je afwijkt, maar het begrijpt niet waarom. Die context lever jij. Welke status omschrijft een vertraging van het project het best? Onder welke categorie valt het vertrek van een medewerker met een regeling? Op welke kostenpost boek je een factuur die nergens precies bij past? Elke lepel energie die daaraan opgaat, gaat niet naar werk dat de organisatie verder brengt.
Van kennis naar handelen
Wat een ERP-systeem moet weten om het denkwerk van de gebruiker over te nemen, verschilt per sector. Publieke organisaties werken met subsidies die aan wettelijke verplichtingen moeten voldoen, zakelijke dienstverleners draaien projecten waarin contractuele afspraken en reputatie meewegen, en non-profits geven donateursgeld uit dat vaak aan een specifiek doel is gekoppeld. Door die sectorverschillen mee te geven aan de software, maak je van een generieke ERP een systeem dat het werk daadwerkelijk begrijpt.
Branche-specifieke spelers zetten AI daarom op een fundamenteel andere manier in. Neem bijvoorbeeld een projectmanager die aan een lopend project werkt. Zij kan haar AI-agent vragen: ‘Loopt dit project nog op schema?’ Of: ‘Zit ik nog binnen budget?’ De AI-agent bevestigt dat het budget klopt, maar dat het project achterloopt. Ze vraagt door: ‘Wat als ik mijn teamgenoot Julia aan het project toevoeg? Halen we het schema dan in?’ De agent bevestigt. Julia is beschikbaar, haar uurtarief valt binnen het budget, en ze kent de klant.
In een volgende fase komt de AI-agent zelf met een suggestie: ‘Dit project loopt uit. Julia is beschikbaar en kent de klant. Zal ik haar toevoegen?’ Of: ‘Er heeft iemand ontslag genomen die volgende maand op drie projecten stond. Op één daarvan kan een collega het overnemen, maar voor de andere twee heb je vervanging nodig. Zal ik de vacature klaarzetten?’ Zo werkt het ERP-systeem samen met agents die zelfstandig taken uitvoeren en terugkoppelen aan de gebruiker.
ERP als teamlid
Een ERP-systeem dat meedenkt, doet meer dan taken uitvoeren. Het neemt uitzoekwerk over waar voorheen de gebruiker zijn energie aan kwijt was. Welke status en welke kostenpost erbij horen, bepaalt het systeem zelf, omdat het begrijpt wat er speelt.
Zover komt het alleen als software de organisatie goed genoeg kent om die keuzes te maken. Inhoudelijke kennis van de sector is daarvoor het vertrekpunt. De rest leert het systeem gaandeweg door de vragen die een gebruiker stelt en de elke keuze die hij maakt.
Bereikt jouw ERP dat punt, dan begin je de dag nog steeds met een beperkt aantal lepels, maar besteed je ze niet meer aan taken die je over kunt laten aan software. Die energie kun jij weer gebruiken voor werk dat er werkelijk toe doet. Dat is waar deze transformatie om draait. En we staan nog maar aan het begin.
Reacties
Om een reactie achter te laten is een account vereist.
Inloggen Word abonneeWat ik heel erg mis in dit artikel is dan wel WAAROM het de lepel-theorie heet ;). Dat heb ik wel nodig om dit te onthouden.
In het ICT-jargon noemen we wat jij beschrijft een 'task based (user) interface' (i.p.v. een CRUD UI of object oriented UI). Met een task based UI kun je niet alleen data in opslaan en terugvinden, maar het systeem 'kent' ook jouw workflow: jouw werkprocessen. En dan bedoel ik 'kennen' niet in de zin van een LLM die iets (lijkt te kunnen) begrijpt/en, of iets als RAG, maar het proces is echt ingebakken in de UI. E.g. er zijn schermen en knoppen met herkenbare acties en logische gerelateerde acties in de buurt. As opposed to een veredelde Excel sheet (CRUD, alles kent alleen create, read update, delete operaties).
Het ontwerpen en realiseren van een specifieke interface is wat meer werk, maar nog altijd wel prettiger dan (te denken dat je) dit met een 'natuurlijk taal' interface (kunt) oplossen. LLM's hallucineren nu eenmaal af en toe. Of ze geven een aantwoord op de vraag die je stelt, in plaats van de vraag die je bedoelde te stelllen, maar even niet zo geformuleerd kreeg. Met LLM's kun je deze custom software wel snel zelf helpen bouwen. Mits je het daarna goed valideert dat dit inderdaad goed aansluit op de processen. Dan is het LLM op compile time, niet op run-time ;).