Hoe het werkt
Wat u moet bestellen, en waarom
Elke week beslist iemand wat er ingekocht wordt. Stocktimal maakt die beslissing expliciet: uw voorspelling, lead times, voorraad en openstaande orders gaan erin, en er komt een voorgestelde order per SKU uit — hoeveelheid, datum, leverancier, en de onderbouwing op de regel. U past aan waar u het er niet mee eens bent, keurt goed, exporteert. Deze pagina is de uitgebreide versie: wat de engine met uw cijfers doet, wat het daarbij aanneemt, en waar het stopt.
Eén beslissing, en die dan goed
De voorspelling is de makkelijke helft. De open vraag is wat u deze week bestelt, in welke hoeveelheid, bij welke leverancier — en die vraag wordt meestal beantwoord in een spreadsheet, onder tijdsdruk, door wie er net is. Stocktimal beantwoordt haar expliciet: het neemt uw voorspelling, uw lead times, uw actuele voorraad en uw openstaande orders, en komt terug met een voorgestelde order per SKU. Het is geen ERP en geen S&OP-suite. Uw ERP blijft de voorraad, de orders en de administratie houden; Stocktimal leest wat u daaruit exporteert en geeft een plan terug waar u tegenin kunt gaan.
Die afbakening is bewust smal. De bestelbeslissing is één taak, het is de taak waarbij geld daadwerkelijk wordt vastgelegd, en het is er een die wij liever goed doen dan in een suite verpakken.
Deel één — een voorspelling is een schatting met een vorm
De meeste planningstools behandelen de voorspelling als één getal en zetten daar een regel voor veiligheidsvoorraad bovenop. Wij bepalen de buffer op basis van de gemeten spreiding van de voorspelfout. Dat is het verschil, en het is na te gaan: vraag elke leverancier uit welke verdeling hun veiligheidsvoorraad volgt, en of die op uw data is gefit of is aangenomen.
Een voorspelling is een schatting met een vorm. "Wij verwachten volgende week 40 stuks" is het midden van die vorm; wat voor bestellen telt, is hoe breed hij aan weerszijden is. Bestelt u op het midden, dan komt u ruwweg de helft van de tijd tekort. Bestelt u op een afgeronde buffer, dan houdt u voorraad aan op de SKU's die dat nooit nodig hadden, terwijl de werkelijk grillige SKU's alsnog leegraken.
Het getal waarmee Stocktimal werkt, is dus geen getal. Het is een verdeling per SKU per periode — een lage, een midden- en een hoge waarde — en een lead time die zelf ook een bandbreedte is in plaats van een vast cijfer. De buffer volgt uit die rekensom in plaats van met de hand te worden ingesteld. Waar de vraag stabiel is, is de buffer krap zonder dat iemand daartoe hoeft te besluiten. Waar de vraag grillig is, is de buffer ruim, en de reden daarvoor is zichtbaar in plaats van een kwestie van iemands lef.
Dat is ook waarom de twee delen van het product één verhaal zijn. Een kleinere foutverdeling is geen academische verbetering — het is rechtstreeks minder voorraad bij dezelfde fill rate, omdat de buffer om te beginnen op die spreiding is bepaald.
De forecasting is het deel dat wij het langst doen. Het is een ander vak dan bestellen, en het is waar RAW Analytics is begonnen.
Hoe de voorspelling tot stand komt
Een niveau dieper, voor de lezer die wil weten wat er werkelijk gebeurt. Niets hiervan is nodig om het product te gebruiken.
Meerdere modelfamilies, per reeks gekozen
Statistische, machine-learning-, neurale en foundation-modellen worden alle gefit, en de keuze wordt per SKU gemaakt in plaats van over het hele assortiment opgelegd. Een langzaam lopend onderdeel en een snel lopend verbruiksartikel zijn niet hetzelfde voorspelprobleem en krijgen niet hetzelfde model.
De foutverdeling wordt gefit, niet aangenomen
De residuen van het model dat voor die reeks het beste presteerde, worden gebruikt om de spreiding te fitten. Vraag in de groothandel is doorgaans telbaar en grillig in plaats van klokvormig, dus een normaalverdeling is als uitgangspunt de verkeerde keuze. Wij fitten een verdeling die grilligheid toelaat.
SKU's met weinig historie lenen van vergelijkbare SKU's
Een SKU met een handvol ruizige waarnemingen wordt niet vertrouwd alsof hij jaren historie heeft. De schatting van de spreiding wordt naar het gedrag van vergelijkbare SKU's toe getrokken, en die trek neemt af naarmate de eigen historie groeit.
Elk model wordt afgezet tegen naïeve benchmarks
Een model verdient zijn plek door op dezelfde reeks een voortschrijdend gemiddelde en een seizoensnaïeve vergelijking te verslaan. Verfijning die het eenvoudige alternatief niet verslaat, wordt niet gebruikt.
Wat hierbij wordt aangenomen, zonder omhaal: dat uw verkoophistorie de vraag weerspiegelt en niet wat u toevallig op voorraad had; dat het verleden iets zegt over de komende perioden; en dat de SKU waar u naar vraagt enige historie heeft, of lijkt op een SKU die dat wel heeft. Waar dat niet opgaat — een gloednieuwe SKU, een eenmalige aanbesteding, een omslag in uw markt — wordt de buffer op magere onderbouwing bepaald, en is het eerlijke antwoord dat u die beter kunt overschrijven dan op de rekensom te vertrouwen.
Deel twee — waar de randvoorwaarden gaan knellen
Een verdeling is geen order. Van het een het ander maken is de tweede helft van het werk, en daar komen uw randvoorwaarden binnen.
Per SKU bepaalt de engine een hoeveelheid en een datum. De hoeveelheid moet de verwachte vraag over de lead time dekken, plus de buffer die de spreiding vraagt, min wat u al heeft liggen en wat al onderweg is. Dan komt de praktijk erbij: de leverancier hanteert een minimale afnamehoeveelheid, de goederen komen in dozen, en de order moet een minimumwaarde halen voordat de leverancier verzendt. Die randvoorwaarden ronden het antwoord af, en die afronding is niet gratis — een doos van twaalf op een SKU die er zeven nodig heeft, is een keuze en geen detail.
Het fill rate-doel stelt u zelf in, per groep en per SKU. Dat is de knop die bepaalt hoeveel van de staart u bereid bent af te dekken. Lead time wordt behandeld als een bandbreedte en niet als een vast getal, want een leverancier die drie weken opgeeft en tussen de twee en vijf levert, is een ander planningsprobleem dan een leverancier die betrouwbaar in vier weken levert.
Voorraadkosten en bestelkosten worden meegenomen in de run en naast het voorstel gerapporteerd, zodat u ziet wat een plan met zich meebrengt. Wees helder over wat dat vandaag betekent: ze worden gemeten en getoond, en niet door de standaard-engine gebruikt om de hoeveelheid te kiezen.
De uitkomst is een voorgestelde order per SKU per leverancier, met een datum en de onderbouwing erbij — inclusief welke randvoorwaarde het getal heeft verschoven, als er een was.
Beter voorspellen is minder voorraad
Neem één SKU en houd al het andere gelijk — hetzelfde fill rate-doel, dezelfde lead time, dezelfde voorraad. Geef hem een brede foutverdeling en de buffer moet ruim zijn, want het doel moet ook in de slechte weken worden gehaald en niet alleen gemiddeld. Geef hem een kleinere en de buffer krimpt, bij precies hetzelfde doel. Er is niets aan de bestellogica veranderd; de invoer is veranderd.
Daarom staat de kwaliteit van de voorspelling niet los van uw werkkapitaal. De buffer is een directe functie van de spreiding, dus alles wat die spreiding verkleint, gaat rechtstreeks af van de voorraad die u aanhoudt — en alles wat een spreiding aanneemt in plaats van meet, gokt naar het getal dat u geld kost.
U heeft het laatste woord
Stocktimal stelt voor. Het bestelt niet. Dat is een ontwerpkeuze en geen ontbrekende functie, en er staat geen plan om dat te veranderen.
Een run komt terug als een lijst die u afwerkt: voorgestelde hoeveelheid per SKU, per leverancier, met de onderbouwing per regel beschikbaar. Waar u het er niet mee eens bent, typt u de hoeveelheid over — de inkoper die weet dat een klant op het punt staat groot te bestellen, weet iets wat de historie niet weet. U keurt goed wat u wilt en wijst af wat u niet wilt. Wat u goedkeurt wordt een CSV die u downloadt en zelf in uw ERP inleest.
De aanpassingen horen bij de vastlegging en zijn geen omweg. Een run bewaart wat er is voorgesteld en waar u het in heeft veranderd, zodat de volgende die vraagt waarom er in november is besteld zoals er is besteld, beide kan zien.
Werkt dit met mijn ERP?
Ja — want er hoeft niets gekoppeld te worden. U exporteert de actuele voorraad, openstaande orders en uw voorspelling; Stocktimal geeft voorgestelde orders terug die u in uw ERP inleest zodra u tevreden bent. Er staat geen integratieproject tussen u en het eerste bruikbare resultaat, en er komt niets in uw administratieve systeem zonder dat een mens besluit dat dat moet gebeuren.
Er is geen koppeling, en deze pagina gaat u er ook geen beloven. Wat u dat kost, is een bestand dat u elke cyclus verplaatst. Wat het u oplevert, is dat wij niet in uw administratieve systeem kunnen schrijven, en dat u binnen weken kunt draaien in plaats van na een integratieproject.
Elk getal mag u bevragen
"Waarom is deze order 400 stuks?" is de vraag die bepaalt of een planningstool wordt gebruikt of stilletjes wordt losgelaten. Stocktimal beantwoordt die op twee manieren. Elk voorstel draagt zijn eigen onderbouwing op de regel, waarvoor u niets extra's nodig heeft. Daarnaast is er een chat-assistent die onderzoeksvragen beantwoordt op basis van uw eigen rungegevens — de gebruikte voorspelling, de lead times, de randvoorwaarde die de hoeveelheid heeft verschoven.
Er gelden tegelijk drie dingen voor, en alle drie horen in dezelfde adem thuis en niet in een voetnoot: hij is alleen-lezen van constructie, dus hij kan geen order plaatsen of parameter wijzigen; hij is een functie van een betaald pakket en geen onderdeel van elk plan; en hij wordt per omgeving aangezet, dus het is een schakelaar die iemand omzet en niet iets wat meekomt met het product.
Het is een manier om een run te ondervragen, geen planner. De bestelbeslissing blijft waar hij was.
Navolgbaar van opzet
Elke run legt de mappingversie, de parameterset en de overrideset vast waartegen hij is gedraaid, en is zo opgezet dat hij vanuit die vastgelegde snapshot opnieuw te draaien is. De bedoeling is dat een plan van drie maanden geleden te reconstrueren is uit wat het werkelijk heeft gebruikt, en niet uit wat de instellingen vandaag toevallig zeggen.
De onderbouwing per order is bewust smal. Zij noemt de gekozen sourcing-optie, de gebruikte vraag- en lead time-cijfers, de voorraad en het fill rate-doel — en zij noemt een leveranciersvoorwaarde alleen wanneer die de hoeveelheid daadwerkelijk heeft verschoven. Een reden die op elke regel staat, is geen reden maar versiering.
In het juiste register gezegd: zo is het systeem gebouwd, en het is geen resultaat dat wij over klanten heen hebben gemeten. Het is een eigenschap van het ontwerp. Heeft u de sterkere versie van die uitspraak nodig, vraag ons dan wat wij wel en niet hebben getoetst, dan vertellen wij dat.
Waar uw data staat
Stocktimal draait op Microsoft Azure in de EU (West-Europa). Elke klant krijgt een eigen tenant, en elk record draagt de tenant waar het bij hoort, zodat het assortiment van de ene klant niet vanuit het account van de andere te lezen is. Wij tekenen een verwerkersovereenkomst.
Wij hebben vandaag geen beveiligingscertificering, en wij zullen ook niet suggereren van wel. Heeft uw inkoopproces de details nodig — hoe tenants gescheiden zijn, waar secrets staan, hoe toegang is afgebakend — vraag het en wij lopen het met u door.
Stocktimal is niets voor u als
Niemand schrijft dit stuk, en dat is ongeveer waarom het het schrijven waard is. Elk punt hieronder is een echte grens van vandaag en geen zachte, en elk ervan is een goede reden om te stoppen met lezen.
U voorraad over meerdere magazijnen tegelijk moet plannen
v1 plant tegen één voorraadpool. Is uw vraag hoeveel u centraal aanhoudt tegenover elke regionale locatie, en hoe u daartussen herverdeelt, dan is dat multi-echelon planning en die doet Stocktimal niet. Eén pool, goed gepland, is het geheel van v1.
U wilt dat er wordt besteld zonder tussenkomst van een mens
Stocktimal stelt voor en een mens keurt goed. Is uw doel dat orders 's nachts ongezien de deur uitgaan, dan hebben wij de verkeerde vorm — en wij gaan u geen beoordelingsstap aanpraten die u niet wilt.
Het in uw ERP moet schrijven
Gegevens gaan er als CSV in en komen er als CSV uit. Iemand exporteert, iemand importeert. Is een handmatige bestandsstap per cyclus onacceptabel, of eist uw inkoopproces een gecertificeerde koppeling met uw administratieve systeem, dan is dat een werkelijke mismatch en niet iets om omheen te werken.
U geen enkel zicht heeft op toekomstige vraag
De engine heeft per SKU enig vooruitzicht nodig. Dat hoeft niet geavanceerd te zijn — de verkopen van vorig jaar en een gevoel voor wat loopt zijn een begin, en forecasting is iets wat wij doen. Maar is er geen historie en geen beeld, dan is er niets om een buffer op te bepalen.
U het vandaag wilt kopen, zonder ons te spreken
Toegang gaat op uitnodiging en wij nemen steeds een klein aantal klanten aan. Er is geen registratieknop. Heeft u software nodig die u dit kwartaal zonder gesprek kunt aanschaffen, dan zijn wij dat niet.
Uw bestelbeslissing al goed werkt
Zijn nee-verkopen zeldzaam, houden uw langzame lopers geen geld vast dat u nodig heeft, en staat de logica ergens anders opgeschreven dan in één hoofd, dan lost u een probleem op dat u niet heeft. Dat zeggen wij liever vroeg.
Voor wie dit wel en niet is
Kort gezegd: honderden tot enkele duizenden SKU's, een ERP dat de voorraad bijhoudt terwijl de bestelbeslissing in een spreadsheet zit, en lead times die zo variëren dat een vast bestelpunt er telkens naast zit. De uitsluitingen staan hierboven en zijn het lezen waard vóór de lijst met wat wel past — die zijn namelijk de specifieke.
In één gesprek weet u of dit past
Vertel ons wat u verkoopt, ongeveer hoeveel SKU's, en bij wie u inkoopt. Wij zeggen u of dit past — ook wanneer dat niet zo is, en dat is vaak genoeg het antwoord om het vooraf te melden.