MBO a workflow

Typy a užití workflow

Standardně se workflow používá pro podporu řízení procesů. Lze namítnout, že úkoly v rámci MBO jsou jedinečné a žádný proces tam není. Analogicky u projektů - jedinečná aktivita - kde je proces? A pokud tam proces není, nedává smysl vytvářet workflow.

Takže "Jaký proces?!"

U projektů je to jednoduché - proces projektového řízení. Předpokládejme, že dává smysl definovat povinnosti lidí v rámci opakujících se dílčích aktivit při plánování práce, zadávání úkolů atd. Pokud to platí pro projekty, je nasnadě, že u úkolů (viz MBO) by to mohlo být obdobné.

Zjevně existují i "rámcově definované procesy" (které nemají explicitně a přesně definované činnosti, které mají být provedeny, v době návrhu / design time, ale jsou upraveny a doplněny vhodnými činnostmi na úrovni instance ~ v době realizace / run time). Specifickou verzí je "ad hoc" činnost (či flow), která přesně odpovídá charakteristice MBO úkolu.

• Jediná role (člověk), tedy všechny dílčí činnosti probíhají v rámci jedné instance.
• Má proběhnout "co nejdřív" - ideálně v "jednom souvislém čase".
• Není předpoklad, že by se opakovala (nic natolik podobného, aby stálo zato zobecňovat průběh).

Případně se detailní popis typů procesů/workflow objeví v metodice. Velmi zjednodušeně - standardní (rutinní velmi pravidelně se opakující činnosti), příležitostné (vyskytující se nepravidelně, ale mají relativně pevný rámec + mohou být doplňovány ad-hoc činnostmi) a jedinečné/jednorázové (ad-hoc viz výše).

Principy MBO & workflow

Podstatou (viz metodika) řízení pomocí úkolů je formalizace zadání, nezbytný dohled a případné korekce v průběhu a při převzetí výsledku. Všechny části jsou důležité - při sjednání zadání je kritické dodržovat pravidla, mít zaznamenány veškeré dohody a použité podklady (informace). Sledování průběhu může výrazně ovlivnit pravděpodobnost úspěšného dokončení. Stejně důležité je realizaci i realizátora po skončení  práce vyhodnotit.

Protože MBO stojí na formalizaci (evidenci), je nezbytné mít každý úkol konzistentně zaznamenaný. Zejména pokud spoléháme na SMART princip, musí být jednoznačně definovány veškeré atributy (účastníci, zadání, termíny, postup, výsledky atd.). Typicky budeme využívat další informace prezentované dokumenty či jinými daty, takže úkol by měl mít svůj "pracovní prostor" (technická podoba není rozhodující, ale je výhodné, když je snadno dostupný / integrovaný).

Vycházíme z následujících (zjednodušných/rámcových) potřeb při řízení pomocí úkolů:

• Iniciátor/zadavatel vytvoří záznam obsahující standardní sadu údajů (včetně seznamu potenciálních odkazů na využívaná data).
• Typický záměr vychází ze zpracovaných podnětů / požadavků.
• Určí (případně by mohlo být zajímavé podpořit "hledání") nejvhodnějšího realizátora.
• Sdílí s ním podklady a návrh zadání.
• Vyžádá si převzetí zadání (realizátor je v dané lhůtě povinen projít podklady a doplnit zadání).
• Připomenout / upozornit obě strany na exspirující lhůtu.
• Umožnit realizátorovi úkol odmítnout.
• V nezbytně nutné podobě realizátor vytvoří (jednoduchý) plán práce (kdy co). Ideálně by si práci na úkolu měl naplánovat do kalendáře (zcela ideálně to proběhne automaticky - z definovaných pracovních bloků vznikou časové bloky, které si najdou volný prostor v kalendáři realizátora (popř. podle nastavení odsunou méně naléhavé již naplánoavané časové bloky jiných činností). 
• Zahájení a případně průběh by si měl zadavatel mít možnost ověřit (viz též kontrola).
• Pohlídat termín dokončení.
• Zaznamenat výsledky.
• Připomínkovat podklady a zadání a výsledky.
• ...

Proces řízení pomocí úkolů

Jednoznačně máme minimálně dvě role (zadavatel a realizátor) a konkrétní činnosti, které by měly být prováděny, aby se principy řízení pomocí úkolů mohly uplatnit. Tedy vznikne záznam nesoucí záměr (zadání "úkolu"). Je samostatně, protože technicky vzato v procesu budou vznikat elementární úkoly (činnosti) vázané na stavy tohoto záměru.

Snad nesporně "vhodný" úkol z praxe z dříve identifikovaných příkladů: Je potřeba vytvořit "nový" (fakticky žádný neexistuje) kalkulační mechanismus (pro zabudování do nástroje pro podporu nabídek / CRM). Vedoucí obchodu nebo někdo, kdo má k metodice cenotvorby nejlepší předpoklady, má sestavit model & metodiku. Jenom výchozí verzi, u které  nemá ani on, ani nikdo další vymýšlet kulaté čtverce (takto by to mělo být v libovolně velké firmě, i když konkrétně v tomto případě nebyl nikdo další, kdo by se tím chtěl zabývat).

Potřebujeme konzistentní (podložený) výchozí návrh. Nesporně práce pro jednotlivce. Jistě bude užitečné výsledky před předáním pro zabudovávání do nástroje pro tvorbu nabídek ověřit a připomínkovat, ale pokud jeho autor je skutečně nejvhodnějším autorem (popř. garantem pro vytvoření externím expertem), nemá do toho do té doby zatahovat nikoho dalšího. Ona potřeba je "...navrhnout závazný způsob tvorby nabídkových cen..." (použitelná forma standardizace veškerých faktorů, které v daném obchodním prostředí mají nabídkovou cenu ovlivnit, včetně kritérií, jež mohou být čistě subjektivní - založené na názoru konkrétního obchodníka - i takový faktor chceme zaznamenat a předem stanovit, na kterou část ceny může mít jak velký vliv).

Zadání a plnění tohoto úkolu by mělo probíhat v následujících krocích (jen výchozí zjednodušený nástřel).

• [Nový] Zadavatel: Vybrat realizátora a formulovat výchozí zadání ("proč").
• [Zadaný] Realizátor: Zpracovat podklady, navrhnout výstupy, plán práce a akceptační kritéria.
• [Připravený] Zadavatel: Případně vrátit/upřesnit/revidovat - nebo potvrdit až bude zadání vyhovující (včetně plánovaných kroků, které realizátor hodlá udělat - konkrétní činnosti - dílčí úkoly s datem, trváním a výsledkem).
• [Potvrzený] Realizátor: V plánovaném termínu zahájit.
• [Probíhající]
  Realizátor: Po skončení každého dílčího kroku (má dopady do kalendáře a seznamu práce) aktualizovat plán práce záměru (což může vést k přeplánování), spotřebu a zbývající práci a očekávané datum dokončení.
  Zadavatel: Zkontrolovat (popř. namátkově) zahájení, postup, ...
  Má možnost si nastavit "připomínání" své zamýšlené aktivity vázané ke konkrétnímu úkolu. Dostává (dle nastavení) notifikace o tom, jak realizátor "postupuje". Např. pokud v plánu prací zůstane viset činnost po termínu, dostane upozornění. Stejně tak, když se očekávaný termín dokončení posouvá za stanovený limit.
• [Upřesňovaný | Upřesněný] Realizátor & zadavatel: Pokud se objeví potřeba, změnit zadání a/nebo plán prací atd. Upřesnění může vycházet od zadavatele, ale mělo by jít cestou realizátora, popř je potřeba doplnit stav (např. "Nejistý"), který bude znamenat povinnost realizátora navrhované změny zapracovat atd.
  Ukončením upřesňování se dostane zpět do stavu "Probíhající". Dokud práce neskončí.
• [Dokončený] Zadavatel: Ověřit splnění zadání.

Těch stavů a činností bude víc. Důležité je, že se každá změna stavu instance je standardním způsobem notifikována tomu, kdo je povinen na ni reagovat (role, která má přiřazenu činnost, která je na stav vázána. Na níže zobrazeném formuláři je ukázka, jak vypadá vlastní plán práce realizátora (Tasks) v rámci MBO-úkolu/záměru (WorkReason). Workflow pro řízení průběhu realizace záměru (což nemusí být jen MBO-úkol) běží nad záměrem a sleduje průběh prací (činností ad hoc přiřazených záměru). Pokud je některá z činností složená (realizována posloupností jiných činností), pracuje s nimi (o úroveň níž).

Jednotlivé činnosti úkolu mohou vznikat pomocí šablony nebo jako nové. Což je důvod, proč činnosti (instance) v systému nespoléhají na své šablony, ale mají veškeré údaje převzaté (resp. zadatelné / modifikovatelné... popř. pokud šablona existuje, může jejich změny zablokovat). Realizátorem definované kroky a výstupy (pro splnění úkolu) jsou tomuto řídícímu mechanismu k dispozici (úplně stejně, jako jsou vyhodnocovány instance a úkoly vygenerované rutinními procesy). Proto je může "hlídat" (notifikovat či eskalovat jejich ne/plnění). Činnosti, které mají realizátor a zadavatel provádět pro obsluhu úkolu/záměru, představují souběžné režijní workflow, definované obecným životním cyklem úkolu.

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 MBO či máte příklad úkolu, ozvěte se. Umíme pomoci včetně nezbytného rozvoje dovedností.