Luboš Zmátlík, projektový manager

V nedávné době jsem vedl jeden projekt, na kterém jsem si ověřil pro mě jednu zajímavou věc. To mě vedlo k tomu, abych se o ni s Vámi podělil.

V dnešní době se setkáváme s více lidmi, kteří si myslí, že simulace je všespásná, geniální, nepostradatelná a jedinečná metoda, která nahradí úplně vše, i zdravý lidský rozum. Osobně si myslím, že tento fenomén je v dnešní době rozšířen všude a není omezen pouze na náš obor. Pozoruji, že mnozí lidé v mnoha profesích mají představu, že počítače, synchronizované sítě, sdílené kalendáře a vůbec všechna „moderní“ technická zařízení jim nahradí jejich zdravý selský rozum, přirozený intelekt a dokonce i moudrost. Je to docela smutný jev dnešní doby a jeho následky určitě každý můžete vidět ve svém okolí…

Proto jsem byl rád za tento projekt, který mi v tomto smyslu hodně ukázal.

Popis problému:

Náš zákazník měl automatizovaný systém pro uskladnění a vyskladnění palet, který sloužil jako zásoba rozpracované výroby při čekání na následné operace. Pro představu pár čísel: Přibližná délka byla přes 100 metrů, kapacita kolem 2000 paletových míst, systém měl cca 20 vstupně/výstupních míst pro uskladnění/vyskladnění palet. Toto vše obsluhovaly dva automatizované vozíky, které plnily jednotlivé požadavky.

Jaký byl vývoj situace před naším příchodem?

V průběhu projektu jsme zjistili následující informace. Původně systém obsluhoval jeden automatizovaný vozík. Během několikaletého vývoje se ale pozměnilo portfolio výroby, některé stroje byly přesunuty, odstraněny nebo nahrazeny a původní objemy výroby se staly pouze zlomkem současného stavu. Prostě se časem stalo, že jeden vozík nestíhal, tak bylo třeba přidat druhý. Situace se několikráte opakovala a za nějaký čas nestíhaly ani oba vozíky. Proto se zvyšovala jejich rychlost až na maximální možnou hranici. A jelikož to dále nešlo a vozíky stále nestíhaly, byli jsme poptáni, abychom zkusili vymyslet nějaké funkční řešení.

Jak se to odvíjelo dále?

Při prvotním rozmotávání pavučiny jsme na funkčním modelu celého systému zjistili, že se vozíky vzájemně hodně blokují a že zbytečně čeká jeden na druhého při vyřízení požadavků. Podrobnějším zjištěním jsme došli k příčině. Tou bylo neustálé zvyšování rychlosti. Zkusím to vysvětlit.

Vozíky mají čidla proti čelnímu nárazu, aby se nemohly poškodit. A tato čidla jsou nastavena na určitou vzdálenost. Její délka je vypočtena tak, aby vozíky mohly bezpečně zpomalit na krokovou rychlost, pokud se k sobě přiblíží. A tato brzdná dráha je závislá na zrychlení/zpomalení, které vozíky mají a na maximální rychlosti, kterou mohou dosahovat. A právě v tom byl ten zakopaný pes. Jelikož se neustále pouze zvyšovala maximální rychlost, tak i tato brzdná dráha se neustále prodlužovala. Tudíž vozíky velkou část své cesty jezdily velmi pomalu, neboť byly v čidlem označené „brzdné“ oblasti. Naproti tomu maximální rychlosti vozíky dosahovaly pouze výjimečně a nebylo to téměř ani nutné.

Jinými slovy by se dalo říci, že čím větší byla maximální rychlost, tím větší bylo nutné držet bezpečnou brzdnou dráhu. A v této dráze vozíky jezdily ohromně pomalu. Naproti tomu maximální rychlost byla využita jen zřídka, a proto z pohledu celého systému bylo lepší tuto rychlost zmenšit a tím pádem i zkrátit brzdnou dráhu. Díky tomu nebyly vozíky tak svázané a mohly jezdit více bez omezení rychlosti, tudíž vychystaly požadavky rychleji.

Dokud v systému byl pouze jeden vozík, tak tento problém nebyl aktuální. Naopak, jakmile byly vozíky dva a jakmile se pouze zvyšovala rychlost, byl tento vliv čím dál silnější. Proto se tak moc vozíky blokovaly, čekaly jeden na druhého místo toho, aby jezdily s paletami. Tento vliv jsme odstranili paradoxně snížením a nalezením optimální rychlosti vozíků. Tím se i snížila blokace, a jak již bylo napsáno, i čas na vychystání jednotlivých požadavků se znatelně zmenšil.

Samozřejmě, že toto nebyl jediný přínos z tohoto projektu. Mohl bych zde napsat spoustu výstupních charakteristik, krásných grafů, procent a vyčíslených úspor. Ale proto jsem tento článek nepsal. Záměrně zůstávám pouze u zmíněného problému a jeho řešení, protože mi nyní připadá krásně jednoduchý, zajímavý a nebylo lehké na něj přijít. Samozřejmě, že z pohledu, kdy je nám znám výsledek a celá pointa, se tento problém může zdát až úsměvně jednoduchý. A tak to funguje napříč vším, po bitvě je každý generál.

Poučení, která mi z mého příběhu plynou:

  • Díky simulaci jsme mohli vytvořit přesný obraz docela komplikovaného reálného systému v takovém detailu, že jsme byli schopni odhalovat a prověřovat různé problémy a hlavně i jejich příčiny. V tomto ohledu je simulace velkým přínosem a konkrétně v tomto projektu by se velmi těžko nahrazovala.
  • Zjistil jsem, že bez dobrých lidí kolem, bez chuti a dobré nálady, bez dobrých nápadů v týmu, které díky tomu vznikají, by stejně simulační model nebylo čím plnit. Prostě by nebyly nápady, energie a chuť. Tudíž si myslím, že k úspěchu by to nevedlo, alespoň ne v takové atmosféře a s takovým výsledkem.
  • Simulace je prostě dobrý nástroj pro prověření složitějších systémů. A tak by se mělo i k simulaci přistupovat, není to žádná spásná věc, která by vyřešila tisíce problémů bez mrknutí oka, je to dobrý nástroj, který se dá využít. A jako s každým nástrojem se musí pracovat. Na to se dnes bohužel malinko zapomíná, ale nejen v simulaci J.

Poslední věcí, co mi tento projekt dal, bylo uvědomění si celkem prosté, ale opomíjené zákonitosti. To, že budu něco neustále zrychlovat, neznamená, že to bude stále rychlejší a lepší, i když to tak na první pohled může vypadat.