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

Viz též příležitosti pro automatizaci.

• 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.).
• Související sledování využití kapacit.
• 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ů). Popř. včetně registru souvisejících povinností ("termínů").
• Analogicky široká škála evidencí v personální oblasti (průběžně publikujeme případovou studii na správu benefitů).
• Správa (např. tvorba a připomínkování) podnikových dokumentů.
• Jednoduchý procesní model
  Pokud nemáme k dispozici nic lepšího - lze využít s některými výhodami a nevýhodami (ale pravděpodobně s nepřekonatelným poměrem výkon/cena).
• 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.

V případové studii o využívání PP např. pro time-tracking je mimo jiné zmíněno:

• "...Poprvé jsem schopen dosáhnout skutečné agility..." (není podstatné, co přesně je pojmem 'agilita' míněno) - podstata je zřejmá - prostředí, které díky své podstatě podporuje:
  • Iterativní vývoj.
  • Změny (požadavků).
  • Možnost začít na primitivní úrovni.
  • Snadno výměnu komponent.
  • Zapojení všech relevantních spolupracovníků.
• Předání použitelné aplikace (řešení) v řádu jednotek týdnů.
• Nepočítají se řádky kódu či něco podobného, ale pokrývání konkrétních potřeb/požadavků (bohužel skryto za frází "delivering value to people").

Konkrétně využití PP na vytvoření řešení pro záznam & analýzu (popř. navazující plánování) využití kapacit považujeme za dokonalou příležitost pro osvojení či ověření možností prostředí.

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. Obzvlášť zákeřné je přidávání dalších a dalších nezávislých evidencí, vztahujících se k ne/přítomnosti.. pokud akceptujeme myšlenku platného kalendáře.
• 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í.
• Podívejte se kolem nebo spíš do poštovní schránky - co všechno se má "vyplňovat" a zjevně by se to dalo dělat elegantněji.
  Nedávno (listopad 2024) jsem viděl mail s přiloženým sešitem na hlášení čerpání dovolené do konce roku nebo jeden zcela neuvěřitelný ohledně pojištění zodpovědnosti.
  
  

Některé scénáře jsou jednoznačné a jednoduché. Stačí hrozně málo. Ovšem pozor, může se to zvrhnout.

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í). Ale na podporu smysluplného vyhodnocení kapacity lidí, kteří samostatně pracují na více zakázkách, nepotřebujeme - a nejspíš ani nevyužijeme - komplexní systém pro řízení výroby.

Čím se řešení na Power Platform liší

Podstatné je, od čeho.

• Obvyklá lidová tvořivost - viz dále.
• Zadávání přizpůsobení (customizace) komerčních řešení (spíše samostatně).
• Či vývoj komplexních řešení na zakázku.

Všechny zkušenosti ukazují, že v organizacích je naprosto nezbytná co nejrychlejší analýza situace, podmínek a záměrů v oblasti digitalizace a automatizace (vyhodnocení koncepce digitalizace). Prakticky všude změny bohužel vycházejí ze zájmů dodavatelů IT v situacích, kdy je současná situace (typicky lidová tvořivost nebo naprostá absence práce s daty) neudržitelná, obvykle pod tlakem legislativy nebo obdobně špatně ovlivnitelných faktorů. Zásadní doporučení je (co nejrychlejší) analýza/audit aktivit v této oblasti (lhostejno, jak jí říkáte a do čeho všeho zasahuje či kde se "skrývá"). Popravdě je potřeba zahrnout low/no code platformy do informační strategie. Ať už jejich podpora či monitoring (navždy je zavrhnout by bylo hodně neracionální). 

Lidová tvořivost

Jistou výhodou je, že i když je platforma prezentována jako "vhodná" pro "občanské vývojáře", není tak úplně jednoduché s jejím používáním začít. Ano, výhodou. 

Rozšiřování standardních systémů

Pokud by komerční řešení byla připravena na rozšiřování, mohl by to být rozumný postup... pokud by to rozšíření inicioval a platit výrobce onoho řešení. Na téma "individuálních" úprav monolitů jindy/jinde.

Vývoj na zakázku

V jistém smyslu horší varianta předchozího.

Zásadním problémem v obou případech je kvalita analýzy potřeb a formulace zadání. 

Popíšeme tady zákeřnosti spojené s tím, že když necháte někoho zvenčí vyvíjet "jeho" řešení (dle vašeho zadání), vzniká iluze izolace od technologických aspektů. Nejen. Vytvořená řešení - protože není reálné udělat zadání, které by předem postihlo úplně vše, co bude systém muset zvládat - budou vyžadovat úpravy. Téměř jistě je nemůže dělat nikdo jiný, než autor. Tak vzniká naprosto fatální "vendor lock".

Plus otázka izolace funkčnosti. Při použití PP bude nutno (doporučeno) vytvářet a ověřovat řešení od počástku s průběžným nasazováním do produkčního prostředí. To proto, že bude muset být navázáno na dostupné systémy a data. Takže je snadné sledovat postup a porovnávat jej se zadáním (např. popsanými situacemi ~ use case či jiný formát). Hlavní přínos je, že díky charakteru vznikajícího řešení (jindy/jinde... jde o relativní nezávislost jednotlivých částí řešení a nezbytné přístupnosti způsobu řešení) je snadno auditovatelné / kontrolovatelné (potenciálně převzatelné prakticky kýmkoli, kdo danou technologii přijatelně ovládá).

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 ostatní uživatele.
      • Je pro něj obtížné a zbytečné nahradit přílohu odkazem, aby se k ní dostal.
      • Nemá potřebu uvést do metadat přílohy odkaz na zdrojovou právu, aby propojení bylo obousměrné.
    • V případě osobní pošty je mnohem lepší, když se taková automatizace koná na úrovni doplňku lokálního klienta elektronické pošty (nikoli flow). Především proto, že je k dispoźici interakce s uživatelem a je možno upřesnit ppotřebná nastavení (klasifikaci zprávy/přílohy a určení místa, kam se má uložit; je dobře vidět, že lokál přestává platit při používání více zařízení). Typicky je rozumné rovnou vytvořit a parametrizovat nový kontakt, pokud ještě neexistuje (včetně nastavení/kontroly a doplnění úložiště a pravidel pro ukládání příloh).
  • V podmínkách organizace je vrcholně nežádoucí, aby se komunikací s externími subjekty zabývali jednotlivci prostřednictvím svých osobních schránek (Centralizace komunikace). 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 sdíleného úložiště, nahrazeny ve zprávách odkazy atd.
  • Rozhodně by takovou funkčnost neměl vytvářet 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 účelnost řešení posoudit (což subjektivně nelze - tím to přestává být "individuální"). Nutnou podmínkou (plošného nasazení) je navíc celkem důsledná standardizace podoby schránek (proto je rozumné vést většinu takto podporované komunikace přes sdílené schránky) a úložišť - prostě při bližším pohledu to jednoznačně musí být celopodnikové řešení. Jistě, vyžaduje to přemýšlení a bezpochyby zásahy do zvyklostí jednotlivců.
    Jenže co má vysloveně lokální charakter a nemá být řešeno obecně?
• 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.). 
• Vytváření aplikací na "připomínky" je jednoznačně zločin. Něco jiného je agenda hlídající platnost (to může být cokoli v personální oblasti - zdravotní prohlídky, zákonné certifikace, BOZP, servis zařízení, podávání hlášení pokud to nelze automatizovat... vždy to bude nezávislá agenda, která bude v okamžiku, kdy je potřeba něco udělat, hledat aktuálně přiřazené pracovníky pro definovanou roli; pokud k roli není nikdo přiřazen, eskaluje poplach přes správce systému).

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.