Start · Rozwiązania · Zakupy
Rozwiązanie · ZakupyWniosek w Teams, akceptacja w Teams, zamówienie w SAP tworzy robot, status widzi każdy
Wnioski zakupowe i akceptacje zamówień bez e‑maili
Pracownicy składają wniosek w Teams, właściciele budżetów decydują w aplikacji Approvals z przypomnieniami i zastępstwami, a robot tworzy zamówienie w SAP i odsyła jego numer.
Streszczenie dla zarządu
Wnioski zakupowe giną między skrzynkami, akceptującymi i kupcami. Koniec z przepisywaniem ich do ERP.
Ścieżka użytkownika nie opuszcza Microsoft Teams.
Czas od wniosku do zamówienia skraca się do czasu decyzji akceptującego: modelowo jeden do dwóch dni roboczych zamiast pięciu do dziewięciu.
SAP S/4HANA (zamówienia przez BAPI); rejestr wniosków na SharePoint (Microsoft Lists)
Problem biznesowy
Proces zakupowy
Wniosek zakupowy istnieje po to, żeby ktoś odpowiedzialny za budżet powiedział „tak”, zanim firma zaciągnie zobowiązanie. Zasada jest słuszna, narzędzia rzadko. Wniosek to formularz w Excelu, akceptacja to odpowiedź w Outlooku, a zamówienie wpisuje do systemu ERP kupiec. Między planistą a numerem zamówienia wniosek zmienia właściciela od czterech do sześciu razy, za każdym razem e‑mailem.
Wnioskujący czekają i dzwonią do kupca. Akceptujący dostają wnioski pomiędzy zaproszeniami na spotkania, bez informacji o pozostałym budżecie. Kupcy rano ponaglają akceptujących, a po południu przepisują ich decyzje. Finanse widzą zaciągnięte zobowiązanie dopiero wtedy, gdy przychodzi faktura.
Przy większej skali pęknięcia się poszerzają: trzy zakłady czytają limity akceptacji na trzy sposoby, zastępstwa na czas urlopu ustala się na czacie, a na pytanie, kto zaakceptował, kiedy i w jakim limicie, odpowiada przeszukiwanie skrzynki. Pilne części zamawia się telefonicznie, a zamówienie utworzone po dostawie jest zamówieniem, którego księgowość zobowiązań nie ma jak dopasować.
Jak to wygląda dzisiaj
- CzłowiekWnioskujący wypełnia formularz w Excelu, dołącza ofertę i wysyła ją e‑mailem do właściciela MPK
- OczekiwanieWniosek leży w skrzynce akceptującego przez kilka dni; powyżej limitu kierownika trafia do dyrektora zakładu i czeka ponownie
- CzłowiekAkceptujący odpisuje „OK” albo zadaje pytanie; odpowiedź zakłada nowy wątek, a załącznik ginie
- CzłowiekKupiec zbiera zaakceptowane e‑maile w folderze i przepisuje każdy z nich do SAP ME21N
- Ryzyko błęduWnioski zaakceptowane powyżej limitu albo przez niewyznaczonego zastępcę wychodzą na jaw przy fakturze, jeśli w ogóle
- OczekiwanieWnioskujący pyta o numer zamówienia na czacie; pilne części zamawia się telefonicznie, a zamówienie powstaje później
Dlaczego obecny proces kosztuje więcej, niż widać
Najdroższa część tego procesu nie ma własnej pozycji kosztowej.
- Przepisywanie to strata widoczna, ponaglanie jest większe. Kupiec obsługujący pięćdziesiąt wniosków tygodniowo poświęca część każdego dnia na przypominanie akceptującym, czego nikt nigdzie nie odnotowuje.
- Spóźnione zamówienia oznaczają spóźnione dostawy: przekładnia zaakceptowana w czwartek zamiast w poniedziałek to albo linia stojąca przez weekend, albo dopłata za transport ekspresowy.
- Zaciągnięte zobowiązania pozostają dla finansów niewidoczne aż do faktury, więc miesięczny przegląd kosztów patrzy na to, co wydano, a nie na to, co zostało obiecane.
- Limity akceptacji są zapisane w podpisanej polityce, ale skrzynka pocztowa ich nie egzekwuje; przekroczenia znajduje próba audytora, a zamówienia telefoniczne rodzą zamówienia tworzone po fakcie, których nie da się dopasować.
Koszt zaniechania
Kupcy dalej będą ponaglać, zakłady dalej będą płacić za transport ekspresowy części zaakceptowanych za późno, a zamówienia tworzone po fakcie dalej będą trafiać do księgowości zobowiązań. Odpowiedzią na kolejny wzrost będzie siódmy kupiec, który odziedziczy ten sam folder.
Po cichu rośnie za to ekspozycja na ryzyko kontroli. Polityka istnieje jako intencja, a faktyczną kontrolą jest ten, kto akurat przeczyta wątek. Wniosek zaakceptowany powyżej limitu przez niewłaściwą osobę zostaje niezauważony aż do próby audytora, a naprawa pochłania więcej czasu kierownictwa, niż kosztowałby cały przepływ.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Producent opakowań z trzema zakładami w Europie Środkowej, 900 pracowników, SAP S/4HANA, Microsoft 365 E3 i sześciu kupców w centralnym dziale zakupów.
1 100 wniosków zakupowych miesięcznie: około 70% to części zamienne, materiały eksploatacyjne i usługi poniżej progu działowego, 25% przekracza próg i wymaga drugiego poziomu akceptacji, 5% to inwestycje poza zakresem; jedna trzecia dotyczy pozycji katalogowych objętych umową.
Formularz w Excelu krąży e‑mailem, akceptacje wracają jako odpowiedzi, kupcy przepisują zaakceptowane wnioski do ME21N, a jeden z nich prowadzi w Excelu listę spraw otwartych.
Około osiemnastu minut obsługi i ponaglania na wniosek, rozłożone na wnioskującego, akceptującego i kupca; od pięciu do dziewięciu dni roboczych od wniosku do numeru zamówienia; w modelowanym przypadku co piąte zamówienie powstaje już po zamówieniu towaru.
Formularz wniosku w Teams zasilany danymi podstawowymi z SAP; matryca akceptacji wykonywana przez akceptacje Power Automate w aplikacji Microsoft Teams Approvals, z poziomami sekwencyjnymi, zastępstwami i eskalacją; robot UiPath, który tworzy zamówienie w SAP i odsyła jego numer; rejestr wniosków jako zakładka w Teams.
W modelowanym przypadku czas od wniosku do zamówienia skraca się do czasu decyzji akceptującego, zwykle jednego do dwóch dni roboczych; przepisywanie znika, a czas kupców przechodzi na wybór dostawców i negocjacje. Liczby opisują model, a nie zrealizowany projekt.
Proponowane rozwiązanie
Ścieżka użytkownika nie opuszcza Microsoft Teams. Wnioskujący otwiera aplikację wniosku w zakładce Teams (aplikacja kanwy Power Apps albo Microsoft Forms przy prostszych wnioskach), wybiera MPK, pozycję, ilość, termin potrzeby i dostawcę, dołącza ofertę i wysyła. Wniosek dostaje numer i status w rejestrze, czyli na liście SharePoint pokazanej w tej samej zakładce.
Przepływ w chmurze Power Automate odczytuje matrycę akceptacji, czyli niewielką tabelę, której właścicielem są finanse: MPK do właściciela, próg do drugiego poziomu, zastępstwo dla każdego akceptującego. Akceptacje powstają po kolei: najpierw właściciel MPK, powyżej progu dyrektor zakładu. Akceptujący widzą wniosek w aplikacji Microsoft Teams Approvals oraz w wiadomości z przyciskami akcji w Outlooku, wraz z załącznikiem, kwotą, pozycją budżetu i czterema odpowiedziami: akceptuj, odrzuć, odeślij z pytaniem, przekaż do działu zakupów. Jeśli nikt nie odpowie w wyznaczonym czasie, przepływ przypomina, a następnie oddaje wniosek zastępcy; akceptujący może też przekazać zadanie innej osobie. Każda decyzja zapisuje się w Dataverse i trafia do dziennika audytu Microsoft Purview.
Zaakceptowane wnioski idą do UiPath: przepływ dodaje element do kolejki przez UiPath connector for Microsoft Power Platform (Preview, licencja premium) albo robot pobiera zaakceptowane pozycje z rejestru przez UiPath Integration Service, co pozostawia przepływ na konektorach standardowych. Robot sprawdza dostawcę, pozycję, MPK i cenę wobec danych podstawowych SAP, tworzy zamówienie standardowym interfejsem BAPI, zapisuje w rejestrze numer zamówienia i akceptującego oraz wysyła wnioskującemu wiadomość w Teams. Odrzucenia z SAP trafiają do kupca. Zestaw narzędzi jest celowo mały: żadnego AI do dokumentów, żadnego agenta, żadnego nowego portalu; środowisko, za które firma już płaci, jeden robot nienadzorowany i Orchestrator.
Aplikacja Microsoft Teams Approvals (załączniki, przekazanie zadania, audyt w Purview); akceptacje Power Automate (sekwencyjne, własne odpowiedzi, Teams i Outlook) oraz liczniki czasu; Power Apps i Microsoft Forms w zakładce Teams; Microsoft Lists jako zakładka Teams; kolejki, wyzwalacze i audyt w UiPath Orchestrator; konektory UiPath Integration Service do SAP BAPI oraz Microsoft OneDrive & SharePoint; UiPath connector for Microsoft Power Platform (Preview)
Aplikację wniosku i jej listy referencyjne z SAP, przepływ matrycy akceptacji z progami, zastępstwami, przypomnieniami i eskalacją, rejestr i jego widoki, robota tworzącego zamówienia wraz z walidacją i obsługą błędów, powiadomienia, widoki wydatków oraz instrukcję operacyjną
Tworzenie zamówień i odczyt danych podstawowych w SAP S/4HANA przez aktywności UiPath SAP (BAPI albo SAP GUI, jeśli zespół SAP tak woli); nocny eksport danych podstawowych
Jak działa proces po automatyzacji
- CzłowiekWnioskujący otwiera aplikację wniosku w Teams, wybiera MPK, pozycję, ilość, termin i dostawcę, dołącza ofertę i wysyła
- AutomatyzacjaPrzepływ nadaje wnioskowi numer w rejestrze, odczytuje matrycę akceptacji i tworzy pierwszą akceptację z kwotą, pozycją budżetu i załącznikiem
- CzłowiekWłaściciel MPK akceptuje, odrzuca albo odsyła wniosek w aplikacji Microsoft Teams Approvals; powyżej progu dochodzi drugi akceptujący
- AutomatyzacjaJeśli akceptujący nie odpowie w uzgodnionym czasie, przepływ przypomina, a potem oddaje wniosek wskazanemu zastępcy
- SystemRobot pobiera zaakceptowany wniosek z kolejki Orchestratora, sprawdza dostawcę, pozycję, MPK i cenę wobec danych podstawowych SAP, tworzy zamówienie standardowym interfejsem BAPI i zapisuje w rejestrze numer zamówienia, akceptującego oraz znacznik czasu
- AutomatyzacjaWnioskujący dostaje w Teams wiadomość z numerem zamówienia; kupiec widzi wyłącznie odrzucenia z SAP i wnioski przekazane do zakupów; resztę pokazuje zakładka według statusu
Model współpracy człowieka z automatyzacją
Automatyzacja obsługuje
- Nadawanie numerów, kierowanie wniosków i kolejność akceptacji wynikającą z matrycy
- Przypomnienia, przekazanie do zastępstwa i zapis audytowy każdej decyzji
- Kontrolę danych podstawowych SAP, tworzenie zamówień i aktualizację statusu w Teams
Ludzie decydują o
- Tym, czy kupować: właściciel MPK, a powyżej progu drugi akceptujący, w Teams
- Wnioskach przekazanych do działu zakupów lub odrzuconych przez SAP: pozycje pozakatalogowe powyżej limitu, nowi dostawcy, błędy danych podstawowych
- Samej matrycy: progi, właściciele i zastępstwa pozostają w gestii finansów i zakupów
Przed i po
Systemy i integracje
Każdą pozycję da się sprawdzić w dokumentacji producenta. Klasa dowodu jest podana przy każdej.
Wejścia
- formularz wniosku Power Apps w Teams (albo Microsoft Forms)
- załączone oferty
- dane podstawowe z SAP
Warstwa automatyzacji
- przepływy w chmurze Power Automate
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service (SAP BAPI, OneDrive & SharePoint)
Systemy docelowe
- SAP S/4HANA (zamówienia przez BAPI)
- rejestr wniosków na SharePoint (Microsoft Lists)
Punkty styku z człowiekiem: aplikacja Microsoft Teams Approvals; wiadomości z przyciskami akcji w Outlooku; wiadomości na czacie do wnioskującego; zakładka ze statusem wniosków w Teams
Wykorzystane technologie
całe doświadczenie użytkownika: wniosek, decyzja, rejestr, status
Amatryca akceptacji, poziomy sekwencyjne, własne odpowiedzi, przypomnienia, eskalacja
Aformularz wniosku z listami MPK, katalogu i dostawców
Atworzenie zamówienia w SAP przez BAPI; kolejka, ponowienia, poświadczenia, audyt; wyzwalacz na liście jako przekazanie niezależne od licencji
Abezpośrednie przekazanie z przepływu do Orchestratora; licencja premium
Asystem źródłowy dla zamówień i danych podstawowych
AIlustracyjny model ekonomiczny
Arytmetyka jest jawna, żeby dało się z nią spierać.
Osiemnaście minut na wniosek to suma trzech ról w średnich firmach produkcyjnych, jakie znamy, podana jako przedział ilustracyjny, a nie pomiar u klienta: około pięciu minut po stronie wnioskującego, cztery po stronie akceptującego i dziewięć po stronie kupca na ponaglanie, sprawdzenie, przepisanie do ME21N i odpowiedzi na pytania. 28 € to mieszany pełny koszt godziny pracy kupców, planistów i kierowników w Europie Środkowej. Pokazujemy uwolniony czas, a nie zredukowane etaty.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Czas od wniosku do zamówienia skraca się do czasu decyzji akceptującego: modelowo jeden do dwóch dni roboczych zamiast pięciu do dziewięciu
- Kupcy przestają przepisywać, a ich czas przechodzi na wybór dostawców i pracę nad ich wynikami
- Limity akceptacji, zastępstwa i reguły drugiego poziomu stosuje przepływ, za każdym razem tak samo
- Wnioskujący widzą status i numer zamówienia w Teams, bez pytania; zaciągnięte zobowiązania są widoczne na każdym MPK już w chwili akceptacji
Perspektywa zarządu
- Jeden rejestr z każdym wnioskiem, akceptującym, znacznikiem czasu i numerem zamówienia, filtrowany w Teams i gotowy dla audytora
- Dyscyplina akceptacji, która przetrwa urlopy i reorganizacje, bo matryca akceptacji jest zwykłą tabelą
- Zobowiązania znane przed fakturami: przegląd kosztów patrzy na wydatki zaakceptowane, nie tylko zaksięgowane
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Audytor powinien móc odtworzyć każdą decyzję.
- Robot korzysta z dedykowanego konta SAP ograniczonego do zakupów; jego poświadczenia leżą w magazynie poświadczeń Orchestratora (albo w Azure Key Vault, jeśli firma go używa), nigdy przy człowieku
- Akceptacje zapisują się w Dataverse i podlegają audytowi w Microsoft Purview: kto zaakceptował, kiedy i po jakim przekazaniu zadania
- Tożsamości akceptujących pochodzą z Microsoft Entra ID; matryca akceptacji ma właściciela w finansach, zmiana progu sama wymaga akceptacji, nikt nie akceptuje własnego wniosku, a robot nie akceptuje niczego
- Nic z tego nie jest osiągalne spoza Państwa katalogu: wnioski, załączniki i rejestr leżą w środowisku Microsoft 365 w granicach EU Data Boundary, a Orchestrator w tenancie UiPath Automation Cloud w regionie UE; żaden model AI nie bierze w tym udziału
Dlaczego teraz
Prowadzenie akceptacji e‑mailem kosztuje modelowe 9 240 € miesięcznie w samym czasie pracy, zanim doliczymy transport ekspresowy i zamówienia tworzone po fakcie
Wraz z obowiązkowym e‑fakturowaniem w Polsce (KSeF) faktury wpływają jako dane ustrukturyzowane; automatyczne dopasowanie opłaca się dopiero wtedy, gdy zamówienie istnieje przed fakturą, a ten obieg to gwarantuje
Aplikacja Approvals, akceptacje Power Automate i przekazanie do UiPath (konektor Power Platform w wersji Preview albo wyzwalacze Integration Service) sprawiają, że jedynym pisanym elementem pozostaje logika zapisu do SAP
Role zarządcze, których to dotyczy
Zobowiązania stają się widoczne w chwili akceptacji, a nie dopiero przy fakturze, a polityka akceptacji jest egzekwowana, nie zakładana
Kupcy przestają przepisywać i ponaglać, a rejestr pokazuje każdy otwarty wniosek i osobę, na której się zatrzymał
Części są zamawiane wtedy, gdy zakład ich potrzebuje, a numer zamówienia trafia do planisty w Teams, a nie na fakturę
Częste pytania i zastrzeżenia
Warto ją zachować. Decyzja zapada raz, w Teams, a robot wykonuje następnie krok zwolnienia w SAP własnym kodem zwalniania i wpisuje do zamówienia nazwisko akceptującego oraz znacznik czasu. SAP pozostaje systemem źródłowym, a Teams staje się jego interfejsem.
Wniosku w aplikacji Approvals nie da się zasypać wątkiem; niesie ze sobą załącznik i pozycję budżetu, a po upływie uzgodnionego czasu eskaluje się sam. Akceptujący widzą własną kolejkę, a dział zakupów widzi każdą eskalację w rejestrze.
Nie dla formularza, akceptacji ani rejestru, bo działają na uprawnieniach zawartych w Microsoft 365. UiPath connector for Microsoft Power Platform jest w wersji Preview i wymaga licencji premium; bez niego robot pobiera zaakceptowane wnioski z rejestru przez UiPath Integration Service, a przepływ pozostaje na konektorach standardowych.
Kiedy to nie jest właściwe rozwiązanie
- Wnioskujący pracują już w SAP (ME51N lub Ariba Guided Buying) z działającym obiegiem zwalniania; problemem jest wtedy przyjęcie narzędzia przez ludzi, a nie brak interfejsu
- Mniej niż kilkaset wniosków miesięcznie w jednej lokalizacji, gdzie wystarczy szablon Approvals bez robota
- Polityka akceptacji nie jest ustalona: progi, właścicieli i zastępstwa trzeba najpierw wyznaczyć
Pytanie na najbliższe posiedzenie
Kto potrafi bez przeszukiwania skrzynki powiedzieć, które wnioski i na kogo czekają, i ile dni mija w naszych zakładach od wniosku zakupowego do zamówienia?
Podejście wdrożeniowe
Wdrożenie idzie etapami, bo tak da się je zatrzymać w każdej chwili.
Dostarczamy
- Rozpoznanie typów wniosków, progów, matrycy akceptacji i zastępstw
- Aplikację wniosku w Teams wraz z listami referencyjnymi z SAP oraz przepływ akceptacji: poziomy sekwencyjne, własne odpowiedzi, przypomnienia, eskalację do zastępstwa, ślad audytowy
- Robota tworzącego zamówienia, z walidacją, obsługą błędów SAP i numerem zamówienia odsyłanym do Teams
- Rejestr z widokami statusu i wydatków, pilotaż w jednym zakładzie, a następnie wdrożenie z intensywnym wsparciem po starcie (hypercare) i instrukcją operacyjną
Potrzebujemy od Państwa
- Podpisanej polityki akceptacji: progów, właścicieli MPK i zastępstw
- Właściciela procesu w dziale zakupów oraz jednego właściciela MPK gotowego na pilotaż
- Kont SAP dla robota, eksportu danych podstawowych i administratora Microsoft 365
Etapy
Rozpoznanie
Typy wniosków, wolumeny, matryca akceptacji, zastępstwa i wyjątki
Projekt
Formularz, rejestr, progi, czasy eskalacji, przekazanie do UiPath, reguły walidacji w SAP
Budowa i walidacja
Aplikacja wniosku, przepływ akceptacji, robot i integracja z SAP; odtworzenie wniosków z ostatniego kwartału, sprawdzenie liczników czasu i zastępstw, odbiór przez użytkowników
Uruchomienie
Najpierw jeden zakład, kupcy nadzorują zamówienia tworzone przez robota, potem kolejne
Szybki efekt. Nakład pracy zależy od liczby poziomów akceptacji, stanu danych podstawowych SAP stojących za formularzem oraz tego, czy zamówienia w SAP mają strategię zwalniania, którą trzeba zachować.
Wniosek zakupowy żyje w skrzynkach, aż kupiec przepisze go do SAP.
Wystarczy przesłać nam politykę akceptacji i wnioski z jednego miesiąca z jednego zakładu: liczbę, wartości, akceptujących. Odpowiadamy projektem matrycy akceptacji w Teams i czasami obiegu, jakie powinna dawać.
Zaprojektujmy Państwa matrycę akceptacjiTen sam problem ma zwykle sąsiedni proces
Koniec z płaceniem zespołowi finansów za przenoszenie liczb z plików PDF do systemu ERP.
Zobacz rozwiązanie Finanse i księgowośćZablokowane faktury wyjaśnione przed przebiegiem płatnościKoniec z wyjaśnianiem różnic cen i ilości e‑mailami, gdy płatności dla dostawców czekają tygodniami.
Zobacz rozwiązanie ZakupyProcess mining P2P: zakupy poza umową, wskaźnik bezdotykowyNikt nie wie, jaka część zakupów omija umowy i zamówienia ani ile razy wraca faktura. To da się mierzyć co miesiąc.
Zobacz rozwiązanieBranże, w których wdrażamy to najczęściejProdukcja i przemysłUsługi i IT