De developer als bottleneck
Er is iets raars aan de hand in veel e-commerce organisaties. Teams sturen elke week een rij verzoeken naar de developer. Kleine dingen. Verbindingen tussen systemen. Meldingen die automatisch zouden moeten lopen. Rapportages die iemand handmatig samenstelt omdat de systemen het niet zelf doen.
De developer werkt ze af. Wanneer hij er aan toekomt.
Niemand klaagt. Het is gewoon hoe het gaat.
Maar als je er goed naar kijkt, zie je iets anders. Je ziet een organisatie die zichzelf vertraagt op plekken waar dat helemaal niet nodig is. Waar kennis en beslissingen ophopen bij één persoon, terwijl de rest wacht.
Automatisering was een technisch probleem. Dat is het niet meer.
Een paar jaar geleden was dit een eerlijk excuus. Automatiseren betekende code schrijven. Systemen aan elkaar koppelen vereiste iemand die begreep hoe APIs werkten, hoe je datastromen bouwde, hoe je fouten afving.
Dat is veranderd.
Tools als N8N maken het mogelijk om workflows te bouwen met drag-and-drop. Je verbindt systemen, bepaalt wat er gebeurt als er iets binnenkomt, en laat het draaien. De logica die je inbouwt is dezelfde als altijd. Maar je hoeft er geen code voor te schrijven.
Ik liet het onlangs aan een collega zien. We bouwden in een kwartier een koppeling tussen een projecttool en een meldingssysteem. Niet als proof of concept. Als iets wat we daarna gewoon gebruikten.
Het klinkt bijna te simpel. Maar dat is precies het punt.
Wat het vraagt is geen technische kennis. Het is denkwerk.
Het grootste obstakel bij automatisering is niet de tool. Het is de vraag die eraan voorafgaat: wat wil ik eigenlijk dat er automatisch gebeurt?
Die vraag is moeilijker dan hij lijkt. Niet omdat de antwoorden complex zijn, maar omdat mensen het niet gewend zijn om hun eigen werkprocessen zo te bekijken. Wat zijn de stappen? Wat triggert wat? Waar gaat het mis als er niets is dat het opvangt?
Als je die vraag goed kunt beantwoorden, is de rest uitvoering.
En die uitvoering lukt de meeste mensen prima. Ze hebben alleen iemand nodig die ze er de eerste keer doorheen begeleidt. Die laat zien hoe je een flow opbouwt, waar je op moet letten, hoe je debugt als er iets niet klopt.
Daarna liggen de mogelijkheden voor henzelf open.
Wat het betekent als een team dit zelf kan
De verschuiving die dan plaatsvindt is groter dan je van een tool zou verwachten.
Teams die zelf automatisaties kunnen bouwen, hoeven niet meer te wachten. Ze pakken hun eigen problemen op. Ze begrijpen hun systemen beter, omdat ze er actief mee bezig zijn. Ze zien zelf wat er efficiënter kan, en ze kunnen het ook uitvoeren.
De developer wordt geen bottleneck meer voor de kleine dingen. Die kan zich richten op het werk waar zijn kennis echt nodig is.
En als er iets misgaat in een automatisatie, is het niet automatisch een ticket voor de technische afdeling. De logica is zichtbaar. De stappen staan open. Iemand die begrijpt wat er gebouwd is, kan er ook naar kijken.
Dat is een ander soort organisatie.
De vraag is niet of dit kan. De vraag is wie je begeleidt.
N8N is gratis te hosten. De leercurve is laag. De technische drempel is gedaald tot het punt waarop iemand met een goed gevoel voor processen er binnen een dag mee overweg kan.
Wat teams nog wel nodig hebben, is iemand die ze de eerste keer begeleidt. Die helpt de goede vragen te stellen. Die laat zien hoe je een omgeving inricht zodat het later ook te beheren is.
Daarna zijn ze op zichzelf aangewezen. En dat is precies de bedoeling.
