Jak na Power Platform

17. 11. 2024 Petr Opletal

Využití nástrojů pro vývoj a nasazení funkčnosti, která může zefektivnit běžné administrativní činnosti, je možná trošku větší výzva, než to vypadá na první pohled. Pokud tedy chceme získat skutečně užitečná řešení.

Jak na Power Platform

Primární otázka zní "K čemu je Power Platform užitečná". Pokud se rozhodneme, že nám využití dává smysl, musíme vytvořit podmínky pro její rozumné fungování. V jistém smyslu je potřeba dát si pozor na marketingové záměry MS. Podobně jako u Teams není šťastné přistoupit na "default" nastavení (viz dále/později, viz prozatím "Zásady správy/vývoje (low-code) aplikací"). Není ani úplně bezproblémové podlehnout indoktrinovanému nadšení z toho, jaké by to mohlo být úžasné...

Nejdřív si udělejme jasno v tom, zda potřebujeme koncepci. Možná nejprve co je to koncepce. Dle možností zpřístupníme vzorovou a metodiku pro její rozvoj a využívání.

  • Koncepce ... vymezení záměrů, podmínek, postupu, kritérií účelnosti a všech dalších principů + základ identifikace strategických faktorů úspěchu. Součást informační strategie, tedy součást podnikové. Identifikace skupin/lidí, jejich rolí, procesů. Neustále se vyvíjí.
    Je písemná. Nestačí si "myslet", že je to jasné.
  • Lidé (procesní role), bez kterých se neobejdete. Tým.
    • Architekt řešení s přesahem do "byznys architektury" (viz též Role...) .
      Pokud si myslíte, že nic takového nepotřebujete, tak jste buď ještě nezačali nebo už někoho takového máte, aniž o tom víte. Pokusíme se identifikovat symptomy, podle kterých poznáte, že vám chybí. Prvním symptomem je, že nikdo z lidí kolem Power Platform / digitalizace / automatizace nepostrádá koncepci.
    • Správce prostředí - včetně zajištění / koordinace veškeré potřené podpory a dohledu ze strany IT (bezpečnost atd.).
    • Tvůrce řešení... kdo dokáže na základě pochopení potřeb (bez detailní alibistické analýzy) vytvořit návrh způsobu řešení. Nejlépe tak, aby se daný postup dal vyzkoušet. Neměl by vytvářet funčnost metodou pokus-omyl, ale naopak při snaze "téma" strukturovat intenzívně doplňovat chybějící informace (aneb fakticky současně s návrhem vytváří analýzu), které musí zaznamenávat (na toto téma více jindy/jinde, prozatím příspěvek na základě konference). 
      V terminologii MS "maker"... 

      An app maker is someone with deep expertise in a solution who builds custom apps for their team that solve a business problem or respond to a need. They may envision, design, build, and implement an app—for example, to simplify, automate, or transform tasks and processes. After the app is up and running, they manage its security and versions. Being able to quickly create an app that helps others in your workplace is what makes this new role so exciting. 

    • Ambasador...
    • Asi jich bude víc...

Doporučené "strategické" skupiny (popsané v Role a působnost) jsou nutné. Nesmí být ovšem chápány formálně. Spíš je potřeba hledat vhodné pojetí a náplň. Prostě musí být dobře nastaveny procesy a potom se skupiny "objeví" samy. Jasně konkretizovat činnosti - např. licence k užívání, řízení přístupu, import dat či optimalizace zdrojů. Nebo ověřování nových funkcí, vytváření sdílených komponent atd. atd. 

  • Procesy...

Čím je koncepce užitečná. Sjednává (důležité - je to proces, nikoli cár papíru) shodné vnímání a vymezení příčin, omezení a možností prostředí, lidí, technologií mezi všemi účastníky. Formuluje (a umožňuje vysvětlovat, přezkoumávat a upřesňovat):

  • Srozumitelný (aktuální, aktualizovaný, platný) plán postupu
  • Jasné cíle - proč to děláme, čeho potřebujeme dosáhnout.
  • Zajistit, aby všichni, kdo budou vytvářet řešení, měli dostatečné znalosti toho, co je k dispozici (když to zjednodušíme, tak to směřuje k průběžně udržovanému katalogu typových řešení - nevymýšlet kolo, dobře vyjasnit / popsat možnosti služeb a standardních a vlastních komponent a zdůvodnit doporučení pro jejich používání či potlačení).
  • Zabránit multiplicitám, chaosu, plýtvání kapacitou...

Jak by mohla vypadat a fungovat - analogicky jiným strategiím (viz výše cár papíru × proces).

  • V rámci týmu je člověk, který shromažďuje/monitoruje/zpracovává podněty, požadavky atd.
  • V případě nutnosti svolá mimořádné jednání (celého nebo dílčího) týmu, na každé jednání připravuje (koordinuje přípravu ostatních) program. Členové týmu se dohodnou / validují zjištěné podněty (změny, problémy, úspěchy, výjimky, požadavky, ...), identifikují závislosti a převedou na plán změn / úkolů (možná "projekt"). Dle situace vyčlení kapacitu (najdou nejvhodnějšího spolupracovníka či dodavatele, který vyřeší první úkol).
  • Tyto kroky přinášejí změny pravidel, nástrojů, postupů, dovedností, ...

Identifikovat & analyzovat potřeby

Kritický krok. Viz Správa požadavků. Bude upřesněno.

Osobní produktivita

Při diskusi o podobě sady řešení, které by mohla vznikat s využitím PP, se vyskytuje pojem "personal productivity" (popravdě když se hledá u MS, na prvních deseti stránkách výsledků hledání jsou jen samá témata pro experty; navíc to vůbec nekoresponduje s tím, že by aplikace měl vytvářet člověk "...with deep expertise... for their team that solve a business problem...").

Rozumí se tím "default" prostředí, ve kterém si může každý splácat, co ho napadne. 

Bohužel to nejde zakázat.

Pokud budete mít koncepci, musíte si odpovědět, jestli máte zájem o "osobní produktivitu", resp. v jaké podobě.

Ambasador digitalizace / automatizace

Rozhodně se vybízením k opatrnosti při šíření nadšení pro nové technologie nemyslí to, že by se lidem měly tajit či bránit v jejich "používání". Klíčový je význam "používat". Aplikace / řešení by měli vytvářet / vyvíjet (skuteční) "tvůrci" / vývojáři (kvalifikovaní, kompetentní, ... rozhodně se do toho nemá pouštět člověk, který nezná základy jako např. cykly nebo ošetření chyb). Se znalostí principů vývoje software. Nadšení (běžných) uživatelů je velmi dobré směřovat ke zkoušení všeho, co by se jim mohlo líbit. Prozkoumávání zajímavých řešení. Poznávání a experimentování. 

Cílem je, aby vznášeli informované požadavky.

Pomáhali při pochopení podstaty. Přesně tato oblast je určena pro průkopníky a evangelisty. Mají se intenzívně věnovat lidem v organizaci. Rozvíjet komunikaci. Hledat způsoby, jak jim pomáhat. Moderovat jejich zájem a úsilí. Směrem k dostatečně důkladné a důsledné analýze potřeb. Nikoli k amatérskému vytváření primitivních udělátek. A pokud mají zájem vytvářet funkčnost, tak mít nachystaný kvalitní trénink, který je naučí "plavat, než skočí do vody".

Nekoncepční (zjednodušeně nekvalitní) řešení nelze udržovat, natož rozvíjet. Současně se jich neumíme zříci až do doby, než naprosto zkolabují (nebo nastane jiná pohroma, která je zcela vyřadí). Poté s údivem zjišťujeme, že bez nich je (občas)¨všechno mnohem jednodušší a rychlejší. To je bohužel špatná vlastnost ad hoc řešení, která vznikají "nejsnazší možnou cestou". Základ je víceméně v pořádku a použitelný. Jenže celková architektura řešení (či spíše chybějící architektura) neumožňuje je rozšiřovat. Jenže se rozšiřují. Tím vzniká zhoubně bující nádor kontraproduktivity. 

Správa / governance

Snadno se tak stane, že začnou vznikat řešení, která nejsou v souladu se zájmy organizace (např. z důvodů bezpečnosti, integrity, kompatibility, konzistence, stability, ...). Vůbec nejde o to, jestli je využívaný systém dostatečně robustní, pokud na něm budou přímo či nepřímo záviset kritické procesy. Jde o to, aby nezačal překážet. To je raz dva.

Nesystémový přístup může rozvoj zablokovat.

Správa má pro všechny účastníky zajistit (v daných podmínkách) optimální postupy, pravidla, zjednodušit využívání a poskytnout informace tak, aby zejména tvůrcům bylo jasné, jaké zdroje (data, funkčnost, rozhraní) mohou získat a jak + jaké jsou vzory pro jejich použít. Jinak budou pracovat jen s tím, co vědí (co si sami najdou). Domyslet způsoby (organizaci práce), aby přidávali minimální rozsah (splnili vnější tlak na termíny nasazení, neplýtvali kapacitou). Aby nedělali, co už je hotové a naopak toho využívali. Cestou je vytváření katalogu vzorových aplikací či přímo šablon.

Je dobré správně chápat, co znamená správa (později, prozatím "Zásady správy/vývoje (low-code) aplikací"). Rozhodně se nejedná jenom o bezpečnost (viz též Koncept nasazení, více jindy/jinde). Dost často se pod tím pojmem prezentuje obrovská halda občas sporných či (často) formálních opatření, která (na začátku) nepřinášejí žádný prospěch (a pokud nejsou domyšlená, tak nikdy). Je jisté, že není účelné nejdříve vymýšlet, jak něčemu zabránit či podpořit, když nevíme čemu. Je potřeba to dělat současně.

Nevyvíjet co již máte (nebo můžete koupit)

Kdy je rozumné vytvářet nové řešení a kdy je lepší hledat potřebnou funkčnost v těch stávajících.

Asi se to může v různých organizacích / podmínkách lišit. Existující řešení - nejlépe standardní - je vždy nekonečně efektivnější, než lopotně vytvářet vlastní funkčnost (případná diskuse jindy/jinde). Je opravdu dobré předem zamítnout představu, že právě ta naše organizace je tak mimořádně specifická, že je potřeba mít individuální řešení (většinou je to způsobeno tím, že neumíme správně analyzovat potřeba a formulovat své požadavky, takže nedokážeme vyhodnotit, jestli je či není standardní řešení vhodné a věříme, že potenciální dodavatel individuálního tuto závadu odstraní... přesto celou dobu hrajeme hru, ve které předstíráme, že víme, co chceme). 

Samozřejmě je velmi užitečné, pokud standardní řešení má rozhraní (API), pomocí kterého jej lze propojit s ostatní infrastrukturou. To je něco, co by mělo být pro každé nový (popř. akualizaci stávajícího) systém kritickou podmínkou.

Vzorové aplikace jsou poměrně dobrý způsob, jak se mohou tvůrci s možnostmi platformy seznámit.

  • Nedoporučujeme snažit se je upravovat pro vlastní potřebu, pokud se plně neztotožníte s principem jejich fungování. Potom je ovšem není potřeba upravovat.
  • Je výhodné si je vyzkoušet a projít, co všechno funguje / jaký je potenciál technologie.
  • Pro vytvoření vlastního řešení je rozumné provést nejdříve poměrně důkladnou analýzu potřeb (a ověřit, zda potřebná funkčnost není již někde k dispozici).

Umíte identifikovat příležitosti pro zjednodušení, racionalizaci, automatizaci. Chcete svým spolupracovníkům pomoci s tím, aby nevymýšleli kolo.

Nehodláme vytvářet cosi jako "personal asistent", protože je jisté, že je efektivnější naučit všechny zacházet s Outlook-em.