Reguły biznesowe
Reguły biznesowe to zapisane w formie warunków zasady, według których organizacja podejmuje powtarzalne decyzje: „faktura powyżej progu wymaga drugiej akceptacji”, „urlop na żądanie maksymalnie cztery dni w roku”, „kontrahent spoza białej listy blokuje płatność”. W systemie workflow reguły są wydzielone z kroków procesu, żeby można je było zmieniać bez przebudowy procesu, a ich wykonanie zostawia ślad.
Rodzaje reguł biznesowych
- Decyzyjne - wybierają ścieżkę: faktura do określonej kwoty ma jeden stopień akceptacji, powyżej dwa.
- Walidacyjne - blokują błędne dane: NIP musi być na białej liście, kwota podziału musi równać się kwocie faktury, pole „projekt” jest obowiązkowe przy kosztach projektowych.
- Obliczeniowe - wyliczają wartości: dietę za delegację, termin płatności, VAT, wysokość zaliczki.
- Przydziału - wskazują wykonawcę: reklamacje z regionu południowego do serwisu w Krakowie, faktury z MPK działu do jego kierownika.
- Terminowe - ustalają czas na krok i eskalację po jego przekroczeniu.
- Uprawnień - określają, kto widzi i edytuje dokument.
Źródłem reguł są przepisy, umowy, polityki wewnętrzne i decyzje zarządu. Każda reguła powinna mieć wskazane, skąd się wzięła - to ułatwia jej zmianę, gdy zmieni się źródło.
Reguły a proces: dlaczego trzymać je osobno
Proces opisuje kolejność kroków i zmienia się rzadko. Reguły opisują parametry decyzji i zmieniają się często: rośnie próg akceptacji, zmienia się stawka diety, pojawia się nowa kategoria wydatków. Jeśli reguły są zaszyte w krokach procesu, każda zmiana wymaga przebudowy procesu i testów całości. Jeśli są wydzielone - w tabelach decyzyjnych, parametrach lub silniku reguł - zmienia się jedną tabelę, a proces zostaje. Dodatkowo jedna reguła może obsługiwać wiele procesów (ta sama matryca akceptacji dla faktur, wniosków zakupowych i delegacji), a historia pokazuje, która wersja reguły zadecydowała w danej sprawie. Notacja DMN pozwala zapisać takie tabele w standardowy sposób: każdy wiersz to jedna reguła, a kolumny dzielą się na warunki i wyniki.
Jak spisać reguły biznesowe
- Językiem biznesowym, nie technicznym: jedna reguła to jeden warunek i jeden skutek.
- Z właścicielem, źródłem i datą obowiązywania - stawki i progi mają daty, od których działają.
- Ze zdefiniowanymi pojęciami: „kwota” oznacza netto czy brutto, „pracownik” obejmuje zleceniobiorców czy nie.
- Z przypadkami brzegowymi rozstrzygniętymi wprost: co z fakturą dokładnie na progu.
- Z przykładami testowymi - kilka realnych spraw i oczekiwany wynik dla każdej.
- W jednym katalogu reguł dla całej organizacji, nie w głowach kierowników.
Reguły biznesowe na platformie JobRouter: podejście e-MSI
W analizie przedwdrożeniowej e-MSI mapuje obecny przebieg procesu - to dobry moment, żeby spisać też reguły: skąd pochodzą, kto jest ich właścicielem, jak brzmią i jak mają być sprawdzane. Na platformie JobRouter reguły biznesowe definiuje się jako warunki przejść między krokami, korzystające m.in. ze słowników i baz kontrahentów. Zmiana reguły czy ścieżki akceptacji nie wymaga budowania systemu od nowa, a przeszkolony pracownik może ją wprowadzić bez czekania na programistę - to jedna z cech podejścia low-code. W obiegu faktur ścieżka akceptacji może zależeć od kwoty, dostawcy lub typu kosztu, a faktury z KSeF trafiają do tego samego procesu co papierowe i PDF. Decyzje i przebieg sprawy zapisują się w historii procesu, więc przy audycie widać, którą ścieżką poszła faktura i kto ją zatwierdził.
Najczęstsze błędy w zarządzaniu regułami biznesowymi
- Reguły zaszyte w kodzie lub w krokach procesu, których nie da się zmienić bez wdrożeniowca.
- Sprzeczne reguły w różnych działach: inny próg akceptacji w zakupach i w księgowości.
- Reguła bez właściciela - nikt nie wie, kto może ją zmienić.
- Brak daty obowiązywania, więc nowa stawka działa wstecz.
- Nieprzetestowane przypadki brzegowe, które wychodzą na jaw przy pierwszej fakturze na progu.
- Reguły „w głowie” jednej osoby, które znikają razem z jej urlopem.
Przykłady zastosowania
Matryca akceptacji zapisana jako tabela: kwota i kategoria wydatku wyznaczają liczbę i role akceptujących. Zmiana progu to edycja jednego wiersza, bez ruszania procesu.
Reguła walidacyjna sprawdza przy płatności za transakcję o wartości powyżej 15 000 zł, czy rachunek dostawcy jest na białej liście podatników VAT, i blokuje przelew, gdy go tam nie ma.
Reguła obliczeniowa wylicza dietę krajową według stawki obowiązującej w dniu delegacji - stawka ma datę obowiązywania, więc starsze delegacje liczą się po staremu.
Reguła przydziału kieruje reklamacje do serwisu według regionu klienta, a gdy serwis ma więcej niż ustaloną liczbę otwartych spraw, do najbliższego wolnego.
Reguła terminowa eskaluje wniosek do zastępcy, jeśli akceptujący nie zareaguje w dwa dni robocze, i powiadamia o tym wnioskodawcę.
Najczęstsze pytania
Co to są reguły biznesowe prostymi słowami?
Zasady „jeśli-to”, według których firma podejmuje powtarzalne decyzje: jeśli faktura przekracza próg, to potrzebna jest druga akceptacja. Spisane i wydzielone z procesów, dają się zmieniać bez przebudowy systemu, a ich działanie można sprawdzić w historii każdej sprawy.
Czym reguła różni się od procesu?
Proces mówi, w jakiej kolejności wykonuje się kroki i kto je wykonuje. Reguła mówi, jaką decyzję podjąć w danym kroku na podstawie danych. Proces zmienia się rzadko, reguły często - dlatego trzyma się je osobno, w tabelach lub parametrach, a nie w opisie kroków.
Co to jest silnik reguł biznesowych?
Składnik systemu - samodzielny lub będący częścią systemu zarządzania regułami (BRMS) - który przechowuje reguły w postaci tabel lub warunków i wykonuje je na żądanie procesu, zwracając wynik. Pozwala zmieniać reguły bez programowania i używać tej samej reguły w wielu procesach. W platformach workflow tę rolę pełnią zwykle tabele decyzyjne i parametry konfiguracji.
Co to jest tabela decyzyjna?
Zapis reguł w formie tabeli: każdy wiersz to jedna kombinacja warunków i jej wynik, a kolumny dzielą się na warunki i wyniki. Na przykład kwota faktury i kategoria wydatku w warunkach, liczba akceptacji i role w wynikach. Standard DMN opisuje, jak takie tabele budować, żeby były jednoznaczne i kompletne.
Kto powinien zarządzać regułami biznesowymi?
Właściciel procesu, którego reguła dotyczy, przy wsparciu osoby znającej źródło reguły - prawnika, głównego księgowego, kadr. Dział IT lub wdrożeniowiec udostępnia narzędzie do zmiany, ale nie decyduje o treści. Zmiany powinny przechodzić prosty proces zatwierdzania z datą obowiązywania.
Jak testować reguły przed wdrożeniem?
Zestawem realnych przypadków z oczekiwanym wynikiem: faktura poniżej progu, dokładnie na progu, powyżej, w nietypowej kategorii, od kontrahenta spoza listy. Każdą zmianę reguły przepuszcza się przez ten zestaw na środowisku testowym, zanim trafi na produkcję. Przypadki brzegowe są ważniejsze niż typowe.
Powiązane hasła
Zobacz, jak wygląda to w systemach, które wdrażamy w polskich firmach.
