Pár slov úvodem aneb Bylo nebylo...

Přechod z funkčního řízení společnosti na procesní – to je téma na dlouhý článek nebo dlouhou debatu. Také na dlouhou (byť pro firmu velmi přínosnou) předimplementační fázi analýzy potřeb, modelování procesů a organizačních změn.

Realita je ale potvora a manažerům hází pod nohy pořádná polena. Třeba v podobě povinně provozovaného molocha (ERP systému), vylučujícího jakoukoli vlastní cestu (důvodem může být zahraniční majitel, protekční výběr dodavatele v polostátní firmě, nevhodný leč již zafinancovaný nedávný nákup IS… kdo z nás se s tím nesetkal?) Trh však nespí a každé zaváhání potrestá, boj o podíl na trhu je denní realitou, a tudíž i potřeba řídit a optimalizovat své činnosti s podporou informačního systému v rychlém souladu s tržními změnami. Což může být v případě rigidního molocha potíž. V takových situacích lze realizovat projekt na dílčí – obvykle z hlediska tržního úspěchu kritické – části firemního provozu. Někdy je málo více (= někdy i špetka pomůže; než by se stihlo plnohodnotně implementovat do ERP, tak se už začne vyrábět něco jiného, ...).

Vyjdeme-li z pojetí procesu jakožto sledu vzájemně na sebe navazujících operací, kdy se transformuje zadaný vstup na zadaný výstup, můžeme nahlédnout procesně jen na část činností organizace. Vnějším světem, zadávajícím vstup a požadujícím výstup, pak není externí okolí, ale ostatní útvary společnosti.

Definice problému workflow ve výrobě aneb Jak úzká je lávka?

Ukažme si to na příkladu výrobní organizace, kde nastane potřeba vyrábět nový výrobek v několika variantách pro různé typy zákazníků, tedy vlastně několik nových výrobků, a to formou zakázkové výroby na základě konkrétních objednávek, nikoli na sklad. Jednotlivé výrobní operace se budou provádět v různých dílnách a přesně po sobě, vynechání jediné zničí celý výrobek v řádu desítek tisíc. Jinými slovy nastala situace, kdy je výroba znatelně komplikovanější, než tomu bylo dosud.

Z celého business procesu (poptávka – nabídka – smlouva – technologická příprava – vyskladnění materiálu – výroba – dodávka – doprava – fakturace – platba – následná péče) se budeme zabývat pouze jednou jeho částí - výrobou, a to zejména řízením posloupnosti výrobních operací. Zde nastává nutnost řešit:

• přijetí objednávky – zakázky od obchodního oddělení (tedy vstup z „vnějšího“ světa),
• koordinaci pracovníků ve výrobě,
• optimální vytíženost dílen,
• sledování koncových časů zakázek,
• odepisování operací přímo ve výrobě,
• předání hotové zakázky (výstup pro „vnější“ svět).

Jednotlivé varianty výrobků bude potřeba sledovat jako samostatné výrobní projekty, kdy každý projekt bude mít přirazeny určité operace v určitém pořadí. Jednotlivé výrobní zakázky, tak jak je budou obchodníci zadávat, si z projektu převezmou sled a typy operací. Každá zakázka si musí nést sebou informaci o počtu požadovaných kusů výrobků a plánovaném čase, zejména plánovaném datu ukončení zakázky. Taky je nutno určit přesná pravidla řešení případných problémů a mechanismus jejich předávání, řešení a znovuspuštění přerušeného výrobního procesu zakázky.

Při takto naspecifikovaném projektu je vlastní workflow ve výrobě už poměrně triviální. Z firemního ERP přichází zakázka, založená obchodníkem. Z již zadaného projektu si převezme posloupnost operací a je tak připravena k zaplánování do výroby. Ve chvíli, kdy plánovač uvolní zakázku do výroby, začne se zobrazovat na základní obrazovce s ostatními již vyráběnými zakázkami. Kromě dalších parametrů zakázky se zobrazuje vždy aktuální operace zakázky, která je na řadě k realizaci.

Jednotliví montéři se přihlašují k aplikaci (technologické řešení je popsáno níže) a volí dle své kvalifikace a vytíženosti své dílny zakázku ke zpracování. Po vykonání potřebné operace o ní montér provede záznam, který se automaticky podepíše jeho identifikačním kódem, a „posune“ ji tak v procesu k další operaci, která se ihned začne zobrazovat na základní obrazovce. Zde si ji opět vybírá další montér. Na prvním schématu je rovněž naznačen proces řešení problémů.

Takto nastavené procesní řešení obsahuje všechny prvky klasického workflow:

• jasně daný vstup a výstup procesu,
• jednotlivé činnosti jsou propojeny do procesu s možností jejich variabilního přeskupení,
• jsou definovány a evidovány kompetence k procesu i k jednotlivým operacím,
• jsou definovány a sledovány limitní faktory procesu – čas, rozpočet,
• proces má požadovanou informační schopnost. 

Pár slov uprostřed aneb Obě se na lávku nevejdeme, která ustoupí?

Nastává otázka, jak si firemní ERP (výše zmíněný povinný moloch) poradí s nečekanou informační potřebou.

V ideálním (teoretickém) případě by měl firemní informační systém takto nadefinovaný postup realizovat v rámci již naprogramovaných řešení či rychlým přenastavením parametrů. Dobrým řešením může být programová úprava na zakázku. Jenže – co když si neporadí? A zakázková úprava je finančně a časově nevyhovujícím, nebo zcela nemožným (jak časté, v případě molocha) řešením?

Pokud bez informační podpory hrozí velké ztráty (financí, důvěry, času, nervů…), je na místě pragmaticky hledat pro tuto dílčí část činnosti organizace jiný informační systém. Při tom musíme zvažovat zejména následující faktory:

• vhodnost informačního systému pro tuto konkrétní potřebu,
• propojení se stávajícím ERP,
• technologickou kompatibilitu se stávajícími podnikovými standardy.

Ale pojďme zpátky k našemu příkladu. Vzhledem ke skutečnosti, že se jedná o typické procesní řízení, je vhodné hledat informační systém, jenž podpoří individuální nastavení uživatelských procesů, tedy umožní řetězit uživatelsky definované operace do požadovaného sledu bez nutnosti programování. Je třeba myslet i na to, že se pravděpodobně bude jednat o velmi živou implementaci, na niž budou výhledově kladeny vysoké nároky na variabilní doplnitelnost a přizpůsobivost.

Z následujícího obrázku je patrné, jak informační systém podporující workflow pracuje:

• Vyhovující a rychlé propojení se stávajícím ERP lze realizovat přes webové služby. Tak se zajistí přebírání zakázek založených obchodním oddělením a následně po vyrobení zakázky předání potřebných podkladů do firemního ERP pro účely expedice, mezd, fakturace atd.
• Příjemným a moderním řešením případné technologické nesourodosti (stávající ERP je např. provozován nad jinou databází) může být realizace výrobní aplikace v cloudu. 

Zbývá jen otázka, jak aplikaci dostat až k pracovníkům ve výrobě, aby mohli operativně sledovat a realizovat výrobní proces. Elegantním a přístupným řešením jsou například tablety – na trhu jsou k dispozici zařízení odolná proti prachu, vodě, nárazu a schopná načítat i čárový (nebo QR) kód do webové aplikace. Lidi ve výrobě se přes tablety přihlásí k aplikaci a budou mít přímo na místě přehled toho, co je třeba udělat a v jakém pořadí. Přes tablety budou také „posouvat“ zakázku procesem.

Pár slov závěrem

Teoretik by patrně viděl řadu úskalí takto navrhovaného řešení. Asi by pohovořil o nekoncepčnosti, nesystémovém přístupu, nehomogenitě. Pragmatik je ovšem rád, že má k dispozici dobré, funkční a dlouhodobě využitelné řešení navzdory potvoře realitě a polenům pod nohama. Oba pak jistě nahlédnou potenciál procesního řešení a jeho nevyužité možnosti v ostatních oblastech řízení společnosti. Ale to je pak jiná kapitola.

Tentokrát tedy vyhrála Praxe. Nemusí tomu tak ale být vždy, někdy není na škodu investovat víc peněz a času a prosadit od počátku teoreticky vhodnější řešení. Život prostě není pohádka.

Ing. Jaroslav Janda Autor článku je ředitelem společnosti BM Servis s.r.o.