Temat: BPMN - zastosowania

Jerzy N.:
Moim zdaniem:
3. Dziwnym trafem procesy zamodelowane w BPMN można z niemal 99% dokładnością zamodelować w UML za pomocą diagramów aktywności.

A ja podejrzewam w tym zakresie spisek a może nawet sabotaż :P

4. Przejście od modelowania biznesowego do modelowania systemu informatycznego (np. diagram klas, diagram sekwencji, diagram komunikacji, diagram use-case itd.) w UML jest niemal naturalne i
większość narzędzi UML to umożliwia (wiązanie poszczególnych elementów z poszczególnych dagramów ze sobą pozwala zastosować traceability).
5. Przejście od modelowania biznesowego do modelowania systemu informatycznego za pomocą BPMN może nastręczyć sporo trudności, a i tak modele systemu informatycznego obecnie wykonuje się w UML (modelowanie obiektowe).
6. Do modelowania systemu informatycznego BPMN jest fajne, ale obecnie nie ma specjalnego zastosowania (bardziej opłaca się UML).

Kompletnie nie zgadzam się ze stwierdzeniem że cokolwiek w UML jest naturalne. 99% procesowców nie ma pojęcia o UML, natomiast notacja BPMN jest właśnie naturalnym językiem modelowania procesów rozszerzonym o wymagane przez IT "gadżety". Umożliwia w taki sposób zamodelować proces biznesowy, że jest jednoznaczny, spójny i łatwy do konwersji chociażby na ukochany przez programistów UML.
Właśnie po to zostały stworzone narzędzia umożliwiające konwersję jednej notacji do drugiej, bo modelowanie procesów biznesowych w UML się nie opłaca, bo analitycy po stronie biznesu tej techniki nie znają, nie lubią, daleka jest od języka naturalnego dla tej części organizacji. Analityk biznesowy który nawet zna UML, nie jest w stanie skutecznie komunikować się z właścicielami biznesowymi procesów lub produktów, ponieważ dla nich jest to tym bardziej czarna magia. BPMN jest przez nich łatwiej przyswajalny i interpretowalny, co skutkuje jego co raz większą popularnością.

Porównanie UML z BPMN, to tak jakby wymagać od analityków czy procesowców, aby dostarczali IT od razu gotowe funkcje do implementacji w systemie napisane w javie/C czy dowolnym innym języku programowania.

Dodatkowo ze względu na swoją specyfikę BPMN pozwala modelować procesy na innym poziomie abstrakcji, który jest istotny przy kontaktach z managementem wyższego szczebla.

Kolega patrzy tylko na swoje podwórko, na naszym UML do ciekawostka, którą bawią się "sweterki" z IT :)

PS. A normy mają upraszczać życie i komunikację, ale nie wyznaczają jedynego słusznego kierunku :PGrzegorz Kozłowski edytował(a) ten post dnia 15.10.07 o godzinie 16:54

Temat: BPMN - zastosowania

Jerzy N.:
Może jednak poda Pan mi ten standard. Chętnie skoczę na Świętokrzyską zakupić rewolucyjną normę ISO. Wszak za tego typu wiedzę trzeba płacić, toteż w Internecie Pan tego nie znajdzie.

Nic mi nie wiadomo by analizy były opisywane jakimikolwiek normami. Jeżeli zna Pan normy, poza kodeksami etycznymi bo te znam, regulujące prace analitków i ekspertów chętnie się z nimi zapoznam.Jarosław Żeliński edytował(a) ten post dnia 15.10.07 o godzinie 18:57

Temat: BPMN - zastosowania

Jerzy N.:
Proponuję wymieniać w tym temacie firmy i projekty, gdzie został zastosowany BPMN oraz oczywiście reakcje klientów.
Z mojej strony:
1. Urząd Patentowy RP - Portal Internetowy - zainteresowanie klienta: prawie żadne
2. Urząd Gminy Parzęczew - Zarządzanie dokumentami - zainteresowanie klienta: bardzo żywe !!!
3. Projekt EOG w Cieszynie - Scenariusze księgowań - zainteresowanie klienta: minimalne
4. TPSA - SMP - zainteresowanie klienta: marginalne.

Z moich doświadczeń wynika, że BPMN to praktycznie ciekawostka.

Ja planuje zakończenie swojego udziału tej dyskusji wiec podsumuje od siebie:
- z uwagi na umowy jakie mnie wiążą z klientami w kwestii listy kłientów odsuła tu: http://wspolpraca.it-consulting.pl
- z moich obserwacji wynika, że BPMN to nie jest ciekawostka

Pozdrawiam
jz
P.S.
Ja wykonuje analizy, nie sprzedaję żadnego BPMN, wiec prawdopodobnie nie jestem reprezentatywny w tej próbie.

Temat: BPMN - zastosowania

Jerzy Niepostyn:

4. TPSA - SMP - zainteresowanie klienta: marginalne.

Z moich doświadczeń wynika, że BPMN to praktycznie ciekawostka.

Dlaczego tak uwazasz, na jakiej podstawie????

Pozdrawiam
Remi

Temat: BPMN - zastosowania

Grzegorz Kozłowski:

>. Analityk

biznesowy który nawet zna UML, nie jest w stanie skutecznie komunikować się z właścicielami biznesowymi procesów lub produktów, ponieważ dla nich jest to tym bardziej czarna magia. BPMN jest przez nich łatwiej przyswajalny i interpretowalny, co skutkuje jego co raz większą popularnością.

Porównanie UML z BPMN, to tak jakby wymagać od analityków czy procesowców, aby dostarczali IT od razu gotowe funkcje do implementacji w systemie napisane w javie/C czy dowolnym innym języku programowania.

No teraz to juz przesadziles :) ... UML nie jest az taki straszny ... jest po prostu inny i przekladanie jego trudnosci w porownaniu do BPMN'u jak prawie na kodowanie to juz przestepstwo :)

Mysle ze to jest wystarczajacy komentarz:

"Where BPMN has a focus on business processes, the UML has a focus on software design and therefore the two are not competing notations but are different views on systems.
The BPMN and the UML are compatible with each other. A business process model does not necessarily have to be implemented as an automated business process in a process execution language. Where this is the case, business processes and participants can be mapped to constructs such as use cases and behavioural models in the UML."

Pozdrawiam
RemiRemigiusz Franek edytował(a) ten post dnia 17.11.07 o godzinie 01:40

Temat: BPMN - zastosowania

Remigiusz Franek:

Grzegorz Kozłowski:

>. Analityk

biznesowy który nawet zna UML, nie jest w stanie skutecznie komunikować się z właścicielami biznesowymi procesów lub produktów, ponieważ dla nich jest to tym bardziej czarna magia. BPMN jest przez nich łatwiej przyswajalny i interpretowalny, co skutkuje jego co raz większą popularnością.

Porównanie UML z BPMN, to tak jakby wymagać od analityków czy procesowców, aby dostarczali IT od razu gotowe funkcje do implementacji w systemie napisane w javie/C czy dowolnym innym języku programowania.

No teraz to juz przesadziles :) ... UML nie jest az taki straszny ... jest po prostu inny i przekladanie jego trudnosci w porownaniu do BPMN'u jak prawie na kodowanie to juz przestepstwo :)

Mysle ze to jest wystarczajacy komentarz:

"Where BPMN has a focus on business processes, the UML has a focus on software design and therefore the two are not competing notations but are different views on systems.
The BPMN and the UML are compatible with each other. A business process model does not necessarily have to be implemented as an automated business process in a process execution language. Where this is the case, business processes and participants can be mapped to constructs such as use cases and behavioural models in the UML."

Pozdrawiam
Remi

No i dobrze że odezwał sie ktoś z "wymienionej wcześniej firmy, która do wszystkiego używa UML". :)

Powyższy ang. cytat moim zdaniem wyjaśnia sedno sprawy.

Coraz więcej metodyk uznaje, że biznes należy zrozumieć cały zanim określi się zakres projektu. Coraz częściej spotykam się z potwierdzeniem tezy, że przypadki użycia (UC, Use Case) to najwcześniej drugi etap analizy, pierwszy to analiza całej organizacji. Ja szczerze mówiąc traktuje UC jako trzeci etap po modelu procesów i modelu dziedziny systemu.

Tu chyba nalezy się honor analizie strukturalnej, która od zawsze zakładała diagram kontekstowy jako punk wyjścia analizy wymagań, dzisiaj nazwał bym go namiastką modelu biznesowego. Wtedy była to jednak tylko analiza strukturalna, ciężka i pracochłonna, nie poddajaca się temu co obecnie nazywamy Agile Modeling.

Dziś mamy sytuację, w której standardem tworzenia systemów są metody obiektowe. Dlatego zarzuca się diagramy przepływu danych. Diagramy ERD jako modele danych nadal są w użyciu bo nadal na rynky dominują bazy relacyjne. Tak więc mapowanie O/R nadal często ma miejsce bo tego nie zrobi automat.

SOA zakłada opis wszystkich procesów (całej organizacji) za pomocą BPMN bo celem tego etapu jest zrozumienie i udokumentowanie całości metodą biznesową (biznes łatwo akceptuje to co bez dodatkowej nauki jest dla nich zrozumiałe) ale jednak sformalizowaną metodą czyli tu pojawia się BPMN.

Analiza obiektowa wkracza dopiero w momencie gdy pada hasło "trzeba stworzyć system IT". I tu dopiero pojawia się UML jako podstawowe obecnie narzędzie dokumentowania wyników analizy obiektowej. UML to także narzędzie do dalszych prac np. tworzenia modelu technicznego itp...

Analiza obiektowa to doskonałe narzędzie do modelowania organziacji ale w kontekście implementacji tej wiedzy w systemie. Nie widzę, żadnego zastosowania anlizy obiektowej w kontekście zarządczym bo tu właśnie istotne sa działania a nie "klasy", "stany" i "byty".

Na poziomie zarządczym ważne są struktury zasobów i przepływ pracy. Tu UML ma niewiele do powiedzienia, mimo że są tam diagramy czynności i sekwencji. Sa one dobrym narzędziem przekazu wiedzy o algorytmach dla programisty ale nie koniecznie opisu pracy dla prezesa.

Moim zdaniem żaden model nie ma sensu jeżeli nie można go skonsultowac z jego adresatem. Adresatem modeli BPMN jest biznes, modeli UML wykonawca przyszłego systemu. A dobry analityk musi żyć w środku.