Dokumentowanie zasad biznesowych dla aplikacji AI prostym językiem

Dlaczego niejasne zasady tworzą zawodne aplikacje

Zasady biznesowe mówią aplikacji, co robić w prawdziwych sytuacjach. Odpowiadają na pytania takie jak: kto może zatwierdzić wniosek, jak oblicza się sumę i co się dzieje, gdy sprawa wychodzi poza zwykły schemat.

Jeśli te zasady są niejednoznaczne, aplikacja wciąż musi wybrać ścieżkę. Może jednak nie wybrać takiej, jakiej oczekiwałeś.

Weź prostą regułę: "duże wydatki wymagają zatwierdzenia przez menedżera." Dla człowieka może to brzmieć jasno. Dla twórcy — nie. Co oznacza "duże": 500 USD, 5 000 USD czy wszystko powyżej budżetu zespołu? Który menedżer: bezpośredni przełożony, kierownik działu czy dział finansów? Jeśli nikt nie odpowie w dwa dni — czy wniosek czeka, wygasa, czy trafia do kogoś innego?

Dlatego niejasne zasady prowadzą do zawodnych aplikacji. Twórca może być tak spójny, jak dokładne są instrukcje. Gdy sformułowanie daje pole do domysłów, aplikacja może zachowywać się inaczej dziś i inaczej jutro, gdy pojawi się nieco inny przypadek.

Największe problemy zwykle pojawiają się w kilku obszarach:

• obliczenia z brakującymi szczegółami, takimi jak zaokrąglanie, podatki, rabaty czy zakresy dat
• wyjątki, które każdy zakłada, ale nikt ich nie zapisuje
• kroki zatwierdzania bez jasnego właściciela, kolejności lub planu awaryjnego

Prosty przykład pokazuje problem. Założyciel buduje wewnętrzną aplikację do rozliczania wydatków w Koder.ai i pisze: "Zwrot kosztów podróży, chyba że wydają się nietypowe." To brzmi rozsądnie, ale aplikacja nie ma wiarygodnego sposobu oceny, co jest nietypowe. Jeden pracownik ma taksówkę zatwierdzoną, inny podobną zostaje oznaczony, i nikt nie wie dlaczego.

Niezawodne zachowanie zaczyna się od zasad, które można stosować w ten sam sposób za każdym razem. Słowa takie jak "duży", "pilny" i "przypadek specjalny" trzeba zastąpić dokładnymi limitami, warunkami i działaniami. Jeżeli dwie różne osoby zastosowałyby regułę w ten sam sposób, aplikacja ma większą szansę robić to samo.

Jak wygląda jasna zasada biznesowa

Jasna zasada obejmuje jedną decyzję lub jedną akcję, a nie cały proces. To ważniejsze, niż większość zespołów się spodziewa. Gdy jedna reguła próbuje obejmować zatwierdzenie, wycenę, wyjątki i powiadomienia naraz, twórca musi zgadywać, która część jest najważniejsza.

Dobra reguła jest łatwa do przeczytania na głos. Ktoś spoza zespołu powinien ją zrozumieć bez wewnętrznego żargonu. Zamiast terminów takich jak "szybkie przetworzenie", "przypadek standardowy" czy "podpis menedżera", użyj prostego języka, który dokładnie opisuje, co się dzieje.

Większość jasnych zasad odpowiada na cztery podstawowe pytania:

• Kto podejmuje decyzję lub wykonuje akcję?
• Kiedy reguła ma zastosowanie?
• Co się zmienia w aplikacji?
• Co się dzieje dalej?

Taka struktura utrzymuje regułę związaną z rzeczywistym zachowaniem. Zamiast pisać "Duże zamówienia wymagają przeglądu", napisz "Jeśli zamówienie przekracza 5 000 USD, menedżer sprzedaży musi je zatwierdzić, zanim zostanie wysłane do realizacji." Jedno zdanie, jedna decyzja, jeden rezultat.

Pomaga też trzymać powiązane zasady oddzielnie. Reguła zatwierdzania powinna istnieć sama dla siebie. Reguła wysyłania e‑maila powinna być osobna. Reguła blokowania wysyłki również. Dzięki temu każda reguła jest łatwiejsza do testowania, aktualizacji i naprawy.

Różnica jest prosta:

"Klienci premium mają priorytetową obsługę" — to niejasne.

"Jeśli klient ma plan premium, zgłoszenie wsparcia jest oznaczane jako Wysoki Priorytet przy utworzeniu ticketu" — to jasne.

Druga wersja nazywa wyzwalacz, warunek i zmianę w aplikacji. Mówi twórcy, jak powinno wyglądać wiarygodne zachowanie.

Jeśli używasz kreatora opartego na czacie, taki sposób formułowania ma duże znaczenie. Jasne reguły nie potrzebują języka prawnego. Potrzebują prostych słów, po jednej myśli na raz i oczekiwanego rezultatu mieszczącego się w jednym zdaniu.

Pisanie obliczeń prostym językiem

Obliczenia często wyglądają na proste, aż ktoś próbuje je zbudować. Najbezpieczniejsze podejście to zacząć od jednego prostego zdania, które dokładnie mówi, co aplikacja ma robić.

Dobra reguła brzmi tak: "Kwota zwrotu równa się zatwierdzonym milom pomnożonym przez stawkę za milę." To dużo jaśniejsze niż "oblicz pensję za podróż" czy "zastosuj standardowy zwrot".

Po tym pierwszym zdaniu zdefiniuj każde wejście, które aplikacja ma użyć. Bądź na tyle szczegółowy, by twórca nie musiał zgadywać.

Co określić dla każdego obliczenia

Dla każdego obliczenia zapisz:

• wejścia, z prostymi nazwami i jednostkami
• skąd pochodzi każda wartość
• zasady zaokrąglania
• minimalną lub maksymalną wartość
• co się dzieje, gdy wartość jest pusta

Małe szczegóły mają znaczenie. "Zaokrąglij końcową kwotę do 2 miejsc po przecinku" daje inny wynik niż zaokrąglanie każdej pozycji osobno. Jeśli istnieje limit, powiedz, czy aplikacja ma zatrzymać się na tym limicie, czy pokazać ostrzeżenie.

Reguła napisana prostym językiem może wyglądać tak: "Zwrot kosztów podróży równa się zatwierdzone mile x 0,67 USD. Zaokrąglij końcową kwotę do 2 miejsc po przecinku. Maksymalny zwrot to 300 USD za podróż. Jeśli zatwierdzone mile są puste, nie obliczaj kwoty. Oznacz wniosek jako niekompletny i poproś użytkownika o wpisanie mil."

Potem dodaj jeden lub dwa przykłady z prawdziwymi liczbami. Przykłady szybciej ujawniają luki niż abstrakcyjne formuły.

Przykład 1: "Jeśli zatwierdzone mile to 120, zwrot to 120 x 0,67 USD = 80,40 USD. Ponieważ to poniżej limitu 300 USD, końcowa kwota to 80,40 USD."

Przykład 2: "Jeśli zatwierdzone mile to 500, zwrot to 500 x 0,67 USD = 335,00 USD. Ponieważ maksymalna kwota to 300 USD, końcowa kwota to 300,00 USD."

Taki styl jest łatwiejszy do przeglądu i łatwiejszy dla twórcy do zamiany w zachowanie aplikacji.

Opisywanie wyjątków bez zamieszania

Większość aplikacji nie zawodzi na głównej ścieżce. Zawodzi na przypadkach brzegowych.

Normalna ścieżka może być prosta, ale prawdziwa praca obejmuje zwroty po terminie, VIP‑ów, brakujące dokumenty i jednorazowe zatwierdzenia. Jeśli wyjątki zostaną pominięte, aplikacja wypełni lukę sama i stąd biorą się niespójne wyniki.

Prosty sposób zapisu wyjątków to krótkie reguły w formacie if-then. Każdą trzymaj skupioną na jednym warunku i jednym wyniku.

• Jeśli wydatek jest poniżej 100 USD, wtedy autozatwierdź.
• Jeśli wydatek jest poniżej 100 USD, ale zgłoszony po 30 dniach, wtedy wyślij go do ręcznej weryfikacji.
• Jeśli pracownik należy do zespołu wykonawczego, wtedy zignoruj limit 100 USD i skieruj do działu finansów.
• Jeśli administrator finansów oznaczy roszczenie jako pilne, wtedy ma zastosowanie ręczne nadpisanie i roszczenie trafia na początek kolejki.

Taki format ujawnia ukrytą logikę. Pomaga też zauważyć nakładające się reguły, zanim staną się błędami.

Równie ważne jest napisanie, która reguła wygrywa, gdy dwie reguły się potykają. Klient może kwalifikować się do rabatu, ale zamówienie może też wpadać w okres blokady świątecznej. Napisz priorytet prostym językiem: "Jeśli reguła blokady świątecznej koliduje z regułą rabatu klienta, wygrywa reguła blokady."

Bądź dokładny co do ograniczeń. Daty, typy użytkowników, lokalizacje, status konta i ręczne nadpisania często zmieniają wynik. Zamiast pisać "późne zgłoszenia wymagają zatwierdzenia", napisz "Jeśli wniosek zostanie złożony więcej niż 14 dni kalendarzowych po zdarzeniu, wtedy wymagana jest zgoda menedżera."

Powiedz też, co aplikacja powinna pokazać użytkownikowi w każdym wyjątku. Dobra reguła nie zatrzymuje się na decyzji. Definiuje też komunikat, np. "Złożono po 14 dniach. Wymagana zgoda menedżera" lub "Ręczne nadpisanie zastosowane przez administratora finansów."

Gdy wyjątki są pisane w ten sposób, nietypowe przypadki przestają wydawać się nietypowe. Stają się normalnym, testowalnym zachowaniem.

Opisywanie logiki zatwierdzania krok po kroku

Logika zatwierdzania działa najlepiej, gdy jest zapisana jako sekwencja decyzji, a nie jako niejasna polityka. Każdy krok powinien odpowiedzieć na pięć pytań: kto działa, co wywołuje ich przegląd, jakie limity obowiązują, ile mają czasu i jaki status ma wniosek po ich decyzji.

Zacznij od nazwania roli, nie tylko zespołu. Zamiast pisać "finanse przeglądają duże wnioski", napisz "Menedżer Finansów może zatwierdzić, odrzucić lub odesłać dowolny wniosek powyżej 5 000 USD." To usuwa zgadywanie i ułatwia budowę zachowania.

Potem określ wyzwalacz dla każdego kroku. Wyzwalacz to warunek, który wysyła wniosek do następnej osoby. Może być oparty na kwocie, dziale, poziomie ryzyka, typie wniosku lub kombinacji tych czynników.

Na przykład:

• Jeśli wniosek jest poniżej 500 USD, sprawdza go lider zespołu.
• Jeśli wniosek wynosi od 500 do 5 000 USD, po akceptacji lidera sprawdza go kierownik działu.
• Jeśli wniosek przekracza 5 000 USD, po akceptacji kierownika działu sprawdza go dział finansów.
• Jeśli wniosek jest oznaczony jako wysokie ryzyko, compliance musi go sprawdzić przed ostatecznym zatwierdzeniem.

Progi muszą mieć dokładne granice. Nie mów "duży" ani "wrażliwy". Mów "powyżej 5 000 USD", "z działu Sprzedaży" lub "ocena ryzyka 8 lub wyżej." Jeśli dwa progi mogą obowiązywać jednocześnie, napisz, który ma pierwszeństwo. Na przykład: "Wysokie ryzyko zawsze trafia do compliance, nawet jeśli kwota jest niska."

Potrzebujesz też reguły timeoutu. Jeśli nikt nie odpowiada, aplikacja nie powinna wisieć w próżni na zawsze. Powiedz, co się dzieje po ustalonym czasie, np. 48 godzin lub 3 dni robocze. Wniosek może zostać eskalowany do menedżera zatwierdzającego, przypisany zapasowy zatwierdzający lub automatycznie anulowany.

Na koniec zdefiniuj status po każdej decyzji. Trzymaj etykiety krótkie i spójne:

• Zatwierdzony: wniosek przechodzi dalej lub jest zakończony.
• Odrzucony: wniosek zamyka się i nie są podejmowane dalsze działania.
• Odesłany: wnioskodawca musi edytować i ponownie złożyć.
• Eskalowany: wniosek trafia do zapasowego lub wyższego zatwierdzającego.

Gdy logika zatwierdzania jest napisana w ten sposób, twórca ma mniej pola do zgadywania, a workflow staje się dużo bardziej przewidywalny.

Prosty szablon reguły, którego możesz używać wielokrotnie

Jeśli chcesz uzyskać spójne zachowanie, nadaj każdej regule ten sam kształt. Mieszane style zapisu często tworzą mieszane wyniki.

Prosty format dobrze sprawdza się w większości przypadków: wyzwalacz, warunki, akcja, rezultat. Jest na tyle krótki, by szybko go napisać, i na tyle jasny, by ktoś inny mógł go później przeglądnąć.

Użyj jednej reguły, jednej jednostki

Trzymaj każdą regułę w osobnej linijce, karcie lub bloku. Nie pakuj kilku pomysłów w jeden akapit. Jeśli reguła obejmuje cenę, zatwierdzenie i wyjątek jednocześnie, staje się trudna do przetestowania i łatwa do źle zrozumienia.

Praktyczny szablon wygląda tak:

Trigger: When [event happens]
Conditions: If [facts must be true]
Action: Then [the app does this]
Result: So [expected outcome]
Assumption: [anything not yet confirmed]
Example: [short sample input and output]

Nie potrzebujesz każdego pola za każdym razem. Ale zachowywanie tej samej kolejności pomaga ludziom szybciej przeglądać reguły.

Na przykład:

Trigger: When an employee submits an expense claim
Conditions: If the total is over $500 and no receipt is attached
Action: Then send the claim back for correction
Result: So incomplete claims are not forwarded to a manager
Assumption: Receipt is required for all claims above $500
Example: A $620 taxi claim without a receipt is returned to the employee

Zauważ, że przykład leży pod regułą, a nie w jej środku. To utrzymuje regułę w czystości. Przykład tylko pokazuje, jak reguła ma się zachować.

Wyraźnie oznacz założenia zamiast ukrywać je w zdaniu. Krótka notatka jak "Założenie" lub "Wymaga potwierdzenia" ułatwia przegląd otwartych pytań przed rozpoczęciem budowy.

Pomaga też zachować spójność sformułowań. Zawsze zaczynaj wyzwalacze od "When", warunki od "If", a akcje od "Then." Małe wzorce jak ten redukują nieporozumienia, zwłaszcza gdy reguły są zamieniane w logikę aplikacji.

Szybki test dobrze tu działa: czy ktoś potrafi przetestować tę regułę i czy ktoś mógłby ją źle odczytać? Jeśli odpowiedź na pierwsze jest "nie", albo na drugie "tak", dopracuj sformułowanie.

Przykład: aplikacja do zatwierdzania wydatków

Aplikacja do wydatków pracowniczych jest dobrym przypadkiem testowym, bo polityka jest znana, a przypadki brzegowe szybko wychodzą na jaw. Pracownicy mogą rozliczać posiłki, taksówki, hotele i małe koszty dla klienta, ale każdy wniosek ma limity, wyjątki i kroki zatwierdzania. To dokładnie ten rodzaj procesu, gdzie prosty język ma znaczenie.

Przykładowa polityka

Napisz regułę dla posiłków tak: pracownicy mogą rozliczać do 40 USD na dzień za posiłki w normalne dni pracy. Aplikacja powinna sumować wszystkie paragony za dany dzień i porównywać tę sumę z limitem dziennym, a nie każdy paragon osobno.

Jeśli pracownik wyda 12 USD na śniadanie i 22 USD na lunch we wtorek, suma to 34 USD i wniosek przechodzi. Jeśli doda 15 USD za kolację tego samego dnia, suma wyniesie 49 USD i aplikacja powinna oznaczyć wniosek jako przekraczający limit.

Dodaj teraz wyjątek. Jeśli posiłek miał miejsce podczas zatwierdzonej podróży służbowej lub spotkania z klientem, limit dzienny na posiłki wzrasta do 75 USD. Ten wyjątek ma zastosowanie tylko, gdy pracownik wybierze Travel day = Yes lub Client meeting = Yes i doda krótką notatkę z nazwą klienta lub celem podróży.

To jest bardziej wiarygodne niż niejasne sformułowanie typu "przypadki specjalne mogą być dozwolone", bo wyjątek jest powiązany z jasnymi warunkami.

Kroki zatwierdzania

Logika zatwierdzania może pozostać równie prosta:

• Wnioski poniżej 100 USD zatwierdza menedżer pracownika.
• Wnioski od 100 do 500 USD wymagają zatwierdzenia menedżera, a następnie zatwierdzenia finansów.
• Wnioski powyżej 500 USD wymagają zatwierdzenia menedżera, zatwierdzenia finansów i zatwierdzenia kierownika działu.
• Każdy wniosek oznaczony jako "travel" wymaga też przeglądu przez finanse, nawet jeśli kwota jest poniżej 100 USD.

Możesz przetestować regułę kilkoma prostymi przypadkami. Wniosek na 36 USD za posiłek w normalny dzień powinien zostać zatwierdzony, jeśli paragony są dołączone. Wniosek na 60 USD za posiłek w dniu podróży powinien przejść, jeśli zaznaczono podróż i wypełniono notatkę. Wniosek na 60 USD w normalny dzień powinien zostać odrzucony lub odesłany do poprawki. Wniosek na 650 USD za hotel powinien przejść przez wszystkie trzy kroki zatwierdzania.

O to chodzi: reguła powinna dawać ten sam wynik za każdym razem, gdy ktoś testuje ją na realnych przypadkach.

Częste błędy prowadzące do złych wyników

Reguła może brzmieć jasno dla człowieka, a i tak mylić twórcę. Zwykle dzieje się tak, gdy dokument jest niejasny, zawiera wiele pomysłów lub jest niespójny.

Jednym z częstych błędów jest upakowanie kilku reguł w jednym długim akapicie. Na przykład: "Menedżerowie zatwierdzają podróże, chyba że suma jest wysoka, finanse sprawdzają paragony, a pilne prośby mogą pominąć weryfikację." To może wyglądać efektywnie, ale ukrywa wiele oddzielnych decyzji. Rozdziel to na osobne reguły, tak by każda akcja miała jeden wyzwalacz i jeden wynik.

Innym problemem jest rozmyty język. Słowa takie jak normalny, duży, pilny czy ostatni działają tylko wtedy, gdy są zdefiniowane. Jeśli "duży wydatek" oznacza wszystko powyżej 2 000 USD, napisz to. Jeśli "pilne" oznacza potrzebne w ciągu 24 godzin, określ to.

Brakujące dane to kolejna duża przyczyna złych rezultatów. Zespoły często opisują ścieżkę idealną i zapominają napisać, co robić, gdy informacje są niekompletne lub błędne. Jeśli wniosek nie ma kwoty, działu lub paragonu, reguła powinna określać dalsze kroki.

Błędy, które powodują najwięcej kłopotów, to zwykle:

• łączenie wielu reguł w jednym akapicie
• używanie niezdefiniowanych terminów dotyczących wielkości, czasu lub priorytetu
• pomijanie przypadków błędów i brakujących pól
• niejasne określenie, kto ma ostateczne zatwierdzenie
• zmienianie nazw tego samego elementu w połowie dokumentu

Ostateczne uprawnienia mają większe znaczenie, niż wiele zespołów się spodziewa. Jeśli menedżer i recenzent finansowy się nie zgadzają, kto decyduje? Jeśli nikt nie ma ostatniego słowa, aplikacja może stanąć w miejscu lub wysyłać pracę w kółko.

Zmiana terminologii tworzy cichsze błędy. Jeśli zaczynasz od "wniosek", a potem mówisz "zgłoszenie" albo "ticket", czytelnicy mogą założyć, że to różne rzeczy. Wybierz jeden termin i trzymaj się go przez cały dokument.

Ma to jeszcze większe znaczenie przy twórcy opartym na czacie, gdzie prosty język napędza zachowanie. Jasne reguły nie muszą brzmieć formalnie. Muszą być konkretne, spójne i kompletne.

Szybka lista kontrolna przed budową

Zanim przełożysz wymagania na ekrany, przepływy czy prompta, zrób ostatni przegląd. Krótkie sprawdzenie teraz może oszczędzić wiele godzin naprawiania dziwnego zachowania później.

Upewnij się, że każda reguła jest testowalna. Każda reguła powinna kończyć się jasnym wynikiem, takim jak tak/nie, zatwierdź/odrzuć, zastosuj opłatę/nie stosuj opłaty. Jeśli dwie osoby mogą przeczytać to samo zdanie i udzielić różnych odpowiedzi, reguła wymaga dopracowania.

Wypisz każde obliczenie. Nazwij wejścia, formułę i kiedy obliczenie ma się wykonać. Dodaj zasady zaokrąglania, obsługę walut, dat i co robić, gdy wartość jest pusta lub zero.

Trzymaj wyjątki osobno. Najpierw napisz regułę domyślną, potem dodaj wyjątki w osobnych wpisach. Podstawowy limit wydatków nie powinien być ukryty wewnątrz przypadku specjalnego dla kontrahentów, pilnych zakupów czy zatwierdzonej podróży.

Zmapuj pełną ścieżkę zatwierdzania. Dla każdego progu podaj, kto zatwierdza i co się dzieje dalej. Bądź dokładny także przy krawędziach: powiedz, czy reguła zaczyna się powyżej 500 USD, czy od 500 USD w górę.

Następnie wykonaj test z osobą nową w zespole. Daj regułę komuś, kto nad nią nie pracował i poproś, by wyjaśnił ją własnymi słowami. Jeśli potrzebuje dodatkowego kontekstu, reguła wciąż jest zbyt niejasna.

Mały przykład pokazuje, dlaczego to ważne. "Menedżer zatwierdza duże wydatki" brzmi jasno, dopóki ktoś nie zapyta, czy 500 USD to już duży wydatek. "Menedżer zatwierdza wydatki powyżej 500 USD. Dyrektor zatwierdza wydatki powyżej 2 000 USD. Wydatki do 500 USD są autozatwierdzane" pozostawia mniej pola do błędów.

Zamiana reguł w działającą aplikację

Gdy reguły są jasne, przejrzyj je razem z ludźmi, którzy codziennie używają procesu. Menedżerowie, koordynatorzy, pracownicy finansów i zatwierdzający często zauważają drobne szczegóły, które nie trafiają do dokumentu. Zwykle to one sprawiają, że aplikacja działa płynnie lub irytuje.

Traktuj dokument reguł jako instrukcję roboczą, a nie jednorazowy szkic. Powinien wyjaśniać, co się dzieje, kto decyduje, jakie są wyjątki i co aplikacja robi, gdy brakuje informacji.

Zanim zbudujesz pełną aplikację, przetestuj kilka prawdziwych scenariuszy z ostatniej pracy. Użyj zarówno czystych przypadków, jak i bałaganiarskich: standardowego wniosku, który powinien przejść; wniosku z brakującymi informacjami; wyjątku wymagającego ręcznej weryfikacji; oraz przypadku, który przekracza limit wydatków lub próg zatwierdzania.

Ten krok wykrywa luki wcześnie. Reguła może brzmieć jasno na papierze, ale rozpaść się, gdy prawdziwy wniosek nie pasuje do oczekiwanego wzorca.

Gdy scenariusze działają poprawnie, przenieś je do kreatora. Jeśli używasz platformy opartej na czacie, takiej jak Koder.ai, jasny zestaw reguł znacznie przyspiesza budowę, ponieważ tłumaczysz zdefiniowany proces na ekrany, akcje i zatwierdzenia, zamiast podejmować decyzje w locie.

Po uruchomieniu trzymaj dokument jako źródło prawdy. Gdy polityka się zmienia, dodaje się nowy zatwierdzający lub aktualizuje limit, zmień najpierw dokument, a potem aplikację. To upraszcza przyszłe edycje i zmniejsza ryzyko, że różni ludzie zapamiętają regułę inaczej.

Mały nawyk pomaga: przeglądaj reguły za każdym razem, gdy proces się zmienia, nie tylko gdy aplikacja zaczyna działać źle. Małe aktualizacje zrobione wcześnie są dużo łatwiejsze niż naprawianie mylącego zachowania później.

Jeśli dokument pozostaje aktualny, aplikacja staje się łatwiejsza do testowania, ulepszania i zaufania z czasem.