Koncepcja BPM według PEGA (wersja 7.1)

innowacyjne rozwiązania IT

PEGA posiada złożony układ zależności między poszczególnymi bytami wchodzącymi w skład swojego BPM (Business Process Management). W oparciu o wspomniane byty będziemy budować nasze rozwiązania ułatwiające zarządzanie przepływem prac (workflow) w organizacji. Jakkolwiek maślanie by to nie brzmiało, odpowiada rzeczywistości. W tym artykule omówię wspomniane byty i wskażę jakie są między nimi zależności. A także, które z nich są niezbędne, aby możliwe było opracowanie rozwiązania wykorzystując PEGA.

Zacznijmy od początku. Pierwsze co musimy posiadać, aby w ogóle zacząć myśleć o budowie rozwiązania to Organizacja (Organization). To właśnie ona jest punktem wyjścia dla naszych prac. Do organizacji przypisujemy jej hierarchię (działy – Divisions oraz jednostki – Organization units), grupy dostępów (Access Groups) i użytkowników (Users). Posiadając użytkowników w danej organizacji możemy zacząć projektować nasze rozwiązanie. Podczas dodawania organizacji otrzymujemy na dzień dobry użytkownika o loginie ‚Admin@<nazwa organizacji>‚ i haśle ‚rules‚. Możemy oczywiście dodawać kolejnych użytkowników, ale do rozpoczęcia pracy w zupełności wystarczy admin. Pamiętajmy, że jeden system PEGA może posiadać wiele niezależnych od siebie organizacji.

W ramach organizacji dodajmy aplikację (Application). Do jednej organizacji możemy dodawać wiele aplikacji, działających niezależnie od siebie. Aplikacja jest rozwiązaniem biznesowym, które wspiera automatyzację przepływu prac (workflow) w organizacji. Np. w firmie ubezpieczeniowej aplikacjami będą: Sprzedaż, Obsługa odszkodowań, Back office itd.

Mając już aplikację, dodajemy sprawę (Case). Sprawą jest coś co chcemy zrealizować w ramach aplikacji. Każda aplikacja może obsługiwać wiele różnych spraw. Mogą one posiadać zależności między sobą, ale nie muszą. Sprawa to najmniejsza jednostka pracy na jaką możemy podzielić aplikację. Generalnie sprawa ma za zadanie obsłużyć konkretny przypadek biznesowy (np. Obsługa wniosku o pożyczkę, Wypłata odszkodowania itp.).

Żeby nie było za prosto, dzielimy dalej. Sprawę możemy podzielić na etapy (Stages), czyli pewne logiczne zgrupowania kroków, jakie będziemy wykonywać w ramach danej sprawy.

A skoro już o krokach mowa – etapy dzielimy na kroki (Steps). Takim krokiem może być jeden z 3 bytów:

  1. Przypisanie – czyli po prostu uzupełnienie danych – formularz, na którym użytkownik powinien wprowadzić dane.
  2. Proces – zestaw czynności, które wykonuje użytkownik lub system (w naszym przypadku systemem jest PRPC – PegaRULES Process Commander, czyli silnik BPM PEGA).
  3. Sprawa – czyli uruchomienie innej sprawy.

I na tym podstawowe podziały bytów w BPM PEGA kończą się. Myślę, że dość już namieszałem. Czas na przykład.

W firmie Billennium chcemy zatrudnić nowego pracownika – grafika. Czyli w organizacji ‚Billennium’ potrzebujemy aplikacji ‚System HR’, która będzie obsługiwała sprawę ‚Kandydat’. Rekrutacja kandydata składa się z kilku etapów:

  1. Zebranie informacji o kandydacie.
  2. Kwalifikacja.
  3. Rozmowa rekrutacyjna.
  4. Decyzja o zatrudnieniu.

Natomiast etapy składają się z kroków. Na potrzeby tego przykładu zajmijmy się etapem ‚Kwalifikacja’. W jego skład wchodzą następujące kroki:

  1. Dodanie portfolio – jest to przypisanie, czyli pojedynczy formularz, na którym kandydat zamieszcza swoje portfolio.
  2. Ocena kwalifikacji – to już kolei proces, na który składa się ocena kwalifikacji kandydata przez kilku pracowników i wystawienie przez nich opinii.

Mam nadzieję, że niniejszy artykuł pomoże w zrozumieniu założeń jakich używa PEGA w ramach swojego BPM.

Polecam także artykuł „Zmiany w PEGA 7.2”

PEGA

Jeżeli polubiłeś ten artykuł. Zobacz również:

Szybki kontakt

Billennium Warsaw
pokaż kontakt

Billennium w Lublinie
pokaż kontakt

Billennium Łódź
pokaż kontakt

Billennium Olsztyn
pokaż kontakt

Billennium Bytom
pokaż kontakt

Billennium India Private Limited
pokaż kontakt

Billennium Inc.
pokaż kontakt