Aby zacytować tę publikację: Sitek T., Gola M., Klasyfikacja metod modelowania procesów biznesowych, [w:] Wachowicz J. (red.), Problemy wykorzystania informatyki w zarządzaniu, Wydawnictwo Politechniki Gdańskiej, Gdańsk 2005, s. 7-20. KLASYFIKACJA METOD MODELOWANIA PROCESÓW BIZNESOWYCH Marcin GOLA Tomasz SITEK W artykule podjęto próbę klasyfikacji metod modelowania procesów biznesowych uwzględniając złożoność metody, cel modelowania oraz zakres modelowanych aspektów organizacji. Zawarto także opis popularnych diagramów używanych w metodologiach modelowania procesów bitznesowych. Wyjaśniono przy tym podstawowe pojęcia związane z modelowaniem procesów biznesowych w kontekście inżynierii oprogramowania oraz zarzadzania procesami biznesowymi. 1 WSTĘP Technologie informatyczne stają się coraz bardziej wydajne. Problemem, jaki stoi przed informatyką, jest jak najlepsze dostosowanie ich do rozwiązywania problemów użytkowników. W dziedzinie biznesu problem ten występuje w coraz trudniejszym dostosowaniu się informatyki do zmieniającego się przedsiębiorstwa. Procesy globalizacji powodują większą konkurencyjność rynków, a co za tym idzie, presję na obniżanie kosztów w przedsiębiorstwie poprzez gruntowną reorganizację procesów firmy oraz ich automatyzacje przy wykorzystaniu technologii informatycznych. Nowe produkty, a także współpraca pomiędzy firmami bardzo często są zależne od sprawnych systemów informatycznych. Informatyka stara się coraz lepiej dostosować do tych trendów. Nowe metodologie i narzędzia inżynierii oprogramowania coraz bardziej skracają cykl wytwórczy oprogramowania. Coraz częściej tworzy się wysokopoziomowe narzędzia pozwalające na budowę systemów lub aplikacji bez pomocy informatyków. Warunkiem ich skuteczności jest jednak dobrze zdefiniowany problem informatyczny. Takim coraz lepiej zdefiniowanym problemem informatycznym stają się także systemy przepływu roboczego (workflow) oparte na opisie procesu biznesowego. Trendom tym sprzyjają nowe metodologie nauki zarządzania związane z zarządzaniem jakością oraz reinżynierią procesów. Aby lepiej kontrolować oraz optymalizować procesy gospodarcze, menedżerowie i specjaliści do spraw jakości dokładnie dokumentują ich przebieg oraz zbierają ich dokładne statystyki. Tak udokumentowane i dobrze zdefiniowane procesy są doskonałą informacją do tworzenia systemów informatycznych.
Autorzy przeprowadzili badania wybranych popularnych metodologii modelowania procesów biznesowych. Badania te doprowadziły do szeregu analiz porównawczych, niniejszy artykuł można traktować jako raport podsumowujący je. 2 PROCES BIZNESOWY DEFINICJA I CELE MODELOWANIA 2.1 Wertykalne i horyzontalne spojrzenie na organizację Na początku lat dziewięćdziesiątych odkryto już, że problemy, których doświadczają organizacje nie są związane z zadaniami, lecz z procesami. Odkryto, iż w firmach nie ma osób, które byłyby w stanie zawsze przekazać klientom informację o stanie procesu, którego rezultatu oczekują. Magazyn minimalizuje rotacje zapasów, ekspedycja skupia się na kosztach wysyłki, wydział kredytów skupia się na tym czy standardy kredytowania są zachowane. Nikt natomiast nie zastanawia się czy połączone zadania proces, daje rezultat oczekiwany przez klienta. Nowe techniki zarządzania Total Quality Management oraz Reengineering przyniosły znaczną poprawę wyników działania przedsiębiorstw, gdyż przedmiotem ich zainteresowania były nie zadania, lecz właśnie procesy. Jeden z twórców reengineeringu Michael Hammer podaje cztery wyróżniki organizacji zorientowanej horyzontalnie (systemowo, procesowo) [8 s. 21]. 1. Procesy są rozpoznawane i nazywane. 2. Każdy pracownik jest świadomy wszystkich procesów w firmie i ich znaczenia dla organizacji. Wszyscy pracownicy powinni zdawać sobie sprawę z wejść i wyjść każdego procesu i ich wzajemnych zależności. 3. Procesy są mierzone. Organizacja posiada miernik każdego procesu, który pozwala określić czas procesu, jego dokładność i koszt. 4. Procesy są zarządzane. Konieczne jest ciągłe szukanie sposobów na ulepszenie procesu, poprawianie jego mierzonych parametrów. Podejście horyzontalne związane jest z przetwarzaniem dużych ilości informacji w przedsiębiorstwie. Rozwój organizacji horyzontalnych nie byłby możliwy bez rozwoju technologii informatycznych. 2.2 Definicja procesu biznesowego Najprostsza definicja procesu spotykana w literaturze mówi, iż proces to zbiór logicznie powiązanych czynności, wykonywanych w celu osiągnięcia wspólnego celu [11 s. 38]. Dokładniejszą definicje przedstawia Hammer: Proces to powiązana grupa zadań, których wspólny rezultat stanowi wartość dla klienta [8 s. 15]. Zaznacza przy tym, że najważniejszym słowem w tej definicji jest klient. W innym miejscu Hammer dodaje: Możemy myśleć o procesie, że powoduje przekształcenia, otrzymując wkłady (inputs) i przetwarzając je na produkty (outputs) wyższej wartości [8 s. 18]. Nie wszystkie zbiory czynności mające wspólny cel będą leżały w kręgu zainteresowań analityków. Procesy, na których należy się skupiać są zawsze związane z przewagą strategiczną przedsiębiorstwa. Jeśli przewaga tkwi w produktach, to zapewne modelowane i analizowane będą procesy związane z przygotowaniem i wprowadzaniem na rynek nowych produktów. Jeśli przewagą strategiczną firmy jest czas realizacji zamówienia to analitycy będą skupiać się na procesach przyjmowania i realizacji zamówień. Procesy związane z przewagą strategiczną przedsiębiorstwa są zawsze głównymi kandydatami do automatyzacji przy pomocy systemów informatycznych.
Wyróżnia się procesy podstawowe (core processes) i procesy pomocnicze. Procesy podstawowe są to procesy, które posiadają interakcję z otoczeniem firmy (zwłaszcza z klientami) oraz są krytyczne dla dostarczania towarów i usług oferowanych przez przedsiębiorstwo. Procesy pomocnicze (wspomagające) są procesami, których odbiorcą jest klient wewnętrzny w przedsiębiorstwie. Procesy wspomagające mogą być również bardzo ważne z punktu widzenia przewagi strategicznej przedsiębiorstwa. Jeśli źródłem przewagi strategicznej są niskie koszty, to niezwykle istotnym jest proces budżetowania. Rummler i Brache wyróżniają także procesy zarządzania. Ich przykładowa lista wygląda następująco [12 s. 77]: Ogólne procesy podstawowe (np. zakładanie nowego biznesu; przygotowanie i wprowadzenie nowego produktu (usługi); produkcja; obsługa pogwarancyjna) Procesy podstawowe specyficzne dla branży (np. załatwianie wniosku kredytowego bankowość, rozpatrzenie wniosku o odszkodowanie ubezpieczenia, przydzielanie dotacji-agendy rządowe, przyjmowanie rezerwacji hotele) Ogólne procesy wspierające (np. formalne planowanie strategiczne i taktyczne, budżetowanie, rekrutacja, szkolenie) Ogólne procesy zarządzania (np. planowanie strategiczne i taktyczne, ustalanie celów, alokacja zasobów) Procesy można rozpatrywać na różnych poziomach abstrakcji. Wszystkie przedsiębiorstwa branży motoryzacyjnej można rozpatrywać jako uczestników jednego procesu, który przekształca czynniki produkcji takie jak stal i chemikalia na samochody oferowane klientom. Procesy można analizować także na poziomie jednego przedsiębiorstwa, np. produkującego opony. W takim pojedynczym przedsiębiorstwie można wyróżnić zazwyczaj około kilkunastu procesów pomocniczych i podstawowych [8 s. 21]. Najpełniejszą listę elementów dobrze zdefiniowanego procesu przedstawiają Eriksson i Penker [5 s. 106]. Przedstawiają oni listę pytań, na które trzeba odpowiedzieć, aby dobrze zdefiniować proces. Przykładowe z nich brzmią: Które czynności są konieczne?, Kiedy są te czynności wykonywane i w jakim porządku?, Dlaczego dane czynności są wykonywane; jaki jest cel procesu?, W jaki sposób poszczególne czynności są wykonywane?. 2.3 Zalety modelowania procesów biznesowych W literaturze można znaleźć wiele powodów, dla których warto formalnie modelować procesy biznesowe. W modelowaniu systemów produkcji są to np. [4 s. 116]: podniesienie satysfakcji klienta poprzez identyfikację czynności wpływających na długość cyklu wytwórczego, ustalenie mierników osiągnięć skoncentrowanych na zadowoleniu klienta poprzez określenie czynników wpływających na usatysfakcjonowanie odbiorcy produktu, zmniejszenie ilości braków poprzez określenie źródeł ich powstawania, redukcja kosztów poprzez wykrycie czynności nie dających wartości produktowi, ustalenie przyczyn zaburzeń procesu poprzez wykrycie nieciągłości w przepływie informacji pomiędzy zespołami funkcjonalnymi i redundancji informacji,
podniesienie produktywności dzięki usunięciu wykrytych nieciągłości w realizowanym procesie. Opisywanie procedur organizacyjnych w postaci rysunkowej posiada wiele zalet nad opisywaniem takich procedur samym tekstem. Są to [2 s. 184]: przejrzystość, zachęta do czytania, łatwość zrozumienia, łatwość aktualizacji, przydatność do szkoleń, spójność, łatwość tworzenia, pokazywanie relacji. Procesy w przedsiębiorstwach modeluje się jednak zazwyczaj w kontekście wdrażania systemów zarządzania jakością lub w kontekście budowy systemów informatycznych, na tego rodzaju zastosowaniach autorzy skupili się przeprowadzając badania wybranych metodologii. 3 MODELOWANIE PROCESÓW BIZNESOWYCH W INŻYNIERII OPROGRAMOWANIA Leffinwell i Widrig wymieniają trzy kategorie aplikacji programowych [10 s. 20]: systemy informatyczne i inne aplikacje tworzone do użytku wewnętrznego firmy (np. system płacowy) zwane w skrócie IS/IT (information systems/information technology) oprogramowanie na półkę sprzedawane jako produkt komercyjny (np. edytor tekstu) zwane w skrócie ISV (independent software vendors) systemy wbudowane (np. oprogramowanie telefonu komórkowego). Autorzy ci twierdzą, iż do w cyklu rozwojowym pierwszej z wymienionych kategorii konieczny jest pierwszy etap zwany przez nich modelowaniem przedsiębiorstwa (business modelling). W budowaniu systemów IS/IT jest to technika pozwalając uzyskać odpowiedź na pytania [10 s. 58]: Po co w ogóle budować system? Gdzie on się powinien znajdować? Jako możemy określić czy zakładana funkcjonalność systemu jest optymalna? Kiedy powinniśmy stosować kroki manualnego przetwarzania lub obejścia systemu? Kiedy powinniśmy rozważyć restrukturyzację samego przedsiębiorstwa w celu rozwiązania problemu? 4 ARCHITEKTURA, METODA, NOTACJA, NARZĘDZIE ROZRÓŻNIENIE POJĘĆ Przeglądając literaturę dotyczącą modelowania procesów biznesowych bardzo często trudno jest wyróżnić granice pomiędzy pojęciami: architektura, metoda, narzędzie i notacja. Różni producenci czy konsorcja mają do zaoferowania inny element modelowania procesów biznesowych. Podstawowym elementem z wymienionych powyżej pojęć jest notacja. Notacja jest to zbiór dopuszczalnych elementów graficznych występujących na diagramach procesów biznesowych wraz z regułami łącznia tych elementów. Istnieją bardzo dokładnie zdefiniowane notacje jak np. notacja BPMN. Inne notacje nie mają dokładnej definicji, a w zasadzie są notacjami zdefiniowanymi przez narzędzie. Przykładem tego może być obrazkowa notacja MS Visio. Istnieją notacje, które są bardzo dokładnie opisane i bardzo ściśle opisana jest ich gramatyka. Przykładem takiej notacji może być notacja IDEF0, będąca niegdyś wykorzystywana do celów wojskowych. Zaletą tego podejścia jest precyzja informacji, jaką uzyskujemy dzięki stosowaniu dyscypliny w opisie poszczególnych procesów biznesowych. Wadą ściśle
zdefiniowanych notacji jest długi czas ich uczenia a także niemożliwość użycia jej w środowiskach gdzie modelowanie procesów może się wiązać z zaangażowaniem ludzi bez przygotowania informatycznego. Narzędzie jest programem komputerowym służącym do tworzenia diagramu procesu biznesowego przy pomocy edytora graficznego mającego zaimplementowane ograniczanie wynikające z gramatyki używanej notacji. Do modelowania procesów biznesowym używa się zazwyczaj narzędzi określanych jako CASE (Computer Aided Software Engineering) lub jako CABE (Computer Aided Business Engineering). Pierwszy typ narzędzi zorientowany jest na użytkowników informatyków, podczas gdy drugi typ zorientowany jest na specjalistów ds. zarządzania procesami. Narzędzia CASE oparte są zazwyczaj na bardzo sformalizowanej notacji, podczas gdy narzędzia CABE opierają się raczej na bardzo luźno sformalizowanych notacjach i skupiają się na funkcjonalnościach związanych z symulacją procesów oraz generowaniem raportów ze statystykami procesów. Jedno narzędzie może pozwalać na użycie wielu notacji. Metoda czy inaczej metodologia jest elementem, który nie zawsze jest oferowany razem z notacją lub narzędziem. Metoda jest algorytmem, który mówi, w jaki sposób podejść do modelowania tego, co się dzieje w przedsiębiorstwie. Specyfikuje, od czego zacząć i jakich diagramów kolejno używać, aby stworzyć precyzyjny model przedsiębiorstwa. Bardzo często z metodą wiążą się narzędzia producenta, który daną metodę wymyślił. Przykładem tego może być metoda CASE firmy Oracle, mogąca być wykorzystana w zasadzie jedynie z narzędziem Oracle Designer. Metoda może być jednak nie związana z narzędziem. Metodę modelowania procesów biznesowych RUP można by użyć w większości edytorów UML. Rzadko spotyka się metodologie nie związane ani z narzędziem ani z notacją. Do tego grona kandyduje metodologia ARIS. Trudno jednak powiedzieć, że ARIS oferuje bardzo precyzyjny algorytm modelowania procesów biznesowych. Sami producenci ARIS twierdzą, że ARIS to coś więcej niż metoda to architektura. Architektura jest koncepcją zbioru modeli całościowo opisujących przedsiębiorstwo. W przypadku architektury może istnieć wiele metod tworzenia poszczególnych modeli występujących w danej architekturze. ARIS jest architekturą zasadniczo niezależną od żadnej notacji. Architekturę opisu procesów biznesowych opartą na notacji UML opisali w swojej książce Eriksson i Penker [5] 5 ZBADANE METODY I NARZĘDZIA Przeprowadzone badania miały na celu sprawdzić możliwości użycia wybranych metodologii modelowania oraz narzędzi z nimi związanych. Wybrano 7 metod, za główne kryterium wyboru uznano ich popularność na rynku oraz oryginalność zapisu (w trakcie badań przebadano większą liczbę metod i narzędzi większość nieuwzględnionych w niniejszym opracowaniu powstała w oparciu o jedną z wybranych siedmiu). W tabeli 1 poniżej zestawiono podstawowe informacje na temat każdej z nich. 1 Nazwa metody: Rational Unified Process - Business Modeling Twórcy metody: IBM/Rational Software Corporation Badane narzędzie: Rational Rose Enterprise Edition Release Version: 2003.06.00.436.000
2 3 Nazwa metody: Eriksson-Penker Unified Modeling Language Business Extensions Twórcy metody: Hans Erik Eriksson, Magnus Penker, Open Training Company Badane narzędzie: Enterprise Architect 3.60, Sparx Systems Pty Ltd. 4 5 Nazwa metody: Microsoft Visio Stencils Twórcy metody: National Institute of Standards and Technology, USA; Action Technologies Badane narzędzie: Microsoft Visio Professional 2002 SR-1 Nazwa metody igrafx Process Twórcy metody: Corel Corporation Badane narzędzie: igrafx Process 2005 6 Nazwa metody Oracle Case Method Twórcy metody: Oracle Corporation Badane narzędzie: RDBMS Oracle 9i, Oracle 9i Designer 9.0.2.9 7 Nazwa metody ARIS (Architecture of Integrated Information Systems) Twórcy metody: IDS Prof. Scheer GmbH Badane narzędzie: ARIS Toolset version 6.2.350332.71929, IDS Scheer AG Nazwa metody Business Process Modeling Notation Twórcy metody: Business Process Management Initiative Badane narzędzie: System Architect 10, Popkin Software Tabela 1 Zbadane metody i związane z nimi narzędzia modelowania procesów biznesowych Należy zwrócić uwagę, iż celem niniejszego opracowania nie jest szczegółowa charakterystyka wybranych do badań metodologii, stąd czytelnika zainteresowanego opisami każdej z nich trzeba odesłać do innych źródeł (w szczególności: do stron internetowych producentów, gdzie można znaleźć niejednokrotnie sporo ciekawych opracowań). W kolejnych rozdziałach zaprezentowane zostaną rezultaty analiz porównawczych tychże metod ze względu na możliwości modelowania różnych kategorii procesów oraz ze względu na wsparcie dla różnych podejść do modelowania biznesu (od prostych rysunków po złożone modele wszystkich perspektyw biznesowych).
6 DIAGRAMY PROCESÓW KLASYFIKACJA 6.1 Wprowadzenie Kompleksowy model architektury systemu informacyjnego przedsiębiorstwa bardzo trafnie opisał w 1987 roku John A. Zachman. Rysunek 1 przedstawia jego schemat. Rysunek 1 Ramy modelowania systemów informacyjnych według Zachamana Źródło: [6, s. 2] Bardzo często to, co nazywamy potocznie modelowaniem procesów biznesowych znajduje się pomiędzy perspektywami określonymi przez Zachmana jako SCOPE i SYSTEM MODEL. W praktyce jednak typowe diagramy modelowania procesów biznesowych znajdują się tylko w abstrakcjach What, How i Who perspektywy BUSINESS MODEL, czyli odpowiadają na pytania, kto wykonuje proces, co jest przetwarzane w procesie i jak jest to robione. W zasadzie każdy typowy diagram spotykany w metodologiach i notacjach procesów biznesowych można zaliczyć do jednej z wymienionych poniżej grup: diagramy hierarchii procesów i czynności, diagramy zależności między procesami, diagramy struktury procesu, diagramy przepływu czynności w procesie. W dalszej części rozdziału diagramy te zostaną scharakteryzowane. Po charakterystyce tej zostaną przedstawione wyniki analizy badanych narzędzi pod kątem możliwości modelowania przy ich pomocy każdego rodzaju diagramów.
6.2 Diagramy hierarchii procesów i czynności Przedstawienie na diagramie hierarchii procesów i czynności jest bardzo łatwym, a zarazem bardzo użytecznym sposobem przedstawienia na rysunku tego, co dzieje się w przedsiębiorstwie. Najwyższym poziomem drzewa procesów i czynności może być cel firmy. Na najniższym poziomie drzewa można umieścić atomowe czynności nie dające rozbić się na podczynności. Diagramy te występują w wielu notacjach. Zazwyczaj pokazują one kody poszczególnych czynności będących węzłami danego drzewa. Metoda CASE firmy Oracle używa tego typu diagramy do dokładnego określenia granic implementowanego systemu. Dzięki wylistowaniu wszystkich czynności przedsiębiorstwa na różnych stopniach abstrakcji, analityk może bardzo precyzyjnie określić, które z czynności będą lub nie będą wspomagane przez systemy informatyczne. 6.3 Diagramy zależności między procesami Diagramy hierarchii procesów i czynności nie zawierają informacji, jakie są interfejsy pomiędzy procesami, tzn. które procesy współpracują ze sobą. Do przedstawienia tego rodzaju informacji służą diagramy zależności między procesami, określane często jako mapy procesów. Diagramy zależności pomiędzy procesami nie mają na celu pokazania sekwencji czynności. Ich głównym zadaniem jest pokazanie, że wyjścia jednego procesu są jednocześnie wejściami innego procesu. Tego typu diagramy, bardzo często używane w metodologiach modelowania procesów biznesowych, pozwalają głównie na zrozumienie przepływu informacji pomiędzy procesami przedsiębiorstwa. 6.4 Diagramy struktury procesu Innym typem diagramu często używanym w modelowaniu procesów biznesowych jest diagram struktury procesu. Celem tworzenia tego typu diagramów jest przedstawienie informacji o procesie bez podawania informacji jak proces ten jest realizowany. Występuje tu podejście czarnej skrzynki. Typowe informacje zawarte na diagramie struktury procesu to: wejścia procesu (wiedza, informacje, materiały fizyczne) wyjścia procesu (wiedza, informacje, materiały fizyczne) cele procesu (jednostki miary oraz ich wartości) kontroler procesu (kto jest odpowiedzialny za wyniki procesu) 6.5 Diagramy przepływu czynności w procesie Tworzenie diagramu przepływu czynności w procesie jest bardzo często synonimem modelowania procesów biznesowych. Notacja Business Process Modeling Notation zawiera jedynie ten rodzaj diagramu. Diagram przepływu czynności pokazuje, w jaki sposób osiągane zostają cele danego procesu, tzn., w jaki sposób wejścia procesu zostają przekształcone na wyjścia. Diagramy przepływu czynności wywodzą się od diagramów algorytmów, dlatego ich głównymi elementami są zazwyczaj punkty decyzyjne oraz operacje czy czynności. Typowe dla tych diagramów jest także pokazanie torów symbolizujących wykonawcę czynności. Inne elementy mogące występować na tego typu diagramach to zdarzenia oraz obiekty, których przepływ może również być zarysowany na diagramie przepływu czynności.
Diagramy takie są bardzo dobrze modelowane przy pomocy notacji UML, a zwłaszcza po rozszerzeniach dodanych w UML 2.0. 6.6 Możliwości modelowania różnych diagramów badanymi narzędziami W trakcie badania poszczególnych narzędzi okazało się, że opisane powyżej rodzaje diagramów są wspierane przez różne narzędzia. W poniższej tabeli 2 pokazano wyniki tych analiz, jest to jednocześnie ich pewna klasyfikacja. Szare pola oznaczają możliwość stworzenia diagramu danej kategorii przy użyciu danej aplikacji. Pola białe - dane narzędzie nie pozwala na tworzenie wybranego diagramu. Diagram Hierarchia procesów i czynności Zależności między procesami Struktura procesu Przepływ czynności w procesie Narzędzie igrafx Process Microsoft Visio Oracle Designer Rational Rose Enterprise Architect System Architect ARIS Toolset Tabela 2 Możliwości generowania różnych typów diagramów poszczególnymi narzędziami Źródło: opracowanie własne Analiza wyraźnie wykazała, do jakich celów poszczególne narzędzia zostały zaprojektowane. I tak możemy zauważyć, iż produkt firmy Microsoft jest bardzo wszechstronny i możemy go wykorzystać do budowy różnych modeli procesów. igrafx z kolei to program nadający się doskonale do modelowania przepływów czynności w czasie, aczkolwiek to jedyna jego funkcjonalność (w kontekście tej analizy porównawczej). W następnym rozdziale przedstawiono własny podział podejść do modelowania biznesu. Wyróżnione podejścia scharakteryzowano pokrótce w kolejnych podrozdziałach, w ostatnim zaś zawarto wyniki badania odpowiadające na pytanie o możliwości zastosowania konkretnej metodologii przy każdym z tych podejść. 7 PODEJŚCIA W TWORZENIU GRAFICZNYCH MODELI BIZNESU 7.1 Rysunkowe proste schematy Najprostszym podejściem w modelowaniu procesów biznesowych jest tworzenie rysunków, których głównym zadaniem jest proste, schematyczne zobrazowanie przebiegu czynności lub struktur organizacyjnych w firmie. Bardzo często do tego podejścia używane są graficzne edytory procesów typu Microsoft Visio. Modelowanie w podejściu rysunkowym nie ma na celu bardzo precyzyjnego opisu procesu, lecz raczej schematyczne pokazanie tego, co dzieje się w firmie. Notacje tego typu diagramów nie są zazwyczaj formalnie zdefiniowane i od wykonujących te diagramy nie wymaga się ich znajomości. Notacja jest w tych wypadkach narzucana raczej przez samo narzędzie. Podejście to nie wiąże się zazwyczaj z żadną metodologią modelowania, choć stworzenie tego typu schematów może być pierwszym krokiem, aby stworzyć bardziej dokładne i precyzyjne diagramy. Jest to raczej podejście używane w narzędziach typu CABE niż w narzędziach typu CASE.
7.2 Symulacyjne symulacja i dokładne modelowanie przepływu czynności Podejście symulacyjne pierwotnie było używane w narzędziach CABE (np. igrafx), choć obecnie jest już w dostępne w narzędziach CASE mających rozbudowane opcje modelowania procesów biznesowych (Oracle Designer, narzędzia BPMN). Podejście symulacyjne do modelowania procesów biznesowych skupia się na tworzeniu diagramów przepływu czynności w procesie. W wielu przypadkach modelowanie procesów biznesowych jest wręcz synonimem tworzenia diagramów przepływu czynności w procesie. W podejściu tym, w przeciwieństwie do podejścia rysunkowego, konieczne jest bardzo dokładne odzwierciedlenie na diagramie logiki przepływu czynności w procesie. Istotne w tym przypadku jest bardzo dokładnie modelowanie przy pomocy bramek logicznych. Osoba modelująca musi wciąż zadawać sobie pytania, co jest warunkiem koniecznym a co wystarczającym, aby rozpoczęła się kolejna czynność. Podejście to ma obecnie dwa główne zastosowania. Pierwszym zastosowaniem tego podejścia jest zarządzanie procesem. Dzięki dokładnemu odzwierciedleniu przepływu czynności na diagramie, możliwe jest zebranie statystyk procesu oraz modyfikacja procesu, dzięki której można poprawić jego efektywność (przykład symulacji jest opisany w rozdziale 6). Drugim zastosowaniem takich precyzyjnych diagramów jest tworzenie aplikacji klasy workflow. Zastosowanie to jest szczególnie ważne w przypadku systemów klasy B2B, gdzie przepływ czynności pomiędzy partnerami z różnych przedsiębiorstw musi być bardzo dokładnie sprecyzowany. Cel ten przyświecał twórcom notacji BPMN, którzy poszli nawet o krok dalej i sformalizowali mapowanie elementów graficznych diagramu przepływu czynności do formatu XML. Diagramy tego typu nie posiadają bardzo wyrafinowanej notacji. Często stosowana jest notacja typowa dla diagramów algorytmów. Kolejne wersje narzędzi CASE i CABE używają już jednak notacji BPMN do tego typu diagramów. Notacja BPMN jest konkurencyjna dla notacji diagramu czynności UML 2.0.Standard UML nie jest w obecnie w stanie konkurować z popularnością BMPN. To właśnie na BPMN wzorowali się twórcy rozszerzeń dla diagramu czynności w wersji UML 2.0. 7.3 Analityczno-holistyczne modelowanie wszystkich możliwych perspektyw Istnieją metodologie modelowania procesów biznesowych oferujące holistyczne podejście do modelowania przedsiębiorstwa. Metodologie te nazywa się wręcz architekturami. Podejście te wykracza poza zwykłe modelowanie przepływu czynności. Innymi modelowanymi aspektami przedsiębiorstwa mogą być: struktura organizacyjna, zasoby przedsiębiorstwa, mapa procesów, strategia i cele firmy, wiedza. Podejście analityczno-holistyczne zawiera w sobie także szczegółowe modelowanie procesów. Twórcy architektur procesów biznesowych twierdzą jednak, że samo modelowanie przepływu czynności nie jest wystarczające do poznania pełnego obrazu przedsiębiorstwa. Podejście analityczno holistyczne nie wiąże się zwykle z jakimś określonym typem diagramów czy notacją. Jest to przede wszystkim zbiór wytycznych, co należy modelować. Rysunki 2 i 3 przedstawiają typowy schemat dla podejścia analityczno-
holistycznego. Pod każdą z perspektyw przedstawionych na rysunkach architektur może się kryć szereg typowych i niestandardowych diagramów. Podejście to użyteczne jest, gdy analityk chce zamodelować całkowicie nową dziedzinę. Użycie poszczególnych perspektyw gwarantuje, że nie pominiemy żadnego aspektu modelowanej dziedziny. W przypadkach, gdy interesuje nas jedynie mały wycinek przedsiębiorstwa wygodniej jest zastosować podejście symulacyjne, gdzie skupiamy się jedynie na dynamicznych aspektach jednego procesu. Business Vision View Business Process View Business Structure View Business Behaviour View Rysunek 2 Perspektywy architektury biznesu według Erikssona i Penkera Źródło: [5 s. 90] Rysunek 3 Perspektywy architektury biznesu według metodologii ARIS Źródło: [9 s. 39]
7.4 Inżynieryjne modelowanie tego, co bezpośrednio pomoże w tworzeniu oprogramowania Podejście inżynieryjne było pierwszym podejściem do modelowania procesów biznesowych. Opiera się ono na założeniu, że jest sens modelować tylko to, co może przydać się w tworzeniu oprogramowania. Mogą to być klasy opisujące dziedzinę przedmiotową, które zostaną zamienione na klasy projektu programu, lub też mogą to być czynności, które zostaną zamienione na procedury w systemie informatycznym. Podejście to prezentuje wiele narzędzi CASE oferujących generowanie projektów aplikacji na podstawie diagramów opisujących dziedzinę przedmiotową. W podejściu tym analityk nigdy nie zacznie modelować np. struktury organizacyjnej, jeśli elementy tej struktury organizacyjnej nie wystąpią jako obiekty tworzonego systemu, lecz jedynie maja pomóc analitykowi w zrozumieniu przedsiębiorstwa, dla którego tworzy system. Przykładem tego podejścia może być również modelowanie procesów przedsiębiorstwa przy pomocy diagramów przepływu danych. To podejście wciąż jest stosowane (np. w narzędziu Oracle Designer opisywanym w rozdziale 7), gdyż pozwala na bardzo łatwe i praktyczne przejście z diagramu opisującego dziedzinę przedmiotową do diagramu projektu aplikacji. Innym przykładem stosowania tego podejścia jest używanie edytorów UMLa do modelowania elementów przedsiębiorstwa. Projektanci bardzo często nie traktują modelowania procesów biznesowych jako osobnego etapu w fazie zbierania wymagań. Opisywanie biznesu zaczynają po prostu w momencie tworzenia projektu systemu, gdzie obiekty i klasy ze świata biznesu bardzo szybko stają się obiektami i klasy oprogramowania. Podejście to jest naturalnym podejściem projektanta, który nie zetknął się nigdy z metodologiami modelowania biznesu. W sytuacjach, gdy kompleksowość dziedziny przedmiotowej nie jest duża podejście to może być efektywne. 7.5 Standaryzowane notacja BPMN ukierunkowana na tworzenie systemów zarządzania przepływem procesu Podejście standaryzowane jest wypadkową podejścia inżynieryjnego, symulacyjnego oraz rysunkowego. Standard modelowania procesów biznesowych stworzony przez konsorcjum Business Process Management Initiative zawiera jedynie standard diagramu przepływu czynności w procesie. Jest to podejście bardzo pragmatyczne, gdyż zakłada, że inne perspektywy, występujące w architekturach podejść analityczno-holistycznych, nie mają tak praktycznego znaczenia dla informatyki, że warto byłoby je umieścić pod szyldem standardu modelowania procesów biznesowych. Podejście standaryzowane zakłada rozwój modelowania procesów biznesowych w kierunku systemów zarządzania procesami biznesowymi (BPMS business process managament systems). Oznacza to rozwijanie standardów mapowania elementów notacji graficznych do standardu XML, który ma być jednoznacznym opisem modelu procesu biznesowego, tak samo jak model danych jest jednoznacznym opisem danych w systemach zarządzania bazami danych (DBMS). Podejście standaryzowane jest pewnym kompromisem między prostotą opisu procesów konieczną dla specjalistów zarządzania procesami oraz precyzją wymaganą do tworzenia systemów informatycznych. Notacja BPMN pozwala w miarę prosty sposób opisać procesy biznesowe, a zarazem jest na tyle precyzyjna, że pozwala na
jednoznaczne mapowanie diagramów do języków BPML, BPEL i BPML4WS, które są szkieletem działania silników (engines) systemów BPMS. Przewiduje się, że w niedługim czasie wszystkie narzędzia CASE i CABE będą używać do modelowania przepływu czynności jedynie standardu BPMN oraz diagramów czynności z UML 2.0. 7.6 Podejścia a zbadane metody - wyniki badania Tabela 3 przedstawia jak opisane w pracy metody mapują się do podejść, której objęły badania. Podejścia Rysunkowe Symulacyjne Inżynieryjne Metody Microsoft Visio Stencils igrafx Process ARIS BPMN Oracle Case RUP Eriksson-Penker Tabela 3 Podejścia do modelowania procesów biznesowych a zbadane metody Źródło: opracowanie własne Analitycznoholistyczne Standaryzowane Tabela ta jest wynikiem możliwie najbardziej obiektywnych analiz porównawczych dokonanych podczas badań. Jak wyraźnie można zauważyć, nie można jednoznacznie określić, że jedna metoda odpowiada jednoznacznie tylko jednemu podejściu. Ciemny prostokąt oznacza, że metoda głównie wiąże się z danym podejściem. Jasnoszary prostokąt oznacza, że metodę można użyć w innym podejściu, choć nie jest to idealna metoda do takiego zastosowania. Przykładowo, podejście standaryzowane to przede wszystkim metoda BPMN. Notacja IDEF0 używana w MS Visio jest również pewnym standardem przemysłowym do dzisiaj stosowanym np. w wojsku. Metoda Erikssona-Penkera to przede wszystkim podejście analitycznoholistyczne, ale można ją także użyć w podejściu rysunkowym. 8 PODSUMOWANIE W niniejszym opracowaniu podjęto próbę klasyfikacji popularnych metodologii modelowania procesów biznesowych. Okazało się, że nie wszystkie narzędzia wspierają możliwe podejścia do modelowania. Wnioski z tych badań płynące mogą okazać się cenne dla kogoś stojącego przed wyborem metodologii (lub w zależności od punktu widzenia - narzędzia) dla celów związanych z inżynierią oprogramowania. Chociaż badanie przyniosło konkretne rezultaty, ważne jest, by uświadomić sobie podstawowe problemy, które może napotkać osoba decyzyjna, stojąca przed koniecznością wspomnianego wyboru. Po pierwsze, trudno jest zdobyć zwięzłą informację o metodach. Wiele metod nie ma formalnego opisu i zaleceń dotyczących jej stosowania. Inne metody zawierają bardzo dokładne opisy stosowania metody sięgające kilku tysięcy stron. Ponadto chcąc poznać zalety metod empirycznie należy nastawić się na bardzo długi cykl uczenia się ich. Konieczne jest to zrozumienie zarówno podstaw notacji samej metody, ale także nauka obsługi samego narzędzia. Dosyć często może też okazać się, że zaistniała konieczność porównania narzędzi znacznie różniących się funkcjonalnością, a wręcz należących do różnych klas -
modelowanie procesów biznesowych może być wspomagane zarówno przez edytory graficzne typu MS Visio jak i przez skomplikowane narzędzia klasy CASE jak Oracle Designer. By przekonać się o "jakości" metody dla celów modelowania procesów z konkretnej dziedziny należałoby podjąć próbę stworzenia co najmniej dwóch takich samych modeli w różnych narzędziach. W trakcie badań zauważono jednak kolejne niebezpieczeństwo związane z uzyskaniem obiektywnego wyniku takich analiz porównawczych. Jeżeli analityk przeprowadzi badania szeregowo, można zaryzykować tezę, iż zawsze modele budowane w pierwszej kolejności uzna (subiektywnie) za trudniejsze, niezależnie od samej metodologii czy narzędzia. ŹRÓDŁA [1] Barker R., Longman C.: CASE* Method SM. Modelowanie funkcji i procesów. Warszawa: Wydawnictwa Naukowo Techniczne 2001. [2] Biernacki P. T.: Dokumentowanie i symulowanie procesów biznesowych od ISO 9000 do six sigma. [w:] Systemy informatyczne zastosowania i wdrożenia. Warszawa: Wydawnictwa Naukowo Techniczne 2002. [3] Business Process Management Initiative: Business Process Modeling Notation, Version 1.0 May 3, 2004; http://www.bpmi.org/ 2004. [4] Czerska J.: Mapa systemu. Jak uzyskać informacje o procesie i możliwościach jego doskonalenia.[w:] Inżynieria Systemów Zarządzania. Praca zbiorowa pod redakcją Ludmiły Zawadzkiej. Gdańsk: Wydawnictwo Politechniki Gdańskiej 2002. [5] Eriksson H-E., Penker M.: Business Modeling with UML. Business Patterns at Work. New York: Wiley Computer Publishing 2000. [6] Frankel D.S., Harmon P., Mukerji J., Odell J., Owen M., Rivitt P., Rosen M., Soley R.M.: The Zachman Framework and the OMG s Model Driven Architecture [W:] Business Process Trends, September 2003: http://bptrends.com. [7] Gola M., Porównanie metod i narzędzi modelowania procesów biznesowych - praca magisterska, Gdańsk 2005 [8] Hammer M.: Reinżynieria i jej następstwa. Jak organizacje skoncentrowane na procesach zmieniają naszą pracę i nasze życie. Warszawa: Wydawnictwo Naukowe PWN 1999. [9] IDS Scheer: ARIS Method [w:] ARIS 6 Collaborative Suite, July 2004. [10] Leffingwell D., Widrig D.: Zarządzanie wymaganiami. Warszawa: Wydawnictwa Naukowo Techniczne 2003. [11] Quint Wellington Redwood Academy. Materiały Szkoleniowe: IT Service Management Foundations. Quint 2001. [12] Rummler G. A., Brache A. P. : Podnoszenie efektywności organizacji. Warszawa: Polskie Wydawnictwo Ekonomiczne 2000.