Komplexní zakázky s MS Teams

Pozor - toto není návod, jak postupovat - pouze nástin možností. Pro korektní a účelné nasazení MS Teams pro řízení zakázek je nanejvýš vhodné postupovat na základě procesní analýzy, popř. s využitím procesního metamodelu. Nachystáme odpovídající variantu tohoto produktu. Je dobré si  pro lepší vnímání očekávaného způsobu použití Teams přečíst předcházející články - Jak používat MS Teams a Kanály. Diskutovat se dá u příspěvku na LI.

Zakázka - obchodní případ

U běžných výrobních firem by měly být zakázky (rozumí se vyřizování objednávek na existující produkty včetně jejich přizpůsobení potřebám zákazníka - např. privátní značky či cokoli podobného) spravovány na základě striktních pravidel - procesů. Správa (data, případně koordinace činností) musí být podporována základním podnikovým informačním systémem.

Zakázky mají být řízeny procesně.

Firmy inženýrského charakteru (viz "Engineering") mají obchodní případy, které představují nový produkt. Možná to není nový produkt dle té či oné definice, ale jedná se o unikátní výstup (u kterého nemá smysl snažit se procesně pokrýt odchylky od obvyklého/obdobného řešení; výchozí šablony jsou jiné téma). Zakázka vyžaduje spolupráci účastníků z více částí firmy (obchod, projekce, výroba, nákup), popř. i více externích partnerů ve všech fázích životního cyklu zakázky podle konkrétních podmínek.

Typicky jsou to aktivity většího významu a rozsahu - dovést příležitost k realizaci a předání představuje více desítek či stovek člověkodnů práce (bez technické realizace). Trvá to třeba i déle než rok. Úspěšnost je v jednotkách procent. Obvykle máme náročného zákazníka. Může být hodně náročný, protože má hodně peněz (např. stát či jiný kanál, kterým tečou veřejné prostředky nebo opravdu úspěšná firma, která ví, co potřebuje a ví, jakou to pro ni má hodnotu... popř. si uvědomuje, jakou hodnotu má čas).

Náročný zákazník a jeho produkt

Náročnost se může projevovat různými způsoby.

• Někteří zákazníci se budou chtít zbavit veškeré zodpovědnosti. Může to být výhoda (není účelné se tím zde zabývat).
• Někteří budou porušovat pravidla dobrého chování a budou chaoticky měnit požadavky. Má to dva aspekty - dobrá smlouva/podmínky by měly zajistit, že to bude minimálně ekonomicky výhodné, a/nebo toho využít (ve smyslu neakceptovatelné nestability) a dle smluvních podmínek převzít zodpovědnost i za formulaci a upřesňování požadavků (což je samostatné téma, konkrétně správa požadavků - na produkt, zde zakázku - bude řešena velmi důkladně).
• Nejčastěji tlakem na termíny.

Vždy bude dobré mít veškeré aktivity velmi dobře zdokumentované. Dobře plánované. Neztrácet čas hledáním. Hlídat si termíny.

Takovéto zakázky mají charakter projektu.

Jsou ze své podstaty velmi obtížně řiditelné a obvykle spojují problematiku více různých i samostatně značně náročných oblastí. Samozřejmě je potřeba se k zakázkám projektového charakteru chovat jinak, než ke komplexním rozvojovým projektům (zejména zde nedává smysl hrát si na formality typu "sponzor" a obdobné). V tomto smyslu se budou celkem výrazně lišit i od faktického vývoje nového produktu.

• Správu/řízení portfolia zakázek. Protože tyto zakázky je nutno řídit projektově, znamená to integraci s interními projekty a prakticky nevyhutelně využití projektové kanceláře, protože je nutno řídit využití kapacit napříč procesními (rutinními) činnostmi i projektovým portfoliem (klidně se může jmenovat "zakázková/produktová kancelář" nebo prostě dispečink).
• Řízení životního cyklu zakázky/produktu (pokud připouštíme, že se jedná o produkt, byť výhradní). Sice nebude potřeba zajistit jeho uvedení na trh, ale spolupráce s náročným zákazníkem může být stejnou nebo i větší výzvou. A je potřeba vědět, jak na to (viz dříve zmíněné šablony).

Budeme potřebovat i podporu aktivit obchodního charakteru, správy a rozvoje firemní knowledge-base a nejspíš spoustu dalších. Bude se nám hodit flexibilní tvorba a aktualizace šablon dle typu zakázky.

Co potřebujeme pro správu zakázek?

Pochopitelně záleží na konkrétních podmínkách (obsahu dodávek atd.). Základ bude téměř všude obdobný.

• Prostředí umožňující plnit podmínky (smlouva) spolupráce a formalizovaný způsob uchování a zpracování informací, týkajících se dané zakázky (dohledatelnost / doložitelnost, průkaznost, jednoznačnost, trasovatelnost).
  Např. je dobré si umět představit, že daný obchodní případ může mít "svoji" adresu elektronické pošty a lze nastavit poštovní server a klienty tak, aby veškerá komunikace, která přijde od kontaktních osob daného případu (či bude jinak rozlišena), skončí ve sdílené schránce vyhrazené tomuto obchodnímu případu (týmu), totéž při odesílání zpráv. Rozhodně je však potřeba zajistit, aby veškeré informace (zde zprávy) týkající se zakázky, byly na jednom místě. Povinností musí být shodným způsobem zaznamenat a uložit i neformální či prvotní obsah telefonických, osobních a obdobných forem jednání. Přičemž platí, že veškeré informace obsažené v těchto prvotních záznamech musí být zapracovány tam, kam patří - do specifikací, plánu práce či jinam. Ke zprávám a záznamům by se nemělo být potřeba vracet.
  Tady je zřetelně potřeba jasná koncepce (pravidla/povinnosti) komunikace.
• Úložiště pro zakázkovou dokumentaci (tím se zdaleka nemyslí jen výkresová). Prostor s potřebnými možnostmi pro uložení všech ostatní digitálních součástí zakázky (zejména výkresy).
• Komunikační prostředky podporující (žádoucí) informovanost účastníků, organizaci schůzek, sjednávání úprav specifikací a plánu práce, zadávání a sledování plnění úkolů, snadné sdílení informací či předávání & zpracování podnětů atd.
• S tím souvisí správa zakázkových specifikací (a zjištěných omezení). Pravděpodobně celý systém pro podporu předání hotového díla by měl být nedílnou součástí (vytváření a ukládání akceptačních protokolů atd.).
• Možná něco obvykle označovaného jako "tikety" (zjednodušeně trasovat všechny události/potřeby zakázky a řídit adekvátní reakce). Takový mechanismus bude logicky sdílený se všemi ostatními projekty všech typů, možná i s provozními (procesními) činnostmi. Pro speciální potřeby musí být definován způsob, jak požadavek nasměrovat ke správnému zdroji (klidně externímu).
• Nebo bude potřeba vymyslet systém, pomocí kterého půjde snadno (v podstatě jako jeden) řídit několik zakázek (u menších firem třeba všechny). Umožnit střídání lidí v týmech včetně vedení zakázky.
• Pokud platí výše uvedené (projektové řízení a alokace kapacit), tak je zjevně klíčovou součástí prostředí jednotná správa zdrojů (kapacit) včetně vykazování práce (nástroj pro podporu řízení projektu). Je asi rozumné začít bez úporné snahy koordinovat práci napříč zakázkovým portfoliem, ale z logiky věci se to v jistém okamžiku stane primárním omezením a bude nutno to řešit.
  To prakticky znamená přistoupit na principy správy projektového portfolia, projektovou (popř. zakázkovou či produktovou) kancelář (rozumí se centrální koordinace informací a zdrojů sdílených napříč portfoliem).
• Bezpochyby bude potřeba systém pro monitorování, popř. kontroly stavu a postupu. Souběžně s vyhodnocováním výkonu či další analýzou (reporting). Data, která k tomu budete používat, musí být jednotně zpracovatelná.

Ono toho bude nejspíš mnohem víc. Je však dobré začít s minimálními ambicemi. Méně je vždy více. Pokud vidíte jinou důležitou oblast, která vám dělá potíže při správě zakázek toho či onoho typu, ozvěte se. Je nutno si udělat jasno, co doopravdy (právě teď) potřebujete a kam to má směřovat - jestli se dá najít vyhovující způsob řešení, popř. po důsledné analýze požadavku zjistit, že podstata potřeby je jiná a lze použít radikálně odlišný postup.

Pro začátek obvykle stačí správně používat standardní funkčnost.

Pozor - ke správnému používání standardní funkčnosti se nedostanete tím, že necháte své spolupracovníky (a sebe) vyškolit v tom, co považuje za "standardní funkčnost" člověk, který nezná průběh vašich zakázek. Také proto, že se ho nebudete umět zeptat "...a jak mám udělat, aby...", protože vůbec nebudete tušit, že něco takového chcete dělat. Doporučený způsob rozvoje dovedností je "Learning by doing".

Postup využití MS Teams u obchodních případů

Pracovní prostředí představované týmem v MS Teams je určeno pro jednorázové aktivity. Proto  záměr použít tým pro zakázu nevypadá příliš důvěryhodně. Naprostou katastrofu představuje snaha "propojit" všechny lidí pracujících na všech zakázkách s vizí, že daný tým bude existovat navěky. Jenže pokud je zakázka (konkrétní druh) projekt, mohl být tým MS Teams elegantně poskytout potřebné pracovní prostředí. Jeden z prvních kroků, které budete muset udělat, bude pojmenovat a ujastnit činnosti, které tu děláte - detailně a důkladně... namátkově např.:

• Připravit jednání s potenciálním zákazníkem (pokud to není kryto funkčností sytému na podporu akvizice nebo řízení vztahů).
• Získat chybějící podklady pro přípravu nabídky.
• Rozdělit práci/úkoly pro vytvoření nabídky.
• Připomínkovat nabídku / součást.
• Získat informace o konkurenčních aktivitách.
• Vypořádat připomínku.
• Připravit předání nabídky (dle typu včetně řady dílčích činností jako je zorganizovat cestu & ubytování, zajistit techniku, odladit prezentaci, ...)
• ...

Nemyslete - může jich být hodně desítek nebo stovky. Všechny stojí zato pojmenovat. Všechny musí být nebo mít možnost dostat se do plánu práce. Víte, jak na to?

Potom musíme úplně stejně důkladně a důsledně identifikovat veškeré myslitelné artefakty související se zakázkou - i když budou hmotné, musí mít digitální "otisk". Primárně jde ovšem o typologii dokumentů a ostatních záznamů. Budeme muset promyslet, nakolik ne/důslední můžeme/musíme být v uplatnění projektového řízení.

• Zvážit, kam mají být které typy dokumentů umísťovány.
• Jak rozsáhlé sdílení se zákazníkem/subdodavateli bude potřeba / je možné.
• Pokud je konání následných činností závislé na reakci zákazníka, bude to chtít vyladit pravidla pro mobilizaci zdrojů (hibernaci a aktivaci instancí aktivit).
• Pro jaké účely/činnosti (popř. typy zakázek) využívat jakou funkčnost.
• Pokud je prostředkem komunikace převážně elektronická pošta, bude to chtít najít rozumná opatření (viz výše, popř. samostatně).

Podle toho se vytvoří a průběžně zdokonalují šablony pro MS Teams. Šablona může obsahovat jak prázdné, tak předvyplněné objekty. Také do ní mohou a mají být vložena rozhraní k celopodnikovým úložištím a nástrojům (KB, FAQ, rozhraní na provozní mechanismy - např. informace o zákazníkovi, konkurenci, dodavatelích, monitoring informačních zdrojů & systém řízení rizik, data dřívějších zakázek tohoto typu apod.). Vytvoření týmu pro novou příležitost a spousta dalších úkonů se dá hodně elegantně zautomatizovat. Včetně průběžného doplňování užitečných součástí. 

Podstatné je, že všechny klíčové evidence (specifikace a plán práce) jsou plánovány a evidovány v jednotném prostředí, takže pro jejich sledování a hodnocení lze použít jednotný celopodnikový mechanismus.

Kritické požadavky

Co potřebujeme a co očekáváme (u vás to může být něco jiného).

• Plánovat a sledovat práci týmů / lidí na zakázkách (i dalších aktivitách). Mít přehled o využití kapacit a postupu práce (signální mechanismy).
  Jedná se převážně o podporu projektového řízení.
• Jediný závazný seznam úkolů. Pokud možno na principech MBO a co nejsnáze použitelný - jak pro zadavale, tak pro realizátory.
  Tady je sporné, nakolik budeme mít odvahu si přiznat, že potřebujeme jediný a poměrně sofistikovaný systém správy úkolů nad celým projektovým - produktovým - zakázkovým portfoliem a i pro veškeré ostatní mimořádné úkoly; tedy celofiremní.
• Podporu pro hlídání termínů a postupů (flexibilní/parametrické workflow).
• Usnadnit lidem ukládání / přístup k veškerým informacím, podkladům a dokumentům zakázky. Závazné úložiště s řízeným přístupem, metadata která umožní automatizovat řízení životního cyklu dokumentů / položek. Na základě striktní typologie (jaké typy záznamů a dokumentů musí mít jaké vlastnosti, případně včetně stuktury sad dokumentů aj.).

Platí totéž. Není účelné vymýšlet hodinky s vodotryskem. Je velmi rozumné se omezit na naprosto nezbytné potřeby a postupně systém zdokonalovat a rozšiřovat.