Projekt matrycy zatwierdzeń zaczyna się od progów, zapasowych zatwierdzających, zastępstw i eskalacji, aby ekrany odzwierciedlały rzeczywistą ścieżkę decyzji.
Czysty ekran może ukrywać chaotyczny proces. Jeśli logika zatwierdzania nie zostanie najpierw zdefiniowana, użytkownicy mogą widzieć przyciski Zatwierdź i Odrzuć, a mimo to nie wiedzieć, kto ma działać, kiedy ma działać ani co stanie się potem.
To zamieszanie pojawia się szybko w rzeczywistej pracy. Ktoś wysyła wniosek, trafia on do aplikacji, a pierwsze pytanie brzmi: „Czy to idzie do menedżera, działu finansów, czy do obu?” Ekran wygląda na skończony, ale brakuje ścieżki decyzyjnej.
Dzieje się tak, ponieważ ekrany upraszczają wygląd reguł. Formularz może pokazywać status, komentarze i przyciski akcji, ale nie zgadnie prawdziwej matrycy zatwierdzania stojącej za procesem. Jeśli w firmie są limity kwotowe, reguły działowe lub tymczasowi zastępcy, UI zaczyna się psuć, gdy pojawiają się takie przypadki.
Często wystarczy jeden wyjątek, żeby praca wyleciała poza aplikację. Zwykle zatwierdzenia idą do szefa działu, chyba że zgłoszenie jest pilne, przekracza określoną kwotę lub zatwierdzający jest na urlopie. Jeśli taki przypadek nie został zmapowany, ludzie wracają do e-maili, czatów lub arkuszy kalkulacyjnych.
Pojawia się wtedy większy problem: każdy zespół zaczyna stosować własną wersję reguł. Operacje wysyłają wniosek w jeden sposób, finanse w inny, a wsparcie traktuje wyjątki inaczej niż HR. Aplikacja staje się wspólnym ekranem dla niespójnych decyzji zamiast wspólnym procesem.
Zwykle łatwo zauważyć ostrzegawcze sygnały:
Aktualizacje polityki szybko uwidaczniają tę słabość. Kiedy logika żyje w ekranie zamiast w jasnych regułach workflow, każda zmiana progu lub roli zamienia się w przebudowę UI. To spowalnia zespoły, generuje błędy i powoduje utratę zaufania użytkowników.
Ekran powinien odzwierciedlać ścieżkę decyzji, a nie jej definiować. Gdy matryca jest najpierw jasna, UI staje się prostsze, stabilniejsze i łatwiejsze w użyciu.
Zacznij od logiki decyzyjnej, nie od ekranu. Solidna matryca zatwierdzeń zaczyna się jako prosta tabela pokazująca, kto może zatwierdzać co, w jakich warunkach i co się dzieje, gdy ktoś jest niedostępny. Jeśli ta logika jest nieostra, nawet dopracowany interfejs będzie mylić ludzi.
Dla każdego typu wniosku zmapuj poziomy zatwierdzeń w kolejności. Zapisz rolę, która jest właścicielem każdego kroku i co ten krok pozwala: zatwierdzić, odrzucić, przejrzeć lub odesłać do poprawy. Role działają lepiej niż imiona, bo ludzie się przemieszczają, zespoły się zmieniają, a proces nadal musi działać.
Następnie zdefiniuj reguły, które zmieniają trasę. Kwota jest oczywistym wyzwalaczem, ale rzadko jedynym. Reguły workflow często zależą od regionu, działu, typu dostawcy, kategorii wniosku lub poziomu ryzyka. Ta sama kwota może być rutynowa w jednym zespole i wrażliwa w innym.
Absencje też potrzebują reguł. Jeśli główny zatwierdzający jest nieobecny, kto przejmuje natychmiast? Jeśli zastępca jest tymczasowy, jakie daty obowiązują? Bez tego wnioski stoją, bo nikt nie wie, kto jest właścicielem w tym tygodniu.
Limity czasowe są równie ważne. Zdecyduj, co się dzieje, gdy wniosek nie otrzyma odpowiedzi. Możesz wysłać przypomnienie po jednym dniu, eskalować po dwóch dniach i powiadomić operacje po trzech. Te wybory wpływają na etykiety statusu, powiadomienia i widoki kolejek, więc warto je ustalić przed projektowaniem ekranów.
Praktyczna matryca zwykle odpowiada na pięć podstawowych pytań:
Jeśli wczesne mapowanie odpowie na te pytania, reszta budowy będzie znacznie prostsza.
Użyj tabeli, tablicy suchościeralnej lub arkusza kalkulacyjnego. Trzymaj to na tyle proste, żeby menedżer, lider zespołu i właściciel procesu zrozumieli to za pierwszym razem.
Najpierw wypisz każdy typ wniosku, który wymaga zatwierdzenia. Nie próbuj wszystko wciskać w jeden uniwersalny przepływ, jeśli biznes już traktuje wnioski różnie. Wniosek zakupowy, zwrot, zatwierdzenie rabatu i prośba o dostęp często potrzebują różnych zatwierdzających, limitów i terminów.
Następnie zapisz pierwszego zatwierdzającego i każdy punkt decyzyjny po nim. Dla każdego typu wniosku zanotuj, kto pierwszy go przegląda i co się dzieje po zatwierdzeniu lub odrzuceniu. Podążaj ścieżką, aż dojdziesz do końcowego wyniku, takiego jak zatwierdzony, odrzucony, odesłany do poprawek lub anulowany.
Potem dodaj progi, które zmieniają trasę. Tu wiele zespołów blokuje się później. Jeśli wniosek poniżej $500 idzie do lidera zespołu, a powyżej $500 do szefa działu, zapisz to teraz. Jeśli pilne wnioski pomijają krok lub idą szybszą ścieżką, uwzględnij to również.
Następnie zanotuj wyjątki, terminy i stany końcowe. Uwzględnij przypadki brakujących dokumentów, duplikatów, naruszeń polityki i przeterminowanych zatwierdzeń. Reguła nie jest ukończona, dopóki nie wiesz, jak zachowuje się, gdy coś pójdzie nie tak.
Na koniec przejrzyj szkic z osobami, które dzisiaj zatwierdzają wnioski. Zapytaj, gdzie zwykle praca staje, gdzie ludzie pomijają kroki i co się dzieje, gdy normalny zatwierdzający jest niedostępny. Rzeczywiste nawyki często ujawniają reguły, które nigdy nie zostały udokumentowane.
Mały przykład to wyjaśni. Wyobraź sobie wniosek zakupowy: materiały biurowe poniżej $200 idą do lidera zespołu, oprogramowanie między $200 a $2,000 do kierownika działu, a wszystko powyżej tego też wymaga zatwierdzenia finansów. Jeśli formularz nie zbiera kwoty i kategorii na początku, UI nie będzie w stanie wysłać wniosku we właściwą ścieżkę.
Progi działają tylko wtedy, gdy ludzie szybko je odczytają i zawsze dokonają tej samej decyzji. Jeśli reguła mówi „małe zakupy” lub „dostawcy wysokiego ryzyka”, różni ludzie będą to różnie interpretować. Używaj stałych liczb, dat i nazwanych warunków.
Jaśniejsza reguła brzmi tak: „Do $1,000 trafia do lidera zespołu. $1,001–$5,000 do kierownika działu. Powyżej $5,000 do finansów i dyrektora.” Nikt nie musi zgadywać, gdzie należy wniosek.
Kwota jest powszechna, ale nie powinna być jedynym wyzwalaczem, jeśli proces zależy od innych czynników. Niskokosztowy zakup oprogramowania od nowego dostawcy może wymagać większego przeglądu niż większe zamówienie od zatwierdzonego dostawcy.
Większość zespołów potrzebuje tylko niewielkiego zestawu reguł routingu. Typowe przykłady to zakres kwot, status dostawcy, kategoria zakupu, dział i pilność. Ważne nie jest ile reguł, ale czy wszyscy stosują je tak samo.
Kolejność reguł też ma znaczenie. Jeśli ludzie nie wiedzą, który warunek ma pierwszeństwo, będą kierować ten sam wniosek inaczej. Wybierz jedną kolejność i trzymaj się jej. Możesz najpierw sprawdzać status dostawcy, potem kategorię, a na końcu kwotę. Albo odwrotnie. Oba podejścia działają, jeśli wszyscy stosują tę samą sekwencję.
Warto też określić, kto może nadpisać próg i kiedy. Bez tego pracownicy będą albo zbyt długo czekać, albo omijać proces przez e-mail i czat. „Dyrektor finansów może zatwierdzać wnioski powyżej limitu podczas zamknięcia miesiąca” jest użyteczne. „Kadra kierownicza może robić wyjątki” nie jest.
Prosty test sprawdza się dobrze: daj ten sam przykładowy wniosek trzem osobom i zapytaj, gdzie powinien trafić. Jeśli każda odpowie inaczej, progi są wciąż zbyt niejasne.
Silna matryca nie kończy się na głównym zatwierdzającym. Rzeczywista praca nadal się toczy, gdy ktoś jest na urlopie, na chorobowym lub po prostu nie odpowiada na czas. Jeśli nie zaplanujesz tego wcześnie, ekran może wyglądać schludnie, a proces cicho stanie w miejscu.
Zacznij od wskazania zapasowego zatwierdzającego dla każdego ważnego kroku. Powinien to być osoba lub rola z odpowiednim kontekstem, a nie tylko „następny menedżer” domyślnie. Jeśli lead finansów zatwierdza wydatki powyżej określonej kwoty, zdecyduj, kto wchodzi w jego miejsce, gdy ta osoba jest niedostępna.
Tymczasowe zastępstwa potrzebują ograniczeń. Zastępca powinien otrzymać prawa zatwierdzania tylko na określony okres, np. daty urlopu. To zachowuje jasność odpowiedzialności i zapobiega sytuacjom, w których ktoś zachowuje dostęp do zatwierdzania znacznie dłużej niż powinien.
Proste ustawienie powinno odpowiadać na cztery pytania: kto jest głównym zatwierdzającym, kto jest backupem, jak długo zastępca może działać i kiedy wniosek przesuwa się wyżej w łańcuchu.
Eskalacje powinny opierać się na jasnych wyzwalaczach, nie na domysłach. Typowe wyzwalacze to czas, kwota, ryzyko lub brak informacji. Na przykład, jeśli wniosek zakupowy powyżej $10,000 nie ruszył przez 24 godziny, może zostać eskalowany do szefa działu.
Utrzymuj ścieżkę eskalacji krótką. Jeśli potrzebny jest złożony diagram, żeby zrozumieć, kto otrzymuje wniosek dalej, reguła jest prawdopodobnie zbyt skomplikowana. Jedno lub dwa jasne przeskoki zwykle wystarczą.
Zapisuj też każdą decyzję. Zachowaj informację, kto zatwierdził, kto zastępował, kiedy nastąpiło przekazanie i dlaczego wniosek został eskalowany. Ta historia jest ważna, gdy ktoś później zapyta, dlaczego wniosek był opóźniony lub zatwierdzony przez zastępcę.
Jeszcze jedna reguła ma większe znaczenie, niż się wydaje: unikaj pętli. Wniosek nigdy nie powinien wracać do osoby, która już go zatwierdziła, ani do zastępcy działającego w imieniu tej samej osoby. Sprawdź matrycę pod kątem ścieżek cyklicznych zanim zbudujesz logikę w aplikacji.
Wyobraź sobie małą firmę kupującą codzienne rzeczy. Pracownik wysyła jeden wniosek z przedmiotem, kwotą, uzasadnieniem i datą potrzebną. Routing jest napędzany regułami, a nie tym, kto akurat jest online.
Jeśli wniosek opiewa na $420, idzie bezpośrednio do lidera zespołu. To pozwala małym zakupom szybko przechodzić. Wniosek za $3,200 pomija lidera i trafia do kierownika działu, bo wpływ budżetowy jest większy.
Teraz weźmy wniosek na $7,800 na nowe wyposażenie. Kierownik działu nadal go przegląda, ale to nie wystarczy. Ponieważ kwota jest powyżej $5,000, musi go także przejrzeć dział finansów. Tutaj jasna matryca pomaga: wyższe kwoty dodają kontroli bez zgadywania.
Absencje też mają znaczenie. Jeśli kierownik działu jest na urlopie, wniosek nie powinien utknąć. Automatycznie trafia do wskazanego zastępcy, który może działać przez określony czas.
Limity czasowe wymagają tej samej jasności. Jeśli nikt nie zadziała przez dwa dni, wniosek eskaluje do operacji. Operacje mogą się skontaktować, przekierować lub zadbać, żeby to nie blokowało pracy.
W tym przykładzie matryca odpowiada na kilka prostych, ale ważnych pytań: ile jest żądane, jaka rola zatwierdza przy każdej kwocie, kiedy dołącza finansów, kto pokrywa absencje i co się dzieje przy przekroczeniu terminu.
Gdy te odpowiedzi są zdefiniowane, projektowanie ekranów staje się proste. Formularz potrzebuje tylko odpowiednich danych, a strona wniosku tylko pokazuje obecnego zatwierdzającego, ewentualnego zastępcę i czy zegar eskalacji działa.
Większość przeróbek zaczyna się, zanim narysujesz choćby jeden ekran. Zespoły zgadują ścieżkę zatwierdzeń, a potem próbują dopasować UI do reguł, które nigdy nie zostały uzgodnione.
Jednym z częstych błędów jest skopiowanie organigramu i nazwanie go workflow. To może wyglądać schludnie, ale rzeczywiste wnioski zwykle poruszają się według kwoty, ryzyka, lokalizacji lub rodzaju wniosku. Jeśli matryca to pomija, ekrany będą później wymagać dodatkowych pól, stanów i niezręcznych wyjątków.
Innym problemem jest zapominanie o specjalnych przypadkach. Pilne wnioski, zakupy regulowane lub wnioski międzyzespołowe często potrzebują innej ścieżki. Jeśli wyjątki nie są zmapowane wcześnie, ludzie zaczynają prosić o ręczne obejścia, a interfejs zapełnia się jednorazowymi opcjami, które wszystkich mylą.
Zespoły komplikują sprawę też wtedy, gdy dwóm osobom nadają tę samą rolę bez reguły rozstrzygającej. Jeśli obie mogą zatwierdzić, kto działa pierwszy? Jeśli się nie zgadzają, czyja decyzja obowiązuje? Bez odpowiedzi wnioski krążą, a użytkownicy tracą zaufanie.
Reguły zastępstw to kolejne słabe miejsce. Zastępca powinien pokrywać nieobecność, a nie cicho stawać się drugim właścicielem na stałe. Gdy tymczasowe i stałe uprawnienia się mieszają, raporty stają się nieczytelne, a odpowiedzialność znika.
Projektowanie formularzy przed ustaleniem routingu powoduje kolejną falę przeróbek. Formularz może wyglądać ukończony, ale gdy reguły zatwierdzania zostaną sfinalizowane, często brakuje pól takich jak zakres kwot, dział, pilność czy flaga polityki. Wtedy trzeba zmieniać układ, walidację i powiadomienia.
Szybkie sprawdzenie rzeczywistości pomaga wykryć to wcześnie:
Jeśli którejkolwiek odpowiedzi brakuje, zatrzymaj się. Napraw matrycę, zanim dopracujesz ekrany.
Zanim naszkicujesz formularz lub odznakę statusu, przetestuj logikę prostym językiem. Dobra matryca zatwierdzeń powinna dać się łatwo wytłumaczyć bez otwierania diagramu. Jeśli menedżer, lead finansów lub osoba z operacji nie potrafi opisać trasy w około minutę, proces jest wciąż zbyt niejasny do pracy nad UI.
Przeprowadź szybki przegląd na realnych przykładach. Poproś jedną osobę, żeby opisała pełną trasę od wniosku do decyzji końcowej. Sprawdź, czy każdy prawdopodobny wynik ma nazwanego następnego zatwierdzającego, nie tylko ścieżkę idealną. Przepisz niejasne progi jako dokładne reguły, np. „$1,000 i mniej” lub „ponad 10% rabatu”. Potwierdź, że reguły fallback i eskalacji używają jasnych limitów czasowych typu „po 24 godzinach” albo „po 2 dniach roboczych”.
Potem przetestuj śledzalność. Później ktoś zapyta, dlaczego wniosek był opóźniony, kto zatwierdził wyjątek lub kiedy wszedł zastępca. Twój proces powinien już odpowiadać na te pytania. Znaczniki czasu, historia decyzji i przejrzyste zmiany statusu nie są dodatkiem. Są częścią zestawu reguł.
Prosty scenariusz często ujawnia słabe punkty. Wyobraź sobie wniosek na $4,800 przychodzący w piątek po południu, gdy zwykły zatwierdzający jest nieobecny. Kto dostaje go dalej? Jak długo system czeka, zanim go przemieści? Co jeśli backup też nic nie robi? Jeśli te odpowiedzi nie są zapisane, UI będzie ukrywać zamieszanie zamiast je rozwiązywać.
Gdy te kontrole przejdą pomyślnie, projektowanie ekranów staje się znacznie łatwiejsze. Nie zgadujesz już, co powinien pokazywać interfejs. Nadajesz jasny kształt jasnym regułom.
Gdy reguły są jasne, zbuduj proces, zanim dopracujesz ekrany. Zacznij od logiki, pól danych i stanów zatwierdzeń. Jeśli routing działa, interfejs znacznie łatwiej zaprojektować. Jeśli routing wciąż się zmienia, atrakcyjne ekrany tylko zamaskują problemy.
Praktyczna pierwsza wersja zwykle zawiera podstawy: typ wniosku, kwotę, dział, obecnego zatwierdzającego, status końcowy i czytelną historię każdej decyzji. Potem dodaj reguły, które przesuwają wniosek do przodu, wysyłają go do zapasowego zatwierdzającego lub wyzwalają eskalację, gdy nikt nie odpowie na czas.
Trzymaj pierwsze ekrany proste. Wnioskodawca powinien móc wysłać, sprawdzić status i odpowiedzieć na pytania uzupełniające. Zatwierdzający powinien móc przeglądnąć, zatwierdzić, odrzucić lub przekazać. To wystarczy, by przetestować, czy workflow ma sens w codziennym użyciu.
Sensowna kolejność budowy jest prosta:
To wspólne źródło prawdy ma większe znaczenie, niż wiele zespołów się spodziewa. Jeśli mobilna aplikacja pokazuje inny status niż panel webowy, a backend stosuje inne progi, zaufanie znika szybko.
Jeśli budujesz to w AppMaster, jasna matryca znacznie ułatwia konfigurację. Możesz najpierw zamodelować dane, logikę biznesową i przepływ zatwierdzeń, a potem przenieść ten sam proces na backend, web i mobile bez przepisywania reguł w kilku narzędziach.
Użyj jednego realnego przypadku do pierwszego testu. Przeprowadź faktyczny wniosek zakupowy z progiem, zastępcą i eskalacją spowodowaną przeterminowaniem. Obserwuj, gdzie ludzie mają wątpliwości, jakich danych brakuje i które etykiety statusu mylą.
Popraw słownictwo i układ po tym teście. Gdy proces działa przy realnym wniosku, projektowanie ekranów jest prostsze i znacznie mniej prawdopodobne, że będziesz musiał je przebudowywać tydzień później.
27 sty 2026
8 min
26 sty 20268 min
21 sty 20268 minEksperymentuj z AppMaster z darmowym planem.
Kiedy będziesz gotowy, możesz wybrać odpowiednią subskrypcję.
