MS Teams - organizace týmů a kanálů

Bylo nebylo…

V jedné firmě (nebojte, není to o vás) se rozhodli, že:

• Budou pro komunikaci používat MS Teams. Buď se do toho pustili sami (nebo možná s někým, kdo především potřeboval prodávat předplatné Office/MS 365).
• Vytvořili týmy. Nijak moc promyšleně - spíš tak, jak to fungovalo dosud.
• K zakázkám a jiným aktivitám, na kterých začínaly jednotlivé týmy pracovat, vytvářeli v rámci týmů kanály.

To není dobrý nápad.

Týmy & Teams × organizační struktura

Výše uvedený scénář je (pro rozumnou organizaci) sporný. Jenom ve stručnosti jak a proč by účelné nasazení Teams mohlo vypadat:

• Týmy v Teams nemají být používány na základě statické organizační struktury.
  • Bohužel v návodu na používání není dost zdůrazněno, že týmy, které kopírují útvary (funkční organizační strukturu) jsou sice možné, ale pro racionální organizaci spolupráce fakticky nepoužitelné (můžete vytvořit "útvarové týmy", ty využívejte pouze pro organizaci týmových volnočasových či obdobných aktivit celého útvaru).
  • Ve výše uvedeném návodu se praví:
    • A team is a group of people gathered to get something big done in your organization.
    • Teams are made up of channels, which are the conversations you have with your teammates.
    • A následně "Each channel is dedicated to a specific topic, department, or project.", což (ty přeškrtnuté dvě možnosti) je v rozporu s dříve uvedeným (autor chce pokrýt všechny možnosti užití). Pro účelné použití "kanálů" je dobré jim dát jednotný význam - jediné dílčí téma. Je dobré mít konvence - zjednodušují nám život. 
      Detailně & důkladně dále a jinde.
  • Pro práci musí vzniknout nezávislé "pracovní týmy", složené z lidí (interních i externích), kteří se na dané práci skutečně účastní.
• Pro aktivitu vzniká tým. Tým existuje jen po dobu trvání aktivity. Může se v průběhu měnit (členy přidávat či nahrazovat). Po skončení akce tým zanikne.
  Když to takto od začátku vnímáte, je jasné, kam patří jaké informace.
• V běžné firmě by týmy mohly (pokud se Teams ukáží jako nejlepší možnost) odpovídat (velkým) zakázkám (nebo obdobným akcím, které mají charakter projektů).
  Pro běžné zakázky nic takového nemá smysl (je nutné je řídit provozními prostředky, procesně - s daty v provozních systémech atd.).

Je potřeba si všechno důkladně vyzkoušet. Když k tomu nemáte dost času nebo zkušeností, je výhodné si k vytvoření koncepce nasazení nového nástroje přizvat někoho, kdo potřebné znalosti a zkušenosti má.

Pro sdílení vhodné nástroje - wiki, knihovnu dokumentů, ... 

Všechno další je nutné nastavit dle konkrétních podmínek. Se znalostí možností a omezení - např. většina dokumentů patří (minimálně cílově) do celofiremních knihoven dokumentů. Stačí je vybavit potřebnými metadaty. Chce to se nad skutečnými potřebami zamyslet (např. jako v případě implementace ERP nebo čehokoli jiného).

Nová doba přináší nové potřeby a požadavky. Proto přicházejí nové nástroje. Neměli bychom nové technologie nutit podporovat "součinnost" z dob dávno minulých. Spousta dřívějších zkušeností a osvědčených postupů se v novém prostředí neuplatní.

Minulost × budoucnost

V oné firmě došlo k obvyklému - ne zcela vhodnému - přesunu.

• Co se dříve dělalo špatně pomocí mailu, začalo se ještě hůř dělat v chatu Teams. Bez koncepce, pravidel, neřízeně. Bez procesů. 
• Do komunikace v rámci kanálů se uváděly věcné (obsahové) informace, požadavky a úkoly. A zůstávaly jen tam, nikdo je nepřenesl do zakázkové dokumentace.
• Jenže chat (kanály) jsou určeny (má smysl používat) pouze pro určené typy interakcí. Nepatří tam závazné hodnoty, závěry diskuse, upřesňování zadání, natož úkoly a změny požadavků.
• Odkaz na schůzku. Případně s průvodní informací, čemu je potřeba věnovat zvýšenou pozornost (z programu, přičemž je to uvedeno i u toho bodu programu).
• Odkaz na dokument. Případně s upozorněním, kdy vyprší termín (uvedený v dokumentu). Nebo odkaz na cokoli dalšího. V naznačeném režimu.
• Pokud k tomu není vhodný jiný lepší nástroj, je možné otevřít v rámci týmu diskusi - k tématu, které je obsaženo v některém odkázaném dokumentu (či něčem podobném). Do dokumentu potom přenést jen závěry.

Nastavit pravidla komunikace tak, aby se kanál (popř. tým) dal víceméně bezprostředně po skončení práce odstranit. Nemá existovat důvod, aby nadále existovat. Počítat s tím, že všechno (co je uloženo na úrovni týmu) zmizí.

Někde si dokonce předávají v chatu přílohy…
Zkrátka proto, že jsou tak zvyklí. Protože to jde.

Když akce (zakázka/projekt) skončila, objevila se potřeba obsah těch kanálů někam uložit. Jelikož některé důležité informace (odsouhlasení diskutovaných změn v obsahu plnění/podobě spolupráce) nikde jinde nebyly. A bylo potřeba zpětně (řadu měsíců po ukončení práce) dohledat, proč se to či ono dělalo tak, jak se to dělalo. Jenže vzhledem k určení kanálů není standardně podporovano uložení obsahu chatu. Situace přímo křičí, jak se to mělo dělat lépe:

• Vyzkoušet, co a jak se dá a má dělat.
• Nastavit pravidla a pokud možno omezit nežádoucí praktiky.
• Všechno ověřit a přitom popsat & zaškolit + následně podporovat uživatele.
  Nikoli jednorázově - trvale. Lidi, systém i prostředí je nutné stále rozvíjet. 

Je nešťastné řídit se zvyklostmi komunikace založené na (nevhodném způsobu) používání elektronické pošty, jednodušších komunikátorů či jiných platforem pro spolupráci. Každý nástroj má specifika a omezení. Naše zvyklosti z dob před digitální revolucí jsou také většinou zavádějící. Pro novou technologii se vyplatí investovat přiměřené úsilí do jejího poznání a nalezení optimálního způsobu jejího nasazení.

Kam co patří

Příklady (jen nejobvyklejší typy obsahu).

• Vstupy
  Podklady, které mají být využity (texty, data, obrázky aj.). To by mělo být samostatné úložiště, které patří k danému projektu/týmu. Může to být vyhrazená knihovna dokumentů, kterou lze nasdílet i externím uživatelům pro vkládání dat.
• Výstupy
  Pokud v průběhu či na konci práce má být zdokumentován výsledek nebo výsledkem je digitální obsah, téměř jistě patří někam, kde se s nímu bude dále pracovat. Tedy to nemůže být interní knihovna týmu. To lze řešit tak, že si příslušné úložiště (obvykle knihovnu SharePoint-u) připojíte do nástrojů týmu/kanálu. 
• Data
  Může se stát, že součástí práce týmu jsou data, ke kterým potřebujete zajistit přístup např. na souborové úrovni (např. výsledky dotazníků, které chcete zpracovávat nezávislou aplikací). Můžete synchronizovat a zpřístupnit knihovnu dokumentů týmu, ale to je zjevně v rozporu s jednoduchostí přístupu a trvanlivostí příslušných souborů. Řešení je stejné - použijete či vytvoříte knihovnu dokumentů na SharePoint-u (rozumí se mimo tým; popř. složku v již připojené) a přidáte jako další nástroj.
• Změny požadavků či parametrů
  Dají se (a bylo by to vhodnější) vypořádat přímo ve správě podnětů/požadavků (specializovaný nástroj). Ale může existovat důvod, proč jsou např. v dokumentu textového či tabulkového procesoru (požadavek zákazníka). Proto může být stanoveno, že se pro každý takový podnět vytvoří kanál. Změna může být iniciována zprávou (chat, mail či telefon - relevantní obsah se umístí do chatu kanálu a tím se zpřístupni ostatním členům týmu). Případná diskuse by měla obsahovat identifikaci souvislostí (případě překážek a způsobů řešení) a závěr - jakým způsobe bude podnět/požadavek vypořádán. Závěry (a případné vázané informace) musí být přeneseny do příslušného dokumentu (požadavky na výstup, specifikace plnění, akceptační protokol apod.).
  Pokud žádný takový dokument neexistuje, je dobré (nutné) jej založit.
  Sdílet (zejména se zákazníkem) a průběžně informovat o provedených změnách.

Vyplatí se to.

Co je to komunikace

Klíčová otázka. Co má být komunikačním nástrojem podporováno. Proč jej vlastně potřebujeme.

• Komunikace = výměna sdělení (viz wikipedie - jen pro zajímavost). V širším pojetí se dá chápat jako technická podoba výměny informací. Která je pro součinnost lidí a koordinaci jejich úsilí prostě nutná.
• V podnikové praxi podpora týmové spolupráce. K tomu jsou MS Teams určeny.
• Žádný nástroj nemůže podporovat všechny myslitelné typy používání. Každý systém využívá specifické datové struktury, odpovídající určitému pojetí (zde klíčovým principům obvyklé podoby spolupráce v organizacích). Pro jeho rozumné využití je potřeba respektovat principy, podle kterých byl vytvořen.
• Podpora spolupráce znamená (asynchronní zprávy + interaktivní prvky):
  • Sdílení podkladů a zajištění přístupu k nim pokud možno dle rolí.
  • Koordinaci činností všeho typu. Podporu řízení pomocí úkolů.
  • Integraci aplikací typu průzkumy apod. Sběr požadavků a správu podnětů.
  • Velkou výhodou je úzké propojení na další nástroje (ať už podpora organizace schůzek či prostředky pro interaktivní spolupráci).

Příklad - poradenská spolupráce

Konkrétní (nejjednodušší) příklad - spolupráce (v primitivní podobě) zákazníka a poradenské firmy na rozvojovém projektu u zákazníka - např. převodu péče o vztahy se zákazníky (z terénních obchodníků) na obchodní administrativu a související tvorbě (revizi) systému řízení výroby. Ptáme se, s jakými informacemi takový projekt pracuje a jak se pro jeho potřebu využijí komunikační prostředky. Při použití MS Teams:

• Nesporné potřeby / požadavky.
  • Administrátor (kde jsou k tomu lepší podmínky, měl by být u zákazníka, pokud by byl u dodavatele, pouze provizorně) vytvoří nový tým s vhodným jménem (Restrukturalizace 2020). A udělá vše, co je pro fungování takového týmu nutné (detaily v metodice).
  • Na výstupu projektu má být:
    • Procesní model obchodu  a výroby.
    • Kalkulační vzorec (nástroj & metodika).
    • Jednoznačná pravidla pro tvorbu nabídek včetně cenotvorby, řízení spolupráce se subdodavateli a zadávání výrobních zakázek.
  • V průběhu jsou používány tyto typy komunikace (jen základní):
    • Notifikace - kde je k dispozici/zpřístupněn nový či byl změněn obsah.
    • Obsah - dokumenty, kalendář / plán práce, databáze/systém správy úkolů, metodika a směrnice (pravidla fungování tohoto konkrétního projektu) formou hypertextového systému založeného na wikiknihovně.
    • Data v provozních informačních systémech (zprostředkovaná pomocí transformace/výběru pokud je to možné nebo pseudorozhraním, na kterém je popsán způsob použití těch informačních systémů a případně způsob protokolování získaných informací).
• Příklad reakce na vznik neplánovaného obsahu: V průběhu akce došlo k tomu, že proběhl průzkum spokojenosti a potřeb stávajících zákazníků.
  • Tento dílčí záměr vznikl spontánně (nebyl v plánu prací). Nedůsledností (nadšením) realizačního týmu ani nebyl do plánu prací zařazen. Tedy k jeho provedení nevznikla žádná pravidla.
    Je to přijatelná situace?
    I kdyby to byla nezpochybnitelně jednorázová účelová záležitost?
    Pokud ne, existuje jiné rozumné řešení, než to napravit?
  • Metodika a dotazník (skript) vznikly ad hoc nekorektně v prostředí projektu/týmu. Následně se zde začaly také zpracovávat výsledky této aktivity (sice v samostatném kanálu, ale ani tak to není v pořádku). Sice je takový scénář pro pilotní aktivitu myslitelný, je ovšem nutné mít jasnou představu, co se s daty a nástroji bude dít dál. 
  • Primárně se musel doplnit plán+výkaz práce. Vytvořit (základ) závazná metodika pro provádění takového průzkumu. V jejím rámci upřesnit používání nástrojů a způsob uložení získaných dat pro běžnou provozní potřebu.
    Tohle rozhodně jednorázová záležitost nebyla - takový průzkum (byť dotyčná firma předtím nic takového nedělala) je standardní součástí obchodu. Proto bylo žádoucí celý mechanismus přenést do běžného provozu.
• Každý tým i kanál musí mít svého správce ("vlastníka"). Ten zodpovídá za to, že jeho využívání bude v souladu s pravidly a když se objeví cokoli, s čím pravidla nepočítají, tak si zajistí jejich aktualizaci.

K čemu jsou Teams vhodné

Teams jsou postaveny na SharePoint-u & Exchange. Máme k dispozici plnohodnotnou infrastrukturu, se kterou není potřeba hledat provizoria a kompromisy. Základem rozumného využití je ovšem dobrá klasifikace informací (interakcí, aktivit atd.), které mají být v systému podporovány. Musí být stanovena závazná pravidla používání. Vždy s ohledem na potřebu či nutnost uchování obsahu po dobu práce nebo i déle.

Pokud je něco potřeba uchovávat, nesmí to zůstat jako obsah chatu.

Když potřebujete zjistit, co platí (domluva, pravidla, parametry, postupy, termíny, ... cokoliv), nemáte to hledat ani v hromadě elektronické pošty, ani v ještě větší hromadě zpráv chatu/kanálu (v extrémním případě několika desítek různých kanálů různých týmů). To nedává smysl. Informace, které mají širší či delší (či nejasnou) platnost, musí být uchovávány odpovídající formou (dokumenty, wiki apod. v podobě analýz, metodik apod.) na odpovídající úrovni (místě). Zejména pokud k nim má být umožněn přístup i odjinud.

Je rozumné:

• Zajistit, že skupiny, kanály, knihovny a všechny další typy obsahu vznikají velmi striktně řízeně a podle dohodnutých pravidel (uživatelé si nemohou vytvářet skupiny dle vlastního uvážení - zajistit v nastavení/politikách).
• Zakázat přílohy - dokumenty patří do knihoven (ať už týmu nebo jinde). Tím se celkem vyjasní, k čemu jsou určeny zprávy. Když se zpráva týká konkrétního dokumentu nebo jiného objektu či skupiny, je jednoduché do zprávy vložit odkaz na příslušný objekt (je smutné, že to nikde v nastaveních nelze technicky zablokovat).
• Dokumenty nesmí existovat jinde, než v přiřazeném úložišti.
• Úkoly se zadávají, sledují a hodnotí prostřednictvím určeného dílčího nástroje (Planner apod.).
• Požadavky jsou spravovány odpovídajícím způsobem (knihovna záležitostí). Opět záleží na tom, jestli a jak je potřeba & jednoduché či složité je uchovat tato data i po skončení práce (zániku týmu).
• Předávací / akceptační protokoly jsou nezávislé ve vhodném prostředí (knihovna dokumentace - výstupy).
• Do mailů a chatu patří ty informace, které mají pouze dočasnou platnost (představte si to tak, že jakmile danou zprávu akceptuje poslední příjemce, zanikne, protože se k ní již nikdo nikdy nemá vracet, popř. zanikne při svojí exspiraci bez ohledu na to, kdo všechno ji četl). K tomu je samozřejmě potřeba říci, jak mají být předávány všechny ostatní informace.
  • Odkaz na schůzku je jasný - ukončením schůzky ztrácí platnost a měl by z historie zpráv zmizet. Pokud to nejde automaticky, měla by to být povinnost organizátora schůzky.
  • Program či podklady schůzky musí být u dané schůzky (formou odkazů). Upozornění na změnu obsahu podkladů patří mezi zprávy a mělo by být navázáno na oznámení schůzky - tohle může být inspirace pro to, jak smysluplně využívat kanály (všimněte si, že schůzky jsou implicitně vztahovány ke kanálu; je tím myšleno samostatný kanál pro každou schůzku / téma).
• Kanál by měl být využíván pro výměnu zpráv týkajících se jednoho tématu. Např. vznikne nejasnost nebo problém. Pro diskusi nad danou otázkou je vhodné založit kanál, který se po ukončení diskuse odstraní. Výsledky diskuse je nutno zaznamenat tam, kam patří.
• Připomínkování
  Může se stát, že v rámci výměny zpráv (v kanálu = otázky a odpovědi) se účastníci na něčem domluví - např. na tom, že se něco má dělat konkrétním způsobem (např. jak má vypadat nabídka, na co je potřeba dávat pozor, popř. jakým způsobem se mají předávat konkrétní informace či cokoli podobného).
  • Takovou dohodu (její obsah/výsledek) je potřeba zapracovat jako aktualizaci do příslušné metodiky či dokumentu, úpravy si nechat schválit a původní zprávy nejlépe z původního kanálu odstranit.
  • Aktualizace sama může být kanál a případný text původního podnětu a navazující výměny názorů, pokud je to účelné, může být zkopírován (nikoli odkázán, protože tam tu informaci chceme uložit trvale) do zadání úkolu nebo přímo do akualizovaného dokumentu.
  • Veškerá následná komunikace má být vedena a zpracována závazným způsobem (dle pravidel pro připomínkování obsahu).
• Využíváte třeba průzkumy (ty samy existují nezávisle, a máte chuť sdílet analýzu výsledků nebo koordinovat součinnost na přípravě - zase se hodí kanál, který s definitivním uzavřením práce na anketě také zanikne - všechny věcné informace které ať už z tvorby nebo rozboru vznkají, patří do průvodní dokumentace průzkumu - mimo jiné proto, že daný záznam máme vybavit více atributy (kategoriemi, značkami, vazbami na jiné aktivity/průzkumy atd.), přes které dává smysl je zpřístupňovat. A umístit jej tam, kam patří - možná neplatí jinde, než v rámci projektu (týmu), ale většinou má širší vazby, proto má skončit v některé celopodnikové knihovně dokumentů.

Stačí vědět, jak se připojují do týmu/kanálu další nástroje.

Kdy je užití týmů a kanálů sporné

Jednoduchý scénář - IT outsourcer by chtěl používat Teams pro komunikaci při poskytování podpory klientům. Vypadá to elegantně a jednoduše. Jenže co je podstatou poskytování podpory (bez ohledu na to, jak tomu říkáme)?

• Plánování péče/rozvoje (běžná profylaxe, analýza provozu, školení, ...). Některé tyto aktivity se týkají uživatelů u klienta, některé ne. Na ty společné je potřeba zorganizovat termín. Většinou je nutný alespoň jednoduchý záznam výsledků.
• Možná je dobré vyčlenit samostatně "metodickou podporu".
  Tady by se dalo o využití Teams uvažovat. Často se objeví dotaz nebo se zjistí nekorektní způsob používání IT, popř. dojde ke změně nastavení a tedy i postupu, jak lidé mají např. aktualizovat dokument.
  • O tématu lze diskutovat (viz výše připomínkování)
  • Závazná verze toho, jak se to má dělat či co je potřeba dodržovat, musí být nesporná. Tedy velmi přesně formulována v metodice, aby mohla být provázána na ostatní pravidla. 
  • Po diskusi následuje závazná formulace, publikace a notifikace dotčených uživatelů. Ale zjevně je lepší integrovat komunikační rozhraní do standardního nástroje (viz dále), mimo jiné proto, že ne všichni klienti budou ochotni používat Teams. 
• Obvykle je nosná funkčnost nástroje pro zefektivnění poskytování podpory (nejen v IT) něco jako helpdesk - správa incidentů. Pokud je uzavřena SLA, existují definované typy incidentů a reakční doby. O zásazích je nutné vést poměrně přesnou evidenci. I ty ostatní činnosti je potřeba vykazovat - což by měl zajišťovat jediný systém.
• Bylo by velmi nešťastné používat Teams pro dotazy v rámci podpory či požadavky.

Optimální řešení závisí na konkrétních podmínkách. Lze odhadnout, že pro poskytování podpory Teams kryjí 20-40% potřebné funkčnosti. Zbývající potřeby by se řešily obtížně a neefektivně. Navíc typicky funkčnost helpdesku by měla zajistit, že se incidentu bude věnovat co nejdřív první volný technik (což komplikuje týmy pro jednotlivé klienty). Pro poskytování podpory je vhodný nástroj typu extranet, který lze velmi efektivně vytvořit (včetně případné jednoduché funkčnosti typu helpdesk) např. pomocí SharePoint-u.

Co potřebujete uchovat

Předpokládejme, že jste se rozhodli využít Teams pro spolupráci při realizaci velkého obchodního případu - ať už pouze interně nebo se zapojením externích partnerů z obou stran - zákazníka & subdodavatelů. Dohodnete se, že veškerá dokumentace (informace) budou uchovávány = sdíleny pomocí Teams.

• Začínáme plánem práce. Kde má být a jak má vypadat?
  Případně pokud mají být vytvářeny - co výkazy práce? Hotové činnosti z plánu práce by měly být v něm. Takže žádný výkaz  práce nepotřebujete (získáte jej výpisem ukončených činností). Je to jediný správný způsob, protože je nezbytné udržovat plán práce platný. To lze pouze tak, že veškeré provedené činnosti do něj zaznamenáváte (tak, jak skutečně proběhly) a současně aktualizujete budoucí část plánu práce. 
  • Odpovídá tomu kanál "Plán práce" nebo pokud je to extrémně rozsáhlý projekt, lze jej členit na etapy a potom je potřeba mít nástroj, který umožňuje plánování a vykazování práce etap v rámci nadřazeného plánu.
  • Funguje tak dlouho, dokud není práce (projekt, etapa) skončena. Kanál obsahuje pouze upozornění na změny plánu prací - ideálně s odkazem na danou položku. Není přípustné, aby se v něm vyskytovala sdělení s delší platností - veškeré takové informace musí existovat nezávisle na něm.
  • Vlastní plán práce je Planner, Work progress tracker nebo odpovídající typ obsahu SharePoint-u.
    
• Veškeré informace vztahující se k organizaci práce na projektu (které nejsou plánem práce = metodika & postupy, analýzy, akceptační kritéria apod.). patří do metodiky řízení/organizace akce. Bezpochyby bude existovat nějaká základní verze. Můžeme se na ni odkázat (pokud je fixně platná a neměnná) nebo ji převzít a následně upravovat. Má být umístěna v snadno odkazovatelné a propojitelné hierarchické struktuře - ideálně vyhovuje wikiknihovna (nativní součást Teams). Ve zprávách se objeví jen velmi dočasně platná upozornění na provedené aktualizace apod.

Zkrátka všechno, co potřebujete uchovat, musí existovat v podobě dokumentů nebo obdobných záznamů. Nedává smysl stavět jakoukoli dohodu na informacích, roztroušených v mailech nebo zprávách skupiny (kanálu). 

Správné řešení

Sice je teoretická možnost vytvořit konektor, který by s příspěvky kanálu něco dělal, ale příliš to nedává smysl. Jaké je korektní řešení?

• Zvážit, jestli je „komunikace“ přes kanály týmů žádoucí scénář.
• Pokud to tak má být, je potřeba domyslet, jak určené (?) typy zpráv uložit do určeného úložiště (popř. získat nástroj, který to bude podporovat). Velmi drahé, nejisté, nepodporované (např. je prakticky nemožné zavést klasifikaci zpráv).
• Protože rozhodně nemá smyslu ukládat všechno.
• Jenže jak definovat, co se má ukládat?
• Co přesně vede k tomu, že v příspěvcích kanálu máme něco, co bychom chtěli uchovat?
• Co z toho je vlastně potřeba mít "uložené", proč a na jak dlouho?
• Bude obtížné zdůvodnit, proč mají být v příspěvcích kanálů/skupiny informace, které je potřeba uchovat (z jakých důvodů), jinak bychom vynakládali úsilí na podporu nekorektního řešení (což by téměř jistě nemohlo dopadnout dobře).
• Používejme kanály k tomu, k čemu jsou určeny (viz výše "conversation").
• Jenom pro výzvy, oznámení, upozornění - prostě pro obsah, který nemá trvalou platnost.
• Obsah (objekty s informacemi, které mají delší než bezprostřední platnost) ukládat tam, kam patří (dokumenty, poznámky atd.). To samozřejmě vyžaduje promyslet a korektně nastavit pravidla. Klasifikovat typy záznamů a určit jim odpovídající prostředky.
• Pokud víme, že zprávy z chatu nelze (ani to nedává smysl) nijak extrahovat a uložit, tak do chatu prostě nic takového, co by bylo potřeba uložit, nesmíme dávat. Uložit obsah tam, kam patří a do kanálu uvést odkaz. Jak to dělají Teams v případě systémových změn.
• Co udělat s těmi stávajícími? Využít pro zmapování typů obsahu a specifikaci skutečných potřeb.
• Ručně je projít a při té příležitosti upřesňovat organizaci dat.
• Převést informace s delší platností do žádoucí podoby (úložišť).
• Přitom formulovat pravidla a ověřovat postupy.

Aneb rozumný postup je přiznat si, že by se to mělo dělat jinak, než dosud. Přejít na nový způsob. Všechny rozumné typy obsahu (dokumenty, wiki atd.) lze zálohovat, synchronizovat a používat naprosto běžným způsobem (otevřít týmový web přes SharePoint a najít např. přes Site Contents to, co nás zajímá).  

Čím dříve, tím lépe.

Přečtěte si pokračování Jak a k čemu používat MS Teams. Pokud jste v podobné situaci, rádi poskytneme konzultaci zdarma. Už dlouho nabízíme online poradnu a vývoj nadstaveb pro MS365.

Obsah článku je jenom předběžný - budeme se k němu vracet. Zejména pokud se ozve někdo, koho toto téma zajímá.