Wstęp

KLuczową ich wadą jest

To, że są one tak na prawdę tylko uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji i jej potrzeb (bo nie koniecznie jej pracowników!)  i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane,  swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE!

Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek? ( czytaj cały artykuł: Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!).

Dlaczego tak jest? Bo oprogramowanie jest tworzone z pomocą języków programowania a te SĄ sformalizowane. Nie da się skompilować do postaci systemu ERP “luźnej prozy”. Napisałem to w Listopadzie 2011, dzisiaj ciąg dalszy. Na początek dodam jeszcze moją konkluzję z pewnej konferencji:

Tak więc język formalny, użyta notacja, czyni projekt wartościowym [jednoznacznym]. Bez tego raczej nie znaczy on po protu nic. (Modelowanie procesów biznesowych – dlaczego mają sens tylko metody formalne i uznane notacje).

Jak to mówią: mocne słowa, ale nie zapominajmy, że mało który projekt biznesowy IT kończy się w terminie i zamyka w założonym budżecie. Zastanówcie jak były dokumentowane Wasze “nieudane” projekty…

O notacjach

Króciutko, żeby się nie powtarzać.  Notacja to pewien język wyrazu, przestrzeń nazw zawierająca skończoną liczbę pojęć o ściśle zdefiniowanych znaczeniach. Notacji mamy na rynku wiele. Czy to jakiś problem? W pewnym sensie tak, bo po pierwsze języki te nieco nakładają się na siebie (nakładają się na siebie przestrzenie nazw) ale nie dają się na siebie w sposób jednoznaczny tłumaczyć. Języki te nie zastępują się wzajemnie. Są “w użyciu” notacje (systemy tworzenia diagramów) niesformalizowane, trudno je w ogóle nazywać notacją. To po protu biblioteki symboli do tworzenia schematów blokowych a te nie koniecznie są “modelami”. Przykładem może być bardzo popularny MS Visio z wieloma bibliotekami symboli. Niestety tak powstające diagramy są zapewne ilustracją dla tekstu ale nie są żadnym modelem.

Opisze tu wybrane notacje, te których używam i uznaje za pewien standard de’facto. Nie będzie to żadne “szkolenie z notacji”, bo nie jest to ani miejsce ani dobry sposób na szkolenia (na te serdecznie zapraszam zainteresowanych na sale wykładową :)).  Powiemy sobie o ArchiMate (z tej notacji później zrezygnowałem z uwagi na jej niejednoznaczność i wprowadzone licencjonowanie), BMM, BPMN, UML.

Organizacji się nie “opisuje”, organizacje się modeluje

Każda organizacja to bardzo złożony organizm. Stopień złożoności jest duży, szczególnie gdy wziąć pod uwagę fakt, że niejedna zatrudnia setki pracowników, tworzy tysiące dokumentów, obsługuje tysiące spraw i używa dziesiątek narzędzi (w tym oprogramowanie) wspomagających tę pracę . Czy to w ogóle da się jakoś opisać? Owszem. Jak?

Ich modele to określone idealizacje, pozwalające zrozumieć sposób ich działania. Problem jednak  w tym, że organizacja to wiele różnych aspektów jej działania. Dla każdego z nich powstał inny język opisu, powodem jest (tak sądzę), po pierwsze różny odbiorca na każdym poziomie szczegółowości, a po drugie różne paradygmaty (procesowy, obiektowy czy system analiz wpływu). Kto inny czyta opis strategii biznesowej a kto inny opis techniczny systemu ERP, jednak oba te aspekty są jakoś powiązane (powinny być ;)) i to także powinno dać się opisać. Z tego powodu pierwszym podziałem modeli są: modele logiczne (abstrakcja) i wykonawcze (specyfikacja). Na to nakłada się sfera biznesowa (zarządzanie) oraz techniczna (zasoby w tym narzędzia).

Nie znajdziecie tu państwo definicji tych notacji, odsyłam na strony organizacji standaryzujących (Object Management Group oraz The Open Group). Pokaże do czego doszedłem na bazie dziesiątek projektów małych i dużych, dla realnych przedsiębiorstw i fikcyjnych badawczych. Posłużę się klasycznym chyba już modelem analizy zstępującej, w postaci piramidy obrazujące trzy poziomy abstrakcji opisu organizacji (im niżej tym więcej szczegółów zawiera dokumentacja):

Na najwyższym poziomie abstrakcji mamy strategię, tu pojawia się tak zwany model motywacji i analiza wpływu.  Obecnie używam na tym poziomie notacji (języka modelowania) Business Motivation Model. Zawiera takie pojęcia jak cel biznesowy, środki osiągania celu ale także bardzo ważne na tym etapie takie elementy jak czynniki wpływu, analiz a SWOT, ryzyka  czy strategie i taktyki.

Na tym poziomie od tego roku można stosować notację ArchiMate, jednak w moim przekonaniu jest ona w tym obszarze zbyt silnie ukierunkowana na metodykę i struktury opisu TOGAF, jest w moich oczach w tej sferze uboższa, brakuje jej wielu pojęć “obsługiwanych” przez BMM.

Jeżeli nie widzę nic złego w stosowaniu kilku notacji w jednym projekcie (jest to w zasadzie konieczność), to z zasady używam wyłącznie jednej notacji na jednym poziomie abstrakcji (warstwie jak wyżej). Używanie na jednym poziomie np. dwóch różnych notacji prowadzi co najmniej do braku spójności modeli gdyż pojęcia różnych notacji różnią się swoim zasięgiem (poszczególne pojęcia mają nieco inne znaczenia).

Na poziomie procesów biznesowych, stosuję zamiennie BPMN albo ArchiMate.  Z każdym kolejnym projektem skłaniam się jednak do używania na tym poziomie ArchiMate. Powodem jest to, że BPMN oferuje wyłącznie czyste pojęcia z definicji procesu (czynność, dane, zdarzenie, rola, pula, bramki). Na tym poziomie jednak nie raz należy wyrazić rozdzielnie takie pojęcia jak rola i aktor (np. klient i kontrahent mogą pełnić rolę zamawiającego w procesie) albo odrębne pojęcia takie jak funkcje biznesowe (aktor wraz z zasobami jakich używa pełni funkcję administracji wewnętrznej) albo usługi powiązane z procesami (proces sprzedaży powiązany z usługą obsługi klienta). Przykłady można mnożyć.

Realizacja procesów to “suche” łańcuchy czynności i twarda logika ich scenariuszy. Tu doskonale sprawdza się BPMN i pierwotny cel powstania tej notacji: modelowanie skryptów BPEL ([[Business Process Execution Language]], a obecnie  głównie [[XPDL]]). W tej warstwie BPMN nie ma konkurencji, jest w 100% zgodny z XPDL  (język opisu procesów zalecany przez [[Workflow Management Coalition, WfMC]]). Podejmowane są próby stosowania UML (Diagram czynności) ale nie wróżę tej metodzie sukcesu i nie polecam jej (powody na końcu tekstu).

Tu dodatkowa mała uwaga. Nawet na poziomie wykonawczym procesu rzadko pojawia się potrzeba, modelowania “explicite” każdej czynności, z dokładnością niemalże algorytmiczną. W większości wypadków zupełnie wystarczy “model celowości działań” i ich scenariusze, algorytm postępowania potrzebny jest tylko maszynie.  Na stronach BPM Research dostępne są wyniki badań pokazujące to zjawisko:  The average subset of BPMN used in these models consisted of just 9 different symbols. That means that the average BPMN model uses less than 20% of the available vocabulary. (Najczęściej używany w modelach zestaw pojęć BPMN to  9 symboli. Oznacza to, że w modelach BPMN używanych jest niecałe 20% zdefiniowanych w tej notacji pojęć). Polecam dostępny na tych stronach wykres.

Można się spotkać z pojęciem trzech poziomów modelowania procesów (Bruce Silver blog): warstwa opisowa, warstwa modeli analitycznych, warstwa modeli wykonawczych. w zasadzie nie odbiega to od powyższego modelu jednak autor proponuje tu w warstwie pierwszej (opis) tworzenie ogólnych modeli z zaniedbaniem reguł notacji. Tu jednak niestety narażamy się na niejednoznaczności. Ja widać nie ja jeden dostrzegam potrzebę  podziału na poziomy abstrakcji w modelowaniu i analizie. Propozycja Bruce’a Silvera jest jak najbardziej warta naśladowania, z tym jednak, że lepszym pomysłem jest, moim zdaniem, wybranie notacji dostosowanej do poziomu abstrakcji, dlatego na poziomi opisowym (ja jednak wole nazwę model biznesowy lub łańcuch wartości, to nadaje konkretny sens temu modelowi) stosuję oraz częściej ArchiMate by nie musieć łamać zasad systemu pojęciowego danej notacji (jak sam Bruce Silver przyznał, wymaga to wyłączenia kontroli poprawności modelu).

Warstwa architektury systemów IT. Tu w zasadzie równoprawnie można używać ArchiMate i UML (głównie diagram komponentów i diagram wdrożenia). Jednak kojarząc logikę biznesową (poziom procesów biznesowych) z architekturą aplikacji (system IT), należy zastosować jedną notację dla obu warstw by zachować spójność pojęciową modelu, a to daje nam właśnie ArchiMate (to są już projekty “dotykające” architektury korporacyjnej).

Najniżej mamy warstwę specyfikacji systemu IT, jego strukturę (albo jak to woli model realizacji systemu IT). Na tym poziomie w użyciu notacja UML, która do tego powstała. Jeżeli uznać fakt, że metody strukturalne odeszły do lamusa (notacje DFD) a modele relacyjnych baz danych są na zbyt niskim, inżynierskim poziomie (notacja ERD), to UML jako język obiektowy, nie ma w tym obszarze konkurenta. Poniżej typowy zakres (pakiety, w nich są lokowane “artefakty” produktu analizy) moich projektów:

Powyższy diagram obrazuje strukturę modeli (pod spodem odpowiadające mu drzewo katalogów, diagram powyższy do diagram pakietów UML).

Powyższy diagram to także podział z perspektywy adresata dokumentacji: dla tak zwanego biznesu adresowane są trzy warstwy licząc od góry. Dla wykonawców systemów ostatnia: wykonawcza.

Na zakończenie kilka słów o UML

Notacja ta powstała jako uniwersalna (Unified Modeling Language, Uniwersalny Język Modelowania)  jednak tu chyba autorzy tej notacji dotknęli problemu “coś co jest do wszystkiego jest do niczego”. Mimo tego, że z pomocą systemu tak zwanych profili w UML możliwe jest wyrażenie w tej notacji pojęć każdej z pozostałych wymienionych, nie jest to dobry pomysł. Mam nadzieję, że nie “zachoruje na to” The Open Group i ArchiMate (pojawiła się wspomniana ArchiMate 2.0).

Dlaczego UML nie powinien być używany do wszystkiego? Notacja ta jest “skażona” tak zwanym obiektowym paradygmatem, bardzo trudnym do przyswojenia dla osób nie obytych z metodami obiektowymi w inżynierii oprogramowania. Po drugie system graficzny w UML nie ułatwia odbioru, percepcji modeli gdyż większość pojęć jest obrazowana prostokątem z różnymi etykietami. Zjawisko to (zrozumiałość graficznych systemów komunikowani treści) opisuje nauka jaką jest [[Semiotyka]]. Nie jest to miejsce na jej opis, jednak wykazuje ona, że stosowanie np. UML do komunikowania czegokolwiek ludziom z tak zwanego “biznesu”, nie mającym nic wspólnego z obiektowym paradygmatem, nie jest dobrym pomysłem, a dokumenty opisujące  organizację w końcu mają im służyć.

Semiotyka “uczy nas”, że każde pojęcie (koncept) dla możliwie najlepszej zrozumiałości dla odbiorcy, powinien być reprezentowany innym znakiem (kształtem), najlepiej kojarzącym się z reprezentowanym znaczeniem (co znaczy ten znak).

Innym razem na kilku przykładach, pokażę modele w ArchiMate…

Przewiduję powolne odchodzenie od idei systemów zintegrowanych na jednym modelu danych. Dotychczasowa ich zaleta czyli pełna (i zarazem trwała) integracja przestaje być zaletą a staje się garbem. System zintegrowany można już “skleić” ze specjalizowanych aplikacji, komponentów. Technologia komponentowa bardzo ten proces ułatwiła. Drugim powodem przewidywanego odejścia od tej idei są ogromne kłopoty z oceną rentowności wdrożenia systemu ERP. Nie raz jest to po prostu wręcz niemożliwe z powodu braku możliwości oceny jakim kosztem wspieramy pojedynczy proces biznesowy bo trudno z jednego ogromnego systemu wykroić koszt wsparcia pojedynczego procesu. Z tego też powodu rośnie zainteresowanie systemami typu middleware (szyny ESB). Do tej pory były wykorzystywane rzadko i dużych firmach, głównie w sektorze finansowym i głownie z uwagi na ich koszt. Obecnie rozwiązanie to staje się coraz popularniejsze. Dlatego?

Pojawienie się standardów w modelowaniu, ustanowienie modelowania pełnowartościowym etapem projektu (a nie ekstrawagancją), otwieranie się technologii, pojawianie się standardów wymiany metadanych i modeli, torują drogę do znacznego obniżenia kosztów i usprawnienia tworzenia systemów opartych o komponenty. To wszystko powoduje, że nie trzeba jednego wielkiego systemu zintegrowanego. Wystarczy tak zwany motor procesów biznesowych i specjalizowane systemy, mogą one pochodzić od różnych producentów i pracować na różnych platformach.

Jedyne czego trzeba przestrzegać to praca od samej góry: model biznesowy organizacji, model procesów biznesowych, struktura workflow (scenariusze działań czyli wewnętrzny opis procesów), lista oczekiwanych usług systemu IT i sam system składany z komponentów. Te trzy elementy: model biznesowy, model procesów, usługi IT stanowią pewną całość. Ubranie opisu usług w ciało to właśnie obiektowe/komponentowe technologie w IT, architektura SOA i MDA, języki i notacje BPMN, UML oraz format danych XML, obiektowe języki programowania.

Koniec quasimonopolu dostawców systemów

No i okazało sie, że standardy sprawdzone same się bronią. Microsoft w BizTalk Server będzie wspierał BPEL (Business Proces Execution Language, oparty na XML język skryptowy opisu procesów między innymi w systemach BPM i workflow management używany już między innymi w niektórych systemach CASE). Oracle także “rozumie” BPEL. Modelowanie staje się normą a otwartość standardem. Notacje UML i BPMN stają się standardem modelowania.

Co to znaczy? Moim zdaniem to, że powoli staje się coś o czym pisałem swego czasu na stronach IT-Consulting. Monopolistę zaczęli doganiać konkurenci. Monopolista zaczyna czuć pokorę: już nie wyznacza sam standardów de’facto (np. formaty plików dokumentów, narzędzia programistyczne, interfejsy komunikacyjne). Tracąc powoli rynek na rzecz rozwiązań konkurencji dostrzegł, że to co było przewagą rynkową (zamknięte rozwiązania) stało się w dalszej perspektywie hamulcem. Przyszła pora na otwartość i konkurowanie jakością a nie szantaż ponad 80% udziałem w rynku (vide współpraca Microsoft i Novell).

Kierunki rozwoju systemów IT

Albo analiza procesowa i obiektowa albo na margines życia. Coraz powszechniejsze zrozumienie idei zorientowania na procesy, interoperacyjności (w tym zarządzanie łańcuchami dostaw), architektury SOA (która moim zdaniem doskonale się wpasowuje w metody zarządzania zorientowanego na procesy i reorganizację w firmach) powoduje stawianie takich wymagań także dostawcom rozwiązań IT. Te które się do tego nie dostosują, moim zdaniem odejdą z rynku.

Model biznesowy firmy, informacje i dane jakich firma wymaga do sprawnego funkcjonowania to już jeden organizm. Stało się faktem, że żadna firma na rynku już nie będzie w stanie konkurować bez sprawnego zarządzania informacją. Do zarządzania informacją i przetwarzania danych zaś potrzebne są sprawnie działające i przede wszystkim łatwe w ich rozwijaniu systemy. Warunek taki spełniają obecnie zorientowane na procesy systemy tworzone w technologiach obiektowych.

Drugi warunek sprawności organizacji to optymalizacja jej wewnętrznej wydajności. Tu wkraczamy dla odmiany w zarządzanie i jego procesową naturę. Jak to pogodzić? Postrzegam tu właśnie miejsce dla architektury SOA. Firmę i jej miejsce w rynkowym łańcuchu wartości można, moim zdaniem, jednoznacznie opisać tylko za pomocą modelu procesowego zorientowanego na produkty. Zasoby (tu system IT) potrzebne do realizacji tej strategii analizujemy już obiektowo.

Namiastką takich opisów i analiz były procedury w księgach jakości ISO. Do pełnej analizy wymagany jest jednak opis (mapa procesów) uwzględniający cały obraz firmy. SOA to architektura wskazująca naturalny proces projektowania systemów IT: model procesowy firmy (organizacji), analiza procesów z perspektywy zasobów IT jakimi mogą być wspierane, na bazie tej analizy powstaje lista usług na rzecz procesów biznesowych jakich oczekujemy od nowego systemu.

Następnie w procesie analizy obiektowej usługi te transponowane są na model obiektowy przyszłego systemu IT. Analiza obiektowa powinna dać jako produkt także opis dziedziny systemu czyli reprezentację rzeczywistych obiektów w systemie. Jest to podstawa modelu danych dla powstającego systemu. Kolejne etapy to już projekt obiektowego programu (aplikacji) i jego implementacja.

Na razie widzę, że klarują się dwa podejścia:

– IDEF0 lub ICOM i pochodne (w tym EPC i eEPC)

– inne idą w kierunku UML

IDEF0 to kompletny model logiczny uwzględniający zasoby i cele biznesowe (które niestety często zatraca się w procesie modelowania!). UML to droga do zaprojektowania aplikacji. Myślę, że tą drogą w środku spotkają się analitycy i programiści. W miejscu gdzie mamy model procesowy i procedury (workflow) na najniższym poziomie dekompozycji programista obiektowy ma wszystkie informacje by z pomocą UML zaprojektować i napisać kod aplikacji. Każdy prosty ?bloczek? modelu oraz interfejsy (formatki dokumentów) mogą teraz zostać zaimplementowane w systemie. Być może od strony modelowania BPMN (Business Process Modeling Notation) a od strony kodowania BPEL wniosą ułatwienie polegające na umożliwieniu pewnej automatyzacji tworzenia programów jednak w moim przekonaniu ważniejsze jest by precyzyjnie wskazać granice kompetencji pomiędzy analitykiem a inżynierem i dokładnie na tej granicy umieścić styk narzędzi analitycznych i inżynierskich.

Modelowanie to dziedzina prawie tak stara jak systemy informatyczne dla biznesu. Podstawowym celem modelowania procesów jest opisanie firmy, określenie celu projektu reorganizacyjnego i jego zakresu, określenie wymagań na tworzone oprogramowania a wcześniej optymalizacji organizacji i przygotowanie jej do wdrożenia. Stworzenie opisu funkcjonalnego tego co będziemy oprogramowywać zawsze było wyzwaniem trudnym. Drugim, być może jeszcze trudniejszym jest (do dzisiaj) nawiązanie nici porozumienia i zrozumienia pomiędzy sferą biznesu a inżynierami i programistami.

Jedna z ról jaką ma do odegrania wykonany przez analityków model jest stworzenie szkieletu aplikacji lub przynajmniej opisu tego szkieletu. Naturalnym dążeniem jest także próba uniknięcia ręcznego “przepisywania” pracy analityków biznesowych modelu i wygenerowanie na jego podstawie kodu aplikacji lub przynajmniej jej modelu np. w postaci UML.

Notacje i metodyki modelowania można podzielić  na dwie grupy:

1. modelowanie do prowadzenia analiz i optymalizacji procesów i zdarzeń gospodarczych (procesów biznesowych)
2. modelowanie do celów tworzenia oprogramowania

Na świecie nadal najpopularniejsze są: IDEF wśród analityków i UML wśród programistów.

Modele analityczne

Tu się niewiele zmieniło. Nadal w użyciu jest IDEF0 i jego odmiany a raczej warianty czyli ICOM  i mniej znany IGOE. Skrót ICOM to: Input, Controll, Output, Mechanizm czyli Wejście, Sterowanie, Wyjście, Mechanizm (tu chodzi o zasoby). Skrót IGOE ma rozwiniecie: Input, Guide (odpowiednik sterowania), Output, Enabler (tu chodzi o zasoby w kontekście inicjatora realizacji danej funkcji). W obu przypadkach ogólny schemat procesu w tych konwencjach przedstawiany jest za pomocą prostokąta symbolizującego funkcję realizowaną przez proces oraz strzałki obrazujące wymienione cztery jego atrybuty :

Na tym poziomie powstało wiele produktów, które niestety zawierają swoje unikalne rozszerzenia symboli i reguł. Doprowadziło to powstania wielu narzędzi do modelowania, których produkty są ze sobą niekompatybilne już na poziomie użytych symboli. Nie wymieniając ich tu napisze, tylko, że w dość powszechnym użyciu jest ich prawie dziesięć a Gartner zidentyfikował ich na rynku trzydzieści sześć. Z tego też powodu używam w pracy symboli ICOM prostych i zrozumiałych dla biznesu zaś w przypadkach bardziej “sformalizowanych” używam IDEF0. Z uwagi na stały rozwój także tych metod ostanio zainteresowąłem się notacją BPMN.

Modelowanie do celów tworzenia oprogramowania

Ten temat jest dużo trudniejszy, gdyż dążenie do realizacji “sprzęgu” pomiędzy analitykiem a informatykiem to temat istniejący od początku czasów tworzenia oprogramowania do celów biznesowych. Krótka historia narzędzi do modelowania na potrzeby tworzenia oprogramowania (rok powstania i nazwa metody):

• 1962: sieci Petriego (Carl Petri Network)
• 1970: ANSI Flow charts
• 1979: DFD (Data Flow Diagram)
• 1982: ISO TC87 (ISO Conceptual Schema Model)
• 1992: Merise (Methode d’Etude et de Realisation Informatique pour les Systemes d’Enterprice)
• 1992; EPC (Eventdriven Process Chains)
• 1995: IDEF3 (Integrated Definition Method 3, Process Description Capture Method)
• 2001: ebXML v.1.1 (electronic business using eXtesible Markup Language)
• 2002: BPML v.1.1 (Busines Process Modeling Language)
• 2002: WSCi v.1.0
• 2003: BPEL4WS (Business Process Execution Language for Web Services)
• 2004: BPMN (Business Process Modeling Notation)

(na podstawie “Process modeling – A Maturing Discipline?”, Michael Rosemann, Maria Indulska, Peter Green, Quinsland University of technology Information).

Sieci Petriego są nadal uważane za jedno z najskuteczniejszych narzędzi do modelowania jednak ich głównym ograniczeniem jest dość skomplikowany model matematyczny oraz brak hierarchizacji funkcji jak to ma miejsce w realnych organizacjach.  Nie zawiera też w sobie narzędzi do opisu  architektury obiektowej oprogramowania. Metody tworzenia oprogramowania zorientowane obiektowo doprowadziły do powstania narzędzi typu UML jednak są one bardzo trudne do zastosowania w modelowaniu biznesowym gdyż natura organizacji jest hierarchiczna a nie obiektowa. Modele obiektowe są po pierwsze praktycznie niezrozumiałe dla biznesu po drugie nie sprawdzają się jako narzędzie do opisu organizacji, która żyje i ewoluuje. Stale rozwijające się metody zarządzania ewoluują w stronę procesów biznesowych ich natura zaś jest jest hierarchiczna. Kolejną próbą rozwiązania problemu jest powstanie BPMN.

BPMN – Business Process Modeling Notation

Ideą twórców BPMN jest stworzenie narzędzia dla analityków ale takiego, którego produkty da się “tłumaczyć” na BPEL4WS. Bazą dla BPMN są sieci Petriego i EPC. Dla tego 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.

Notatka: W tym roku (2005) opublikowano wersję 1.0 notacji BPMN (Business Process Modeling Notation). 12 Września 2005 w Atlancie odbyła się konferencja BPMN Foundation na której między innymi ogłoszono połączenie Notation Working Group z OMG i specyfikację BPMN v.1.0. W planie jest RFC.