Bouw een cyclustelling-app workflow om telbatches te maken, afwijkingen vast te leggen, grote deltas naar een supervisor te sturen en voorraadcorrecties netjes te posten.
Voorraad begint meestal goed op dag één en zakt dan elke dag een beetje weg. Meestal is het niet één grote fout. Het zijn veel kleine, normale gebeurtenissen die telkens net iets anders worden afgehandeld.
Picking is een veelvoorkomende bron. Een picker pakt het juiste artikel uit de verkeerde bak, voert een korte pick uit met het plan later terug te komen, of scant een label dat voor een andere doos is geprint. Retouren voegen meer drift toe: items komen geopend terug, missen onderdelen of worden “voor nu” in een willekeurige locatie gedropt en vervolgens vergeten. Schade en shrink doen het ook, vooral wanneer mensen kapotte items weggooien zonder het te registreren omdat het sneller voelt.
Foutieve labels zijn de stille moordenaar. Eén slecht label kan later tientallen “mystery variances” veroorzaken.
Cyclustelling is de kleine, frequente versie van voorraadcontrole. In plaats van alles één of twee keer per jaar stil te leggen voor een volledige fysieke inventaris, tel je een beperkte set items of locaties volgens een schema. Het doel is problemen vroeg te ontdekken, terwijl ze nog makkelijk te verklaren zijn.
“Goede nauwkeurigheid” is geen perfect getal op een rapport. Het betekent dat het dagelijkse werk voorspelbaar blijft: orders verzenden zonder last-minute vervangingen, inkoop bestelt niet teveel “voor het geval”, en klantenservice hoeft zich niet te verontschuldigen voor onnodige out-of-stocks.
Teams worstelen meestal om dezelfde redenen. Tellingen zijn inconsistent (verschillende eenheden, beschadigde items overgeslagen). Afwijkingen hebben geen duidelijke eigenaar, dus mensen “lossen” ze op door te raden. Grote wijzigingen worden zonder review geboekt, waardoor één fout een echte correctie wordt. En correcties worden niet verklaard (geen redencode, geen notities, geen audittrail), zodat dezelfde problemen zich blijven herhalen.
Een cyclustelling-app werkt het beste wanneer hij de juiste stappen moeilijk laat overslaan en de risicovolle stappen onmogelijk maakt om ongemerkt uit te voeren.
Een cyclustelling-workflow is een herhaalbare manier om een klein deel van de voorraad te controleren, te corrigeren wat niet klopt en vast te leggen wat er gebeurde. Een goede cyclustelling-app maakt daar een eenvoudig pad van dat mensen kunnen volgen zonder te gokken.
De meeste teams gebruiken dezelfde kernflow: plan een telbatch, tel op de vloer, vergelijk met het systeem, keur uitzonderingen goed, en post daarna voorraadcorrecties.
Houd rollen duidelijk:
Twee termen zijn belangrijk bij vergelijken: afwijking en delta. Afwijking is het met teken aangegeven verschil tussen wat het systeem verwachtte en wat je telde. Delta is de grootte van dat verschil.
Voorbeeld: het systeem zegt dat Bak A 120 eenheden heeft. De teller vindt 95.
Er bestaan goedkeuringspoorten omdat grote verschillen echte problemen kunnen zijn of simpele fouten. Een mis-scan, de verkeerde eenheid of het tellen van de verkeerde bak kan een grote delta veroorzaken. Het verplicht stellen van review voor grote deltas helpt voorkomen dat je een slechte correctie post die een groter probleem creëert dan de oorspronkelijke fout.
Zodra iets is goedgekeurd, moet de correctie op een gecontroleerde manier worden gepost, met wie het goedkeurde, wanneer en waarom vastgelegd in het record.
Voordat je een cyclustelling-app bouwt, moet je duidelijk hebben welke gegevens de workflow moet vastleggen. Als de basis ontbreekt, gaan mensen op de vloer gokken en houden de resultaten geen stand bij controle.
Begin met de minimale masterdata: items (SKU, naam, eenheid, actief/inactief), locaties (magazijn- en bakstructuur, en of een bak telbaar is) en de huidige on-hand hoeveelheid per item per locatie. Als je met lots of serienummers werkt, heb je ook het lot-/serienummer, vervaldatum en status nodig.
Bepaal daarna wat een telbatch in jouw organisatie betekent. Een batch is de container die een telling beheersbaar en traceerbaar maakt. Het moet de scope bevatten (locaties of SKU-groep), geplande data, toegewezen tellers en een eenvoudig statusmodel zoals Draft, In Progress, Submitted, Approved en Posted.
Op regelniveau (elk ding dat iemand telt) leg je net genoeg vast om de rekensom later te kunnen verklaren: item, locatie, systeemhoeveelheid, getelde hoeveelheid en de afwijking (in eenheden en, indien nuttig, in procent).
Neem vanaf dag één goedkeuringsgegevens op, ook als je ze eerst niet gebruikt. Je wilt een drempel voor afwijkingen (wat telt als een “grote delta”), redencodes (beschadiging, mis-pick, ontvangstfout), een supervisor-beslissing (approve/reject) en notities.
Voorbeeld: als Bak A3 24 op voorraad toont maar de teller 10 noteert, zou de app een reden moeten vereisen en het voor review moeten routeren voordat er een voorraadcorrectie wordt gepost.
Een cyclustelling-app werkt alleen als batches haalbaar aanvoelen. Als iemand een batch opent en 120 locaties ziet, zullen ze opschieten, overslaan of de batch verlaten. Begin met batches die zijn afgestemd op één persoon in één dienst, met extra tijd om duidelijke problemen op te lossen (ontbrekende labels, gemengde producten, beschadigde verpakking).
Kies wat je telt met regels die bij je pijnpunten passen, niet wat er netjes uitziet op een rapport. Veelgebruikte benaderingen zijn ABC-dekking (A-items vaker, C-items minder), fast movers, bins met herhaaldelijke problemen en een klein beetje willekeur om stille drift te vangen.
Houd elke batch compact: één zone, één gangbereik of een cluster van nabijgelegen bakken. Als reistijd hoog is, is de batch te breed. Een praktisch startpunt is 20 tot 40 locaties per batch voor handmatig tellen; pas aan op basis van de werkelijke doorlooptijden van je team.
Bepaal hoe je bewegingen tijdens het tellen afhandelt. De schoonste optie is picks en putaways blokkeren voor bakken die in een actieve batch zitten. Als blokkeren niet mogelijk is, gebruik dan een timestamp-cutoff: alles ná die cutoff wordt uitgesloten en in een vervolg behandeld.
Duidelijke statussen voorkomen verwarring en verminderen herstelwerk. Gebruik namen die overeenkomen met wat mensen doen:
Als je dit in AppMaster bouwt, kun je batches, locaties en statussen modelleren in de Data Designer en vervolgens regels toevoegen in de Business Process Editor zodat de app bewerkingen blokkeert zodra een batch op Posted staat.
De snelste tellingen gebeuren wanneer het scherm overeenkomt met wat iemand met zijn handen doet. Dat betekent meestal één eenvoudige invoerweergave die werkt in een lawaaierige gang, met handschoenen, schittering en slechte wifi.
Beperk invoervelden tot wat een teller echt kan bevestigen: item, bak (of locatie), getelde hoeveelheid en een optionele notitie. Als foto’s helpen om later geschillen op te lossen, maak ze optioneel en met één tik toe te voegen. Alles wat als papierwerk aanvoelt, wordt overgeslagen of, erger nog, geraden.
Maak scannen beschikbaar, maar niet verplicht. Barcodes zijn prima wanneer labels schoon zijn, maar je hebt altijd een handmatige fallback nodig voor gescheurde labels, lege scanners of gemengde verpakking. Een degelijk patroon is: scan item (of zoek), bevestig bak, voer hoeveelheid in.
Toon het systeemaantal, maar houd het read-only. Tellers mogen het getoonde aantal niet ter plekke “repareren”. Het zien van het verwachte aantal kan helpen om voor de hand liggende fouten te dubbelchecken, maar het mag niet overschrijven wat ze fysiek hebben geteld.
Twee gevallen verwarren mensen en verdienen expliciete afhandeling:
In beide gevallen leg je nog steeds de bak en het aantal vast (zelfs als dat nul is). Dat houdt het record bruikbaar voor review en correcties.
Als je dit in AppMaster bouwt kun je het invoerscherm minimaal houden met een mobiele UI, scannerinvoer gebruiken als die beschikbaar is, en foto’s en notities naast elke teltregel opslaan zodat supervisors kunnen beoordelen zonder mensen achterna te moeten lopen.
Een cyclustelling-app is slechts zo betrouwbaar als zijn afwijkingsregels. Op het moment dat iemand een slechte telling kan “fixen” door een getal te bewerken, stopt het proces een control te zijn en verandert het in een suggestie.
Gebruik eenvoudige wiskunde op elke regellijn:
Procentverschil helpt grote problemen bij items met weinig voorraad te spotten. Eenheidsverschil helpt kostbare schommelingen bij veelverkochte items te herkennen. Als het systeemaantal 0 is, behandel dat als een speciaal geval en routeer het automatisch naar review.
Gebruik drempels die passen bij hoe jouw operatie werkt. Veel teams combineren absolute eenheden en procenten zodat noch kleine items noch fast movers door de mazen glippen.
Bijvoorbeeld:
Houd de regel eenvoudig uit te leggen. Mensen accepteren controles wanneer ze die begrijpen.
Vereis vervolgens een redencode wanneer de afwijking niet nul is. Dit dwingt een korte “waarom”-vraag terwijl het artikel nog voor de teller ligt en maakt rapportage later nuttig. Typische redencodes zijn beschadigd/verlopen, mis-pick/short ship, verplaatst (andere bak), ontvangst niet geboekt en label- of eenheid-van-maat problemen.
Voorkom ten slotte risicovolle bewerkingen. Zodra een teller een batch (of regel) indient voor review, vergrendel hem. Als iets echt gecorrigeerd moet worden, maak er dan een begeleide recount van die een nieuwe invoer creëert en het origineel intact laat. Die ene regel beschermt je audittrail en stopt stille wijzigingen achteraf.
Supervisor-review moet minuten duren, niet uren. De truc is de beslisser op één scherm de context te geven die hij nodig heeft en de acties simpel te houden.
Supervisors hebben zelden alleen de ruwe telling nodig. Ze willen het recente verhaal van het item zien: vorige cyclustellingen, het verwachte on-hand en wat er veranderde sinds de laatste schone telling (ontvangsten, picks, retouren, transfers). Wanneer je cyclustelling-app die tijdlijn naast de afwijking kan tonen, stoppen supervisors met gokken.
Houd het praktisch:
Acties moeten aansluiten op de praktijk: goedkeuren wanneer het duidelijk is, afwijzen wanneer de telling ongeldig is, een recount aanvragen als de vloeromstandigheden rommelig zijn, en de batch splitsen wanneer slechts een paar regels twijfelachtig zijn zodat de rest kan doorgaan.
Voor grote deltas eis je een commentaar voordat je goedkeurt. Houd de prompt specifiek (beschadiging gevonden, mis-pick bevestigd, ontvangst niet geboekt, eenheid-probleem).
Elke beslissing moet automatisch vastleggen: wie besloot, wanneer, welke actie, welke drempel de review activeerde en de redenstekst. Als je dit in AppMaster bouwt, leg deze velden vast als onderdeel van de goedkeuringsstap zodat het record elke keer wordt aangemaakt, zonder op geheugen te vertrouwen.
Posten is het moment waarop je cijfers veranderen. Het betekent het bijwerken van on-hand hoeveelheden en het opslaan van een permanent record van wat veranderde, wanneer en waarom.
Houd goedkeuring en posten als twee afzonderlijke stappen. Goedkeuring is een beslissing. Posten is het schrijven naar de voorraad. Als je ze mengt, kan een mis-tap of een half-afgewerkte review de voorraad aanpassen voordat iemand het merkt.
Een eenvoudige regel voor een cyclustelling-app: alleen goedgekeurde afwijkingen mogen correcties genereren, en alleen correcties mogen on-hand bijwerken.
Maak een correctierecord per item en locatie (één regel per SKU en bak), ook als je een hele batch in één keer post. Elke regel moet dezelfde referenties dragen zodat je later kunt auditen: batch-ID, item, locatie/bak, systeemaantal, getelde hoeveelheid, delta, redencode, goedgekeurd door, goedgekeurd op en wie het poste.
Voeg voordat je een gebruiker laat posten een paar veiligheidscontroles toe:
Posten moet expliciet zijn op het scherm. Toon een laatste samenvatting van hoeveel regels zullen veranderen en wat de totale delta is, zodat de gebruiker precies weet wat er gebeurt.
Plan integraties vroeg, zelfs als je ze niet meteen bouwt. Als je ERP of WMS de bron van waarheid is, behandel posten als “exporteer goedgekeurde correcties” en laat het andere systeem ze toepassen. In AppMaster kun je correcties modelleren als een tabel en later een export naar CSV of een API-call toevoegen zonder de telworkflow te veranderen.
Een picker start een cyclustelling voor Bak A-14 (Item: 10mm bouten). Het systeem toont een verwacht aantal van 50, gebaseerd op de laatste ontvangst en recente picks. Op de vloer telt de picker 43.
Dat verschil van 7 eenheden kan door eenvoudige oorzaken ontstaan: een doos is tijdens een drukte naar een nabijgelegen bak verplaatst, een pick is gedaan maar niet bevestigd, een retour is zonder transactie teruggezet, of het baklabel is versleten en iemand heeft op de verkeerde plek geborgen.
In de cyclustelling-app tikt de picker op Submit Count. De app berekent de delta (-7, of -14%). Omdat de magazijnregel zegt dat alles boven 10% goedkeuring nodig heeft, staat hij niet toe dat een correctie direct wordt gepost. In plaats daarvan routeert hij de telling naar de status Needs Review en vraagt om een snelle recount.
Bij de recount vindt de picker een kleine ongeopende doos achter een grotere en werkt de recount bij naar 45. De afwijking is nu -5 (nog steeds -10%). De app houdt hem in review en vraagt om een korte notitie zoals “Gevonden verborgen doos, recount uitgevoerd.”
De supervisor opent de review-queue en ziet de originele telling, de recount, timestamps en wie telde. Zij kiezen één van de acties:
Zodra iets is goedgekeurd, post de app een voorraadcorrectie van 50 naar 45 met een audittrail. Het team legt ook de leer vast: herindeling van de bak om verborgen dozen te voorkomen en een herinnering om picks te bevestigen voordat je de gang verlaat.
De meeste problemen met cyclustelling gaan niet over inspanning. Ze komen door kleine workflow-gaten die je cijfers ongemerkt in gokwerk veranderen.
Een van de grootste fouten is mensen toestaan het systeemaantal te overschrijven. Dat voelt snel, maar het vernietigt de audittrail. Een telling moet een afwijking creëren, en vervolgens een correctie die wordt beoordeeld en gepost. Zo kun je altijd zien wat veranderde, wanneer en waarom.
Een andere veelvoorkomende kwestie is het tellen van een bewegend doel. Als picks, ontvangsten of transfers doorgaan terwijl iemand een bak telt, wordt je afwijking zinloos. Zelfs een simpele cutoff helpt, zoals bewegingen pauzeren voor een locatie terwijl een batch in uitvoering is, of een recount vereisen als er een beweging plaatsvond tijdens het telvenster.
Batchgrootte is belangrijker dan de meeste teams verwachten. Als batches te groot zijn, lopen ze over diensten heen, verliezen mensen context en sluit de batch nooit. Kleinere batches creëren een sneller ritme en schonere data.
Een paar faalpatronen duiken steeds weer op: ontbrekende redencodes voor afwijkingen, goedkeuringen in chat zonder record, onduidelijke eenheden (stuk vs doos), dingen één voor één ‘fixen’ in plaats van een consistente batchworklow, en snelle bewerkingen toestaan die het posten van correcties omzeilen.
Een kort voorbeeld: een teller vindt 12 stuks in een bak waarvan het systeem zegt 20. Als er geen redencode is, kun je later niet vertellen of het diefstal, schade, een pickfout of een ontvangstfout was. Als supervisor-goedkeuring in een berichtthread plaatsvindt, kun je ook niet aantonen wie het risico accepteerde.
Een goede cyclustelling-app voorkomt deze fouten door ontwerp: vergrendelde systeemaantallen, verplichte redencodes en een goedkeuringsstap die wordt vastgelegd voordat een voorraadcorrectie wordt gepost.
Voer voor de eerste echte telling een dry run uit met één gang of één kleine voorraadruimte. Je test niet de mensen, je test het proces.
Zorg dat:
Als je dit in AppMaster bouwt, stel deze regels in je Business Process: valideer scope, handhaaf drempels, vereis goedkeuring, post en vergrendel.
Begin klein zodat je snel kunt leren. Kies één magazijnzone, één productfamilie en een korte lijst met redencodes (beschadiging, mis-pick, shrink, ontvangst niet geboekt). Een smal pilot maakt het makkelijker te zien waar de workflow verwarrend is, waar tellingen te lang duren en welke afwijkingsregels te vaak triggeren.
Draai de pilot een week en verscherp daarna de workflow op basis van wat er echt op de vloer gebeurde. Houd het doel simpel: batches op tijd afronden en afwijkingen makkelijk verklaarbaar en goedkeurbaar maken.
Een praktisch plan voor de eerste week:
Zodra de basis werkt, kies je wat je als volgende automatiseert. De meeste teams halen snel winst uit een paar toevoegingen: notificaties wanneer een batch is toegewezen of overdue, automatische routing naar recount wanneer drempels worden overschreden, en een dagelijks rapport met afrondingspercentage, herhaalde afwijkings-SKU’s en openstaande goedkeuringen.
Als je een cyclustelling-app zonder veel code wilt bouwen, is AppMaster (appmaster.io) één optie: je kunt je voorraaddata modelleren, stappen voor afwijkingsgoedkeuring instellen en zowel web- als mobiele apps genereren vanuit dezelfde workflow.
Wat is cyclustelling en hoe verschilt het van een volledige fysieke inventaris?Cycle counting controleert regelmatig een kleine set items of bakken in plaats van één grote jaarlijkse fysieke telling. Het grootste voordeel is dat je afwijkingen vroeg ontdekt, terwijl de oorzaken nog vers en gemakkelijk te verklaren zijn.
Hoe groot moet een cyclustelling-batch zijn zodat mensen deze ook echt afmaken?Begin met een grootte die één persoon in één dienst kan afronden zonder te haasten. Voor veel magazijnen is 20–40 locaties per batch een praktisch startpunt; pas aan op basis van daadwerkelijke tijden en reistijd.
Moeten we voorraadbewegingen bevriezen terwijl een cyclustelling bezig is?Blokkeer picks en putaways voor bakken in een actieve batch wanneer mogelijk, omdat dat voorkomt dat de telling een bewegend doel wordt. Als blokkeren niet kan, gebruik dan een duidelijke afsluittijd en vereist een recount als er transacties tijdens het telvenster hebben plaatsgevonden.
Hebben we barcode-scanning nodig, of is handmatige invoer voldoende?Gebruik scannen wanneer labels betrouwbaar zijn, maar zorg altijd voor een handmatige fallback voor gescheurde labels, gemengde verpakking of kapotte scanners. Een eenvoudige flow die goed werkt: identificeer het item, bevestig de bak, voer de hoeveelheid in en verzend.
Moeten tellers het systeemaantal zien tijdens het tellen?Laat het systeemaantal zichtbaar maar alleen-lezen zijn, zodat tellers niet ter plekke aantallen kunnen ‘fixen’. Een telling moet een afwijking creëren; alleen een goedgekeurde correctie mag de voorraadhoeveelheid aanpassen.
Hoe bepalen we een goede drempel voor een “grote delta” die naar goedkeuring moet?Begin met een gecombineerde regel die zowel grote hoeveelheidsverschillen als grote procentverschillen opvangt, bijvoorbeeld “10+ eenheden of 5%”, en stem dit bij op hoe ‘ruis’ jouw voorraad is. Beschouw elke telling waarbij het systeemaantal 0 is als automatische review, omdat dit vaak misplaatsing of ontbrekende transacties aangeeft.
Welke redencodes moeten we verplichten bij een afwijking?Gebruik een korte lijst die overeenkomt met werkelijke oorzaken, zoals beschadigd/verlopen, mis-pick/tekortzending, ontvangst niet geboekt, verplaatst, en label- of maateenheidsprobleem. Houd het consistent zodat rapporten patronen tonen in plaats van een stapel unieke verklaringen.
Wat moet een supervisor doen tijdens de review van een afwijking?Laat supervisors goedkeuren, afwijzen of een recount aanvragen, en eis een korte opmerking bij grote deltas zodat de beslissing later uitlegbaar is. Het review-scherm moet voldoende context bieden om gokken te voorkomen, zoals recente tellingen en recente bewegingen voor dat item en die locatie.
Hoe posten we voorraadcorrecties veilig zonder nieuwe fouten te maken?Houd goedkeuring en posten als twee aparte stappen en sta alleen posten toe voor goedgekeurde regels. Posten moet een permanent correctierecord aanmaken (wie telde, wie goedkeurde, wat veranderde en waarom) en dubbele posting voorkomen met een posted-flag en timestamp.
Kunnen we dit als een eenvoudige no-code app bouwen en toch auditable houden?Ja — mits het de workflow afdwingt in plaats van te vertrouwen op geheugen. Vergrendelde ingediende tellingen, verplichte redencodes en automatische vastlegging van goedkeuringen maken het auditable. In AppMaster kun je batches en tellijnen modelleren, goedkeuringsregels toevoegen in een Business Process en zowel web- als mobiele apps genereren uit dezelfde workflow.
21 jan 2026
8 min
20 jan 20268 min
20 jan 20267 minExperimenteer met AppMaster met gratis abonnement.
Als je er klaar voor bent, kun je het juiste abonnement kiezen.
