Plánování materiálových potřeb (MRP)

Klasické MRP v ERP počítá s pevnými dodacími lhůtami a neomezenou kapacitou. MSF MRP vychází z plánu APS s konečnou kapacitou, takže jsou termíny reálné.

Vytváří návrhy, které schvalují vaši nákupčí. Schválené návrhy se do ERP promítnou jako nákupní objednávky.

Ano, kooperační operace i materiál dodávaný subdodavatelům jsou plně podporované.

Pět věcí, ne tři: kusovníky, které odpovídají tomu, co se ve výrobě skutečně staví, skladové zásoby, které odpovídají regálu, dodací lhůty, které někdo změřil a ne zdědil, otevřené nákupní a výrobní zakázky s termíny, kterým ještě někdo věří, a pravidla pro zmetkovitost, výtěžnost a velikost dávky. Nejtišší problém jsou staré otevřené objednávky, protože zdánlivě kryjí potřebu, která ve skutečnosti krytá není. Před spuštěním si vypište každou otevřenou objednávku s termínem v minulosti a vynuťte rozhodnutí: přeplánovat, nebo uzavřít.

Ne tak, jak potřebujete. MRP kryje potřeby proti skladové zásobě a otevřeným objednávkám, takže když je stav skladu špatně, je výsledek špatně hned v obou směrech naráz: navrhne objednat materiál, který už na skladě máte, a mlčí o materiálu, který vám chybí. Cyklická inventura na položkách, které nesou největší hodnotu, je podmínka na začátku, ne etapa na později.

Kompletní propočet přes noc a cílené přepočty po změně plánu nebo po opožděné dodávce. Častěji neznamená automaticky lépe: každý běh přeplánuje podle nových informací a termín potřeby, který se každé ráno posune, nedá nákupčímu nic, podle čeho by jednal. Uvnitř zmrazeného horizontu si ujasněte, jestli se návrhy přestanou přepočítávat úplně, nebo se přepočítávají dál a jen se označí, když se rozejdou s plánem, protože pro člověka, který ten seznam zpracovává, se to chová hodně odlišně.

Ano, samostatně proti vašemu ERP. Zůstane vám vícestupňový rozpad kusovníku, krytí proti skladové zásobě a otevřeným objednávkám, kalendáře dodavatelů i minimální objednací množství. Přijdete o termíny odvozené z plánu: termíny potřeby se vrátí k pevným odečtům dodacích lhůt, takže jsou přesně tak dobré jako dodací lhůty, které tam někdo zadal, a nepohnou se, když se výroba zpozdí.

Nedělá žádná obchodní rozhodnutí. Navrhuje množství a termíny, ale nevyjednává cenu, nevybírá mezi dodavateli nad rámec toho, co jste nastavili (preferovaný dodavatel, cenové pásmo, dodací lhůta, minimální objednací množství, kalendář), a nedělá předpověď poptávky. Ta musí přijít z vašeho obchodního plánu. Taky nevidí materiál, který se ve výrobě spotřeboval, ale nikdo ho neodepsal, což bývá obvyklý důvod, proč návrh vypadá špatně.

Denní průchod seznamem výjimek, jehož rozsah se odvíjí od toho, kolik položek plánujete a jak široký horizont výjimek nastavíte. Letmý pohled na dashboard nestačí. Běh vygeneruje výjimková hlášení typu urychlit, odložit a zrušit a hodnota je v tom, že někdo rozhodne, které z nich jsou podstatné, a ještě týž den podle toho jedná. Tam, kde se tenhle krok vynechá, seznam roste, až ho nikdo neotevírá, a o systému se začne říkat, že jen šumí.

Data platnosti řídí, co použije nový rozpad kusovníku, ne zakázky, které jsou už otevřené. Uvolněná zakázka si nese soupis komponent, se kterým byla vystavena, a znovu se nerozpadá, takže dostat do ní změnu znamená zakázku vystavit znovu, nebo ji ručně upravit. Ověřte si, které datum rozhoduje o platnosti (vytvoření, uvolnění, plánovaný začátek, nebo termín potřeby), protože právě tahle volba určuje, jestli se změna na danou zakázku vůbec promítne.