Silnik do przeglądu

Automatyzacja procesów biznesowych przy użyciu silników workflow nie jest, wbrew twierdzeniom dostawców, panaceum na integrację aplikacji.

Automatyzacja procesów biznesowych przy użyciu silników workflow nie jest, wbrew twierdzeniom dostawców, panaceum na integrację aplikacji.

Automatyzacja Procesów Biznesowych (BPA - Business Process Automation) to obszar znany informatyce od przeszło 10 lat. To właśnie wtedy - na przełomie lat 80. i 90. na rynku pojawiły się pierwsze tzw. silniki workflow. Oprogramowanie IBM FlowMark, Staffware czy FileNet WorkFlo miało stanowić instrumentarium dla modnej w tym czasie koncepcji reorganizacji procesów biznesowych. Praktyka nie dorosła jednak do założeń teoretycznych. Jednocześnie wokół tematu narosło wiele mitów, które wciąż funkcjonują w środowisku informatycznym, pomimo dużego odsetka nieudanych projektów.

Silnik do przeglądu

Architektura referencyjna WfMC

Podstawowy mit polega na przekonaniu, że można kupić jakiś silnik workflow (narzędzi tego typu są obecnie setki) i za jego pomocą zautomatyzować wszystkie procesy w przedsiębiorstwie, zwiększając przez to ich efektywność i redukując koszty. Inwestorzy, decydujący się na wdrożenie narzędzi do autoryzacji procesów, liczą też na zwiększenie ich elastyczności. W szczególności wierzą zapewnieniom dostawców, że pracownik biznesowy (nie: techniczny) wyposażony w graficzne narzędzie do modelowania będzie w stanie praktycznie dowolnie definiować procesy bez konieczności ręcznej rekonfiguracji aplikacji wspomagających te procesy.

Mitem jest także możliwość zbudowania architektury, w której silnik workflow jest centralnym elementem systemu informatycznego, do którego odwołują się wszystkie jego moduły przed wykonaniem jakiejkolwiek bardziej skomplikowanej operacji. Ten nadmiernie optymistyczny, by nie powiedzieć naiwny, pogląd na możliwości zastosowania silników workflow weryfikują realia projektowe. Kluczowy element architektury, jakim w założeniu miał być silnik workflow, zaczyna być spychany na margines lub nie jest wykorzystany w ogóle.

Być może więc, w świetle dotychczasowych doświadczeń, wypada zastanowić się, czy naprawdę każdy proces warto automatyzować, a także czy silniki workflow w ogóle są właściwymi narzędziami do automatyzacji procesów.

Procesy nieujarzmione

Już na wczesnym etapie rozwoju narzędzi workflow zdawano sobie sprawę z tego, że różnorodność procesów utrudnia stworzenie uniwersalnego narzędzia do automatyzowania procesów. Tradycyjna klasyfikacja procesów przygotowana na użytek ich automatyzowania dzieli procesy na produkcyjne, kolaboracyjne i ad hoc. W świadomości wielu architektów systemów informatycznych podział ten jednak już dawno się zatarł.

Najłatwiej automatyzuje się procesy powtarzalne, o dużej liczbie instancji, w których prawdopodobieństwo odstępstwa od zdefiniowanych reguł biznesowych, czyli prawdopodobieństwo zaistnienia sytuacji wyjątkowych, jest małe. Przykładem takich procesów są transakcje rozproszone, wymagające interakcji między wieloma systemami informatycznymi. Procesy te są zwykle bardzo precyzyjnie zdefiniowane, a udział człowieka jest w nich ograniczony do minimum. Na przeciwległym biegunie znajdują się procesy, w których ramy postępowania są tylko bardzo ogólnie zakreślone i nieprzypadkowo są najczęściej takie, w których decyzja człowieka odgrywa ważną rolę. Przykładem mogą być procesy obsługi różnego rodzaju wniosków w administracji publicznej. Automatyzowanie tego typu procesów jest bardzo trudne, a jeżeli nawet możliwe, to nie zawsze celowe lub opłacalne.

Większość procesów obejmuje zarówno elementy łatwe, jak i trudne do zautomatyzowania, stąd próba automatyzacji całego przebiegu procesu przeczy często zdrowemu rozsądkowi, a już prawie na pewno rachunkowi ekonomicznemu. Najczęściej jest bowiem tak, że proces można opłacalnie zautomatyzować, załóżmy w 80%, zaś koszt automatyzacji pozostałych 20% jest niewspółmierny do potencjalnego przyrostu korzyści. Oszczędności można zresztą osiągać nie tylko dzięki automatyzacji procesu czy jego części, ale także w wyniku działań niejako prostopadłych do jego przebiegu, w tym zwłaszcza przez różnorakie zmiany jakościowe.

Nawet w przypadku pełnej automatyzacji, rozumianej jako komputerowe sterowanie przebiegiem procesu, niejednokrotnie okazuje się, że silniki workflow nie są optymalnym narzędziem do realizacji tak postawionego celu. Narzędzia te wymagają wyspecyfikowania automatyzowanego procesu za pomocą formalnego języka definiowania procesów (nawet jeżeli producent dostarcza narzędzia graficzne, ostatecznym efektem modelowania jest pewien kod). W odróżnieniu np. od relacyjnych baz danych, w których relacyjny model reprezentacji danych i język zapytań SQL nie różnią się istotnie pomiędzy poszczególnymi produktami, powszechnie akceptowany model opisu procesu biznesowego nie istnieje. Mimo wysiłków organizacji standaryzacyjnych prowadzonych w ramach Workflow Management Coalition (WfMC), każdy silnik workflow używa własnego języka definiowania procesów, a różnice semantyczne między nimi są bardzo znaczące. Procesu opisanego za pomocą jednego narzędzia nie da się więc łatwo przetłumaczyć na język innego narzędzia.

W celu komercyjnej reprodukcji treści Computerworld należy zakupić licencję. Skontaktuj się z naszym partnerem, YGS Group, pod adresem [email protected]

TOP 200