Posty oznaczone jako ‘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.

h1

Perspektywa Klienta

Marzec 14, 2011

W poprzednich wpisać (w szczególności w ramach Etapów benchmarkingu) wskazane zostały następujące kroki procesu wykonywane po stronie klienta:

  • zgłoszenie zapotrzebowania / wyszukanie produktu(-ów),
  • akceptacja oferty dostawcy / złożenie zamówienia,
  • realizacja zamówienia (płatność, odbiór produktu, podanie szczegółów realizacji).

Między powyższymi krokami procesu wykonywane są kroki dostawcy, wpływające na zachowanie klienta i jego decyzje. Wskazane kroki nie są jedynymi wykonywanymi przez klienta. Patrząc z perspektywy klienta można również wyróżnić elementy tzw. procesu decyzyjnego przed zakupem. W literaturze można znaleźć wiele podejść do tego procesu, różnego nazewnictwa uczestników oraz występujących etapów. Do mnie najbardziej przemawia rozwiązanie zaproponowane przez M.J. Baker.

W skrócie można je przedstawić jak na powyższym diagramie (przedstawionym w BPMN), dostosowując do przedstawionej sytuacji w poprzednich wpisach. Między punktami A i B, C i D mają miejsce kroki realizowane przez dostawcę lub wspólnie z dostawcą. Krok „Realizacja decyzji” mógłby zostać potraktowany jako cały wcześniej przedstawiony proces do momentu złożenia zamówienia/potwierdzenia.

h1

Benchmarking procesów

Luty 15, 2011

Benchmarking procesów jest jednym z 3 rodzajów benchmarkingu, biorąc pod uwagę przedmiot porównania (obok benchmarkingu strategicznego i benchmarkingu produktów). Polega na analizie procesów liderów rynkowych pod względem efektywności kosztowej oraz sposobie kreowania wartości dla klienta, a następnie porównanie z procesami danego przedsiębiorstwa i wyciągnięciu wniosków. Wnioski z porównania mogą przyczynić się do przeprowadzenia odpowiednich zmian. Na przykład w ramach łańcucha dostaw ten rodzaj benchmarkingu skupia się przede wszystkim na następujących możliwościach odnośnie procesów:

  • łańcuch kierowany przez dialog z klientem,
  • skuteczna dystrybucja,
  • planowanie sprzedaży na podstawie popytu,
  • wytwarzanie odchudzone (ang. lean manufacturing),
  • partnerskie stosunki z dostawcami,
  • zintegrowane zarządzanie łańcuchem.

Na powyższym diagramie (w BPMN) zaprezentowano w sposób uproszczony przebieg łańcucha dostaw sterowanego popytem klienta. W trakcie określania przedmiotu realizacji następują ustalenia między Klientem a przedstawicielem dostawcy/producenta. Diagram zawiera moment oczekiwania na decyzję klienta – proces planowania nie rozpocznie się, jeżeli zamówienie nie zostanie potwierdzone. Nie są przygotowane produkty na magazynie. Pominięta została w przykładzie kwestia dostawy surowca czy zlecania pracy podwykonawcom. Uwzględniając te elementy można byłoby wskazać także w jaki sposób przebiegają kontakty z kolejnymi uczestnikami procesu. Modnym podejściem w kontekście organizacji procesów produkcyjnych, dostawczych jest stosowanie tzw. wytwarzania odchudzonego.

h1

Dynamika – szczegółowość opisu

Styczeń 4, 2011

Trochę zainspirowany komentarzem do jednego z poprzednich wpisów, prowadzącym do artykułu „Diagram klas – czyli „reinżynieria” analizy biznesowej” (z it-consulting.pl/blog), a trochę w wyniku krystalizacji pomysłu na kolejny wpis, postanowiłem spojrzeć na diagram klas z poprzedniego wpisu w sposób bardziej dynamiczny. Jest to o tyle ważne, że sposób prezentacji diagramu klas i wykorzystane konstrukcje wpływają później na sposób implementacji takiego rozwiązania, przedstawiającego w bardziej lub mniej szczegółowy wymagania użytkownika. Chciałbym się skupić na elemencie „Zamówienia” wraz z operacjami wykonywanymi na nim.

Zastanówmy się najpierw czego oczekuje użytkownik systemu do składania zamówień od tego elementu. Odpowiedź nasuwa się sama, chce zaspokoić, w szczególności, dwie swoje potrzeby:

  • potrzebę dodania produktu do zamówienia oraz
  • potrzebę (ewentualnego) usunięcia produktu z zamówienia

Po prostu wyszukuje produkt i dodaje go do zamówienia, bądź wchodzi do „zamówienia” (listy dodanych produktów) i usuwa dany produkt. Świadomie nie wpisałem powyżej zmiany ilości, ponieważ tak naprawdę zwiększenie/zmniejszenie ilości produktu można zinterpretować jako dodanie/usunięcie produktu. Zostańmy jednak przy operacjach dodaj/usuń.

Użytkownik wybiera daną opcję i nie interesuje go co się dzieje wewnątrz systemu. Poniższy diagram w notacji BPMN jest próbą zaprezentowania tego, co mogłoby się dziać.


Diagram obrazuje, że system może kilka różnych czynności wykonać po wybraniu opcji przez użytkownika. Kilka kwestii wymaga jednak komentarza. Na poziomie Klienta zostały przedstawione operacje na najwyższym poziomie tożsame wręcz przyciskom w systemie. Natomiast na poziomie Systemu pojawiają się operacje wskazane na diagramie klas. Użytkownik dodaje produkt do zamówienia, określając jego ilość, a system tworzy pozycję na zamówieniu, dla danego produktu wraz z odpowiednią ilością. Pozycje zamówienia w tym wypadku nie są współdzielone (zastosowano kompozycję).

Można byłoby dalej dodać mechanizmy zabezpieczające przed dodaniem większej ilości produktu niż jest dostępna. Można także określić operacje proklienckie.  Wraz z kolejnymi zamówieniami sytuacja klienta w systemie oraz określonych produktów w pewnym sensie się zmienia. Zwiększając precyzję opisu wymagań można wskazywać kolejne ograniczenia czy też możliwości.

Rozbudowa opisu może przejść od typowej „narracji” (przykład w poprzednim wpisie), przez konkretne „scenariusze” (repezentowane przez tabele, diagramy) po „komunikację” (między elementami, wymianę komunikatami, co częściowo zostało pokazane w niniejszym wpisie).

Follow

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

Join 49 other followers