Plánování a řízení dodavatelského řetězce (SCP)

APS optimalizuje výrobní plán uvnitř továrny; SCP tento plán rozšiřuje na dodavatele, nákup a výstupní logistiku.

Ano, dodavatelské portály a integrace EDI/API automaticky synchronizují potvrzení dodavatelů i dodací lhůty.

Rozhodně. SCP je navrženo tak, aby vyvažovalo poptávku a nabídku napříč více závody a sklady.

Ano. Co SCP potřebuje bez ohledu na okolní systémy, je udržovaný kmen položek s dodacími lhůtami a objednacími pravidly, kusovníky, stav zásob, kterému se dá věřit, a otevřené nákupní a výrobní zakázky. To vše musí přijít z ERP nebo rovnocenné evidence. Bez MES chodí odvádění a spotřeba jako hlášení zaúčtovaná na konci směny nebo zakázky. Plán proto reaguje pozdě, ale reaguje.

Nákupní návrh je aritmetika nad dodací lhůtou, minimálním objednacím množstvím, objednacím násobkem, stavem zásob a kusovníkem. Pokud jsou dodací lhůty dodavatelů pořád ty, které někdo naťukal při založení dílu, budou návrhy sebejistě špatně. Tyhle chyby nezůstanou skryté: první plánovací běhy udělají ze špatné dodací lhůty nebo zásoby viditelně špatný termín nebo množství. Vyčistit to před spuštěním ostrého provozu je mnohem levnější než potom.

Počítá ji a navrhuje; nerozhoduje ale, jaké riziko jste ochotni nést. Pojistná zásoba vychází z variability poptávky, variability dodacích lhůt dodavatelů a z úrovně obsluhy, kterou si zvolíte. Úroveň obsluhy je přitom obchodní rozhodnutí, které musí někdo udělat pro každou skupinu položek. Nastavte ji proti změřené variabilitě, ne podle zvyku, a pak procházejte výjimky, protože právě tam se zásoba reálně sníží.

Samo o sobě ne. Co dostanete, je jedna prognóza, která je viditelná, verzovaná a porovnávaná se skutečným prodejem. Obvykle právě to lidé touhle otázkou myslí. Statistické modely pomůžou tam, kde má poptávka historii a nějaký vzor; s novým výrobkem nebo se zakázkou vyhranou ve výběrovém řízení neudělají nic. Zlepšení přijde z toho, že prognózu někdo vlastní a každý cyklus vyhodnocuje odchylku.

Může, ale rozhodněte se, proti čemu. ATP kontroluje volnou zásobu a potvrzené příjmy; CTP navíc ověří, jestli je kapacita a materiál na to zakázku včas vyrobit. S nasazeným APS se CTP počítá proti naplánované sekvenci, bez něj proti deklarovaným kapacitním oknům, což směrem sedí, ale konflikt v sekvenci nebo přetypování nezachytí. Sliby padají na neaktuálních potvrzeních dodavatelů a optimistické kapacitě, takže si s obchodem dohodněte, co smí systém slíbit bez zásahu člověka.

Potřebujete jednoho jmenovitého vlastníka. Jeho prací se stane řešení výjimek a přestavování tabulek odpadne. Ta práce je konkrétní: procházet upozornění, uvolňovat nebo zamítat návrhy v rytmu vašeho plánovacího cyklu a držet dodací lhůty a objednací parametry poctivé. Zátěž roste s počtem plánovaných položek a s počtem výjimek, které vaše parametry generují, a nejtěžší je v prvních cyklech po spuštění, kdy se tyhle parametry opravují. Když to nikdo nevlastní, seznam upozornění naroste tak, že ho lidé přestanou číst.

Jen když si to přejete. Většina závodů si zamrazí blízký horizont, změny uvnitř něj pošle plánovači jako výjimky a za ním nechá systém plán znovu optimalizovat. Kde ta hranice leží, je rozhodnutí o pravidlech, ne technická věc, takže si zamrazené období a to, kdo ho smí porušit, dohodněte už při implementaci. Plánovače nevrací zpátky k tabulkám výpočetní čas, ale nervozita plánu.