Posts Tagged ‘przykład’

h1

Obowiązek dla właściciela procesu?

Listopad 16, 2019

„…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…;
  • …”
h1

Oczekiwane statystyki czasu realizacji

Listopad 10, 2019

Pozostając w wątku zakupów internetowych, dziś ponownie nawiąże do wiadomości e-mail, którą otrzymałem. W tym samym tygodniu, co ankietę, otrzymałem maila od innego sklepu, w którym zwykle robię takie zakupy, ale ostatnio czas realizacji zamówienia nie był dla mnie akceptowalny. Nastąpiło wydłużenie czasu od złożenia zamówienia do nadania przesyłki przez sklep. Wcześniej były to 1-2 dni, a ostatnio nawet tydzień. Po otrzymaniu tej wiadomości, dałem im szansę, bo w ofercie mają kilka produktów, których nie ma ten drugi sklep (czyli szerokość oferty  bardziej mi odpowiada). A może nie miałem wyjścia?

Treść wiadomości zawierała sformułowania typu „Zdajemy sobie sprawę, że nasz serwis w tym okresie mógł zawieść Twoje oczekiwania […] mamy nadzieję, że te chwilowe problemy nie wpłyną na dotychczasowe zaufanie.[…] Przywróciliśmy standard realizacji zamówień – wysyłamy przesyłki w ciągu 1-2 dni roboczych od złożenia zamówienia. […]”. Na koniec było odesłanie do serwisu ze wskazanymi czasami realizacji.

czas_realizacji450px_v3

Na diagramie, który zamieściłem kiedyś we wpisie z przykładami czasu realizacji (powyżej), zaznaczyłem miejsce, które sklep pewnie monitorował i zauważył, że nastąpiło jego znaczne wydłużenie. Taka obserwacja jest prosta do monitorowania – wystarczy badać czas między zapisem/złożeniem zamówienia (czas zapisu/złożenia – Z) a czasem odnotowania nadania przesyłki (czas nadania – N). Obydwie informacje przychodzą w wiadomości e-mail w postaci statusów, więc muszą być także odnotowane w systemie.

Sklep może prowadzić dzienny monitoring czasu realizacji zamówienia (N-Z) w zakresie maksymalnej wartości, minimalnej, mediany, dominanty czy średniej (pojęcia wyjaśnione poniżej). W zależności od rozkładu tych wartości, może podejmować odpowiednie decyzje lub zaplanować właściwe kroki. Jeżeli wartości wykraczające poza 1-2 dni są sporadyczne pewnie nie wymagają pilnych akcji.

Gdyby zobrazować na wykresie częstość występowania poszczególnych czasów realizacji dobrze byłoby, gdyby wykres był prawostronnie skośny (co zostało zaprezentowane na diagramie). Oznacza to, że większość wartości jest na początku przedziału 1-2 dni, a mniej powyżej 2 dni.

Rozkład prawostronnie skośny to taki rozkład, w którym zachodzi nierówność dominanta < mediana < średnia, czyli

  • [średnia:] średni czas realizacji zamówienia jest wyższy niż
  • [mediana:] czas realizacji zamówienia, który dzieli wszystkie pomiary czasu na 2 równe części co do występowania, a ten jest większy od
  • [dominanta:] czasu, który występuje najczęściej w rozkładzie czasów realizacji.

 

h1

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

Październik 20, 2019

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.

wspoldzielenie450px_1

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.

wspoldzielenie450px_2

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.

wspoldzielenie450px_3

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.

h1

Zakupy wg elektronicznej listy

Październik 12, 2019

Gdy chodzę między półkami sklepowymi obserwuję w jaki sposób klienci danego sklepu wspomagają się w tym, aby nie zapomnieć o jakimś produkcie. Jedni korzystają z list zapisanych na papierze (na kartce, w notatniku), inni patrzą w ekran (komórki lub innego sprzętu), a inni jeszcze wyglądają jakby wszystko pamiętali (a może kupują to, co im się rzuci w oczy). W ramach swoich zakupów korzystałem z każdej z tych opcji, więc robiłem zakupy wg jakiejś listy (o czym już kiedyś pisałem).

Dzisiaj chciałbym się skupić na liście elektronicznej. Przez jakiś czas korzystałem z jednej z dostępnych aplikacji na komórkę. Aplikacje te mają pewnie wiele elementów wspólnych. Bazując na tej, z której korzystałem, można powiedzieć, że:

  • wspierają tworzenie listy (dodawanie, usuwanie, edytowanie, nadawanie kategorii automatyczne lub ręczne),
  • wspierają odtwarzanie listy (np. kopiowanie poprzedniej do nowej – całej lub wybranych produktów),
  • umożliwiają kontrolę postępu zakupów (oznaczanie zakupionych),
  • umożliwiają współdzielenie listy zakupów z innymi osobami,
  • pozwalają na dodawanie produktów w promocji z listy podłączonych gazetek lub list produktów promocyjnych,
  • pozwalają na sortowanie produktów,

Na poniższym diagramie jest zaprezentowany proces tworzenia takiej listy zakupów.

zakupy450px

Co ciekawe w aplikacji, z której korzystałem, była możliwość wykorzystania wyszukiwarki produktów – wpisując fragment nazwy podpowiadał produkty lub wskazywał te, które kiedyś zostały dodane. Bardzo to przyspieszało tworzenie listy. Ten element jest zaznaczony na diagramie za pomocą „*” oraz rozpisany w dodatkowej ramce.

Co ciekawe chęć dodania dwóch takich samych produktów wymagała jedynue podwójnego „kliknięcia” w wyszukany produkt, a usunięcie wymagało jednego ruchu palca. Mając powtarzalną listę zakupów lub produkty na różnych listach, można było je kopiować do nowo tworzonej listy a potem edytować oraz usuwać. Wpisanie jednostek czy dokładniejszych informacji, z czego rzadko korzystałem, wymagało wejścia w opcję edycji konkretnej pozycji na liście. Było to bardzo wygodne.

Produkty oznaczone jako kupione, „spadały” na dół ekranu i były wyszarzane. Lista „braków” się skracała i była widoczna cały czas od góry ekranu. W przypadku pomyłki lub zmiany zdania można było produkt „odznaczyć” i wracał „na górę”.

Polecam taką formę budowania listy zakupów i jej wykorzystania. W sieci można znaleźć wiele artykułów od tym jakie funkcjonalności powinna mieć dobra aplikacja na komórkę do wspierania zakupów, listy najlepszych aplikacji oraz ich wymagania.

h1

Poziom akceptacji

Wrzesień 30, 2019

Proces kredytowy, wniosek o dotację, wniosek o dofinansowanie, proces rekrutacji… składa się na pewno z dwóch kroków – złożenia wniosku oraz podjęcia decyzji/oceny przez określoną jednostkę/grupę osób. Decyzja taka podejmowana jest na podstawie określonych kryteriów, działań ręcznych lub/i automatycznych lub w oparciu o wiedzę ekspercką/doświadczenie. W szczególności ten ostatni element jest ciekawy, ponieważ można go rozciągnąć na inne działania, takie jak na przykład udział w konkursie fotograficznym. Właśnie wyniki z jednego z konkursów zainspirowały mnie do tego wpisu. W wynikach pojawiło się pojęcie poziomu akceptacji. Mogę przypuszczać, że na akceptację złożyły się 2 elementy – spełnienie kryteriów podczas zgłoszenia do konkursu oraz pozyskana ocena zdjęć w ramach obrad jury.

Poziom akceptacji można określić jako liczbę wniosków/zgłoszeń, które przeszły punkt oznaczony na zielono na diagramie (punkt B) i przeszły do końca procesu, względem wszystkich zgłoszeń, które zostały zgłoszone do konkursu, co zostało oznaczone kolorem niebieskim na diagramie (punkt A). Wartość B/A wyrażona procentowo to prawdopodobnie poziom akceptacji, który pojawił się w opublikowanych wynikach.

poziom_akceptacji2_450px

Informację też można byłoby podzielić dodatkowo, wprowadzając punkt zaznaczony na czerwono na diagramie (punkt C), informujący o tym ile wniosków/zdjęć zostało zaakceptowanych formalnie, ale nie otrzymało wymaganej oceny eksperckiej aby przejść dalej, czyli nie kwalifikowało się do nagrody lub publikacji podczas wystawy. Mamy więc:

  • B/A – poziom akceptacji
  • C/A – poziom akceptacji formalnej (spełnienie kryteriów)

Podobnie można byłoby podejść do pozostałych wskazanych procesów oraz sytuacji biznesowych.

Obserwacja poziomu akceptacji dla procesów biznesowych może być przydatna, w szczególności, gdy zbadamy obydwa wskazane miejsca. Jeżeli na przykład większość wniosków odpada na punkcie C (kryteria formalne), to może to oznacza, że:

  • wniosek/kryteria są nieczytelne lub nieprecyzyjne (nie zakładam tu świadomego działania);
  • konieczne są dodatkowe działania edukacyjne, komunikacja, przykłady lub wsparcie podczas wypełniania wniosków;

Jeżeli natomiast zdecydowana większość odrzuceń odpada na punkcie B (decyzja/ocena), może to być spowodowane tym, że:

  • wzrósł poziom ryzyka/niepewności wśród wnioskujących;
  • spadł poziom akceptowalnego ryzyka w jednostce przyjmującej;
  • obniżony został dostępny budżet lub liczba nagród;
  • istnieje brak/nadmiar odpowiednich wniosków/kandydatów;
  • nastąpiły zmiany w otoczeniu rynkowym lub jego zachowaniu;

W pewnych sytuacjach obniżenie poziomu akceptacji może być oczekiwaną lub zamierzoną sytuacją, a w innych może to być przypadek lub coś co zaskoczyło daną jednostkę lub opiekuna procesu. Myślę jednak, że warto przyjrzeć się zmianom poziomu akceptacji w czasie, poszukać tego przyczyn lub sposobów na ustabilizowanie sytuacji.

h1

Nadmiarowe statusy?

Listopad 22, 2018

Po opublikowaniu poprzedniego wpisu, dotyczącego „jakości” danych w systemie, z którego korzystają użytkownicy, robiłem porządki w poczcie. Przeglądałem wiadomości, których już nie potrzebuję, a dotyczyły opisanych we wpisie przypadków. W ramach listy wiadomości dotyczących przypadku (3), gdy zamówiony produkt był dostępny wg strony sprzedawcy, ale nie było go u dostawcy , zwróciłem uwagę na jedną rzecz. Wiadomości dotyczące tego zakupu zawierały nietypową, porównując do innych wiadomości, listę statusów zamówienia, które otrzymałem.

O statusach pisałem już wiele razy i z tych wpisów, bazujących na otrzymanych wiadomościach, statusy można sprowadzić do listy: utworzone, złożone, w trakcie realizacji, wysłane, dostarczone. Czasami pojawiały się statusy pośrednie lub dotyczące firmy dostarczającej przesyłkę. Statusy te wydawały się uzasadnione i przy okazji w wiadomościach wskazywane były dodatkowe możliwości (np. zmiana godziny dostawy). Natomiast w przykładzie do którego zmierzam, te statusy były inne, co prezentuje poniższy diagram.

nadmiarowe_statusy450px

Jak widać, jako Klient zostałem poinformowany, że złożyli zamówienie u dystrybutora (2 osobne wiadomości dla każdego produktu), potem, że idzie ono do magazynu (znów 2 wiadomości), a potem, że tam dotarło (uff… jedna wiadomość)…  Wybrane statusy były osobno dla każdego produktu. Wydaje się, że te trzy statusy mogłyby być przekazane jako w trakcie realizacji lub w kompletacji (przypadek z pewnego sklepu). A potem dopiero status wysłane. Byłoby to myślę wystarczające. To, że złożyli zamówienie u dystrybutora nic mi nie mówi i jest to raczej status wewnętrzny sklepu. Co ciekawe nie ma potwierdzenia złożenia zamówienia przez Klienta.

I tutaj przypomina mi się Brzytwa Ockhama, która zakłada, że „nie należy mnożyć bytów ponad potrzebę”. Moim zdaniem tutaj można byłoby tę zasadę zastosować i ograniczyć liczbę statusów do 2 i w szczególności nie rozdzielać statusów osobno na każdy produkt z zamówienia, a traktować je jako całość. Zamówiłem tylko 2 produkty i dostałem 6 wiadomości, a mógłbym dostać 2. Pierwszy np. o treści dla zamówienie w trakcie realizacji: „Otrzymaliśmy Twoje zamówienie i informujemy, że jej kompletujemy. Poinformujemy Cię, gdy zostanie ono wysłane” i drugi dla zamówienie wysłane: „Wysłaliśmy Twoje zamówienie. Dziękujemy za skorzystanie z naszych usług”. Byłoby prościej i otrzymałbym mniej wiadomości, które i tak potem usuwam.

h1

Nieudany proces

Październik 16, 2017

Miesiąc temu pisałem we wpisie o procesie zamówienia, w którym firma dostarczająca produkt informowała mnie o każdym zrealizowanym i planowanym kroku z bardzo dużą dokładnością. Proces zakończył się sukcesem, w szacowanym terminie – produkt został dostarczony. Mogę powiedzieć, że każdy z przekazanych statusów odzwierciedlał sytuację rzeczywistą. Do każdego z elementów SIPOC (o którym pisałem już wielekrotnie) można przyporządkować określone obiekty z podanego procesu.

Dzisiaj wrócę również do tematu procesu zamówienia. Jednakże niestety muszę przytoczyć przykład rzeczywistego procesu, w którym to fakt, byłem informowany o każdym etapie realizacji, ale niestety komunikaty nie odzwierciedlały rzeczywistości, patrząc z mojej perspektywy. Na początku wszystko wyglądało identycznie: złożyłem zamówienie, czyli wybrałem produkt, podałem parametry zamówienia, zapłaciłem, a produkt został wysłany, o czym poinformował mnie pierwszy komunikat. I tu się podobieństwa kończą. Następny komunikat stwierdzał: uzgodniono termin przesunięcia dostawy. Nie było ani kontaktu mailowego ani telefonicznego od firmy kurierskiej. Ok, machnąłem ręką, nowy termin był w ostateczności akceptowalny, jak nie dojdzie produkt będę się martwił.

nieudanyprocess450px

Kolejny komunikat poinformował: brak kontaktu z odbiorcą, produkt zwrócony. I w tym momencie już nie było ciekawie. Ani nie wiedzieliśmy, że kurier jednak nie przyjedzie, ani nie podał wcześniej szacowanej godziny dostawy, a na koniec pomimo aktywnego telefonu i przebywania w strefie objętej zasięgiem – kontaktu nie było. Skończyło się reklamacją skierowaną do firmy kurierskiej. Wielokrotnie zamawialiśmy produkty u tego dostawcy i z wykorzystaniem kuriera – nigdy nie było problemów.

Potem okazało się, że produkt wrócił do firmy, u której zamawiałem produkt, a po kilku dniach nastąpił zwrot środków na konto.  Choć niestety nie mam zamówionego produktu, czy element oczekiwanego “wyjścia” (ang. output) w ramach modelu SIPOC nie został zrealizowany zgodnie z oczekiwaniami. Zostałem z “wejściem” (ang. input) – swoją potrzebą oraz środkami na koncie. Dostawca produktu (ang. Supplier) oraz Odbiorca produktu/Klient (ang. Client) uczestniczyli w tym procesie, ale nie można powiedziec, że są zadowoleni – z jednego strony produkt nie został sprzedany, a z drugiej dostarczony. Sam proces  (ang. process)“podobno” – podkreślam to słowo – został zrealizowany, choć mam wątpliwości, czy z tak funkcjonującym kurierem wszystkie kroki rzeczywiście zostały zrealizowane.

Powyższy diagram obrazuje taką zmianę sytuacji, z oznaczeniem, że nastąpiła kolejna zmiana strony obsługującej oraz w procesie nie ma statusu „produkt dostarczony”.