Waarom standaardsoftware de versketen niet begrijpt
Een standaard ERP is gebouwd op vaste prijzen, vaste eenheden en voorspelbare levertijden. In AGF bestaat geen van die drie. Een pallet tomaten heeft een dagprijs, een gewicht dat afwijkt van de bestelling en een levermoment dat afhankelijk is van de veiling of de teler. Pakkettenlogica werkt op stuks of dozen. Gewichtslogica werkt anders: je factureert op kilo, je bestelt op pallet, je ontvangt op gewicht. Elk standaardpakket dat dit niet als kern heeft, vraagt aanpassingen. Die aanpassingen stapelen zich op, worden duur in onderhoud en maken elke upgrade een klein project. De operatie past zich aan het systeem aan in plaats van andersom. Dat is de kern van het probleem.
Welke processen lopen het vaakst vast?
In gesprekken met AGF-bedrijven komen steeds dezelfde knelpunten terug. De orderinvoer is het eerste: klanten bellen of mailen bestellingen door die handmatig worden ingeklopt, terwijl de voorraadpositie al aan het schuiven is. Het tweede knelpunt zit in de pakbons en paklijsten: die moeten soms per klant anders zijn, met specifieke weergave van gewichten, besteleenheden en partijcodes. Een derde pijnpunt is de koppeling tussen inkoop en verkoop. Als een teler minder levert dan verwacht, moet de verkoper direct weten welke orders hij moet herplannen. In de meeste systemen is die koppeling er niet automatisch. Een medewerker belt rond, past handmatig aan en hoopt dat de factuur later nog klopt. Dat is geen uitzondering. Dat is de dagelijkse gang van zaken.
Wat lost een maatwerksysteem op dat een standaardpakket niet doet?
Een systeem dat gebouwd is voor de versketen heeft gewichts- en prijsvariatie als basislogica, niet als add-on. Dat betekent dat een order automatisch herberekend wordt als de werkelijke ontvangst afwijkt van de bestelling. Dat paklijsten gegenereerd worden op basis van de logistieke werkelijkheid van die dag, niet op basis van een sjabloon dat ooit is ingesteld. Dat inkoop- en verkoopposities live gekoppeld zijn, zodat tekorten zichtbaar zijn voordat ze een klantprobleem worden. Bonsai bouwt zulke systemen als een Bonsai AI Digital Twin: het kernsysteem volledig opnieuw, met de logica van het bedrijf erin verwerkt, en met AI die het voorwerk doet. Geen rapport achteraf, maar een systeem dat in de operatie meeloopt.
Wanneer is een AI-laag om het bestaande systeem de betere keuze?
Niet elk AGF-bedrijf moet het kernsysteem vervangen. Als de basislogica van het pakket redelijk klopt maar de invoer en documentverwerking te veel mensenwerk kosten, is een AI-laag eromheen een realistischere eerste stap. Bonsai AI Workers kunnen dan specifieke taken overnemen: orderemails uitlezen en omzetten naar invoer, pakbons genereren op basis van klantspecificaties, of afwijkingen tussen bestel- en ontvangstgewicht signaleren. Die ingreep is kleiner, sneller en vraagt minder van de organisatie. De keuze tussen beide routes hangt af van hoe diep het probleem zit. Zit het in de logica van het systeem, dan helpt een laag eromheen niet structureel. Zit het in de handmatige handelingen bovenop een werkend systeem, dan is een Worker vaak genoeg.
Wat is een realistisch startpunt voor een AGF-bedrijf?
Begin met het in kaart brengen van de drie processen waar de meeste handmatige correcties plaatsvinden. Dat zijn vrijwel altijd orderinvoer, paklijstverwerking en de afstemming tussen inkoop en verkoop bij afwijkende leveringen. Als die drie processen op papier staan, is het mogelijk te bepalen of de oorzaak in de systeemlogica zit of in de invoer- en communicatieprocedures eromheen. Pas daarna heeft de keuze tussen maatwerk en een AI-laag een feitelijke basis. Zonder die analyse koop je een oplossing voor een probleem dat je nog niet precies hebt omschreven. Dat is een veelgemaakte fout, ook bij bedrijven die al jaren weten dat het systeem niet goed genoeg is.