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

22

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.

użytkownik16549
źródło
1
„Narzędzia przepływu pracy” to tylko „wizualne narzędzia programowania” i myślę, że ten post na blogu mówi wystarczająco dużo: blog.davor.se/blog/2012/09/09/Visual-programming
Doc Brown
1
Nie, narzędzia przepływu pracy, to narzędzia zastępujące papier i sposób, w jaki ludzie pracują w znormalizowany sposób. Pomyśl o szpitalu, czy nie byłoby wspaniale, gdyby wszystkie oficjalne dokumenty przechodziły równymi drogami, bez niektórych osób preferujących dokument X trasy lub bezpośrednio mówiąc / dzwoniąc na temat standaryzacji pracy, często wymaganej prawem.
user613326,
@ user613326: szczerze mówiąc, powinieneś przeczytać pytanie ponownie. Zajmuje się dokładnie tym, co napisałem - narzędziami przepływu pracy do kontrolowania i wykonywania przepływów pracy, a nie tylko ich modelowania. Nie neguję korzyści wynikających z modelowania przepływów pracy (zwłaszcza w formie elektronicznej zamiast korzystania z ołówka i papieru) lub ich standaryzacji, ale kiedy zaczynam korzystać z narzędzi do „programowania wizualnego”, nie oczekuję lepszych wyników, jak opisano powyżej Blog
Doc Brown

Odpowiedzi:

8

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
Vishal Bardoloi
źródło
2
Łącze jest nadal martwe - nie ma szansy zobaczyć, na jakich doświadczeniach w świecie rzeczywistym opiera się biała księga, gdy brakuje zasobu.
Doc Brown
7

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;)

c69
źródło
3

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.

Marco
źródło
1
Dziękuję za odpowiedź. Tak więc, afaik, istnieją podstawowe narzędzia przepływu pracy oparte na bezpośrednich wykresach, a także złożone narzędzia przepływu pracy, które są w zasadzie wizualną reprezentacją kompletnych języków programowania Turinga. Nie rozumiem, czy potrzebujesz kompletnego języka programowania Turinga ... dlaczego nie zrobić tego z prawdziwym językiem programowania ogólnego przeznaczenia? Jeśli używasz pętli i warunkowych, dlaczego nie robisz tego w powiedzmy ... Python?
użytkownik16549
2
Ponieważ wizualne reprezentacje kompletnych języków programowania Turing są dostępne dla znacznie większej liczby odbiorców niż deweloperzy, co oznacza, że ​​firmy korzystające z tych narzędzi muszą tylko zatrudniać programistów do komponentów technicznych i mogą pozwolić ekspertom domeny wykonać resztę (za pomocą narzędzia przepływu pracy). Ponadto reprezentacje wizualne są natychmiast przezroczyste, w przeciwieństwie do jakiegokolwiek rodzaju kodu.
Marco,
Czy uważasz, że prawdziwym powodem, dla którego programiści wdrażają logikę biznesową w kodzie zamiast w „liniach i polach”, nie jest to, że „programiści czują się bardziej komfortowo w kodzie”, ale że większość istniejących graficznych narzędzi przepływu pracy jest po prostu nieodpowiednia do opisywania prawdziwego świata przepływy pracy w wykonywalny sposób (co oznacza, ze wszystkimi wyjątkami, obsługę awarii, częściowo obsługę awarii, wizualizację stanu, wymagania niefunkcjonalne itd.)?
Doc Brown,
@DocBrown Celem narzędzi przepływu pracy jest unikanie sytuacji, w których programiści wdrażają logikę biznesową. Idealnie, deverloperzy spędzają czas na wdrażaniu komponentów technicznych i pozwalają analitykom biznesowym (z pomocą narzędzi przepływu pracy) opracowywać i utrzymywać komponenty logiki biznesowej.
Marco,
@Marco: wniosek, który wyciągam z tego, co napisałeś, jest taki, że narzędzia są dalekie od spełnienia oczekiwań, w przeciwnym razie programiści nie mieliby nawet zadania opracowania logiki przepływu pracy.
Doc Brown
1

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

Michail Gede
źródło
0

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.

użytkownik 2800708
źródło
1
„Nie wydaje mi się, żeby tak było zawsze” - czy możesz to zrobić, wykorzystując rzeczywiste doświadczenia? To byłoby interesujące.
Doc Brown,
@DocBrown Niestety nie. Słyszałem, jak inni twierdzą, że osiągnęli sukces dzięki tym narzędziom i szybkim zmianom nowych procesów. Jedyne bezpośrednie doświadczenia, jakie miałem z nich, to ogromne, nieporęczne i niezwykle czasochłonne wysiłki, które doprowadziły mnie do poważnego zwątpienia w ich wartość. Będę się powstrzymywał przed nazwaniem dostawcy narzędzia, ponieważ kiedyś dla nich pracowałem, ale miałem wrażenie, że wiele błędów dotyczy samego narzędzia i sposobu, w jaki programowanie stało się trudniejsze.
user2800708,
@DocBrown Powinienem dodać, zasugerowano, że używamy takiego narzędzia w moim obecnym projekcie roboczym. Dlatego staram się obecnie zastanowić, czy warto, a nie stworzyć własny kod. Warto zbadać coś bardziej lekkiego niż duże narzędzia, na razie nie wiem, co by to było.
user2800708,
@DocBrown warto zauważyć, że pytanie ma obecnie nagrodę stwierdzającą: „Poszukiwanie odpowiedzi pochodzi z wiarygodnych i / lub oficjalnych źródeł”. W świetle tego odpowiedź czysto spekulacyjna nie wydaje się szczególnie przydatna (zastanawiam się, co może być powodem do głosowania)
komnata
-2

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.

Bez szans
źródło
2
OP jest wspomnieć, jakie narzędzia ma na myśli, a te nie są modelowania lub narzędzia symulacyjne. W rzeczywistości narzędzia BPM służą głównie do „tworzenia rysunków biznesowych w celu opisania procesów”, a PO dostrzega w nich wartość. Pytanie dotyczy narzędzi do kontrolowania tych procesów.
Doc Brown,
@DocBrown, docenienie docenione.
NoChance,
1
@doc Brown - narzędzia, o których mowa, kontrolują wykonanie komponentu przy użyciu różnych modeli i diagramów jako „kodu”! (I działa tak, jak można by oczekiwać - stąd łzawienie włosów i zgrzytanie zębów z PO).
James Anderson,
-2

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.

użytkownik613326
źródło
1
czy to tylko twoja opinia, czy możesz to jakoś poprzeć? Zwróć uwagę, że pytanie ma obecnie nagrodę stwierdzającą: „Szukasz odpowiedzi pochodzącej z wiarygodnych i / lub oficjalnych źródeł”.
komar
oparty na historii, miał być zabawnym przykładem, ale nie wszyscy rozumieją przepływ pracy i humor razem.
user613326,