WYŻSZA SZKOŁA ZARZĄDZANIA I BANKOWOŚCI W KRAKOWIE

WYDZIAŁ INFORMATYKI

PRACA SEMESTRALNA Inżynieria Oprogramowania

Mirosław Potaczek Mirosław Rożek

„Narzędzia wspomagające modelowanie biznesowe”

Kraków 2006

2

CZĘŚĆ I Wstęp ......................................................................................................................... 3 CZĘŚĆ II

Modelowanie biznesowe............................................................................................ 5 CZĘŚĆ III Model biznesowy........................................................................................................

7

3.1. Co to jest model biznesowy.......................................................................................... 7 3.2. Model procesów biznesowych i mapa przebiegu (łańcucha) czynności...................... 10 CZĘŚĆ IV

Techniki modelowania............................................................................................... 11 4.1. Podstawowe techniki modelowania............................................................................... 12 4.1.1. IDEF.................................................................................................................... 13 4.1.2. UML.................................................................................................................... 16 4.1.3. BPMN.................................................................................................................. 21 CZĘŚĆ V

Przykładowe aplikacje do modelowania................................................................... 37 CZĘŚĆ VI

Zakończenie................................................................................................................ 43 CZĘŚĆ VII

Bibliografia................................................................................................................ 45

3

CZĘŚĆ I

WSTĘP

4

Podstawowym przedmiotem niniejszej pracy jest przedstawienie modelowania

biznesowego oraz narzędzi, które temu służą.

Rozdział pierwszy poświęcony jest ogółowi modelowania biznesowego.

W rozdziale kolejnym swoją uwagę skupiliśmy na modelu biznesowym – czym on

jest, jak wygląda.

W rozdziale następnym przedstawiliśmy różne techniki modelowania biznesowego.

A teraz zapraszamy do bliższego zapoznania się z treścią naszej pracy.

5

CZĘŚĆ II

MODELOWANIE BIZNESOWE

6

W dzisiejszych czasach sytuacja rynkowa jest bardzo niestabilna, zwłaszcza z punktu

widzenia niedużych przedsiębiorstw. Managerowie robią wszystko, aby usprawnić działanie

swoich firm, nie tyle w sferze kontaktów z klientami czy dostawcami, co w sferze

wewnętrznego ich funkcjonowania. Niestety, dbanie o zachowanie prawidłowej struktury

organizacji bądź odpowiedni przepływ informacji jest trudne i często kłopotliwe, choć

konieczne. W wyniku działań mających na celu usprawnienie procesów czy też polepszenie

zarządzania wiedzą w przedsiębiorstwie pojawiły się różne metody, których zadaniem jest

uzdrowienie i ulepszenie organizmu, jakim jest firma. Jedną z nich jest modelowanie

procesów biznesowych.

Modelowanie biznesowe (z ang. Business Modeling) jest praktyką stosowaną

z powodzeniem przez wiele współczesnych przedsiębiorstw, ale mimo wszystko niezbyt

znaną.

Model biznesowy pozwala nam zrozumieć czym zajmuje się nasza firma, czemu akurat tym

i czemu akurat w taki sposób. Pozwala ponadto stwierdzić za co odpowiedzialne są konkretne

osoby w naszej firmie, jaka jest ich rola czy też zakres współpracy z innymi pracownikami.

Należy jednakże pamiętać o tym, by opisać każdy, nawet najmniejszy fragment naszej

rzeczywistości biznesowej i określić dokładnie jego miejsce w hierarchii oraz związki

z innymi elementami. To bowiem pozwoli uzyskać model kompletny i spójny, a co

najważniejsze - wiarygodny. Jest to ważne ze względu na integracje. Wdrażając nowy system

informacyjny czy też usprawniając działanie starego, musimy upewnić się, że "pasuje" on do

tego, co się w naszej firmie dzieje. Mam/y tu na myśli nie tyle integrację aplikacji czy

integrację systemową. W dzisiejszych czasach coraz częściej wspomina się o tzw. integracji

biznesowej, dotyczącej w dużej mierze procesów biznesowych powiązanych z daną

jednostką. Jest ona możliwa do osiągnięcia, ale wymaga precyzyjnego określenia reguł

operacyjnych biznesu oraz zrozumienia zasad jego działania - głównie poprzez integrację

samych procesów z wspomagającymi je systemami informacji.

7

CZĘŚĆ III

MODEL BIZNESOWY

8

3.1. Co to jest model biznesowy

Model biznesowy opisuje kontekst rynkowy firmy. Jest to diagram, często

z dodatkowym opisem, obrazujący role firmy w łańcuchu wartości na rynku, w łańcuchu

zaopatrzenia. Obrazuje także wszystkie zależności z otoczeniem rynkowym. Jest

podstawowym elementem zobrazowania strategii firmy, jej roli i pozycji na rynku. Przyjmuje

różne postacie. Wybór metody zobrazowania jest tu drugorzędny, ważne by diagram był

czytelny, jasny i jednoznacznie określał wszystkie zależności i kanały informacyjne w jakich

firma bierze udział. Jest bardzo przydatny w budowaniu planu marketingowego, także jako

jego późniejsza ilustracja.

Poprawny model biznesowy określa przepływ wartości dodanej i przepływ środków za

oferowane na rynku wartości, przepływy informacji.

Poprawny model biznesowy powinien definiować dwa podstawowe obszary:

1. przepływ wartości dodanej i przepływ środków za oferowane na rynku wartości,

2. przepływy informacji.

Rys. 3.1.1. Przykład rzeczywistego modelowanie biznesowego

9

3.2. Model procesów biznesowych i mapa przebiegu (łańcucha) czynności

Jest to opis wnętrza firmy. Zależnie od potrzeby i wymaganego stopnia dokładności

diagramy tego typu opisują sposób funkcjonowania firmy. Model procesów jest niejako

naturalnym rozwinięciem do wewnątrz modelu biznesowego firmy. W połączeniu z modelem

biznesowym stanowi kompletny opis roli firmy na rynku oraz tego jak ta rola jest wewnątrz

firmy realizowana. W najprostszej postaci może być to diagram obrazujący podstawowe

funkcje jakie realizuje forma. Schemat taki służy najczęściej do zaprezentowania na wysokim

poziomie abstrakcji pracownikom lub osobom z zewnątrz tego co firma tak na prawdę robi.

Pozwala to szybko przekazać wiedze o specyfice firmy.

Do celów reorganizacji lub dokumentowania obrazu firmy na potrzeby n. wdrożeń systemów

IT wykonuje się modele dokładniejsze. Poniżej fragment mapy procesów biznesowych.

Obrazuje ona podstawowe procesy w firmie i związki pomiędzy nimi. Model taki może także

obrazować łańcuch procesów uwzględniając np. bezpośrednich dostawców i odbiorców.

Stosowane są tu tak zwane notacje modelowania. Może to być IDEF0, ARIS/eEPC czy

BPMN. IDEF0 to notacja często jeszcze wykorzystywana w dokumentowania procesów

biznesowych. jej zaletą jest duża skuteczność jednak praktycznie nie jest wspierana przez

organizacje związane z technologiami modelowania. ARIS to potężne narzędzie

wykorzystujące jako podstawową notację eEPC (ang. extend Event Driven Process Chain).

Pozwala tworzyć w zespołach nawet bardzo skomplikowane modele dużych organizacji.

Ostatnia, BPMN (Business Process Modeling Notation) jest coraz częściej wykorzystywana

przez analityków jako narzędzie do tworzenia modeli firm. Notacja jest kompatybilna z BPEL

(ang. Business Process Execution Language) co pozwala np. wykorzystać stworzony model

dalej w pracach programistycznych.

10

CZĘŚĆ IV

TECHNIKI MODELOWANIA

11

4.1. Podstawowe techniki modelowania

Wybór techniki modelowania może stanowić problem, z uwagi na ilość dostępnych

rozwiązań. Technik jest wiele, ciągle trwają prace nad ich udoskonalaniem i rozwojem,

w rezultacie czego powstają zupełnie nowe koncepcje. Śledzenie tych badań jest niewątpliwie

ciekawe, ale rzadko który manager może sobie pozwolić na czasochłonne rozważania na

temat wyższości wybranej techniki modelowania nad innymi. Rozwiązania kompleksowe

często nie sprawdzają się w obliczu specyficznych sytuacji, w jakich znajdują się

przedsiębiorstwa. Standaryzacja bywa uciążliwa - każde odstępstwo od normy stanowi

problem, często nie do przejścia dla szeregowego pracownika. Obecnie preferuje się techniki

modelowania poszczególnych części biznesu, np. Analizę Działań (Activity Analysis),

Analizę Potrzeb (Need Analysis), Analizę Przypadków Użycia (Use CASE Modeling) czy

Modelowanie Pojęciowe (Conceptual Modeling). Takie podejście pozwala uniknąć

problemów w przypadkach nietypowych sytuacji. Techniki te są jednak tak skonstruowane, że

zastosowane razem, pozwolą na uzyskanie modelu kompletnego, o który przecież nam

chodzi. Kolejną kwestią, o której należy w tym miejscu wspomnieć, jest problem niespójności

modelowania. W przypadku pracy grupowej techniki modelowania mogą się różnić ( nie ma

przecież najlepszej - nasz wybór jest zatem subiektywny). Nawet stosowanie tej samej

techniki może być inne w przypadku różnych projektów, co może prowadzić do powielania

pracy czy poważnych jej utrudnień wymagających dodatkowych nakładów czasu.

Przykładowe techniki modelowania:

• IDEF - Integrated DEFinition Methods,

• UML - Unified Modeling Language (czyli Ujednolicony Język Modelowania),

• BPMN - Business Process Modeling Notation.

12

4.1.1. IDEF

Od wielu lat prowadzone są przedsięwzięcia mające na celu standaryzację metod opisu

procesów i sposobów pozyskiwania informacji potrzebnych do budowy modelu. Departament

obrony USA opracował w latach 70. normę tworzenia przebiegu procesu IDEF0 (Integration

DEFinition language 0). Stosowana była ona jako narzędzie tworzenia programów

komputerowych wspomagających procesy produkcyjne, później przyjęła się jako narzędzie

umożliwiające sporządzenie wykresów procesów w firmach usługowych i produkcyjnych.

Norma IDEF0 pomóc ma ustaleniu zakresu analizy oraz zbudowaniu relacji pomiędzy

analitykiem i jego klientem. IDEF0 może być pojmowane zarówno jako narzędzie

komunikacji za sprawą znormalizowanych symboli graficznych, jak i jako narzędzie analizy,

ukazujące jakie czynności mają być wykonane w celu prawidłowego wymodelowania

procesu. Norma IDEF0 pomaga również w ustaleniu słabych i mocnych stron modelowanego

systemu.

Podstawowym założeniem IDEF0 jest umieszczanie poszczególnych funkcji

wchodzących w skład procesu w prostokątnych ramkach, w sposób przestawiony na rysunku.

Strzałki wchodzące z lewej strony oznaczają wejścia funkcji – nakłady materiałowe

i informacyjne, strzałki wychodzące z prawej strony reprezentują wyjście funkcji – czyli

materialne i niematerialne efekty jej wykonania. Strzałki wchodzące z góry symbolizują

mechanizmy sterowania funkcją (np. wewnętrzna politykę firmy lub czynniki zewnętrzne),

zaś strzałki wchodzące od dołu – mechanizmy niezbędne do wykonania funkcji – np.

narzędzia, pojazdy, wykonawców. Modele zbudowane mogą być z wielu funkcji połączonych

sobą za pomocą strzałek w taki sposób, że wyjścia jednej funkcji są wejściami lub

mechanizmami sterowania dla innych funkcji. Norma uwzględnia również możliwość

współbieżnego wykonywania dwóch lub więcej funkcji – w sytuacji, gdy wyjście jednej

funkcji jest wejściem dla wielu innych funkcji. Każda funkcja opisana może być przez

osobny, podrzędny model.

Norma IDEF0 szczegółowo i precyzyjnie opisuje sposób umieszczania funkcji,

strzałek i ich opisów. Każda funkcja, strzałka i model opisane są przez nadany zgodnie

z normą identyfikator. Zgodnie z normą IDEF0 model główny oznaczony jest symbolem A-0

(A minus 0) i znajduje się w nim jedna, nadrzędna funkcja A0. Opisana może być ona przez

model A0, a funkcje w nim się znajdujące nosić będą oznaczenia A1, A2, A3, itd. Model

podrzędny opisujący funkcję A1 nosić będzie również oznaczenie A1, a funkcje w nim się

13

znajdujące – symbole A11, A12, A13, itd. Ten usystematyzowany sposób opisu umożliwia

szybsze stworzenie spisu poszczególnych modeli i funkcji. Zależności między modelami

podrzędnymi i nadrzędnymi ukazać można też graficznie za pomocą drzewa hierarchii

funkcji. Norma IDEF0 ogranicza do sześciu ilość funkcji, które znajdować mogą się

w modelu podrzędnym.

Norma IDEF0 zawiera również szereg zaleceń dotyczących odpowiedniego sposobu

tworzenia modelu, zbierania potrzebnych do jego sporządzenia danych oraz oceny

zbudowanego modelu. Implementację normy IDEF0 umożliwiają różne narzędzia

informatyczne - jednym z nich jest AI0 WIN firmy KBSI.

Rozwinięcie i uzupełnienie normy IDEF0 stanowią kolejne normy IDEF. Norma

IDEF1 umożliwia zbudowanie modelu ukazującego strukturę przepływu informacji

w systemie. Norma IDEF2 ukazuje sposób zbudowania dynamicznego modelu pokazującego

zależności czasowe pomiędzy funkcjami. Rozwinięciem normy IDEF1 jest norma IDEF1X,

służąca do projektowania relacyjnych baz danych.

Norma IDEF3 jest kompleksową metodą modelowania procesów. Została stworzona

pod kątem zobrazowania łańcucha następujących po sobie działań. Zawiera opis

mechanizmów, umożliwiających zebranie odpowiednich do opisu procesu informacji. Norma

IDEF3 używa definicji procesu według Davenporta i Shorta, zgodnie z którą proces

biznesowy to „uporządkowany ciąg wydarzeń angażujących osoby, surowce, energię

i wyposażenie, który to ciąg zaprojektowany jest dla osiągnięcia określonego rezultatu”.

Przesłankami do stworzenia normy IDEF3 były czynniki takie jak zwiększenie wydajności

analizy systemów biznesowych, ułatwienie zbudowania opisu wymagań systemu, wspieranie

procesu zarządzania projektami.

Norma IDEF3 jest zbudowana w sposób, który umożliwia zrozumienie metody opisu

przez osoby nie zajmujące się modelowaniem procesów, ma też ułatwić łatwe poznanie różnic

pomiędzy różnymi, alternatywnymi wersjami procesu.

Podstawowym elementem schematu procesu według normy IDEF3 jest symbol UOB

(Unit of Behavior box), ukazujący pojedyncze działanie (funkcję), które przedstawiane jest za

pomocą odpowiednio opisanego prostokąta. Symbole UOB łączone są za pomocą różnego

typu połączeń (links), przedstawianych za pomocą strzałek.

Rozgałęzienia procesu w schematach IDEF3 przedstawiają węzły (junctions), które

zachowują się w sposób podobny do operatorów w programie ARIS. Występują węzły AND,

rozdzielające proces na wiele równolegle przebiegających gałęzi, węzły OR (węzeł ten

aktywuje jedną lub więcej gałęzi) oraz XOR (węzeł aktywuje jedną gałąź z kilku możliwych).

14

Dodatkowo występują węzły synchroniczne (synchronous) OR i AND, które oznaczają

rozpoczęcie wielu odpowiednich dla danego węzła gałęzi w tym samym momencie (nie

występuje synchroniczne XOR, gdyż po węźle aktywowana jest jedynie jedna gałąź).

W symbolu okręgu umieszczane są występujące w procesie obiekty (na przykład

poszczególne komponenty używane w produkcji), bądź stany tych obiektów.

Norma IDEF3 ukazuje też kolejność przeprowadzania reorganizacji procesów, dzieląc

ją na następujące etapy:

1. Udokumentowanie istniejącego procesu

2. Zidentyfikowanie zebrania najważniejszych dla procesu danych

3. Przeanalizowanie istniejącego procesu

4. Zaprojektowanie nowego procesu

5. Wyznaczenie alternatyw i wyboru konkretnej alternatywy

6. Opracowanie projektu biznesowego

7. Uzyskanie zgody na implementację zmian

8. Zaplanowanie i wdrożenie zmian

9. Ciągłe ulepszanie procesu

Normy IDEF stanowią więc nie tylko zbiór metod opisu procesów i systemów

informacyjnych, ale zawierają też sposoby zbierania danych i metody przeprowadzania

zmian. Wsparte odpowiednimi narzędziami informatycznymi stanowić mogą więc

podstawę dla przedsięwzięć z zakresu zmian procesów w organizacjach gospodarczych.

15

4.1.2. UML

UML został właściwie wymyślony jako język, który pomaga wizualizować,

specyfikować, konstruować i dokumentować zaawansowane oprogramowanie. Projektanci

UML sprawili, że możliwe jest rozszerzenie języka w taki sposób, aby odnosił się on do wielu

różnych dziedzin. Ta cecha umożliwiła UML zostanie językiem zarówno dla tradycyjnego

modelowania biznesowego, jak również dla systemowej analizy i projektowania.

UML został pomyślnie zastosowany do modelowania różnorodnych systemów tj.:

q struktur danych do systemów czasu rzeczywistego,

q schematów XML (Extensible Markup Language),

q organizacji – począwszy od małych prodzinnych firm, poprzez większe

przedsiębiorstwa, a skończywszy na przedsiębiorstwach międzynarodowych.

Zatem nie jest zaskoczeniem, że analitycy biznesu uważają UML za bardzo poręczny system

do wizualizacji procesów w organizacji.

UML jest bardzo przydatny, to najbardziej potężna, najelastyczniejsza notacja

dostępna dla modelowania biznesowego w obecnych czasach. Pomaga zarządzać złożonością,

zredukować czas developingu i ulepszyć jakość systemu. Istnieje sześć głównych powodów

dlaczego:

1. UML dostarcza wspólnego języka dla analityków biznesu i producentów

2. UML jest wizualny, poglądowy, ilustracyjny

3. UML jest zorientowany obiektowo

4. UML opisuje procesy biznesu zarówno strukturalnie i dynamicznie

5. UML pomaga skupić się na kliencie

6. UML pomaga wyprowadzić wymagania systemowe

Popatrzmy na każdy z tych powodów dokładniej. 1. UML dostarcza wspólnego języka dla analityków biznesu i producentów

UML umożliwia modelowanie procesów biznesowych używając tych samych symboli,

diagramów i innych form notacji, których używa grupa projektantów, by modelować systemy

oraz aby utworzyć albo automatyzować te procesy. Używanie wspólnego języka umożliwia

16

coś, co wcześniej nie było możliwe w rozwoju oprogramowania: analitycy biznesu

i projektanci mogą się porozumieć!

Brzmi to dość prosto, ale zanim UML zanim został zastosowany do modelowania

biznesowego, zawsze była rozłączność pomiędzy projektowaniem biznesowym

i projektowaniem systemowym. UML w wielkim stopniu eliminuje przepaść pomiędzy

developerami, kierownictwem i klientami. Kiedy zaczynasz z modelem bazującym na UML,

kluczowe rozważania biznesowe są bardziej włączone do systemowych wymagań i to

ostatecznie prowadzi do tego, że system, który służy klientom jest lepszy.

2. UML jest wizualny, poglądowy, ilustracyjny

Moim zdaniem, perspektywy oferowane przez diagram przepływu i arkusze kalkulacyjne są

zbyt liniowe, aby efektywnie modelować biznes. Ograniczony punkt widzenia może

spowodować, że źle lub odmiennie spojrzymy na to, co prowadzi proces, gdzie jest wąskie

gardło albo jak przepływa informacja. Aby w pełni modelować , potrzebna jest odpowiedź na

tradycyjne pytania : jak?, kto?, co?, dlaczego? i kiedy? to ma miejsce.

UML pozwala wizualizować, jak działa model. Jak?, kto?, co? są reprezentowane jako

symbole i diagramy. W tym kontekście, związki, działalności i przepływy informacji, dobra

i wszystkie usługi stają bardziej oczywiste. Te wizualne odwzorowania umożliwią.

Zobaczenie wąskich gardeł, a także to w jaki sposób przepływa informacja (albo i nie)

i określić kto co robi z twoją informacją biznesową. Na przykład, wizualny model upraszcza

kiedy zbyt dużo informacji musi płynąć przez pojedynczy punkt, wskazuje na potencjalną

potrzebę przekierowania przepływu do innego procesu.

Dobrze zbudowany wizualny model biznesu– taki, jak umożliwia UML – odpowie na

wszystkie fundamentalne pytania :

q Kim są twoi wewnętrzni i zewnętrzni klienci? (kto skorzysta na tym systemie

biznesowym),

q Gdzie system może wzbogacić wartość do twojego biznesu?

q Jakie zdarzenia w/albo na zewnątrz organizacji wywołują każdy proces biznesowy?

q Jakie końcowe produkty produkują procesy biznesowe?

q Jakie wewnętrzne elementy wiążą się z procesami biznesowymi?

q Co jest organizacyjną strukturą która wspomaga biznes?

q Jakie role i odpowiedzialności w obrębie tych struktur organizacyjnych powinny być

częścią systemu?

17

3. UML jest zorientowany obiektowo

Kiedy modelujesz przy użyciu UML, twoje biznesowe zainteresowania są wyraźnie

naszkicowane w stosunku do odpowiednich biznesowych przedmiotów, w formie

biznesowego modelu przedmiotu. Obiekty są jednostkami, które dorównują obiektom

w świecie rzeczywistym : maja różne właściwości (takie jak imię i adres), powiązane w różne

sposoby z innymi rzeczami otaczającymi, ukazują różne zachowania, kiedy wpływają na

siebie. Obiektowo zorientowane modele mogą bardzo przybliżać obiekty biznesowe

i systemowe, nawet do przedstawiania jak różne części systemu współpracują razem

dynamicznie. To prawda, ponieważ obiekty, które obejmują modele UML odzwierciedlają

dokładnie jednostki świata rzeczywistego. To znaczy, że obiektowo zorientowane modele są

bardziej konkretne i lepiej opisane i ogólnie bardziej elastyczne i intuicyjne.

Weźmy za przykład obiektowo zorientowany opis roli pracownika. Prawdopodobnie

zawarłby informację o zachowaniu, taką jak odpowiedzialność za prace, szacunek do innych

pracowników, opis pracy, etc.

4. UML opisuje procesy biznesu zarówno strukturalnie i dynamicznie

Biznes staje się bardziej zautomatyzowany, bardziej powiązane systemy oprogramowania

tworzą rdzeń biznesowej wartości, która jest dostarczana klientom. Zrozumienie jak te

przeplatane systemy oddziałują wzajemnie na siebie i jak skierować ich pomyślny rozwój

w odpowiedzi na zmieniający się krajobraz biznesu prowadzi do zdecydowanego sukcesu.

Wartość UML w tym kontekście jest taka, że pozwala patrzeć na rzeczy wewnątrz biznesu

zarówno strukturalnie, jak i dynamicznie. UML ma wiele różnych typów diagramów, które

pozwalają reprezentować informację z różnych punktów widzenia, a to całkowicie opisze

twój biznes i dostarczy istotnych informacji.

Przypadki użycia UML (USE CASES) opisują procesy biznesowe w taki sposób w jaki

aktorzy (klienci) go widzą, by osiągnąć jakiś cel. Przypadki użycia opisują kompletny proces

biznesowy od jego początku do końca, od zewnętrznej perspektywy. To jest w bezpośrednim

kontraście do wielu tradycyjnych metodologii modelowania biznesowego, które rozkładają

albo dzielą procesy wzdłuż linii funkcjonalnych. Przy takiej dekompozycji całość nie jest

potrzebna, by zsumować części. Opisy procesów stają się odizolowane od siebie i ich relacje

stają się mniej oczywiste. Kiedy to się dzieje, korzyść jest mniej wymierna i ich wartość staje

się bardziej subiektywna.

Wartość UML staje się oczywista kiedy kierujesz modelowanie biznesowe wzorując się na

problemie biznesowym. Z konwencjonalnymi metodologiami, kluczowe zagadnienia mogą

18

łatwo zostać źle zinterpretowane, ponieważ te metodologie często przeoczają dynamiczne

związki, które wpływają na proces.

UML, w kontraście, dostarcza bogatych alternatyw dla opisów dynamicznych i połączeń

świata rzeczywistego, które są częścią i rozdzielają nowoczesne systemy biznesowe.

Różnorakie spojrzenia UML na model naprawdę pomagają zrozumieć problem z różnych

stron. Ponadto, ponieważ UML dostarcza wspólnego języka i współdzielonych podstaw dla

dyskusji między sztabem rozwojowym a biznesowym, nie ma potrzeby by tłumaczyć model

na słowa.

5. UML pomoże skupić się na kliencie

Metodologia modelowanie biznesowego UML obraca się wokół biznesowego użycia

przypadków, które podkreślają jaką biznesową wartość dostarcza się do klienta. Ta

perspektywa pomaga pojmować zewnętrzny widok systemu, który tworzysz. To jest

szczególnie skuteczne i użyteczne podejście w kontekście biznesowym, gdzie zewnętrzne

skupienie jest bardziej decydujące o sukcesie.

W UML, biznesowe użycie przypadków jest zdefiniowane jako „Sekwencja zadań

przedstawionych przez biznes, które uzyskują możliwy do zaobserwowania rezultat wartości

dla każdego klienta biznesowego”.

Procesy biznesowe są jak zautomatyzowane systemy biznesowe; obejmują konkretne

zachowanie organizacji. Ponieważ procesy biznesowe są środkami developingu ważnymi dla

klientów, sukces organizacji zależy całkowicie na przedstawieniu jego procesu biznesowego

(czy są zautomatyzowane czy nie).

Biznesowe przypadki użycia UML są zbudowane na podstawie przekazania założenia jak

działa system i jak klient będzie go używać.

6. UML pomoże wyprowadzić wymagania systemowe

Z jego bogatymi opisami relacji pomiędzy komponentami, aktorami biznesowymi i innymi

jednostkami, UML sprawia, że jest to łatwiejsze niż inne podejścia do modelowania, by

zidentyfikować, gdzie system najlepiej pasuje w biznesowym kontekście. To, w rezultacie

umożliwia większą czytelność walidacji wymagań systemowych. Końcowym efektem jest

działający system biznesowy, który rozwiązuje specyficzne procesy biznesu. Napotykając

realne potrzeby dostarcza optymalną wartość do klientów.

Ponadto biznesowe modele bazujące na UML , które Twoja grupa stworzyła mogą przetrwać

jako bezpośrednie wkłady do potrzebnych modeli.

19

The Rational Unified Process (RUP) dostarcza bezpośrednie mapowanie pomiędzy modelem

biznesowym UML a analitycznymi wymaganiami modelu.

20

4.1.3. BPMN

Business Process Management Initiative (BPMI) rozwinęła Business Process Modeling

Notation. Specyfikacja BPMN 1.0 została wydana w Maju 2004 roku. Specyfikacja ta prezentuje

ponad dwuletnia pracę BPMI Notation Working Group. Celem pracy BPMN było dostarczenie

notacji, która będzie łatwa do zrozumienia przez wszystkich biznesowych użytkowników, od

biznesowych analityków, którzy tworzą początkowe szkice procesów do developerów

odpowiedzialnych za implementację technologii, a w końcu do ludzi, którzy będą nią

zarządzać i monitorować procesy.

BPMN definiuje Biznesowy Diagram Procesu (Business Process Diagram – BPD), który bazuje

na technice diagramów przepływu, dopasowanej do tworzenia graficznych modeli operacji

procesów biznesowych. Biznesowy Diagram Procesu (BPD) więc jest siecią graficznych

obiektów, które są aktywnościami/zadaniami (np. praca) i kontrolami przepływu, które

definiują kolejność wykonywania.

Podstawy BPMN

Biznesowy Diagram Procesu (BPD) jest złożony z kompletu graficznych elementów.

Te elementy umożliwiają łatwy rozwój prostych diagramów, które wyglądają znajomo dla

większości analityków biznesowych. Elementy zostały tak wybrane, aby były łatwe do

rozróżnienia i wykorzystywały znane już kształty, np. zadania to prostokąty, romby to

decyzje. Powinno zostać podkreślone, że jednym z celów dla twórców BPMN jest stworzenie

prostego mechanizmu do tworzenia modeli procesów biznesowych a jednocześnie w być

wstanie radzić ze złożonością właściwą do procesów biznesu. Propozycja do podjęcia tych

dwóch kolidujących wymagań było uporządkowanie graficznych aspektów notacji

w określone kategorie. To dostarczyło małego kompletu kategorii notacji, wiec czytelnik

BPD mógł łatwo rozpoznawać podstawowe typy elementów i rozumieć diagram.

W podstawowych kategoriach elementów, dodatkowe warianty i informacje mogą być dodane

by wspierać wymagania dla złożoności bez znacznego zmieniania prostego wyglądu

diagramu. Czterema podstawowymi kategoriami elementów są:

- obiekty przepływu,

- obiekty łączące,

- swimlane (z Ang.),

- artefakt.

21

Obiekty przepływu

PBD posiada mały komplet trzech rdzennych elementów, tak więc modelujący nie

musi się uczyć i rozpoznawać wielkiej ilości różnych figur. Tymi trzema obiektami

przepływu są:

Zdarzenie Zdarzenie jest reprezentowane przez

okrąg i coś co dzieję się podczas biegu

procesu biznesowego. Te zdarzenia

oddziaływają na przepływ procesu

i zazwyczaj maja przyczynę i rezultat.

Są trzy typy zdarzeń : start, etap

pośredni i koniec (patrz na figury,

zaczynając od lewej)

Aktywność Aktywność jest reprezentowana przez

prostokąt z zaokrąglonymi rogami i jest

ogólnym określeniem pracy, która jest

wykonywana. Aktywność może być

„atomowa” lub „nieatomowa” (w tym

znaczeniu – złożoność). Typami

aktywności są zadanie i pod-proces.

Pod-proces jest dystyngowany przez

znak plusa po środku dna figury.

Przejście Przejście jest reprezentowane przez

romb i jest używane do kontrolowania

rozbieżności i zbieżności przepływu

sekwencji. Do tego stopnia, że

rozpoznaje tradycyjne decyzje, takie jak

rozwidlenie, łączenie, dołączanie dróg.

Wewnętrzne znaki wskazują na typ

kontroli zachowania.

22

Obiekty łączące

Obiekty przepływu są połączone w diagram, aby stworzyć główny szkielet struktury

procesu biznesowego. Są trzy obiekty łączące które realizują tę funkcje. Te „łączniki” to:

Kolejność

przepływu

Kolejność przepływu jest reprezento-

wana przez strzałkę z wypełnionym

grotem (patrz na ilustracje po prawej)

i jest używana do pokazania kolejności

(sekwencji) aktywności, która będzie

wykonywana w procesie.

Przepływ

komunikatu

Przepływ komunikatu jest reprezento-

wany przez strzałkę rysowaną linią

przerywana z niewypełnionym grotem

(patrz na ilustracje po prawej) i jest

używana do pokazania jak przepływają

komunikaty pomiędzy dwoma

oddzielnymi uczestnikami procesu,

którzy je wysyłają i odbierają.

W BPMN dwa oddzielne Pool (z Ang.)

będą oznaczać dwóch uczestników.

Asocjacja Asocjacja jest reprezentowana przez

kropkowaną strzałkę i grot z lini (patrz

na ilustracje po prawej), jest wykorzy-

stywana do skojarzenia danych, tekstu

i innych artefaktów z obiektami

przepływu. Asocjacje są używane do

pokazania wejść i wyjść w czynno-

ściach.

Dla osoby tworzącej model, która wymaga lub pragnie niskiego poziomu precyzji do

stworzenia modelu procesu do dokumentacji i do celów komunikacji, rdzenne elementy oraz

23

„łączniki” dostarczą możliwości łatwego stworzenia zrozumiałych diagramów (przykład

poniżej).

Rys. 4.1.3.1. Przykład prostego procesu biznesowego

Dla osoby tworzącej model, która wymaga większego poziomu precyzji do stworzenia

modelu, który będzie poddany szczegółowej analizie może dodać dodatkowe detale do

rdzennych elementów i pokazać je poprzez wewnętrzne znaki. (przykład poniżej)

Rys. 4.1.3.2. Część procesu z większą szczegółowością

24

Swimlane

Wiele metodologii modelowania procesu wykorzystuje koncepcje „swimlane” jako

mechanizmu do organizacji aktywności jako oddzielnych wizualnych kategorii w porządku

ilustrującym różne funkcjonalne zdolności lub odpowiedzialności. BPMN wspiera dwie

główne konstrukcje. Dwa typy „swimlane” w BPD to:

Pool Pool reprezentuje uczestnika

w procesie. Poza tym występuje jako

graficzna otoczka dla przegrodowych

zbiorów aktywności z innych

Pool’ow (patrz na ilustracje po

prawej)

Lane Lane jest pod-przegrodą w Pool’u

i będzie obejmować cała długość

Pool’a, zarówno w płaszczyźnie

pionowej i poziomej (patrz na

ilustracje po prawej).

Lane są używane do organizowania

i klasyfikowania aktywności.

Pool’e są używane kiedy diagram obejmuje dwie oddzielne jednostki biznesowe lub dwóch

uczestników i są fizycznie oddzielone w diagramie. Aktywności w oddzielnych Pool’ach są

rozpatrywane w swoich otoczkach procesu. W ten sposób kolejność przepływu może nie

przekraczać obszaru Pool’a. Przepływ komunikatu jest zdefiniowany jako mechanizm będący

do pokazania komunikacji pomiędzy dwoma uczestnikami, i w ten sposób, muszą zapewniać

połączenie pomiędzy dwoma Pool’ami (albo obiektami w Pool’ach).

25

Rys. 4.1.3.3. Przykład BPD z użyciem Pool

Lane są bardziej powiązane do tradycyjnego modelowania przy użyciu metodologii

„swimlane”. Lane są przeważnie używane do oddzielenia aktywności powiązanej ze

specyficzną funkcją lub rolą w firmie (Patrz na ilustracje poniżej). Kolejność przepływu może

przekraczać obszar Lane w Pool’u, ale Przepływ komunikatu może nie być użyty pomiędzy

obiektami przepływu w Lane w tych samych Pool’ach.

Rys. 4.1.3.4. Segment procesu z Lane

26

Artefakty

BPMN został stworzony, aby umożliwić modelującemu i narzędziom modelującym na pewną

elastyczność w rozszerzaniu podstawowych notacji i dostarczaniu możliwości do

dodatkowego kontekstu przeznaczania do specyficznych sytuacji modelowych, takich jak

pion rynkowy (np. bankowość). Jakakolwiek ilość artefaktów może być dodana do diagramu

jako stosowny dla kontekstu procesu biznesowego jaki jest modelowany. Obecna wersja

specyfikacji BPMB predefiniuje tylko trzy typy artefaktów BPD. Są to:

Obiekt Danych Obiekty danych to mechanizmy do

pokazania jak dane są wymagane lub

produkowane przez aktywności. Są

połączone do aktywności przez

asocjacje.

Grupa Grupa jest reprezentowana jako

prostokąt z zaokrąglonymi rogami,

rysowane linią przerywaną (patrz

ilustracja po prawej). Grupowanie może

być używane przy dokumentowaniu lub

analizowaniu celów. Nie mają wpływu

na przepływ sekwencji.

Adnotacja Adnotacje są po to, by zapewnić

dodatkową informację tekstową dla

osoby czytającej diagram BPMN (patrz

ilustracja po prawej).

Modelujący może stworzyć swoje typy artefaktów, dzięki czemu może oddać wecie detali

o tym jak proces przebiega, dość często do pokazania wejść i wyjść aktywności w procesie.

Jednakże, podstawowa struktura procesu, określana jako Aktywności, Przejście, Kolejność

przepływu, nie zmieniały się w dodatku z Artefaktami w diagramu jak można to zobaczyć

porównując rys. 4.1.3.4. i rys. 4.1.3.5.

Tekst Adnotacji

Nazwa (Wyrażenie)

27

Rys. 4.1.3.5. Segment procesu z Danymi Obiektu, Grupami i Adnotacjami

Główne użycia BPMN

Modelowanie procesów biznesowych jest używane do komunikacji szeroko zróżnicowanej

informacji dla różnych odbiorców. BPMN jest stworzony do obejmowania wielu typów

modelowania i pozwala na kreowanie segmentów jak również procesów biznesowych na

różnych poziomach dokładności. W związku z różnorodnością celów modelowania procesu,

są dwa podstawowe typy modelów które mogą być stworzone przy pomocy BPD:

- Collaborative (Public) B2B Processes

- Internal (Private) Business Processes

Collaborative B2B Processes (Wspólny)

Collaborative (Public) B2B Processes przedstawia interakcje pomiędzy dwoma lub więcej

jednostkami biznesowymi. Diagramy dla tych typów procesów generalnie są z ogólnego

punktu widzenia. Tzn., że one nie pokazują żadnego konkretnego uczestnika, ale pokazują

interakcje pomiędzy uczestnikami. Interakcje są przedstawiane jako sekwencja aktywności

wymiany wiadomości pomiędzy uczestnikami. Aktywności dla współpracy uczestników

mogą być traktowane jako „touch-points” pomiędzy uczestnikami. W ten sposób proces

28

definiuje interakcje która jest widoczna publicznie dla każdego uczestnika. Kiedy patrzy sę na

proces pokazany tylko w jednym Pool’u (np. dla jednego uczestnika), publiczny proces jest

wakże nazywany jako proces abstrakcyjny. Rzeczywiste (wewnętrzne) procesy

prawdopodobnie mają więcej działań (aktywności, funkcji) i detali niż te, które są pokazane

w collaborative B2B processes.

Rys. 4.1.3.6. Przykład Collaborative B2B Processes

Internal Business Processes

Internal Business Processes generalnie skupia się na punkcie widzenia pojedynczej

organizacji. Pomimo tego wewnętrzne procesy często pokazują interakcje z zewnętrznymi

uczestnikami, definiują aktywności, które generalnie nie są widoczne dla publiki, i są dlatego,

prywatnymi aktywnościami. W „swimlane” są używane wtedy, gdy wewnętrzny proces

biznesowy będzie zawierać się we wnętrzu Pool’a i nie może przekraczać granicy Pool’a.

Przepływ komunikatu może przekraczać granicę Pool’a by pokazać interakcje, która istnieje

pomiędzy oddzielnymi wewnętrznymi procesami biznesowymi. W ten sposób, pojedynczy

Diagram Procesu Biznesowego może pokazać wielorakość prywatnych procesów

biznesowych.

29

Różne cele – różne poziomy precyzji

Modelowanie procesów biznesowych zazwyczaj zaczyna się z wyłapaniem aktywności

wysokiego poziomu i potem do zniżenia go do niższego poziomu szczegółowości

w diagramach. Może być wiele różnych poziomów diagramów, w zależności od metodologii

używanej do rozwijania modelowania. Jednakże, BPMN jest samodzielny w jakiejkolwiek

specyfikacji metodologii modelowania procesu.

Rys.4.1.3.7. pokazuje przykład procesu wysokiego poziomu, uchwyconego dla

badania przypadku BPMN, który właściwie jest serią podprocesów z trzema punktami decyzji

w procesie.

30

Rys

. 4.1

.3.7

. Prz

ykła

d pr

oces

u w

ysok

iego

poz

iom

u

31

Rys. 4.3.8. pokazuje szczegóły pierwszego podprocesu z rys. 4.1.3.7.. Ten diagram używa

dwóch Pool : jednego dla klienta i jednego dla przedsiębiorstwa zapewniającego usługę.

Aktywności w przedsiębiorstwie są rozdzielone przez Lane aby pokazać oddziały lub role

odpowiedzialne za ich funkcje (np. Koordynator).

32

Rys

.4.1

.3.8

. Szc

zegó

ły P

roce

su d

la p

rzyk

ładu

wys

okie

go p

ozio

mu

33

Jaka jest wartość modelowania w BPMN?

Członkowie BPMI Working Group reprezentują dużą cześć społeczności biznesowego

modelowania procesów i obecnie przyjmują jednomyślnie BPMN jako standard

modelowania biznesowego. Rozwój BPMN jest ważnym krokiem w zredukowaniu

fragmentacji, która istnieje w niezliczonych narzędziach i notacjach do modelowania

biznesowego. BPMI Notation Working Group przynosi z sobą wiedze specjalistyczną

i doświadczenie z wielu znanych notacji i poszukiwała umocnienia najlepszych pomysłów

z tych rozmaitych notacji w jedną standardowa notację. Przykładami innych metodologii lub

notacji mogą być : UML Activity Diagram, UML EDOC Business Processes, IDEF, ebXML

BPSS, Activity-Decision Flow (ADF) Diagram, RosettaNet, LOVeM, and Event-Process Chains

(EPCs). To rozczłonkowanie przeszkadzało w powszechnie przyjętych systemach zarządzania

procesem biznesowym. Świetnie wsparty standard notacji do modelowania zmniejsza

zakłopotanie pomiędzy biznesem a końcowym użytkownikiem IT.

Innym czynnikiem, który napędza rozwój BPMN jest to, że w aspekcie historycznym

biznesowe modele procesów rozwijane przez ludzi biznesu były technicznie oddzielone od

reprezentacji procesu przez systemy stworzone do zaimplementowania i uruchomienia tych

procesów. W ten sposób, istniała potrzeba do manualnego tłumaczenia oryginalnych modeli

procesów biznesowych do wykonywania modeli. Takie tłumaczenia podlegają błędom

i powodują trudności dla właścicieli procesów w zrozumieniu ewolucji i osiągów procesów,

które rozwinęli.

Mapowanie diagramu BPMN do BPEL4WS

By pomóc złagodzić techniczną lukę modelowania, kluczowym celem w staraniach, by rozwinąć

BPMN było stworzenie „pomostu” od biznesowo z orientowanej notacji do ukierunkowanej na

IT, wykonywalnych języków które implementują proces wewnątrz systemu zarządzania

procesem biznesowym. Graficzne obiekty BPMN, wspomagane przez bogatą paletę atrybutów,

zostały zmapowane do Business Process Execution Language for Web Services

(BPEL4WS v1.1), defacto standard dla wykonania procesu. Rys. 4.1.3.9. dostarcza przykładu

części procesu biznesowego i zaznacza mapowanie do wykonywalnych elementów BPEL4WS.

34

Rys. 4.1.3.9. BPD z adnotacjami, aby pokazać mapowanie do BPEL4WS

Z jednej strony kompletna lista symboli BPMN to 38 symboli obrazujących typowe

zdarzenia biznesowe dające się odwzorować za pomocą BPEL4WS, modelować zaś można

już za pomocą sześciu podstawowych, które pozwalają na zbudowanie pełnego modelu

procesów biznesowych. Pozostałe symbole służą do dodatkowego definiowania zdarzeń

koniecznych z punktu widzenia inżynierii oprogramowania. Dlatego np. model wykonany za

pomocą podstawowego zestawu symboli przez analityka da się łatwo uzupełnić jako

kontynuacja projektu o brakujące elementy w celu wygenerowania kodu dla BPEL. ten zaś

być może będzie standardem służących do generowania kodu aplikacji jak dawne systemu

Typu CASE.

35

Rys. 4.1.3.10. Droga łącząca strategów z programistami [Źródło: strony Business Process Management Initiative (bpmi.org)]

36

CZĘŚĆ V

PRZYKŁADOWE APLIKACJE

DO MODELOWANIA

37

Modelowanie trudno sobie obecnie wyobrazić bez pomocy narzędzi informatycznych.

Najprostsze z nich umożliwiają jedynie stworzenie wykresu procesu, wykreowanie

diagramów i nadanie im odpowiedniego opisu. Programy te znajdują zastosowanie przy

prostych przedsięwzięciach, w których wystarczy jedynie możliwość szybkiego zobrazowania

procesu. Bardziej zaawansowane narzędzia oprócz tworzenia modeli umożliwiają ich

gromadzenie w bazie danych, dają również możliwość tworzenia modelu przez wielu

użytkowników w ramach jednego przedsięwzięcia. Umożliwiają również zaawansowaną

analizę procesów i symulacje ich przebiegu.

Dla przykładu zostaną przedstawione: ARIS firmy IDS Scheer AG, Corporate

Modeler firmy Casewise oraz narzędzia z firmy KBSI.

ARIS

ARIS (Architecture of Integrated Information Systems – architektura zintegrowanych

systemów informacyjnych) jest narzędziem powstałym na bazie teorii opisu i reorganizacji

procesów stworzonej przez prof. Augusta Wilhelma Scheera z Uniwersytetu Saarbrucken.

Podstawy metodologii prof. Scheer zawarł w książce Architektur Intergrieter

Inforamtionssysteme, wydanej w 1991 roku. Ewoluujący przez lata ARIS w obecnej postaci

jest rozbudowanym narzędziem służącym tworzeniu procesów, ich analizie, doskonaleniu

i reorganizacji. Podstawowa funkcjonalność narzędzi ARIS to opisywanie danych procesu,

funkcji, organizacji za pomocą modeli, ich analiza pod kątem czasu i kosztów oraz

wspomaganie rozwiązywania problemów w zakresie rekonstrukcji procesów, wyboru

i wdrożenia systemów informatycznych, rozwoju tych systemów, opisu metod przetwarzania

danych, zarządzania przepływem pracy. Wraz z rozwojem pakietu uzupełniony został on

o wyspecjalizowane aplikacje, takie jak system służący wspomaganiu zarządzania jakością

czy narzędzie wspomagające analizę opartą o metodę Balanced Scorecard.

Produkty oferowane przez IDS-Scheer to pakiet narzędzi składający się z wielu

wyspecjalizowanych aplikacji. Najprostszy produkt – ARIS Easy Design umożliwia

tworzenie modeli procesów i zarządzenie bazą danych, użytkownikami, modelami

i obiektami. Podstawowe narzędzie pakietu - ARIS Toolset – oprócz funkcji zawartych

w programie Easy Design umożliwia również kształtowanie metodyki modelowania zgodnie

38

z własnymi potrzebami, zarządzanie identyfikacją użytkowników podczas modelowania,

konsolidowanie zawartości bazy danych, automatyczne generowanie modeli, budowanie

wariantów modeli, analizy procesów, animacje modeli procesów, kształtowanie raportów

i analiz na własne potrzeby projektowe.

Kolejny produkt – ARIS ABC – umożliwia rozbudowaną analizę kosztów za pomocą

metody ABC (Activity-Based Costing). Wspiera również czynności związane z kontrolingiem

kosztów procesów. Narzędzie to umożliwia analizę, symulację i optymalizację procesów pod

względem związanych z nim kosztów, ułatwia również porównywanie różnych wariantów

procesu. Kolejną z cech produktu jest możliwość współpracy z systemem kontroli kosztów

istniejącym w programie SAP R/3.

ARIS Simulation umożliwia przeprowadzanie symulacji procesu. Dzięki temu określić

można, jak wymodelowany proces zachowa się w praktyce, określić koszty i czas wykonania

procesu i poszczególnych działań. Dowiedzieć się można, jakie działania zużywają najwięcej

kosztów i czasu. Możliwe staje się określenie wykorzystania i efektywność pracowników.

Symulacja umożliwia też określenie wąskich gardeł procesu, czyli stanowisk pracy

ograniczających swoją zbyt niską wydajnością pozostałe stanowiska pracy. W wyniku

symulacji oszacować można dynamiczny czas oczekiwania (dynamic wait time), który określa

przestoje powstałe w czasie wykonywania procesu. Zakres i wiarygodność uzyskanych

informacji zależny jest od ilości i jakości danych wejściowych wprowadzonych do modelu

procesu.

Innym rozwiązaniem oferowanym przez firmę IDS-Scheer jest ARIS QMS. System

ten ma formę portalu intranetowego, a jego zadaniem jest wspomaganie systemu zarządzania

jakością (Quality Management System) i tworzenie dokumentacji tego systemu za pomocą

map procesów. Dostęp do bazy dokumentów możliwy jest poprzez standartowe przeglądarki

stron WWW. Wprowadzenie systemu ARIS QMS ułatwić może tworzenie systemu, gdyż

umożliwia łatwy dostęp do dokumentacji każdemu pracownikowi firmy, zmniejszając

zarazem koszty tworzenia dokumentacji i wprowadzenia systemu zarządzania jakością.

Pakiet programów ARIS jest kompleksowym narzędziem służącym mapowaniu

i reorganizacji procesów. Rozszerza tradycyjne obszary zainteresowania tego typu pakietów

o zagadnienia związane z zarządzaniem jakością czy wspomaganiem handlu elektronicznego.

Duża baza modeli referencyjnych umożliwia tworzenie nowych procesów w oparciu o już

istniejące wzorce. Pakiet ten z powodzeniem może być stosowany w przedsięwzięciach

z zakresu reorganizacji procesów, wprowadzania norm zarządzania jakością czy wdrażania

39

zintegrowanych systemów informatycznych (szczególnie w przypadku wdrażania systemu

SAP R/3).

Corporate Modeler

Corporate Modeler jest produktem działającej na rynku od 1989 roku brytyjskiej firmy

Casewise. Program ten zbudowany jest z modułów korzystających ze wspólnej bazy danych

(repozytorium), w której zgromadzone są występujące w modelu diagramy, obiekty i ich

atrybuty. Najważniejsze moduły to:

• Hierarchy Modeler – umożliwia zobrazowanie statycznych zależności pomiędzy

procesami, jednostkami organizacyjnymi, pracownikami, technologiami

informatycznymi,

• Process Dynamic Modeler – umożliwia ukazanie procesów w sposób dynamiczny,

wiąże działania przebiegające w ramach procesu z jednostkami organizacyjnymi

i lokalizacjami, w których są wykonywane, umożliwia również przeprowadzenie

symulacji,

• Data Flow Modeler – umożliwia ukazanie przepływu informacji w organizacji za

pomocą diagramów DFD (Data Flow Diagram),

• Entity Modeler – umożliwia zaprojektowanie struktury systemów baz danych,

• Generic Modeler- umożliwia przedstawienie danych z repozytorium w formie

diagramu o formie graficznej określonej przez użytkownika,

• Repository Explorer – umożliwia łatwy dostęp do danych o diagramach, modelach

i obiektach zapisanych w bazie danych, integrując zarazem pozostałe aplikacje

wchodzące w skład pakietu.

Proces w Corporate Modelerze ukazany jest jako ciąg czynności zainicjowany wydarzeniem

i kończący się określonym rezultatem. W interesujący sposób rozwiązane jest

przyporządkowanie czynności do miejsc ich wykonywania – jednostki organizacyjne ukazane

są jako prostokątne pola, na których umieszczane są czynności. Dla jednostek

organizacyjnych określić można koszt, jaki pochłania ich funkcjonowanie w jednostce czasu,

podobnie koszt określić można dla poszczególnych czynności.

Dane o procesie zapisane w repozytorium mogą być za pomocą Generic Modelera

ukazane w dowolnej formie, na przykład proces ukazany może być jako diagram EPC,

zgodny z wymogami Sapa

40

Pakiet Corporate Modeler staje się coraz bardziej kompleksowym narzędziem

wspomagającym mapowanie i reorganizacje procesów, wdrażanie systemów informatycznych

i norm ISO. Na szczególną uwagę zasługuje stopień integracji modułów wchodzących

w skład pakietu oraz udane potraktowanie zagadnienia symulacji i wprowadzania danych

potrzebnych do jej przeprowadzenia.

Narzędzia firmy KBSI

Jednym z pakietów oprogramowania, które wspomaga modelowanie procesów są narzędzia

tworzone przez amerykańską firmę KBSI (Knowledge Based Systems Inc.). W skład pakietu

oferowanego przez KBSI wchodzą następujące produkty:

• AI0 WIN – program ten umożliwia modelowanie procesów zgodnie z normą IDEF0,

• SmartER – program wspomagający modelowanie systemów informatycznych i baz

danych,

• ProSim – umożliwia modelowanie i symulację procesów zgodnie z norma IDEF3,

• ProCap – wspomaga mapowanie procesów w oparciu o normę IDEF3,

• SmartCost – umożliwia kalkulację i analizę kosztów,

• ProjectLink – wspomaga zarządzanie projektami i ich symulację.

Programy wymienione powyżej mogą być używane oddzielnie, mogą również pracować

wspólnie udostępniając zawarte w nich dane innym programom wchodzącym w skład

pakietu.

AI0 WIN jest programem umożliwiającym mapowanie procesów zgodnie z normą

IDEF0. Modele tworzone w ramach projektu zgrupowane są w repozytoriach (repositories).

Zarządzanie i przeglądanie modeli w ramach repozytorium umożliwia model browser, który

ukazuje modele, jak również hierarchię czynności w nich zawartych. Z poziomu model

browsera utworzyć można czynności podstawowe, oznaczone symbolem A0, jak również

czynności podrzędne. Następnie do każdej czynności przypisać można obrazujący ją diagram,

ukazujący wejścia, wyjścia, mechanizmy sterowania i zasoby potrzebne do jej wykonania.

Dla czynności określić można atrybuty, jak koszty i czas potrzebny do ich wykonania, istnieje

również możliwość zdefiniowania dowolnego zestawu atrybutów. Czynność nadrzędną

przedstawić można jako proces, składający się z czynności podrzędnych. Diagramy ukazują

zależności pomiędzy czynnościami podrzędnymi – wyjścia jednych czynności mogą być dla

innych czynności ich wejściami, zasobami lub mechanizmami sterowania.

41

Wyjścia, wejścia, mechanizmy sterowania i zasoby każdej czynności mogą być też

przedstawione w postaci tabeli – tzw. diagramu A/C. Używając matrycy ABC (ABC matrix)

wprowadzić można zależności kosztowe pomiędzy poszczególnymi czynnościami. Zależności

te wyeksportowane do programu EasyABC służą do rachunku kosztów metodą ABC.

Na podobnej zasadzie do programu AI0 WIN zbudowany jest program ProCap,

umożliwiający tworzenie modelów procesów w oparciu o normę IDEF3, oraz program

ProSim, który również opierając się o normę IDEF3 umożliwia przygotowanie modelu do

symulacji oraz analizę kosztów. Za pomocą programu ProSim określić można wykorzystanie

czasu poprzez poszczególne obiekty zaangażowane w działania, jak również tworzone przez

nie koszty. Czasy i koszty określone mogą być za pomocą stałej liczby, istnieje również

możliwość przedstawienia ich za pomocą różnych typów funkcji.

Pakiet narzędzi firmy KBSI wydaje się odbiegać od wiodących na rynku programów

pod względem stopnia zintegrowania poszczególnych aplikacji, zakresu obejmowanych

zagadnień, dogodności pracy wielu użytkowników w ramach jednego projektu czy wygody

obsługi. Jednak niewątpliwą zaletą pakietu jest silne wsparcie teoretyczne ze strony norm

IDEF, które zawierają nie tylko sposoby opisu procesów, ale też metody ułatwiające ich

reorganizację i pozyskiwanie danych.

42

CZĘŚĆ VI

ZAKOŃCZENIE

43

Na końcu rozważań chcielibyśmy spróbować odpowiedzieć na jedno pytanie: Czy

warto budować modele? Myślimy, że tak.

Przede wszystkim jest to wgląd w strukturę przedsiębiorstwa i procesy w nim

zachodzące oraz baza do wprowadzania wszelkich zmian. Analiza modelu pozwala dostrzec

wszelkie niedoskonałości i wąskie gardła, które mogą utrudniać działalność przedsiębiorstwa,

czy hamować obieg wiedzy lub informacji. Jako, że model pozostaje bardzo czuły na

wszelkie zmiany, stanowi doskonałe narzędzie kontrolne. Stanowi odzwierciedlenie

zależności zachodzących między poszczególnymi fragmentami biznesu, nie tylko

technicznych, ale również socjalnych. Każdy zatem może dokładnie określić swoje miejsce

w organizacji i przypisaną mu rolę. Te czynniki pozwalają stworzyć lepsze środowisko pracy.

Stanowi również swoiste repozytorium wiedzy o przedsiębiorstwie, może zatem być

wykorzystywany do podejmowania decyzji, alokacji zasobów czy jako narzędzie strategiczne.

Warto również zauważyć, że jako "pamięć" jednostki zapobiega wypływaniu wiedzy ukrytej

wraz z odejściem pracowników.

W dzisiejszych czasach, kiedy tak trudno jest utrzymać pozycję rynkową, firmy

powinny dążyć do zwiększenia własnej efektywności. Czemu nie poprzez efektywność

własnych działań i procesów? Skoro informatyka dostarcza narzędzi umożliwiających

modelowanie, czemu z nich nie korzystać? Nikt nie twierdzi, że jest to łatwe zadanie, ale

skoro stawką jest przetrwanie czy poprawa obecnej sytuacji, to może warto zadać sobie trud?

44

CZĘŚĆ VII

BIBLIOGRAFIA

45

1. Craig Dewalt, Business Process Modeling With UML, Johns Hopkins University 1997

2. http://www.it-portal.pl

3. http://www.bpmn.org

4. http://www.man.torun.pl/archives/modelowanie-biznesowe.html

5. http://www.logistica.pl

6. http://pl.wikipedia.org