Wprowadzenie

Od czasu do czasu jestem pytany o narzędzie Bizagi. Jest to kompletny system BPMS?*? składający się z narzędzi do modelowania procesów i serwera stanowiącego dla tych modeli środowisko wykonawcze ?(?Bizagi Overview,? n.d.)?. Narzędzie do modelowania, Bizagi Modeler, to bardzo popularne, darmowe, narzędzie do dokumentowania modeli procesów biznesowych z użyciem notacji BPMN???.

Często wyszukiwanym hasłem na moim blogu jest enigmatyczne: “bizagi”, od czasu do czasu jestem pytany: “Co sądzę o Bizagi, bo rozważamy jego wykorzystanie w naszej firmie do modelowania procesów biznesowych?” Ten artykuł nie będzie jednak rozbudowaną opinią czy analizą możliwości tego narzędzia, skupię się na opisie przydatności Bizagi do określonego celu jakim są analizy biznesowe.

Bizagi

Trzeba zacząć od tego, czym jest to narzędzie. Otóż jest to przede wszystkim narzędzie do tworzenia graficznej formy modeli procesów, których celem jest ich uruchamianie na platformie Bizagi Automation. Bizagi to rozbudowane platforma do modelowania i uruchamiania systemu wspomagania procesów biznesowych. Są to trzy narzędzia: Bizagi Modeler, Bizagi Studio i Bizagi Automation. Pierwsze to darmowe narzędzie do tworzenia graficznej wersji modeli procesów biznesowych. Pozostałe dwa to płatne narzędzia do tworzenia i uruchamiania aplikacji implementującej modelowane procesy.

Bizagi Modeler pozwala jedynie na opracowanie graficznych modeli procesów (schematów blokowych) z użyciem notacji BPMN. Wspiera tę notacje bardzo dobrze. Pozwala na tworzenie rozbudowanych diagramów, a także na ich współdzielenie w grupie (wspólny dysk lub w chmurze np. Dropbox). Pozwala generować ich dokumentację, jednak dokumentacja ta, to raport a nie samodzielny dokument korzystający z diagramów, dlatego wpływ na kształt tych dokumentów jest ograniczony. Narzędzie to przyda się, jeżeli jedynym celem projektu jest opracowanie dokumentacji procesów biznesowych w notacji BPMN i nic ponad to.

Czy Bizagi pomoże w analizie biznesowej? Jeżeli pod pojęciem Analiza Biznesowa rozumiemy pracę, której celem jest opracowanie wymagań na oprogramowanie to niestety, poza opracowaniem modeli procesów biznesowych, nie pomoże. Kluczowym problemem jest tu to, że do pozostałych prac (etapów pracy) w analizie biznesowej, analizie wymagań, i projektowaniu oprogramowania, trzeba korzystać z innych narzędzi. W efekcie zarządzanie całą dokumentacją staje się bardzo trudne.

Bizagi Modeler jest narzędziem darmowym i łatwym w nauczeniu się korzystania z niego, więc dobrze sprawdza się jako notatnik dla członków zespołu po stronie firmy analizowanej, o ile oczywiście dysponujemy po tej stronie osobami potrafiącymi używać notacji BPMN. W praktyce wygląda to tak, że po przeszkoleniu, zespół pracowników firmy analizowanej, wg. “najlepszej swojej wiedzy” opisuje określone procesy biznesowe, korzystając z Bizagi Modeler, i przekazuje efekty pracy analitykowi. Te modele, jako szkice procesów, analityk importuje do swojego narzędzia CASE (pliki Bizagi są łatwe w imporcie) i kontynuuje prace, tworząc już osobiście poprawne, profesjonale modele tych procesów.

Tu uwaga praktyczna: odradzam podejście, polegające na wysłaniu zespołu projektowego na kilkudniowe szkolenie i przekazaniu mu zadania “opracujcie modele procesów biznesowych” np. przed wdrożeniem systemu ERP, czy zamówieniem dedykowanego oprogramowani. Po takim kursie produkty pracy takiego zespołu mogą być dobrym punktem startu dla doświadczonego analityka, ale nie znam przypadku by stanowiły jakikolwiek wartościowy materiał końcowy.

Trzeba mieć świadomość, że analiza i modelowanie wymaga umiejętności, dużej wiedzy i doświadczenia, a planowane tak oszczędności (pójdziemy na szkolenie i sami zrobimy taniej) szybko się mszczą. Celem szkoleń jest zdobywanie wiedzy. Doświadczenie i umiejętności zdobywa się już samodzielnie w trakcie kolejnych projektów.

Na zakończenie

Bizagi jako narzędzie darmowe i wygodne na pewno pomoże wejść niskim kosztem w nowy obszar wiedzy i pracy, jest to narzędzie, które powstało tylko w jednym celu: dokumentowanie procesów na użytek określonej platformy BPMS. Owszem, tam gdzie celem jest jedynie udokumentowanie procesów, jego stosowanie nie jest pozbawione sensu. Jednak zakres dzisiejszych projektów analitycznych bardzo rzadko zamyka się w obszarze modelowania procesów. Warto pamiętać, że pełna dokumentacja procesów to także procedury (złożone listy i scenariusze) oraz struktury dokumentów biznesowych (tu XML, UML), tworzenia których Bizagi już nie wspiera.

Bizagi z zasady służy do tworzenia modeli wykonywalnych (BPMN rozdz.2: Common Execution Models), dlatego w projektach trzeba przyjąć określoną konwencję tworzenia modeli analitycznych, a tu walidator Bizagi (narzędzie pomagająca w utrzymaniu zgodności diagramów z zasadami notacji) nie raz raczej będzie przeszkadzał niż pomagał.

Artykuł jest krótki i na pewno nie wyczerpuje listy problemów i niejasności w wyborze narzędzia, dlatego zachęcam do zadawania pytań poniżej. Postaram się odpowiedzieć wedle najlepszej swojej wiedzy i doświadczenia.

Podobnie jest z narzędziami typu Lucidchart, drav.io, MIRO, itp. To narzędzia na poziomie PowerPoint, pozwalają coś narysować, ale na pewne nie są to narzędzia do modelowania, na pewno są bardzo czasochłonne i nie pozwalają na generowanie możliwej do zarządzania i przekazania komuś dokumentacji projektowej .


  1. ?*?
    BPMS – ang. Business Process Management System, czasami też rozszerzany jako Business Process Management Server
  2. ???
    BPMN – Business Process Modeling and Notation, standard notacyjny https://www.omg.org/bpmn/

Źródła

  1. Bizagi Overview. (n.d.). Retrieved June 23, 2019, from Bizagi website: https://www.bizagi.com/en/products

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 8 komentarzy

  1. Adam

    A może lepszym jest Event Storming promowany od wielu lat? Od UML się powoli odchodzi zresztą programiści i architekci jak dostaja od analityka biznesowego dokumenty to nie raz za głowę trzeba się lapac… Chyba tez rola analityka odchodzi do lamusa. Po co kogoś o coś pytać i na tej warstwie tracić informacje skoro deweloperzy muszą mieć cała wiedzę o biznesie… Rozumieć ją lepiej niż prezes firmy

    1. Jarosław Żeliński

      Niestety od UML się nie odchodzi, wręcz przeciwnie. Co do dokumentów od ‘analityka’ zawierających UML, głowa boli nie dlatego, że UML a dlatego, że większość ludzi zwanych Analityk Biznesowy pisze bzdety w tym UML ;). Po drugie developerzy nie muszą mieć i nie raz nawet nie mogą mieć całej wiedzy o domenie. Powody są bardzo proste i te same co w całej inżynierii: ochrona know-how biznesu (żaden dostawca komponentów do samolotów czy samochodów nie ma kompletu wiedzy o całości, i nie musi rozumieć co robi).

      Event storming niestety daje słabe efekty: jest ich masa i bardzo fałszują faktyczny obraz logiki. Prosty przykład dla biblioteki: wypożyczenie książki, zwrot książki, sprawdzenie liczby wypożyczonych przez czytelnika książek, naliczenie kary za przetrzymanie, sprawdzenie czy książka jest wypożyczona, ….. itp. To wszystko są konteksty aktora i może ich być więcej. A aplikacja to tylko jedna formatka (karta wypożyczenia) zawierająca pola: czytelnik, książka, data wypożyczenia i data zwrotu (plus reguły walidacji).

      Niestety żaden developer nie będzie lepiej rozumiał firmy niż jej prezes, tak samo jak producent samochodów nie będzie w stanie zastąpić prezesa wypożyczalni samochodów…. Największym problemem developerów jest ich przeświadczenie, że aplikacja to cały biznes, a tak nigdy nie jest. Dostawca nawet najlepszych maszynek do golenia nigdy nie będzie w stanie zastąpić fryzjera.

  2. Adam

    Nie zgodzę się z Panem.
    Polecam zapoznać się z technikami Domain Driven Design gdzie w ujęciu strategicznym.trzeba patrzeć na całą organizację. Co Events Storming jest wydaje mi się Pan w wielkim błędzie, jako developer nigdy nie rozmawiam po przez UML z biznesem.
    Polecam zastosować w praktyce.
    BTW Events Storming jest dla.mnje BPMNem na sterydach. Wydobywa język tworzący Bounded Contexty…. Może jeśli ktoś nie programuje jest mu to obce ale na końcu dnia to programista musi się zastanawiać nad każdym edge casem i nie usta nie zadawać sobie pytanie a co jeśli itp. ileż user story nie pokrywa wymagań: https://youtu.be/2df8_PHJuzk

    Polecam prezentacje Sławka Sobótki poniżej o Events Storming
    https://m.youtube.com/watch?v=F-A6n6HGJ_U
    A także materiały Mariusza Gila z bottegi na ten temat… Póki co jako business deweloperzy będą przejmować i już to robią pałeczkę od analityków i omów.

    1. Jarosław Żeliński

      Znam DDD od początku jego istnienia i żadne oprogramowanie nie zawiera w sobie 100% logiki biznesowej danej firmy. UML nie służy do tworzenia dokumentów dla ‘biznesu’ (tak jak rysunki techniczne samochodu nie są dla taksówkarzy). Sławka Sobótkę znam osobiście, on po latach doświadczeń ma podobne zdanie co ja ;). O ile wiem, Sławek raczej nie planuje przejmować pałeczki po mnie ;).

      A co z tą biblioteką, o której napisałem?

  3. Adam

    Co do DDD to pytanie czy z teorii czy z praktyki? UML nie przekazuje dla mnie tyle wiedzy biznesowej co warsztaty z ludzmi. Oczywiście powstaje pytanie jak to wiedzę zapisać…
    Sytuacja z życia analiza trwa 3 miesiące przed dewelopmemtem… Dołącza nowy deweloper do zespołu nie zna domeny biznesowej, co powinno mu się przestawić aby zrozumiał biznes i mógł go czuć i pisać oprogramowanie zgodnie np z BDD…
    Co do przejmowania pałeczki jest powoli zauważalna tendencja do budowania zespołów bez analityków biznesowych, ponieważ deweloper może tę wiedzę wydobyć bezpośrednio od interesjaruszy w organizacji.
    Zresztą kto nie programował a wyłącznie skupiał się dokumentach diagramach bpmn to nie czuje problemu z jakim idzie się zetknąć w codziennej pracy…
    Co do Sławka Sobótki to z prezentacji można między wierszami wywnioskować co innego chociaż nie wiem czy jest ta akurat gdzie wspomina o analitykach…

    Pozdrawiam i udanego Sylwestra

    1. Jarosław Żeliński

      Co do DDD i praktyki wystarczy wpisać DDD w tym blogu ;). Co do zastąpienia UML prozą i warsztatami, to proszę w fabryce samochodów lub pociągów zastąpić rysunek techniczny warsztatami z pasażerami;). Co do Sławka, wystarczy do niego napisać :). Powodzenia w Nowym Roku.

  4. Adam

    DDD mam na myśli od przeniesienia wiedzy do kodu 😉
    O taką praktykę mi chodzi…. Deweloperzy nie zatrzymują się tylko na zbieraniu wymagań i analizie ale po niej wypada coś napisać…
    https://github.com/ddd-by-examples/library
    Proszę zapoznać się z przykładem DDD z Events Stormingiem oraz C4… Jeden z najlepszych przykładów w sieci…
    Pozdrawiam i dziękuję za wymianę poglądów.

  5. Jarosław Żeliński

    “DDD mam na myśli od przeniesienia wiedzy do kodu”
    Sytuacja z przed dwóch dni: kto poza kilkoma developerami, potrafi skorzystać z “wiedzy przeniesionej do kodu?”. Biznes nie potrafi…

Możliwość dodawania komentarzy nie jest dostępna.