Wniosek o dofinansowanie

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: www.wfmc.org, www.bpmi.org,
http://www.itposter.net/itPosters/bpmn/bpmn.htm
• Przykładowe narzędzia : Enhydra Jawe, Enhydra Shark- www.enhydra.org, BizAgi
Process Modeler- www.bizagi.com
1. 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).
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ą
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
informatycznych wspomagających zarządzanie
systemów
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 9000-2006 pkt.0.2d
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
Analityk
d efi n i uj e
d e fi n iu j e
d e fi n iu j e
P roce sy b i zne so we
in i cj u je
P rzypa d ki u życi a
Wym a g a n i a
Czynność 1
wyn i ka z
Czynność 2
wyn i ka z
Wym a g a n i e 1
re a l i zu je
Wym a g a n ie 2
re a l i zu je
PU 1
PU 2
« i ncl u d e »
wyko n u j e
i m p le m e n tu j e
im pl e m e ntu j e
Di a g ra m kl a s
tworzy
Klasa 1
Klasa 2
o p e ru je n a
M o d el d an ych
Projektant
Encja 1
Encja 2
two rzy
0..*
1
Rys. 2 Zależności pomiędzy artefaktami
PU 3
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 zasady2:
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: www.processdriven.org
1.5 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.
•
•
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.
Certyfikacja
ISO
Zarządzanie
Jakością
Przebudowa
Procesów
(BPR)
BPM
Symulacja
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
Czytelnikowi w zapoznaniu się z BPMN, oraz z pozostałymi ważnymi dla modelowania
procesów biznesowych standardami.
1.6.1 BPMN - geneza i główne cele
BPMN został opracowany jako kluczowy element nowej inicjatywy w świecie architektury
korporacyjnej (Enterprise Architecture) – Zarządzania Procesami Biznesowymi (BPM3 –
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.
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ń).
1.6.2 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:
Zwi ni ęt a Jednost ka
Tor
Br amka
Zr ównol egl eni
a
War unkowe
Zdar zeni e
Począt kowe
Zwi ni ęt y
Podpr oces
Br amka
Rozłączna
St er owana
Zdar zeni em
Rozwi ni ęt a Jednost ka
Podpr oces Ad- hoc
[ st an1]
Pośr edni e
Zdar zeni e
Czasu
Br amka
Rozłączna
St er owana
Danymi
Mul t i i nst ancyj noś
ć
Zdar zeni e
Końcowe
Zadani e
Tor
Zadani e
Br amka
Zr ównol egl eni a
Pośr edni e
Zdar zeni e
Komuni kat u
Pośr edni e
Zdar zeni e
Komuni kat u
Obi ekt
Dat nych
Pr zepływ
Sekwencj i
Pęt l a
Zadani e
Tor
~
Zadani e
[ st an2]
Pośr edni e
Zdar zeni e Wyj ąt ku
Pośr edni e
Zdar zeni e Czasu
Pr zepływ
Wyj ąt kowy
Tor
Zadani e
Adnot acj a
Obi ekt
Danych
Wbudowany
Podpr oces
Obi ekt
Danych
Gr upowani e
Zadani e
Zadani e
Zakończeni a
Rys. 6 Przykładowy proces według BPMN
1.6.3 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).
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
Bramki
Przepływy
Sekwencji
Przepływy
Komunikatów
Przepływy Komunikatów używane są do pokazania
wymiany
komunikatów
pomiędzy
odrębnymi
uczestnikami procesu.
Asocjacje
Asocjacje służą do dołączania dodatkowych informacji
do Elementów Przepływu. Strzałka na końcu Asocjacji
wskazuje kierunek powiązania.
Jednostki
Jednostki służą do prezentowania uczestników
procesu. Zarówno Jednostki jak i Tory mogą być
prezentowane w sposób horyzontalny lub wertykalny.
Tory
Tory umieszcza się wewnątrz Jednostek. Służą do
organizowania Czynności wewnątrz Jednostki.
4
Symbol
Pool
Czynność
Opis
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ść 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 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 używane są do pokazania
kolejności, w jakiej Czynności będą wykonywane w
ramach procesu.
P oo l
Lane
Lane
Element
Zdarzenie
BPMN pozwala osobom modelującym lub narzędziom do modelowania na dodawanie dowolnych artefaktów
Obiekty
Danych
Grupa
Adnotacja
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.
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
o
o
o
o
•
Wzorce zaawansowane
o
o
o
o
o
•
Podział wielokrotny
Połączenie wielokrotne
Dyskryminator
Połączenie „N z M”
Połączenie synchroniczne
Wzorce strukturalne
o
o
•
Sekwencja
Podział równoległy
Synchronizacja
Podział typu XOR
Połączenie podstawowe
Pętle
Zakończenia
Wzorce anulowania
o
o
•
Wzorce stanów
o
o
o
•
Podział
XOR
wyzwalany
zdarzeniem
Częściowy przepływ równoległy
Wzorzec typu „kamień milowy”
Wzorce obejmujące wiele instancji
procesu
o
o
o
o
Wielokrotna instancja ze znaną
krotnością przed rozpoczęciem
Wielokrotna instancja bez znanej
krotności
Wielokrotna
instancja
z
krotnością ustalaną podczas jej
realizacji
Wielokrotna
instancja
z
synchronizacją
Anulowanie aktywności
Anulowanie procesu
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
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
:
http://www.itposter.net/itPosters/bpmn/bpmn.htm
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
6
Tłumaczenie własne na podstawie definicji Worflow w WfMC Terminology & Glosary–WfMC-TC-1011
Tłumaczenie własne na podstawie definicji Worflow Management System w WfMC Terminology & Glosary–WfMCTC-1011
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.
• 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,
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- www.enhydra.org, BizAgi Process Modeler-
www.bizagi.com) 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.)