Definice workflow × procesní model

Teorie & best practice

U standardního pojetí procesního přístupu platilo, že je potřeba začít procesní analýzou (dále PA) - 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). Mimo jiné to znamená, že jak analytik, tak řídící pracovníci (vlastníci procesních oblastí) musí mít dostatečné znalosti principů a metodik procesů. Musí mít představu, jak na sebe činnosti navazují, jak životní cyklus instance procesu může procházet rozdílnými stavy. Jak s pomocí stavů a činností lépe organizovat práci.

Což je poměrně náročné. Procesní přístup a principy by měly být ukotveny v podnikové stragegii. Musíte mít modelovací nástroj a případně podporu pro zpracování dat získaných při analýze. Zjištěné skutečnosti se mohou změnit jenom tím, že je zjistíte. Vznikne model, se kterým umí málokdo zacházet - jen výjimečně umí modelovací nástroje definovat plánované změny a nové verze uspořádání činností... a popravdě modelování budoucí podoby činností jde neuvěřitelně těžko (pokud respektujete pravidlo, že novou verzi je možné vytvořit pouze validní změnou ze současného stavu.

Žádnou další verzi nemá smysl vytvářet. Není jisté, jak dopadne ta nejbližší změna. Protože je téměř jisté, že výsledná podoba činností bude trošku jiná, než ta plánovaná. 

Jak provádět změny

V poslední době roste zájem o PA. Není úplně jednoduché se se zadavateli dohodnout - což je jiná úvaha (co si kdo představuje a co je schopen využít). Konkrétně to využití je pekelně slabé místo - většinou se vůbec nepodaří dovést zákazníka k tomu, aby formuloval, co od toho procesního modelu (výsledku analýzy) očekává (jestli vůbec počítá s tím, že by "procesní analýzou" měli vzniknout něco, co bude muset někdo použít... nebo spoléhá na to, že jejím provedením se stane sama od sebe  zázračná změna... nebo jestli prostě příslušný řídící pracovník zoufale hledá alibi).

Např. doporučujeme použít procesní model (současného stavu) jako součást specifikace pro implementaci nového podnikového informačního systému. Platí to ovšem pouze pro případ, kdy implementační partner (spíše aktivně sám) tuto součást očekává či vyžaduje - ví, co s nim bude dělat (a umí to vysvětlit, popř. ukázat). Nemusí se jednat o implementaci procesně orientovaného informačního systému.

To je jedno konkréní využití procesní analýzy. Pomůže nám definovat případy užití, vzorová / testovací data, akceptační kritéria a migrační mechanismy. Víme o "všech" (identfikovaných) činnostech, na nic podstatného by se nemělo zapomenout.

Jaké jsou další případy užití procesního modelu?

• Seznam činností s údaji o počtech instancí, frekvenci, kapacitní náročnosti, rezervách atd.
• Teoreticky (poněkud naivní) se dá použít pro "vymýšlení" změn.
• Není úplně špatně chápat PA jako skrytý personální/manažerský audit, ale to chce hodně silné nervy.
• Občas někdo věří, že tím, že "se popíše" (nikoli současný, ale žádoucí) stav, tak lidé začnout pracovat podle toho popisu. To je asi největší omyl.

Definovat jako povinnost lze pouze reálný stav.

Tedy:

• Mít dobře definovaný výchozí stav. Bez příkras a fantazírování.
• Najít, promyslet, navrhnout, připravit, ověřit a zavést zlepšení.
• Tuto realitu vytvořit a fixovat v provozních nástrojích (běžných evidencích, případně workflow).
• Role, stavy, události a činnosti/povinnosti jsou popsány v procesním modelu.
• Monitorovat a podporovat (a upřesňovat). Až je jisté, že to funguje, lze s výkonními lidmi sjednat ověřenou a osvojenou podobu jejich povinností.

Nasazení nových nástrojů

Reálné projekty jednoznačně vyžadují interaktivní upřesňování podoby činností (aby mohlo fungovat stavové workflow). To je taky samostatné téma.

Jak víceméně "přirozeně" rozvíjíme procesní model obsažený ve vytvářených řešeních, realita se dostává do rozporu s "teorií".

Realita

U nasazovaných řešení jsme nebyli schopni s vlastníky procesních oblastí ani s výkonnými pracovníky předem dohodnout stavy a činnosti. Když jsme udělali provozně využitelné workflow (činnnosti dle stavů instancí, přechodové možnosti, reálné role... ty jsou asi nejobtížnější) jako součást formuláře instance, tak je uživatelé "vidí" a chápou. Dokáží i upřesňovat či doplnit.

V obecné poloze nedokážeme "domýšlet", jak by která činnost měla fungovat, co smí a nesmí být povoleno či musí být vyžadováno. Jestli je to jedna nebo dvě povinnosti. Jak by měly fungovat časové limity. Jak přistoupit k situaci, kdy povinností člověka není vypořádat se s jednou instancí (např. zakázkou), ale se všemi ve stavu, ve kterém je nutno je "vyřídit" (např. vyfakturovat). Kdy se to dá dělat automaticky a kdy je potřeba automatické zpracování zablokovat.

Dokud to nevidíte, je těžké si to představit.

Je potřeba to dělat průběžně.

Vnucuje se otázka - není potřeba "začít" s procesní analýzou od těch nejjednodušších primárních činností, na kterých je vidět, co se doopravdy děje? Viz třeba předchozí úvaha o kontrole - jasně, dá se "počkat", až budou v katalogu činností všechny úžasně a dokonale definované...

...nebo je navrhovat (identifikovat, zaznamenávat, ověřovat, popisovat... pozor, reálný stav) průběžně, jak je budu nacházet (zde myšleno "bude záměr zkontrolovat, zda lidé dělají to, co by měli dělat tak, jak by to měli dělat). Umím si živě představit, jak "objevné" to ve většině případů musí být.

Jestli k tomu, aby v organizaci mohla proběhnout opravdu zásadní změna (což procesní přístup bezpochyby je), není potřeba začít od toho, co nám pomůže tuhle změnu navrhnout, připravit a provést. Konkrétně začínáme sběrem podnětů. Potom potřebujeme řídit přípravné práce pomocí MBO a projektů. Musíme nachystat pro tu "opravdovou" procesní analýzu infrastrukturu. Vyzkoušet. Ověřit. Rozchodit. Umožnit efektivně zapojit každého, u koho to bude dávat smysl.

Nejdříve definujte řídící procesy, potom provozní

Stejně to nebude "nikdy hotové".

Co kdyby se činnosti místo v analýze definovaly rovnou v provozním procesním modelu? Při jeho praktickém používání? Mohlo by to fungovat? Daly by se to vyzkoušet na bázi vytvoření systému pro podporu kontrolní činnnosti? Budou se dát takto zaznamenané činnosti použít např. při zapracování lidí, řízení výkonu a trvalém zdokonalování? Dostanou se tam i činnosti, které nemají administrativní charakter? Třeba distribuce (dodávky). I když vlastně ta taky má velmi výraznou datovou vrstvu (expediční příkazy, výdejky, dodací listy, ...). Možná v reálné organizaci neexistují žádné činnosti, které by neměly "administrativní stopu". Asi to chce "před upotřebením zatřepat".

Možná poněkud bizarní - nedala by se procesní analýza dělat (spíše "začít identifikovat činnosti") tím, že zkusíme rozchodit dříve navrženou kontrolu? Vejce nebo slepice?

Téměř jistě se neobejdeme bez správy podnětů (na kterou musí navazovat jak řízení pomocí úkolů, tak odpovídající systém pro podporu řízení projektů). Taky velmi užitečné pro pochopení a osvojení principů stavového workflow.

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í.