Kiedy używać silników przepływu pracy?

Pracowałem w przeszłości nad niektórymi silnikami przepływu pracy jako programista, ale nigdy nie miałem jasności, dlaczego wybraliśmy silniki przepływu pracy na pierwszym miejscu. Jako programista wiem, że istnieje co najmniej 100 sposobów na zrobienie czegokolwiek podczas pisania kodu, ale tylko nieliczne są najlepsze!

Nadal nie rozumiem, które przypadki użycia najlepiej rozwiązać za pomocą silników przepływu pracy (a raczej ich koncepcji) niż projektowanie dobrej aplikacji z obsługą DI. Szukam jakiejkolwiek ogólnej charakterystyki przypadków użycia niezależnych od domeny, w których silniki przepływu pracy są jedną z najlepszych opcji.

Moje pytanie brzmi zatem: jakie są ogólne cechy wymagania, które można uznać za sygnał wyboru silnego silnika przepływu pracy i kodowania go?

Mechanizm przepływu pracy jest przydatny, gdy trzeba przejść od początku do końca, ale istnieje wiele różnych ścieżek / logiki / reguł.

Załóżmy na przykład, że piszę program, który publikuje treści. Tak więc w moim przypadku publikacja przechodzi proces weryfikacji, legalny, a następnie ostateczne zatwierdzenie. Piszę program, wdrażając moją logikę procesu i kroki. Teraz działa to świetnie dla mnie i mojej firmy. Dlatego postanawiam, że inni powinni korzystać z mojego programu.

Niestety nie wszyscy publikują treści przy użyciu tego samego procesu, więc zamiast pisać osobne procesy dla każdego innego przypadku, wdrożylibyśmy proces przepływu pracy, aby program był elastyczny dla wszystkich. Bez względu na to, ile kroków, reguł lub logiki znajduje się między tymi dwoma punktami, wynik jest taki sam.

Tak więc, jeśli masz procesy, które są zmienne od początku do końca, użyj przepływu pracy. Jeśli wszyscy mogą korzystać z tego samego procesu, nie potrzebujesz przepływu pracy.

Wiem, że poprosiłeś o przypadki użycia, ale łatwiej jest wymienić zalety niż wyobrazić sobie wszystkie możliwe przypadki użycia. Zalety oczywiście zależą od silnika i języka, który porównujesz, ale ogólnie:

1. Zachowanie reguł jako danych zamiast kodu oznacza, że ​​nie musisz ponownie kompilować, więc możesz szybko testować zmiany, zmieniać je w czasie wykonywania itp. Niewielka korzyść, jeśli nie musisz rekompilować w pierwszej kolejności.

2. Można zasadnie oczekiwać, że użytkownicy będą edytować reguły. Potencjalnie mogą manipulować nimi interaktywnie w sposób, który nie jest wykonalny, gdy programiści piszą dla nich kod.

3. Zachowanie reguł jako danych pozwala na pisanie narzędzi do wizualizacji i zmiany danych.

4. Zachowywanie reguł jako danych pozwala na łatwiejsze metaprogramowanie - możesz napisać kod do analizy danych i wstawić bardziej skomplikowany sposób, co byłoby bardzo trudne dla kodu.

Wszystkie te rzeczy można zrobić bezpośrednio z kodem (np. - napisać parser C #, aby znaleźć wszystkie reguły określonego typu i wygenerować kod dla większej liczby reguł, wstawić go dynamicznie do zestawu w sposób, który umożliwia rozładowanie zestawu, napisać narzędzia do użytkownicy również mogą to zrobić za pomocą wizualizatora i edytora), ale może to być znacznie trudniejsze w zależności od języka (programiści używający Lisp mogą odnosić się do punktów 1-4 jako „programowanie”).

IMHO Jedynym przypadkiem, w którym powinieneś użyć tego rodzaju rzeczy, jest to, że mogą ją skonfigurować mniej wartościowi użytkownicy. Jeśli możesz rozwiązać problem, dając mu narzędzie, a następnie wróć do pracy nad czymś ważniejszym, użyj jednego.

Jeśli nadal musisz je dla nich skonfigurować, wyobrażam sobie, że możesz pomyśleć o 10 różnych sposobach uzyskania tego samego rezultatu za pomocą narzędzia, które znasz i będzie o wiele łatwiejsze do obsługi i dostosowywania.

To wygląda jak stare pytanie, ale pojawia się wiele razy na wolności. Zgadzam się z odpowiedzią Jona . Stwierdziłem, że silniki przepływu pracy są bardzo wydajne w następujących scenariuszach:

1. Istnieje podstawowy proces biznesowy, który próbujesz reprezentować / wdrożyć za pomocą swojego oprogramowania.
2. Istnieje jeden (być może złożony) podmiot gospodarczy, nad którym pracuje się na wszystkich lub niektórych etapach procesu. W podanym przez Jon przykładzie ten byt lub Element przepływu pracy byłby treścią lub artykułem. Rozważ śledzenie błędów jako kolejny przykład przepływu pracy, błąd przechodzi między różnymi stanami w oparciu o działanie, które użytkownik podejmuje.
3. Przepływy pracy służą do modelowania procesów, tylko jeśli oczekujesz zmiany procesu biznesowego, przez zmianę rozumiem sekwencję lub akcję wykonaną w wyniku akcji użytkownika lub przejścia.

Bądź bardzo ostrożny i krytyczny, aby sprawdzić, czy Twoja problematyczna domena / wymagania zawiera proces biznesowy, nie próbuj „dopasowywać” go do przepływu pracy.

Mam kilka wskazówek, których używam do sugerowania silników przepływu pracy.

1) Gdy analitycy biznesowi nie mają podstaw kodowania, ale mogą rysować diagramy.

Nowoczesne silniki przepływu pracy używają notacji modelowania procesów biznesowych lub mniej wydajnych wersji dostępnych w SharePoint i podobnych systemach. Pozwalają one technicznie kompetentnym, ale wymagającym od programistów członkom zespołu zaprojektować i rozwinąć wiele przepływów pracy.

2) Gdy musisz monitorować postęp pracy, wykonuj eskalacje, przewijaj w obie strony między procesami sterowanymi przez komputer a procesami kontrolowanymi przez człowieka.

Monitorowanie i samooceny są cechami charakterystycznymi nowoczesnych silników przepływu pracy.

Z biznesowego punktu widzenia silniki przepływu pracy są bardzo ważne.

1. Zapewniają ustrukturyzowany proces, nawet jeśli za każdym razem jest taki sam.

2. Zapewniają przejrzystość

   • Kto poprosił o zmianę,
   • Kiedy było wymagane
   • Kto zatwierdził itp.

   Ta przejrzystość pomaga w kierowaniu procesem i promuje własność.

Zakładając, że formularze są zintegrowane i inteligentne, wspierając logikę biznesową, ma to również dramatyczny wpływ na oś czasu, wydajność przetwarzania i jakość danych. Należy również wziąć pod uwagę bezpieczeństwo, a zawieranie poufnych informacji w bezpiecznym systemie jest znacznie lepsze niż papierowe formularze czekające na podpis. Jest także znacznie bardziej mobilny. Po niedawnym wdrożeniu jeden menedżer powiedział mi, że zaoszczędziło mu to wielu kłopotów z wysyłaniem do niego rzeczy do podpisania, ponieważ dużo podróżował.

W imieniu HR: długi przepływ pracy !!!