Czy RODO wpływa na BPR?

Dwanaście lat temu, dokładnie 9 lutego 2008, we wpisie na moim blogu, wymieniłem kroki składające się na proces reengineeringu (tj. reinżynierii procesów biznesowych, w skrócie BPR). W powiązanych wpisach opisałem, wykorzystując również dostępne publikacje w tym temacie, z czego składają się wybrane kroki tego działania. Natomiast część kroków pozostawiłem bez rozbudowanych wyjaśnień. Wspomniany proces reengineeringu ma na celu przebudowę/zmianę procesu, która odbywa się w oderwaniu od obecnego przebiegu procesu. Takie podejście ma na celu stworzenie procesu, który spełnia oczekiwania jego odbiorców, realizuje potrzeby podmiotu oraz adresuje w odpowiedni sposób kwestie, które dotychczas nie zostały wzięte pod uwagę. Przypomnijmy jakie kroki zawiera to działanie – przedstawione w postaci procesu na diagramie poniżej.

Podczas przygotowania odpowiedzi na pytanie postawione w tytule, trafiłem na ciekawy artykuł, który idealnie podsumowuje kroki, które należy wykonać, aby przejść przez proces dostosowania organizacji do RODO. W artykule jest informacja że „te wymagania dotyczące zgodności [mój dopisek: chodzi o RODO] mogą stymulować inicjatywy związane z przeprojektowaniem procesów biznesowych”, czyli wspomnianym reengineeringiem.
Autor artykułu wymienia 6 kroków, które powinny podjąć organizacje, podmioty czy przedsiębiorstwa w momencie, gdy dostosowują się do wymogów RODO (GDPR).

rodo_bpr_550px

Autor artykułu zwraca uwagę zarówno na aspekt budowy świadomości, zmiany kultury, zarządzania, jak i na kwestie samego procesu dostosowania. Sam proces dostosowania jest rozbity, trochę to upraszczając, na identyfikację danych, identyfikację przepływów oraz na zmianę kluczowych polityk i procesów. Właśnie tym 3 krokom składającym się na proces dostosowania chciałbym się bliżej przyjrzeć w kontekście reengineeringu. Dlaczego? Ponieważ efekty identyfikacji danych i przepływów mogą wpłynąć na decyzję o tym, jaki proces wybierzemy do reengineeringu a potem na dalsze kroki realizowane w ramach tego działania. Przyjrzę się teraz bliżej tym 3 krokom wskazanym w artykule i spróbuję (mam nadzieję, że w poprawny sposób) je odnieść do kroków reengineeringu – podsumowanie takiego odniesienia (w poniższych wyjaśnieniach takie elementy są podkreślone) znajduje się również na diagramie:

  • Identyfikacja danych/Zestawienie danych w przedsiębiorstwie (odpowiednik „Catalogue data across the enterprise z artykułu”) – sprowadzając to do kroków reengineeringu, możemy podczas wyboru procesu zdecydować się na ten, w którym przetwarza się najwięcej danych osobowych lub/i który został oceniony jako (najbardziej) problematyczny pod względem zgodności z RODO (co się wpasowuje moim zdaniem w punkt „dotyczący skali problemów powodowanych przez proceswymieniony w książce, o której piszę w jednym z wcześniejszych wpisów). Podczas analizy procesu możemy zwrócić uwagę na to jakie rodzaje danych występują lub nawet mogą być nadmiarowe w określonych krokach lub czy same czynności przetwarzania nie są zbyt rozbudowane a może dane są za długo przechowywane. Warto też przyjrzeć się uczestnikom procesu i ich potrzebom w zakresie danych. Odnosząc się do regulacji RODO, można jeszcze postawić wiele innych pytań. Myślę jednak, że już te wskazane pytania dają podstawy do głębszej analizy procesu. Celem działania jest określenie potrzeb i oczekiwań odnośnie docelowego procesu.
  • Identyfikacja przepływów/Zweryfikuj przepływy danych w ramach przedsiębiorstwa (odpowiednik „Audit data flow across the enterprise” z artykułu) – podczas analizy procesu możemy spojrzeć na proces z perspektywy danych, które przepływają między jednostkami przedsiębiorstwa. Wyobraźmy sobie, że proces jest oparty o system i uczestniczą w nim co najmniej 2 jednostki biznesowe. Wykonują one różne zadania, ale mają dostęp do tych samych danych. Wg RODO w danym momencie użytkownik powinien mieć dostęp do danych, które są mu rzeczywiście potrzebne. W zależności od sytuacji, trzeba pogłębić temat lub odnotować ten fakt w wynikach analizy/rekomendacjach. Angażując różne jednostki kontrolne, regulacyjne, wspierając się specjalistami ochrony danych (na przykład włączając ich do zespołu), przedsiębiorstwo może wybrać określoną strategię postępowania w samym procesie i określić jakie dodatkowe działania należy podjąć, aby uniknąć problemów w przyszłości. Opiekun czy właściciel procesu może tutaj odegrać ważną rolę, ponieważ z założenia zna oczekiwania odnośnie procesu i jego dotychczasowy przebieg, a także związane z nim regulacje.
  • Utwórz lub popraw kluczowe polityki i procesy (odpowiednik „Create or improve key policies and processes” z artykułu) – w ramach reengineeringu budujemy nowy proces. Jest to szansa aby spojrzeć na dane wykorzystywane w tym procesie z nowej perspektywy i zmienić sposób ich wykorzystywania. Podczas uwzględniania aspektu RODO może się okazać, że dla procesu trzeba dobudować lub podłączyć (istniejące lub nie) dodatkowe podprocesy lub procesy powiązane, które będą adresować specyficzne sytuacje. Może się także okazać, że w nowym procesie dane można ograniczyć do minimum i uprosić proces także z perspektywy jego odbiorcy. Budując nową wersję procesu konieczne jest także spojrzenie na obowiązujące regulacje oraz polityki postępowania związane z procesem. One także muszą zostać odpowiednio przebudowane, z zachowaniem zgodności z wprowadzonymi przez organizację procesami ochrony danych osobowych czy dedykowanymi politykami w tym zakresie.

Mam nadzieję, że udało mi się trochę przybliżyć ten wpływ RODO na BPR.  Sama odpowiedź na pytanie postawione w tytule jest jak najbardziej twierdząca. Tak jak wskazuje wspomniany artykuły może wręcz się przyczynić do rozpoczęcia takich działań lub nawet ich przyspieszenia.


Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

RODO a procesy

Przez ostatni miesiąc pewnie wielu użytkowników poczty elektronicznej otrzymało po kilka, kilkanaście, a może kilkadziesiąt wiadomości, które zaczynały się od słów lub były zatytułowany w stylu: „zmiana regulaminu”, „to kolejna wiadomość”, „ważna zmiana”, „Od 25 maja…”, „Ochrona danych osobowych” i wiele innych. Częścią wspólną tych wiadomości, pochodzących z różnych sklepów internetowych, serwisów, stron internetowych, było odniesienie do RODO. Takie cztery litery pojawiały się w tytule lub samej treści.

RODO to unijne rozporządzenie dotyczące ochrony danych osobowych, w zakresie ich przetwarzania oraz przepływu. Rozporządzenie weszło w życie 25 maja 2018 i jak najbardziej dotyczy procesów, zarówno biznesowych, jak i tych technicznych związanych z przetwarzaniem danych.

Wyobraźmy sobie, że mamy proces biznesowy, który zbiera dane osobowe a który można uogólnić do trzech poniższych kroków: Zebranie danych, Zapisanie danych, Wykorzystanie danych.

process_rodo_1_450px

W każdym z tych kroków w jakiś sposób RODO dotyka takiego procesu:

  • zebranie danych – osoba, której dane dotyczą musi otrzymać informację o tym dlaczego zbierane są dane i jakie z tego tytułu posiada ona uprawnienia – takie zapisy  już funkcjonują w wielu formularzach czy regulaminach obecnie, choć w wyniku wejścia Rozporządzenia  mogły już zostać uszczegółowione/zmienione, co wynikało z ich aktualnego brzmienia oraz z powiązań z innymi dokumentami (np. Regulaminem);
  • zapisanie danych – w tym wypadku z perspektywy RODO jest istotna świadomość tego jakie dane zbieramy, gdzie je składujemy, kto jest administratorem oraz kto może z nich skorzystać. RODO wprowadza lub wskazuje jeszcze wiele zasad (które wyjaśnia ustawa, rozporządzenie, publikacje czy też regulaminy stosowane przed podmioty);
  • wykorzystanie danych – RODO zwraca uwagę na to, aby ich wykorzystanie było uzasadnione (nie będę wchodzić w szczegóły co to znaczy) oraz zgodne z tym, co zakomunikowaliśmy osobie, które dane dotyczą (zainteresowanych co to znaczy odsyłam do właściwych publikacji dotyczących RODO).

„Skutki” ochrony danych

Jeden z sobotnich poranków, sprawdzam prywatną pocztę i wśród wiadomości znajduję zatytułowaną w następujący sposób: „Komunikat ws. naruszenia ochrony danych osobowych” (więcej o takich komunikatach można znaleźć w sieci Internet) . W pierwszym momencie zrobiło mi się gorąco, bo tego się nie spodziewałem i może to być problem, w zależności od tego, który podmiot wysłał taką wiadomość (w domyśle jakimi danymi dysponował). Spojrzałem na nadawcę i trochę się uspokoiłem. Pierwsze pytanie, które sobie zadałem: „Kiedy korzystałem z tego serwisu?”. Na pewno dawno (po sprawdzeniu okazało się, że kilka lat temu), więc czytam już spokojnie całą wiadomość. Wiadomość można streścić w 5 punktach (więcej o takim zawiadomieniu można znaleźć na stronie UODO):

  1. co się stało? czyli opis sytuacji;
  2. co to może oznaczać? czyli konsekwencje. Przy tym punkcie postanowiłem, że sprawdzę jakie moje dane mają, zmienię hasło dostępu oraz wyślę prośbę o usunięcie konta.
  3. co zrobili i co planują zrobić? To, co przeczytałem wzbudziło mój niepokój ale mnie nie zaskoczyło, bo te elementy znam już z artykułów związanych z RODO (o kilku kwestiach pisałem też na blogu).
  4. co mogę zrobić po swojej stornie? Informacje odnosiły się bardziej do sugerowanych reakcji, gdy jednostka/osoba, która weszła w posiadanie moich danych, zaczęła je wykorzystywać. Utwierdziłem się w przekonaniu co do akcji, które chciałem podjąć. Dodatkowo zdecydowałem się na zarejestrowanie się w BIK, co wskazywał jeden z punktów.
  5. dodatkowe informacje. Można powiedzieć, że przyjąłem do wiadomości.

Wykonałem akcje:

  • [grupa A na diagramie:] sprawdziłem jakie dane podałem – na szczęście nie podałem PESEL, serii dowodu osobistego oraz innych specyficznych danych. Dane były bardzo ograniczone (uff!) i błędnie sformatowane ze względu na wprowadzone zmiany w systemie.
  • [grupa A na diagramie:] zmieniłem hasło. Nigdy nie zaszkodzi.
  • [grupa A na diagramie:] wysłałem prośbę o usunięcie konta w serwisie ze wszystkimi danymi powiązanymi (bo takiej opcji nie ma w samym serwisie) – nie jest mi potrzebny dostęp do tego serwisu i nie mam żadnych aktywnych usług/transakcji/opcji. Konto zostało usunięte.
  • [grupa B na diagramie:] zapoznałem się z informacjami na stronie BIK, a następnie zarejestrowałem się w serwisie.

Powyższy diagram prezentuje wykonane ścieżki postępowania. Rozpoczyna się od zdarzenia inicjującego opartego o komunikat (message event). Następnie przybliża ścieżkę weryfikacji danych, zmiany hasła, prośby o usunięcie konta, a następnie rejestracji w BIK.    

Wskazany proces rejestracji w BIK (link znalazłem po przygotowaniu powyższego diagramu) jak widać ma dużo elementów mających na uwadze bezpieczeństwo danych oraz jednoznaczne potwierdzenie tożsamości. Samo potwierdzenie rejestracji jest wieloetapowe – trzeba zrobić przelew weryfikacyjny (na przykład korzystając z płatności online), dane przelewu muszą się zgadzać z wprowadzonymi danymi, trzeba wykonać kroki z wiadomości wysłanej na wskazany e-mail, po drodze dostajesz specjalny kod na wskazany numer telefonu i go podajesz podczas ustalania hasła, a potem trzeba zalogować się dodatkowo podając PESEL w formie maskowanej. Czułem, że podmiotowi zależy na ochronie moich danych przy równoczesnym zabezpieczeniu się przed nieuprawnionym dostępem do nich.

Po otrzymaniu takiej wiadomości, mamy jakieś opcje, aby upewnić się czy nasze dane nie zostały wykorzystane lub jak poznać, że zostały wykorzystane lub też co możemy zrobić, aby się ustrzec przed takim ryzykiem w przyszłości (wiadomość wskazywała takie opcje, można też znaleźć takie informacje w dedykowanych artykułach). Wiele zależy od rodzaju danych, które wpadły w niepowołane ręce. Im ich więcej lub/i bardziej detaliczne, to można powiedzieć, że ryzyko jakiś niechcianych zdarzeń, z perspektywy ich właściciela, rośnie.

Dobrze zawsze się zastanowić czy udostępniane dane (wprowadzane podczas rejestracji lub przy innej okazji) pasują do działań/operacji możliwych do wykonania w serwisie lub w danej funkcjonalności/procesie. Jeżeli na przykład w serwisie będzie tylko korzystać z publikacji wewnątrz serwisu, podawanie numeru PESEL czy dowodu osobistego nie wydaje się uzasadnione. Z kolei, gdy zamierzamy podejmować zobowiązania wymagające jednoznacznego potwierdzenia tożsamości, brak podania takich danych może uniemożliwić skorzystanie z takich usług online czy nawet stacjonarnie. O przykładzie nadmiarowych danych podczas zgłoszenia reklamacji pisałem w innym wpisie.

Gdy aplikacja pamięta Twój telefon

Wczoraj otrzymałem maila o tytule „Próba logowania przy użyciu nieznanego urządzenia”. W pierwszym momencie zacząłem się zastanawiać… Czy ktoś loguje się moimi danymi, a może ktoś się pomylił… Przeglądając jednak treść wiadomości zauważyłem oznaczenie aplikacji, która wygenerowała taką wiadomość. Zainstalowałem na nowym telefonie aplikację (jednego ze sklepów stacjonarnych wraz ze sklepem internetowym), którą miałem także na starym telefonie. Podczas próby zalogowania się pomyliłem się i pewnie aplikacja zidentyfikowała, że logowanie nastąpiło po przerwie, ale z innego urządzenia. Sprawdziłem w regulaminie aplikacji, że oprócz podawanych świadomie danych przez użytkownika, zapisuje ona również numer używanego urządzenia mobilnego. Element ten widocznie pozwala na rozróżnienie, że użytkownik, który próbuje się zalogować użył innego urządzenia. Regulamin wskazuje po co zbiera tę informację i jawnie o tym informuje.

Na poniższym diagramie w BPMN, będącym moim wyobrażeniem procesu występującego w takiej aplikacji na bazie obserwacji aplikacji/narzędzi, z których korzystam, są wskazane kroki (na zielono), które w tle identyfikują urządzenie użytkownika i następnie w przypadku poprawnego logowania zapisują te dane. W przypadku nieudanego logowania, używa tych danych do weryfikacji zgodności urządzenia z poprzednio stosowanym. Taki mechanizm, stosowany także przez inne narzędzia, pozwala podnieść bezpieczeństwo logowania, chronić dane osobowe. Wykonuje to przez każdorazowe informowanie użytkownika na podany podczas rejestracji adres e-mail co najmniej o tym, że nastąpiła jakaś nieudana próba logowania (ścieżka (1) na diagramie).

Niektóre narzędzia/aplikacje wysyłają powiadomienie o poprawnym logowaniu, które nastąpiło z innego urządzenia niż dotychczas (ścieżka (3) na diagramie). W podanym przykładzie nastąpiło wejście do aplikacji, ale nie musi to nastąpić – zależy to od sposobu zbudowania aplikacji i przyjętych założeń. Może być tak, że najpierw użytkownik musiałby potwierdzić, że to on się logował. Na diagramie zostały zaznaczone obydwie takie opcje obok ścieżki gdy dane poprawne logowanie odbywa się z tego samego urządzenia co dotychczas (ścieżka (2)).

dane_logowania_430px

Powyższy przebieg procesu został zasygnalizowany przy użyciu odpowiednich elementów BPMN, przy czym:

  • (oznaczona przez (A)) do przeprowadzenia równoczesnej identyfikacji urządzenia oraz identyfikacji użytkownika pod kątem późniejszej autentykacji  użyto bramek rozdzielających i łączących dla ścieżek równoległych (ang. paralel gateway).
  • (oznaczona przez (B)) do podjęcia decyzji są użyte bramki oparte o dane, w których tylko jedna ze ścieżek jest możliwa (ang. exclusive).

Użytkownik otrzymując taką wiadomość (kroki oznaczone na żółto na diagramie) może zadecydować czy jest to sytuacja, o której wie, czy może jest to sytuacja, na którą powinien zareagować. Na przykład nie używał aplikacji danego dnia lub w ostatnim czasie, a nagle otrzymuje informację o próbie zalogowania nieudanego lub udanego.

Jeżeli dane narzędzie/aplikacja ma taką obsługę logowań, to widzę 2 możliwości:

  • Twórca/Właściciel narzędzia równocześnie zapewnia narzędzia wspierające obsługę reakcji użytkownika (np. tymczasowa blokada użytkownika, kontakt z twórcą/właścicielem lub inne) lub
  • Mechanizm ma tylko charakter informacyjny i użytkownik na własną rękę musi poszukać metod reakcji (np. zmienić hasło).

Myślę, że to dobrze, że istnieją takie mechanizmy. Dzięki takim rozwiązaniom mamy większą pewność, że nasze dane, przechowywane w aplikacji, nie zostaną podejrzane przez nieuprawnioną osobę lub też dowiemy się szybko o tym, że ktoś taką próbę wykonał. Patrząc na serwisy, aplikacje dostępne z różnych urządzeń, jest to duże ułatwienie oraz wsparcie w zakresie realizacji wskazówek dotyczących bezpiecznego korzystania z aplikacji mobilnych (opublikowanych na stronach urzędowych).

Użytkownik otrzymując taką wiadomość w sytuacji, gdy określa ją jako wymagającą zareagowania, powinien zastanowić się jakie dane podał w danej aplikacji – ograniczoną liczbę informacji (np. tylko e-mail) czy dane generujące dla ich właściciela duże ryzyko (np. dane pesel, adres zamieszkania, numer dowodu wraz z wizerunkiem czy danymi finansowymi). Mam nadzieję, że nikt z czytelników mojego bloga nie doświadczył tego bardziej ryzykownego wariantu.


Przypominam o możliwości wypełnienia anonimowej ankiety dot. mojego bloga – https://www.surveymonkey.com/r/LVC5B59. Wypełnienie ankiety to tylko kilka minut. Zachęcam do tego.

Obowiązek dla właściciela procesu?

„…może być wykorzystana w celu stworzenia dokumentacji, której celem będzie wykazanie zgodności realizowanych procesów przetwarzania z wymaganiami RODO. Obowiązek wykazania przestrzegania stosowania przepisów RODO wynikający z art. 24 RODO nie określa bowiem w jaki sposób, poprzez jakie dokumenty, czy inne instrumenty zarządzania powinien być zrealizowany. Przepis art. 24 RODO stanowi jedynie, że administrator ma wykazać, że wdraża odpowiednie środki techniczne i organizacyjne, aby przetwarzanie odbywało się zgodnie z RODO.” oraz „...podejmowanie działań zapewniających, że osoby zaangażowane w proces przetwarzania informacji posiadają stosowne uprawnienia i uczestniczą w tym procesie w stopniu adekwatnym do realizowanych przez nie zadań oraz obowiązków mających na celu zapewnienie bezpieczeństwa informacji…” – są to dwa fragmenty artykułu ze strony Urzędu Ochrony Danych Osobowych mówiące o dokumentacji przetwarzania danych osobowych zgodnie z RODO.

Czytając ten artykuł zacząłem się zastanawiać czy przypadkiem z powodu obowiązywania rozporządzenia RODO nie pojawiają się dodatkowe obowiązki dla właściciela procesu. Samo sformułowanie właściciela procesu nie pojawia się w ustawie (o ile dobrze zweryfikowałem). Występują sformułowania odnoszące się do administratora danych, do jednostki przetwarzającej dane oraz rejestru czynności przetwarzania.

Temat wpływu RODO na procesy biznesowe już opisywałem w innym wpisie, niedługo po wejściu ustawy w życie, a był to okres kiedy podmioty funkcjonujące na rynku wysyłały do swoich klientów stosowne klauzule informacyjne. Wskazałem tam takie aspekty jak zebranie danych, zapisanie danych oraz wykorzystanie danych (co zasygnalizowałem również na poniższym diagramie). Są to elementy procesów, np. zamawiania w internecie lub innych, których kształt oraz rozwój określa właściciel procesu wraz z interesowanymi stronami. Przypomnę, że jednym z punktów było odpowiada za zgodność procesu z oczekiwaniami biznesowymi, co wydaje się oczywiste.

rodo2_450px

Działanie różnych procesów biznesowych, opartych o dane Klientów w nich uczestniczących, jest uzależnione także od innych aspektów – takich jak bezpieczeństwo procesu (w sklepie, z którego korzystam, regulamin to precyzuje), ryzyko procesu czy zgodność procesu z regulacjami obowiązującymi dany podmiot (regulamin sklepu, z którego skorzystam, ma takie zapisy, precyzujące z jakimi ustawami jest zgodny). W zależności od ustaleń i zasad stosowanych w danym podmiocie, można powiedzieć, że na jednostce rozwijającej, utrzymującej lub opiekującej się procesem, leży obowiązek spełnienia tych wymogów. Można uogólnić, że to właściciel procesu powinien odpowiadać za zgodność procesu z wymogami regulacyjnymi, w tym z RODO.  Wskazanie właściciela procesu wydaje się tutaj uzasadnione.

Dlaczego? To właściciel procesu ma (powinien mieć?) najlepszą wiedzę o tym jakie są kroki procesu oraz jakie elementy w procesie są pozyskiwane od Klienta (zasygnalizowane na diagramie). W momencie konieczności zebrania dodatkowych poświadczeń lub danych od Klienta, to właściciel procesu inicjuje samodzielnie lub wspólnie z zainteresowanymi jednostkami odpowiednią zmianę techniczną, zmierzającą do osiągnięcia postawionego celu.

Wracając do cytatu, to właściciel procesu  moim zdaniem wspiera administratora danych w określeniu odpowiednich zapisów w rejestrze czynności przetwarzania oraz wyjaśnia elementy składające się na taką pozycję jak na przykład (co próbowałem także zasygnalizować na diagramie):

  • „…
  • cele przetwarzania;
  • opis kategorii osób, których dane dotyczą, oraz kategorii danych osobowych;
  • kategorie odbiorców, którym dane osobowe zostały lub zostaną ujawnione…;
  • …”

Notacja uniwersalna dla procesu

Wiele symboli, grafik, mechanizmów, które nas otacza każdego dnia jest zrozumiała niezależnie od posiadanego wykształcenia, narodowości czy wcześniejszych doświadczeń. Gdy widzimy “+” w wyrażeniu, to wiemy, że coś dodajemy do czegoś. Gdy widzimy czerwone światło na ulicy, to oznacza brak możliwości ruchu. Gdy widzimy pięciolinię to myślimy o muzyce. Podobnie jest z wieloma innymi symbolami. Symbole są mniej lub bardziej upowszechnione. Korzystanie z nich ułatwia komunikację, wymianę pomysłów oraz idei między różnymi odbiorcami. Opisane przykłady wskazują na stosowanie tzw. notacji uniwersalnej, z ang. universal notation.

upn450px

W przypadku procesów biznesowych, także istnieje taka notacja, która pozwala na zaprezentowanie przebiegu procesu w sposób zrozumiały dla większości odbiorców. Jest to tzw. Universal Process Notation, po przetłumaczeniu Uniweralna Notacja dla Procesów. W tej notacji, jak widać na powyższym diagramie są stosowane obiekty (ramki), zawierające informację o nazwie czynności oraz jej wykonawcy oraz połączenia opisujące wejścia i wyjścia poszczególnych czynności. W odróżnieniu od notacji BPMN, którą się często posługuję w ramach diagramów na blogu, zapis jest zdecydowanie uproszczony.

Na powyższym diagramie zapisałem przykładowy proces dot. kolejkowania, gdzie występowały dwie różne role – użytkownik oraz system. Produkty poszczególnych kroków były różne i można je jednoznacznie określić: Otrzymane żadanie klienta, Wypełniony formularz, Zapisane zgłoszenie, Parametry listy ustalone, Sprawa dodana do kolejki. Strzałki informują o kolejności kroków oraz kierunku przekazywania wejść. Dodatkowo mamy ponumerowane kroki, aby łatwiej było się do nich odnosić. Pozwalają też zidentyfikować pierwszy krok (proste zastosowanie uniwersalnej notacji związanej z liczbami).

Warstwy procesu

A. Tsalgatidou oraz S. Junginger w „Modelling in the Re-engineering Process” wskazują dwie warstwy procesu. Są to: warstwa reinżynierii i warstwa implementacyjna.

Pierwsza z nich – warstwa reinżynierii – określa tzw. charakter wykonania procesu. Proces jest postrzegany jako element codziennej działalności przedsiębiorstwa. Element ten jest oceniany w kategoriach kosztów (ang. costs), czasu (ang. time), przydzielonych praw (ang. laws), odpowiedzialności, wykonywanych zadań.

Druga z nich – warstwa implementacyjna – powiązana jest z takimi kwestiami jak IT, środowisko pracy. Warstwa ta zawiera w sobie zbiór elementów, które dotyczą integracji procesów z systemami przedsiębiorstwa, procedurami oraz środowiskiem pracy, siłą roboczą, posiadanymi kompetencjami do wykonywania określonych zadań.

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