1. Procesy biznesowe modelowanie procesów

Transkrypt

1 Materiały do samodzielnego studiowania dla przedmiotu Informatyczne Wspomaganie Zarządzania Logistycznego Studia I stopnia Wydział Ekonomiczny 1. Nazwa przedmiotu: Informatyczne Wspomaganie Zarządzania Logistycznego 2. Temat zajęć: Modelowanie procesów biznesowych w logistyce: 3. Cel zajęć: Zamodelowanie przykładowych procesów biznesowych w logistyce zgodnych ze standardem BPMN: cel i zasady modelowania i budowania procesów biznesowych, standard i notacja procesów - BPMN, projekt przykładowego procesu biznesowego z wykorzystaniem narzędzi informatycznych. 4. Zadania dla studentów: studenci zobowiązani są zapoznać się z materiałami i narzędziami wymienionym w punkcie 5, a dla utrwalenia materiału samodzielnie wykonać przykładowe definicje procesów zawarte w tutorialach narzędzi do modelowania procesów. 5. Literatura: Marek Piotrowski, Notacja modelowania procesów biznesowych podstawy Business Process Modeling Notation BPMN, Wydawnictwo BTC, Legionowo 2007, Standardy: Przykładowe narzędzia : Enhydra Jawe, Enhydra Shark- BizAgi Process Modeler Procesy biznesowe modelowanie procesów Podejście procesowe jest terminem powszechnie używanym w różnych dziedzinach nauki i biznesu, na przykład: procesowe podejście do zarządzania jakością, procesowe podejście do tworzenia oprogramowania, procesowe podejście do zarządzania konkurencyjnością czy procesy zarządzania dostawami towarów i usług. Idea podejścia procesowego stosowanego w różnych dziedzinach jest taka sama i zakłada wykonywanie zbioru określonych działań jako procesu. W ramach pracy rozpatrywane będzie podejście procesowe do organizacji i wynikające z niego podejście procesowe w tworzeniu systemów informatycznych. Podejście procesowe do organizacji polega na zarządzaniu nią poprzez zarządzanie procesami biznesowymi. Taki sposób działania wymusza stosowanie odpowiednich rozwiązań informatycznych. Wynikiem tego jest potrzeba tworzenia systemów w kontekście konkretnych procesów biznesowych. Podejście procesowe do produkcji oprogramowania polega na wykorzystaniu procesów zarówno na etapie analizy systemu, projektowania jak i implementacji. Obok podejścia obiektowego i strukturalnego stanowi kolejną metodę tworzenia systemów. 1.1 Proces biznesowy Kluczowym pojęciem związanym z podejściem procesowym jest proces biznesowy. Proces biznesowy (ang. Business Process), to zbiór powiązanych ze sobą czynności, które przekształcają wejścia w wyjścia według określonych reguł, w oparciu o określone zasoby i w efekcie prowadzą do realizacji celów biznesowych organizacji. Proces charakteryzowany jest poprzez określenie danych wejściowych, danych wyjściowych, zasobów, reguł i ograniczeń (rys.1).

2 Rys. 1 Proces biznesowy i jego otoczenie Dane wejściowe są to wszelkie informacje przekazywane procesowi w momencie jego rozpoczęcia lub informacje inicjujące proces. Dane wyjściowe to produkt końcowy procesu stanowiący efekt jego wykonania. Zasoby to dane, informacje, usługi i produkty, które wykorzystywane są podczas realizacji procesu. Reguły i ograniczenia określają sposób wykonywania czynności wchodzących w skład procesu. Zidentyfikowanie tych podstawowych elementów zapewnia klarowny i użyteczny opis procesu biznesowego. Proces biznesowy zachodzący w organizacji może być określany, jako proces główny lub wspierający. Podział ten wynika z biznesowej potrzeby rozróżnienia procesów mających bezpośredni wpływ na produkt dostarczany klientowi zewnętrznemu, od procesów, które pośrednio wpływają na wytworzenie finalnego produktu poprzez wspieranie realizacji procesu głównego. Zatem, proces główny to proces realizujący główne cele biznesowe firmy, natomiast proces wspierający, to proces, który wspiera jego skuteczne wykonanie. Trzeci rodzaj procesu, to proces zarządzania, którego głównym celem jest zapewnienie sprawnego funkcjonowania organizacji. Może on obejmować działania logistyczne, finansowe itp. Procesy biznesowe składają się ze zbioru powiązanych ze sobą i wykonywanych w określonej kolejności czynności. Ich realizacja składa się na realizację całego procesu i wytworzenie produktu końcowego. Zarówno czynności jak i sam proces mogą pozostawać w różnego rodzaju relacjach z innymi czynnościami i procesami. Zależności te przedstawiane są za pomocą modelu procesów, który stanowi podstawę wdrażania podejścia procesowego w organizacji. 1.2 Podejście procesowe do zarządzania organizacją Procesowe podejście (ang. Process apporach) do zarządzania organizacją jest obecnie traktowane jako jeden z głównych trendów w zakresie zarządzania. Jest to jeden ze sposobów na skuteczne zarządzanie przedsiębiorstwem w kontekście dynamicznie zmieniającej się sytuacji rynkowej i nieustannie rosnącej konkurencji. Jego celem jest zwiększenie skuteczności działań, jakości ich rezultatów oraz zmniejszenie kosztów i czasu ich realizacji. Fakt skuteczności podejścia procesowego w zarządzaniu potwierdzają m.in. wymogi standardów jakościowych. Według normy ISO 9000:2000 zarządzanie poprzez procesy wpływa bezpośrednio na efektywność pracy i stopień realizacji założonych celów - Pożądany wynik osiąga się z większą efektywnością wówczas, gdy działania i związane z nimi zasoby są

3 zarządzane jako proces 1. Podejście procesowe stanowi jedną z 8 podstawowych zasad zarządzania jakością w normie ISO 9000:2000. Procesowe podejście do zarządzania organizacją polega na odejściu od orientacji nastawionej na strukturę funkcjonalną i skupieniu się na procesach zachodzących w organizacji. W podejściu procesowym przedsiębiorstwo postrzegane jest jako całość, a praca poszczególnych komórek organizacyjnych jest od siebie zależna i bezpośrednio wpływa na efektywność wykonywanych działań. Bardzo istotnym założeniem jest to, że procesy przechodzą na wskroś przedsiębiorstwa i ich wykonywanie nie jest zależne tylko od jednej komórki organizacyjnej. Odpowiedzialność za realizację określonego procesu - i tym samym za funkcjonowanie organizacji - ponoszą wszyscy aktorzy biorący udział w procesie. Praktyczne zastosowanie procesowego podejścia do organizacji oznacza rozpoczęcie zarządzania jej procesami biznesowymi. Zarządzanie procesami biznesowymi obejmuje zestaw czynności, których nieprzerwane realizowanie zapewnia ciągłość działania przedsiębiorstwa i osiągnięcie założonych celów biznesowych. 1.3 Modelowanie procesów w tworzeniu systemów informatycznych wspomagających zarządzanie Modelowanie procesowe to kolejne po obiektowym i strukturalnym podejście do tworzenia systemów informatycznych. Pozwala na wysokim poziomie abstrakcji uchwycić aspekty biznesowe, projektowe i implementacyjne. Pierwsze metody tworzenia systemów informatycznych (metody strukturalne) były ściśle związane z dostępnymi narzędziami implementacyjnymi, a dokładnie z strukturalnymi językami programowania. W kontekście budowy wielkich rozwiązań angażujących duże zespoły projektowe metody te nie zdawały egzaminu. Większość dużych projektów kończyło się przekroczeniem budżetu lub niedotrzymaniem terminów. Powstanie języków obiektowych wpłynęło nie tylko na zmianę sposobu implementowania systemów lecz również na sposób ich analizowania i projektowania (metody obiektowe). Systemy zaczęto postrzegać jako grupę komunikujących się obiektów, składających się z danych i metod na nich operujących. Kolejnym krokiem w rozwoju inżynierii oprogramowania jest stosowanie podejścia procesowego do modelowania i implementowania systemów. Tak jak w podejściu obiektowym podstawowym elementem jest obiekt, tak w modelowaniu procesowym jest proces. W podejściu procesowym system to zbiór komunikujących się ze sobą obiektów, których zachowanie sterowane jest przez procesy. Taki sposób postrzegania systemów informatycznych wynika z procesowego podejścia do zarządzania organizacją. Przedsiębiorstwa zarządzane poprzez zarządzanie procesami w nich zachodzącymi potrzebują rozwiązań informatycznych, które będą je wspierały. Wykorzystanie modelowania procesowego w tworzeniu systemów informatycznych polega na prowadzeniu prac projektowych oraz programistycznych w oparciu o model procesów. Taki sposób działania określa się jako programowanie zorientowane na procesy. Model procesów biznesowych organizacji może zostać bezpośrednio przełożony na model procesów, które będą implementowane w systemie. Zależność ta wpływa na zmniejszenie ryzyka zbudowaniu rozwiązania, które nie będzie realizowało określonych we wczesnej fazie projektu założeń (problem źle zdefiniowanych wymagań). Jeśli system informatyczny ma automatyzować procesy organizacji, to model tych procesów określa w dużym stopniu sposób działania tego systemu. W praktyce podejście procesowe wykorzystywane jest wraz z podejściem obiektowym i strukturalnym. Według najbardziej rozpowszechnionych metodyk - Rational Unified Process i 1 PN-EN ISO pkt.0.2d

4 Select Perspective, pierwszym etapem tworzenia systemów jest modelowanie procesów biznesowych. Kolejne to definiowanie przypadków użycia, związanych z nimi artefaktów (np. diagramy sekwencji i aktywności UML, klasy analityczne), a następnie diagramów klas i modeli danych. Te trzy główne etapy odpowiadają podejściom: procesowym, obiektowym i strukturalnym. Istotne jest, aby tworzone w ramach różnych podejść produkty analityczne, projektowe i implementacyjne były od siebie zależne i wzajemnie z siebie wynikały (rys. 2). Model procesów pozwala zrozumieć sposób funkcjonowania organizacji a za tym zdefiniować jej potrzeby pod kątem systemów informatycznych (wymagania). Pewne fragmenty procesów biznesowych, które określają wymagania funkcjonalne mogą odpowiadać przypadkom użycia. Oznacza to, że czynności wykonywane w ramach procesu są czynnościami systemowymi wykonywanymi nie tylko w kontekście procesów. Przykładem może być rejestracji sprawy. Czynność ta może być wykonywana jako funkcja systemu dostępna dla użytkowników poza procesem biznesowym, może również być realizowana jako jeden z kroków procesu. W takiej sytuacji przypadek użycia związany z rejestracją odpowiada odpowiedniej czynności procesu. Innym przykładem zależności pomiędzy procesami, a przypadkami użycia jest sytuacja, w której wywołanie przypadku użycia (wybranie funkcji w systemie) powoduje utworzenie nowej instancji procesu i rozpoczęcie jego obsługi. Zachowanie poszczególnych czynności procesu może być również implementowane przez mechanizmy nieuwzględnione w przypadkach użycia. Są to najczęściej działania systemu, które nie są widoczne dla użytkownika, a wpływają na poprawne wykonywanie instancji procesu. analysis Artefakty d efin iuje Analityk definiu je Procesy biznesowe d efin iuje in icjuje Przypadki użycia Wym a gania Czynność 1 wynika z Wymaganie 1 realizu je PU 1 Czynność 2 wynika z Wymaganie 2 realizu je PU 2 PU 3 «include» wykonuje im ple m e ntu je im p le m e n tu je Diagra m kla s tworzy Klasa 1 Klasa 2 op eru je na Projektant Model danych tworzy Encja 1 Encja 2 0..* 1 Rys. 2 Zależności pomiędzy artefaktami

5 1.4 Zarządzanie procesami w organizacji Zarządzanie procesami (ang. Business Process Management) to systematyczne analizowanie, usprawnianie i kontrolowanie procesów biznesowych organizacji w celu realizacji jej celów biznesowych (rys.3). Według koncepcji ARIS jest to stały proces kierowniczy, w którym obowiązują następujące zasady 2 : 1. podstawowe procesy firmy są udokumentowane i poddane analizie, 2. powiązania wewnątrz procesów analizowane są przez pryzmat potrzeb klientów, 3. powtarzalność, spójność i jakość rezultatów procesów zapewniają systemy i udokumentowane procedury, 4. podstawą określania celów i oceny rezultatów procesów jest pomiar działań, 5. zarządzanie procesami opiera się na ich ciągłym doskonaleniu, 6. zarządzanie procesami jest podejściem do zmiany organizacyjnej kultury firmy. Rys. 3 Zarządzanie procesami w organizacji Źródło: Modelowanie procesów biznesowych Modelowanie procesów biznesowych (BPM ang. Business Process Modeling) jest dyscypliną, która znalazła swoje miejsce w wielu różnych aspektach związanych zarówno z biznesem jak i realizacją przedsięwzięć informatycznych. Modelowanie procesów ma na celu odwzorowanie za pomocą przyjętych symboli, procesów zachodzących w przedsiębiorstwie w celu ich udokumentowania lub analizy pod określonym kątem. W wyniku modelowania powstaje model procesów biznesowych (rys.4). Dobrze skonstruowany pomaga odpowiedzieć na następujące pytania: Jak działa organizacja? Jakie procesy są realizowane? Czy realizowane procesy są wystarczająco efektywne i wydajne? Czy możliwe jest usprawnienie realizowanych procesów? Czy realizowane procesy są zgodne z założeniami strategicznymi? Kim są aktorzy, których udział jest wymagany w danych operacjach? Które czynności operacyjne mogą być wyróżnione? Które czynności są wykonywane, przez których aktorów? Jakie są wejścia i wyjścia do/z czynności? 2 IDS Scheer Polska : ARIS Easy Design Podręcznik użytkownika.

6 Jaka jest kolejność czynności do wykonania w szczególnych przypadkach? Które czynności mogą być wykonywane jednocześnie w szczególnych przypadkach? Analiza modelu implikuje rozpoczęcie przedsięwzięć związanych najczęściej z: usprawnieniem sposobu funkcjonowania organizacji - BPR (ang. Business Process Reengineering) lub/i jej reorganizacje BPI (ang. Business Process Improvement), budową systemu informatycznego wspomagającego jej pracę. Pierwsze przedsięwzięcie odnosi się do zarządzania procesami biznesowymi. Stworzony model organizacji poddawany jest gruntownej analizie w wyniku, której dokonywana jest reorganizacja firmy lub/i procesów biznesowych. Jednym ze sposobów analizy jest symulacja procesów. Odbywa się ona w oparciu o ściśle sprecyzowane kryteria i wykonywana jest przy użyciu odpowiednich narzędzi informatycznych - należy podkreślić fakt, że analiza zamodelowanych procesów jest możliwa tylko wtedy, jeśli narzędzie do symulacji potrafi interpretować opisane procesy. Dla wielu firm jest to poważny problem, gdyż nieprzemyślana inwestycja w narzędzie do modelowania oraz w sam proces modelowania może ograniczać ją do wykorzystywania tylko określonych technologii lub uniemożliwiać wykorzystanie uzyskanych podczas modelowania efektów. Dlatego też m.in. z tego powodu dąży się do opracowania standardowej formy opisu procesów, która pozwoli na uniwersalne ich wykorzystywanie. Drugie przedsięwzięcie zakłada budowę i wdrożenie rozwiązania informatycznego. Przyczyną takiego podejścia jest potrzeba skutecznego identyfikowania potrzeb organizacji w celu zdefiniowania wymagań na system informatyczny. Większość projektów informatycznych kończy się niepowodzeniem z powodu źle zdefiniowanych wymagań. Najczęstszym tego powodem, jest niska świadomość kadry kierowniczej przedsiębiorstw, co do własnych potrzeb. Modelowanie procesów biznesowych pozwala na dokładne określenie potrzeb organizacji i co za tym idzie, na dokładne zdefiniowanie wymagań. Pozwala również na opracowanie projektu procesów workflow, które implementują przebieg procesów biznesowych w systemie. Specyfika procesów workflow różni się od specyfiki procesów stricte biznesowych. Procesy stricte biznesowe są modelowane na wyższym poziomie abstrakcji i ich głównym celem jest opis sposobu funkcjonowania organizacji. Procesy workflow natomiast, określają logikę biznesową jak i implementacyjną. Modelowane są w oparciu o wzorce procesowe oraz mechanizmy automatyzacji procesów wykorzystujące specyficzne obiekty, takie jak: zadania, listy zadań. Modelowanie procesów biznesowych używane jest do osiągnięcia różnych celów. W ramach wspomnianego już wcześniej BPR modelowanie procesów służy przebudowie realizowanych przez organizację procesów, aby osiągnąć drastyczną poprawę wskaźników takich jak koszt, szybkość czy jakość. W metodzie ABC utworzone w ramach modelowania modele używane jako podstawa wyliczania kosztów produktów i usług. Certyfikacja ISO i zarządzanie jakością, skupiające się na zapewnieniu wysokiej jakości organizacji wymagają między innymi formalnych zapisów realizowanych przez organizację procesów. Modele procesów biznesowych bywają też używane do realizacji symulacji w celu oceny i optymalizacji procesów produkcji realizowanych przez organizację. Kolejnym ważnym celem modelowania procesów biznesowych jest użycie go jako narzędzia inżynierii wymagań. Wiele organizacji boryka się z zapewnieniem wsparcia dla realizacji swoich celów używając nowych technologii. Pierwszym krokiem w tego typu projektach jest określenie i zrozumienie w jaki sposób realizowane są procesy w organizacji i które z procesów system będzie wspierał. Pierwszym krokiem jest zatem przedstawienie realizowanych przez organizację procesów w sposób taki, by były one adekwatne i pomocne w procesie wytwarzania systemu. Dyscypliny takie jak wytwarzanie systemów informatycznych, systemy automatyzacji czy planowanie zasobów przedsiębiorstwa używają więc modelowania procesów biznesowych w celu zapewnienia jak najlepszego wsparcia organizacji w związanych z tymi dyscyplinami dziedzinach.

7 Certyfikacja ISO Przebudowa Procesów (BPR) Symulacja Zarządzanie Jakością BPM Rachunek Procesowy Kosztów (ABC) Inżynieria Wymagań Wytwarzanie Systemów Informatycznych Systemy Workflow Planowanie Zasobów Przedsiębiorstwa (ERP) Rys. 4 Zakres wykorzystania modelowania procesów biznesowych 1.6 Omówienie standardu BPMN BPMN (Business Process Modeling Notation) jest standardem graficznej notacji szeroko przyjętym w produktach związanych z modelowaniem procesów biznesowych. BPMN definiuje wygląd procesu, kolejność i połączenia pomiędzy jego elementami. Notacja ta opracowana została przez BPMI (Business Process Management Initiative), a od 2005 roku po fuzji BPMI z OMG(Open Management Group) jest przez tę drugą organizację wspierany i rozwijany. Głównym celem przyświecającym twórcom BPMN było zapewnienie notacji, która będzie czytelna dla wszystkich jej użytkowników, zaczynając od analityków biznesowych tworzących szkice procesów poprzez deweloperów odpowiedzialnych za implementacje technologii, która pozwoli na wykonanie tego procesu, aż po ludzi odpowiedzialnych za nadzorowanie i monitorowanie działającego procesu. BPMN w zamyśle twórców miał zapewniać łatwe przejście od etapu projektowania i modelowania procesów do ich implementacji. Kolejnym, równie ważnym celem było zapewnienie, że oparte na XML języki wykonawcze procesów biznesowych, takie jak BPEL (Busines Process Execution Language) czy BPML (Business Process Modeling Language), będą mogły zostać zaprezentowane za pomocą powszechnej notacji. Modelowanie procesów wykorzystujące BPMN skupia się na modelowaniu systemów z punktu widzenia procesów biznesowych. Można, zatem przyjąć, że biorąc pod uwagę różne punkty widzenia na modelowanie systemów, oba standardy są względem siebie komplementarne i zapewniają pełne opisy systemów informatycznych. Kolejną zaletą w stosunku do UML jest oferowanie przez BPMN notacji, która lepiej odpowiada sposobowi, w jaki analitycy modelują procesy. Dodatkowo oparcie BPMN na solidnych matematycznych fundamentach powoduje, że może być on mapowany na jeden z kilku języków wykonawczych (execution language), czego UML nie zapewnia. Ten i kolejne podpunkty mają pomóc

8 Czytelnikowi w zapoznaniu się z BPMN, oraz z pozostałymi ważnymi dla modelowania procesów biznesowych standardami BPMN - geneza i główne cele BPMN został opracowany jako kluczowy element nowej inicjatywy w świecie architektury korporacyjnej (Enterprise Architecture) Zarządzania Procesami Biznesowymi (BPM 3 Business Process Management). BPM (Zarządzanie ) zogniskowane jest na zarządzaniu zmianą w celu ulepszenia procesów biznesowych. BPM stanowi integrację, w ramach jednego standardu, istniejących już, ale jako autonomiczne, dyscyplin: Modelowania procesów (Process Modeling), Symulacji, Automatyzacji procesów (Workflow), Integracji aplikacji korporacji (EAI Enterprise Application Integration), Integracja Business-to-Business (B2B). Fakt, iż BPM jest inicjatywą nową nie oznacza, że do tej pory procesy nie były zarządzane w ogóle. W ramach wielu przedsiębiorstw i organizacji procesy były zarządzane korzystając z mieszanki różnych technik i narzędzi. Te sposoby często jednak okazywały się niewystarczające, głównie ze względu na brak standardów i opisu kompletnego cyklu życia procesów, który pozwoliłby na ujednolicenie przebiegu modelowania i wykonywania procesów biznesowych. Aby stać na straży poprawnego przebiegu cyklu życia procesów konieczna jest kontrola planowania, projektowania i wdrażania procesów, a aby tego dokonać należało stworzyć notację procesów oraz język opisujący ich wykonanie. Organizacja BPMI została powołana jako ciało mające na celu promowanie i rozwijanie Zarządzania Procesami Biznesowymi, poprzez używanie standardów do projektowania, wdrażania, wykonywania, utrzymywania i optymalizacji procesów. BPMI postanowiła opracować trzy standardy do celów określanych w ramach BPM: BPMN jako standard do modelowania procesów, BPML (Business Process Modeling Language) jako standard języka wykonawczego procesów biznesowych, oraz BPQL (Business Process Query Language) jako standardowy interfejs dla wdrażania i wykonania procesów biznesowych. Jednym z podstawowych założeń przyjętych przez BPMI było, aby opracowane w ramach jej działań standardy miały solidne podłoże matematyczne. Dlatego podczas prac nad powyższymi standardami użyto jednej z teorii matematycznych w ramach rachunku procesów (process calculus). Było to podobne złożenie do tego, które przyjęto podczas opracowywania systemów zarządzania relacyjnymi bazami danych (RDBMS). W przeciwieństwie do istniejących już standardów i notacji BPMN był tworzony z uwzględnieniem istnienia (bądź perspektywy zaistnienia) języków wykonawczych i technologii Web service ów. Dlatego do palety elementów BPMN dodano specjalne konstrukcje pozwalające na modelowanie zdarzeń opartych na komunikatach i wymianę tychże komunikatów między różnymi organizacjami. Wprowadzenie tych elementów pozwoliło na zapewnienie możliwości modelowania procesów typu Business-to-Business (B2B). Co więcej BPMN był tak zaprojektowany, aby mógł być mapowany na BPML, lub dowolny inny język wykonawczy, jak np. BPEL4WS. Pierwsza wersja BPMN, oznaczona jako 1.0, została oficjalnie zatwierdzona i wydana jako standard w lutym 2006 roku. Prawie dwa lata później, w styczniu 2008 roku opracowano i 3 Akronim BPM posiada wiele rozwinięć (Business Process Management, Business Process Modeling, Business Proces Model itp.) dlatego należy używać go ostrożnie, zawsze określając czego dotyczy, aby uniknąć pomyłek.

9 wydano kolejną wersję oznaczoną numerem 1.1. Najbardziej aktualną wersję OMG udostępniło w styczniu 2009 roku, a jej oznaczenie to 1.2. Cały czas trwają też pracę nad następcą aktualnej wersji (obecnie to wersja2.0, która wnosi szereg zmian i usprawnień) Zakres BPMN BPMN, przy całej swojej złożoności, wspiera jedynie pewien zakres modelowania biznesowego, ściśle związany z procesami biznesowymi. Oznacza to, że inne aspekty modelowania, wykorzystywane w ramach organizacji dla celów biznesowych znajdują się poza obszarem wspieranym przez BPMN. Przykładowe, niewspierane przez BPMN aspekty modelowania biznesowego: Modelowanie struktury i zasobów organizacji, Modelowanie danych, Modelowanie strategiczne. Rys. 5. Architektura BPMN BPMN określa jeden typ diagramu procesów nazywany diagramem procesów biznesowych (BPD Business Process Diagram) (rys.5). Diagram miał spełniać dwie podstawowe funkcje. Przede wszystkim miał być prosty do opanowania, czytelny i łatwy do zrozumienia; pozwalać na szybkie i łatwe modelowanie procesów i zrozumienie ich przez ludzi bez technicznego wykształcenia (zazwyczaj kierownictwo firmy). Jednocześnie, i jest to druga z jego głównych funkcji, miał dostarczać zbioru mechanizmów pozwalających na zamodelowanie złożonych procesów biznesowych i swobodne ich mapowanie na języki wykonawcze. Aby zamodelować prosty proces biznesowy wystarczy określić zdarzenie inicjujące proces, czynności i zadania wykonywane w trakcie realizacji procesu oraz jego wynik końcowy. Podejmowanie decyzji biznesowych lub sprawdzanie warunków realizowane jest poprzez bramki (podobne do elementów decyzyjnych w schematach blokowych). Rozbudowując definicję procesu można dodawać podprocesy, które mogą realizować bardziej skomplikowane zadania i być opisane, jako zbiór kolejnych czynności, dodawać elementy, które są modyfikowane lub wytwarzane w trakcie realizacji. Wchodząc głębiej w strukturę procesu możemy określić, kto robi co poprzez umieszczanie elementów procesu w ramach jednostek (pools). Jednostki możemy dzielić dalej, grupując role lub stanowiska w ramach torów (lanes). Komunikacje między różnymi organizacjami, bądź obszarami organizacji biorącymi udział w procesie określamy z wykorzystaniem przepływów komunikatów. Poniższy diagram (rys.6) prezentuje podstawowe możliwości notacji BPMN:

10 Zwi ni ęt a Jednost ka Rozwi ni ęt a Jednost ka Tor Tor Tor War unkowe Zdar zeni e Począt kowe Br amka Zr ównol egl eni a Pr zepływ Sekwencj i Pośr edni e Zdar zeni e Komuni kat u Podpr oces Ad- hoc Zadani e Zadani e ~ Pośr edni e Zdar zeni e Czasu Zwi ni ęt y Podpr oces Obi ekt Danych Obi ekt Dat nych [ st an1] Br amka Rozłączna St er owana Zdar zeni em Br amka Rozłączna St er owana Danymi Wbudowany Podpr oces Pośr edni e Zdar zeni e Komuni kat u Pośr edni e Zdar zeni e Czasu Pęt l a Zadani e Zadani e Mul t i - i nst ancyj noś ć Pośr edni e Zdar zeni e Wyj ąt ku Br amka Zr ównol egl eni a Zdar zeni e Końcowe Obi ekt Danych [ st an2] Tor Zadani e Pr zepływ Wyj ąt kowy Zadani e Adnot acj a Gr upowani e Rys. 6 Przykładowy proces według BPMN Zadani e Zakończeni a Elementy notacji BPMN Notacja BPMN umożliwia modelowanie procesów biznesowych z wykorzystaniem szerokiej palety elementów. Jednocześnie, aby uniknąć zbytnich komplikacji zdecydowano się na podział elementów na cztery podstawowe kategorie: Elementy przepływu (Flow Objects), Połączenia (Connecting Objects), Uczestnicy (Swimlanes), Artefakty (Artifacts). Każda ze wspomnianych kategorii dzieli się następnie na podzbiory, prezentujące elementy pogrupowane zgodnie z ich charakterem. Elementy przepływu stanowią podstawę diagramu procesów biznesowych. Prezentują elementy kluczowe w strukturze procesu. Wyróżnia się trzy podzbiory tej kategorii: Zdarzenia (Events), Bramki (Gateways), Czynności (Activities). Kategoria Połączenia zawiera elementy pozwalające na zaprezentowanie związku pomiędzy elementami na diagramie, niezależnie czy jest to prezentacja przepływu, czy użycia danego elementu przez inny na diagramie. Wyróżnia się trzy podzbiory tej kategorii: Przepływy Sekwencji (Sequence Flow), Przepływy Komunikatów (Message Flow), Asocjacje (Associations). Kategoria Uczestnicy zawiera elementy pozwalające na grupowanie obiektów procesu biznesowego zgodnie z ich przynależnością do określonej osoby, roli bądź jednostki organizacyjnej. Wyróżnia się dwa podzbiory tej kategorii: Jednostki (Pools), Tory (Lanes).

11 Kategoria Artefakty zawiera elementy pozwalające na zapewnienie dodatkowych informacji o modelowanym procesie. Wyróżnia się trzy elementy w tej kategorii 4 : Obiekty Danych (Data Objects), Grupy (Groups), Adnotacje (Annotations). Poniższa tabela (1) prezentuje podstawowe elementy diagramów BPMN wraz ich krótkim opisem oraz symbolem graficznym używanym w notacji. Tabela 1: Podstawowe elementy diagramów w notacji BPMN Element Opis Symbol Zdarzenie Zdarzenia są sposobem prezentowania na diagramie wydarzeń, które wystąpią lub mogą wystąpić w trakcie wykonywania procesu. Wpływają na przebieg procesu i ich wystąpienie jest czymś spowodowane (trigger) lub powoduje skutek (result). Wyróżnia się trzy typy zdarzeń, w zależności od sposobu ich wystąpienia w procesie: Początkowe, Pośrednie i Końcowe. Na diagramie prezentowane są jako okręgi, których obramowanie i wnętrze zależy od typu zdarzenia Czynność Czynność ogólnym pojęciem określającym pracę, którą uczestnik procesu wykonuje. Czynności mogą być proste lub złożone (podproces). Na diagramie prezentowane są jako zaokrąglone prostokąty Bramki Bramki są elementami pozwalającymi na kontrolę przebiegu procesu, jego rozgałęzień i połączeń. Utożsamiać je można z elementami decyzyjnymi. Na diagramie prezentowane są jako romby, których wnętrze zależy od typu bramki. Przepływy Sekwencji Przepływy Sekwencji używane są do pokazania kolejności, w jakiej Czynności będą wykonywane w ramach procesu. Przepływy Komunikatów Przepływy Komunikatów używane są do pokazania wymiany komunikatów pomiędzy odrębnymi uczestnikami procesu. Asocjacje Jednostki Tory Asocjacje służą do dołączania dodatkowych informacji do Elementów Przepływu. Strzałka na końcu Asocjacji wskazuje kierunek powiązania. Jednostki służą do prezentowania uczestników procesu. Zarówno Jednostki jak i Tory mogą być prezentowane w sposób horyzontalny lub wertykalny. Tory umieszcza się wewnątrz Jednostek. Służą do organizowania Czynności wewnątrz Jednostki. P o o l P o o l L a n e L a n e 4 BPMN pozwala osobom modelującym lub narzędziom do modelowania na dodawanie dowolnych artefaktów

12 Obiekty Danych Grupa Obiekty Danych mogą być dołączane do Przepływów, ale nie mają wpływu na ich przebieg. Mogą zawierać informacje o tym, czego dana Czynność wymaga, aby mogła zostać wykonana lub co dana Czynność produkuje. Grupy służą do łączenia elementów diagramu i prezentowania pewnego ich związku. Grupa nie ma wpływu na Przepływy pomiędzy Czynnościami. Adnotacja Adnotacje są sposobem pozwalającym modelującemu na dołączenie do elementów diagramu dodatkowych informacji dla jego odbiorcy. Treść 1.7 Wzorce opisu procesów Wzorce procesowe (ang. Workflow Patterns) to 21 podstawowych konstrukcji opisujących różne zachowania procesów. Powstały w celu ułatwienia implementacji odpowiedzialnych za interpretowanie i wykonywanie procesów serwerów workflow. Ich autorami są Wil van der Aalst, Arthur der Hofstede, Bartek Kiepuszewski oraz Alistair Bartos. Do interpretacji wzorców procesów wykorzystywane jest pojęcie tokenu. Token rozumiany jest jako wskaźnik na aktualnie wykonywany krok procesu (sterowanie). Przebieg pojedynczego procesu opisywany jest przez token główny oraz tokeny pochodne wykonywane jednocześnie (podział równoległy). Wzorce procesów podzielone zostały na sześć grup: Wzorce proste o Sekwencja o Podział równoległy o Synchronizacja o Podział typu XOR o Połączenie podstawowe Wzorce zaawansowane o Podział wielokrotny o Połączenie wielokrotne o Dyskryminator o Połączenie N z M o Połączenie synchroniczne Wzorce strukturalne o Pętle o Zakończenia Wzorce anulowania o Anulowanie aktywności o Anulowanie procesu Wzorce stanów o Podział XOR wyzwalany zdarzeniem o Częściowy przepływ równoległy o Wzorzec typu kamień milowy Wzorce obejmujące wiele instancji procesu o Wielokrotna instancja ze znaną krotnością przed rozpoczęciem o Wielokrotna instancja bez znanej krotności o Wielokrotna instancja z krotnością ustalaną podczas jej realizacji o Wielokrotna instancja z synchronizacją Każda grupa definiuje wzorce o różnej złożoności. Wzorce proste opisują najmniej złożone zachowania procesów. Wzorce zaawansowane definiują mechanizmy podziału oraz połączeń. Wzorce strukturalne charakteryzują iteracyjność oraz zależność przebiegu procesów. Sposób tworzenia kopii czynności oraz ich wielokrotnych instancji przedstawiają wzorce wielu instancji. Kolejna grupa wzorców wzorce stanów, opisują jak czynniki zewnętrzne w stosunku

13 do procesu, mogą wpływać na jego przebieg. Wzorce anulowania charakteryzują możliwe zakończenie wykonywania czynności/procesu. Szczegółowy opis elementów notacji BPMN można znaleźć w postaci skondensowanej pod adresem : 2. Systemy automatyzacji procesów workflow Przepływ pracy z ang. workflow opisuje automatyzację procesów, gdzie dokumenty, informacje lub zadania przekazywane są między uczestników zgodnie ze zdefiniowanymi dla nich regułami zachowań, by osiągnąć wspólny cel. Workflow może być zorganizowany w sposób manualny, jednak w praktyce większość obecnie dostępnych przepływów pracy jest zautomatyzowana za pomocą systemu informatycznego, który odpowiedzialny jest za utrzymywanie automatyzacji procesów w sposób, w jaki zostały one uprzednio zaprojektowane. W 1996 roku, Workflow Management Coalition (WFMC) opublikowała dokument, w którym wyjaśniła wszystkie pojęcia związane z przepływem pracy. Najnowsza wersja definiuje workflow jako: Workflow może być rozumiany, jako: automatyzacja procesu biznesowego, w całości lub części, w ramach której dokumenty, informacje i zadania są przekazywane pomiędzy uczestnikami, zgodnie z określonymi procedurami zarządczymi 5 System (zarządzania) workflow natomiast jako (WFM): system, który definiuje, tworzy i zarządza wykonaniem procesów workflow, poprzez użycie oprogramowania, uruchamiany w ramach jednego lub większej ilości silników workflow, który umożliwia interpretacje definicji procesów, pozwala na współpracę uczestników procesu i, jeśli konieczne, na użycie odpowiednich narzędzi i aplikacji 6 We wcześniejszych latach praca przekazywana była pomiędzy jednym pracownikiem a innym. Głównym powodem, dla którego przepływ pracy został dostarczony ludziom, była możliwość przekazywania pracy pomiędzy użytkownikami, jednak systemy nie wspomagały przekazywania pracy niekompletnej. W chwili obecnej technologia potrafi przekazywać zadania niekompletne, a nawet wywłaszczać zadania od jednego użytkowania do drugiego. Zadania lub dane, które są utworzone, a później przetwarzane są lub muszą być zgodne z wymaganiami organizacji, dla której zostały zaprojektowane. Schemat działania większości silników wspomagania procesów biznesowych można zapisać za pomocą reguł matematycznych i może być zarządzany przez system zarządzania workflow. Workflow zwykle wykonuje szereg logicznych kroków następujących po sobie, które znane są jako aktywności (zadanie, czynność) - BPMI (Business Process Managment Insitiute): Aktywność, jest to proces, niepodzielny w zakresie instrukcji abstrakcyjnych, zwykle zawierający czynności technologiczne związane z wykonaniem zadania. Aktywność może wymuszać działanie użytkownika lub uczestnika obiegu pracy lub wymuszać działanie zautomatyzowane np. uruchomić program, który obliczy wartości, a wyniki przekaże 5 Tłumaczenie własne na podstawie definicji Worflow w WfMC Terminology & Glosary WfMC-TC Tłumaczenie własne na podstawie definicji Worflow Management System w WfMC Terminology & Glosary WfMC- TC-1011

14 do dalszej analizy. Automatyzacja pracy powoduje znaczący wzrost efektywności i prowadzi do wytworzenia Wirtualnych Organizacji. 2.1 Typy systemów workflow. Jakiego typu systemu workflow powinniśmy używać? Wszystko zależy od celu, który mamy osiągnąć. Duże organizacje używają kilku systemów workflow, zwykle różnych producentów. Niczym niezwykłym jest używanie tego samego rozwiązania workflow do osiągnięcia kilku celów. Zapewnia to skalowalność systemów, by były jak najbardziej elastyczne. Produkcyjne Kluczowym zadaniem obsługiwanym przez systemu klasy produkcyjnej jest zarządzanie dużą liczbą podobnych zadań w celu optymalizacji produkcji. Osiąga się to przez automatyzację maksymalnie dużej liczby aktywności do momentu, gdy jest to praktycznie uzasadnione i przetwarzanie nie osiągnie optymalnej wydajności, a interakcja z człowiekiem zaistnieje wyjątkowo w przypadkach niemożliwych do automatycznego przetworzenia. Miejsca styku, w których człowiek wymagany jest w celach pracy są sukcesywnie minimalizowane. Systemy produkcyjne są optymalizowane do osiągnięcia wysokiej wydajności oraz jakości poprzez wykonywanie powtarzających się zadań, zwykle działających non-stop. Systemy produkcyjne mogą zarządzać kompleksowo produkcją oraz w dużej mierze być zintegrowane z istniejącymi systemami. Prowadzi to często do zagnieżdżania komponentów workflow w aplikacjach tak, aby mogły one działać jak Silnik Regułowy. Prowadzi to do dalszych możliwych klasyfikacji: Autonomiczne silniki workflow Są to systemy, które do funkcjonowania nie potrzebują żadnych dodatkowych aplikacji wyłączając aplikacje bazodanowe oraz różnego rodzaju aplikacje pośredniczące wymianie informacji np. kolejkowanie wiadomości. Autonomiczne systemy workflow są oddzielnymi częściami aplikacji, które udostępniają funkcjonalność przepływu pracy. Zwykle mają własne interfejsy użytkownika oraz odczytują dane z innych aplikacji. Instalowane są po to, by wspomóc pracę innych aplikacji. Wbudowane Workflow Systemy wbudowane workflow mają prawo działania tylko, jeśli są zagnieżdżone wewnątrz innych systemów, np. systemów ERP. Funkcjonalność workflow jest rozgrzeszeniem systemów ERP, CRM, itp. Wspólnym przykładem jest umożliwienie dla ERP zarządzania produkcją, czy jak w powyższym przykładzie umożliwienie systemom magazynowym kontroli swojej pracy, przekazanie dalej wyników jej wykonania. Komponenty workflow używane są do kontrolowania sekwencji funkcji aplikacji, zarządzania ich kolejnością oraz obsługiwaniem wyjątków w ich działaniu. Bardzo wartościową cechą jest możliwość definiowania reguł pracy aplikacji normalnie obsługiwanych przez zapadki bazodanowe lub inne mechanizmy niezależne od samego przepływu pracy. Rozwiązanie takie pozwala na kompleksową obsługę działania aplikacji w organizacji. Administracyjne Najważniejszą cechą administracyjnych systemów workflow jest łatwość definiowania procesów. Zazwyczaj w systemie działa równolegle klika instancji definicji procesu równolegle, które współpracują z dużą liczbą pracowników. Definicje procesów tworzone są za pomocą prostych formularzy. Jest to odwrotność systemów produkcyjnych gdzie wspomagana jest produkcja przez automatyzację procesów wytwórczych. W tym przypadku złożonym czynnikiem jest sam obieg dokumentu, opisany w definicji procesu.

15 Współpracy Systemy workflow oparte na współpracy skupiają się na zespołach pracujących razem w celu osiągnięcia wspólnego celu. Rozpiętość grup, w jakich działają waha się od małych grup roboczych porzez zespoły zorientowane projektowo, aż do bardzo zróżnicowanych grup, często rozproszonych, o wspólnych interesach (np. administracja publiczna). Obecnie w większości organizacji rozważa się używanie przynajmniej przepływu pracy opartego na współpracy, ponieważ podnosi on efektywność wykonywanych zadań w całym przekroju działalności przedsiębiorstwa. Użycie Internetu, a właściwie stron WWW do wspierania współpracy otwiera się na szeroką gamę odbiorców tego rodzaju systemów (e-państwo). Często systemy workflow oparte na współpracy nazywają się grupware. Z drugiej zaś strony jest szereg grup, których działań nie można sklasyfikować jako workflow, np. grupy dyskusyjne czy wideokonferencje, ponieważ nie występuje tam formalnie zdefiniowany przepływ pracy, a jedynie wymiana informacji w sposób nieustandaryzowany. AD-HOC Workflow typu Ad-hoc pozwalają użytkownikowi tworzyć oraz zarządzać definicjami procesów bardzo łatwo i szybko, spełniając przy tym wymagania, dla których zostały stworzone (zwykle dość proste ze względu na szybkość powstawania). Takie systemy pozwalają na dużą elastyczność tam, gdzie szybkość reakcji jest najważniejsza, ale pomijają zagadnienia związane z bezpieczeństwem. Systemy produkcyjne oczyszczają organizację przez definiowanie procesów dla całej struktury organizacyjnej w jednym miejscu. Organizacja ma wówczas spójnie zdefiniowane procesy w obrębie całej swojej działalności; w systemach typu Ad-hoc każdy użytkownik ma własne procesy, co może zaciemniać obraz organizacji. Podsumowując, prawie wszystkie klasyfikacje są pewnego rodzaju wyjątkami i pokrywają pewien zakres zapotrzebowania użytkowników, np. niektóre systemy produkcyjne pozwalają obecnie na pewne dynamiczne zmiany indywidualnych procesów przez specyfikacje dynamicznych właściwości w obrębie aktywności, np. warunki pomijania (skip-logic), czy różnego rodzaju delegaty itp. W ten sposób powstają produkty będące mieszankami wszystkich wyżej wymienionych typów. Komponenty workflow Silniki workflow rzadko, jeśli w ogóle pracują samodzielnie. Kiedy Workflow Managment Coalition rozpoczęło pracę nad zdefiniowaniem standardów dla przemysłu workflow w 1994 roku, kluczowym aspektem było zapewnienie współpracy pomiędzy silnikami workflow. Prace skupiały się na zagadnieniach znanych z języka C, wywołanie funkcji itp., a wiadomości przekazywane były za pomocą standardów MIME, w celach zapewnienia współpracy. Niektórzy członkowie koalicji zaczęli pracować nad obiektową wersją interfejsów. 2.2 Model implementacyjny systemu klasy workflow Różnorodność systemów typu workflow obecnie dostępnych powoduje potrzebę spójnego jednoznacznego modelu implementacyjnego, który byłby wstanie zaspokoić potrzeby większości użytkowników a jednocześnie zapewniałby odpowiedni poziom interoperacyjności. Podejście tego typu identyfikuje główne komponenty funkcjonalne w ramach, którego system workflow będzie mógł współpracować z modelem abstrakcyjnym. Obecnie istnieje wiele różnych systemów typu workflow, jednak nie wszystkie wspierają interoperacyjność, a większość nie ma wspólnej implementacji procesów biznesowych, co za tym idzie nie jest możliwe transferowanie części procesów pomiędzy różnymi środowiskami wykonawczymi. Zauważalnym współcześnie trendem, do którego dążą producenci systemów klasy workflow,

16 jest udostępnienie interfejsów do wymiany informacji. Zatem udostępnia to system wymiany informacji pomiędzy różnymi systemami WFM, co zapewnia częściową interoperacyjność. Model funkcyjny generycznego systemu przepływu pracy pokazany jest na Rys 7. Rysunek 7. Schemat generycznego systemu przepływu pracy. Model generyczny posiada trzy główne typy komponentów: Komponenty oprogramowania, które udostępniają szereg funkcji w ramach systemu workflow (symbole wypełnione ciemnym kolorem), Różne typy definicji systemu dla różnych funkcji i danych (symbole niewypełnione) używane przez jeden lub więcej komponentów programowych, Aplikacje oraz bazy danych aplikacji (symbole wypełnione szarym kolorem), które nie są częścią systemu workflow, ale mogą z nim współpracować, jako część systemu przepływu pracy. 3. Zadanie do wykonania Wykorzystując narzędzia do modelowania i wykonania procesów (przykładowe narzędzia: Enhydra Jawe, Enhydra Shark- BizAgi Process Modeler-

17 należy zapoznać się z obsługą tych narzędzi, dołączoną dokumentacją oprogramowania i przykładowymi modelami procesów oraz zamodelować przykładowy proces wspomagania zarządzania w organizacji (np. proces obsługi zamówień w organizacji, obsługi wniosku o urlop, obiegu dokumentów finansowych, itp.)