Koncepce nasazení MS Teams

Když se MS Teams začaly používat, nebyly klíčovým způsob využití schůzky. Potom přišel COVID. Najednou všichni museli mít nějaký komunikační nástroj. A když už je měli, tak si s tím začali "hrát". Bez větší přípravy. Také proto, že se technologie tváří, že stačí víceméně náhodně klikat a ono se něco stane. Že je dobrý nápad zakládat nové týmy kdy koho napadne. Že nepotřebujete pravidla. 

Technologie jsou zákeřné.

Pokud je uvádíte do praxe bez dostatečně jasné představy, co s jejich pomocí chcete dosáhnout, ošklivě se to vymstí.

Běžná praxe 

Někdo ve firmě to spustil - ani to nemusel být člověk z IT. Třeba "angažovaný" uživatel, který si rád zkouší nové věci. Třeba řešil některé z témat (viz dále) a považoval za rozumné si k tomu přizvat některé spolupracovníky. Což je v podstatě v pořádku. Jen by to tak neměl dělat každý o své vůli. Potom kdosi jiný zjistil, že ve firmě s 20 lidmi u počítačů je více desítek týmů, většina naprosto irelevantních až obskurních.

Nebo rovnou někdo, kdo se cítil být dostatečně kompetentní, rozhodl "...když jsou to Teams, tak s nimi vytvoříme pracovní prostory pro stávající týmy..." - typicky útvary funkčního organizačního uspořádání. Takže vzniknou týmy "Logistika (Výroba)", "Finance", "Nákup", "Vedení", "Personalistika".

Zásadní otázka je - vyhovuje? Pokud ano, tak je to skvělé. 

Pokud to skřípe, stojí zato se zamyslet, jestli se to dá dělat jinak. Je pravda, že pokud jste neměli představu, jak by to fungovat mělo, tak nemusí být vidět, že něco není v pořádku. Je pravda, že osvícenější uživatelé se snaží prosadit "týmy" podle toho, že existují oblasti či témata, o kterých je potřeba komunikovat (zásady a typologie komunikace je čím dál akutnější téma, zatím není prostor, takže jindy/jinde). Jenže pokud není jasné, na základě jakých principů by měla být spolupráce organizována, spontánní vytváření týmů moc nepomůže, v delším horizontu je destruktivní.

Jak chápat "téma"

Běžné × doporučené řešení

Příklad - obchodní ředitel přijde na poradu vedení s tím, že dosavadní systém odměňování nevyhovuje "jeho" potřebám. Samozřejmě jej nějaká část ostatních řídících pracovníků podpoří, ekonom a personalista se budou bránit. Vypukne naprosto neplodná debata (to stejné se stane, když se to odehrává v písemné podobě, jen s mnohem větší pravděpodobností a mnohem menším užitkem, pokud je to technicky možné). Může se stát, že výkonný ředitel rozhodne, že se tímto podnětem je účelné zabývat (rozumí se na té poradě, popř. všech dalších).

S využitím Teams to může dopadnout tak, že se udělá tým pro daný záměr nebo kanál v týmu vedení a tam se budou (spíše neorganizovaně/neřízeně ~ chaoticky) někteří účastníci vyjadřovat, obvykle k tomu, čemu oni sami vůbec nerozumí. Těžko předvídat, k čemu to povede.

Ten tým nebo nový kanál tomu nejspíš nepomůže.

Korektní reakce by mohla být:

• Výborný podnět, přijímáme to do seznamu záměrů.
• Upřesníme zadání - komplexní revize systému hodnocení, optimalizace výkonnostních kritérií, založená na analýze/definici podnikových potřeb nejen vzhledem k systému odměňování (první krok).
• Všichni formulují svá doporučení směrem k cílům, popř. průběhu a omezením.
• Pan obchodní ředitel shromáždí všechny podklady, které k tomuto záměru získá.
• Společně s tím, kdo mu bude ochoten pomoci, připraví první návrh alternativ & možnosti realizace, referenční implementace a cokoli dalšího, co lze považovat za relevantní.
• Podnět (již) je založen v systému správy požadavků (jinak by se nemohl dostat na program jednání).
• Cílem přípravy je odhad přínosů, pracnosti a rizik jako vždy.
• Až to bude k projednání, přihlaste to na poradu vedení.

Pokud nemáte systém pro správu požadavků, nejdřív si musíte něco takového opatřit.

Je úplně jedno, jestli ten systém je vysoce sofistikovaný digitální zázrak nebo papír. Pokud se změna má uskutečnit, musí to být připravena jako regulérní změnový projekt.

Projekty je rozumné spravovat s využitím Teams.

• Úkol pro přípravu musí být sjednán pomocí MBO.
• Realizátorem přípravy je ten, kdo s námětem přišel nebo případně někdo vhodnější (tady např. personalista).
• V pravidlech by mělo být ukotveno, že vrcholový řídící pracovník nikdy nic takového dělat nesmí.

Pokud nemá nikoho, koho by mohl pověřit něčím trošinku náročnějším, tak nejříve musí najít rozumného personalistu (to se možná dá outsourcovat, stojí to za zvážení, diskusi a ověření), který mu doručí potřebnou kvalifikovanou kapacitu (např. formou personálního / manažerského auditu a rozvoje dovedností stávajících spolupracovníků).

Příklady dalších témat

Je jasné, že pro projekty (a cokoli podobného) je rozumné mít tým & Team. Na rutinní aktivity (vyskytují se opakovaně a lze je standardizovat - šablona postupu, kde je většina činností předem definována, byť mohou mít alternativní průběh dle podmínek / parametrů) musí být procesy. Vedle jasně ohraničených aktivit ovšem máme oblasti, které nejsou ani projektem, ani (jednoznačným) procesem. 

• Tvorba/aktualizace podnikové strategie - informačně intenzívní činnost omezené skupiny spolupracovníků, která potřebuje silnou podporu pro ad-hoc dělbu práce (úkolování), organizaci spolupráce (jednání / komunikace / sdílení & účast na vzniku a využívání informačních zdrojů...). Přestože "strategii" bychom měli chápat jako proces.
• Inventarizace - možná poněkud trapný příklad, ale v jedné firmě se to osvědčuje. Sice se většinou provádí jenom jednou ročně, ale je velmi pohodlné, když je dokumentace a podpůrné nástroje (ovlivněné předchozími zkušenostmi) na jednom místě. Lidé v inventarizačních komisích se mění jen zčásti (máme zájem, aby to dělali ti, kdo už to umí). Také je to ovšem bezpochyby proces. Tady je dobře vidět, že je žádoucí jej při/před/po každé instanci upravovat. Proto vlastní "prostředí" dává (může dávat) smysl.
• Tým specializované péče - omezená skupina, která má analogicky strategii potřebu sdílet informace a koordinovat spolupráci. Takový tým se objeví hned, jakmile nad tématem začnete přemýšlet - potřebujeme prostředí, ve kterém budeme spravovat / řídit nasazení a rozvoj právě Teams (či čehokoli obdobného, co si vyžaduje trvalou pozornost).

Jak uvedeno výše - rozhodně není dobré chápat nic jako dogma. Moderní technologie jsou až nepřístojně přizpůsobivé. Cokoli uděláte promyšleně, mělo by fungovat. Naše zkušenost však preferuje nastavit si úmyslně raději zábrany, abychom si život zjednodušovali. Víme, že korektní řešení se v rozumném prostředí většinou prosadí díky tomu, že se ukáže, že žádná lepší (jednodušší) cesta není. To může v některých situacích platit např. pro CRM.

Jak naložit s "problémem"

Příklad - ředitel logistiky: S novým logistickým partnerem je asi potíž, protože stoupl počet nekompletních dodávek ze zanedbatelných jednotek měsíčně na desítky a vzhledem k tomu, že vychystávání i balení v expedici monitorují kamery a žádný dispečer nenašel potenciální příčinu závad, je pravděpodobné, že se to ztrácí po cestě. Nevím, co s tím.

No... to by asi měl vědět a netahat to na poradu vedení.

Dejme tomu, že je nezkušený a navíc se bojí hyperaktivního výkonného ředitele. Takže si jde pro alibi. Korektní reakce by měla být "...tak se pokus něco vymyslet, kolegové nejsou taky včerejší, mám pocit, že ve firmě XY měli podobný problém, můžeš se obrátit na firmu, co nám pomáhala budovat systém řízení logistiky... Nebo si zajeď za šéfem té dopravní firmy a prober, jestli o něčem vědí nebo mohou pomoci, měli by mít nejvíc zkušeností. Je známo, že to tady máme pod kamerami. A taky se podívej, co na tohle téma máme ve smlouvě."

Ani k téhle záležitosti asi nechceme zakládat Team.

Záležitosti - jaká situace vyžaduje jaký přístup

Nejdřív si udělejme jasno v tom, jaké typy situací v běžné organizaci vznikají a jak by se měly řešit.

Tradiční organizace - funkční organizační uspořádání

V běžným způsobem řízení organizaci funguje direktivní přístup. Lidé (občas) dělají to, co jim je nařízeno. Výsledky závisí na osobním nasazení a zájmu. Naprostá většina lidí, kteří jsou ochotni něco dělat, tak to dělá nejlépe, jak to dokáže. Každý jinak, občas pokaždé jinak. Pokud k řešení problému potřebují účast někoho dalšího, závisí to, co kdo bude dělat, na přesvědčovacích schopnostech toho člověka, který chce výsledku dosáhnout. Těžko najít něco takového, jako "tým" (neřku-li účelový, heterogenní, autonomní, samoorganizující, ...).

Moderní organizace - procesní přístup

Primární potřebou (tématem) je rozvoj - zlepšování procesu. Protože je to ryze procesní záležitost a probíhá v neustálých iteracích včetně toho, že se i v rámci jedné procesní oblasti pracuje na více instancích současně, je případné uplatnění "týmového" přístupu sporné. Tento proces spíše "direktivně" řídí vlastník procesní oblasti. Instancí je příliš mnoho a nelze je řídit izolovaně. Lidé by se vyskytovali v přílo

Dočasná působnost

Týmy mají být dočasné. Primárně jde o jednorázové jednoúčelové aktivity, které odpovídají myšlence "...propojit skupinu lidí, která má vykonat něco výjimečného...". 

• Jednoduše (pomocí šablony pro konkrétní typ akce) vzniknout.
• Relativně krátce fungovat = podporovat:
  • Organizaci - kalendář týmu - plán aktivit.
  • Interakci - online či osobní jednání - záznam a další vymoženosti.
  • Sdílení a řízení přístupu k digitálnímu obsahu.
  • Získávání dat (např. pomocí Forms).
  • Úkolování.
  • Případně pokročilejší nástroje - např. projektového řízení nebo správy požadavků.
• Předat výsledek (např. aktualizaci dokumentace či pracovních postupů, zprávu o provedení úkonu, k jehož uskutečnění spolupráce směřovala... např. vyúčování či kontrola dotačního projektu apod.).

Přestože mají být dočasné, může ta dočasnost být poměrně dlouhodobá. U projektů je jasné, že tým má zaniknout s ukončením projektu. Ale jsou "témata", která si "zaslouží" (je to vhodné řešení) tým a jsou dlouhodobá nebo trvalá. Takže mimo projektů je rozumné vytvořit týmy např. pro:

• Firemní strategii - podle podmínek bude jeden nebo mohou existovat další pro každou realizační strategii (to se moc neosvědčilo). Možná jeden z případů, kdy by stálo zato vytvořit pro realizační strategie kanály (opravdu záleží na lidech a prostředí).
• Nasazení a rozvoj TEAMS.
• Digitalizaci/automatizaci.
• Rozvoj firemní kultury.

Nebo cokoli obdobného - je to sice "napořád", ale nelze předem definovat všechny činnosti.

K čemu je koncepce 

Tím, že formuluje principy/zásady (krom toho by tam mělo být i zadání pro "nasazení/rozovoj").

• Urychlují zvládnutí oblasti (zde využití Teams).
• Omezí plýtvání kapacitou a tvůrčím nadšením.
• Pomohou zabránit slepým uličkám - ochrání uživatele před zklamáním a odmítnutím.
• Sníží riziko provozních selhání (tedy závažnějších problémů v důsledku nevhodného užití).
• Minimalizuje neplodné diskuse a neřízené experimenty.

Prakticky jistě lze minimálně 80% obsahu koncepce adaptovat (nikoli bezmyšlenkovitě zkopírovat) z obecné verze. Není potřeba vymýšlet kolo. Ten zbytek je tak jako tak potřeba upřesňovat průběžně.

Identifikuje základní role. Primární je řídící tým organizace a její výkonné procesní týmy.

• Správa Teams... tým pro nasazení a rozvoj. Pravděpodobně jeden z "trvalých" týmů.
• Technický správce... konfigurace, práva atd.
• Metodik.
• Vývojář... spíše analytik - doplňuje funkčnost (předpokládá se Power Platform).
• Vedoucí týmu... moderuje práci týmu & vymáhá korektní využívání prostředí.
• Člen týmu... interní × externí.

Kdy, kdo a jak ji chceme použít.

• [Správa Teams] Při přípravě nasazení (plán prací). Pro tvorbu/popis procesů této oblasti.
• [Technický správce] Pro formulaci zadání pro IT (konfiguraci infrastruktury).
• [Metodik] Definuje nezbytné dovednosti - je základem pro program jejich rozvoje.

Co by měla obsahovat

Vychází z toho, k čemu ji kdo využívá.

• Urychlují zvládnutí oblasti (zde využití Teams).

 

Jak začít

Hlavně se nenechte přesvědčit, že vám může pomoci správně začít školení od vašeho poskytovatele IT podpory. Opravdu je nutné nejdřívě vědět, co skutečně potřebujete (jak to naznačuje předchozí článek i pokračování). Analýza potřeb & specifikace požadavků.

Dejte vědět, jak používáte Teams. Nebo jaké máte pochybnosti. Rádi poradíme nebo pomůžeme. Zadarmo, pokud budeme moci zkušenosti sdílet.