BPML: podejście pierwsze

Cele języka BPML

Podczas tworzenia oraz rozwijania języka BPML, przez grupę BPMI, zostały postawione przed tym językiem następujące cele:

  • Połączenie i zjednoczenie integracji na poziomie zewnętrznym i wewnętrznym w odniesieniu do procesów biznesowych.
  • Konsolidacja procesów pracy zorientowanych na czynnik ludzki z procesami wykonywanymi przez maszyny.
  • Wykorzystanie rosnącego znaczenia usług sieciowych w biznesie.
  • Włączenie w procesy aktualnie wykorzystywanych przez przedsiębiorstwa systemów typu „back-office” i na odwrót, włączenie procesów pod możliwości analityczne i funkcjonalne tych systemów
  • Integracja z aktualnie występującymi i funkcjonującymi systemami typu „middleware”w przedsiębiorstwie.
  • Wspieranie zmian zachodzących w biznesie (w przedsiębiorstwie).
  • Stworzenie korzystnych warunków dla potrzeb wykonania, czy przetwarzania rozproszonego
  • Zainicjowanie zmian na rynku w kierunku tzw. rynku procesów.
  • Opieranie się na dotychczas istniejących w biznesie standardach.

Cechy BPML

Język modelowania procesów biznesowych BPML ma kilka cech szczególnych:

  • Proces jest przedstawiony w postaci kodu wykonywalnego, który jest niezależny od środowiska jego wykonania.
  • Zdefiniowany jest wzorzec (standard) dla reprezentacji procesu biznesowego.
  • Procesy są jasne, co otrzymuje się dzięki jednoznacznej definicji jego elementów i możliwości ich wykorzystania w procesie.
  • Język nie posiada zdefiniowanej semantyki specyficznej dla danej dziedziny.
  • Język pozwala na wyrażenie procesów współpracy między obiektami biznesowymi – interfejs procesu.
  • Obsługa uczestników różnego typu.
  • Język posiada możliwość tworzenia procesów abstrakcyjnych.
  • Proces pozwala na rozdzielanie różnego typu relacji zachodzących w procesie (systemowe od biznesowych)
  • Procesy mogą być modyfikowane „w locie”.
  • Język posiada wsparcie w postaci graficznej reprezentacji BPMN.
  • Elastyczność języka pozwala na odzwierciedlanie w procesie realiów świata rzeczywistego

BPML i słownik procesu

BPML, czyli Business Process Modeling Language, jest językiem bardzo elastycznym i o szerokim zastosowaniu. Cechy te wynikają z dwóch faktów. Po pierwsze z tego, że jest oparty na XMLu. Po drugie, ponieważ zawiera tzw. słownik procesu (ang. vocabulary of process).

Słownik procesu zawiera definicję znaczników, określeń, atrybutów, słów kluczowych, definicji przystosowanych do modelowania procesów biznesowych z danej dziedziny.

Można powiedzieć, że BPML jest metajęzykiem.

BPML pozwala na uwzględnienie w procesie następujących aktorów:

  • Ludzie i ich organizacje, przedsiębiorstwa.
  • Systemy komputerowe,
  • Aplikacje,
  • Maszyny,
  • Dane, informacje i wiedza (są one zarówno przedmiotem, jak i w pewnym sensie podmiotem procesu)
  • Rynki (internetowe, wirtualne) – w szczególności w przypadku relacji B2B oraz B2C.

Powyżej wymienieni uczestnicy procesów mogą wchodzić między sobą w różne interakcje – biznesowe oraz systemowe.

Dlaczego powstało BPMN/BPML?

Wiele stosowanych współcześnie narzędzi służących do analizowania procesów biznesowych oraz ich reprezentacji za pomocą odpowiednio skonstruowanych diagramów, jest oparte od jakiegoś czasu na wspomnianych wcześniej diagramach przepływu (ang. Flow charts). Jednakże trzeba podkreślić, że możliwości reprezentacji procesów biznesowych za pomocą tych diagramów są bardzo ograniczone.

Ograniczeniem najbardziej widocznym jest to, że pozwala na reprezentację tylko jednego procesu, bez połączeń z innymi procesami. Bardzo rzadko się zdarza, aby procesy istniał niezależnie, sam w sobie, bez żadnych powiązań z innymi procesami. Z tego punktu widzenia jest to wada. Możemy jednak spojrzeć na to również inaczej… Dla osób ze szczebla kierowniczego, dla których potrzebny jest całościowy wgląd w proces, jest to rozwiązanie proste i pozwalające na znalezienie szybkiego porozumienia między menedżerami a projektantami procesów. Widzą jeden proces zapisany za pomocą jednoznacznych symboli graficznych. Nie muszą zagłębiać się w dokumentację, czy wyjaśnienie poszczególnych powiązań. Trzeba jednak to powiedzieć, że ciężar implementacji uwag menedżera spadał na projektantów procesów. W tym momencie, mógł się pojawić problem błędnej interpretacji zmian i ich niewłaściwe naniesienie na diagram procesu.

W związku z powyżej zarysowaną sytuacją, odpowiednie podmioty rozpoczęły prace nad nowymi metodami modelowania i reprezentacji procesów biznesowych. Celem tych prac było stworzenie metody o różnorodnym zastosowaniu i przeznaczonym dla różnych odbiorców. Dodatkowo oczywiście, język musiał być możliwy do przeniesienia na poziom maszynowy.

Jedną z grup pracujących nad taką metodą była grupa Business Process Modeling Inititiative (BPMI) http://www.bpmi.org

Grupa ta stworzyła notację Business Process Modeling Notation (BPMN), która jest graficznym odpowiednikiem dla języka Business Process Modeling Language (BPML).

Elementy procesu

W wielu publikacjach dotyczących modelowania procesów biznesowych, ich reprezentacji, analizy i przygotowania do ich zmiany, pojawia się sformułowanie języka do modelowania wielowymiarowego dla procesów biznesowych (ang. multi-view process modeling language). Założeniem tego podejścia jest przedstawienie procesu z różnych perspektyw w taki sposób, aby łatwo było je porównywać, tworzyć powiązania. Proces jest traktowany jako bardziej klasa procesu niż jego reprezentacja w maszynowej postaci (np. za pomocą BPML).

Elementami takiej reprezentacji procesu, a bardziej modelu procesu są:

  • tzw. artefakty (ang. artifacts), czyli obiekty, które proces tworzy, modyfikuje lub wykorzystuje podczas swojego przebiegu. Mogą to być obiekty/dane wejściowe, wyjściowe, a także obiekty stosowane tymczasowo wewnątrz przebiegu procesu. Są używane przy wykonywaniu kroków/czynności procesu.
  • tzw. aktywności/czynności (ang. activities), czyli rzeczywiście wykonywane działania w ramach realizowanego procesu. Pewne zadania mogą przyczyniać się do wzrostu wartości produktu procesu, a inne są niezbędne dla interesariuszy procesu . O tym elemencie procesów pisałem wielokrotnie na swoim blogu, z różnych perspektyw.
  • tzw. agenci/uczestnicy procesu (ang. agents), czyli wykonawcy kroków procesu lub osoby zainteresowane jego przebiegiem.
  • tzw. role (ang. roles), czyli obowiązki lub uprawnienia przypisane do uczestników procesu podczas jego wykonywania.
  • tzw. zasoby (ang. resources), czyli narzędzia, aplikacje, systemy lub inne środki, które wspierają, umożliwiają realizację procesu. Mogą to też być środki pozwalające na automatyzację lub przyspieszenie wykonywanych czynności.

Zadanie: Reguła biznesowa

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ę.

„Świąteczne” procesy – inna perspektywa

Dziś będzie trochę nietypowo. Co dopiero minął świąteczny czas – przygotowania, świętowanie, odpoczynek itd. W czasie tego czasu, wielokrotnie były przygotowywane listy – zakupów, składników, potraw do wykonania, gości, prezentów, czy postanowień noworocznych. W szczególności przygotowywane były ciasta – sprawdzony przepis, lista składników, pieczenie. Prawie każdy wypiek można sprowadzić do takich czynności jak: przygotowanie składników, przygotowanie ciasta, przygotowanie nadzienia, dodanie nadzienia (czy to bakalii do keksa czy maku do makowca), pieczenie, chłodzenie, dekorowanie (np. lukrem) oraz jedzenie.

Wykonując te czynności nawet się nie zastanawiamy, że one mają charakter mniej lub bardziej skomplikowanego procesu, w który zaangażowani są ludzie oraz maszyny (które jak najbardziej mogą być uczestnikami procesu). Idąc dalej można powiedzieć, że pewne czynności mają charakter sekwencyjny a pewne synchroniczny.

Diagram w BPMN przedstawia ten prosty proces przygotowania ciasta.

Zastanówmy się nad cechami tego procesu:

  1. zorientowany na wykonanie zadania, czyli upieczenie ciasta
  2. wykonywany zgodnie z procedurą, czyli przepisem zawierającym informację o kolejnych czynnościach, wyborach,
  3. wykonanie kolejnych czynności oznacza postęp procesu, przybliżenie do efektu końcowego,
  4. może zostać wykonany przez dwie osoby, jedna osoba przygotowuje ciasto, a druga równocześnie przygotowuje nadzienie
  5. wiadomo, który uczestnik jest za co odpowiedzialny.
  6. czynności do wykonania są znane, czas oczekiwania na wyrośnięcie oraz pieczenie również, co pozwala na ustalenie kolejności oraz momentu rozpoczęcia poszczególnych czynności,
  7. po upieczeniu ciasta, przechodzi się do innych zadań związanych ze świętami, proces nie jest powtarzany,
  8. czynności są ze sobą powiązane czasowo,

Wymienione cechy pozwalają na określenie rodzaju procesu, jego perspektywy. Można rózróżnić proces sekwencyjny (określane także jako diachronic) oraz synchroniczny (synchronic). Cechy (1), (2). (3), (5), (6), (7) są właściwe dla procesów sekwencyjnych. Pozostałe dwie – (4) oraz (8) – dla procesów synchronicznych. O dokładnym rozróżnieniu można poczytać w standardzie konsorcjum SCIPIO.

Ciekawą cechą jest (6). Jest ona istotna dla procesów workflow (strumieni pracy), gdzie lista zadań jest wykonywana w określonej kolejności przez określonych uczestników.

Założenia procesu – warstwa reinżynierii

Załóżmy, że:

  • mamy wdrożyć rozwiązanie informatyczne do obsługi dla procesu sprzedaży produktu przez internet;
  • w przedsiębiorstwie istnieją systemy zarządzania relacjami z klientem, zarządzania łańcuchem dostaw
  • proponowane rozwiązanie ma zintegrować różne systemy występuje w przedsiębiorstwie

W takiej sytuacji analizę można rozpocząć od odpowiedzi na następujące kategorie pytań:

  • Jakie udogodnienia oferowane są dla klienta?
  • W jaki sposób firma chce wspomagać decyzje klienta?
  • Jaki są cele firmy oraz procesu?
  • Z jakich źródeł danych proces może, ma, musi korzystać?
  • Jakie systemy informatyczne będą wykorzystywane w procesie?
  • Jakie informacje firma posiada o rynku, o klientach, jakie informacje potrafi zdobyć?
  • Jakie znaczenie ma dany proces wśród procesów przedsiębiorstwa?

Można zadawać kolejne pytania. Celem ich jest ustalenie tzw. kontekstu procesu (który docelowo przyczynia się do stworzenia tzw. słownika procesu). Uzasadnieniem tego faktu jest to, iż odpowiedzi na powyższe pytania są uzależnione od gałęzi/dziedziny gospodarki, w którym ma miejsce dana sprzedaż, czy obsługa klienta. Innego typu zależności będą występować w przypadku sprzedaży elementów wyposażenia mieszkania, a inne w przypadku przemysłu spożywczego.

Prowadząc taką analizę, poruszamy kwestie dotyczące dwóch warstw procesu. W przypadku założonego procesu, warstwa reinżynierii mogłaby w skrócie przebiegać następująco:

  1. Zapoznanie się z ofertą/produktami
  2. Wybranie produktu i złożenie zamówienia
  3. Przekazanie oraz przetworzenie zamówienia
  4. Sprawdzenie możliwości realizacji zapłaty
  5. Sprawdzenie możliwości dostarczenia produktu
  6. Ustalenie sposobu/miejsca dostarczenia
  7. Realizacja zamówienia
  8. Obsługa posprzedażna oraz transakcje powiązane

Trochę o notacji BPMN

BPMN jest metodą bazującą na technikach wykorzystywanych w diagramach przepływu, która pozwala tworzyć diagramy procesów biznesowych. Notacja BPMN posiada skończony i jednoznacznie zdefiniowany zbiór elementów graficznych, które pozwalają na budowanie diagramów zrozumiałych zarówno przez projektantów procesów, analityków, jak i kadrę zarządzającą.

BPMN „spełnia” zasady tworzenia metamodeli dla języków modelowania procesów biznesowych, przez co jest bardzo elastycznym narzędziem. Diagram może być zmieniany na każdym etapie życia procesu: od stworzenia, poprzez rozwój, wykonanie, monitorowanie i analizę procesu.

W przypadku notacji BPMN należy podkreślić następujące zalety:

  • Czytelność – graficzna reprezentacja jest bardziej zrozumiała niż kod języka, np. xml, na którym jest oparty język BPML.
  • Jednoznaczność – wynika to z definicji pojęć i postaci elementów graficznych w notacji. Jest zrozumiała dla różnych grup odbiorców.
  • Elastyczność – możliwość zastosowania do różnego typu procesów.
  • Możliwość zapisu diagramu w języku BPML.