K čemu je dobrá Power Platform

Osvědčený způsob užití

Proces administrativního charakteru, který je v současné době realizován pomocí mailu a Excelu. Podstatou je workflow, často obsahuje správu a generování dokumentů. Není možné (bez vývoje rozšíření) jej v potřebném rozsahu / podobě podpořit žádným ze stávajících informačních systémů. Níže jsou uvedeny i příklady nevhodného nasazení. V obou případech se nejedná o žádné dogma.

Konkrétní příklady z praxe

• Podpora správy projektového portfolia.
  Dokonce i když použijete silné nástroje typu Project Online, tak bude účelné (nutné) rozšířit systém o automatizaci rutinních činností na úrovni projektové kanceláře (sběr dat / výzvy k aktivitě / identifikace změn aj.).
• Správa vyjádření (podání externího subjektu, na které je potřeba reagovat).
  Libovolným způsobem je doručena žádost, často obsahující dokumenty (např. včetně výkresové dokumentace). Tím vzniká případ, který se zpracovává za účasti různých rolí podle typu podání. Cílem je vypořádat dané podání - koordinovat účast povinných subjektů, hlídat termíny atd.
• Správa požadavků (obecně, popř. požadavků v duchu TOGAF).
• Řízení životního cyklu a obnovy majetku
  Pokud není k dispozici standardní řešení pro správu majetku s potřebnou funkčností. Byť vypořádání požadavku na obnovu či rozšíření využívaných zařízení (není tím myšlen drobný majetek) obvykle nebude podporován - a právě proto je dobré pro asset management hledat řešení, které má otevřené API. Jelikož přesně tato konstelace je ideálním příkladem nasazení Power Platform - 
• Samostatně nebo jako součást agenda řízení nákupu majetku a služeb (také ve vazbě na správu požadavků).
• Správa (např. tvorba a připomínkování) podnikových dokumentů.
• Jednoduchý procesní model
  Pokud není nic lepšího.
• Agendy typu ESG a obdobné (sběr a vykazování dat, která nemusí být součástí produkčních systémů). Sem bude patřit i funkčnost pro podporu systémů řízení jakosti, BOZP aj. (vše, co dnes obvykle poměrně provizorně vytváříte pomocí tabulkového procesoru, ve kterém se vyzná pouze člověk, který tu evidenci vytvořil.

Jednoduché náhrady Excel-u

Naprostá většina by mohla/měla být řešena standardní funkčností kancelářských aplikací nebo inteligentním využití možností standardních systémů (

• Schvalování (čehokoli) je už hotové - stačí se naučit používat. Je to i v Teams.
• Veškeré "žádanky" (dovolené, služební cesty a školení, drobný majetek, ...).
  Tady platí, že by bylo lepší, kdyby danou funkčnost podporoval odpovídající informační systém, typicky řešení pro personalistiku a/nebo mzdy. Pokud ne, je potřeba optimalizovat případné nezbytné předávání dat.
• Zjišťování účasti / zájmu (např. centralizace správy čerpání benefitů).
  Pokud není nic lepšího - v nejjednodušší podobě lze použít Forms. Příklad - omezený počet např. skipasů, které je potřeba si včas rezervovat. Případně se zaregistrovat jako náhradník, pokud to původní zájemce zruší. Popř. kdo se zúčastní akce a co preferuje na jídlo či které aktivity. Forms si o automatizaci vysloveně říkají.

Není to černobílé

Jedním z výrazně nedoporučených scénářů je vytvářet funkčnost, které již je k dispozici ve standardních systémech určených pro standardní agendy (např. účetnictví). Řízení výroby je bezpochyby také standardní agenda a existuje pro to spousta různých nástrojů. Přesto může dávat smysl vytvořit - pro specifické podmínky - řešení, které se také dá pojmenovat jako "řízení výroby" (na základě diskuse na LinkedIn o projektech; článek je v přípravě).

• Může se jednat o hodně jednoduchou podobu řízení kapacit.
• Nejsou potřeba náročné optimalizace.
• Ani integrace s řízení materiálového toku.

Na skutečné řízení (materiálové) výroby by vývoj řešení v takovémto prostředí byl příšerně náročný (neefektivní)

Podmínky

Data, která takové řešení bude využívat, lze relativně snadno získat z datových zdrojů organizace (tedy již existují v systémech, které mají API nebo v databázích, ke kterým je možno se připojit). Neměli bychom (až na výjimky) budovat samostatné izolované systémy s vlastní datovou základnou.

• Prostředí vyžaduje správu (celkem užitečný přehled, převedeme).
• Jednotlivé části řešení by měl zvládat vytvořit a udržovat jediný autor (nutno vysvětlit, patří do koncepce). I přesto musí být každý objekt zdokumentován a "řízen".
• Rozumná datová architektura napříč organizací a fungující MDM (Master Data Management).

Dle našich zkušeností je klíčovou podmínkou (nejen pokud vnímáme jako hlavní přínos platformy možnost relativně snadno vytvářet řešení založená na workflow) procesní přístup a pořádek v datech. Pravděpodobně to představuje větší či menší překryv se správou prostředí. 

Kontraindikace 

Není dobrý nápad:

• Vytvářet (komplexní, rozsáhlé, datově a uživatelsky intenzívní) systémy, které již existují ve standardní podobě (účetnictví, fakturace, mzdy a v nich integrované části personální agendy, ...).
• Nahrazovat funkčností neznalost uživatelů či nesmyslné nastavení procesů (nevyužívání standardní funkčnosti - sem patří multiplicitní evidence úkolů a termínů, které následně vytvářejí záplavu zpráv, kterým nikdo nevěnuje pozornost - např. termíny je nutno dostat do termínového kalendáře).
• Neřídit obsah a strukturu vytvářených řešení - nechat využití nástrojů živelný průběh. Nemá smysl snažit se předem vytvořit dokonalé prostředí (plánování, řízení, kontrola... správa/governance) - opravdu užitečné jsou robustní základy a průběžně s rozvojem využívání Power Platform rozvíjet dovednosti účastníků, potřebné procesy a jejich technologickou podporu.
• Absence pravidel / koncepce rozvoje. Živelný průběh...
• Nepřinutit "tvůrce":
• Seznámit se alespoň se základy pravidel pro vývoj (viz jindy/jinde). Či spíše respektovat veškerá pravidla...
  A umožnit jim (přinutit je) podílet se na jejich formulaci / upřesňování.
• Definovat a projednat (se správcem) každý záměr & ověřit, zda zamýšlená funkčnost již neexistuje. Následně zařadit do katalogu či podnětů (podle způsobu organizace správy požadavků).
• Dokumentovat, co vytvoří (resp. co chtějí vytvořit, vytvářejí, ... a rozvíjejí).
• Nechat nadšence, aby si sami pro sebe hráli s funčností, která se zdá užiteční (pouze) jim.
• ...

Platformy využívající výhod prostředí podporujícího spolupráci systémů (především správu uživatelů a přirozenou integraci standardních kancelářských systémů - zejména elektronické pošty a prostředků pro podporu spolupráce) jsou určeny primárně pro nadstavby nad stávajícími systémy, jejich případnou integraci (propojení a využívání / konsolidaci dat), popř. na jednoduché relativně nezávislé agendy. 

Výhody 

• Relativně dobrá dostupnost funkčnosti standardních systémů (veliké množství celkem použitelných konektorů do Office a stovek aplikací třetích stran).
• Některá zajímavá řešení jsou přímo v defaultním prostředí a nabízí se neuvěřitelné možnosti přizpůsobení (např. Project for web - více jinde/jindy).
• Rozšiřitelnost o vlastní konektory a další možnosti.

Nevýhody 

• Prozatím nedostatečná podpora řízení vývoje (propojení s DevOps).
• Vizuální podoba pro jakýkoli skutečný algoritmus jej činí naprosto nesrozumitelným a nepřehledným. Je snad užitečná v jednotkách kroků, vytvářet a zejména udržovat cokoli složitějšího je utrpení.
• Poměrně komplikované možnosti pro hledání chyb a zlepšování výkonu.
• Prakticky chybějící možnosti pro automatizované testování.

Sporné pojetí

Příklady a hodnocení + náměty na rozumné řešení. Neustále hledáme reálné příklady toho, na co a jak by se měla Power Platform využívat. Uvítáme příklady z praxe.

• Ukládání příloh příchozích zpráv elektronické pošty.
  • Pro jednotlivce je to výborný nápad - flow dohledá nebo založí kontakt a pokud u něj najde odkaz na složku, do které se mají ukládat přílohy od daného odesílatele, tak to udělá a téměř jistě se dá i nějakým způsobem zpracovat obsah (jinde/jindy).
    • Má to svá "ale". Zpracování probíhá v cloudu. Takže "tvůrce" se shání po způsobu, jak uložit přílohu na lokální disk. Nebo zabudovává přímo do flow svá osobní pravidla. Ani ho nenapadne, že by to měl řešit parametrizací, protože netuší, jak zajistit správu parametrů pro jiné uživatele. Je pro něj obtížné a zbytečné nahradit přílohu odkazem, aby se k ní dostal. Ani ho nenapadne uvést do metadat přílohy zdrojovou právu, aby propojení bylo obousměrné.
    • Pro jednotlivce je mnohem lepší, když se taková automatizace koná na úrovni doplňku klienta elektronické pošty, především proto, že je k dispoźici interakce s uživatelem a je možno příslušné nastavení (klasifikaci zprávy/přílohy a určení místa, kam se má uložit) - třeba pro nový kontakt rovnou vytvořit, pokud ještě neexistuje (včetně vytvoření/kontroly a doplnění kontaktu).
  • V podmínkách organizace je vrcholně nežádoucí, aby se komunikací s externími subjekty zabývali jednotlivci prostřednictvím svýcho osobních schránek (Centralizace komunikace). A interně by posílání příloh mělo být striktně zakázáno. Naopak přílohy z externí firemní komunikace by měly být hned na vstupu nekompromisně ukládány do úložišť, nahrazeny ve zprávách odkazy atd.
  • Rozhodně by takovou funkčnost neměl dělat jednotlivec pro sebe (vývoj funkčnosti pro individuální použití dává smysl pouze v hodně specifických situacích a tedy je potřeba to posoudit - subjektivně to nejde - tím to přestává být "individuální"). Nutnou podmínkou je navíc celkem důsledná standardizace podoby schránek (proto vést většinu takto podporované komunikace přes sdílené schránky) a úložišť - má to být celopodnikové řešení.
    Co ostatně má vysloveně lokální charakter a nemá být řešeno pro všechny?
• Na základě zprávy elektronické pošty obsahující interní "schválení" provozního požadavku (dovolená, homeoffice, školení, ...) "automatizovat" vložení schváleného termínu do kalendáře či něco podobného.
  • Především je nutno zakázat vyřizování takovýchto žádostí mailem (nahradit odpovídajícím mechanismem - typicky schvalovacím workflow nebo funkčností na úrovni plánování dostupnosti lidí - např. pro správu kapacit).
  • Případná automatizace má mít "opačný" směr - vložením události daného typu do kalendáře se spustí transakce, která by standardně měla proběhnout bez lidského zásahu (na straně potenciálně "schvalujících" nadřízených by mělo být možno nastavit logiku, která vyhodnotí požadavek a pokud nenajde důvody k přezkoumání, tak jej schválí; samozřejmě to předpokládá, že žádost obsahuje nebo má k dispozici všechny potřebné údaje - např. u nepřítomnosti uvedení zastupujících apod.). 

Bojíme se, že nadšené amatérské využívání je stejně nebezpečné, jako Excel. Když cituji člověka, který má - dle našeho pohledu na podnikové potřeby a možnosti/požadavky technologií - poněkud "aktivistický" názor: "...lidé si pro sebe automatizují... stahování příloh, vyčítání informací, připomínky termínů, ...". To klíčové téma je chápání "osobní produktivity" - možná si někdo myslí, že dotyčný "občanský vývojář" má zvyšovat svoji vlastní osobní produktivitu... což celkem zákonitě není technicky "možné" (celkové úsilí × potenciální individuální přínos). Jednoznačně je to tak, že má zvyšovat osobní produktivitu skupiny spolupracovníků.

Pokud se rozhodnete, že tvorba takovýchto řešení dává ve Vašich podmínkách smysl, je potřeba to přiměřeně rozumně zorganizovat (Jak na Power Platform). Opravdu se vyplatí mít koncepci. Vědět, co a proč chcete. Jak se dají a mají aktivity řídit. Jak udělat z "občanů" vývojáře.