ERP mode collectieplanning: gids van ontwerp tot naorder
Artikel samenvatting
Hoe richt u collectieplanning in een ERP systeem voor de modebranche in?
Direct antwoord: Collectieplanning in een fashion ERP werkt pas wanneer collectiestructuur, inkoopbudget, voororders, naorders en NOS-artikelen op dezelfde style- en variantdata draaien. U bouwt eerst de structuur (seizoen, levering, productgroep, style en maat-kleur-matrix), legt daarna het Open-to-Buy-budget vast en laat verkoop- en voorraaddata de bijsturing voeden. Microsoft Dynamics 365 Business Central kan die basis vormen, aangevuld met een fashionlaag zoals itSuitsFashion 365 van TCOG.
- Begin bij de datastructuur, niet bij het planningsscherm.
- Een voororder is een verkoopbelofte, een naorder een correctie tijdens het seizoen, en NOS-artikelen volgen een eigen aanvulritme. Plan ze apart, maar op hetzelfde budget.
- Forecast op productgroep en style, en verdeel pas daarna naar kleur en maat.
- Overweegt u Business Central als basis? TCOG combineert blueprinting, implementatie en itSuitsFashion 365 in één traject voor modemerken, groothandels en fashionretailers.
Stel: het inkoopbudget voor het komende winterseizoen staat in het planningsbestand op een vast bedrag, terwijl de geplaatste inkooporders in het ERP systeem al duidelijk hoger uitkomen. Finance vraagt waar het verschil zit. Het antwoord ligt verspreid over een spreadsheet van de buyer, een export uit het agentenportaal en een paar mails met aangepaste aantallen (waarvan er één nog niet is doorgevoerd).
Precies daar draait ERP mode collectieplanning om. Een sluitende collectieplanning in een fashion ERP koppelt vijf dingen aan dezelfde style- en variantdata: de collectiestructuur, het inkoopbudget, de voororders, de naorders en de aanvulling van NOS-artikelen (never out of stock, de basics die het hele jaar beschikbaar horen te zijn). Draait dat op één databron, dan verdwijnt het verschil tussen plan en werkelijkheid niet, maar wordt het wel zichtbaar op het moment dat u er nog iets aan kunt doen.
Dat is de kern. Microsoft Dynamics 365 Business Central kan die basis leveren, mits u de modespecifieke laag goed inricht. Wie die laag overslaat, houdt een prima boekhoudpakket over met een collectieplanning ernaast in Excel.
Wat collectieplanning in een fashion ERP eigenlijk omvat
Collectieplanning is het vastleggen van wat u per seizoen ontwerpt, inkoopt, laat produceren en verkoopt, en hoeveel geld en voorraad daarbij hoort. In een ERP systeem staat die planning niet naast de operatie. Ze is de operatie, alleen in een vroeger stadium.
Alles begint bij de collectiestructuur. Een gangbare opbouw loopt van seizoen (zomer of winter, eventueel opgedeeld in tussenleveringen) naar collectie of lijn, dan naar productgroepen zoals broeken, knitwear of accessoires, en pas daarna naar de individuele style. Die hiërarchie oogt administratief, maar ze bepaalt welke vragen u later kunt beantwoorden: wilt u na het seizoen weten hoeveel marge knitwear in de tweede levering opleverde, dan moet die indeling er vanaf de eerste dag in zitten en niet achteraf in een rapport worden gereconstrueerd.
Een goede collectiestructuur werkt als de ladekast in een werkplaats. Elk onderdeel heeft één vaste plek, en wie een schroef zoekt, hoeft niet de hele kast om te keren.
Seizoensplanning legt daar een tijdlijn overheen. Denk aan de designfreeze, het moment waarop het lookbook naar agenten en groothandelsklanten gaat, de sluiting van het voorordervenster en de verwachte leverweken per productgroep. Wij raden aan die mijlpalen als gegevens in het systeem vast te leggen en niet alleen in een gedeelde agenda. Een agenda vertelt u wanneer iets moet gebeuren, uw ERP systeem kan u vertellen of het ook gebeurd is.
Styles, samples en de maat-kleur-materiaal-matrix
Hier wint of verliest u de rest van het seizoen.
Een style is het ontwerp: een jas, een jurk, een sneaker. Pas wanneer u daar kleuren, maten en soms materialen of pasvormen aan koppelt, ontstaan de verkoopbare varianten. Elke combinatie krijgt een eigen SKU (stock keeping unit, de kleinste eenheid waarop u voorraad bijhoudt) en meestal een eigen barcode. Een jas in vier kleuren en zes maten levert dus 24 SKU’s op. Met een extra materiaalvariant verdubbelt dat.
Die maat-kleur-materiaal-matrix moet in uw systeem ook als matrix te bedienen zijn. Een inkoper die 600 stuks over 24 varianten verdeelt, wil dat in één raster invullen en niet in 24 aparte orderregels. Lukt dat in uw huidige omgeving niet, dan belandt het werk onvermijdelijk weer in een spreadsheet.
Samples verdienen een eigen plek in het proces. In de showroom hangt een sample met een kartonnen label en een werkcode, terwijl de productieversie later een definitieve stylecode krijgt. Die style- en SKU-mapping (welke sample hoort bij welke style, en welke style bij welke SKU’s in de webshop en bij de leverancier) is saai werk met grote gevolgen. Een blazer die in de showroom ‘Antwerpen navy’ heet, in het ERP systeem een cijfercode draagt en in de webshop een naam heeft die alleen marketing nog herkent: zo ontstaan dubbele artikelen en voororders die bij de verkeerde productierun terechtkomen.
Slaat u de samplefase in het systeem over, dan verliest u ook de koppeling tussen samplekosten en de uiteindelijke marge per style.
Inkoopbudgetten en Open-to-Buy: hoeveel mag u nog inkopen?
Open-to-Buy (OTB) is het bedrag dat u in een periode nog mag inkopen nadat de geplaatste orders zijn afgetrokken van het geplande inkoopbudget. Dat geplande budget volgt doorgaans uit verwachte verkoop, verwachte afprijzingen en de gewenste eindvoorraad, verminderd met de voorraad waarmee u het seizoen start.
In een spreadsheet is dat een formule. In een ERP systeem wordt het een levend getal, omdat elke bevestigde inkooporder, elke geannuleerde productie en elke ontvangst het saldo direct bijwerkt. Dat is het verschil tussen een financieel manager die achteraf een verklaring krijgt en een financieel manager die halverwege de inkoopronde al een signaal ziet.
Ons advies: budgetteer op productgroep per levering, niet op style. Op style-niveau is een budget vooraf vooral gokwerk, en uw buyer verliest de ruimte om binnen een groep te schuiven wanneer een kleur in de showroom onverwacht aanslaat. Er is één uitzondering. Bij grote NOS-programma’s of private-labelorders met vaste afnameafspraken kan een budget per style wel zinvol zijn, omdat de volumes daar voorspelbaar genoeg zijn.
Nog een praktisch punt. Leg vast in welke valuta en tegen welke koers het budget is opgesteld, want een inkoopronde die in dollars wordt geplaatst en in euro’s is gebudgetteerd, wijkt anders al af voordat er één stuk is geleverd.
Voororder, naorder en NOS: drie ritmes in één planning
Veel modebedrijven behandelen voororders, naorders en NOS-aanvulling als één inkoopstroom met verschillende deadlines. Dat klopt maar half. Het zijn drie ritmes, elk met een andere informatiebron en een ander risico, en de tabel hieronder zet ze naast elkaar.
| Ritme | Wat het ERP systeem moet vastleggen | Typisch risico |
|---|---|---|
| Voororder (pre-order) | Orders van retailers, agenten of eindklanten per style en variant, gekoppeld aan een leverperiode, nog vóór productie | Toezeggingen worden niet teruggekoppeld naar productieaantallen, waardoor u te krap of te ruim bestelt |
| Naorder (re-order) | Bijbestellingen tijdens het seizoen op basis van verkoopcijfers en beschikbare leverancierscapaciteit | Te laat gesignaleerd: tegen de tijd dat de goederen binnen zijn, is de vraag voorbij |
| NOS en replenishment | Minimum- en maximumvoorraad, levertijden en aanvulregels per SKU, los van de seizoenscyclus | NOS-artikelen lopen mee in het seizoensbudget en worden afgeprijsd alsof het seizoensartikelen zijn |
Wat de drie verbindt, is de voorraad. Een voororder claimt toekomstige voorraad, een naorder vult die tijdens het seizoen aan en replenishment houdt een bodem vast. Draaien ze op hetzelfde artikel- en variantniveau, dan ziet u op één scherm hoeveel van een SKU besteld, verkocht, onderweg en nog vrij is. Draaien ze apart, dan verkoopt uw webshop soms stuks die al aan een groothandelsklant beloofd zijn.
Een voororderboek is een beetje als een reserveringslijst in een restaurant: het zegt hoeveel gasten u verwacht, niet hoeveel er werkelijk komen opdagen. Annuleringen en verschoven leveringen horen daarom als eigen status in het systeem, niet als een stilletjes verwijderde orderregel.
Forecasting per stijl, maat en kleur zonder schijnprecisie
Forecast eerst op het niveau waar u voldoende historie heeft, en verdeel daarna naar beneden. Een nieuwe style heeft per definitie geen verkoopgeschiedenis, dus een voorspelling op SKU-niveau voor die style is een getal met veel decimalen en weinig waarde.
Een werkbare volgorde loopt van productgroep per levering, via vergelijkbare styles uit eerdere seizoenen, naar kleur en ten slotte naar maat. Voor die laatste stap gebruikt u een maatcurve: de historische verdeling van verkopen over maten binnen een productgroep. Die curve kan per kanaal verschillen (de webshop trekt mogelijk een ander publiek dan de winkel in het stadscentrum), dus het loont om dat in uw eigen data na te gaan voordat u één curve voor alles hanteert.
Een weerbericht voor de hele provincie is betrouwbaarder dan een voorspelling voor uw eigen tuin. Hier geldt hetzelfde.
De data die deze curves voedt, komt steeds vaker van buiten de winkel. Webshop- en marktplaatsorders moeten op dezelfde SKU binnenkomen als de kassaverkoop en de groothandelsorder, inclusief retouren en retourredenen. Een maat die vaak terugkomt met de reden ‘valt klein’, vertelt uw planner meer dan de bruto verkoop van die maat. Hoe u kassa, webshop en magazijn op één voorraad laat draaien, werkten we eerder uit in ons artikel over omnichannel retail met ERP, POS, webshop en magazijn, en dat fundament heeft uw forecasting nodig voordat een algoritme er iets zinnigs mee kan.
Een bruikbare vuistregel om mee te starten: herzie de maatcurve elk seizoen, maar pas de verdeling over productgroepen pas aan wanneer de afwijking twee seizoenen op rij in dezelfde richting gaat.
ERP mode collectieplanning in Business Central: checklist en valkuilen
Microsoft Dynamics 365 Business Central is geen fashionpakket uit de doos, en dat hoeft ook niet. De standaardsoftware van Microsoft kent onder meer artikelvarianten, artikelcategorieën en -attributen, raamorders, budgetten en planningsvoorstellen. Dat is een solide basis voor inkoop, voorraadbeheer en financieel management. Voor seizoenen, leveringen, matrixinvoer en maatcurves zoeken de meeste modebedrijven een fashionlaag bovenop die basis, en TCOG ontwikkelde daarvoor itSuitsFashion 365. Welke onderdelen standaard, via die laag of via maatwerk worden ingevuld, laat u best tonen in een demo op uw eigen collectiedata.
Gebruik onderstaande checklist om te toetsen of uw huidige of toekomstige omgeving klaar is voor collectieplanning:
- Collectiestructuur als velden. Seizoen, levering, productgroep en style zijn zoek- en filterbare gegevens, geen onderdelen van een artikelomschrijving.
- Kan uw inkoper een order in één raster over maat en kleur verdelen?
- Elke sample krijgt een code die later naar een style verwijst.
- Open-to-Buy wordt automatisch bijgewerkt bij bevestiging, annulering en ontvangst van inkooporders. Over deze stap ontstaat vaak de meeste discussie, omdat finance en buying elk een eigen definitie van ‘besteld’ hanteren. Spreek vooraf af welke orderstatus meetelt.
- Voororders, naorders en NOS-aanvulling zijn als aparte ordersoort of markering herkenbaar.
- Retouren uit webshop en marktplaatsen: komen die op SKU-niveau terug in de voorraad, met reden?
- Een dashboard (bijvoorbeeld in Power BI) toont plan versus werkelijkheid per productgroep en levering.
Dat laatste punt vraagt geen apart BI-project op dag één. Power BI maakt deel uit van het Microsoft Power Platform en kan rechtstreeks op Business Central-data draaien, zodat u kunt beginnen met één rapport dat buying en finance allebei vertrouwen.
Waar trajecten op vastlopen
De zwaarste fout is oude artikelcodes één op één migreren. In veel oudere systemen zitten maat en kleur verstopt in de artikelomschrijving of in een codeconventie die alleen de collega van inkoop nog kan lezen. Neemt u dat mee naar een nieuw systeem, dan erft u alle beperkingen van het oude: geen echte matrix, geen betrouwbare maatcurve en geen koppeling tussen style en SKU. Herstructureren kost tijd vóór de livegang. Niet herstructureren kost tijd in elk seizoen daarna.
Een tweede valkuil is starten bij het planningsscherm. Een mooi plannerscherm op slordige stamdata levert vooral sneller foute antwoorden op.
De derde is minder zichtbaar: niemand is eigenaar van de artikelstamdata. Wanneer design, inkoop en e-commerce allemaal velden mogen aanpassen zonder afspraken, vervuilt de structuur binnen één seizoen. Een blueprinttraject (een vooraf uitgewerkte blauwdruk van processen, rollen, scope en software) dwingt u die eigenaarschapsvraag te beantwoorden voordat er een regel wordt geconfigureerd, en dat is goedkoper dan dezelfde discussie midden in de inkoopronde.
Waar TCOG instapt in uw collectieproces
De vraag die modebedrijven bij TCOG meestal meebrengen, is zelden ‘welk pakket?’ en vaker ‘waarom klopt ons budget niet met onze orders?’. TCOG is een ERP specialist voor Fashion, Retail, Hospitality en Industry, met meer dan 225 klanten in de Benelux en 90+ industry experts verspreid over vier kantoren in drie landen. Als Microsoft Solutions Partner voor Business Applications implementeert TCOG Business Central (de software zelf wordt ontwikkeld door Microsoft) en vult die aan met itSuitsFashion 365, de eigen fashionoplossing van TCOG.
Voor collectieplanning betekent dat concreet: een blueprint en fit/gap-analyse waarin uw collectiestructuur, budgetlogica en orderritmes worden uitgetekend, gevolgd door implementatie, datamigratie van uw bestaande artikelen en training van buyers, planners en finance. Na de livegang kan een Continuous Improvement SLA (Service Level Agreement) de omgeving per seizoen verder bijschaven, wat bij collectieplanning zinvol is omdat elk seizoen nieuwe lessen oplevert. Meer over de ERP-basis zelf vindt u op de pagina over Microsoft Dynamics 365 Business Central.
Werkt u met meerdere entiteiten, magazijnen of verkoopkanalen, dan weegt die combinatie van branchekennis en integratie zwaarder dan een losse planningstool. Het collectieplan raakt dan immers ook intercompanyorders, logistiek en de voorraad die uw webshop toont, en die schakels moeten in hetzelfde systeem kloppen.
Veelgestelde vragen over ERP mode collectieplanning
Wat is collectieplanning in een ERP voor de modebranche?
Collectieplanning in een ERP systeem is het vastleggen van collectiestructuur, inkoopbudget, voororders, naorders en NOS-aanvulling op dezelfde style- en variantdata. Daardoor sluiten plan, inkoop, voorraad en verkoop op elkaar aan in plaats van in losse bestanden.
Welke ERP functionaliteiten heeft u minimaal nodig voor seizoensplanning?
U heeft minimaal een collectiehiërarchie met seizoen, levering en productgroep nodig, plus varianten per maat en kleur die als matrix in te voeren zijn. Een Open-to-Buy-berekening die automatisch meebeweegt met inkooporders hoort er ook bij. Verder moet het systeem voororders, naorders en NOS-artikelen van elkaar kunnen onderscheiden. Rapportage van plan versus werkelijkheid per productgroep maakt het geheel bruikbaar voor finance.
Hoe ondersteunt een ERP systeem voororders, naorders en NOS-artikelen?
Een ERP systeem legt voororders vast als toekomstige verkoop per variant en leverperiode, verwerkt naorders als aanvulling tijdens het seizoen en beheert NOS-artikelen met minimum- en maximumvoorraad per SKU. Omdat alle drie op dezelfde voorraad draaien, ziet u per SKU wat besteld, onderweg en vrij is.
Kan Microsoft Dynamics 365 Business Central collectieplanning voor modebedrijven ondersteunen?
Ja, als basis wel. Business Central biedt standaard onder meer artikelvarianten, budgetten, raamorders en planningsvoorstellen. Voor modespecifieke onderdelen zoals seizoenen, leveringen en matrixinvoer wordt het doorgaans aangevuld met een fashionoplossing zoals itSuitsFashion 365. Toets in een demo op uw eigen data welke onderdelen standaard zijn en welke via die aanvulling lopen.
Hoe nauwkeurig is forecasting per maat en kleur?
Op SKU-niveau is een forecast voor nieuwe styles beperkt betrouwbaar, omdat er geen verkoophistorie is. Forecast daarom op productgroep en style, en verdeel naar maat met een historische maatcurve.
Hoe lang duurt het om collectieplanning in een fashion ERP in te voeren?
Dat hangt sterk af van de staat van uw artikeldata, het aantal kanalen en entiteiten en de integraties met webshop en marktplaatsen. Een vast aantal maanden is vooraf niet eerlijk te geven. Wel helpt het om de livegang te plannen rond een seizoenswissel, zodat een nieuwe collectie meteen in de nieuwe structuur start. Een blueprint vooraf geeft u een onderbouwde planning voor uw eigen situatie.
Wat betekent dit voor uw volgende seizoen?
Een collectieplan wordt pas betrouwbaar wanneer budget, orders en voorraad naar dezelfde style en SKU verwijzen, en dat begint bij de structuur van uw artikeldata, niet bij de planningstool. Een goede eerste stap: neem één productgroep uit het lopende seizoen en probeer voor die groep plan, geplaatste orders en werkelijke verkoop naast elkaar te leggen. Waar dat vastloopt, ligt het startpunt voor uw ERP mode collectieplanning.
