UWAGA: Tekst jest z 2008 roku. BPMN wtedy raczkował. Dziś tj. dekadę później standardem modelowania procesów biznesowych jest BPMN a UML jest notacją stosowaną w specyfikacji systemów informatycznych.
Modelowanie procesów biznesowych odgrywa co raz większe znaczenie. Wiele organizacji, które właśnie zamierzają wejść w świat modeli biznesowych ma problem jaki standard zapisu wybrać BPMN (Business Process Modeling Notation) czy UML (Unified Modeling Language)? Z tego też powodu i ja postanowiłem dorzucić swój kamyczek do ogródka. Na wstępie zaznaczam, ze znam obie notacje i poniżej reprezentuje tylko swoje subiektywne zdanie.
Niewątpliwie jest BPMN jest dedykowany do budowania modeli procesów biznesowych a UML jest dedykowany do modelowania systemów informatycznych, ale posiada dedykowane dla modelowanie procesów biznesowych rozszerzenie notacji. Wydawać się by mogło, że odpowiedź jest oczywista: modelowanie procesów biznesowych to BPMN, ale BPMN ma sporo ograniczeń w stosunku do UML. Oto kilka z nich:
-
BPMN modeluje tylko przepływy sterowanie a nie widać tu przepływu danych – w UML dane można zobrazować jako klasy i potem na diagramach aktywności pokazać je jako przepływ obiektów,
-
BPMN nie pozwala zamodelować struktury firmy – w UML są od tego diagramy pakietów
-
BPMN nie pozwala zamodelować hierarchii użytkowników – w UML za pomocą biznesowych aktorów i generalizacji można to zrobić
-
BPMN ma wiele elementów, które wymagają od osoby czytającej diagram znajomości niuansów BPMN – UML ma w modelu biznesowym mniej elementów notacji
-
znajomość notacji BPMN nie pozwala czytać modeli opisujących projektowany (lub działający) system informatyczny
-
BPMN oferuje jeden diagram do opisu organizacji – w UML można uzyskać opis organizacji z różnych perspektyw
BPMN w stosunku do UML ma też plusy:
-
BPMN pozwala lepiej uwidocznić logikę procesu biznesowego
-
BPMN pozwala wygenerować kod BPEL (Business Process Execution Language) co wspomaga automatyzację implementacji
Wybierając notację zapisu modeli biznesowych należy przede wszystkim zastanowić się do dlaczego chcemy modelować i do czego w przyszłości będzie wykorzystywany model. Wydaje się mi ze ograniczenie zastosowanie notacji język UML dedykowanej dla modeli biznesowych w zakresie diagramów przypadków użycia, aktywności i klas oraz pakietów w zupełności pozwala odwzorować strukturę i czynności, jakie realizuje prawie każda organizacja. Ponadto w przypadku decyzji o wsparciu wybranych obszarów firmy systemem informatycznym specyfikacja takiego systemu jest w znacznym stopniu gotowa. A to w wielu przypadkach wielkie oszczędności czasu i pieniędzy.
Artykuł ciekawy jednak chyba troszke stronniczy: tu kilka uwag w kwestii ograniczeń BPMN:
* BPMN modeluje tylko przepłwy sterowanie a nie widać tu przepływu danych – w UML dane można zobrazować jako klasy i potem na diagramach aktywności pokazć je jako przepływ obiektów,
jz- przepływy danych w BPMN modeluje sie obiektem danych wraz z możliwością modelowania zmiany stanów tego obiektu (każdy oniekt Dane ma stan i powiązanie z procesem),
*BPMN nie pozwala zamodelować struktury firmy – w UML są od tego diagramy pakietów
jz – struktura torów basenów modeluje hierarchię ról np. strukturę organizacyjną firmy.
*BPMN nie pozwala zamodelować hierarchii użytkowników – w UML za pomocą biznesowych aktorów i generalizacji można to zrobić
jz – patrz wyżej
*BPMN ma wiele elementów, które wymagają od osoby czytającej diagram znajomości niuansów BPMN – UML ma w modelu biznesowym mniej elementów notacji
jz – podstawowe elementy to siedem intuicyjnych ikon, nieobyty klient prędzej przeczyta procesowy BPMN niż obiektowy UML (to z praktyki)
*znajomość notacji BPMN nie pozwala czytać modeli opisujących projektowany (lub działający) system informatyczny
jz – nie rozumiem tej uwagi…
*BPMN oferuje jeden diagram do opisu organizacji – w UML można uzyskać opis organizacji z różnych perspektyw
jz – owszem, jednak obiektowy paradygmat kiepsko pasuje do opisu procesowo/projektowych struktur zarządzania….
Osobiście używam BPMN do modelowania organizacji i UML do modelowania oprogramowania i danych. Moim zdaniem stosunkowo łatwo nauczyć absolwenta prawa czy zarządzania modelowania procesów ale trudno będzie mu zaakceptować abstrakcyjny model obiektowy.
Pozdrawiam gorąco i na prawdę podziwiam znajomość UML.
Artykuł ciekawy jednak chyba troszke stronniczy:
[michal] Oczywiście :), ale to moje przemyślenia i ciesze się, że jest ktoś kto myśli inaczej bo poznanie innych opinii pozwala się rozwijać.
tu kilka uwag w kwestii ograniczeń BPMN:
* BPMN modeluje tylko przepływy sterowanie a nie widać tu przepływu danych – w UML dane można zobrazować jako klasy i potem na diagramach aktywności pokazać je jako przepływ obiektów,
jz- przepływy danych w BPMN modeluje sie obiektem danych wraz z możliwością modelowania zmiany stanów tego obiektu (każdy oniekt Dane ma stan i powiązanie z procesem),
[michal] W UML jest pojecie klasy, która w konkretnym scenariuszu biznesowym jest obiektem mającym swoje atrybuty i stan (np.: faktura atrybuty: numer, data; stan: niezapłacona)
*BPMN nie pozwala zamodelować struktury firmy – w UML są od tego diagramy pakietów
jz – struktura torów basenów modeluje hierarchię ról np. strukturę organizacyjną firmy.
[michal] w moim mniemaniu tory pozwalają zarówno w UML jak i BPMN wskazać tylko kto w w danym procesie biznesowym wykonuje dane działanie.
*BPMN nie pozwala zamodelować hierarchii użytkowników – w UML za pomocą biznesowych aktorów i generalizacji można to zrobić
jz – patrz wyżej
[michal] jak wspomniałem generalizacja sporo problemów rozwiązuje, ale nie wszystkie.
*BPMN ma wiele elementów, które wymagają od osoby czytającej diagram znajomości niuansów BPMN – UML ma w modelu biznesowym mniej elementów notacji
jz – podstawowe elementy to siedem intuicyjnych ikon, nieobyty klient prędzej przeczyta procesowy BPMN niż obiektowy UML (to z praktyki)
[michal] mam inne doświadczenia. Zgodzę się, że wrzucenie obiektowego UML dla kogoś kto go nie zna to pierwszy krok do porażki. Dla nieobytego klienta zastosowanie diagramu aktywności jest IMHO bardziej czytelne bo to tylko 4 elementy (w podstawowej wersji tego diagramu)
*znajomość notacji BPMN nie pozwala czytać modeli opisujących projektowany (lub działający) system informatyczny
jz – nie rozumiem tej uwagi?
[michal] w tym zdaniu chciałem napisać, że BPMN nie jest dedykowany do budowy modeli
*BPMN oferuje jeden diagram do opisu organizacji – w UML można uzyskać opis organizacji z różnych perspektyw
jz – owszem, jednak obiektowy paradygmat kiepsko pasuje do opisu procesowo/projektowych struktur zarządzania?.
[michal] tu się zgodzę, dlatego stosuje tylko wybrane elementy bazujące przede wszystkim na diagramach aktywności
Osobiście używam BPMN do modelowania organizacji i UML do modelowania oprogramowania i danych. Moim zdaniem stosunkowo łatwo nauczyć absolwenta prawa czy zarządzania modelowania procesów ale trudno będzie mu zaakceptować abstrakcyjny model obiektowy.
[michal] Ostatnio spędziłem kilka dni w jednym z banków budując modele procesów biznesowych z doświadczonymi analitykami biznesowymi, którzy nigdy nie modelowali ani w UML ani w BPMN i po bardzo krótkim wstępie szło im rewelacyjnie :). Oczywiście modele biznesowe były ograniczone do modeli biznesowych przypadków użycia i diagramów aktywności.
Widzę, że każdy z nas ma swoje doświadczenia, ale dzięki temu pewnie obaj jesteśmy w umiejętny sposób (czyt. dostosowany do potrzeb klienta) zastosować odpowiednie techniki z danej notacji.
Przy okazji chciałem wspomnieć o innym tekście dotyczącym tego tematu.
pozdrawiam
Michał
[mw] z doświadczonymi analitykami biznesowymi, którzy nigdy nie modelowali ani w UML ani w BPMN
[prawicki] to rzeczywiscie byli doswiadczeni…
[prawicki] to rzeczywiscie byli doswiadczeni?
[mw] Kiedyś też tak myślałem, że analityk musi w czymś modelować, ale czasem nigdy tego nie robią. Jest im trudniej niż tym, którzy modelują ale dają radę 🙂
Więc czemu nadal w większości wybierany jest BPMN? Czego nie daje nam UML co możemy zamodelować w innych językach? W jakich sytuacja pojawiają się komplikacje i problemy?
Moim zdaniem przyczyny wyboru BPMN jest kilka:
1. UML uchodzi za język modelowania dla informatyki a BPMN dla biznesu (moim zadaniem osąd mylny);
2. większość firm, które modelują to firmy zagraniczne a tam zgodnie z punktem pierwszym króluje BPMN;
3. brak świadomości możliwości UML;
4. brak wiedzy jak wykorzystać UML w modelowaniu procesów biznesowych;
Na szczęście polskie firmy, które zaczynają modelować procesy biznesowe starają się dokonać świadomego wyboru pomiędzy UML a BPMN.
* BPMN modeluje tylko przepływy sterowanie a nie widać tu przepływu danych – w UML dane można zobrazować jako klasy i potem na diagramach aktywności pokazać je jako przepływ obiektów,
jz- przepływy danych w BPMN modeluje sie obiektem danych wraz z możliwością modelowania zmiany stanów tego obiektu (każdy oniekt Dane ma stan i powiązanie z procesem),
[michal] W UML jest pojecie klasy, która w konkretnym scenariuszu biznesowym jest obiektem mającym swoje atrybuty i stan (np.: faktura atrybuty: numer, data; stan: niezapłacona)
[pb] W BPMN statusy zapisywane są w nawiasach kwadratowych: Faktura [niezapłacona]
Co do struktury danych. Tak obiekt danych tłumaczony jest do BPEL:
*BPMN nie pozwala zamodelować struktury firmy – w UML są od tego diagramy pakietów
jz – struktura torów basenów modeluje hierarchię ról np. strukturę organizacyjną firmy.
[michal] w moim mniemaniu tory pozwalają zarówno w UML jak i BPMN wskazać tylko kto w w danym procesie biznesowym wykonuje dane działanie.
[pb] Ale to „kto” może być ułożone w hierarchię (tory zagnieżdżone). Nie wypowiadam się na temat sensowności takiego zapisu 🙂
*BPMN ma wiele elementów, które wymagają od osoby czytającej diagram znajomości niuansów BPMN – UML ma w modelu biznesowym mniej elementów notacji
jz – podstawowe elementy to siedem intuicyjnych ikon, nieobyty klient prędzej przeczyta procesowy BPMN niż obiektowy UML (to z praktyki)
[michal] mam inne doświadczenia. Zgodzę się, że wrzucenie obiektowego UML dla kogoś kto go nie zna to pierwszy krok do porażki. Dla nieobytego klienta zastosowanie diagramu aktywności jest IMHO bardziej czytelne bo to tylko 4 elementy (w podstawowej wersji tego diagramu)
[pb] Zgadzam się z Jarkiem bo… diagram aktywności nie musi przedstawiać procesu biznesowego (w biznesowym kontekście procesów biznesowych) i pozwala na mieszanie w przepływie obiektów przepływów i danych (vide przykłady diagramów aktywności ze specyfikacji UML.Dlatego modelowanie za pomocą AD często zaciemnia a nie rozjaśnia zrozumienie procesu.
*znajomość notacji BPMN nie pozwala czytać modeli opisujących projektowany (lub działający) system informatyczny
jz – nie rozumiem tej uwagi?
[michal] w tym zdaniu chciałem napisać, że BPMN nie jest dedykowany do budowy modeli
[pb] BPMN jest dedykowany do budowy modeli i co więcej modele BPMN dają się uruchamiać (np. po konwersji do WS-BPEL) lub symulować jeśli narzędzie do modelowania to potrafi.
Co więcej jedynie prawidłowy model BPMN pokazuje jak potrzeby biznesowe (model abstrakcyjny) są automatyzowane za pomocą systemu IT (model systemowy w BPMN). Biznesu nie obchodzi jak ma działać aplikacja wspierająca a jedynie jak będą wspierane jego potrzeby.
Ale to tylko moje doświadczenie 🙂
Modelowałem przez wiele lat w UML i BPMN, często biorąc udział w dużych projektach. Nie zauważyłem nigdy wspomnianych ograniczeń BPMN w stosunku do UML.
Powiem więcej, dziwi mnie bardzo, że UML nie dopracował się dedykowanych diagramów modelowania procesów biznesowych, skoro analiza procesów biznesowych jest przecież punktem wyjścia w analizie wymagań na systemy IT.
Paweł Tadejko.
Mnie ne dziwi. Zarówno BPMN jak i UML są własnością OMG. Nie ma sensu w ramach tej samej organizacji tworzyć 2 różnych standardów do tego samego. Prostą radą OMG jest – chcesz zamodelować proces? Użyj BPMN. Proces jest dynamicznie zmienny – użyj CMMN.
Czy można ludzi wozić ciężarówką? Można, tylko po co.