Jaka jest wartość narzędzi przepływu pracy? [Zamknięte]

Jestem nowy w rozwoju Workflow i nie sądzę, że naprawdę dostaję „duży obraz”. A może inaczej mówiąc, narzędzia te obecnie nie „klikają” w mojej głowie.

Wydaje się więc, że firmy lubią tworzyć rysunki biznesowe opisujące procesy, a w pewnym momencie ktoś zdecydował, że może użyć automatu stanowego, takiego jak program, do faktycznego sterowania procesami z linii i pól takich jak diagram. Dziesięć lat później te narzędzia są ogromne, niezwykle skomplikowane (moja firma obecnie bawi się z WebSphere, a ja uczestniczyłem w niektórych szkoleniach, to potwór, nawet tak zwane „minimalistyczne” wersje tych narzędzi przepływu pracy, takie jak Activiti, są ogromny i skomplikowany, choć nie tak skomplikowany jak bestia, która jest afaiksem WebSphere)

Jaka jest wielka korzyść z robienia tego w ten sposób? Rozumiem, że proste diagramy linii i ramek są przydatne, ale o ile mi wiadomo, w tym momencie są to wizualne języki programowania, wraz z warunkowymi i pętlami. Wydaje się, że programiści wykonują znaczną ilość pracy w warstwie linii i ramek, co dla mnie wygląda jak naprawdę kiepski, naprawdę podstawowy wizualny język programowania.

Jeśli masz zamiar posunąć się tak daleko, dlaczego nie użyć jakiegoś języka skryptowego? Czy ludzie wyrzucili dziecko z kąpielą? Czy linie i pola zostały przeniesione na absurdalny poziom, czy po prostu nie rozumiem wartości tego wszystkiego?

Naprawdę chciałbym zobaczyć argumenty w obronie tego przez ludzi, którzy pracowali z tą technologią i rozumiem, dlaczego jest ona przydatna. Nie widzę w tym wartości, ale zdaję sobie sprawę, że też jestem nowy i może jeszcze nie do końca ją rozumiem.

Z punktu widzenia dewelopera masz rację mówiąc, że te „wizualne” środowiska są naprawdę trudne do pracy. Przepływy pracy programu SharePoint 2010, z których korzystam, rzucają wszelkie najlepsze praktyki związane z tworzeniem dobrego oprogramowania dla przedsiębiorstw - bez zautomatyzowanych testów, bez ponownego użycia kodu, nieczytelnego oprogramowania ... Wszystko, co jest bardziej skomplikowane niż gotowy szablon, może być bolesne w utrzymaniu , jak doświadczasz.

Ale z punktu widzenia biznesu przepływy pracy przynoszą ogromne korzyści - przynajmniej teoretycznie. Cytując z tej białej księgi , wydajność, odpowiedzialność, kontrola i łatwość użycia zautomatyzowanego przepływu pracy zapewniają ogromny wzrost wydajności. Wyobraź sobie, o ile bardziej nieefektywny byłby prosty proces zatwierdzania lub wdrażania bez tej automatyzacji. Również samo zdefiniowanie przepływu pracy jest cenne dla organizacji, która próbuje przejąć kontrolę nad swoimi procesami biznesowymi.

Obecny stan oprogramowania do przepływu pracy nie jest winą firmy. Chcą tylko ułatwić sobie życie, a przepływy pracy są do tego świetne. Najbardziej winiłbym nas, dział IT:

1. Za to, że firma nie jest bardziej przejrzysta w kwestii złożoności i kruchości systemu. Ukrywamy całą złożoność.
2. Za niemożność „podrapania się” dzięki intuicyjnym, prostym rozwiązaniom przepływu pracy. Jest to prawdopodobnie bardziej rant w stosunku do dużych pakietów korporacyjnych, takich jak SharePoint i SAP, ale są one lepsze niż dostępne tam niestandardowe rozwiązania

Jest tylko jedna prawdziwa korzyść, ale ogromna: oddzielenie obaw .

Tak więc zamiast logiki organizacji procesu wbudowanej w nasz system, staje się ona konfiguracją zewnętrzną. Zasadniczo mapa. Możesz to zmienić (znacznie więcej) niezależnie, możesz mieć wiele procesów, wiele wersji procesów, wiele wersji wielu procesów działających w tym samym czasie, i to wszystko jest gotowe od każdego porządnego rozwiązania.

Historycznie koncepcja SoC wielokrotnie wygrywała - zaczynając od zasady uniksowej „zrób jedną rzecz, ale zrób to dobrze”, i stosuj ją wielokrotnie - jak posiadanie dedykowanych komponentów serwerowych, takich jak ESB, różne systemy utrzymywania, buforowanie, równoważenie obciążenia , monitorowanie, np. dzielenie CSS z HTML itp.

Proces biznesowy i reguły przepływu są często ortogonalne w stosunku do danych, „ekranów” interfejsu użytkownika lub „hierarchii” użytkowników. Dlatego warto go rozwijać i zmieniać oddzielnie od innych aspektów systemu. To była przesłanka, na której BPM pojawił się na początku lat 90.

Od tego czasu stworzono wiele narzędzi i języków do obsługi tej koncepcji, z których najbardziej znany to BPMN - język graficzny do tworzenia „schematów blokowych”, które bezpośrednio mapują procesy. Podczas gdy ludzie narzekają, że jest duży i nieporęczny (ma ponad 100 symboli w słownictwie) i opowiada się za nowoczesnymi podejściami, takimi jak S-BPM (ma tylko 5 podstawowych symboli), obecna praktyka branżowa polega na trzymaniu się BPMN lub jego pochodnych, podzbiorów lub rodzeństwa.

Nie wyglądasz na zadowolonego z BPMN:

Wydaje się, że programiści wykonują znaczną ilość pracy w warstwie linii i ramek, co dla mnie wygląda jak naprawdę kiepski, naprawdę podstawowy wizualny język programowania.

Ale nie jest tak źle) Za tym stoi teoria. Wersja 2.0 miała dobry wgląd w niedociągnięcia 1.0.

Jeśli masz zamiar posunąć się tak daleko, dlaczego nie użyć jakiegoś języka skryptowego?

Imperatywny paradygmat i języki skryptowe nie zawsze są najlepszą odpowiedzią. Jak zapewne widzieliście w językach deklaratywnych (takich jak HTML, CSS, SQL, Drools lub wewnętrzne Nginx, Graddle i Maven, Puppet itp.), Wynikowy kod może być znacznie mniejszy i czystszy niż wersja napisana w „ porządnym języku, jak Java lub C ++ ”.

Co do twojego drugiego punktu:

O ile wiem, w tym momencie są to wizualne języki programowania, w tym warunkowe i pętle.

spojrzałeś na Wydarzenia i Wyzwalacze ? BPMN to język i musisz się go nauczyć przed użyciem lub przynajmniej się z nim zapoznać.

Pod maską BPMN to XML, więc możesz edytować go ręcznie lub generować. Możesz kontrolować ich wersję, ponieważ XML jest oparty na tekście. Jednak posiadanie kodu XML, który można przetłumaczyć na schematy blokowe, nie brzmi jak pomoc goona, i to jest poprawne - napisanie własnego parsera lub edytora jest trudne i kosztowne zadanie z wątpliwymi korzyściami.

Na szczęście istnieją już na rynku narzędzia, które to właśnie robią.

Activiti jest bezpłatny i dość popularny zarówno wśród deweloperów, jak i właścicieli firm, ze względu na jego początkową cenę ( zero ), dostępność informacji i pokorę. Ostatni punkt jest naprawdę wyjątkowy, ponieważ Activi koncentruje się wyłącznie na zarządzaniu procesami biznesowymi, bez konieczności wiązania się z rozwiązaniami obejmującymi cały pakiet. Ponadto jest otwarty - wystarczy znać Java i REST, aby go uruchomić. Wadą jest to, że po stronie klienta, integracja i logika aplikacji / biznesu oraz cała architektura są pozostawione programistom, więc jeśli twój zespół ds. Rozwoju jest słaby - przygotuj się na porażkę. Całkowity koszt posiadania może być zaskakująco wysoki dla darmowego narzędzia;)

Po drugiej stronie spektrum znajduje się Pega (Pega PRPC), królujący w systemach BPM (według Gartnera i Forestera), który wygląda zaskakująco dobrze jak na swój wiek. Ten potwór z umywalką kuchenną jest nawet w stanie obsługiwać CRM, OCR i (jeśli się nie mylę) funkcje rozpoznawania mowy, analizy predykcyjne, zarządzanie regułami biznesowymi i edytor WYSIWYG UI. Ma jednak poważną cenę. Nie tylko kosztuje fortunę, ale cały rozwój odbywa się w aplikacji internetowej, co oznacza, że ​​musisz korzystać z przeglądarki, którą jest IE8 (plus niektóre wtyczki i brzydkie włamania, takie jak edytowanie tabel danych w programie Excel). Ponadto przeglądarka internetowa wykonuje również edycję Java, JavaScript lub HTML / CSS - więc pożegnaj się z testami jednostkowymi, podświetlaniem kodu IDE, refaktoryzacją i wszystkimi zabawkami programistycznymi, które pokochałeś.

Dobra strona tego? możesz wdrożyć złożony system W CIĄGU TYGODNI [ PDF , patrz strona 22]. I tak, wynik nie jest gwarantowany.

IBM niedawno (zgodnie z tempem czasu dla przedsiębiorstw) kupił Lombardi i oferuje teraz bardzo konkurencyjne rozwiązanie (ale wtedy trzeba będzie wszystko kupić ibm ). Appian to młody sprzedawca, który ma ciekawe spostrzeżenia i pozytywne opinie, ale sposób, w jaki zostały napisane (dwa dodatkowe języki DSL oprócz języka wizualnego) po prostu mi się nie podoba.

Są inni gracze i ich rozwiązania. Większość z nich jest po prostu okropna. Na przykład - twoje oczy, mózg i serce dosłownie krwawią, gdy tylko na nie spojrzysz. Ufaj więc sobie i nie zniechęcaj programistów i użytkowników.

Notatka końcowa:

System BPM jest taki sam dla procesów, co Photoshop dla obrazów. Nie bój się, że jest wizualny. Nie zmuszaj go do wykonywania pracy nieodpowiedniej (pamiętasz strony internetowe utworzone w całości w Photoshopie, których edytowanie było prawie niemożliwe?). Uprość to i nie rób błędów;)

Wiele lat temu, zanim większość z nas się urodziła, programiści musieli napisać własny kod do przechowywania danych. Jeśli trzeba było zapisać stan programu, cóż, było to postrzegane jako część funkcji kodu, tak wielu programistów napisało kod, aby uporządkować dane oraz zapisać i odczytać i tak dalej.

I wtedy ktoś zdał sobie sprawę, że to się często zdarzyło - logika zapisywania, organizowania, odczytywania i wyszukiwania danych była w rzeczywistości składnikiem tak często używanym, że powinien to być własny. I mamy bazy danych.

W ciągu ostatnich 10–15 lat działy IT zdawały sobie sprawę, że logika do choreografów i / lub koordynowania procesów biznesowych jest tak powszechna, że ​​powinna to być również jej własna część, co doprowadziło do powstania różnego rodzaju różnych narzędzi przepływu pracy.

Istnieją 3 podstawowe zalety narzędzia przepływu pracy:

1. Czas potrzebny na wprowadzenie i wdrożenie zmian : możesz opracować i zmienić logikę przepływu pracy bez takich samych zagrożeń technicznych, jakie wiążą się ze zmianą fragmentu kodu.
2. Przejrzystość : logika biznesowa w systemie opartym na BPM jest natychmiast dostępna i czytelna dla analityka biznesowego, podczas gdy tylko programiści będą mogli odczytać logikę biznesową w systemach „opartych na kodzie”.
3. Ponowne wykorzystanie komponentów technicznych : narzędzia BPM są często używane w połączeniu z systemami o architekturze zorientowanej na usługi. Oddzielając logikę biznesową od komponentów technicznych - szczególnie w systemach korporacyjnych, które muszą implementować setki lub tysiące różnych procesów biznesowych - możesz ponownie wykorzystać komponenty techniczne, poświęcając stosunkowo mało czasu na rozwój logiki biznesowej (z przepływem pracy narzędzie).

Jednak jednym z najczęstszych problemów, na jakie napotykam podczas pracy i używania narzędzi BPM, jest to, że programiści nadal próbują „zakopać” logikę biznesową w nieprzejrzystym kodzie.

Cały czas widzę, że programiści wciąż starają się dodawać logikę biznesową w najbardziej techniczny sposób, zamiast w najbardziej przejrzysty sposób. Jest to naturalne, ponieważ programiści ze swojej natury są znacznie bardziej zadowoleni z kodu niż z narzędzia przepływu pracy. Co więcej, im więcej logiki zachowujesz w sposób techniczny, tym bardziej będziesz potrzebny jako programista. Niestety, jest to najgorsza rzecz, jaką programista może zrobić z systemem BPM, ponieważ podważa on podstawowe zalety korzystania z BPM.

Wreszcie, większość narzędzi BPM nie jest wystarczająco daleko, aby analitycy biznesowi mogli sami opracowywać przepływy pracy: jednak taki jest cel. Idealnie, analitycy biznesowi opracowaliby schematy przepływu pracy / diagramy procesów biznesowych, a programiści pracowaliby tylko nad komponentami technicznymi wywoływanymi przez silnik przepływu pracy.

Poniższe stwierdzenia przedstawiają moje osobiste doświadczenia związane z korzystaniem z narzędzi przepływu pracy, w szczególności Oracle BPM Suite (10.3G i 11G). Po pierwsze, twoje pytanie koncentruje się na narzędziach przepływu pracy, które umożliwiają modelowanie wykonywalnych modeli procesów, narzędzia te są częścią systemów zarządzania procesami biznesowymi (BPMS). To konkretne modelowanie procesów zdecydowanie się rozwija i można go nazwać wizualnym językiem programowania.

Główną korzyścią jest sprawność zrozumienia i zmiany logiki procesu

Modele procesów biznesowych obejmują wizualne objaśnienie logiki procesu, a jednocześnie wykonywalny komponent integracyjny. Pozwala to na szybsze włączanie i wyłączanie programistów, ponieważ mniej dokumentacji na temat przejść, warunków (bramek lub reguł biznesowych) i ogólnie procesu należy udokumentować, ponieważ jest to część rozwoju.

Dodatkowo masz dołączone funkcje raportowania / monitorowania, które musisz opracować indywidualnie dla każdej aplikacji, która jest objęta większością BPMS.

Ponadto w większości środowisk programistycznych BPM adaptery usług są wstępnie wbudowane (np. JMS, usługi sieciowe, JDBC itp.), Co umożliwia szybsze tworzenie rozwiązań oprogramowania pośredniego krok po kroku w interaktywnej integracji, redukując ludzkie błędy w kodowaniu.

Następująca platforma przepływu pracy zapewnia wiele korzyści wymienionych powyżej - oparte na platformie podejście do automatyzacji przepływów pracy

Wartość

Propozycja wartości polega na tym, że przepływy pracy mogą być tworzone lub zmieniane szybko i łatwo, w zależności od zmieniającego się charakteru firmy. Ważną częścią realizacji tej propozycji wartości jest to, że same procesy biznesowe są jednostkami zasobów w systemie.

Przepływy pracy jako jednostki zasobów oznaczają, że proces biznesowy jest zdefiniowany jako pojedyncza „jednostka”. Aby zrozumieć, co mam na myśli, rozważ dowolny program komputerowy napisany dla firmy. Z pewnością implementuje proces biznesowy, ale logika tego procesu prawdopodobnie będzie w pewnym stopniu rozłożona na kod źródłowy. Narzędzie przepływu pracy powinno umożliwiać zdefiniowanie procesu w jednym dobrze zamkniętym miejscu. Może to być jeden plik konfiguracyjny lub wyodrębniony z jednego wizualnego schematu, lub może to oznaczać, że przepływ pracy jest w jednym module kodu, który można podłączyć, a nawet zamienić lub skonfigurować na bieżąco.

Dlaczego Wartość może nie zostać zrealizowana

Ta propozycja wartości może zostać podważona przez trudność obejmowania przypadków nie waniliowych, integrację z technologią interfejsu użytkownika, która zmienia się bardzo szybko, złe praktyki, takie jak używanie narzędzia przepływu pracy jako samego opakowania i wprowadzanie prawdziwej logiki do kodu.

Niewłaściwy projekt samych narzędzi może być czynnikiem ograniczającym. Przykładem może być narzędzie, które wymaga, aby wszystkie parametry przekazywane między procesami znajdowały się w Mapie Java, z ograniczeniami co do wartości, które można faktycznie umieścić na mapie, zamiast zwykłych starych parametrów metody (myślę o jednym z bardziej szczególnie popularne narzędzia, które to robią).

Myślę, że prawdopodobnie uczciwie jest powiedzieć, że IBM jako duży gracz z dużym ekosystemem technologicznym, działa lepiej niż inni. Jeśli kontrolują również technologię interfejsu użytkownika oraz technologię baz danych i SOA, która jest używana w połączeniu z narzędziem przepływu pracy, mają większą szansę na wymyślenie ekosystemu, który ładnie się ze sobą integruje, i stwarza szansę na prawdziwe wykorzystanie ten pomysł.

Z pewnością prawdą jest, że wysiłek napisania interfejsu między narzędziem przepływu pracy a innymi częściami systemu może całkowicie negować całą propozycję wartości. Zawsze warto zastanowić się, czy istnieje lepszy sposób robienia rzeczy.

Programowanie to przepływ pracy

Prawda jest taka, że ​​programowanie (przynajmniej w językach imperatywnych) JUŻ DZIAŁA. Być może masz kod implementujący przepływ pracy związany z obsługą technologii systemowej; uzyskiwanie dostępu do plików i uruchamianie zapytań SQL itd. Być może masz kod, który implementuje biznesowy przepływ pracy; ustawianie stanu dokumentu i przekazywanie go na przykład recenzentowi.

Rozpoznanie tego i zaprojektowanie kodu w taki sposób, aby dokładnie rozdzielił te osobne problemy, jest trudne do rozwiązania, ale z pewnością można osiągnąć długą drogę.

Zgadzam się z tobą, czasem używamy tych narzędzi, ponieważ ktoś inny uznał, że to dobry pomysł, a są one zbyt skomplikowane i utrudniają nam pracę. Nie sądzę, że tak jest zawsze, należy dokładnie rozważyć, czy warto, czy nie.

Nie jest jasne, którego narzędzia używasz. Chyba masz na myśli ogólny zestaw narzędzi zwanych narzędziami do modelowania procesów biznesowych. Istnieje dobry powód do korzystania z takich narzędzi. Każda firma wysokiej jakości definiuje swoje funkcje w kategoriach procesów, a analitycy, a także eksperci biznesowi mogą wygodnie rysować takie procesy (dopóki nie powiążesz ich ze standardami ...). Możesz tworzyć takie procesy na poziomie koncepcyjnym bez znajomości programowania internetowego, a jeśli masz odpowiednie narzędzie, możesz być w stanie przekonwertować proces na działającą aplikację (doświadczeni ludzie muszą wejść na pokład, aby ta magia została wprowadzona do produkcji oczywiście). Więc pomysł jest dobry.

Celem narzędzi wizualnych jest nie tylko dokumentacja procesów. Korzystanie z narzędzi ma na celu pomóc profesjonalnym przeprojektować procesy, a czasem uruchomić symulacje, aby odkryć punkty, w których procesy są mniej wydajne niż jest to pożądane, aby można było wprowadzić plany usunięcia wąskich gardeł.

Istnieje obecnie standardowy sposób, z którego korzysta wiele firm, o nazwie BPMN 2.0 (Notacja modelowania procesów biznesowych). Zalecam zapoznanie się z tą notacją, jeśli Twoje narzędzie jej używa.

Baza wiedzy dotycząca zarządzania procesami biznesowymi jest znanym zasobem, który również warto rozważyć.

Powyższe dotyczy strony biznesowej. Strona techniczna wymaga SOA i BPEL, nie jestem jednak pewien, czy mogę udzielić porady na temat osób tu i teraz.

W prostym przykładzie według historii.

Era kamienia łupanego

Początkowo miałeś małe firmy menhirskie, w których ludzie właśnie mówili, co mają robić, i robili to. Czasami wszystko idzie źle, a osoba X lub Y są obwiniani (nigdy nie wiadomo, kto to zrobił).

Następnie wynaleziono Internet i e-mail.

Ludzie teraz pisali innym, co mają robić, a ci ludzie często mieli problemy ze swoim e-mailem, źle go czytali lub po prostu usunęli e-maila bez czytania; tak często rzeczy nie obwiniają za zły adres e-mail

Przepływ pracy ewoluował poza administrację Dzięki ujednoliceniu działań wreszcie ludzie mogli zobaczyć, na jakim etapie zatrzymano proces, a jednocześnie uzyskać cyfrowy przegląd tego, co faktycznie zostało zrobione. Działało to dobrze, dopóki ludzie nie chcieli zmienić standardowych procesów, lub dopóki jakaś nieznana osoba XY nie spowodowała niewłaściwego żądania bazy danych, powodując uszkodzenie bazy danych, wysyłając produkcję z powrotem do epoki kamienia.