In ScaleTeam hebben we de inrichting aangepast zodat de bevoegdheid vooraf wordt vastgelegd, in plaats van elke geldige actie achteraf afhankelijk te maken van dezelfde goedkeuringsknop.
De vorige opzet had reorder-point write-back naar het ERP expliciet achter een always-on approval gate gebouwd. Een ERP-wijziging kon dus niet rechtstreeks vanuit de voorraadpolicy worden uitgevoerd.
We hebben governed inventory policy activation geautomatiseerd, zodat policy-activatie een expliciet autonoom uitvoeringspad kreeg. Daarnaast hebben we de bounded Inventory autonomy cycle afgerond: autonome selectie, policy-activatie en ERP-synchronisatie werken nu als één begrensde cyclus die volledig wordt geregistreerd.
De bevoegdheid zelf is verder begrensd tot per-cycle authority. Het wijzigen van een autonomy-preset mag numerieke controles of harde regels niet omzeilen — dat is een harde grens, geen instelbare optie.
Hoe het nu werkt
De module ondersteunt vier expliciete autonomy-modes: advisory, assisted, guarded_auto en autonomous. Advisory houdt voorraadpolicy-aanbevelingen in governed shadow. Guarded_auto staat automatische policy-activatie toe binnen de geconfigureerde authority.
Wanneer policy-activatie automatisch is geautoriseerd, rapporteert het dashboard human review als exceptions_only. Dat is geen cosmetische keuze. Het betekent dat menselijke tussenkomst de uitzondering is, niet de standaardstap na elke policywijziging.
ERP policy synchronisatie is apart begrensd. Off houdt de policy binnen ScaleTeam. Reorder_point kan geautoriseerde reorder points naar het ERP synchroniseren. Een kandidaat-ERP-write vereist drie dingen vooraleer hij als uitvoerbaar wordt behandeld: mandate authorization, adapter capability en live read-back. Zonder die drie is er geen write.
De bounded autonomy cycle registreert bovendien werkelijk uitgevoerde working-capital impact apart van wijzigingen die enkel gestaged zijn. Je ziet dus wat er daadwerkelijk buitenkwam, niet alleen wat het systeem had voorgesteld.
Grenzen in de praktijk
ERP policy write-back is begrensd door een maximum aantal activaties per cyclus. Het maximum wordt gevalideerd als een integer binnen een toegestaan bereik. De huidige productdefault staat maximaal 20 ERP-activaties per run toe, met een relatieve change limit van 0.25.
De standaard mandate verleent geen nieuwe working-capital autonomie. Capital_allocation blijft recommend, maximum additional capital per item is nul en finance_context blijft advisory. Wil je daar meer mee, dan moet dat expliciet worden geconfigureerd en gemandateerd.
Ons standpunt over governance
Ons uitgangspunt is dat de belangrijkste governancebeslissing vooraf hoort te liggen: definieer expliciet wat het systeem mag uitvoeren en welke grenzen nooit automatisch gepasseerd mogen worden. Niet elke geldige uitvoering achteraf opnieuw afhankelijk maken van dezelfde goedkeuringsknop.
Benieuwd wat dit voor uw bedrijf kan betekenen?
We denken graag vrijblijvend met u mee over de mogelijkheden voor uw KMO.
Plan een gesprek →