Start · Rozwiązania · Inne rozwiązania
Rozwiązanie · Inne rozwiązaniaKarta jednorazowa wydana według spisanych reguł i zamknięta, gdy cel się kończy
Karta wirtualna lub zmiana limitu w ciągu godziny
Wnioski o kartę i limit powstają w Teams, są sprawdzane wobec spisanej polityki kartowej, realizowane przez API platformy kartowej i zamykane automatycznie w dniu wygaśnięcia.
Streszczenie dla zarządu
Limity rosną na czas eventu i nigdy nie wracają, a firmowe zakupy ludzie opłacają z własnego konta.
Wniosek zaczyna się tam, gdzie i tak toczy się praca.
Wnioski zgodne z polityką są obsługiwane w ciągu godziny, bo kontrola i praca w portalu przestają czekać na osobę zajętą czymś innym.
platforma kartowa banku przez API wydawcze; rejestr kart; SAP dla MPK
Problem biznesowy
Zarządzanie wydatkami
Program kartowy ma politykę. Mówi ona, kto może mieć kartę, jaki limit obowiązuje na danym szczeblu i które kategorie akceptantów są zablokowane. Czego polityce brakuje, to procesu, który da się odnaleźć. Wnioski o kartę wirtualną albo tymczasowy limit przychodzą mailem do skrzynki skarbu, wiadomością w Teams do osoby, która pomogła poprzednio, albo telefonem z korytarza.
Skarb robi potem za każdym razem to samo: ustala, kto pyta, zgaduje MPK, prosi przełożonego o zgodę, loguje się do portalu banku, zakłada kartę i odsyła dane mailem. Na koniec dopisuje wiersz do rejestru i ma nadzieję, że zapamięta zamknięcie. Wnioskujący czeka dzień lub dwa na pięciominutową czynność, więc najszybszą drogą staje się karta kolegi albo własne pieniądze. Kontrola opuszcza platformę kartową i ląduje w procesie rozliczania wydatków, który widzi zakup dopiero po fakcie.
Powodem, dla którego nic się nie zmienia, jest skala pojedynczej sprawy. Każdy wniosek jest mały, żaden nie uzasadnia projektu, a razem nie należą do nikogo. Tymczasem limity rosną na event i już nie wracają, karty założone dla jednego dostawcy pozostają aktywne, a rejestr w Excelu rozjeżdża się z wyciągiem bankowym wiersz po wierszu.
Jak to wygląda dzisiaj
- CzłowiekKtoś musi dziś zapłacić dostawcy i pisze do skarbu albo prosi kolegę, który ma kartę
- CzłowiekSkarb sprawdza, kto pyta, jakie MPK obowiązuje i czy kwota wygląda rozsądnie
- OczekiwaniePrzełożony dostaje maila z prośbą o potwierdzenie i odpowiada między spotkaniami, czasem następnego dnia
- SystemSkarb loguje się do portalu banku i ręcznie zakłada kartę wirtualną albo podnosi limit
- Ryzyko błęduDane karty wracają mailem albo czatem, gdzie dane płatnicze zostają w historii
- CzłowiekDo rejestru w Excelu trafia wiersz z takim celem, jaki wpisał wnioskujący
- Ryzyko błęduLimit pozostaje podniesiony, a karta otwarta, dopóki ktoś nie zauważy, często dopiero przy rocznym przeglądzie
Dlaczego ten proces kosztuje więcej, niż widać
To nie jest praca, którą ktoś zaplanował.
- Minuty skarbu są tu najmniejszą częścią. Większym kosztem jest ekspozycja: każdy limit podniesiony na event i nigdy nieobniżony to otwarty kredyt, który może wydać phishingowy mail albo jedno nieuważne kliknięcie.
- Karty wydane poza zestawem reguł to odstępstwa od polityki, których nikt nie zaakceptował, niewidoczne, dopóki audytor nie zestawi rejestru z wyciągiem bankowym i nie zobaczy dwóch różnych firm.
- Kto płaci prywatnie, ten przez miesiąc finansuje firmę z własnego konta, a potem składa wniosek o zwrot, który trzeba sprawdzić, zaakceptować, wypłacić i zarchiwizować. Ten wniosek istnieje tylko dlatego, że karta była wolna.
- Dane karty wklejone na czat to dane płatnicze w narzędziu do współpracy, przechowywane tak długo, jak każe polityka retencji, i wyszukiwalne przez wszystkich uczestników rozmowy.
- Gdy specjalisty prowadzącego rejestr nie ma, karty w ogóle nie powstają, a każdy taki tydzień powiększa ekonomię obejść, której polityka miała zapobiegać.
Koszt bezczynności
Otwarty kredyt rośnie tutaj przez nawarstwianie, a nie przez decyzję. Nikt nigdy nie zgadza się, żeby firma niosła większą ekspozycję kartową; ona po prostu rośnie, limit po limicie, bo podniesienie jest wnioskiem, a obniżenie przysługą. Wnioski kartowe idą za eventami, kampaniami, freelancerami i subskrypcjami, a wszystkie cztery rosną szybciej niż dział skarbu, więc kolejka się wydłuża, a razem z nią nawyk płacenia prywatnie.
Powyższe wiersze to część etatowa i najmniej ciekawa. Pojedynczy incydent phishingowy na karcie, której limit podniesiono na targi i nigdy nie obniżono, może kosztować więcej niż rok tego obiegu. Ustalenia audytu w międzyczasie się powtarzają: rejestr nie zgadza się z wyciągiem, akceptacje odstępstw nie są udokumentowane, karty nie są zamykane. Nic z tego nie jest dramatyczne w żadnym pojedynczym dniu, i właśnie dlatego trwa.
Przykładowa organizacja o realnych proporcjach — liczby służą do policzenia sprawy na Waszych danych, nie są wynikiem klienta.
Firma mediowo-eventowa z 900 pracownikami w Polsce, Niemczech i Czechach, prowadząca program kart firmowych w banku, którego platforma kartowa udostępnia API do kart wirtualnych i limitów. Wydatki idą przez SAP Concur, księgi prowadzone są w SAP.
Około 380 wniosków o karty i zmian limitów miesięcznie, głównie na zaliczki eventowe, konta reklamowe, subskrypcje oprogramowania i rezerwacje podróży, obsługiwanych przez trzy osoby w skarbie obok ich pozostałych zadań. Około 140 wniosków o zwrot kosztów miesięcznie to zakupy, które powinny były trafić na kartę firmową.
Wnioski przychodzą mailem, czatem i telefonicznie. Skarb weryfikuje, pyta przełożonego, pracuje w portalu banku, odsyła dane i aktualizuje rejestr w Excelu, którego nikt nie uzgadnia.
Około 26 minut obsługi po stronie skarbu na wniosek, plus dzień lub dwa oczekiwania na pięciominutową czynność i brak wiarygodnego kroku zamknięcia; nikt nie potrafi powiedzieć, ile kart wirtualnych jest dziś otwartych.
Wniosek powstaje w Teams i jest sprawdzany wobec spisanej polityki kartowej. Mieszczący się w niej jest akceptowany automatycznie, o pozostałych decyduje właściciel budżetu. Robot realizuje go przez API platformy kartowej, zapisuje w rejestrze z datą końca i zamyka automatycznie, gdy cel się kończy.
W modelowanym przypadku wnioski zgodne z polityką są obsługiwane w ciągu godziny, każda karta ma datę końca, która jest egzekwowana, a nie pamiętana, a rejestr zgadza się co miesiąc z wyciągiem bankowym. To wielkości modelowe, a nie wynik u klienta.
Proponowane rozwiązanie
Wniosek zaczyna się tam, gdzie i tak toczy się praca. Karta Adaptive Card w Microsoft Teams, udostępniana przez aplikację Workflows, pyta o cel, kwotę, dostawcę, MPK, potrzebny czas i to, czy wystarczy jedno użycie. Reguły spisane z Państwa polityki kartowej sprawdzają wniosek wobec limitów na szczeblu, zablokowanych kategorii akceptantów, maksymalnego czasu i roli wnioskującego. Wewnątrz polityki wniosek jest akceptowany od razu. Poza nią aplikacja Microsoft Teams Approvals stawia go przed właścicielem budżetu, a powyżej progu także przed skarbem, z powodem odstępstwa na karcie.
Pracę w portalu przejmuje robot UiPath. Wywołuje API platformy kartowej przez konektor, który budujemy w UiPath Integration Service Connector Builder. Zakłada kartę jednorazową z zatwierdzonym limitem i datą ważności albo nakłada limit tymczasowy. Rekord trafia do rejestru kart w UiPath Data Fabric: cel, właściciel, MPK, limit, data końca, numer akceptacji. Wnioskujący odbiera kartę w aplikacji wydawcy. Numery kart nigdy nie wędrują przez Teams ani maila, a robot nie musi ich odczytywać.
To, co dzisiaj zależy od pamięci, staje się zadaniem harmonogramu. W dniu końca albo po jednorazowym użyciu robot zamyka kartę lub przywraca pierwotny limit, informuje właściciela i aktualizuje rejestr. Miesięczny ekstrakt zasila Power BI i uzgodnienie z wyciągiem bankowym, więc otwarta ekspozycja jest liczbą do odczytania. Nie ma tu żadnego AI: regułami jest polityka, spisana i wersjonowana.
Karty Adaptive Card przez aplikację Workflows w Microsoft Teams (Power Automate); aplikacja Microsoft Teams Approvals z audytem w Purview; kolejki, wyzwalacze czasowe, magazyn poświadczeń i audyt zadań w UiPath Orchestrator; encje UiPath Data Fabric dla rejestru kart; UiPath Integration Service Connector Builder
Kartę wniosku i jej walidację, zestaw reguł polityki z limitami, czasami, kategoriami i progami, roboty wydające karty i zmieniające limity, zadanie wygaszania i przywracania, model rejestru kart, ekstrakt uzgodnieniowy, widok ekspozycji w Power BI oraz instrukcję operacyjną dla skarbu
API wydawcze platformy kartowej przez konektor zbudowany w UiPath Integration Service Connector Builder, ograniczony do założenia, ustawienia limitu i zamknięcia; odczyt MPK z SAP; miesięczny ekstrakt wyciągu do uzgodnienia
Jak działa proces po automatyzacji
- CzłowiekWnioskujący wypełnia wniosek kartowy na karcie Adaptive Card w Teams: cel, kwota, dostawca, MPK, czas
- AutomatyzacjaReguły sprawdzają wniosek wobec polityki kartowej: limit na szczeblu, kategoria akceptanta, maksymalny czas, rola wnioskującego
- CzłowiekWnioski poza polityką idą do właściciela budżetu w aplikacji Microsoft Teams Approvals, a powyżej progu do skarbu
- AutomatyzacjaRobot zakłada kartę wirtualną albo nakłada limit tymczasowy przez API platformy kartowej
- AutomatyzacjaRejestr zapisuje cel, właściciela, MPK, limit, datę końca i numer akceptacji
- SystemWnioskujący dostaje powiadomienie i odbiera kartę w aplikacji wydawcy; przez Teams nie przechodzi żaden numer karty
- AutomatyzacjaW dniu końca albo po jednorazowym użyciu robot zamyka kartę lub przywraca pierwotny limit
- AutomatyzacjaMiesięczny ekstrakt uzgadnia rejestr z wyciągiem bankowym i zasila widok ekspozycji w Power BI
Model współpracy człowieka z automatem
Automatyzacja obsługuje
- Kontrolę limitu, czasu, kategorii akceptanta i roli wnioskującego wobec polityki
- Akceptację wniosków mieszczących się w spisanej polityce, z zapisem zastosowanej reguły
- Wydanie karty, zmianę limitu, zamknięcie i przywrócenie limitu przez API platformy kartowej
- Rejestr, powiadomienie wnioskującego i miesięczny ekstrakt uzgodnieniowy
Ludzie decydują o
- Każdym wniosku, którego polityka nie obejmuje, na poziomie właściciela budżetu i skarbu
- Zmianach samych reguł: limitów, czasów, zablokowanych kategorii i progów
- Odwołaniu karty przy podejrzeniu nadużycia, w każdej chwili i bez udziału robota
- Wyjątkach, które podnosi miesięczne uzgodnienie
Przed i po
Systemy i integracje
Tam, gdzie wystarczy reguła, nie używamy modelu. Tam, gdzie potrzebny jest osąd, decyduje człowiek.
Wejścia
- karta wniosku w Microsoft Teams
- skrzynka współdzielona skarbu w Exchange Online dla wniosków nadal przychodzących mailem
- polityka kartowa i lista MPK
Warstwa automatyzacji
- UiPath Orchestrator
- UiPath Robots
- UiPath Integration Service (Connector Builder)
- UiPath Data Fabric
Systemy docelowe
- platforma kartowa banku przez API wydawcze
- rejestr kart
- SAP dla MPK
- SAP Concur po stronie rozliczeń
Punkty styku z człowiekiem: aplikacja Microsoft Teams Approvals dla odstępstw; odwołanie karty przez skarb z poziomu rejestru; miesięczny przegląd uzgodnienia
Wykorzystane technologie
formularz wniosku, odpowiedź reguł i komunikaty statusu
Adecyzje właściciela budżetu i skarbu wobec wniosków poza polityką, z audytem w Microsoft Purview
Akonektor do API wydawczego platformy kartowej, ograniczony do założenia, limitu i zamknięcia
Azadania wydawania i wygaszania, kolejki, ponowienia, magazyn poświadczeń i dziennik zadań
Arejestr kart: cel, właściciel, MPK, limit, data końca, numer akceptacji
Aotwarte karty, otwarty kredyt, odstępstwa według działów i różnica rejestr–wyciąg
Alimity na szczeblach, maksymalne czasy, zablokowane kategorie akceptantów, progi akceptacji
CIlustracyjny model ekonomiczny
Zacznijcie od kwestionowania założeń.
Poniższa arytmetyka to podłoga, a nie uzasadnienie korzyści, bo ekspozycja, uniknięte straty z nadużyć i czas oczekiwania pracowników zostały pominięte; żadnego z nich nie da się uczciwie wycenić bez Państwa własnej historii strat. Kalkulator liczy wyłącznie minuty skarbu, a jego wolumen to automatyzowalny udział 0,7 z 380 wniosków, a nie cała kolejka, po 26 minut i 41 € za godzinę w pełnym koszcie. Obok stoją uniknięte wnioski o zwrot kosztów: 140 wniosków × 14 minut × 0,6 to około 20 godzin miesięcznie pracy księgowości po 33 €, jakieś 7 900 € rocznie, co daje łączną pulę rzędu 64 500 €. Nic tutaj nie zostało zmierzone u klienta.
Policz to na swoich danych
Szacunek ilustracyjny na podstawie Twoich danych. To model uwolnionej przepustowości, nie obietnica oszczędności.
Korzyści biznesowe
- Wnioski zgodne z polityką są obsługiwane w ciągu godziny, bo kontrola i praca w portalu przestają czekać na osobę zajętą czymś innym
- Otwarty kredyt maleje i pozostaje znany, bo każda karta ma datę końca, a każdy limit tymczasowy przywraca zadanie, nie pamięć
- Wniosków o zwrot kosztów ubywa, bo karta firmowa staje się najszybszym, a nie najwolniejszym sposobem zapłaty
- Dane płatnicze znikają z maila i czatu: karta jest doręczana w aplikacji wydawcy, a rejestr trzyma wyłącznie identyfikatory
- Akceptacje odstępstw stają się dowodem, zapisanym przy wniosku razem ze złamaną regułą i osobą, która ją przyjęła
- Skarb przestaje być ludzkim interfejsem między pracownikami a bankiem i może zająć się gotówką zamiast administracją kartową
Perspektywa zarządu
- Otwarta ekspozycja staje się odpowiedzią na minutę: ile kart żyje, czyje są, ile mogą wydać i kiedy wygasają
- Wnioski liczone według działów i celów pokazują, gdzie polityka pasuje do rzeczywistości, a gdzie jest omijana
- Rejestr i wyciąg bankowy zbiegają się, więc miesięczne uzgodnienie zamienia się ze śledztwa w kontrolę
- Odpowiedzialność jest jawna: skarb ma reguły, właściciele budżetów mają odstępstwa, a robot wykonuje pracę w portalu pod jednym i drugim
Wpływ na KPI zarządu
Bezpieczeństwo i nadzór
Audytor powinien móc odtworzyć każdą decyzję.
- Numery kart nigdy nie opuszczają platformy wydawcy. Robot pracuje na identyfikatorze karty i czterech ostatnich cyfrach, a wnioskujący odbiera kartę w aplikacji wydawcy
- Poświadczenia API leżą w magazynie poświadczeń Orchestratora albo w Azure Key Vault, ograniczone do założenia, ustawienia limitu i zamknięcia, bez prawa odczytu pełnych danych karty
- Wnioskujący nigdy nie może zaakceptować własnego wniosku, a skarb może odwołać każdą kartę z poziomu rejestru, nie czekając na zadanie
- Każda zmiana reguły jest wersjonowana, a każde wydanie, zmiana limitu i zamknięcie trafiają do dziennika Orchestratora wraz z numerem akceptacji
- Przetwarzanie działa w regionie EU UiPath Automation Cloud i w granicy Microsoft 365 EU Data Boundary; dane osobowe ograniczają się do tożsamości wnioskującego i MPK
Dlaczego teraz
Platformy kartowe, które kiedyś oferowały wyłącznie portal, udostępniają dziś API wydawcze i dopiero to czyni drogę od wniosku do karty automatyzowalną; warto to najpierw potwierdzić z bankiem
Audytorzy coraz częściej proszą o rejestr kart obok wyciągu bankowego, a rejestr prowadzony w Excelu nie odpowiada na to pytanie w żadną stronę
Sama obsługa po stronie skarbu to w modelu około 4 700 € miesięcznie i jest w tym rachunku pozycją najmniejszą; ekspozycja narastająca w czasie bezczynności waży więcej
Role, których to dotyczy
Wydatki kartowe opierają się na regułach, otwarta ekspozycja jest znana w każdej chwili, a wnioski o zwrot kosztów za zakupy firmowe przestają być normą
Zespół przestaje pracować w portalu, rejestr zgadza się z bankiem, a każdy limit ma datę końca, która sama się egzekwuje
Drobne zakupy przechodzą na kontrolowaną ścieżkę kartową, zamiast całkowicie znikać z pola widzenia zakupów
Częste pytania i zastrzeżenia
Pozwala, zespołowi skarbu. Luka to wszystko wokół: wniosek, kontrola polityki, akceptacja, rejestr i zamknięcie. Portal nie robi żadnej z tych rzeczy, więc dzieją się ręcznie albo wcale.
Automatycznie akceptowane są wyłącznie wnioski mieszczące się w spisanej polityce, z tymi samymi limitami, które skarb nałożyłby ręcznie. Każdy jest zapisany z regułą, która go przepuściła, a każdą kartę da się odwołać w chwilę.
My również nie. Teams niesie wniosek i akceptację. Sama karta jest doręczana przez aplikację wydawcy i nigdy nie pojawia się na czacie, co i tak jest poprawą wobec dzisiaj.
Kiedy to nie jest właściwe rozwiązanie
- Platforma kartowa nie ma API wydawczego; pracę w portalu trzeba by prowadzić przez interfejs, co jest możliwe, ale mniej stabilne i trudniejsze do obrony przed audytorem
- Platforma do zarządzania wydatkami z własnym obiegiem wniosków jest już kupiona i używana; praca leży wtedy w adopcji, a nie w drugim obiegu
- Mniej niż kilkadziesiąt wniosków miesięcznie, gdzie spisana polityka i prosty formularz w Teams usuną już większość czekania
Pytanie na najbliższe posiedzenie
Czy ta firma zauważyłaby kartę wirtualną, która przeżyła swój cel, a jeśli tak, to w którym miesiącu i w czyim raporcie?
Podejście wdrożeniowe
Zaczynamy od jednego wycinka procesu i rozszerzamy dopiero po dowodzie.
Dostarczamy
- Politykę kartową zamienioną w testowalny zestaw reguł, uzgodniony punkt po punkcie ze skarbem
- Konektor do API wydawczego Państwa platformy kartowej, zbudowany i przetestowany na jej środowisku testowym
- Kartę wniosku w Teams, jej walidację i ścieżkę odstępstw do aplikacji Approvals
- Roboty wydające, zmieniające limity i wygaszające, z ponowieniami i obsługą błędów
- Model rejestru kart, miesięczny ekstrakt uzgodnieniowy i widok ekspozycji w Power BI
- Pilotaż w dziale generującym najwięcej wniosków, potem rozszerzanie regułami, a nie kodem
Potrzebujemy od Państwa
- Polityki kartowej na piśmie i właściciela po stronie skarbu, który rozstrzygnie pytania o reguły
- Dostępu do API z Państwa banku, z poświadczeniami testowymi i zakresami, których potrzebuje robot
- Wniosków kartowych z jednego miesiąca oraz obecnego rejestru
- Listy MPK i progów akceptacji, które mają obowiązywać powyżej polityki
Etapy
Rozpoznanie
Polityka i jeden miesiąc wniosków; większość okazuje się wariantami pięciu celów
Reguły
Limity na szczeblach, maksymalne czasy, zablokowane kategorie, progi i granica akceptacji automatycznej
Budowa
Konektor, karta wniosku, roboty wydające i wygaszające, rejestr, ekstrakt uzgodnieniowy
Walidacja
Testy wydania, zmiany limitu i zamknięcia na środowisku testowym, następnie odbiór przez skarb
Pilotaż
Jeden dział o dużym wolumenie równolegle ze starą drogą
Rozwój
Kolejne działy i kraje, przez dopisywanie reguł, a nie obiegów
Szybki efekt. Nakład pracy zależy niemal wyłącznie od API platformy kartowej i jej środowiska testowego; część dotycząca Teams i reguł jest niewielka, a najdłuższa bywa zwykle dyskusja o polityce.
Limit podniesiony na targi zeszłej wiosny nadal jest podniesiony.
Wystarczy przesłać politykę kartową i wnioski kartowe z ostatniego miesiąca. Odsyłamy udział, który zostałby wydany w ciągu godziny na Państwa własnych regułach, oraz te wnioski, które polityka by zatrzymała.
Wskażmy karty do zamknięcia już dziśTen sam problem ma zwykle sąsiedni proces
Wydatki kartowe są dopasowywane, kodowane i sprawdzane tygodnie po księgowaniu, a paragony ściga się bez końca.
Zobacz rozwiązanie Inne rozwiązaniaZapotrzebowania w Teams, zamówienie tego samego dniaDroga zgodna z procedurą jest wolniejsza niż wiadomość na czacie, więc najpierw się zamawia, a papiery robi później.
Zobacz rozwiązanie Inne rozwiązaniaAkceptacja wydatków w Teams z gotową kontrolą politykiAkceptacje czekają w poczcie do końca miesiąca, a pytanie o politykę pada już po kliknięciu.
Zobacz rozwiązanieBranże, w których wdrażamy to najczęściejProdukcja i przemysłUsługi i IT