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.

Pytania o kroki procesu ręcznego

Podczas wizyty w hotelu, musiałem wypożyczyć żelazko. Udałem się do recepcji. Pytam, czy jest taka możliwość? Padła odpowiedź, że tak, ale trzeba zapłacić depozyt. Powiedziałem ok. Jak się okazało, najpierw trzeba było zapłacić, podać numer pokoju, poczekać na odnotowanie w papierach wypożyczenia żelazka, założenie oznaczenia na żelazku Potem przy zwrocie  żelazka trzeba było złożyć podpis, że nastąpił zwrot depozytu i żelazka. Natomiast przy oddawaniu klucza  sprawdzają czy nastąpiło rozliczenie pokoju. Dlaczego wypożyczenia żelazka i jego zwrotu nie odnotują w systemie? Podczas wymeldowania, można byłoby sprawdzić czy nastąpił zwrot żelazka.

Opisana zmiana to przejście od procesu w pełni ręcznego (obecnie stosowanego, tzw. as-is, oznaczonego na diagramie) do procesu wspieranego systemowo lub zautomatyzowanego (docelowego, tzw. to-be, oznaczonego na diagramie). System mógłby informować przy zwrocie klucza, że nie zostało ono zwrócone.

zelazko2

Podczas wykonywania takiej zmiany, zaczynamy od analizy bieżącego procesu, jego kroków. Można np. :

Można także zadać pytania, które sugeruje autor artykułu “Avoid Pains Converting a Manual to an Automated Process”:

  • Dlaczego dany krok jest ważny dla procesu?
    Np. na powyższym diagramie jest to powiązanie pożyczonego żelazka i numeru pokoju. Jest to wykonywane poprzez wpis do rejestru. Pozwala to zidentyfikować, gdzie są żelazka, kto jeszcze ich nie zwrócił.

  • Co się stanie jeżeli nie wykonamy danego kroku?
    Np. w powyższym procesie możemy nie pobrać depozytu. Ułatwia to obsługę klienta, nie musi mieć przygotowanej gotówki.

  • Czy miałoby sens, gdyby inny uczestnik procesu go wykonał?
    np.  zamiast ręcznego sprawdzania czy zwrócono żelazko, kontrola wykonywana przez system. na diagramie tego elementu nie oznaczono.

  • Czy istnieją procedury lub regulacje, których wymaga dany krok do wypełnienia przez tego uczestnika?
    W powyższym przypadku, gdy spytałem, dlaczego tyle formalności (ponieważ wystąpiła sytuacja, że gość hotelu nie zwrócił żelazka), odpowiedź, którą usłuszałem mogłem sobie wyobrazić – każą to robimy (czyli jest jakaś procedura).

  • Jeżeli procedury decydują o pełnym wykonaniu kroku, czy mogą zostać zmodyfikowane?
    Przenesienie działań do systemu, będzie wymagać zmiany procedury. Będą wykonywane inne kroki.

  • Jeżeli krok zostanie zautomatyzowany, co jeszcze musi zostać wykonane, aby mieć pewność, że krok jest poprawnie zakończony? Jest to uzależnione od zastosowanego rozwiązania.

Odpowiedź na pierwsze pytanie, to tak naprawdę określenie czego oczekujemy od procesu i czy obecny proces spełnia nasze oczekiwania. Wykonywanie procesu w takiej formie, bez zastanowienia się, bo tak mówią procedury, można powodować zdziwienie uczestników (=klientów) procesu. Takie zdziwienie wyraziłem.

Zwinne modelowanie?

Dzisiaj chciałbym skomentować jeden z artukułów na stronie 4PM.pl. Niestety mechanizmy dostępne na stronie nie pozwalają na komentarze i wymianę doświadczeń czytelników bezpośrednio pod artykułem. Wystarczyłoby dodać opcję – podyskutuj o artykule na forum. To tak przy okazji. Przejdźmy jednak do sedna.

Autor w artykule „Zwinne modelowanie procesów biznesowych w trzech krokach”  przedstawia następujące kroki zwinnego modelowania:

  • Krok 1 – Szacowanie potrzeb organizacji
  • Krok 2 – Identyfikacja procesów biznesowych
  • Krok 3 – Uszczegółowienie procesu biznesowego

Szczerze mówiąc treść artykułu nie przekonuje mnie, że jest to zwinne (agile) modelowanie. Autor wskazuje o konieczności wykonywania iteracji w analizie, pomijaniu kwestii, które nie przyczyniają się do realizacji celu analizy. Tak jak cel pierwszego kroku jest jak najbardziej zrozumiały, gdy potrzebne jest określenie obszaru zmian, podobnie jak przypadku benchmarkingu procesów czy reinżynierii procesów biznesowych, to kolejne punkty wydają mi się niekompletne.

Po pierwsze, moim zdaniem brakuje wskazania, że przy określaniu potrzeb czy identyfikacji procesów, przed podejściem do ich opisu, sprawdzamy jaki jest stan obecny organizacji i jej procesów. Warto dodać element identyfikacji dojrzałości procesowej organizacji, tego, czy procesy są opisane, czy celem jest zmiana istniejących procesów czy ich całkowita przebudowa. Od tego zależy co tak naprawdę wykonamy w kolejnych krokach.

Pod drugie, brakuje określenia od której strony patrzymy na procesy – od wewnątrz organizacji czy do zewnątrz organizacji.

Po trzecie, organizacja może dysponować już tzw. opisem organizacji, jeżeli ma wdrożone pewne praktyki dotyczące zarządzania procesowego czy standard ISO.

Po czwarte, interesariusze powinni uczestniczyć od początku procesu w analizie biznesu. Myślę, że poszczególne etapy powinny być w jakiś sposób przedstawiane interesariuszom, co często występuje w projektach zwinnych. Podobnie cząstkowe analizy, czy kierunek zmian i budowy modelu jest słuszny i akceptowalny, także powinien zostać potwierdzony z interesariuszami. Oddawanie do akceptacji na koniec wiąże się z ryzykiem braku akceptacji i poniesienia wielu nakładów na analizę, która nie sprostała oczekiwaniom.

Myślę, że dodanie kilku dodatkowych elementów do tego „zwinnego” modelowania, mogłoby być naprawdę zgodne z ideą, jak jest modelowanie zwinne rozumiane. Na powyższym diagramie do kroków wynikających z artykułu (na niebiesko) dodałem kilka dodatkowych (na zielono) wskazanych powyżej.

Tempo realizacji reengineeringu

Wielokrotnie we wpisach skupiałem się na tematyce reinżynierii procesów biznesowych (ang. Business Process Reengineering – BPR). Zarówno w kontekście etapów realizacji, ryzyk, problemów czy komunikacji z uczestnikami procesu jak i pracownikami zmienianej organizacji. Zmiana procesów biznesowych jest często realizacją konkretnego przedsięwzięcia projektowego. Zastanówmy się jakie cechy ma taki projekt.

Wychodząc z trójkąta ograniczeń projektowych (czas, budżet, zakres). Pierwsze kryterium to czas – tak naprawdę nie jest on miarą sukcesu dla takiego projektu. Ważniejsze niż czas realizacji jest to w jakiej formie i z jakimi skutkami taka zmiana zostanie przeprowadzona. Spiesząc się można zapomnieć o uczestnikach procesu, o tym co mają do powiedzenia i bardzo łatwo można napotkać opór przeciwko zmianie. Może także umknąć jakiś szczegół procesu. Tworzone są docelowe rozwiązania i tak naprawdę od celu i zakresu zmiany zależy w jaki sposób zostanie ona przeprowadzona i ile potrwa.

Realizacja takiego projektu wymaga stopniowych kroków, najpierw diagnoza organizacji (identyfikacja procesów, analiza as-is na diagramie), potem przystąpienie do określania zmian (Propozycja to-be na diagramie) i ich impementacji (Implementacja). Konieczne jest dokładne analizowanie wszystkich sygnałów o problemach. Są to projekty drogie. Jeżeli natomiast chodzi o zakres projektu, to jest to najważniejszy element – konieczne jest dokładne określenie co i jak chcemy zmienić, zarówno w zakresie obszaru zmian, rodzaju procesów (główne, pomocnicze), .dostosowania struktury organizacyjnej, jednostek funkcjonalnej oraz obecnego działania organizacji. Realia w skrócony sposób poszczególnych części procesu obrazuje powyższy diagram.

Zgodnie z metodologią podejścia do projektów, zaproponowaną przez Aaron J. Shenhar , Dvir Dov, wyróżniamy projekty zwykłe, szybkie/konkurencyjne, krytyczne w czasie oraz błyskawiczne. Wg autorów projekt reinżynierii procesów biznesowych jest projektem zwykłym, którego głównym celem jest osiągnięcie celów długoterminowych bez presji czasowych.

Zmienny chaos

Wielokrotnie w moich wpisach pojawiał się temat powiązania zmian z różnymi elementami, takimi jak komunikacja, status, zarządzanie ryzykiem, zakres zmiany, luki w procesie itp. Starałem się przytoczyć przykłady, możliwe przyczyny, jak i zastanowić się nad rozwiązaniami. Przykłady łatwo można było sobie wyobrazić. Jednak nigdy nie skupiłem się na częstotliwości zmian w kontekście ich zakresu. Postaram się to dziś nadrobić, wspomagając sieiagramem znalezionym w prezentacji na Uniwersytecie w Eindhoven.

Autor (Wil van der Aalst) diagramu wskazuje w przyjazny sposób jaka jest zależność między częstotliwością wprowadzania zmian oraz wpływem wdrażanych zmian. Na diagramie pojawiają się dwa skróty: BPR oznaczający Business Process Reengineering (więcej o tzw. reinżynierii procesów biznesowych w wpisach z 2008 i 2010r.)  oraz CPI oznaczający Continuous Process Improvement (o czym więcej w jednym z kolejnych wpisów).

Z powyższego diagramu wynika, że jak próbuje się wykonywać zmiany często i mające duży wpływ to wtedy następuje chaos. Jest to bardzo dobre określenie sytuacji, która może nastąpić w przedsiębiorstwie. Możemy mówić o następujących obszarach problemów.

  • Ludzie – co mają robić ludzie? Jak postępować? Jakie procedury/regulacje obowiązują w danym momencie? Kto działa wg nowych zasad? Gdzie powinienem zgłaszać problemy? Z kim współpracuję?
  • Komunikacja – kiedy i jaką zmianę należy zakomunikować? Kto jest odpowiedzialny? Co, od kiedy i do kiedy obowiązuje? Czy informacja jest jeszcze aktualna?
  • Kontrola – jak skontrolować sposób postępowania? Jak sprawdzić czy procesy działają poprawnie? Co jest punktem odniesienia dla obecnego procesu? Czy dana obserwacja jest wynikiem błędnego procesu czy okresu przejściowego?
  • Dane – Gdzie są dane? Gdzie powinniśmy przechowywać dokumenty? Kto jest za to odpowiedzialny? Która baza jest źródłem danych a która jest wtórna? Jak wygląda proces przenoszenia, migracji danych?
  • Klienci – Którzy są odbiorcami produktów firmy? Jakie informacje uzyskują? Jakie są produkty, za jaką cenę i w jakim czasie mogą pozyskać? Czy otrzymują informację zgodną z komunikacją wewnętrzną? Czy wiedzą czego mogą oczekiwać? Czy sobie radzą w nowym systemie, z nowymi wymogami?

Nad taką sytuacją jest trudno zapanować, dlatego przed wdrożeniem zmian warto przeanalizować wpływ planowanej zmiany oraz termin jej wdrożenia. Mówiąc termin mam na myśli przede wszystkim to, czy zmiana nie jest realizowana zbyt wcześnie po ostatnich zmianach, czy ludziom udało się dostosować do nowych zasad. Nie będę się powtarzać, że ważna jest dwukierunkowa komunikacja (o czym pisałem w swoim artykule). Można wymieniać kolejne obszary, bardziej lub mniej szczegółowe. Jednakże mogą jedynie pokazać jeszcze większy obraz chaosu. Powyższa lista myślę, że jest wystarczająca.

Rózwój procesu jako likwidacja jego luk

W literaturze można się spotkać z przyczynowym podejściem do rozwoju przedsiębiorstwa, które skupia się na identyfikacji i rozwoju luk. Mogą to być takie luki jak na przykład:

  • luka między stanem pożądanym a rzeczywistym, patrząc całościowo na organizację;
  • luka między stanem możliwości a stanem potrzeb przykładowo w zakresie zasobów o określonym doświadczeniu, zaangażowaniu, umiejętnościach;
  • luka między posiadanymi lub pozyskanymi w przeszłości możliwościami a rzeczywistymi/realizowanymi osiągnięciami, efektami działalności, która najlepiej pokazuje, czy przedsiębiorstwo idzie w oczekiwanym kierunku, czy jego osiągnięcia sprzedażowe, inwestycyjne, w zakresie polityki społecznej itp. odpowiadają posiadanym zasobom oraz zrealizowanym przedsięwzięciom.

Spojrzenie to jest właściwe dla poziomu całej organizacji, jednakże czy nie można tego przełożyć na niższy poziom? Pojedynczego procesu? Odpowiedź jest prosta – tak, w szczególności stosując zasady benchmarkingu lub reinżynierii procesów biznesowych.

Załóżmy, że mamy fragment procesu, gdzie po zakończeniu zadania przez jednego z uczestników procesu, efekt jest „konsumowany” przez innego uczestnika w kolejnym kroku. Diagram (w BPMN) prezentuje „oficjalny” i rzeczywisty przebieg procesu z zaznaczeniem luki.

W procesie konieczna byłaby modyfikacja luki między wyjściem „X” a wejściem „Y”. Różnica wynika z założenia, że każdy z uczestników chce wykonać jak najlepiej swoją pracę, jednakże oczekiwania uczestnika o Roli Y co wejścia do swojego zadania, są różne od rzeczywistego wejścia, produkowanego na wyjściu przez uczestnika o Roli X. W procesie konieczne jest wtedy przeznaczenie czasu na wyjaśnienia lub poprawki. W ramach benchmarkingu możliwe byłoby poprawienie tego procesu – na przykład poprzez zderzenie oczekiwań obydwu stron – Roli X i Roli Y. Może efekt pracy Roli X jest spowodowany przez jakość materiału, który otrzymuje z wcześniejszych etapów procesu. Całościowa analiza pozwoli na zidentyfikowanie większości luk i określenie ich przyczyn.

Czy można pokazać więcej?

Zanim spróbuję odpowiedzieć na pytanie postawione w tytule. Kilka słów komentarza. Przyjęcie pewnych założeń – np. mamy system ERP – powoduje inne spojrzenie na prowadzoną analizę i nie pozwala w pewnych sytuacjach na znalezienie najlepszego rozwiązania, czy może zaprezentowania jak najlepiej efektu, który chcielibyśmy osiągnąć. Może aktualne mechanizmy zastosowane w systemie ERP są niewystarczające, co może być skutkiem ubocznym prowadzonej analizy. Tzw. dostosowywanie się do istniejących narzędzi powoduje, że w jakiś sposób dostosowujemy nasze myślenie, czy docelowy obraz procesów do już znanych mechanizmów. Nie pozwala na spojrzenie szersze, czy nawet wzbudzenie inicjatywy ze strony osób zaangażowanych w projekt. Mało tego czasami zdarza się, że koszty dostosowania się do istniejącego systemu są tak duże, że sam pomysł realizacji usprawnienia czy zmiany przestaje być korzystny albo nie jest wykonalny w akceptowalnym czasie. Zależności między wymaganiami/jakością, czasem realizacji oraz budżetem to już inna kwestia, nad którą nie chciałbym się teraz rozwodzić…

Tymczasem mała dygresja z innego podwórka. W bankowości bardzo często budując strategię sprzedaży staje się przed wyborem: elastyczne procesy i produkty czy standaryzacja produktów. Wydaje się może, że nie jest to kwestia powiązania, ale jak się przyjrzeć bliżej… Opis wymagań abstrahujący od sposobu wykonania, czy ograniczeń na pewnym etapie działania może przynieść w ostateczności bardziej elastyczne rozwiązanie. Stosowanie gotowego rozwiązania i trzymanie się cały czas jego wymagań jest to jakby trzymanie się/powielanie standardów postępowania. Wszystko zależy od tego, co chcemy osiągnąć.

Spójrzmy na poniższy diagram (zamieszczony na stronie it-consulting.pl/blog we wpisie „Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny”):

Diagram klas – czyli „reinżynieria” analizy biznesowej c.d. model dziedziny

 

Diagram powstał jako odpowiedź na mój diagram z wpisu o „Reinżynierii” diagramu klas. Zgadzam się z komentarzem, że mój diagram jest pewnym modelem pojęciowym. Pokazuje jednak pewne zależności między elementami i zatrzymuje się na pewnym etapie ogólności pozwalającym na dyskusję: jakie informacje są potrzebne o produktach? w jaki sposób obsłużyć płatność? czego brakuje? który element jest wykorzystywany przez użytkownika, a co dzieje się automatycznie? Itd. W kolejnych iteracjach mogły zostać dodane kolejne elementy. Zaletą moim zdaniem jest to, że abstrahuje od rozwiązania informatycznego, pokazując pewne informacje logiczne. Wadą jest to, że brakuje wstępnego opisu przypadków użycia, aby przybliżyć dziedzinę. We wpisie o dynamice próbowałem pokazać pewne zachowania, które mogą nastąpić, schodząc na niższy poziom analizy.

Na wcześniejszym diagramie  brakuje mi przestawienia tego w jaki sposób wybierane są produkty i spośród jakich produktów są wybierane. Z doświadczenia wiem, że taka informacja na etapie prezentacji analizy jest cenną informacją. W przypadku nowej aplikacji internetowej pokazuje potencjalny zakres wykorzystywanych źródeł informacji. W przypadku istniejącej aplikacji pokazuje jakie informacje będą potencjalnie wykorzystywane w interakcji z użytkownikiem. Trzymając się zaproponowanego rozwiązania możemy to pokazać jak na poniższym diagramie.

Na diagramie zostały pozostawione operacje tylko z „Zarządcy”. Dodane jednak zostały, trzymając się metody „Role, odpowiedzialność, współpraca”, z zastosowaniem wzorca „Tablica”:

  • tzw. „źródła wiedzy” („Promocje”, „Inni kupowali”, „Wcześniej zakupione”);
  • tzw. „tablica” („Baza produktów”);
  • tzw. „sterownik” („Wyszukiwarka produktów”);

Można by pójść dalej, analizując różne statusy zamówienia i skutki dla systemu, użytkownika. Podobnie można się zastanowić, czy „tablicy” nie zastąpić przez dostawcę usług („interfejs do ERP”).

Podsumowując, myślę, że odpowiedź na pytanie zawarte w tytule jest twierdząca. Stosując zaproponowane metody można pokazać więcej, w szczególności trzymając się pewnego poziomu uogólnienia.

Rozszerzenia – warstwa implementacyjna

Do diagramu przedstawionego jako warstwa reinżynierii dla procesu biznesowego, można dodać wiele elementów uszczegóławiających. Dodawanie tych elementów przybliża reprezentację procesu do tzw. warstwy implementacyjnej.
Elementy, które można dodać, są następujące:

  • elementy odpowiadające źródłom danych, systemom wewnętrznym przedsiębiorstwa,
  • punkty inicjujące inne procesy,
  • wskazanie, które kroki składają się z podprocesów,
  • informacja o wykorzystywanych narzędziach, aplikacjach, formularzach, zestawach danych,
  • aktorzy wykonujący poszczególne czynności (w szczególności po stronie dostawcy),
  • wymagania odnośnie bezpieczeństwa danych (logowanie, autoryzacja, sposób połączenia).

Przedstawiony proces można rozbudowywać w różnych kierunkach i na różne potrzeby.

Przykładowo, proces został rozbudowany o następujące elementy (diagram powyżej):

  1. formularza/zestaw danych
  2. aktor wykonujący zadanie

W tym celu, zostaną wykorzystane 2 kolejne obiekty notacji BPMN – odpowiednio:

  1. element rozszerzający informacje zawarte na diagramie wraz z ich powiązaniem z innym elementem (ang. annotation, ang. association, ang. data object),
  2. element grupujący czynności wykonywane przez danego aktora (ang. group).

Przykład procesu

Proces zamieszczony poniżej został przedstawiony na pewnym poziomie ogólności. Proces można rozwijać o kolejne elementy takie jak obsługa braku środków, informacje szczególne na podstawie wybranych sposobów płatności, kontakty w trakcie realizacji zamówienia. Na diagramie brakuje wskazania obsługi posprzedażnej i transakcji powiązanych. Elementem, który mógłby zostać dodany to podproces wspomagania decyzji klienta (badanie zachowań, produkty powiązane kupowane przez innych klientów, promocje).

Przykładowo zostały pokazane różne rodzaje połączeń między akcjami (sterowanie, komunikaty, wywoływanie, elementy początku i końca procesu) – więcej o elementach procesu. Obiekty oparte są o język UML.

Proces został zbudowany przy założeniu, że Klient rezygnuje z poszukiwania innego produktu (substytutu). Uproszczone zostało także to, że mógłby szukać kilka produktów w ramach jednego zamówienia. W szczególności istotne jest to, czy Klient jest znany, czy jest nowy, czy może korzysta z programu lojalnościowego. Proces można byłoby rozbudowywać w zależności od pytań postawionych przy określaniu założeń procesu.

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