Jak funguje workflow

Podstata procesu a životního cyklu

U procesního přístupu platilo, že je potřeba začít procesní analýzou - od hlavního podnikového procesu, najít dílčí procesní oblasti a v nich buď pokračovat "shora" nebo na vhodné úrovni "zmapovat" (identifikovat) koncové (elementární) činnosti. To jde dělat "hrubou silou" (to je ta procesní analýza)

Obvyklé a rozumné pojetí "workflow"

Naprostá většina toho, co se prezentuje jako "workflow" obvykle obsahuje pouze více či méně stupidní schvalovací rutinu. Nechce se nám přemýšlet nad tím, jak to dělat jinak. Pro praktické užití je nejlépe použitelné "stavové workflow". To znamená, že záznam instance procesu (např. zakázka nebo viz dále požadavek na zásah) se může nacházet v některém z jednoznačně definovaných stavů, který současně může (pokud je daný stav "dočasný") znamenat povinnost pro konkrétní roli provést definovanou činnost. 

Příklad [zdroj "AI"] - standardní "flow" (trošku zamotané se stavy) pro řízení požadavků (service request management). Za výpustkou ("...") se snažím kurzívou popsat činnost / povinnost - bez ní je daný stav bezvýznamný.

• Nový... uvést vše potřebné a předat k posouzení.
• Posouzení [lépe "Podaný"]... vyhodnotit - u požadavku na zásah (service rq) moc nedává smysl. Asi je tím myšleno, že někdo má rozhodnout, zda se bude požadavek řešit. To by tak být nemělo - každý podaný požadavek je nutno řešit / vyřešit. Může dávat smysl činnost "Ověřit | upřesnit | interpretovat" (pokud požadavek není srozumitelný). V původním pojetí by se asi po "posouzení" mohl dostat do stavu "Schváleno", což znamená, že někdo má provést potřebný zásah. Pokud se neschválí, ten, kdo má nahlášený problém, má nejspíše prostě smůlu.
• Schváleno... asi by se měl provést zásah. Evidentně se předpokládá, že se provede sám od sebe.
• Realizace... pokud je zásah proveden - asi nepřipadá v úvahu nic jiného než úspěch, tak by se měl dostat do stavu "Vyřešen" nebo něco podobného. 
• Kontrola... tak k tomu asi nic sebeméně smysluplného nevymyslím. Kontrolovat, zda řešení, které mělo odstranit potíže (závadu apod.) skutečně pomohlo, nedává smysl. Systémová kontrola práce servicedesku je něco jiného.
• Uzavřeno... již žádná další činnost není potřeba.

Popravdě je dost šílené, jakým způsobem se většinou činnosti a stavy definují. Domnívám se, že je to proto, že jejich návrháři se snaží vyhnout té "práci", které je v názvu předjímána. Částečně proto, že není snadné se s vlastníkem procesní oblasti a výkonnými pracovníky dohodnout, co vlastně dělají - jaké jsou jejich povinnosti. Je to dobře vidět už na úplně elementárním scénáři, kdy se "schvaluje" podoba textu (třeba návrh smlouvy, reklamního textu, podnikové směrnice, ...).

• Akceptujeme nedostatečné zadání.
• Smíříme se s tím, že se to někomu nebude "líbit".
• Podle toho to taky vypadá... 😉

Pokud potřebuji rozumný/kvalitní text, musím mít validní zadání, kompetentního autora a rozumný způsob připomínkování. Nic jako "schválení" nedává smysl - buď je v připomínkovaném textu něco, co neodpovídá zadání, realitě atd. a potom je nutno to identifikovat a doložit, co přebývá/chybí/je jinak. Kompetentní autor je povinnen připomínku vypořádat. Rozumná podoba tvorby textu je (měla by být):

• Zodpovědný řídící pracovník zjistí, kdo bude nejvhodnějším autorem.
• Spolupracuje na zadání (definuje si ho autor).
• Pomůže identifikovat připomínkující.
• Zajistí/podpoří (pokud je to nutné) připomínkování.
• Autor rozhoduje, co v textu bude.
• Když se to zadavateli nelíbí, může vyměnit autora.
• Výsledkem je nejlepší za daných okolností možná podoba textu.

Všichni víme, že 80 % (reálně asi víc) kvality zajistí dobré zadání.

Příběh ze života

Velmi konkrétní (absolutně reálný) příklad z praxe. Vlastníkem procesní oblasti se rozumí člověk, který má na starosti sestavení plánu investic za celou organizaci - je zadavatelem popisovaného systému.

• Systém pro sběr požadavků na obnovu mechanizace.
• Snažíme se definovat činnosti & role (povinnosti).
• Mechanizátor střediska identifikuje potřebu.

Tady nastává "panika". Dosud byla účast vedoucího střediska náhodná (zcela alibistická). Návrh vlastníka procesní oblasti byl "Má to 'schválit'."

Ptám se: "Co si pod tím představujete? Volbu 'Schválit/Zamítnout'?"

Údiv: "A co jiného?"

Předlouhé vysvětlování, přesvědčování, dokazování... že se to takto dělat nedá, protože ani ten vedoucí střediska nebude za 5 minut vědět, proč to schválil/zamítnul... pokud to vůbec věděl předtím. Že tím jen podpoříme onen bezbřehý alibismus.

Rezignace: "A co tedy?"

Takže: "A co doopravdy potřebujete, aby se stalo? Proč do toho toho vedoucího taháme? Není mechanizátor dostatečně kvalifikovaný a kompetentní?"

Nestačí schvalovat - je nutno pracovat 

Workflow znamená tok práce. Jednotlivé činnosti nejsou "brány", na kterých má pomazaná hlava "rozhodnout", jestli tuto instanci pustí dál nebo ne. Podstata je, že pokud je instance validní, musí jít dál. Takže je potřeba zkontrolovat validitu. A tím se nemyslí, jestli jsou vyplněné povinná pole nějakou hodnotou. To dokáže algoritmus. Jde o to, jestli zadané hodnoty odpovídají realitě. V našem případě se ukáže, že fakticky je potřeba:

• Aby vedoucí s mechanizátorem společně vytvořili a udržovali plán provozu (využití mechanizace).
• Jaké objemy prací bude nutno provádět dle typologie (využitelnosti) strojů.
• Jaké se očekávají změny v organizaci práce (např. více či méně outsourcingu, omezení atd.)
• Jestli budou mít dost operátorů.
• Jaké je faktické (budoucí) vytížení daného a alternativních strojů.
• Když se obnovují dosluhující stroje, tak se správnou perspektivou (nekupovat nutně "to stejné").

Skutečný vlastník procesní oblasti musí být schopen sjednat s lidmi pověřenými příslušnými rolemi, co jejich činnosti/povinnosti zcela konkrétně znamenají. Pravděpodobně by měl být schopen zajistit alespoň namátkovou kontrolu, v tomto případě musí koordinátor, který přijímá požadavky na doplnění a obnovu, zkontrolovat (v jistém smyslu potvrdit - musí mít také zcela konkrétně definováno, jak svoji práci má provádět), že příslušná část požadavku, která má obsahovat sjednanou informaci, odpovídá minimálně formálně a v případě pochybností musí mít možnost si to ověřit - tedy zobrazit si onen plán využití.

Důsledně identifikovat skutečné potřeby

Po vyjasnění, co se vlastně má dělat, pokrčení ramen. Zmateně zoufalé rozhození rukama.

Dobře: "Co tedy chceme od vedoucího v okamžiku, kdy se má vyjádřit k novému požadavku na doplnění či obnovu mechanizace?"

"Aha... vlastně má zkontrolovat, jestli požadavek je v souladu s tím jejich plánem..."

"...a pokud není, tak to má vrátit s tím, co a proč má mechanizátor upravit nebo musí spolu zpřesnit ten plán... a potom musí 'potvrdit', že požadavek je v souladu s plánem využití strojového parku... ideálně uvede do požadavku hodnoty, vůči kterým jej ověřoval."

"No... to by bylo skvělé... jenom si to nějak neumím představit..."

Ale šlo to. Nakonec tím byli nadšení i ti mechanizátoři a vedoucí středisek. Mají dokonalý přehled, co jim prošlo rukama (monitorem). Jenom jsme jim museli udělat jednoduchý nástroj pro to plánování. Když jsme si ujasnili, proč MVP, bylo to snadné.

Jak si představujete fungování workflow? Stačí schvalovat?

Pokud o tomto tématu máte chuť diskutovat, dá se to u výchozí podoby příspěvku na LinkedIn. Pokud se vám budou hodit informace nebo zvažujete spolupráci, ozvěte se. Umíme pomoci se smysluplnou digitalizací a automatizací.