Proces a projekt

Ostatnio w jednym z wywiadów przedstawionych na stronie Ebizq.net pojawiło się pytanie: „How do project management and business process management relate to each other?”. To pytanie, dotyczące relacji zarządzania projektami i zarządzania procesami biznesowymi, przyciągnęło moją uwagę, na moje zainteresowanie obydwoma dziedzinami. Spotykałem się z różnym zestawieniem relacji, ale najczęściej opierało się na różnicy między projektem a procesem z punktu widzenia organizacji, powtarzalności, granic czasowych i sposobu oceny.

We wspomnianym wywiadzie dziedziny te zostały umieszczone na dwóch biegunach – diagram poniżej. Z jednej strony efektem zarządzania projektami może być zmiana procesu biznesowego, a sama jego realizacja może pozwolić na ocenę realizacji celów projektów, w zakresie np. zaplanowanej zmiany w pracochłonności, zmianie efektywności procesu czy likwidacji wąskich gardeł. Równocześnie uczestnicy procesu mogą wskazać zmiany, które należy wykonać, bądź to w postaci bieżących ulepszeń, bądź poprzez realizację inicjatywy projektowej. Z kolei samo zarządzanie projektem też może się odbywać w ramach określonego procesu działań.

W odpowiedzi na powyższe pytanie pojawia się również dodatkowa kwestia. Zarządzanie procesami biznesowymi jest szersze niż zarządzanie projektem. Myśle, że ta kwestia jest dość oczywista. W ramach wszystkich procesów przedsiębiorstwa niektóre z procesów mogą dotyczyć właśnie zarządzania projektami – proces zgłaszania zmian, proces zarządzania zmianą, proces monitoringu projektów, proces oceny korzyści projektów itd. Dla pewnych jednostek organizacyjnych mogą to być procesy główne, a dla niektórych procesy pomocnicze.

Weźmy na przykład osobę, która wykonuje czynności operacyjne, będące częścią procesu głównego. Równocześnie może zostać zaproszona jako ekspert dziedzinowy do pracy w projekcie w celu przedstawienia obecnego przebiegu procesu lub danego jego kroku

Reklama

Projekt a proces – „magia” trójkąta

Zdaję sobię sprawę, że stosując brzytwę Ockhama nie powininem tego robić, a mówiąc o procesie, raczej trudno mówić o projekcie. Jednakże załóżmy na chwilę, że problem zakupowy przedstawiony w poprzednim wpisie jest projektem. Projekt ten ma jasno zdefiniowany cel (realizacja zakupów) i określone ramy realizacji. Zgodnie z metodyką zarządzania projektami można przyjąć, że ten projekt funkcjonuje w ramach trójkąta ograniczeń: budżet, czas, zakres.

W opisywanym przypadku zakres jest znany: lista zakupów. Czas oczekiwanej realizacji też mamy ustalony. Zastanówmy się nad 3 elementem: budżetem. Jakby wpłynął na realizację tego projektu, gdyby go zmiejszyć albo okazał się niewystarczający.
Załóżmy, że koszt zakupu danego produktu jest wyższy w sklepie, który wybraliśmy.
Możemy:

•  szukać dalej w innych sklepach, co zwiększy czas realizacji;
• zrezygnować z zakupu, co zmniejszy zakres i koszt zakupów, który można inaczej wykorzystać lub potraktować jako oszczędność;

Strzałki na diagramie wskazują zależności między poszczególnymi elementami. Istotne jest założenie, że podejmując daną decyzję – poszukiwanie lub rezygnacja – trzymamy się tego, że pozostałe elementy są stałe. Podobną analizę można by wykonać zaczynając od innego kąta trójkąta. Skutki jednak byłyby inne.

Wróćmy jednak na chwilę do samego procesu. Powyższe przypadki i decyzje mogą powodować nawroty w procesie, zmiany priorytetów, modyfikację kolejności wykonywania zakupów. Każdy nawrót wpływa na czas realizacji procesu i w zależności od podjętych decyzji, na jego koszt oraz efekt. Realizacja procesu ma przynieść efekty (=efektywność) osiągnięte w akceptowany sposób (=sprawność). Powyższy przykładowy diagram w BPMN prezentuje te nawroty.

Czas akcji

Posiadana przeze mnie domena z kończącą się ważnością i powiadomienia od operatora domeny zainspirowały mnie do dzisiejszego wpisu. Nie było w tym nic dziwnego, ale  otrzymałem kilka różnych wiadomości dotyczących mojej domeny w temacie jej przedłużenia, które skłoniły mnie do przemyśleń. Zacząłem się im przyglądać kiedy przyszły i jakie akcje mogłem wykonać na danym etapie obowiązywania domeny. W całym okresie poprzedzającym zakończenie ważności domeny mogłem wykonać takie akcje jak: czekać, opłacić domenę z wyprzedzeniem, zrezygnować z domeny, poprawić dane, anulować zamówienie itd. Poniższy diagram prezentuje te możliwości w odpowiednich odcinkach czasu (trochę uogólniony).

Dodatkowo na diagramie dodałem informację o tym kiedy podjąłem zdecydowaną akcję – na niebiesko – zrezygnowałem z przedłużenia domeny. I z perspektywy oceniam, że komunikaty zaznaczone na czerwono są zbędne (o nadmiarowych statusach pisałem również w innym wpisie). Wskazałem w systemie, że nie chce przedłużać domeny (musiałem to potwierdzić). Cennym komunikatem – na zielono – był ten potwierdzający skuteczność rezygnacji z domeny (bo zaznaczenie braku chęci do jedno, a sam fakt wyłączenia domeny to drugie). Co ciekawe otrzymałem jeden komunikat, mówiący o upłynięciu terminu płatności za domenę po terminie jej ważności – moim zdaniem ten komunikat może spowodować pewien niepokój u Klienta, że jednak nie wszystko odbyło się zgodnie z oczekiwaniami i będą konieczne jakieś wyjaśnienia lub jednak opłacenie faktury.

Myślę, że taki proces w przybliżeniu, ma miejsce w przypadku różnych subskrypcji, usług z określoną ważnością, automatycznie lub „ręcznie” przedłużanych, płatnych jednorazowo z dany okres lub automatycznie opłacanych w odstępach czasu (te odstępy są istotne przy zgłoszeniu ewentualnej rezygnacji). Niektóre podmioty wysyłają wiadomość raz z listą możliwych akcji do wykonania, a potem z potwierdzeniem wybranej akcji. Inni komunikują każdy etap a inni z kolei pozostawiają pełną kontrolę klientowi usługi (zgodnie z zapisami regulaminów) i jedynie potwierdzają (lub nie) wykonanie określonej akcji (bo w sumie wszystko widać w systemie, który udostępnia operator, choć z tym bywa różnie – nie mam dostępu do podglądu pewnych ustawień w jednym z takich systemów, gdy nastąpiła jego migracja na inne/nowsze rozwiązanie).

Okresy między akcjami do wykonania, powiadomienia są specyficznym elementem danego systemu. Podmiot projektujący system, a dokładnie powiadomienia z procesu, ustawia co i w którym momencie wysyła. Patrząc na diagram BPMN może to być zdarzenie czasowe, np. przypadające na 1 dzień miesiąca lub określoną godzinę dnia (tak jest w przykładzie powyżej), dzień tygodnia, informujące wszystkich odbiorców, którym się kończy wykupiona usługa w następnym miesiącu lub za określony czas (np. X dni). Taki przykładowy proces został zaprezentowany na powyższym diagramie. W tym przypadku składa się z określenia listy usług, komunikatów do wysłania i ich wysyłki (komunikaty A-F).

Problem nie tylko w teorii

Słuchając wypowiedzi lekarzy, polityków, publicystów, śledząc publikacje na temat tego, co się obecnie dzieje w Polsce i na świecie w kontekście występującej pandemii, zacząłem się zastanawiać w jaki sposób można spojrzeć na podejmowane przez różne podmioty działania. Jedni wprowadzają pracę zdalną, inni wstrzymują produkcję, oferowanie usług. Jedni patrząc z wielką obawą w przyszłość, a inni są jeszcze spokojni.

Pojawiają się nowego ograniczenia, sposoby postępowania, akcje społeczne, wyrazy solidarności. Uczniowie muszą się przestawić na inny tryb nauki, osoby przyzwyczajone do bardzo aktywnego trybu życia, muszą zwolnić i zostać w domu. Osoby, które planowały różne spotkania, wyjścia na koncerty, uroczystości czy inne działania, muszą zmienić swoje plany. Ograniczają często swoje codzienne działania wymagające wyjścia z domu, do zakupów, krótkiego spaceru z dala od innych. Część osób nie może w cale wychodzić.

Każda z tych osób, podmiotów, państw walczących z epidemią/pandemią, analizuje problem, z którym się mierzy, którego doświadcza. Zbiera dostępne fakty/informacje, obserwuje zachowanie innych jednostek/podmiotów i ocenia je poprzez pryzmat swojego doświadczenia, potrzeb oraz możliwości. Przeprowadza diagnozę sytuacji w danym momencie.

W kolejnym kroku, zastanawia się na czym mu zależy, co chce osiągnąć w danej sytuacji oraz jak chce się zmierzyć z tym problemem. Czego oczekuje, że się wydarzy. Rząd może powiedzieć, że chce zmniejszyć obciążenie szpitali, zmniejszyć ryzyko masowych zachorowań czy też zoptymalizować wydatki w tym trudnym okresie. Podmiot chce zapewnić na przykład przetrwanie biznesu. A zwykły obywatel nie chce się na przykład zarazić. Jest to tzw. określenie oczekiwanego efektu działań.

W zależności od tego, kto określa problem oraz swój cel, może się pojawić różna koncepcja działań. Decydent określa jakie są możliwe działania, kroki do podjęcia, na kim możemy się wzorować, jakie są potrzebne zasoby oraz co dotychczas zrobiliśmy w celu osiągnięcia celu. Na bazie publikacji dotyczących pandemii, pojawiają się na przykład koncepcje działań, które określane są jako model europejski, chiński czy też krajów azjatyckich, patrząc globalnie na całe państwa, regiony. Każde z podejść ma jakieś skutki, prognozowany przebieg, czas dojścia do celu i ryzyka. W ramach wyboru koncepcji działania, następuje prognozowanie tego co się wydarzy.

Te ryzyka, przebieg, potencjalne efekty oczekiwane i uboczne muszą zostać wzięte pod uwagę podczas wyboru najlepszego rozwiązania do zastosowania. Ocena koncepcji działania odbywa się w gronie wybranych osób, przez jedną osobę, korzystając z wiedzy ekspertów dziedzinowych czy po prostu przez wyznaczony do tego komitet lub powołany organ decyzyjny. Na poziomie na przykład podmiotu gospodarczego może to zrobić właściciel czy zarząd. W ramach gospodarstwa domowego, może to być ocena zainteresowanej osoby czy też całej rodziny. Planowane są odpowiednie działania, kolejne kroki wynikające z podjętej decyzji. Są podejmowane odpowiednie działania przygotowawcze oraz angażowane niezbędne zasoby.

Podjęta decyzja, przygotowany plan – można zacząć działać. Rząd informuje o podjętych działaniach, wdrożonych zasadach. Podmiot gospodarczy informuje pracowników o tym, co nastąpi w najbliższym okresie i jak ma działać podmiot. Rodzina wprowadza w życie ustaloną koncepcję działania (może to być na przykład zakupy tylko rano, poprzedzone krótkim spacerem, bez odwiedzania zbyt wielu miejsc).

Po jakimś czasie, konieczna jest ocena podjętych działań. Dzięki temu wiemy czy są skuteczne, czy potrzebne są modyfikacje, czy przyniosły planowane efekty czy nie wygenerowały nowych ryzyk, a także czy nie zminiło się otoczenie i sytuacja. Obserwując różne podmioty ma się wrażenie, że po pierwszym podejściu (na przykład będziemy sprzedawać na wynos), zmieniają założenia (na przykład zamykamy lokal lub ograniczamy dotychczas podjęte działania).

W powyższym opisie, pewne elementy pogrubiłem. Są to elementy, które nawiązują z jednej strony do teorii sprawnego działania, czyli prakseologii ale także do cyklu rozwiązywania problemów. W sieci Internet można znaleźć wiele publikacji, które określają różne sposoby rozwiązywania problemów, wdrażania zmian, reagowania na nietypowe sytuacje. Wybrałem pewne uogólnienie, wzorując się na kilku publikacjach i zaprezentowałem je na powyższym diagramie.

Działanie w takich krokach ma zastosowanie na różnych poziomach życia gospodarczego, społecznego oraz prywatnego – między innymi w sytuacji, gdy pojawia się nowa sytuacja, problem, z którym trzeba się zmierzyć. Poradzenie sobie z pandemią to celowe działanie ludzkie, zmierzające do oczekiwanego efektu (ograniczenia efektów, zmniejszenie liczby zachorowań, rozłożenie zachorowań w czasie itp.).  W powyższych wyjaśnieniach pojawia się sformułowanie o wyborze najlepszego rozwiązania spośród możliwych w danym momencie i przy określonych okolicznościach. Równocześnie jest mowa o tym, że dążymy do pewnego oczekiwanego efektu. Podejmując decyzję odnośnie napotkanego problemu można spojrzeć na to jak na pewien projekt, w którym musimy spojrzeć na dwa aspekty – zarówno sprawność samego działania, jak i jego efektywność. I na koniec oceniamy czy działania były warte podjęcia i osiągnęliśmy trwały sukces, czy może porażkę. Wkrada się tutaj oczywiście niepewność, ponieważ z jednej strony nie wiemy wszystkiego o wirusie, a z drugiej nie wiemy do końca czy podjęte działania przyniosą oczekiwane efekty. Decydent narzucający/rekomendujący sposób postępowania dla innych, nie wie czy i w jakim zakresie będzie on stosowany.

Zachęcam do zapoznania się z różnymi metodami rozwiązywania problemów i przyjrzenie się temu, co się dzieje obecnie z ich perspektywy – moja próba spojrzenia jest powyżej. Czasami można wyraźnie zauważyć poszczególne etapy (zasygnalizowane przez wypowiedzi osób) lub je odczuć na własnej skórze (jak realizacja zaleceń co do braku zgromadzeń). Obecny trudny czas, gdy wszyscy mają wspólny problem do rozwiązania, jest idealnym obrazem (pozwolę sobie użyć takiego sformułowania) każdego z tych etapów.  I w sumie każdy z nas, zauważy w różnym stopniu, czy komunikowany efekt wystąpił i w jaki sposób nastąpiło przejście w kolejny cykl tego procesu. Choć mam wrażenie, że już jesteśmy w kolejnym cyklu (pewnie kolejnym z wielu).

—

Za inspirację do poruszenia tego tematu, a dokładnie tematu prakseologii, dziękuję jednemu z obserwatorów mojego bloga, który odniósł się w komentarzu na LinkedIn do mojego wpisu o metodzie start-stop-continue z 2 marca 2020.

Niespełnione oczekiwania jako początek zmian

Ostatnio poszedłem do biura podróży, z którego jakiś czas temu korzystałem, aby dowiedzieć się jakie oferty wycieczek wpasowałyby się w moje oczekiwania oraz warunki graniczne, które określę podczas wyboru. Po przedstawieniu oczekiwań, zapoznaniu się z przedstawionymi ofertami, wyszedłem z biura. I nie czułem się zadowolony. Sposób obsługi, pytania oraz sposób przedstawienia oferty nie był taki jak oczekiwałem. Przedstawicielka biura nie zachęciła mnie do skorzystania z ich oferty, a wręcz zniechęciła. Poszedłem więc do kolejnego biura z myślą, że będzie inaczej. I było. Zdecydowanie. Wyszedłem z biura z bardzo pozytywnymi odczuciami oraz nawet z typami ofert, z których byłbym chętny skorzystać. Dwie rozmowy i dwa jak różne efekty i odczucia. Proces obsługi (z perspektywy biura podróży), którego doświadczyłem, wraz z próbą identyfikacji różnic, przedstawiłem na poniższym diagramie używającym elementów notacji BPMN z dodatkowymi artefaktami i oznaczeniami (które wyjaśnię w dalszej części wpisu).

Proces oznaczony niebieskimi strzałkami to ten, który spełnił oczekiwania, a ten z czerwonymi strzałkami całkowicie odstawał od moich oczekiwań. Jak się okazuje do biura poszedłem z pewnymi oczekiwaniami – oznaczmy je jak M(oje)O(czekiwania) na potrzeby wpisu i powyższego diagramu. Sposób realizacji obsługi dla procesu czerwonego oznaczmy jako R(ealizacja)U(usługi)D(la)C(zerwonego) [odpowiedni obiekt na diagramie]. I odpowiednio dla niebieskiego – R(ealizacja)U(sługi)D(la)N(iebieskiego) [odpowiedni obiekt na diagramie]. Różnica między wartościami odpowiednio RUDC lub RUDN a wartością MO to jest tzw. luka 5 w modelu jakości usług (GAP 5 w ramach Service Quality Model). Jest to luka między otrzymaną a oczekiwaną usługą. W przypadku procesu niebieskiego ta luka, bazując na moich indywidualnych odczuciach, prawie nie występowała a w przypadku czerwonego była bardzo duża.

Wyobraźmy sobie, że właściciele sieci przeprowadzają/zlecają badanie jakości obsługi w swoich punktach sprzedaży lub takie badanie wykonuje niezależna instytucja. I, idąc dalej, to czerwone biuro podróży ma bardzo słabe wyniki w porównaniu do sieci niebieskiej. W takiej sytuacji, aby nie tracić klientów oraz udziału w rynku, właściciel decyduje się, tak załóżmy, na przeprowadzenie benchmarkingu procesów (pisałem o tym 9 lat temu na moim blogu), wzorując się na liderze rynku lub choćby na sieci niebieskiej, po względem budowy wartości dla klienta oraz realizacji procesu obsługi. Tym sposobem został zrealizowany pierwszy krok procesu benchmarkingu – identyfikacja obszaru/procesu.

W drugim kroku, jakim jest analiza, sieć czerwona może zebrać informacje o różnicach w sposobie funkcjonowania i realizacji działań na styku klienta i pracownika sieci, gdzie zauważona została luka oczekiwań i efektów realizacji. Mogę sobie wyobrazić, że wyznaczony pracownik sieci czerwonej lub zatrudniona do tego osoba udaje się do sieci niebieskiej, aby na własnej skórze poczuć jak wygląda proces, oraz znając instrukcje oraz wyniki badania, określić gdzie tkwią różnice w sposobie obsługi (na diagramie miejsca z różnicami są zaznaczone obszarami w kolorze szarym). W podanym przykładzie w dwóch miejscach różnica polega na wykonaniu określonego kroku lub nie, a w trzecim miejscu są wykonywane różne kroki. Taka osoba obserwująca proces, może właśnie zauważyć, co robi pracownik, aby przyciągnąć, zachęcić i utworzyć dłużej trwającą relację z klientem. Może też wskazać, że dany krok powoduje znaczną różnicę w budowaniu relacji lub wpływa silnie, bazując na swoim doświadczeniu, na poziom satysfakcji.

Po zebraniu obserwacji, można przejść do dalszych kroków procesu benchmarkingu. Dostosowując proces do obserwacji i doświadczeń można poprawić jakość obsługi klienta. Nie mówię tu o kopiowaniu rozwiązań, a bardziej o wyciąganiu wniosków z doświadczeń i próby spojrzenia na proces w inny sposób. To jak wygląda proces jest uzależnione od wewnętrznej polityki, dostępnych szkoleń i przyjętych założeń obsługi, doświadczeń z przeszłości. Może też być wynikiem istnienia lub próby zaadresowania pozostałych luk w jakości obsługi (czyli luk 1-4)). Wdrażanie na siłę rozwiązań niespójnych z resztą procesów i działań podejmowanych przez organizację, może bardziej zaszkodzić niż pomóc. Taka zmiana może następować stopniowo obserwując na przykład innych graczy na rynku, a nie tylko lidera rynkowego. Ta ciągła zmiana poprzedzona obserwacją konkurentów lub liderów rynkowych, analizie różnic i wdrażania odpowiednich zmian jest sednem procesu benchmarkingu.

W kontekście zmian widocznych dla klienta i zapewniania spójności z wewnętrznymi procesami organizacji, dobrze się zastanowić nad takimi elementami jak:

• komunikacja zmian i założeń,
• interesariusze procesu poza klientem,
• mierzenie efektów wprowadzanych zmian,
• ograniczenia budżetowe i dostępny czas,
• strategia i ewentualna potrzeba jej zmiany.

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

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 proces” wymieniony 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.

Drzewko decyzyjne w prezencie

Ostatnie tygodnie to okres szału zakupowego oraz przygotowań do świąt. Wielu z nas szuka prezentów dla najbliższych, znajomych, w ramach akcji społecznych czy czasami też dla siebie. Jedni poszukiwania prezentów zaczynają bardzo wcześnie (nie będę wskazywać kiedy, bo pewnie się znajdą tacy, u których podany termin wywoła emocje) a niektórzy zostawiają to na ostatnią chwilę (tydzień, dzień czy nawet godziny przed momentem wręczenia). Jednych prezenty są symboliczne a innych dość pokaźne. Jedni wydadzą fortunę a inni postawią na ręcznie przygotowywane prezenty. Wszystko zależy od dostępnego czasu, funduszy, pomysłu, poznanych lub nie potrzeb odbiorcy, podejścia danej osoby lub przyjętych zasad w danej grupie, rodzinie. Przypomina mi się przygotowywanie prezentów w szkole podstawowej podczas jednej z akcji – założeniem było, że prezent ma być wykonany ręcznie. Ile to powodowało kombinacji… I pewnie tak jest też w przypadku przygotowywania prezentów w dorosłym życiu.

Moim zdaniem podczas przygotowywania prezentów odpowiadamy sobie na następujące pytania (może trochę nieświadomie, ponieważ nasz sposób postępowania wynika z pewnego podejścia i możemy zawsze postępować w określony sposób lub się nad tym nie zastanawiać):

1. Zamówić gotowy produkt czy przygotować prezent samodzielnie?
2. Zamówić w okolice domu czy na miejsce, gdzie będziemy dawać prezent (o ile jest taka możliwość)?
3. Zamówić do punktu odbioru czy bezpośrednio do domu?
4. Opłacić przy zamówieniu czy dopiero przy odbiorze (o ile jest taka możliwość)
5. Zamówić kurierem , pocztą czy zdecydować się na odbiór osobisty?
6. Rozpocząć poszukiwania z wyprzedzeniem czy zostawić to na ostatnią chwilę
7. Zamówić prezent samodzielnie czy wspólnie z innymi (tzw. „zrzuta”)?
8. Jaką kwotę przeznaczyć na prezent?

Odpowiedzi na niektóre pytania z powyższych, wykluczają pojawienie się innych pytań. Z kolei pewne pytania wspólnie tworzą pewien zestaw wariantów. Np. Odpowiadając na pytanie (1), że wykonujemy prezent samodzielnie, możemy dodatkowo zastanowić się nad budżetem (8), aby określić ile chcemy przeznaczyć na elementy składowe. Możemy także zastanawiać się nad tym jak dostarczyć prezent do miejsca, gdzie zostanie wręczony. Pytanie o budżet czy moment zakupu w sumie występuje na każdym etapie „zastanawiania się”. Czasami kupujemy bo akurat jest promocja z tytułu black week/friday. A czasami czekamy na przypływ gotówki, ale mimo wszystko planujemy zakup prezentów uwzględniając dostępny czas, przyszły budżet oraz pomysły na prezenty.

Układając pytania w odpowiedniej kolejności możemy zbudować „prezentowe” drzewko decyzyjne (ang. decision tree). Czyli zidentyfikowaliśmy pytania, następnie je układamy w kolejności oraz budujemy zależności między nimi. Przykładowe drzewko bazujące na mojej propozycji ułożenia pytań jest przedstawione na powyższym diagramie. Można te pytania ułożyć także w innej kolejności. Można niektóre pominąć lub umieścić „wyżej” lub „niżej” w drzewku. Na szaro są zaznaczone liście (elementy końcowe, ang. leaf node) czyli określone akcje związane z przygotowaniem prezentu. Natomiast na biało miejsca rozgałęzienia (ang. splitting nodes), czyli punkty decyzji/pytania/testu wraz ze wskazaniem numeru pytania, do którego się odnoszą.

Drzewka decyzyjne pokazywałem także w kontekście wyborów, wyboru dostawcy czy scenariuszy dla grup na mistrzostwach.  Powyższe „podejmowanie decyzji” trochę mi przypomina planowanie działań uwzględniając co chcemy kupić (zaczniemy pewnie wcześniej) lub/i do kiedy musimy kupić (zrobimy to tak, aby się wyrobić, nawet rezygnując lub zmieniając wcześniejszy pomysł). Równocześnie mamy ograniczenie w postaci budżetu – co nas sprowadza to trójkąta projektowego (budżet, czas, zakres) lub rodzajów planowania stosowanych w technikach zwinnych.

Tymczasem pozostaje mi życzyć udanych i tafionych zakupów (niech Wasze drzewka będą pomocne), Wesołych Świąt i udanych wypieków o ile się ich podejmujecie.

Współdzielenie listy zakupów – „pull” czy „push”?

W ramach poprzedniego wpisu dotyczącego elektronicznej listy zakupów wskazałem, że jedną z funkcjonalności dostępnych w aplikacjach wspierających zakupy, jest możliwość współdzielenia listy zakupów. W aplikacji, z której korzystałem, to współdzielenie oparte było o podawanie adresu e-mail, przy założeniu, że zarówno tworzący listę, jak i ją otrzymujący jest zarejestrowanym użytkownikiem aplikacji i ma założone konto na serwerze aplikacji.

Użytkownicy aplikacji w ramach udostępnionej listy mogą:

• dodawać/edytować produkty na liście,
• śledzić postęp zakupów realizowanych przez drugą osobę,
• kopiować listę na przyszłość.

Założeniem dla funkcjonowania współdzielenia listy zakupów, był dostęp do sieci Internet z poziomu urządzenia, na którym jest zainstalowana aplikacja. W sytuacji utraty dostępu do sieci Internet, zmiany na liście oczekiwały na podłączenie się drugiego użytkownika listy. W przypadku dostępu do sieci Internet przez obydwa urządzenia, zmiany były przekazywane w miarę na bieżąco.

Wspólny proces dla obydwu użytkowników jest przedstawiony na poniższym diagramie.

Dla współdzielenia listy można byłoby zastosować dwa modele „współpracy”:

• model „push” (aplikacja inicjująca zmianę przy pomocy pośrednika przekazuje zmiany do drugiej aplikacji)
• model „pull” (jedna aplikacja przekazuje zmiany do wspólnego miejsca, a druga odpytuje o ewentualne zmiany w liście)

Wariant: model „push”
Użytkownik – właściciel listy – rejestruje listę, udostępnia ją, a następnie wprowadza na niej zmiany. Wszystkie te elementy są przesyłane na serwer obsługujący aplikację. Każda zmiana jest rejestrowana i przekazywana do aplikacji odbiorcy listy (wskazanego poprzez e-mail). Serwer wysyła informację o zmianach do aplikacji użytkownika, rejestrując wysłane zmiany. Ewentualna zmiana przez drugą aplikację jest wysyłana analogiczną ścieżką. Na diagramie przedstawiona została ta komunikacja, gdzie każda zmiana jest „pchana” (ang. push) na serwer a następnie do drugiej aplikacji.

W tym celu został wykorzystany wykres wyglądający jak diagram sekwencji (znany z UML) z pewnymi dodatkami. W projektowaniu rozwiązań można znaleźć wzorzec fire-and-forget, w którym informacje są przesyłane bez oczekiwania na reakcję odbiorcy. Trochę jak tutaj, bo w tym modelu aplikacja nie czeka na informację zwrotną.

Wariant: model „pull”
Podobnie jak w poprzednim wariancie, użytkownik – właściciel listy – rejestruje listę, udostępnia ją, a następnie wprowadza na niej zmiany. Wszystkie te elementy są przesyłane na serwer obsługujący aplikację. Trafiają na listę zmian/działań (ang. queue) wykonanych na liście zakupów w postaci zdarzeń typu: udostępnienie listy, zmiana listy, zakup produktu (a dokładnie jego odklikanie) itd. W momencie ustawienia udostępnienia listy, zmiany na utworzonej liście są dostępne do pobrania/odczytania (ang. pull) przez drugą aplikację. W sytuacji, gdy takie udostępnienie nie nastąpi, zmiany są odnotowywane na serwerze i są dostępne tylko dla właściciela listy.

Na diagramie jest przedstawiony ten model. W projektowaniu rozwiązań można znaleźć wzorzec publish-subscribe, który zakłada, że odbiorcy pobierają interesujące ich informacje z miejsca, gdzie zostały wystawione.

Pewnie można byłoby jeszcze zidentyfikować kilka innych wariantów, gdzie ta komunikacja jest bardziej dwustronna. Jednakże biorąc pod fakt, że aplikacja jest zainstalowana na urządzeniach mobilnych i nie w każdej sytuacji aplikacje będą miały dostęp do internetu, jakiś sposób przechowywania i kolejkowania zmian jest konieczny.  Dodatkowo użytkownicy wykonują często operacje zmiany i przeglądania zmian w różnym czasie lub tworzenie listy jest rozłożone w czasie. Patrząc od strony „odbiorcy” listy, także może zmodyfikować listę w czasie jej dostępności. Takie zmiany są „przesyłane zwrotnie” do właściciela listy.

EPO – co to jest?

Zapoznając się z tegorycznymi (2017) wynikami konkursu “Liderzy Informatyki” kilkakrotnie napotkałem w artykułach informację, że istotnym elementem na polskim rynku było wprowadzenie tzw. EPO. Wiele firm dołączyło do tego systemu od momentu jego wprowadzenia. Materiały o projekcie opublikowane w Internecie wskazują, że wprowadzenie takich mechanizmów miało przyczynić się m.in. do przyspieszenia obiegu korenspondencji sądowej oraz zmiany samych procesów.

EPO jest to tzw. elektroniczne potwierdzenie odbioru, gdy dla nadanej przesyłki lub grupy przesyłek informacja zwrotna przekazywana jest elektronicznie zamiast przygotowywana i przekazywania w formie papierowego formularza odbioru. Bezpośrednio po dotarciu przesyłki do odbiorcy i jej odebraniu, taka informacja trafia do nadawcy, a dokładnie do jego systemu. Sposób działania jest zaprezentowany na diagramie w formie uproszczonej.

Dla tak zbudowanego rozwiązania istotnymi elementami są:

• dostępność systemu – aby w każdym momencie możliwe było nadanie przesyłki oraz otrzymanie w akceptowalnym czasie potwierdzenia odbioru. W przypadku przesyłek sądowych czas dostarczenia przesyłki oraz informacja o tym ma znaczenie dla przebiegu procesu;
• elastyczność systemu – możliwość dołączenia kolejnych instytucji lub operatorów, aby możliwe było zaspokojenie potrzeb różnych podmiotów. W zapewnieniu tego miało też pomóc zastosowanie otwartych standardów i technologii.
• bezpieczeństwo systemu – w ramach komunikatów przesyłanych do systemu i otrzymywanych z niego krążą poufne informacje. Informacja o tym, że do kogoś idzie przesyłka sądowa, jest informacją dla danego odbiorcy i nie powinna trafić do innego podmiotu. Projekt zakładał szyftowanie danych oraz stosowanie podpisów dla komunikatów, aby zapewnić ich poufność oraz uniemożliwić ich podważenie.
• integralność danych – informacja przekazywana podczas nadania przesyłki powinna być zgodna z informacją w EPO. Dla sądu jest istotne, które przesyłki dotarły do których adresatów i kiedy. Modyfikacja jakiegoś elementu mogłaby mieć konsekwencje, przede wszystkim dla odbiorcy postępowania lub innej osoby.

Lokalnie czy na serwerze?

Kilka razy na tydzień czy nawet dziennie, wypełniamy w przeglądarce formularze. Czy to pola do logowania w aplikacji, czy to formularz zamówienia, rejestracji w serwisie czy może komentarz na forum? Każdy z tych formularzy ma określoną liczbę pól, istotną dla danej operacji. Wypełniając formularz nie zastanawiamy się jednak na tym, że pod nim kryje się dodatkowa logika. Tę logikę zauważamy, gdy ominiemy pole lub wpiszemy błędną wartość. Otrzymujemy odpowiedni komunikat, a potem wprowadzamy uzupełnienia i wysyłamy formularz. Działanie to przedstawia poniższy proces.

W powyższym procesie zakładamy, że po wysłaniu formularza jest wykonywana walidacja sposobu jego wypełnienia. Walidacja taka może odbyć się lokalnie, zdalnie (tj. na serwerze) lub w każdym z tych miejsc. Walidacja wykonywana lokalnie przeważnie nie wymaga komunikacji z serwerem i jest wykonywana przez przeglądarkę użytkownika (np. przy użyciu tzw. Java Script, o czym więcej pod linkiem na końcu wpisu). Walidacja wykonywana zdalnie (na sewerze) wymaga przesłania danych do serwera i poczekania na jego odpowiedź.

Jak widać na diagramie, mamy 2 ścieżki – lokalną na zielono oraz z wykorzystaniem serwera na żółto. Na obydwu ścieżkach wystąpienie błędu (oznaczonego obiektem error event) powoduje powrót do formularza. W pierwszym przypadku formularz do serwera jest przesyłany o 1 raz mniej niż w drugim przypadku.

Częścią wspólną są zdarzenia: początkowe, czyli Zaakceptowany formularz oraz końcowe, czyli Formularz poprawny oraz Formularz niepoprawny. W ramach części procesu, są podobne kroki, ale wykonywane w innych miejscach. Chcąc wdrożyć mechanizmy po obywdu stronach można wykorzystać różne języki programowania i metody. Jak widać w podlinowanym artykule możliwości jest wiele i w zależności od sposobu zaprojektowania rozwiązania mechanizmy są rozdzielone lub silnie ze sobą powiązane (jak np. przy wykorzystaniu AJAX).