1. Workflow w systemach ERP
2. Możliwości rozbudowy w Trawers ERP
3. Zamówienia zakupu (workflow)
4. Model danych i model funkcjonalny (1)
5. Model danych i model funkcjonalny (2)
6. Tematy powiązane
1. Workflow w systemach ERP
Typowe mechanizmy workflow stosowane w systemach ERP.
Niezależnie od producenta systemu. Są to sprawdzone wzorce, które można wykorzystać
jako inspirację przy budowie mechanizmu w Trawers ERP.
Patrz też:
Trawers ERP. WorkflowWorkflow akceptacji dokumentów (Approval Workflow)
Najczęściej spotykany typ workflow w ERP.
Przykłady:
* Zamówienie zakupu
* Faktura kosztowa
* Wniosek urlopowy
* Delegacja
* Umowa
Schemat:
1. Operator tworzy dokument.
2. System sprawdza warunki (np. kwota, typ dokumentu, centrum kosztów).
3. Dokument trafia do akceptacji:
* przełożonego,
* działu finansowego,
* dyrektora (przy wyższych progach).
4. Po akceptacji zmienia się status dokumentu.
5. Dokument może zostać zaksięgowany / wysłany / zrealizowany.
Typowe cechy:
* progi kwotowe (np. 5 000 / 20 000 / 100 000)
* wielopoziomowa akceptacja
* możliwość odrzucenia z komentarzem
* ścieżka powrotu do poprawy
Workflow wielostopniowy (Sequential / Hierarchical)
Zatwierdzanie odbywa się etapami, w ustalonej kolejności.
Przykład:
Zamówienie zakupu:
1. Kierownik działu
2. Dyrektor operacyjny
3. CFO
Każdy etap musi zostać zakończony, aby dokument przeszedł dalej.
Cechy:
* określona kolejność
* brak możliwości pominięcia etapu
* historia decyzji
* możliwość eskalacji po czasie (np. 3 dni bez reakcji)
Workflow równoległy (Parallel Workflow)
Kilka osób musi zatwierdzić dokument, ale równolegle.
Przykład:
Nowy dostawca musi zostać zatwierdzony przez:
* dział zakupów
* dział finansowy
* dział prawny
Zatwierdzenia mogą odbywać się jednocześnie.
Warianty:
* wszyscy muszą zatwierdzić
* wystarczy 2 z 3
* pierwszy zatwierdzający zamyka etap
Workflow zależny od wartości (Rule-based / Condition-based)
Najczęściej stosowany model w ERP.
Przykład:
* do 5 000 zł -> kierownik
* 5 000 - 20 000 -> dyrektor
* powyżej 20 000 -> zarząd
Workflow oparty o:
* kwotę
* walutę
* dział
* typ dokumentu
* projekt
* kontrahenta
To dokładnie model, który projektujemy w Trawers.
Workflow statusowy (State Machine Workflow)
Dokument przechodzi przez kolejne statusy:
```
Roboczy -> Do akceptacji -> Zatwierdzony -> Zrealizowany -> Zamknięty
```
Zmiana statusu:
* może być ręczna
* może być automatyczna
* może wymagać określonej roli
To podejście jest bardzo stabilne architektonicznie.
Workflow eskalacyjny (Escalation Workflow)
Jeżeli operator nie wykona zadania w określonym czasie:
* system wysyła przypomnienie
* przekazuje zadanie wyżej
* przekazuje do zastępcy
Przykład:
* 48h brak reakcji -> powiadomienie
* 72h -> przekazanie do przełożonego
Workflow zastępstw (Delegation Workflow)
Jeżeli operator:
* jest na urlopie
* ma nieobecność
* ma ustawionego zastępcę
Zadania automatycznie trafiają do zastępcy.
Workflow automatyczny (System-driven)
Nie wymaga interwencji użytkownika.
Przykłady:
* Automatyczne zaksięgowanie dokumentu po zatwierdzeniu
* Automatyczne wysłanie zamówienia do dostawcy
* Automatyczne wygenerowanie płatności
Tu idProces wywoływany jest przez AutoRun lub harmonogram.
Workflow zależny od struktury organizacyjnej
Zadanie trafia do:
* bezpośredniego przełożonego
* kierownika centrum kosztów
* opiekuna projektu
* właściciela budżetu
Nie wskazujemy konkretnego operatora, lecz rolę.
To bardziej zaawansowany model niż stały operator docelowy.
Workflow mieszany (Hybrid Workflow)
Najczęściej w ERP stosuje się kombinację:
* reguły warunkowe
* wielopoziomową akceptację
* strukturę organizacyjną
* eskalację czasową
* statusy dokumentów
Typowe elementy techniczne w ERP
Dobry silnik workflow w ERP zawiera:
* tabelę definicji reguł
* tabelę instancji workflow
* tabelę zadań
* historię operacji
* mechanizm powiadomień
* obsługę wyjątków
* możliwość wersjonowania reguł
Co jest standardem w nowoczesnych ERP?
| Funkcja | Czy standard? |
| ------------------------- | ------------- |
| Reguły warunkowe | v |
| Progi kwotowe | v |
| Wielopoziomowa akceptacja | v |
| Równoległe zatwierdzanie | v |
| Eskalacja czasowa | v |
| Role zamiast operatorów | v |
| Historia audytowa | v |
| Dashboard zadań | v |
W kontekście projektu mechanizmu w Trawers ERP
Workflow klasyczny:
Rule-based Sequential Approval Workflow
Jest to:
* najczęściej stosowany model,
* najprostszy do wdrożenia,
* najbardziej przewidywalny,
* łatwy do rozbudowy.
2. Możliwości rozbudowy w Trawers ERP
Roadmapa rozwoju mechanizmu Workflow w Trawers ERP
Zaprojektowana tak, aby rozwijać etapami:
od wersji prostej i stabilnej do silnika klasy enterprise.
Założenie - początek od:
Rule-based -> Sequential -> Akceptacja dokumentów -> idProces jako punkt centralnyETAP 1 Minimalny stabilny mechanizm (MVP)Cel:
Uruchomić działający, przewidywalny mechanizm akceptacji.
Funkcjonalność:
* Reguły oparte o:
* idProces wyzwalający
* warunek (np. kwota >= X)
* Jeden operator docelowy
* Jednoetapowa akceptacja
* Tabela zadań workflow
* Status: Oczekujące / Wykonane
* Powiadomienie przy logowaniu
Architektura:
* Tabela RegułyWorkflow
* Tabela ZadaniaWorkflow
* Hook po wykonaniu idProces
* Prosty interpreter warunku
Rezultat:
Stabilna baza pod dalszy rozwój.
ETAP 2 Wielopoziomowe akceptacjeCel:
Obsługa kilku etapów zatwierdzania.
Rozszerzenia:
* Kolejność etapów (SequenceNo)
* Wiele reguł dla jednego idProces
* Tworzenie kolejnego zadania dopiero po zakończeniu poprzedniego
* Status dokumentu zależny od workflow
Nowe elementy danych:
* WorkflowInstance (instancja procesu)
* WorkflowStep (etapy)
Rezultat:
Mechanizm przestaje być pojedynczym triggerem, staje się procesem.
ETAP 3 Role zamiast operatorówCel:
Uniezależnienie workflow od konkretnych osób.
Zmiana:
Zamiast:
```
OperatorDocelowy = SP
```
Wprowadza się:
```
Rola = KierownikZakupów
```
System dynamicznie:
* wyszukuje użytkownika pełniącego rolę
* uwzględnia zastępstwa
Korzyści:
* brak konieczności zmiany reguł przy zmianach kadrowych
* większa skalowalność
ETAP 4 Silnik warunków (Condition Engine)Cel:
Rozbudowa logiki decyzyjnej.
Zamiast prostego:
```
Kwota >= 5000
```
Obsługa:
* AND / OR
* Typ dokumentu
* Kontrahent
* Waluta
* Projekt
* Centrum kosztów
* Operator tworzący (opcjonalnie)
Możliwość:
* przechowywania warunku jako wyrażenia
* wersjonowania reguł
To moment, gdy mechanizm zaczyna przypominać Rule Engine.
ETAP 5 Eskalacje czasoweCel:
Zabezpieczenie przed 'martwymi' zadaniami.
Dodaje się:
* SLA (np. 48h)
* przypomnienia
* przekazanie wyżej po czasie
* dashboard opóźnień
Wymaga:
* harmonogramu systemowego (AutoRun)
* monitorowania daty utworzenia zadania
ETAP 6 Workflow równoległyCel:
Obsługa wielu akceptujących jednocześnie.
Przykłady:
* 2 z 3 muszą zatwierdzić
* wszyscy muszą zatwierdzić
* pierwszy zamyka etap
Wymaga:
* grupy akceptujące
* logiki agregacji decyzji
ETAP 7 State Machine (model statusowy)Cel:
Pełna kontrola cyklu życia dokumentu.
Dokument przechodzi przez stany:
```
Roboczy
-> Do akceptacji
-> Odrzucony
-> Zatwierdzony
-> Zrealizowany
```
Każdy idProces:
* może być dozwolony tylko w określonym stanie
* może zmieniać stan
To znacznie zwiększa spójność systemu.
ETAP 8 Dashboard i monitoringCel:
Zarządzanie procesami.
Dodaje się:
* widok 'Moje zadania'
* widok 'Zadania podległych'
* widok 'Wąskie gardła'
* historia procesu
* raporty SLA
Workflow staje się narzędziem zarządczym.
ETAP 9 Workflow jako platforma systemowa
Na tym poziomie:
* każdy idProces może być objęty workflow
* workflow może wywoływać inne idProces automatycznie
* możliwa orkiestracja procesów między modułami
Staje się to:
> Silnik orkiestracji procesów w ERP
Strategia rozwoju (najważniejsze)
Rekomenduje się rozwój w tej kolejności:
1 Stabilne MVP
2 Wielopoziomowość
3 Role
4 Rozszerzony silnik warunków
5 Eskalacje
6 Równoległość
7 State machine
Kluczowa decyzja architektoniczna
Trzeba zdecydować:
Czy Workflow ma być:
* dodatkiem do funkcji (trigger po idProces)
czy
* centralnym silnikiem procesów w ERP
Druga opcja wymaga bardziej przemyślanej architektury, ale daje ogromne możliwości.
Docelowa architektura do której warto dążyć
Silnik powinien zawierać:
* Definicję procesu (WorkflowDefinition)
* Wersję procesu
* Instancję procesu
* Etapy procesu
* Zadania
* Historię
* Reguły przejść
* Silnik warunków
* Integrację z idProces
Największe ryzyka projektowe
1. Twarde przypisywanie operatorów
2. Brak wersjonowania reguł
3. Brak historii decyzji
4. Logika warunków zapisana na sztywno w kodzie
5. Brak kontroli stanu dokumentu
3. Workflow. Zamówienia zakupu
Wprowadzenie
Planowany mechanizm Workflow w programie Trawers ERP.
Mechanizm wykorzystuje obiekt idProces. Wewnętrzny (systemowy), unikalny identyfikator funkcji.
Każda wykonywana funkcja ma unikalny IdProces. Moze byc wywoływana z menu lub automatycznie np. w AutoRun.
Np. Rejestrowanie zamówień zakupu --> [ZA_DFA10].
Sytuacja
Mechanizm Workflow polega na przekazywaniu zadania (idProces) od jednego uczestnika,
tu: operatora do innego uczestnika, tu: kierownika tego operatora, gdy wystąpią okreslone warunki.
Np. gdy operator AA zarejestruje zamówienie zakupu, to operator SP (kierownik) powinien
zaakceptowac zamowienie, gdy wartosc jest rowna lub przekracza 5000 zl.
Opis ogolny
Gdy operator AA wykona idProces [ZA_DFA10] (zarejestruje zamówienie) i kwota >= 5000, to wpisujemy
zadanie, ktore wskazuje, że operator SP powinien wykonac akceptację zamówienia, tzn. idproces [ZA_DAC10].
Gdy SP operator zaloguje się do Trawers ERP, to otrzyma powiadomienie o czekającym go zadaniu.
Po wykonaniu idProces [ZA_DAC10] (akceptacji zamówienia) przez SP, zamówienie może przejść
do kolejnego etapu, np. zamówienie można wysłać do dostawcy
Czy opisany mechanizm możę być schematem do definiowania kolejnych podobnych mechanizmów workflow ?
(AsystentAI)
Opisany mechanizm Workflow w Trawers ERP może być skutecznym schematem do definiowania
kolejnych, podobnych mechanizmów Workflow.
Struktura daje możliwość elastycznego rozszerzania na inne procesy w systemie.
3.1 Kluczowe elementy mechanizmu Workflow
* Identyfikator procesu (idProces):
Każda funkcja w systemie ma unikalny identyfikator (np. [ZA_DFA10] dla rejestracji zamówień zakupu).
To zapewnia jednoznaczne wskazanie, które operacje mają być kontrolowane w ramach Workflow.
* Zasady wyzwalania Workflow:
Workflow uruchamia się na podstawie określonych warunków, takich jak:
* Kto wykonał idProces (np. operator AA).
* Parametry związane z procesem (np. kwota zamówienia >= 5000 zł).
* Delegowanie zadania:
Gdy spełnione są warunki wyzwalające, zadanie (idProces) jest przypisywane innemu
uczestnikowi procesu (np. operatorowi SP do akceptacji).
* Powiadomienia:
Operator odpowiedzialny za kolejne zadanie otrzymuje informację o nowym zadaniu
podczas logowania do systemu.
* Przepływ między etapami:
Po wykonaniu przydzielonego zadania Workflow może przejść do kolejnego etapu,
np. zatwierdzenie umożliwia wysyłkę zamówienia.
3.2 Rozszerzalność schematu
Mechanizm można łatwo rozbudować, stosując ten schemat do innych procesów:
1. Definiowanie procesów:
* Określenie identyfikatora procesu wyzwalającego (np. [ZA_DFA10]).
* Określenie warunków (np. kwota, status dokumentu, operator).
* Zdefiniowanie procesu, który ma być wykonany w odpowiedzi (np. [ZA_DAC10]).
2. Warunki zależne od różnych parametrów:
* Różne wartości progowe, np. 10 000 zł dla wyższych poziomów zatwierdzeń.
* Przypisanie do różnych użytkowników w zależności od typu dokumentu.
3. Automatyczne powiadomienia:
* Generowanie powiadomień dla uczestników.
* Możliwość śledzenia zadań w centralnym widoku zadań (np. tablica Workflow).
4. Obsługa wielu uczestników:
* Hierarchiczne zatwierdzanie (np. operator -> kierownik -> dyrektor).
* Równoległe zadania (np. akceptacja przez kilku operatorów jednocześnie).
3.3 Potencjalne korzyści
* Automatyzacja i usprawnienie procesów:
Workflow zmniejsza ryzyko pominięcia ważnych etapów procesów biznesowych.
* Przejrzystość i kontrola:
Operatorzy i kierownicy mają jasny wgląd w oczekujące zadania.
* Elastyczność:
Mechanizm można łatwo dostosować do specyfiki różnych procesów.
3.4 Sugestie dotyczące implementacji
* Rejestracja historii Workflow:
Warto wprowadzić logowanie historii Workflow (kto, kiedy, co wykonał) dla lepszej kontroli i audytów.
* Centralne zarządzanie regułami Workflow:
Opracowanie modułu zarządzania regułami, gdzie administrator może definiować warunki
i przypisania bez konieczności modyfikacji kodu.
* Integracja z istniejącymi modułami:
Mechanizm powinien być spójny z funkcjami logowania użytkowników
i zarządzania uprawnieniami w systemie.
Mechanizm opisany w tym schemacie jest dobrze przemyślany i może służyć
jako podstawa do tworzenia bardziej złożonych procesów Workflow w Trawers ERP.
Rozszerzenie go o elementy takie jak centralne zarządzanie regułami czy logi
zwiększy jego wartość i użyteczność.
4. Model danych i model funkcjonalny (1)
Aby zrealizować mechanizm Workflow w systemie Trawers ERP, konieczne jest zaprojektowanie
odpowiednich modeli danych oraz funkcjonalnych.
Poniżej jest propozycja takich modeli:
4.1 Model danych:
W systemie Trawers ERP każda funkcja posiada unikalny identyfikator procesu (IdProces).
Aby śledzić i zarządzać przepływem zadań między operatorami, można wprowadzić
dodatkowe tabele w bazie danych:
1. Tabela `Procesy`:
* idProces: Unikalny identyfikator procesu (np. `[ZA_DFA10]`).
* NazwaProcesu: Opis procesu (np. 'Rejestrowanie zamówień zakupu').
* Opis: Szczegółowy opis funkcji procesu.
2. Tabela `ZadaniaWorkflow`:
* idZadania: Unikalny identyfikator zadania.
* idProces: Identyfikator procesu powiązanego z zadaniem.
* OperatorŹródłowy: Identyfikator operatora inicjującego proces (np. 'AA').
* OperatorDocelowy: Identyfikator operatora odpowiedzialnego za wykonanie kolejnego etapu (np. 'SP').
* StatusZadania: Status zadania (np. 'Oczekujące', 'W trakcie', 'Zakończone').
* DataUtworzenia: Data i czas utworzenia zadania.
* DataZakonczenia: Data i czas zakończenia zadania (jeśli dotyczy).
3. Tabela `RegułyWorkflow`:
* idReguły: Unikalny identyfikator reguły.
* idProcesWyzwalający: Identyfikator procesu, który wyzwala regułę (np. `[ZA_DFA10]`).
* Warunek: Warunek logiczny do spełnienia (np. 'Kwota >= 5000').
* idProcesDocelowy: Identyfikator procesu do wykonania po spełnieniu warunku (np. `[ZA_DAC10]`).
* OperatorDocelowy: Identyfikator operatora odpowiedzialnego za proces docelowy (np. 'SP').
4.2 Model funkcjonalny:
1. Definiowanie reguł Workflow:
* Administrator systemu definiuje w tabeli `RegułyWorkflow` zależności między procesami,
warunkami ich wyzwalania oraz przypisaniem operatorów odpowiedzialnych za kolejne etapy.
2. Inicjacja procesu:
* Operator (np. 'AA') wykonuje proces o określonym *idProces* (np. `[ZA_DFA10]`).
3. Sprawdzenie warunków:
* System sprawdza, czy dla wykonanego procesu istnieje reguła w `RegułyWorkflow`
oraz czy spełnione są określone warunki (np. kwota zamówienia >= 5000 zł).
4. Utworzenie zadania:
* Jeśli warunki są spełnione, system tworzy nowe zadanie w tabeli `ZadaniaWorkflow`,
przypisując je do operatora docelowego (np. 'SP') z odpowiednim *idProces* do wykonania (np. `[ZA_DAC10]`).
5. Powiadomienie operatora:
* Operator 'SP' po zalogowaniu do systemu otrzymuje powiadomienie o nowym zadaniu do wykonania.
6. Wykonanie zadania:
* Operator 'SP' wykonuje przypisany proces (np. akceptacja zamówienia).
7. Aktualizacja statusu:
* Po zakończeniu zadania system aktualizuje status w tabeli `ZadaniaWorkflow`
na 'Zakończone' oraz rejestruje datę zakończenia.
8. Przejście do kolejnego etapu:
* Zakończenie zadania może wyzwalać kolejne procesy w Workflow,
zgodnie z zdefiniowanymi regułami.
Implementacja takiego modelu wymaga integracji z istniejącymi modułami Trawers ERP
oraz dostosowania interfejsu użytkownika w celu efektywnego zarządzania zadaniami Workflow.
5. Model danych i model funkcjonalny (2)
Model danych i model funkcjonalny do zmodyfikowanego mechanizmu.
Zmiana polega na tym, że nie wskazujemy operatora inicjującego.
Kazdy operator inicjujący proces: tu [ZA_DFA10] tworzy zadanie dla operatora docelowego.
Pozostałe elementy bez zmiany.
5.1 Zmodyfikowany model danych
Tabela `Procesy`
Bez zmian:
* idProces: Unikalny identyfikator procesu (np. `[ZA_DFA10]`).
* NazwaProcesu: Opis procesu (np. 'Rejestrowanie zamówień zakupu').
* Opis: Szczegółowy opis funkcji procesu.
Tabela `ZadaniaWorkflow`
Zmiana: Usunięcie kolumny `OperatorŹródłowy` i dostosowanie opisu:
* idZadania: Unikalny identyfikator zadania.
* idProces: Identyfikator procesu powiązanego z zadaniem.
* OperatorDocelowy: Identyfikator operatora odpowiedzialnego
za wykonanie kolejnego etapu (np. 'SP').
* StatusZadania: Status zadania (np. 'Oczekujące', 'W trakcie', 'Zakończone').
* DataUtworzenia: Data i czas utworzenia zadania.
* DataZakonczenia: Data i czas zakończenia zadania (jeśli dotyczy).
Tabela `RegułyWorkflow`
Zmiana: Usunięcie zależności od operatora inicjującego:
* idReguły: Unikalny identyfikator reguły.
* idProcesWyzwalający: Identyfikator procesu, który wyzwala regułę (np. `[ZA_DFA10]`).
* Warunek: Warunek logiczny do spełnienia (np. 'Kwota >= 5000').
* idProcesDocelowy: Identyfikator procesu do wykonania po spełnieniu warunku (np. `[ZA_DAC10]`).
* OperatorDocelowy: Identyfikator operatora odpowiedzialnego za proces docelowy (np. 'SP').
5.2 Zmodyfikowany model funkcjonalny
Etapy działania Workflow:
1. Definiowanie reguł Workflow:
* Administrator definiuje w tabeli `RegułyWorkflow` zasady przypisywania zadań:
* Proces wyzwalający (np. [ZA_DFA10]).
* Warunki wyzwalania (np. kwota >= 5000 zł).
* Operator docelowy odpowiedzialny za kolejny etap (np. 'SP').
* Proces docelowy do wykonania (np. [ZA_DAC10]).
2. Inicjacja procesu:
* Każdy operator w systemie wykonuje proces o określonym *idProces* (np. [ZA_DFA10]).
3. Sprawdzenie warunków:
* System sprawdza, czy istnieje reguła w `RegułyWorkflow` dla wykonanego procesu
oraz czy spełnione są określone warunki (np. kwota >= 5000 zł).
4. Utworzenie zadania:
* Jeśli warunki są spełnione, system automatycznie tworzy zadanie w tabeli `ZadaniaWorkflow`,
przypisując je do operatora docelowego (np. 'SP').
5. Powiadomienie operatora:
* Operator 'SP' po zalogowaniu do systemu otrzymuje powiadomienie o nowym zadaniu do wykonania.
6. Wykonanie zadania:
* Operator 'SP' wykonuje przypisany proces (np. akceptacja zamówienia).
7. Aktualizacja statusu:
* Po zakończeniu zadania system aktualizuje status w tabeli `ZadaniaWorkflow`
na 'Zakończone' oraz rejestruje datę zakończenia.
8. Przejście do kolejnego etapu:
* Zakończenie zadania może wyzwalać kolejne procesy w Workflow, zgodnie z zdefiniowanymi regułami.
5.3 Różnice w implementacji:
* Brak operatora inicjującego w regułach i zadaniach:
* Mechanizm staje się bardziej ogólny, ponieważ dowolny operator wykonujący proces [ZA_DFA10]
automatycznie wyzwala zadanie dla operatora docelowego.
* Jednolitość i łatwość rozbudowy:
* Dzięki wyeliminowaniu zależności od operatora inicjującego łatwiej można zdefiniować reguły,
które działają w sposób uniwersalny.
* Unifikacja logiki warunków:
* Warunki w tabeli `RegułyWorkflow` mogą być stosowane niezależnie od tego, kto zainicjował proces.
Taki model jest bardziej uniwersalny i pozwala na większą elastyczność w definiowaniu
procesów Workflow w systemie Trawers ERP.