Een multilevel BoM in Odoo klinkt op het eerste gezicht als een technisch detail voor productiebedrijven met complexe structuren. In werkelijkheid gaat het over iets veel concreters: voorkomen dat je planning vastloopt omdat halffabricaten, lead times en bevoorrading niet op het juiste niveau worden beheerd. Zodra een tussenproduct in meerdere eindproducten terugkomt, wordt een gewone stuklijst te plat. Dan wil je subassemblies apart plannen, apart aanvullen en toch gecontroleerd laten aansluiten op het eindproduct. Precies daar krijgt een multilevel BoM in Odoo zijn waarde voor bedrijven die sneller willen groeien zonder extra ruis in manufacturing orders, voorraadreserveringen en doorlooptijden.
Veel teams proberen te lang te werken met één grote BoM waarin alles tegelijk wordt opgenomen. Dat lijkt overzichtelijk, tot dezelfde module in verschillende eindproducten terugkomt, een eigen doorlooptijd krijgt of op een aparte werkpost gebouwd wordt. De officiële Odoo 19-documentatie over multilevel BoMs beschrijft dit scenario duidelijk: zodra een geproduceerd product zelf onderdeel wordt van een andere assemblage, wordt een gelaagde structuur zinvol. Dat past logisch binnen wat Odoo ERP precies is: één omgeving waarin data, planning en uitvoering samenkomen in plaats van naast elkaar te blijven bestaan.
Wat maakt een multilevel BoM in Odoo anders dan een gewone stuklijst?
Een gewone BoM beschrijft welke componenten nodig zijn om één product te bouwen. Een multilevel BoM in Odoo gaat een stap verder en bouwt niveaus op elkaar. Een subassembly krijgt dan een eigen productkaart, een eigen BoM en vaak ook een eigen replenishment- of productielogica. Daardoor stuur je niet langer één platte lijst met onderdelen aan, maar een hiërarchie van bouwblokken die elk hun eigen betekenis hebben. Die aanpak wordt relevant zodra hetzelfde halffabricaat in meerdere eindproducten terugkomt of zodra een tussenproduct zelfstandig gepland, opgevolgd of getraceerd moet worden. Net dan toont een multilevel BoM in Odoo waarom een gelaagd model meer doet dan een gewone stuklijst. Odoo positioneert multilevel BoMs precies voor die gevallen waarin de klassieke, vlakke structuur te weinig grip geeft op hergebruik en timing.
Operationeel betekent dit dat je minder afhankelijk wordt van impliciete kennis op de werkvloer. In plaats van te vertrouwen op medewerkers die wel weten welke onderdelen samen een tussenproduct vormen, laat je Odoo dat niveau expliciet beheren. Zo ontstaat meer herbruikbaarheid, minder dubbel onderhoud en een betere basis om productie, kost en capaciteit later verder te analyseren. Dat sluit ook logisch aan bij Odoo Inventory en magazijnbeheer, omdat een correcte gelaagde productstructuur pas echt rendeert wanneer voorraad- en productielogica elkaar versterken.
Wanneer subassemblies in Odoo echt logisch worden
Niet elk bedrijf heeft meteen nood aan subassemblies in Odoo. Voor eenvoudige assemblages met weinig variatie en zonder terugkerende tussenproducten volstaat een vlakke structuur vaak perfect. Het kantelpunt komt wanneer een tussenproduct een eigen beheersvraagstuk krijgt. Dat is bijvoorbeeld het geval wanneer dezelfde module in meerdere eindproducten terugkomt, wanneer een halffabricaat een eigen productie- of aankoopritme heeft, of wanneer je dat niveau apart wilt opvolgen voor kwaliteit, capaciteit of traceerbaarheid. In zulke situaties wordt een multilevel BoM in Odoo geen over-engineering, maar net een manier om de realiteit correct te modelleren.
Wij vinden drie signalen bijzonder bruikbaar. Eén: hetzelfde tussenproduct zit in meerdere eindproducten. Twee: het subniveau heeft een eigen doorlooptijd of eigen leveranciersafhankelijkheid. Drie: je wilt op dat niveau zicht op kwaliteit, voorraad of productieflow. Zodra minstens twee van die drie signalen aanwezig zijn, loont het meestal om subassemblies in Odoo apart te modelleren. Werk je dan toch met één vlakke BoM, dan verschuif je het echte probleem alleen maar naar de werkvloer. Het systeem blijft simpel, maar de operatie wordt vager. Wie later ook traceerbaarheid of kwaliteitsbeheer op dat niveau wil aanscherpen, merkt dan snel dat de structuur te weinig fijnmazig is.
Een multilevel BoM in Odoo bouw je bottom-up, niet top-down
Een van de belangrijkste inzichten uit de officiële Odoo-documentatie is dat je een multilevel BoM in Odoo van onder naar boven opbouwt. Odoo zegt expliciet dat je, als je van nul start, eerst de laagste productniveaus en hun BoMs moet maken en die daarna pas als componenten in hogere niveaus moet opnemen. Dat lijkt een technische opmerking, maar het is in werkelijkheid een heel praktische ontwerpregel. Wie top-down vertrekt, heeft de neiging om het eindproduct snel werkend te maken en onderliggende niveaus later te verfijnen. Dat leidt bijna altijd tot tijdelijke workarounds die blijven hangen en uiteindelijk voor onduidelijke planning zorgen.
Bottom-up werken geeft meer rust. Je begint met de componentproducten, maakt daarna de subassemblies als aparte producten, voegt daarvoor hun BoMs toe, en herhaalt dat tot elk niveau logisch staat. Pas daarna stel je routes, lead times en eventuele operations in. Door zo te werken, behoud je controle over wat een tussenproduct echt is, hoe het aangevuld moet worden en wanneer het beschikbaar moet zijn. Odoo beschrijft die volgorde niet voor niets als de juiste basis voor multilevel BoMs. Het maakt je model schaalbaarder en voorkomt dat je later aan de bovenkant probeert te herstellen wat onderaan nooit goed was opgezet.
Zo maak je semi-finished products in Odoo beheersbaar zonder extra ruis
De term semi-finished products klinkt misschien formeler dan de dagelijkse praktijk, maar het gaat meestal gewoon over halffabricaten of voorgemonteerde modules die later in een groter product terugkomen. In een multilevel BoM in Odoo zijn die semi-finished products precies de niveaus waar de grootste winst zit. Zodra je ze als volwaardige subassemblies behandelt, kun je voorraad, timing en hergebruik op dat niveau veel beter sturen. Odoo koppelt Days to prepare Manufacturing Order zelfs expliciet aan de tijd die nodig is om componenten aan te vullen of semi-finished products te maken. Dat bevestigt hoe centraal dat tussenniveau in de planning staat.
De fout die hier vaak gemaakt wordt, is dat teams halffabricaten wel fysiek herkennen, maar ze digitaal toch blijven behandelen als losse componenten. Daardoor verdwijnen eigen lead times, eigen routes en eigen work center-logica in het grotere geheel. Het resultaat is voorspelbaar: productie lijkt eenvoudiger in het systeem dan in de realiteit. Wie semi-finished products in Odoo serieus neemt, bouwt niet per se meer complexiteit in, maar selecteert precies waar aparte logica zinvol is. Dat is een andere oefening dan de bredere stuklijstlogica uit blogpost 1. Daar ging het over de kwaliteit van de BoM zelf; hier draait het over de vraag wanneer een productniveau genoeg operationele betekenis heeft om als eigen subassembly beheerd te worden.
Reordering rules of MTO in een multilevel BoM in Odoo
Bij subassemblies in Odoo komt de echte planningsvraag snel boven: hoe moet het systeem tussenproducten aanvullen? Odoo noemt twee bruikbare paden. Het eerste, en ook het aanbevolen pad, is werken met reordering rules op subniveau, vaak in een 0/0/1-configuratie. Het tweede pad is Replenish on Order, dus MTO, gecombineerd met de Manufacture-route. De documentatie over multilevel BoMs noemt de 0/0/1-reorderingregel expliciet de aanbevolen productielogica voor sublevel producten, ongeacht of het om een component of een subassembly gaat. Dat is een sterke aanwijzing dat Odoo voor herbruikbare tussenproducten eerder voorraadgestuurde flexibiliteit verkiest dan een strikte één-op-één-koppeling per bovenliggend order.
De documentatie over MTO maakt tegelijk duidelijk dat die route alleen werkt wanneer ook een tweede route actief is, zoals Buy of Manufacture, en dat je eerst de Multi-Step Routes-feature moet inschakelen. Dat maakt MTO bruikbaar, maar ook specifieker dan veel teams denken. Voor subassemblies in Odoo die over meerdere eindproducten heen ingezet kunnen worden, zijn reordering rules meestal rustiger. Voor ordergebonden productie, waar je absoluut geen hergebruik van tussenvoorraad wilt, kan MTO wel logisch zijn. Die keuze is belangrijker dan ze lijkt, want ze bepaalt of je planning op subniveau flexibel of strikt ordergeketend wordt.
Waarom 0/0/1 in een multilevel BoM in Odoo slimmer is dan het lijkt
Een 0/0/1-reorderingregel oogt op papier vreemd. Minimum nul, maximum nul en automatisch één aanvullen klinkt alsof er nauwelijks sturing is. Toch is precies dat de logica die Odoo aanbeveelt voor sublevel producten in een multilevel BoM in Odoo. Het idee is niet dat je klassieke veiligheidsvoorraad opbouwt, maar dat Odoo onmiddellijk één aanvulactie kan voorstellen of creëren zodra forecasted stock onder nul zakt. Op die manier vang je vraag naar subassemblies in Odoo op zonder die voorraden te zwaar te koppelen aan één specifiek bovenliggend order. Dat maakt het een elegante middenweg tussen pure forecaststuring en strikte MTO-logica.
In de praktijk geeft dit meer manoeuvreerruimte dan veel mensen verwachten. Stel dat dezelfde motorunit of kabelboom in verschillende eindproducten wordt gebruikt. Met een 0/0/1-regel kun je snel laten aanvullen zodra echte vraag ontstaat, terwijl je toch flexibiliteit bewaart om prioriteiten later nog te verschuiven. Dat maakt deze aanpak vaak geschikter voor kmo’s dan MTO, zeker wanneer planningen regelmatig moeten worden herschikt. Wie verder wil denken over replenishmentlogica en stockgedrag, ziet hier ook een link met bevoorrading in Odoo voor groothandels, al ligt de focus hier specifiek op productie en subniveaus.
Lead times maken of breken je multilevel BoM in Odoo
Een multilevel BoM in Odoo werkt alleen goed als lead times op de juiste niveaus ingesteld zijn. Dat geldt zowel voor ingekochte onderdelen als voor intern geproduceerde subassemblies in Odoo. Zodra een kritisch tussenproduct zelf weer afhankelijk is van aangekochte of geproduceerde onderdelen, krijg je een keten van afhankelijkheden die je niet meer betrouwbaar kunt plannen met alleen globale aannames. Odoo legt in zijn lead time-documentatie uit hoe vendor lead times, purchase security lead times, days to purchase, manufacturing lead times en Days to prepare Manufacturing Order samen bepalen wanneer een product of productieorder realistisch kan starten of geleverd worden. Dat is precies waarom multilevel plannen meer is dan alleen BoMs op elkaar stapelen.
Vooral Days to prepare Manufacturing Order is hier essentieel. Odoo zegt expliciet dat je dit veld op de Miscellaneous-tab van de BoM gebruikt om kalenderdagen te reserveren om componenten aan te vullen of semi-finished products te maken. Laat je dat leeg terwijl je subassemblies wel degelijk tijd vragen, dan lijkt je top-level planning sneller dan ze werkelijk is. Het gevolg is dat eindproducten te vroeg startklaar lijken en child manufacturing orders te laat zichtbaar worden. Wie later ook op cijfers wil sturen, ziet dat meteen terug in een Odoo KPI-dashboard voor kmo’s: beloofde data en werkelijke flow beginnen dan uit elkaar te lopen.
Vergeet de openingsvoorraad van subassemblies in Odoo niet
Veel problemen rond subassemblies in Odoo ontstaan niet door de structuur zelf, maar door de uitgangspositie waarmee je start. Odoo raadt expliciet aan om de quantity on hand te actualiseren voor componenten, subassemblies en het eindproduct wanneer je een multilevel BoM in Odoo opzet. Dat lijkt administratief, maar het bepaalt rechtstreeks of Odoo onnodige manufacturing orders creëert of net te weinig vraag ziet. Als bestaande halffabricaten al fysiek op voorraad liggen, maar in Odoo nog niet als apart niveau bestaan, moet je die voorraad na de nieuwe modellering ook op het juiste productniveau zichtbaar maken. Doe je dat niet, dan simuleert Odoo een schaarste die in de werkelijkheid niet bestaat.
Dit punt is vooral belangrijk bij migraties of bij een eerste professionalisering van manufacturingdata. In veel bedrijven bestaan semi-finished products al jaren op de vloer, maar zijn ze nooit als aparte producten in ERP geregistreerd. Zodra je ze wel in een multilevel BoM in Odoo opneemt, verandert ook je databeheer. Dan wordt openingsvoorraad ineens een actieve factor in de planning. Dat is een typisch voorbeeld van waarom productiedata en bredere datadiscipline samen horen. Wie daar te licht over gaat, botst later vaak op problemen die eigenlijk weinig met Odoo te maken hebben en veel met masterdata, iets wat ook herkenbaar is in data governance-regels in Odoo voor kmo’s.
Operations en work centers geven subassemblies in Odoo echte betekenis
Een multilevel BoM in Odoo is veel sterker wanneer subassemblies niet alleen materiaalstructuren zijn, maar ook een eigen productieflow hebben. Odoo laat toe om op de Operations-tab van een BoM werkstappen toe te voegen en die aan work centers te koppelen, op voorwaarde dat de Work Orders-setting geactiveerd is. De documentatie rond work centers bevestigt bovendien dat werkcentra pas zichtbaar worden wanneer Work Orders in Manufacturing > Configuration > Settings aanstaan. Vanaf daar kun je operations koppelen, capaciteiten opvolgen en verschillende werkzones of shifts apart structureren. Dat maakt van een subassembly een echt bestuurbaar productieniveau, niet alleen een administratief tussenblok. Voor teams die dagelijks met subassemblies werken, is dat verschil meteen voelbaar in planning en capaciteit.
Net die laag maakt het verschil tussen een model dat alleen technisch correct is en een model dat de werkvloer echt helpt. Wanneer kabelbomen, voormontages of testmodules elk een eigen werkpost en timing hebben, wil je dat Odoo dat ook ziet. Anders gebruik je het systeem wel voor manufacturing, maar stuur je eigenlijk nog altijd op impliciete kennis. Zodra operations en work centers goed staan, wordt het ook makkelijker om bottlenecks te begrijpen en shop floor discipline op te bouwen. Dat helpt niet alleen in productie, maar later ook in Odoo performance-optimalisatie, omdat minder workarounds bijna altijd leiden tot minder ruis en minder frictie in de dagelijkse uitvoering.
Waarom kits en multilevel productie niet hetzelfde zijn
Een fout die regelmatig terugkomt, is dat teams kits en subassemblies in Odoo door elkaar halen. Odoo beschrijft kits als sets van niet-geassembleerde componenten die verkocht kunnen worden. Ze zijn nuttig voor bundels of voor situaties waarin je componenten als één geheel wilt beheren zonder een klassieke interne productieflow op te zetten. Dat is iets heel anders dan een subassembly die je echt intern produceert, plant, aanvult en eventueel via work orders opvolgt. In een multilevel BoM in Odoo zijn subassemblies dus geen commerciële bundels, maar echte tussenproducten met hun eigen rol in de manufacturinglogica.
Het onderscheid is belangrijk omdat de verkeerde keuze de hele planning scheeftrekt. Gebruik je een kit waar eigenlijk een echte subassembly nodig is, dan verlies je zicht op productie, tijd en doorlooptijd. Gebruik je kits waar subassemblies thuishoren, dan verwatert ook de logica van je onderliggende productieflow. Gebruik je een subassembly waar eigenlijk alleen een bundel nodig is, dan maak je het systeem nodeloos zwaar. In deze blogpost ligt de focus bewust op productiehiërarchie, child manufacturing orders en replenishment op subniveau. Dat houdt de pagina duidelijk gescheiden van de bredere stuklijstpagina en helpt tegelijk om interne kannibalisatie te vermijden.
MPS in een multilevel BoM in Odoo: nuttig, maar niet boven op dezelfde reordering rules
Sommige productiebedrijven proberen extra grip te krijgen door tegelijk reordering rules, MTO en Master Production Schedule te combineren op dezelfde producten. Dat maakt een multilevel BoM in Odoo zelden rustiger. Odoo waarschuwt in zijn MPS-documentatie expliciet dat MPS niet naast reordering rules voor hetzelfde product gebruikt moet worden, omdat de geautomatiseerde logica van reordering rules botst met de manuele replenishmentmethode van MPS. Dat kan leiden tot onnauwkeurige forecasts en onnodige replenishment orders. MPS heeft dus zeker een plaats, maar alleen wanneer je helder beslist op welk niveau je manueel vooruit plant en op welk niveau je het systeem automatisch laat aanvullen.
Voor veel kmo’s betekent dit dat MPS vooral nuttig wordt voor bovenliggende productfamilies of seizoensgevoelige stromen, terwijl subassemblies in Odoo op lager niveau net veel beter werken met reordering rules. Een multilevel BoM in Odoo blijft dan overzichtelijker, omdat je automatische en manuele logica niet op hetzelfde niveau door elkaar laat lopen. Wie die twee zonder duidelijke grens door elkaar gebruikt, krijgt dubbelsturing in plaats van rust. Dat is een belangrijk verschil met blogpost 1: daar lag de nadruk op BoM-kwaliteit en foutpreventie in de structuur zelf, terwijl deze pagina draait rond de planning van subniveaus, semi-finished products en replenishmentlogica voor herbruikbare modules.
De fouten die een multilevel BoM in Odoo onnodig complex maken
De eerste fout is alles als subassembly modelleren. Niet elk logisch blok verdient een apart productniveau. De tweede fout is precies het omgekeerde: echte halffabricaten toch als losse componenten laten staan, waardoor lead times, hergebruik en planning onzichtbaar blijven. Een derde fout is op elk niveau dezelfde route toepassen zonder na te denken over flexibiliteit, orderkoppeling en voorraadgedrag. Een vierde fout is operations buiten de subassemblies in Odoo houden terwijl ze op de werkvloer wel degelijk een eigen werkstap of eigen capaciteit vragen. En een vijfde fout is beginnen modelleren zonder bestaande voorraad, lead times en routes mee op te kuisen.
Wat al die fouten gemeen hebben, is dat ze vaak niet meteen als fout aanvoelen. Het systeem werkt nog net genoeg om mee verder te doen. Precies daardoor blijven zwakke keuzes te lang staan. Ondertussen stijgen manuele ingrepen, worden planningen minder geloofwaardig en verschuift de echte complexiteit opnieuw naar mensen. Een multilevel BoM in Odoo hoort dus niet alleen netjes te zijn op papier, maar ook rust te brengen op de vloer. Zodra extra niveaus vooral extra twijfel opleveren, is dat meestal een signaal dat de structuur niet op de goede operationele grens getekend is.
Een praktisch besliskader voor subassemblies in Odoo
Als je vandaag één productfamilie moet beoordelen, begin dan niet met velden, maar met vragen. Komt dit tussenproduct in meerdere eindproducten terug? Heeft het een eigen doorlooptijd, eigen aankoopmix of eigen werkpost? Wil je het niveau apart plannen, meten of quality-checken? En moet je de voorraad van dat tussenproduct apart kunnen zien? Als het antwoord op meerdere van die vragen ja is, dan is een multilevel BoM in Odoo meestal logisch. Is het antwoord bijna overal nee, dan is een vlakke structuur vaak beter. Dat besliskader klinkt eenvoudig, maar voorkomt veel onnodige detailcomplexiteit. Zo blijft een multilevel BoM in Odoo een hulpmiddel voor orde in plaats van een bron van extra administratieve ruis.
Start daarna klein. Kies één productfamilie waar hergebruik en terugkerende planningsproblemen het duidelijkst zijn. Definieer daar de echte subassemblies in Odoo, zet de juiste routes, werk de openingsvoorraad bij en voeg pas daarna lead times en operations toe. Op die manier test je niet alleen of de structuur technisch klopt, maar ook of ze rust brengt in de dagelijkse planning. Dat is uiteindelijk de beste maatstaf: een multilevel BoM in Odoo is pas geslaagd als hij minder improvisatie vraagt en meer voorspelbaarheid geeft in plaats van enkel meer niveaus in je systeem te tonen.
Conclusie: een multilevel BoM in Odoo brengt geselecteerde orde
Een multilevel BoM in Odoo voegt alleen waarde toe wanneer hij echte complexiteit beter ordent. Dat geldt zeker in omgevingen waar subassemblies, halffabricaten en hergebruik samen bepalen hoe stabiel je planning wordt. Doe je het goed, dan krijg je meer herbruikbaarheid, betere replenishmentkeuzes, realistischere lead times en meer zicht op semi-finished products die anders verstopt blijven in een vlakke structuur. Doe je het half, dan creëer je vooral extra niveaus zonder echte winst. De kernvraag is dus niet of Odoo technisch meerdere niveaus aankan. De kernvraag is of je subassemblies in Odoo zo wilt modelleren dat planning, uitvoering en voorraad elkaar op het juiste niveau beginnen te versterken.
Precies daar ligt de meerwaarde van dit onderwerp ten opzichte van een bredere BoM-pagina. Een multilevel BoM in Odoo is dus geen variant op dezelfde uitleg, maar een eigen ontwerpvraagstuk binnen manufacturing. Blogpost 1 helpt begrijpen waarom een goede stuklijst belangrijk is. Deze pagina gaat een stap dieper en focust op het moment waarop een gewone BoM te vlak wordt en een multilevel BoM in Odoo nodig is om subassemblies zonder planningschaos te beheren. Voor productiebedrijven die worstelen met hergebruik, halffabricaten en timing is dat geen theoretische nuance, maar vaak het verschil tussen reactief plannen en gecontroleerd bouwen.
Veel gestelde vragen
Wat is het verschil tussen een multilevel BoM in Odoo en een gewone stuklijst?
Een gewone stuklijst beschrijft welke onderdelen nodig zijn om één product te bouwen. Een multilevel BoM in Odoo werkt met meerdere niveaus, waarbij halffabricaten of subassemblies zelf ook een eigen productkaart, BoM en vaak een eigen aanvul- of productielogica krijgen. Daardoor kun je tussenproducten apart plannen, apart opvolgen en hergebruiken in meerdere eindproducten. Dat is vooral nuttig wanneer hetzelfde tussenproduct terugkomt in verschillende assemblages of wanneer lead times, voorraad en werkstappen op dat subniveau apart betekenis krijgen. Een vlakke structuur blijft bruikbaar voor eenvoudige assemblages, maar verliest snel grip zodra productie meerlagig wordt.
Wanneer kies je in Odoo beter voor reordering rules dan voor MTO bij subassemblies?
Reordering rules zijn meestal de beste keuze wanneer een subassembly flexibel over meerdere orders of meerdere eindproducten heen ingezet wordt. Odoo raadt voor multilevel structuren zelfs expliciet een 0/0/1-reorderingregel aan, omdat die vraag opvangt zonder tussenvoorraad te strak aan één bovenliggend order te koppelen. MTO past beter wanneer je een strikte één-op-één-relatie wilt tussen vraag en aanvulling, bijvoorbeeld bij ordergebonden productie of wanneer hergebruik van tussenproducten niet gewenst is. In de meeste kmo-scenario’s met herbruikbare modules geven reordering rules meer rust, terwijl MTO vooral zinvol is in uitzonderingen met heel specifieke orderdiscipline.
Hoe pak je datamigratie aan als je bestaande halffabricaten als subassemblies in Odoo wilt beheren?
De veiligste aanpak is om eerst te bepalen welke halffabricaten echt een eigen beheersvraagstuk hebben. Daarna maak je voor die niveaus aparte producten en BoMs aan, en actualiseer je meteen de openingsvoorraad. Dat laatste is cruciaal, omdat Odoo anders onterecht kan aannemen dat alles nog geproduceerd moet worden. Werk vervolgens routes, lead times en eventuele operations bij zodat het systeem niet alleen de materiaalstructuur kent, maar ook de juiste planningslogica. Begin idealiter met één productfamilie in plaats van meteen alles om te zetten. Zo kun je testen of de nieuwe structuur effectief rust brengt op de werkvloer voordat je de aanpak over grotere productgroepen uitrolt.
Wat levert een multilevel BoM in Odoo financieel en operationeel op?
De directe winst zit zelden in één zichtbaar bedrag, maar in een combinatie van kleinere verbeteringen die samen zwaar doorwegen. Een goede multilevel structuur vermindert dubbel onderhoud in BoMs, maakt hergebruik van tussenproducten transparanter, verlaagt het risico op verkeerde reservaties en helpt lead times realistischer plannen. Daardoor krijg je minder ad-hoccorrecties, minder verborgen wachttijden en vaak minder nood aan extra bufferstock om onzekerheid op te vangen. Operationeel ontstaat vooral meer voorspelbaarheid. Dat vertaalt zich later ook financieel, omdat planners, inkopers en productieteams minder tijd verliezen aan brandjes blussen en omdat fouten op subniveau sneller zichtbaar worden voor ze het eindproduct raken.
Hoe zorg je dat productie- en planningsmedewerkers een multilevel BoM in Odoo correct gebruiken?
De beste training start niet bij schermen, maar bij proceslogica. Medewerkers moeten eerst begrijpen waarom een subassembly apart bestaat, welke werkstappen en lead times daarachter zitten en welke keuzes het systeem daardoor automatisch maakt. Pas daarna leg je de concrete Odoo-schermen uit, zoals productkaarten, BoMs, reordering rules en work orders. Hou de eerste uitrol klein en gebruik één herkenbare productfamilie als voorbeeld. Zo zien planners en operatoren meteen het verschil tussen de oude en nieuwe logica. Goede adoptie vraagt ook duidelijke eigenaarschap: iemand moet verantwoordelijk blijven voor BoM-onderhoud, routes en stockniveaus, anders vervalt zelfs een goede structuur opnieuw in verwarring.
