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

Mít na jednom místě, co má člověk udělat. Jasně - měl by to mít v kalendáři. Souvisí to s řízením využití kapacit (i osobního času). Způsobem používání termínového kalendáře. Možná vazeb na jiné činnosti (vlastní nebo cizí). Není to úplně jednoduché. Ne každý vidí užitek.

Předpokládejme, že je nesporně účelné mít evidenci toho, co mají lidé (zejména samostatní pracovníci) dělat. Důvody jsou zřejmé - řízení času a kapacit + termínů & případně koordinace. 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í v aktuální či budoucí situaci se hledá se optimální forma a struktura (dat, funkčnosti, vazeb, ...). 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). Když nepotřebujete nic zlepšit, není potřeba číst dál. Pokud o zlepšování máte zájem, 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í 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). Výhodou je, že všechny požadavky lze směřovat na jedno místo a vyřizovat je v principu stejným způsobem.

Takový požadavek má stanovenu lhůtu na reakci, popř. vypořádání (poskytnutí / zajištění takové akce, která požadavek uspokojí). Musí mít, jinak je provozuschopnost dané organizace nepřijatelně ohrožena. 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 daném okamžiku vůbec k dispozici. Požadavky musí být shromažďovány a čekat, až je někdo odbaví.

Nemá smysl vyvolávat poplach, pokud není požadavek okamžitě řešen, tak je nastavena (podle typu požadavku - přičemž neklasifikovaný požadavek má nejkratší čas pro přijetí - 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). Bezpochyby automaticky.

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

Oba scénáře jsou typicky rutinní procesní činnost. Naprosto zásadní je, že povinnost provést definovanou činnosti se nevztahuje (až na výjimky) na konkrétního uživatele, ale na roli. Tedy všechny uživatele v dané roli, kteří právě neprovádějí jinou činnost (popř. nečeká na ně povinnost s vyšší prioritou). Typicky nevyřízené objednávky (což je situace, kdy se v registru objednávek vyskytuje alespoň jedna ve stavu "nevyřízená") jsou určeny pro kteréhokoli uživatele, který má roli "zpracovatel objednávek". Každý z nich má povinnost (pokud má volnou kapacitu) vzít první z nevyřízených objednávek a zpracovat ji (detaily a výjimky neřešme).  Povinnost má splněnou, až již neexistuje žádná další nevyřízená objednávka bez ohledu na to, kolik jich zpracoval on nebo někdo jiný.

Je nutno zajistit, aby si stejnou objednávku nemohlo "vzít" (začít s jejím vyřizováním) více uživatelů, což by měla být standardní funkčnost (záznam se tím, že jej někdo otevře pro úpravy, zamče nebo jinak označí a tím je pro ostatní nedostupný, takže se ani nezobrazuje; pokud si to ten původní zpracovatel rozmyslí, zase se objeví).

Standardní rutinní činnosti obecně

Záznam o "povinné činnosti" (informace, že někde čeká jedna nebo více instancí agendy, kterou mají povinnost vyřizovat) se má zobrazit všem uživatelům v této roli - a to jak v aplikaci pro zpracování objednávek, tak v případném centrálním registru. Nemá smysl ani není možné to zapisovat komukoli do kalendáře. Trošku jiné téma je, jestli a jak se má zaznamenávat provedená práce. Tedy když některý uživatel objednávku zpracuje.

U některých instancí (např. u požadavku na servicedesk-u, ale platí to pravděpodobně pro většinu entit) je zřejmé, že musí být identifikován ten, kdo požadavek přijal. Mimo jiné proto, že je žádoucí, aby se pokračováním jeho vypořádání zabýval - pokud je to součástí jeho role - stejný člověk. Ale především proto, aby zpracování bylo jednoznačně trasovatelné. Což se nijak netýká "povinné činnosti", týká se to vždy dané instance (objednávky, podnětu, požadavku, ...). Případný preferovaný zpracovatel by měl být identifikován na úrovni záznamu, ostatní informace asi mohou či nemusí být zaznamenávány do konfigurovatelné historie jednotlivých instancí (někdy může být užitečné zaznamenat celý životní cyklus konkrétní instance). Dalším důvodem jsou data užitečná pro statistiky jednotlivých typů činností.

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 může probíhat i automaticky. Algoritmus může 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. 

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. Je zřejmé, že to nepřináší žádný užitek, takže diskuse není potřeba. Ale u někerých pozic (zejména pokud konkrétní člověk má více rolí) to může být sporné. Existuje 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í. Zase je potřeba hledat rozumnou podobu / rozsah.

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 / činnosti a jejím ukončením. Záleží na tom, čeho je potřeba v aktuální fázi rozvoje řízení času/kapacit dosáhnout.

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

Potřeba evidovat, že je potřeba cosi udělat, může ovšem vznikat prakticky kdekoli. Obvykle se požadavek na práci (kapacitu) objeví ve zprávě elektronické pošty. Existují aplikace jako je "ToDo" a řada obdobných. Požadavky na jednání. Dost podstatné bude umět do kalendáře dostat i spotřebu kapacity na očekávaný objem standardních činností (ale není to neřešitelné - stačí statistika a rozumný způsob řízení rezerv). Téměř jistě si chceme plánovat i "vlastní práci" - tedy něco, co není iniciováno naznačenými způsoby (nepatří to do existujících "systémů"). Požadavky na provádění činností vznikají, kam se člověk podívá...

Realitu každodenního provozu a možnosti zlepšení způsobů zadávání práce si asi umí každý představit. Pokusíme se rozpracovat případovou studii, pokud bude zájem...

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, viz též výše) 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/měl být ten termínový kalendář.
• Komplikace
  • Není reálné, že by jakýkoli centrální systém dokázal zajistit takové chování (svého) 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. Byť se dají hledat různé pomůcky...
    Pokud do budoucna provozní systémy budou mít opravdu inteligentní API, tak není vyloučeno, že se vyplatí vytvořit přímo v nástroji pro správu činností rozhraní, které nahradí nativní způsob práce s cílovou agendou.
  • Potřebujeme, aby se v centrálním seznamu mohly objevit i práce, které probíhají v samostatném či dokonce izolovaném systému. Protože potřebujeme platné kalendáře.
• 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ů). Popř. by se dalo uvažovat s některou "nezávislou" synchronizovatelnou správou "práce" (aplikace typu "ToDo").
• Prozatím nevíme o žádném "univerzálním systému". Nejspíš v současné době není příliš reálný. Každý z ostatních používaných nástrojů, pokud spoléhá na funkčnost 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 tak jako tak vlastní funkčnost (protože výrobce nemůže vyžadovat dodatečný samostatný nástroj... bez ohledu na to, že by to pro uživatele bylo mnohem výhodnější). Tedy posílat zprávy, aby si jich uživatelé všimli. 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 komplikované & 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. Práce se musí objevit v osobním termínovém kalendáři technika (termíny mají být plánovány na základě v něm zjištěných volných bloků), obvykle je bude zadávat a musí být schopen je upravit dispečer. Rozhodně pohodlněji, než zásahem do kalendáře. Při automatickém vyhledávání volné kapacity se dá zohlednit významně větší množství parametrů / kritérií, než při "ručním" (očima) hledání - např. zaplněnost kalendáře, tedy úroveň rezerv, přejezdy či přímo optimalizace tras. Analogický scénář při řízení projektu.

Synchronizace práce a kalendářů

Pokud by např. ve výše uvedeném příkladu existovaly sjednané návštěvy / servisní zásahy pouze v kalendáři technika, je jejich případné odmítnutí technikem poměrně komplikované. Při synchronizaci by stačilo termín z kalendáře vymazat (pokud bychom nestáli o zdůvodnění atd.) - protože v centrálním seznamu zůstane, jenom se odstraní vazba na technika a termín. Ve stejný okamžik může být notifikován dispečer, který se pokusí pro sjednaný termín najít jiného vhodného volného technika (což v principu může proběhnout také automaticky a technik dostane danou zprávu již s návrhem přesunu.

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.