Posts Tagged ‘BPMN’

h1

Kiedy zaczyna się proces

Luty 21, 2013

Oczekiwanie na zdarzenie w poprzednim wpisie było związane ze zdarzeniami, które mają miejsce w trakcie trwania procesu i pozwalają na jego kontynuowanie. Z kolei dzielenie klasy na pary, było związane ze zdarzeniami przerywającymi proces lub wymagającymi wykonania określonych kolejnych kroków. Obydwie sytuacje były związane z tzw. intermediate events.

W przypadku BPMN można rozróżnić również zdarzenia inicjujące dane proces – tzw. start events. Proces może rozpoczynać się w wyniku wystąpienia danego zdarzenia (np. momentu czasu) lub jednego z wielu zdarzeń (np. czas lub wiadomość). Możliwa jest także sytuacja, gdy musi wystąpić równocześnie kilka zdarzeń. Dla każdej z tych sytuacji, język BPMN przewiduje różnego typu oznaczenia zdarzeń. Oznaczenia te pozwalają szybko zorientować się, podczas czytania diagramu, jaki rodzaj zdarzenia inicjuje proces.

Załóżmy, że mamy następującą sytuację. Pewna jednostka po zakończeniu każdego miesiąca kalendarzowego przygotowuje raport. Na przygotowanie raportu składa się określenie parametrów raportu, wykonanie raportu w systemie oraz przygotowanie komentarza do raportu. Taki proces jest inicjowany przez zdarzenie o typie określenia czasu (ang. timer), co widoczne jest na poniższym diagramie.proces_timer450

Załóżmy, że w pewnym momencie podjęto decyzję, że raport może być także przygotowywany na żądanie, zgodnie z wytycznymi podanymi we wniosku. Poniższy diagram w BPMN prezentuje dodanie takiego zdarzenia o typie wiadomości (ang. message). Jako element uzupełniający kroku „Określ parametry raportu” dodano informację o danych wejściowych (opcjonalnych).process_message450

Obok wskazanych typów zdarzeń inicjujących BPMN przewiduje jeszcze kilka ich rodzajów: niezdefiniowany (ang. none), warunkowy (ang. conditional), sygnał (używany przy łączeniu procesów, ang. signal), różne zdarzenia (ang. multiple), równoczesne zdarzenia (ang. parallel).

h1

Specjalistyczny pośrednik

Lipiec 20, 2012

Ponad roku, przy okazji omawiania wzorców „Fire and Forget” oraz „Request-Response posłużyłem się przykładem procesu ETL. Jednym z etapów realizacji tego procesu, jest wyciąganie (ang. Extract) danych. Wskazałem przykład zastosowania wzorca „Request-Response” (Pytanie – Odpowiedź) oparty na odpytywaniu bazy danych (dokładnie DBMS, tj. Systemu Zarządzania Bazą Danych) o dane/informacje/status i zwracanie przez nią stosownej informacji. Były to sprawdzenie dostępności bazy (DB), pytanie o wielkość danych (WD) i pobieranie kolejnych rekordów danych (DZ – dane zapytania). Takie działania mogą się odbywać poprzez bezpośrednie zapytania w języku SQL. Fragment oznaczony jako „bez wzorca” na diagramie poniżej przedstawia takie bezpośrednie odpytania.

Załóżmy jednak, że mamy odbytać kilka baz i powiązać dane ze sobą. Chcielibyśmy równocześnie uniknąć sytuacji namierzania się na każdą bazę osobno, identyfikowania jej strukury, a chcielibyśmy przekazać żądanie: sprawdź, pobierz, zapytaj. W takiej sytuacji między procesem Extract a poszczególnymi bazami danych można umieścić narzędzie pośredniczące, które wykona określone operacje i odpowiednio rozdzieli zadania po DBMS poszczególnych baz źródłowych.

W takim celu można zastosować wzorzec projektowy Fasada (ang. Facade), który zmniejszy liczbę połączeń i zależności między systemami. Wiąże się to utworzeniem „pośrednika” przyjmującego żądania i wysyłającego je do odpowiednich wykonawców. Sytuację taką prezentuje powyższy diagram w BMPN w części „wzorzec”.

Zaletą jest to, że mamy jeden interfejs, który można wykorzystać w różnych procesach, bez konieczności ingerowania w systemy źródłowe. Modyfikując połączenie między pośrednikiem a bazą (np. przeniesienie w inne miejsce, inna konfiguracja, sposób zapytania) modyfikujemy je tylko w jednym miejscu, bez konieczności zmiany procesów wywołujących. Takie rozwiązania są stosowane w implementacji systemów opartych o usługi (SOA).

h1

Zadanie: Reguła biznesowa

Lipiec 16, 2012

W artykule „A New Information Systems Paradigm: What does a Business Analyst Needs to Know?” na ModernAnalyst.com autorzy przybliżają czytelnikom serwisu ewolucję systemów informacyjnych i sposobu ich tworzenia. Przechodzą od prostych rozwiązań, wymagających więdzy po stronie szeroko pojętego biznesu nt. choćby tworzenia zapytań SQL, aż do rozwiązań nowoczesnych, rozbudowanych z implementacją systemów klasy workflow, wspartych silnikami baz danych i nie tylko.

Jednym z elementów, które poruszają, jest zarządzanie regułami biznesowymi i tworzenie systemów wspierających ich definiowanie, przechowywanie oraz wykonywanie. Tzw. BRMS (Business Rules Management System, czyli System Zarządzania Regułami Biznesowymi) są nieodłącznym elementem tworzonych systemów. Powstają one trochę przez analogię do wspomnianych jakiś czas temu przeze mnie BPMS (Business Process Management System, czyli System Zarządzania Procesami Biznesowymi) czy DBMS (Data Base Management System, czyli System Zarządzania Bazą Danych).
Załóżmy, że mamy następującą regułę biznesową, wykorzystywaną w korespondencji wysyłanej z systemu:

  • Płeć: mężczyzna → powitanie: Pan;
  • Płeć: kobieta oraz Stan: mężatka → powitanie: Pani;
  • Płeć: kobieta oraz Stan: wolny → powitanie: Panna;

Reguła jest bardzo prosta i to co się rzuca w oczy, w przypadku pierwszej reguły, stan cywilny nie ma znczenia. Powyższą regułę można byłoby w łatwy sposób zapis w bazie danych – jako 3 wiersze, z 3 atrybutami.

Powyższy artykuł przypomina, że w celi opisu takich reguł powstawała Decision Model Notation (DMN) – notarcja modeli decyzyjnych. Artykuł nie rozwija tego tematu, ale w Internecie można znaleźć informacje. W szczególności na stronach brcommunity.com wskazują, że definiowanie reguł jest związane z ich wielokrotnym użytkowaniem. Jest to silne wsparcie dla osób projektujących proces, za pomocą notacji BPMN 2.0, gdzie została przygotowana opcja „BusinessRuleTask”. Służy ona do wołania o wynik poszczególnych reguł. Od notacji BPMN można przejść do postaci wykonawczej poprzez zastosowanie BPML. Przykład zastosowanie tego typu zadania – BusinessRuleTask- został wskazany na powyższym diagramie BPMN. Zadania tego typu oznaczane są przez symbol pogrubionej „tabelki”.

W biznesie można spotkać się z dwoma typami reguł biznesowych – reguły ogólne, mające zastosowanie do wielu procesów, mających miejsce w różnych miejscach orgranizacji oraz reguły szczególne, wykorzystywane w danym procesie biznesowym. Opis reguł biznesowych jest ważnym elementem, który pozwala na zrozumienie działania procesu oraz okoliczności jego wykonania. Często są to tabele lub diagramy drzewiaste ze względu na różnorodnosć powiązań. Samo wykonanie reguł biznesowych może zostać zaimplementowane w różnych sposób – może to być np. tabela bazy danych, na której wykonywane są zapytania SQL a wynikiem jest wynik reguły. Na konferencjach często można usłyszeć w jaki sposób implementować reguły i w jakich sytuacjach. Równocześnie zwracana jest uwaga, aby sposób ich definiowania i przechowywania pozwalał na ich późniejsze aktualizowanie bez konieczności zmiany systemu odwołującego się.

h1

Od sprawności do efektywności procesu

Listopad 19, 2011

Ostatnio płaciłem za usługę za pomocą mechanizmu płatności elektronicznych, inicjowanych z poziomu panelu administracyjnego, jednego z dostawców usług (nazwijmy internetowych). Wybrałem usługę do opłacenia, wskazałem rodzaj pakietu, wybrałem sposób płatności, kilka razy potwierdziłem, a na koniec otrzymałem komunikat „Niestety nie udało się. Spróbuj jeszcze raz”. Pomyślałem, będą musiał powtórzyć ostatni krok. Niestety okazało się, że całość. Czy było to efektywne? Czy można powiedzieć, że proces jest sprawny? Proces w uproszczeniu został zaprezentowany na poniższym diagramie (w BPMN).

Fakt, za drugim razem, proces zakończył się oczekiwanym efektem – usługa została opłacona i jej czas obowiązywania został przedłużony na następny okres. Jednakże sama realizacja nie odbyła się jak dla mnie w najlepszy możliwy sposób – zarówno ze względu na poświęcony czas, kilkakrotne potwierdzanie czy też wątpliwość czy przypadkiem jakaś płatność nie została jednak wykonana, a jedynie potwierdzenie nie zadziałało, czy też powrót do panelu.

Sformułowanie „oczekiwany efekt” wskazuje na tzw. efektywność procesu, natomiast „najlepszy możliwy sposób” wskazuje na tzw. sprawność procesu. W internecie można znaleźć różróżnienie, dla ułatwienia posłużę się angielskimi definicjami:

  • Effective: Adequate to accomplish a purpose; producing the intended or expected result ( =oczekiwany efekt).
  • Efficient: Performing or functioning in the best possible manner (=najlepszy możliwy sposób) with the least waste of time and effort.

Definicje idealnie pokazują, że proces efektywny to taki, który generuje właściwe efekty, a proces sprawny, który doprowadza do tych efektów w najlepszy możliwy sposób, biorąc pod uwagę czas, koszt realizacji. W przypadku powyższego procesu należałoby poprawić sposób działania i obsługi wyjątków, aby był realizowany szybciej. Można by, jak w przypadku niektórych sklepów internetowych, zapisywać etapy zrealizowane i umożliwić podjęcie procesu od pewnego kroku, ostatniego zaakceptowanego. Jeżeli chodzi o efektywność procesu to efekt jest prawidłowy. Myślę, że warto najpierw zadbać, aby z punktu widzenia użytkownika, proces przynosił oczekiwany efekt, a następnie poprawiać sprawność procesu, tak, aby efekt końcowy przewyższał oczekiwania użytkownika.

h1

SIPOC na bazie diagramu BPMN

Czerwiec 4, 2011

W wielu przedsiębiorstwach, które udostępniają swoim pracownikom – np. pracownikom obsługującym klientów – system informatyczny, funkcjonuje proces obsługi zgłoszeń błędów/problemów. Proces ten funkcjonuje obok zwykłych/głównych procesów (ang. core processes), wspieranych przez system informatyczny i w których biorą udział pracownicy. W kontekście systemu informatycznego pracownik staje się użytkownikiem (albo inaczej patrząc aktorem).

Ideę takiego procesu obrazuje poniższy diagram w BPMN.

Proces obsługi zgłoszeńW jednym z ostatnich wpisów wspomniałem o diagramie SIPOC. Jest on używany do zobrazowania przepływu pracy. Po rozwinięciu poszczególnych liter nazwy – umieszczonych także w odpowiednich miejscach na diagramie – mamy następujące elementy:

  • Supplier (S), czyli Dostawca – oznacza podmiot, który dostarcza informacje, zasoby do realizowanego procesu. Na powyższym diagramie jest to użytkownik systemu, który zgłasza problem – oznaczony przez (S).
  • Input (I), czyli zasoby wejściowe – oznacza informacje, zasoby dostarczane przez Dostawcę. Powyżej jest to zgłoszenie problemu/błędu z jego opisem, czasem wystąpienia, identyfikatorem transakcji/błędu, danymi identyfikacyjnymi użytkownika. Obiekty oznaczone przez (I).
  • Process (P), czyli proces – działania w określonej kolejności, które wykorzystuję zasoby wejściowe w celu zwiększenia ich wartości lub wytworzenia efektu końcowego (wyjściowego). W tym wypadku jest proces ze wskazanymi czynności zmierzającymi do znalezienia rozwiązania. Uczestnicy procesu analizują dostarczone informacje przez użytkownika. Wykorzystują przekazane dane kontaktowe w celu uzyskania dodatkowych wyjaśnień. Proces (P) składa się z kroków „Analiza zgłoszenia”, „Poszukiwanie rozwiązania” oraz „Wybór/Wskazanie rozwiązania”.
  • Output (O), czyli efekt wyjściowy – oznacza informacje, zasoby dostarczane przez proces. Na diagramie jest to rozwiązanie (jego opis), oznaczony przez (O).
  • Customer (C), czyli klient – oznacza podmiot, który otrzymuje efekt wyjściowy. W tym wypadku jest to inicjatora zgłoszenia, oznaczony przez (C).

Więcej o diagramie SIPOC można przeczytać u źródła (Six Sigma).

h1

Wejścia i wyjścia w procesie

Kwiecień 13, 2011

Diagramy zaprezentowane w poprzednim wpisie – diagram procesu w BPMN oraz wizualizację myślenia systemowego – można spróbować połączyć na jednym diagramie, powstałym na bazie diagramu aktywności dla procesu biznesowego. Na poniższym diagramie zostały dodane wejścia do kroków i wyjścia z kroków (kierunek strzałek obrazuje to, czy dany obiekt jest wejściem czy wyjściem z danego kroku procesu).

Można zauważyć, że:

  • niektóre wejścia/wyjścia pasują do kwestii zobrazowanych na diagramie myślenia systemowego – np. „Akceptowalna stawka”;
  • niektóre kwestie z diagramu można potraktować jako cechę wejść/wyjść – np. „Liczba zgłoszeń” jest cechą „Listy zgłoszeń”;
  • niektóre kwestie z diagramu nie są związane z wejściami/wyjściami a bardziej są cechą charakterystyczną dla całego procesu – np. „Czas realizacji rekrutacji”;

Istotne jest to, że cechy wejść do poszczególnych kroków wpływają zarówno na realizację danego kroku, jak i całego procesu. Takimi cechami mogą być liczba zgłoszeń, jakość zgłoszeń, czas potrzebny na zapoznanie się z danym zgłoszeniem, stopień dopasowania poszczególnych zgłoszeń do opisu stanowiska pracy itd.

Świadomość takich powiązań ułatwia realizację procesu. W szczególności, gdy dany uczestnik procesu ma świadomość, że efekt (i jakość) realizacji jego zadania zostanie wykorzystany dalej w procesie, wpłynie na działania dalszych uczestników procesu. Właśnie do pokazania takich zależności w ramach procesu w kontekście produktów dla klientów wewnętrznych procesu można wykorzystać myślenie systemowe. Na analizie wejść/wyjść procesu jest oparte narzędzie SIPOC pochodzące z metodologii Six Sigma (ale o tym innym razem).

h1

Proces biznesowy a myślenie systemowe

Kwiecień 2, 2011

Załóżmy, że szukamy pracownika do realizacji określonego zakresu obowiązków w ramach projektu. Poniższy diagram (w BPMN) prezentuje przykładowy proces rekrutacji. Składa się z 3 kroków: utworzenia oferty pracy, znalezienia kandydatów, przeprowadzenia rozmów oraz akceptacji wybranego kandydata lub kandydatów. Realizacja procesu odbywa się sekwencyjnie i można by ją zaprezentować na osi czasu. Myślę, że nie muszę wchodzić w szczegóły, ponieważ łatwo sobie można wyobrazić co się dzieje na poszczególnych krokach.

Chciałbym się jednak zastanowić na powiązaniach między wejściami oraz wyjściami (efektami) poszczególnych kroków tego procesu. „Jakość” niektórych wyjść wpływa pozytywnie bądź negatywnie na realizację kolejnych kroków bądź efekt całego procesu. Można powiedzieć, że pewne kwestie tego procesu pośrednio lub bezpośrednio wpływają na inne. Efekt końcowy w postaci znalezienia odpowiedniego kandydata zależy od wcześniej ustalonych elementów lub zrealizowanych działań. Poszukiwanie takich zależności jest charakterystyczne dla myślenia systemowego.

Myślenie systemowe polega na wskazywaniu kierunku oddziaływania pewnych rzeczy na inne. Wpływ może być zarówno dodatni/pozytywny, jak i ujemny/negatywny. Kierunek wpływu jest oddawany za pomocą strzałek. Poniższy diagram pokazuje to podejście dla wybranych aspektów powyższego procesu.

Obserwuj

Otrzymuj każdy nowy wpis na swoją skrzynkę e-mail.

Join 49 other followers