Správa přidělených činností

Předpokládejme, že je nesporné, že pro samostatné pracovníky je účelné mít evidenci toho, co mají dělat. Stejně tak berme za dané, že nevymýšlíme byrokracii pro byrokracii, ale výhradně proto, abychom všem dotčeným usnadnili život. Tedy žádná dogmata - pro každé prostředí a čas se hledá se optimální forma a struktura. Může být, že optimální formou je nic neevidovat (nevyplatí se to... v daném prostředí, se stávajícím spolupracovníky a strukturou činností prostě není potřeba podpořit, aby se to, co je potřeba udělat, zvládlo v potřebném termínu ani nic podobného - všechno funguje i bez podpory). Pokud to tak není, zkusme naznačit, jak by taková podpora mohla vypadat.

Reálné scénáře

Podpora / servicedesk

Nemusí jít o IT. Existuje interní nebo externí "rozhraní" (tedy povinnost) pro vyžádání si zásahu v případě, kdy člověk v organizaci potřebuje pomoci, jelikož mu něco nefunguje tak, jak by mělo. Třeba atomový reaktor nebo v horším případě kávovar. Takže předá (neřešme formu) požadavek na odstranění potíží (nebo zlepšení podmínek nebo cokoli jiného). 

Takový požadavek má stanovenu lhůtu na reakci, popř. vypořádání (poskytnutí / zajištění takové akce, která požadavek uspokojí). Prostě musí mít, jinak je funkčnost dané organizace nepřijatelně nespolehlivá. Zase se nezabývejme formou, ale počítejme s tím, že se může vyskytnout více požadavků ve velmi krátkém čase nebo že člověk, který je má přijímat / odbavovat, dělá právě něco jiného. Nebo dokonce není vůbec k dispozici. Požadavky musí být shromažďovány a čekat, až je někdo odbaví.

Nemá smysl vyvolávat poplach, tak je nastavena (podle typu požadavku - přičemž neklasifikovaný požadavek má nejkratší lhůtu na přijetí, jelikož není jasné, o co může jít) lhůta, po kterou se čekání považuje za přijatelné. Jakmile je tato lhůta překročena, je potřeba informovat člověka, který zodpovídá za to, že toto (popř. obdobná či všechna) rozhraní funguje (popř. pokud ten v definované lhůtě nezareaguje, musí se vyvolat havárie, která znamená eskalaci problému na všechny pozice, u kterých to dává smysl). 

Přijetí objednávky

Je zřejmé, že podstata situace je v podstatě shodná jako v případě incidentu servicedesku. Typická rutinní činnost - lidé, kteří jsou v roli zpracovatele objednávek dle svého případného alternativního vytížení a objemu nezpracovaných objednávek by je měli vyřizovat tak dlouho, dokud nějaké nevyřízené existují (případně do časového limitu apod.)

Projektový úkol

Člověk se stane členem projektového týmu. Vedoucí projektu (nechme stranou detaily) funguje tak, jak by měl a sjednává s členy týmu jejich úkoly ("task"). Jak víme, projektový úkol je typický kandidát pro MBO. Bez ohledu na to, jak důsledně funguje mechanismus pro vyjasnění co jak a proč má dotyčný provést, nastane situace, kdy už dokáže odhadnout, co všechno bude nutné udělat - neměl by to být jednoduchý úkon typu "vyvez hnůj". Takže si tu práci, kterou má před sebou musí rozplánovat.

Jinak nemůže (zodpovědně) slíbit pravděpodobný termín dokončení.

Techniky plánování v termínovém kalendáři jsou popsány v souvisejím článku. Podstata je jednoduchá - bloky práce musí respektovat reálné kapacitní i termínové možnosti. Pokud je termínový kalendář uživatele platný, tak je rozvržení práce relativně jednoduché a fakticky by mohlo proběhnout i automaticky. Algoritmus může být schopen zohlednit i pravidla na posouvání méně důležitých aktivit nebo termínových nárazníků.

Aktivita ad hoc procesu - např. připomínkovat dokument

Z hlediska inidividuálního uživatele je / může být situace obdobná, jako úkol, popř. rutinní činnost. Ale mohou tam být zajímavé odchylky. Např. povinnost provést požadovanou činnost v dané lhůtě. Může se jednat o jednu kompaktní činnost (nikoli práce na více časových bloků jako u úkolu). Možná se dá odmítnout. Rozhodně 

Sporné scénáře

Otázka je, nakolik dává smysl se zabývat např. tím, kolik času má k dispozici a na co jej spotřebovává skladník. To je natolik zřejmé, že snad diskuse není potřeba. Ale někde to může být opravdu sporné. Máme jednoduché kritérium - pokud takového člověka chceme začlenit do aktivit, ve kterých záleží na termínech a dotyčný člověk má možnost své termíny ovlivnit, bude muset fungovat stejně, jako ostatní.

Některé systémy nebude možno (přímo) integrovat do centrální správy kapacit.

Další ošidné téma jsou "režijní" činnosti. V metodice pro plánování času (aktuálně náznak v metodice používání termínového kalendáře, více v interní metodice adaptované na konkrétní podmínky na základě analýzy potřeb a iniciálního sjednocení představ) je rozumné poměrně detailně a konkrétně nastavit pravidla, co dává a co nedává smysl plánovat. V principu (dle podmínek) není účelné plánovat činnost pod jednu hodinu. To také není dogma a určitě platí, že to (viz výše rutinní činnosti) neplatí pro dávku - např. zpracovat všechny nezpracované objednávky apod. Je dobré orientačně sledovat, kolik času režie pohltí. Zkusit to odhadnout. Nebo se spolehnout na to, že sledované činnosti budou zaznamenány přesně a potom je režie veškerý ostatní čas mezi zahájením práce a jejím ukončením. Záleží na tom, čeho je potřeba v aktuální fázi rozvoje řízení času dosáhnout.

Kdy potřebujeme zjistit či připomenout, že máme něco dělat

Otázka je, nakolik dává smysl se zabývat např. tím, kolik času má k dispozici a na co jej spotřebovává skladník. To je natolik zřejmé, že snad diskuse není potřeba. Ale někde to může být opravdu sporné. Máme jednoduché kritérium - pokud takového člověka chceme začlenit do aktivit, ve kterých záleží na termínech a dotyčný člověk má možnost své termíny ovlivnit, bude muset fungovat stejně, jako ostatní.

Kalendář

Úkoly 

Workflow

Je nezbytná jediná centrální správa aktivit?

Možná je ta otázka spíše v poloze zda je reálné vyžadovat jedinou centrální agendu. Život vyžaduje, aby se úkoly (práce), kterou uživatel má vykonat, objevila nejen v jakémsi centrálním "seznamu práce" (workplace | workbench... těžko najít obecný význam... v této roli by mohly být integrační platformy jako třeba Camunda, ale úplně stejně tak aplikace v M365 - systém analogický a zahrnující Approvals - přesně tam směřují naše ambice), ale také odpovídající povinnosti přímo v agendách, do kterých má uživatel přístup (má v nich něco dělat).

• Někde (zkusíme navrhnout) musí být seznam, ve kterém jsou pokud možno všechny práce, které má člověk provést. Otázkou je, jestli by to nemohl být ten termínový kalendář.
• Není ovšem reálné, že by jakýkoli centrální systém dokázal zajistit takové chování rozhraní, aby nebylo potřeba spouštět aplikaci nativně obsluhující příslušnou práci (pokud bude v seznamu práce ono přijímání objednávek, tak vůle uživatele provést danou činnosti nutně vede ke spuštění příslušného systému pro zpracování objednávek, práci v něm a jeho ukončení). Ne každý systém má možnost při vyvolání přejít na tu instanci, na které je potřeba pracovat.
• Potřebujeme, aby se v centrálním seznamu objevily i práce, které probíhají v samostatném či dokonce izolovaném systému.
• Další možností (vedle kalendáře) by mohly být úkoly (pokud používáme aplikaci, která vedle elektronické pošty, kontaktů a kalendáře podporuje i plánování a plnění úkolů).
• Prozatím nevíme o žádném "univerzálním systému". Nejspíš není reálný. Každý z ostatních používaných nástrojů, pokud spoléhá na podporu typu workflow (tedy předávat práci vztahující se k instanci procesu dalšímu lidskému účastníkovi toho pracovního toku), musí mít vlastní funkčnost. Některé takové systémy umožňují své workflow propojit s jinými systémy a převzít tuto jejich funkčnost, ale obvykle to bude natolik omezené, že to nebude dávat smysl.

Zkušenost ze systému pro podporu řízení servisu - potřebujeme seznam plánovaných zásahů všech terénních techniků - minimálně proto, aby bylo možno při komplikacích zásah odvolat nebo přidělit někomu jinému. Přestože se práce objeví v osobním termínovém kalendáři technika (mají být plánovány na jeho základě), musí o nich vědět a být schopen je upravit dispečer. Rozhodně pohodlněji, než zásahem do kalendáře. Analogický scénář při řízení projektu.

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.