Mezi nejčastější patří obava z toho, že „nemáme dost přesná data“, která implementace APS systému vyžaduje. S tím přímo souvisí obava z příliš dlouhé doby implementace, protože když nemáme přesná data, je třeba je získat a to někdy může trvat opravdu dlouho. Implementace APS proto často trvá déle, někdy i výrazně déle oproti původním odhadům. Velmi často se rovněž mění původně zamýšlený způsob použití. Místo detailních plánů pro řízení výroby se často použití „smrskne“ na detailní plánování požadavků na nákup, nebo jen na potvrzování realistického termínu dokončení zakázky. Když už se podařilo zavést ve výrobě detailní plány, tak výsledkem místo rychlé a spolehlivé výroby byla situace, kdy časté přeplánování způsobovalo posuny ve výrobě a ve výsledku větší nestabilitu než před zavedením APS. Nejabsurdnější situaci, které jsme byli svědkem, bylo, kdy na více než 2 měsíce vypadl server, na kterém byl APS provozován, ale nikdo z firmy si toho po celou dobu výpadku nevšiml, výkony firmy a výrobu to nijak neovlivnilo.

Tyto negativní zkušenosti z implementace APS naznačují, že za původně dobrým záměrem něco nebylo v pořádku, buď při plánování implementace, nebo v jejím průběhu. Další analýza zjistila obvykle jednu nebo více skutečností z následujícího seznamu:

• víra v tvrzení, že výroba nemůže pracovat lépe bez detailních (přesnějších) plánů pro jednotlivé stroje
• přesvědčení, že zlepšení vychází z toho, že tok výrobků bude přesně synchronizován pomocí APS, že operace budou na sebe navazovat téměř bez přerušení (přiblížení se ideálu One Piece Flow)
• nepochopení toho, že plánování v omezených kapacitách (FFS) není stejné jako plánování výroby pomocí metod TOC
• správné řízení výroby není možné, pokud nejsou co nejpřesněji znormované všechny operace
• v každém okamžiku je třeba se řídit podle co nejpřesnějšího plánu, tudíž každá porucha v dodávkách sub-komponentů nebo materiálu, každá porucha stroje ve výrobě, nedostupnost lidí způsobuje změnu plánu, a proto je třeba často přeplánovávat (a mít na to nástroj)

Zásadní problém přesných dat

Obecně, většinu výše uvedených tvrzení, které vedly k implementaci APS nebo kterých se implementace snažila dosáhnout, spadají do jedné obecnější kategorie „nelze dobře rozhodovat, aniž bychom měli okamžité a přesné informace (o stavu výroby, o možném plánu, simulace what-if)“.

Problematika přesnosti dat proto obvykle nemá jiné řešení, než buď přesná data získat, nebo jejich absenci akceptovat a přínosy APS oželet. Pokud podnik APS řešení chce, musí cestu k získání přesných dat absolvovat – analýzou klíčových dat, jejich doplněním, nastavením základních parametrů plánu, tvorbou prvních modelů a plánů a jejich neustálou optimalizací. Tím se ale podnik dostává stále hlouběji do problému s přesnými daty – pokud výsledky nesedí, je třeba ještě zpřesnit data… A to podnik nemusí mít nutně výrobu, kde např. technologické časy silně závisí na počasí (třeba zpracování slídy nebo výroba klobouků z králíčí srsti). Někdy je skoro nemožné pracovat s přesnými daty i ve zcela standardní výrobě, stačí jen, aby se měnily okrajové podmínky výroby a dodávek materiálu, které mají na plán výrazně větší vliv nežli „jakkoli nepřesná“ technologická data.

Jak se tato situace změní, pokud bychom se na stejnou situaci podívali optikou TOC? Pokud podnik není schopen získat přesná výrobní data, neznamená to, že by zlepšení v plánování a řízení výroby nebylo možné. Jen je třeba opustit ideu „super přesných“ dat.

Obr. 1: Základní princip cyklu plánování a řízení výroby pomocí teorie omezení.

Co je v případě TOC jinak?

Základní premisou TOC je, že není třeba zlepšovat všechna místa ve firmě, jen to místo, které představuje omezení (podniku, výroby, …). To mimo jiné také znamená, že není třeba mít co nejpřesnější data na místě, které není omezením. Na druhou stranu, na místě, které omezením je, představují přesnější data výhodu – ale současně to neznamená, že bez přesných dat nemohu v řešení postupovat dále. Přesnější data znamenají pouze přesnější odhad výsledného plánu, tj. s nepřesnými daty (delší časy, než je skutečnost) bude výsledek pravděpodobně pouze lepší, než byl plán.

Ale pojďme postupovat systematicky. První tři z 5 kroků zaměření (se) podle TOC říkají:

1. Nalezněme omezení systému.
2. Rozhodněme, jak omezení co nejlépe využít.
3. Podřiďme zbytek systému rozhodnutí z bodu 2.

Krok 1. Nalezněme omezení systému

Pokud má náš podnik/systém interní omezení, stačí jej nalézt, a máme vyhráno. Prohlásíme jej za hlavní synchronizační bod, změříme na něm časy a postavíme tzv. plán úzkého místa. Ale co v případě, že naše úzké místo stále „cestuje“ po podniku/výrobě? Pak je jediná možnost – prohlásíme podnik za systém bez úzkého místa (je to v realitě většina podniků, pouze méně než 5 % podniků má interní omezení) a budeme jej řídit, jako by omezení bylo vně podniku (což opět v realitě ve většině případů je – omezením je poptávka trhu, podnik by dokázal vyrobit a prodat více, pokud by měl vhodnou poptávku).

Krok 2. Rozhodněme, jak omezení co nejlépe využít

Tento krok představuje rozhodování o využití kapacity – o tom, jak dostupnou kapacitu co nejlépe využít.

Pokud má podnik interní omezení, pak jednou částí tohoto kroku je vytvoření plánu úzkého místa (přesně pořadí operací, které zaručí, že projde co největší počet výrobků optimalizovaný vzhledem k požadavkům trhu) a předcházejících kroků, zejména plánu nákupu (opět synchronizovaný s plánem úzkého místa). Druhou částí tohoto kroku je vytvoření bufferu před úzkým místem. Totiž pokud máme málo kapacity, tak nestačí ji pouze dobře naplánovat, ale musíme také zajistit, aby omezení mělo stále co dělat, aby neztratilo ani minutu tím, že by muselo na něco čekat. Toto zajistí buffer – disponibilní fronta práce před úzkým místem. Porovnejme v tomto okamžiku situaci s APS – v kroku 2 dle TOC říkáme, že plánujeme čekání výrobku na následující operaci, v APS se obvykle snažíme o to, aby operace plynule navazovaly (čtenář si asi dokáže odpovědět na otázku, co se stane, když přestanou z jakéhokoliv důvodu navazovat, a to zrovna na úzkém místě).

Pokud podnik nemá omezení, má jen úzké místo (místo s nejmenší kapacitou), pak je dostatečné, aby na úzkém místě procházely operace zhruba ve stejném pořadí, jako je pořadí dodávek zákazníkovi na výstupu systému. Platí totiž, že výkonnost systému není ovlivněna malou změnou pořadí zakázek na úzkém místě (to je ta obecnější varianta), tudíž ji lze použít i na řízení bez úzkého místa. Plánu pořadí zakázek na omezení (nebo nejužším místě) říkáme drum (buben – taktuje tempo na úzkém místě).

V realitě oba tyto případy v kroku 2 ošetřuje software, který kromě toho ještě prověří dostupnost kapacity na úzkém místě a navrhne nejbližší termín realizace zakázky. Uvedené postupy se týkají jen úzkého místa (nebo kapacitně nejslabšího, tudíž nejzatíženějšího místa) – všechna ostatní místa/operace se řeší v kroku 3.

Krok 3. Podřiďme zbytek systému rozhodnutí z kroku 2

V tomto kroku se vyřeší všechny ostatní body systému. Zmíněné „podřízení se“ znamená, aby celý systém pracoval v taktu nejužšího místa, ať už jde o omezení celého systému (poptávka brání dodat více), nebo je jen místem s nejmenší kapacitou (nemá smysl zpracovávat jinde 50 ks/hod., když nejužší místo umí jen 38 ks/hod…). Jak podřízení se vypadá?

První částí je rozhodnutí o uvolnění materiálu / uvolnění zakázky do výroby. Co to znamená? Určit čas, o kolik dříve musíme uvolnit materiál do výroby, aby bez problémů dotekl před úzké místo a zařadil se do fronty (bufferu). Ze zkušenosti víme, že sečíst technologické časy není dobrý nápad. Co máme k dispozici? Aktuálně platnou průběžnou dobu. V praxi tuto dobu zkrátíme na půl a prohlásíme ji za tzv. lano (anglicky rope). Pokud se někomu zdá zkrácení na 1/2 příliš agresivní, může použít 1/3. Zakázky jsou do výroby uvolněny o lano dříve, než mají procházet omezením. Tímto jsme nastavili základní parametry systému.

Druhou částí je zavedení tzv. buffer managementu. Totiž když nemáme (nebo nemusíme mít) úplně přesná čísla na drumu, uvolňujeme o lano dříve a říkáme tomu nastavený systém, jak víme, že je nastavený dobře? To nám řekne právě buffer management. Rozdělíme lano na třetiny a prohlásíme poslední třetinu za tzv. červenou zónu (anglicky „emergency zone“ – zóna ohrožení), prostřední třetinu za žlutou (normální, standardní průběh) a první třetinu, tj. část bufferu, kterou zakázka prochází těsně po uvolnění, za zelenou, bezpečnou zónu. Víme ze zkušenosti, že ve správně nastavených DBR (Drum-Buffer-Rope) systémech většina zakázek skončí na konci žluté zóny, sem tam nějaká skončí v červené zóně. Pokud je příliš mnoho tzv. červených zakázek, byli jsme při zkracování průběžných dob příliš agresivní, lano je krátké, je to signál k prodloužení zhruba o 1/3. Pokud nemáme téměř žádnou červenou zakázku, je lano příliš dlouhé, je to signál ke zkrácení lana o 1/3. Tímto se systém neustále dostává na optimální nastavení.

Další funkcí buffer managementu je určování priority zakázek. Definujeme tzv. penetraci bufferu, jako lineární čerpání času od 0 do 100 % podél délky lana (bufferu). Pro každý zdroj můžeme v každý okamžik určit ještě nezpracované operace/zakázky. Červené zakázky mají penetraci od 66,6 % výše, žluté od 33,3 %. Penetrace „de facto“ určuje urgenci, prioritu. Pokud seřadíme frontu práce před zdrojem podle penetrace, získáme tak prioritizovanou frontu práce (nejurgentnější zakázky jsou na začátku fronty). Pak již jen stačí zajistit, aby se zdroje/obsluhy na dílně řídily jednoduchým pravidlem: „Dělej na červených zakázkách nejrychleji, jak můžeš. Když nemáš červené, dělej na žlutých, když nemáš žluté, dělej si, co uznáš za vhodné.“ Tímto se mimo jiné dosahuje toho, že pro úzké místo, ale také pro většinu ostatních pracovišť jsme schopní dosahovat téměř 100% vytížení. V realitě opět všechny části kroku 3 zajišťuje vhodný software (viz obr. 2) 

Obr. 2: Ukázka určování priority zakázek ve výrobě pomocí buffer managementu (z reálného systému).

Přínosy TOC

Aplikací těchto kroků na téměř libovolnou výrobu lze zajistit zvýšení průtoku na téměř teoretické maximum, výrazně zkrátit průběžnou dobu a dodací lhůtu zakázek, výrazně zvýšit spolehlivost zakázek, snížit úroveň rozpracované výroby. A to i v situaci, kdy podnik nemá všechna potřebná data nebo nemá přesná data, kdy není jasné, co je úzké místo, jaká je jeho skutečná kapacita, kdy úzké místo cestuje po podniku (tzv. „floating bottkeneck“) a nedá se nikdy přesně zjistit, kam přeskočí příště. Pro většinu běžných pokročilých systémů plánování a řízení výroby je toto velká komplikace, pro metodu DBR (takto se jmenuje výrobní aplikace teorie omezení) je to jen realita, se kterou si dokáže poradit.

Zmiňovaný software, který logiku TOC podporuje, může být nakoupený nebo vytvořený na zakázku, případně i s využitím vlastních kapacit IT oddělení. Zavedení DBR v podniku trvá několik týdnů, ale pro úplnost je třeba říci, že jde jen o „technické“ zavedení, po kterém systém funguje, ale skutečné přínosy přichází až s tím, že se podnik naučí s metodou žít a dokáže podle signálů bufferů dělat správná rozhodnutí. To trvá přibližně půl roku. Přesto je tento postup výrazně rychlejší než zavedení většiny běžných pokročilých systémů plánování a řízení výroby.

Shrnutí

Problematika TOC je samozřejmě mnohem složitější, než kolik se vejde do jednoho článku, ale cílem autora nebylo popsat celou metodu úplně do detailu nebo představit konkrétní software a určitě v žádném případě nějak kompromitovat APS řešení. Autor článku implementoval běžné APS i APS s podporou TOC a ví z vlastní zkušenosti, že pokud jsou správně implementovány, fungují dobře a jsou přínosem. Cílem bylo ukázat, že i v nekomfortních situacích, které podniky již zažily nebo se do nich právě chystají vstoupit a řešit je systematicky, existuje další možnost, v naprosté většině reálných případů úspěšná.

Pavel Majer Autor článku je partnerem firmy Goldratt CZ, která se věnuje implementacím TOC v podnicích.