Microsoft Power Platform: jak dobrać narzędzia do procesu

Czy do uporządkowania wniosków zakupowych potrzebujesz aplikacji, automatyzacji, portalu czy agenta AI? Odpowiedź zależy od tego, kto zgłasza potrzebę, gdzie znajdują się dane i kto podejmuje decyzję. Power Platform warto projektować przez rozdzielenie danych, interfejsu i reguł procesu. Dopiero taki podział pokazuje, które narzędzia są potrzebne, a które jedynie powiększą zakres wdrożenia.

Jeśli wniosek krąży dziś między pocztą, arkuszem i rozmową z przełożonym, nowy ekran może pomóc. Nie ustali jednak, kto zatwierdza wydatek podczas nieobecności kierownika ani co zrobić z korektą po akceptacji. Te reguły powinny powstać przed budową rozwiązania.

Co obejmuje Power Platform

Power Platform łączy narzędzia do tworzenia aplikacji, automatyzacji, raportów, witryn i agentów. Poszczególne składniki mają różne role, wymagania oraz sposoby rozliczania. Nie traktuj nazwy platformy jako jednego pakietu, który automatycznie obejmuje wszystkie zastosowania.

Power Apps służy do budowy aplikacji biznesowych połączonych z danymi. Możesz korzystać z Dataverse oraz obsługiwanych źródeł zewnętrznych. Platforma pozwala również programistycznie rozszerzać rozwiązania, gdy gotowe możliwości nie wystarczają. Zakres ten przedstawia dokumentacja Power Apps.

Power Automate wykorzystasz do przepływu czynności i integracji, Power Pages do witryny obsługującej użytkowników zewnętrznych, a Power BI do analizy wyników. Copilot Studio odpowiada za budowanie agentów. Te narzędzia mogą współpracować, ale nie każdy proces potrzebuje całego zestawu.

Potrzeba	Składnik do rozważenia	Pytanie przed wyborem
Pracownik wprowadza i poprawia dane	Power Apps	Jakie czynności wykonuje na ekranie?
System przekazuje sprawę lub uruchamia działanie	Power Automate	Co wyzwala krok i co oznacza jego zakończenie?
Klient korzysta z witryny samoobsługowej	Power Pages	Które własne dane może zobaczyć?
Kierownik analizuje wyniki	Power BI	Jaką decyzję zmieni raport?
Użytkownik prowadzi rozmowę z agentem	Copilot Studio	Czy potrzebuje odpowiedzi, czy wykonania działania?
Proces wymaga wspólnych danych aplikacyjnych	Dataverse	Jakie rekordy, relacje i role trzeba utrzymać?

Tabela jest punktem wyjścia do projektu. Nie zastępuje sprawdzenia ograniczeń konkretnej funkcji ani wymagań licencyjnych wybranego scenariusza.

Aplikacja canvas czy model-driven

W Power Apps możesz budować aplikacje canvas i model-driven. W pierwszym podejściu masz dużą swobodę projektowania ekranu. W drugim interfejs powstaje wokół modelu danych Dataverse i jego elementów. Microsoft opisuje tę zależność w przeglądzie aplikacji model-driven.

Dla prostego zgłoszenia z telefonu zacznij od sprawdzenia kilku czynności użytkownika: wybór projektu, wprowadzenie kwoty, dodanie dokumentu i wysłanie. Dla zespołu obsługującego wiele powiązanych spraw większe znaczenie mogą mieć relacje, widoki oraz przechodzenie między rekordami. Nie wybieraj rodzaju aplikacji na podstawie wyglądu jednej demonstracji.

Przetestuj także poprawianie danych, wyszukiwanie starej sprawy i pracę na docelowym urządzeniu. Ekran wygodny dla twórcy na dużym monitorze może okazać się uciążliwy dla pracownika korzystającego z telefonu. Użytkownik powinien wykonać zadanie bez instrukcji przekazywanej mu przy każdym kliknięciu.

Najpierw zaprojektuj dane

W przykładzie wniosku zakupowego potrzebujesz przynajmniej zgłaszającego, projektu, kwoty, uzasadnienia, statusu i osoby podejmującej decyzję. Ustal, które dane pochodzą z istniejących systemów. Ręczne przepisywanie listy projektów do nowej aplikacji tworzy kolejne miejsce, które trzeba aktualizować.

Zapisz możliwe stany sprawy. „Nowy”, „do uzupełnienia”, „zaakceptowany”, „odrzucony” i „anulowany” powinny mieć konkretne znaczenie. Osobno określ, czy akceptacja oznacza zgodę na zakup, czy potwierdzenie jego rozliczenia. Połączenie tych dwóch zdarzeń w jeden status może później zafałszować raport kosztów.

Właściciel procesu zatwierdza znaczenie pól i stanów, a osoba techniczna sposób ich przechowywania. Dzięki temu zmiana ekranu nie staje się przypadkowo zmianą zasad zakupowych.

Element wniosku	Reguła do zapisania	Przypadek graniczny
Kwota	Waluta i sposób uwzględnienia podatku	Wniosek w innej walucie
Projekt	Źródło identyfikatora i aktywność	Projekt zamknięty przed decyzją
Akceptujący	Reguła wyboru i zastępstwo	Nieobecność kierownika
Korekta	Co można zmienić po wysłaniu	Wzrost kwoty po akceptacji
Anulowanie	Kto i kiedy może je wykonać	Zakup już przekazany do realizacji

Automatyzacja potrzebuje obsługi wyjątków

Przepływ może przekazać sprawę do właściwej osoby, wysłać przypomnienie lub zapisać wynik. Zanim go uruchomisz, zdefiniuj reakcję na brak odbiorcy, duplikat zgłoszenia i przerwane połączenie z innym systemem. W przeciwnym razie pomyślne zakończenie części kroków może zostać pomylone z załatwieniem całej sprawy.

W syntetycznym przykładzie pracownik klika „Wyślij” ponownie, bo nie zobaczył potwierdzenia. Dwa uruchomienia przepływu nie powinny powodować dwóch zamówień. W projekcie przewidź identyfikator sprawy i kontrolę ponowienia. To wymaganie biznesowe do zaimplementowania i sprawdzenia, nie gwarancja wynikająca z samego użycia Power Automate.

Zachowaj ślad decyzji potrzebny odbiorcom procesu: kto zaakceptował, kiedy i w jakim zakresie. Ustal również drogę ręcznej obsługi podczas problemu. Pracownik powinien wiedzieć, jak pilnie zgłosić wydatek, zamiast tworzyć nieudokumentowane obejście przez prywatną wiadomość.

Dostęp sprawdzaj poza wyglądem ekranu

Ukrycie pola albo przycisku nie dowodzi, że użytkownik nie może dotrzeć do danych inną drogą. Zaplanuj uprawnienia źródła i tożsamość używaną przez połączenia. Osoba zgłaszająca wydatek, kierownik oraz finanse zwykle potrzebują różnych zakresów.

Power Platform oferuje polityki kontrolujące użycie konektorów. Zmiana takiej polityki może wpływać także na istniejące aplikacje i przepływy, a jej pełne zastosowanie nie musi być natychmiastowe. Opisuje to dokumentacja polityk danych. Dlatego administrator powinien sprawdzać wpływ zmiany na działające rozwiązania, a nie tylko zatwierdzać nową konfigurację.

W odbiorze wykorzystaj konta odpowiadające docelowym rolom. Sprawdź własny wniosek, cudzy wniosek i próbę zmiany niedozwolonego statusu. Osobno przetestuj użytkownika zewnętrznego, jeśli powstaje portal. Konto twórcy z szerokimi uprawnieniami nie jest reprezentatywnym odbiorcą.

Low-code nie usuwa pracy inżynierskiej

Low-code ogranicza ilość ręcznie pisanego kodu w określonych zadaniach. Nadal potrzebujesz projektu, testowania i utrzymania. Gdy gotowy konektor lub reguła nie pokrywa wymagania, rozszerzenie programistyczne może być uzasadnione. Jego koszt i odpowiedzialność powinny być jawne już w ofercie.

Współpraca osoby znającej proces z twórcą aplikacji i programistą pozwala wykorzystać różne kompetencje. Pracownik biznesowy opisuje wyjątki, twórca przygotowuje ekran i przepływ, a programista ocenia integrację lub niestandardową logikę. Nie przerzucaj na jedną osobę odpowiedzialności za wszystko tylko dlatego, że narzędzie umożliwia szybkie zbudowanie prototypu.

Microsoft ujmuje wymagania, tworzenie, testowanie, wdrażanie i utrzymanie w podejściu ALM dla Power Platform. Rozwiązania, czyli solutions, służą do przenoszenia składników między środowiskami. Sam eksport składników nie oznacza jednak kompletnego planu odtworzenia danych i działania procesu.

Jak porównać koszt rozwiązania

Zacznij od liczby i rodzaju użytkowników, źródeł danych oraz planowanych działań. Licencjonowanie Power Platform obejmuje różne kombinacje licencji użytkowników, pojemności i zużycia. Ograniczone uprawnienia dostępne w części planów Microsoft 365 nie są równoważne pełnym licencjom premium. Aktualne rozróżnienia znajdziesz w przeglądzie licencjonowania.

Nie przyjmuj, że darmowe środowisko deweloperskie może obsługiwać produkcję. Nie traktuj też obecności planu Dataverse w panelu jako potwierdzenia uprawnień do każdej własnej aplikacji. Poproś o ocenę konkretnego przebiegu: kto uruchamia aplikację, jakie konektory wykorzystuje i co dzieje się w tle.

W kosztorysie oddziel budowę, licencje, przechowywanie oraz obsługę zmian. Portal dla klientów, wewnętrzna aplikacja i agent mogą być rozliczane inaczej. Jedna kwota „za Power Platform” bez założeń utrudni porównanie ofert i późniejsze rozszerzenie zakresu.

W modelowym procesie 200 wniosków wymaga dziś po 8 minut obsługi, czyli 1600 minut miesięcznie. Po zmianie zakładasz po 3 minuty na wniosek i dodatkowe 200 minut na wyjątki: łącznie 800 minut. Hipoteza korzyści wynosi 800 minut, czyli 13 godzin i 20 minut. To umowny rachunek do zweryfikowania w pilotażu, nie obietnica wyniku ani historia klienta.

Zmierz również czas pracowników zgłaszających sprawy. Jeżeli finanse zyskają godzinę, a reszta zespołu poświęci dodatkowo dwie na poprawianie formularza, proces nie został usprawniony. Oceniaj całość od potrzeby do zamknięcia sprawy.

Kiedy dodać funkcję AI

AI Builder pozwala wykorzystać modele AI w Power Apps i Power Automate, między innymi w procesach przetwarzania dokumentów. Dostępność oraz status wydania zależą od funkcji i regionu; część pozostaje w wersji preview. Te rozróżnienia przedstawia dokumentacja AI Builder.

W procesie zakupowym możesz rozważyć odczytanie danych z załącznika, aby pracownik nie przepisywał ich ręcznie. AI Builder jest jednym ze sposobów dodania modelu do takiego procesu, ale najpierw porównaj wynik z dokumentem: kwotę, walutę i dane dostawcy. Nie pozwól, aby samo rozpoznanie tekstu oznaczało zgodę na wydatek. Ocena poprawności odczytu i decyzja zakupowa mają innych właścicieli oraz inne konsekwencje błędu.

Przygotuj próbkę różnych dokumentów, również słabo czytelnych i niekompletnych. Ustal, kiedy wynik trafia do sprawdzenia, a kiedy system może go wykorzystać w kolejnym kroku. Zmierz czas kontroli: jeśli pracownik musi ponownie przeczytać wszystko, korzyść może być mniejsza od oczekiwanej.

Oddziel również AI pomagającą twórcy zbudować aplikację od AI działającej wewnątrz gotowego procesu. Pierwsza wymaga odbioru wygenerowanej konfiguracji, druga stałego sprawdzania wyników na nowych danych. Każda może mieć inny zakres licencji i koszt użycia. Zapisz te założenia przed dodaniem funkcji do produkcji.

Jak przeprowadzić odbiór pilotażu

Wybierz jeden zespół i reprezentatywne wnioski, w tym odrzucenie, korektę oraz zastępstwo. Ustal kryteria przed pokazem końcowym. Dzięki temu odbiór dotyczy rzeczywistego działania, a nie tylko zgodności kolorów i układu pól.

Próba	Warunek przyjęcia	Właściciel oceny
Zwykły wniosek	Trafia do właściwej osoby i kończy się właściwym statusem	Właściciel procesu
Zgłoszenie niepełne	Użytkownik rozumie, co poprawić	Przedstawiciel pracowników
Ponowienie operacji	Nie tworzy podwójnej sprawy	Twórca i odbiorca biznesowy
Dostęp ograniczony	Nie ujawnia cudzych danych	Administrator i właściciel danych
Awaria integracji	Ma czytelny stan i drogę obsługi	Osoba utrzymująca rozwiązanie
Zmiana konfiguracji	Przechodzi kontrolę przed produkcją	Właściciel wdrożenia

Po pilotażu zapisz, kto przyjmuje zgłoszenia i zatwierdza zmiany. Nowe pole, dodatkowy status albo agent odpowiadający o wnioskach może wpływać na wcześniejsze reguły. Wracaj do prób związanych ze zmienionym obszarem, zamiast uznawać pierwszy odbiór za bezterminową gwarancję jakości.

Jeżeli największą luką jest dziś przekazywanie spraw i obsługa wyjątków, przeczytaj jak wykorzystać Power Automate. Narzędzia powinny tworzyć spójny system pracy firmy, w którym każda sprawa ma dane, właściciela i jednoznaczny wynik.

Na najbliższy warsztat przynieś trzy zakończone sprawy: zwykłą, odrzuconą i poprawianą. Odtwórz ich drogę oraz decyzje. Na tej podstawie wybierz pierwszy składnik Power Platform i zapisz warunek, który ma spełnić w próbie.