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í.
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í.
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.
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.
Čí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):
Jak by mohla vypadat a fungovat - analogicky jiným strategiím (viz výše cár papíru × proces).
Kritický krok. Viz Správa požadavků. Bude upřesněno.
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ě.
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.
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ě.
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.
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.