Kluczowe dane procesu

Kilkakrotnie w ramach swoich wpisów posługiwałem się pojęciem słownika danych będącego podstawą do reprezentacji danych dla procesu biznesowego, do jego realizacji, jak i oceny. Taki słownik definiuje poszczególne typy danychwystępujące w procesie, opisuje ich zastosowanie oraz reprezentację.

Poniższy przykład na diagramie (w BPMN) prezentuje zastosowanie różnych typów danych.

Rozróżniane są:

• dane kluczowe (ang. key data) – np. ID klienta czy produktu, dla którego realizowany jest proces. Na powyższym diagramie jest to IDProduktu oraz można również powiedzieć, że IDKlienta, ponieważ bez tych dwóch identyfikatorów nie da się przeprowadzić procesu.
• dane zawartości (ang. content data) – są dane przesyłane między usługami, przekazywane między kolejnymi krokami procesu, będace uzupełnienie dla danych kluczowych. Dane te mają również znaczenie, gdy wystąpi błąd w procesie, aby poznać kontekst błędu. Są to dane kontekstowe. Na powyższym diagramie jest to np. Ilość produktu, a także dodatkowe dane pobierane z bazy.
• dane sterujące (ang. steering data) – dane, na podstawie których określany jest przebieg procesu, w szczególności na bramkach decyzyjnych. Dane sterujące są także używane przez reguły biznesowe. Na powyższym diagramie jest to FProgramu, która decuduje o wykonaniu operacji aktualizacji danych klienta w zakresie wykorzystania/udziału w programie lojalnościowym.
• dane do oceny efektywności procesu (ang. KPI data) – dane pozwalające ocenić zachowanie procesu, obciążenie pracą w poszczególnych krokach, czas wykonania, ilość itp. Nie są zaprezentowane bezpośrednio na powyższym diagramie. W omawianym przykładzie mogłyby być to dane dotyczące np. ilości przypadków realizacji programu lojalnościowego, najczęściej wybierane produkty, czas odpowiedzi usług, problemy.

Świadomość danych „używanych” w procesie, pozwala lepiej go zrozumieć i ocenić. Analiza zachowania procesu, wskaźników efektywności, czasu przebiegu, pozwala na określenie niezbędnych zmian w procesie.

Reklama

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

Trochę inna analiza procesu

W trakcie nakładania metryk na proces (np. pod kątem BPMS), przedstawiony podczas wcześniejszej analizy, używana jest analiza wejść i wyjść procesów, a także próbuje się określić krytyczne punkty procesu. W trakcie analizy przebiegu procesu określa się punkty, w których można zebrać dane do oceny procesu, jego efektywności, czasu realizacji, powtarzalności, ilości wykorzystanych obiektów. Na poniższym diagramie zaprezentowano w sposób poglądowy (uproszczony) czas przebiegu procesu – miejsce startu i końca weryfikowanego fragmentu procesu. Podobnie można określić:

• liczbę zamówień;
• liczbę przesyłek;
• wagi przesyłek (średnia, łączna, mediana)
• liczbę oczekujących zamówień (wpływających w czasie realizacji poprzedniego);
• liczbę zrealizowanych zamówień;

Na podstawie pomiaru czasu (najdłuższy, najkrótszy, średni) można policzyć ilość czasu przypadającego na zamówienie, na przygotowanie przesyłki. Można to użyć do weryfikacji, czy dostępny czas pracy, biorąc pod uwagę zatrudnionych pracowników, jest wystarczający na realizację wszystkich zamówień złożonych w danym okresie czasu.