Workflow / procesní řízení pro plánování a řízení výroby.

 

Výrobní workflow, aneb procesní pohádka

1. 10. 2015


Pohádku o tom, jak se na úzké lávce potkalo Štěstí s Rozumem, jste určitě všichni četli. Ve variantě pro informatiky se setkají dvě jiné bytosti – Teorie a Praxe. Konflikt, neboli zápletka, je však obdobný. Jedna musí trochu uhnout druhé, a je otázka, co je pro chasníka uživatele lepší.

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.

BM Servis - schema


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.

BM Servis - schema


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. 
BM Servis - schema


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. 
BM Servis - schema


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.

BM Servis - schema


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.

Ocitli jste se v podobné situaci? Hledáte praktické a funkční řešení dílčí oblasti, kterou Váš stávající informační systém není schopen pokrýt? Obraťte se na nás, můžeme vám pomoci.

Článek byl publikován v časopise IT Systems 6/2015 a na portále www.systemonline.cz

 

Další články:

Kontrolní hlášení DPH očima informatika

Kontrolní hlášení DPH

Když zjistíš, že jedeš na mrtvém koni, sesedni.

Výrobní workflow, aneb procesní pohádka

Klíčové vlastnosti informačního systému z hlediska malé firmy

Optimalizace skladů v obchodních a výrobních firmách

Všichni do cloudu? A proč?

Blog > Výrobní workflow, aneb procesní pohádka

Firemní informační systémy

pro komplexní, oborově nezávislé, procesní řízení středně velkých firem výrobních, obchodních, projektových či poskytujících služby, případně společností s netypickým druhem činnosti.

BM Servis posiluje kapitálovým vstupem DC Conceptu

BM Servis posílil kapitálovým vstupem společnosti DC Concept s cílem vývoje nové verze informačního systému, ve které by se měly spojit výhody procesního pohledu z IS BM a objektového pohledu z QI. Současně tímto posílením došlo ke zvýšení stability společnosti, což dává garanci, že stávající IS Bílý Motýl může být po celou řadu let dále udržován a rozvíjen včetně poskytování kompletního servisu. BM Servis se také stává implementačním partnerem pro informační systém QI v jihočeském kraji, kde bude IS QI nabízet a implementovat novým zákazníkům.

Seminář /školení Manažerské analýzy a výstupy

Školení pro uživatele informačního systému Bílý Motýl na téma Manažerské analýzy, jejich pojetí a tvorba v IS BM.

Měření spokojenosti zákazníka - uživatelů informačního systému Bílý Motýl

V průbehu jara jsme realizovali průzkum spokojenosti našich zákazníků. Výsledky jsou super!

Kdo má jednu nohu v kanoi a druhou ve člunu, spadne do řeky. Publikujeme v IT Systems a na www.erpforum.cz

O integraci informačních systémů v malých firmách píšeme do IT Systems a na ERP forum.

BM Servis s.r.o.Software, který se vyplatí!

ENGLISHČESKY

optimalizováno pro: Internet Explorer 7+, Mozilla Firefox 3+, Opera 10+