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é využití. 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í").

Nejdřív si udělejme jasno v tom, zda potřebujeme koncepci. Možná nejprve co je to koncepce.

• 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. 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. 
    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...

K čemu by měla být koncepce

• Srozumitelný 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 mít průběžně udržovaný katalog typových aplikací - nevymýšlet kolo, dobře znát možnosti služeb a standardních a vlastních komponent).
• Zabránit multiplicitám, chaosu, plýtvání kapacitou...

Jak by mohla vypadat a fungovat - analogicky strategiím - není to cár papíru, ale proces.

• V rámci týmu je člověk, který shromažďuje/zpracovává podněty, požadavky atd.
• V případě nutnosti svolá mimořádné jednání 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 člena týmu, 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ů.

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".

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ělo 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. 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.

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 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), jak získat, aby splnili vnější tlak na termíny nasazení. 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 na první pohled formálních opatření, která na začátku nepřinášejí žádný prospěch. 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.