Power Platform a benefity

Dílčí personální agendy

Může být, že máte skvělý informační systém, kterým jsou plně pokryty požadavky na různé dílčí evidence spojené s péčí o spolupracovníky. Většinou to tak není. Personální agendy jsou vhodným prostředím pro vznik a uplatnění jednoduchých řešení dle předchozího článku K čemu je dobrá Power Platform. Předpokládáme, že v této oblasti budeme s případovými studiemi pokračovat, také proto je tento článek zjednodušený a schematický (nechceme se zamotat do "...kdyby...možná...jenže...").

Máte možnost přispět. 

Soustředíme se na reálný příběh a nebudeme si všímat vedlejších linií. Na počátku bylo zařazení... či spíše dlouholetý zápas... benefitů typu vstupenky do aquaparku a skipasy. Jejich využívání bylo spojeno se spoustou mailů a telefonátů. Např. k aquaparku chodila výzva (pozor, od sekretářky, na kterou to personální 'hodilo') "... 1.3. v 8:00 začnu přijímat e-maily s požadavky na 2. čtvrtletí...". Není férové si z toho dělat legraci, rozhodně to není optimální řešení, ale dotyčná paní nejspíš neměla důvod hledat něco složitějšího. Jenom mi zůstává záhadou, jak kontrolovala, kdy kdo již daný benefit čerpal.

Digitalizace skipasů

Kdosi bez sebemenších ambicí domluvit se s někým dalším, kdo by mu s tím mohl pomoci, se rozhodl vyžádat "aplikaci". Zadání zjevně bylo nedomyšlené. Vzniklo něco, co se na intranetu dané organizace prezentuje...

Kliknutím na odkaz SKIPAS - PowerApps se můžete podívat, jestli jsou v termínu, který chcete pro lyžování zvolit, volné skipasy. Pokud ano, volejte paní Janě na mobilní číslo xxx xxx xxx (jen a pouze na toto číslo).

Jak se k tomuto vyjádřil kdosi, kdo o možnostech technologií ví alespoň něco, "...pokud je součástí automatizace volání na tel. č., tak je za to trest smrti...". Ona "aplikace" běží nad původním sešitem, do kterého si paní z recepce, která to má na starosti, eviduje, kdo kdy kde chce lyžovat...

Nemusíte tomu věřit, ale nevymyslel jsem si to. Něco takového bych nedokázal. 😉

Principy (vývoje & způsobu nasazení a užití)

• Hledáme minimální funkčnost & optimální poměr výkon / cena (zde práce / užitek). V tomto případu je to poněkud komplikováno tím, že spokojenost lidí je významným faktorem (viz na konci nástin hodnocení efektivnosti).
  
• Řešení musí zůstat otevřené (aby bylo možné je rozšiřovat a/nebo propojit s jinými systémy).
• Uživatelé needitují data, předávají systému své vstupy transakčním způsobem (vytvoří "požadavek" a předají ke zpracování). Pro své definované činnosti využívají přesně odpovídající rozhraní v podobě průvodce.
• Na uživatelském rozhraní a nejpozději při zpracování transakce jsou kontroly, které znemožní vstup neplatných dat do systému.
• Iterace - dodávaná funkčnost se vytváří a zpřístupňuje postupně - v co nejmenších krocích. Jedno rozšíření (nedělitelné) v jednom kroku. Co nejdříve se otestuje a předá k užívání. Od začátku vývoje (v té prvotní fázi bez "plošného" užívání - v závislosti na ALM).

Potřeby a požadavky

Organizační (respektovat pravidla pro čerpání benefitů).
Reálně tato část (zejména u složitějších záležitostí) je naprosto kritická a rozhodně nestačí se spokojit s tím, co dosud "bylo samozřejmé". Co nám kdo řekne. Problém je v tom, že když v dané transakci účinkuje člověk, uplatní svoji logiku a znalost, popř. nesystémově zjistí či dohledá, co chybí. To automatizovaný systém neumí. Proto musí být věcná podstata podporovaného procesu popsána a pochopena poměrně důkladně (viz samostatně). Náročná detektivní práce. Zde jen stručně (opravdu je to extrémně jednoduchá a poměrně deterministická agenda, přesto je analýza potřeba).

• Lidé mají nárok na definovaný počet "vstupenek" za definované období a pro daný výskyt (pokud to poskytovatel služby omezuje - např. nejvýše X skipasů současně). Je tedy potřeba zkontrolovat, jestli spolupracovník má nárok a zda je služba k dispozici - resp. není možné se registrovat na termín, ve kterém je již limitovaný počet dosažen.
• Limit se vztahuje na "typ" benefitu (tedy skipas je skipas bez ohledu na středisko).
• Registraci je možno zrušit - uvolnit pro náhradníky (může být limitováno lhůtou, ve které se případnému poskytovateli služby předává jmenný seznam).
• Termín rezervace lze změnit (v průběhu období pouze na volný), postupuje se stejně jako při zrušení.
• Může být pozitivně přijato, pokud se spolupracovníkovi s předstihem oznámí, že se jeho nárok obnovuje.
• Je potřeba mít možnost se registrovat jako náhradník a stanovit si lhůtu, do kdy je tato registrace platná (jak rychle může dotyčný reagovat na to, když někdo jiný dané čerpání zruší).
• Není jisté, jestli bude účelné (nutné) umožnit registrovat v zastoupení, je potřeba s tím počítat.
• Registraci je možné provést kdykoli (tedy i před termínem, kdy je to "platné"). Pokud je čerpání omezeno na časové úseky (od poskytovatele služby limit pro čtvrtletí apod.), předem zadané požadavky se "slosují" v okamžiku zahájení daného období - nejdříve ti spolupracovníci, kteří daný benefit ještě nečerpali, resp. podle četnosti čerpání (nejdříve se uspokojují registrace těch, kdo čerpali méněkrát, pokud v některé úrovni je více žadatelů než zbývající kapacita, přidělí se zbývající lístky náhodně). Neuspokojené požadavky zůstávají jako rezervace.
• Možná bude potřeba diskriminovat ty, kteří si benefity rezervují a nečerpají.

Nasazení.

• Bude potřeba převést stávající záznamy o dosavadním čerpání benefitů (nelze vyloučit, že některé lhůty přesahují rok nebo se nedrží / nedávají smysl vzhledem ke kalendářnímu roku, navíc by se tak vynucovalo nasazení řešení se začátkem roku a připravili bychom se o možnost na těchto reálných datech ověřit funkčnost).
• Před uvedením do ostrého provozu musí být k dispozici zkušební verze. K té bude k dispozici vysvětlení a návod a všichni spolupracovníci budou vyzváni, aby si aplikaci vyzkoušeli a případně (přímo jejím prostřednictvím) připomínkovali cokoli považují za potřebné.

Provoz

• Uživatelská rozhraní musí být natolik jednoduchá a návodná, aby běžný uživatel (mobilní telefon) nepotřeboval žádné školení a v podstatě ani žádný návod. To znamená, že nesmí být možnost vložit neplatné údaje (úplná kontrola vstupních dat).
• Funkčnost musí být k dispozici na firemních zařízeních všech formátů (PC, kiosky, mobilní zařízení).
• Pokud bude k dispozici SMS služba, bude komunikace členěna mezi SMS a elektronickou poštu.
• Pokud lze předávat notifikace přímo prostřednictvím aplikace / rozhraní v mobilním telefonu, je tato forma upřednostňována.

Koncepční.

• V první fázi není žádoucí integrace na stávající personální systém. Má být provozuschopný nezávisle.
• Taktéž je žádoucí využívat datová úložiště, která jsou již zalicencována. Náklady na uložení dat je nutno minimalizovat (konkrétně pro tento účel není přijatelné použít Dataverse). Je nutno počítat s tím, že konkrétní úložiště se případně vymění za výkonnější, pokud se to ukáže jako nezbytné.
• Pokud bude systém obsahovat užitečná data, bude žádoucí mít možnost je analyzovat a výsledky vizualizovat.
• Je potřeba počítat s tím, že obdobné typy benefitů s případně poněkud odlišnými podmínkami budou přibývat. Popř. je žádoucí následně vyhodnotit, jestli by nebylo účelné/možné spravovat v tomto řešení i ostatní benefity, které nejsou spravovány přes benefitní službu (kartu).
• Systém musí respektovat ochranu osobních údajů.

Výše uvedené jsou "potřeby". Technicky by měly být zpracovány & vyhodnoceny / analyzovány samostatnou akcí - jejím cílem je zmapovat širší kontext, interpretovat představy a přání na konkrétní požadavky a najít jim odpovídající minimální výchozí funkčnost. Pro účely tohoto článku jako požadavky chápeme přímo případy užití (fakticky uživatelská rozhraní, odpovídající konkrétním činnostem).

Případy užití a příprava vývoje řešení

Musíme si udělat (na technologii v podstatě nezávislé a přesto formulující požadavky na funkčnost a uživatelské rozhraní) případy užití. Důkladně. Důsledně. Podrobně. Sehnat si k nim reálná data (specification by example, využijí se pro ověření funkčnosti a testování). Současně musí vznikat procesní model (je škoda, že v Power Platform je to samostatně placená funkčnost). Je rozumné, aby byl společně se sběrem požadavků fakticky přímo v systému (propojen; více jinde/jindy). Tady uvedeme jen některé a stručně, všechny jsou v dokumentaci této případové studie.

Role

• Uživatel... spolupracovník, mající nárok na benefit.
• Správce (benefitů)... role pověřená dohledem a případnou komunikací s poskytovateli služeb (což znamená, že jich může být i relativně hodně - např. pro každého poskytovatele někdo).
• Nahlížející... personalisté či obdobné role - oprávněný zájem se zajímat o čerpání a pokrytí.

Případy (činnosti)

• [Uživatel] Upravit své údaje / nastavení. Prohlížet svoji historii a plán čerpání. Zřetelně zobrazit, na jaké benefity má v současné době (období od-do) nárok (versus vyčerpáno), kdy se nárok obnovuje. Možnost z tohoto přehledu jednoduše pokračovat na objednání.
• [Uživatel] Registrovat zájem o čerpání benefitu (datum, počet, ...). Dostupné možnosti se nabízí dle možností uživatelsky přívětivě - musí být možné jak přímé zadání termínu, o který by měl zájem, tak prohlížení volných termínů - tedy pokud se bude využívat kalendář, je potřeba  odlišit dny, které mají kapacitu (ze strany poskytovatele služby) naplněnou, které jsou volné a kde je kapacita částečně využitá.
• [Uživatel] Reagovat na upozornění <upřesnit, jaká to budou>.
• [Uživatel] Zrušit nebo změnit registraci.
• [Správce] Zobrazit stav registrací na libovolný termín.
• [Správce] Zrušit termín nebo registraci.
• [Správce] Vytvořit požadavek na poskytovatele (pokud nelze automatizovat).
• [Správce] Upravit termíny a podmínky benefitů, přidat benefit.
• [Správce] Pozastavit čerpání benefitu. 

Pro každý případ užití formulovat detailně validační podmínky zadávaných údajů a spouštěných akcí (co je potřeba zkontrolovat, než se údaj "přijme", popř. co je nutno vyhodnocovat pro provedení / zplatnění akce a jaké důsledky má akce mít, včetně příslušného uživatelského rozhraní, ze kterého se spouští). Tohle by mělo být součástí "vývojářské dokumentace", bohužel PP v tomto směru nemá dostatečné možnosti (proto stojí zato zkusit to "obejít" a jak naznačeno, ukládat popis funkčnosti v datové části řešení společně s procesy, požadavky atd.).

Způsob hodnocení efektivnosti

V tomto případě množství práce k výslednému efektu (abstrahujeme od předchozího úsiílí vynaloženého na získání zkušeností, pravidel, metodiky, vzorů, šablon atd.). Budeme sice uvádět i ambiciózní záměry, pokud je pro první verze řešení zamítáme, zkusíme vysvětlit proč.
Výsledný efekt je zde čas, který věnují zaměstnanci organizace uplatňování požadavků a  koordinátoři jejich zpracování. Druhou součástí je spokojenost lidí (jak se jim daný způsob vyřízení bude líbit) - to se dost špatně kvantifikuje, ale stojí zato se alespoň pokusit.

Článek není kompletní. Pravděpodobně bude na pokračování - tak jak budeme na té případové studii pracovat. Pokud o Power Platform, popř. změně přístupu k opatřování softwre uvažujete, mohou být užitečné články Jak na Power Platform a Jak získat potřebné IT.

Možná dáme výsledky k diskusi a k dispozici. Nebo to můžeme probrat na některém PPUG.