Gdy chodzi o pieniądze

Wczoraj słuchając wypowiedzi podczas konferencji prasowej, mającej miejsce późnym wieczorem, dotyczącej przekazania określonej kwoty ma media publiczne, zacząłem się zastanawiać jakie pytania/kryteria można postawić podejmując taką decyzję. Spokojnie, nie będę się zastanawiał nad pytaniami, które można postawić dokładnie we wspomnianej sytuacji. Nie będę się także wypowiadał na temat przedmiotu decyzji czy też wyrażał swojej opinii odnośnie podjętej decyzji. Nie będę też zastanawiał się nad konsekwencjami tej decyzji. Nie będę też nawiązywał do działań, które miały miejsce, przed podjęciem tej decyzji.

Spróbuję uogólnić taką sytuację skupiając się na samym procesie podejmowania decyzji. W sytuacji podejmowana decyzji o finansowaniu, decydent zbiera informacje, ocenia kwestie formalne oraz merytoryczne, identyfikuje cel finansowania i jego warunki a potem wskazuje jaka jest decyzja. Poniższy diagram przedstawia w formie drzewka decyzyjnego jakie kwestie mogłyby być brane pod uwagę podczas podejmowania decyzji o udzieleniu finansowania (z perspektywy komitetu bądź pojedynczej osoby).

kasa_530px

Na diagramie zaznaczono takie elementy jak:

  • przykład kwestii odnoszącej się do weryfikacji kwestii formalnych (kompletność wniosku – np. czy posiada wszystkie wymagane dane, załączniki, zgody);
  • weryfikacja merytoryczna w zakresie elementów biznesowych wniosku takich jak relacja wnioskowanej kwoty do planowanych efektów, korzyści biznesowych, uwzględnienia otoczenia biznesowego, sytuacji rynkowej;
  • weryfikacja prośby/wniosku w kontekście obowiązujących reguł czy zasad; np. w organizacji może funkcjonować przepis, że na dany rodzaj inicjatywy przeznaczamy tylko określoną kwotę budżetu lub odgórne postanowienie, że nie podejmujemy zobowiązań finansowych w kontekście określonych podmiotów/dostawców (bo na przykład ryzyko jest za duże);
  • decyzja odnośnie tego czy przekazanie środków powinno być obarczone dodatkowymi warunkami (np. Zestawienia wykorzystania, udostępnienie w transzach) czy wnioskujący otrzymując środki nie musi nic więcej robić.

Punktem wejścia do podejmowania decyzji jest weryfikacja dostępności budżetu. Jeżeli środki się skończyły lub dostępny budżet został zarezerwowany na inne kwestie, to wtedy wniosek jest odrzucany bez dalszej analizy. W przypadku, gdy środki są dostępne, możliwe są różne warianty sytuacji, począwszy od odrzucenia wniosku z powodów formalnych, przez odrzucenie ze wskazaniem elementów do wyjaśnienia, potem akceptacje warunkowe czy na koniec akceptacja bezwarunkowa. Wszystko zależy od rodzaju wniosku, osób podejmujących decyzję oraz przyjętych zasad, a także innych kwestii specyficznych dla danej organizacji czy podmiotu gospodarczego.

Akceptacja środków może być także wielostopniowa – w zależności od kwoty czy przedmiotu, który będzie podlegał finansowaniu. Można sobie wyobrazić, że na diagramie dojdzie element, który wskaże, że wniosek zostanie przekazany do wyższej instancji lub innego komitetu. Często w statusach spółek (czego odzwierciedlenie można znaleźć w KRS), są informacje kto może podejmować zobowiązania, w jakim zakresie i do jakich kwot. Takie przesunięcie decyzyjności może się pojawić w momencie analizy wniosku, pozyskania dodatkowych informacji czy też dostępności lub nie w danym momencie osób uprawnionych, a także aktualności pełnomocnictw czy występującego otoczenia biznesowego. Podczas analizy mogą wyjść kwestie, które należy skonsultować z jednostką prawną, podatkową czy też działem księgowości.

Warto tutaj dodać, że może też także występować możliwość odwołania się od decyzji. Zgodnie z przyjętymi zasadami w organizacji czy podmiocie gospodarczym, osoba zainteresowana musi wykonać odpowiednie kroki, aby ponownie rozpatrzono jego wniosek o finansowanie. Efektem może być ponowne przejście powyższej ścieżki lub podtrzymanie decyzji bez analizy.

Przypuszczam, że wielu moich czytelników czekało kiedyś na taką decyzję, starało się o podjęcie decyzji uczestnicząc w wyjaśnieniach. Może niektórzy nawet brali udział w podejmowaniu takiej decyzji – jestem ciekawa czy jeszcze jakąś kwestię można wskazać jako element takie procesu.

Start-stop-continue

Praca w grupie/zespole, działanie osoby pełniącej określoną rolę, realizowany proces, organizacja uroczystości/spotkania/warsztatów… – to tylko niektóre działania mające miejsce czy to w życiu prywatnym, czy to w życiu zawodowym. Sposób działania w każdym z tych obszarów może zostać przeanalizowany przy użyciu metody wskazanej w tytule wpisu – start-stop-continue. Metoda ta zakłada znalezienie odpowiedzi na pytania:

  • [start] co powinniśmy lub powinna zacząć robić osoba, aby osiągnąć lepszy efekt, lepiej zostać ocenionym czy też, aby uniknąć napotkanych problemów?
  • [stop] co powinniśmy lub powinna przestać robić osoba, ponieważ np. zauważamy, że nie przynosi to oczekiwanego efektu, wprowadza zamieszanie lub jest nieefektywne?
  • [continue] co powinniśmy lub powinna nadal robić osoba, ponieważ to przynosi właściwe efekty, jest dobrze oceniane i pomaga w realizacji zadań?

Metoda ta jest także często stosowana, obok innych dostępnych metod, podczas tzw. retrospektywy sprintu. Retrospektywa sprintu jest to spotkanie zespołu scrumowego. Jej celem jest analiza sposobu działania zespołu scrumowego, bazując na obserwacjach i odczuciach członków tego zespołu. Jest okazją, aby omówić co działa, co nie działa a czego nam brakuje podczas realizacji pracy zespołu. Mogą to być takie elementy jak komunikacja, podejście do problemów, dostępność product ownera czy inne elementy. Efektem powinna być propozycja zmian, działań, które można wdrożyć już od kolejnego sprintu.

Osoba, która moderuje takie spotkanie, powinna zadbać o zachowanie pewnego porządku spotkania, tak, aby każdy z uczestników miał świadomość jakie są oczekiwania, czego może się spodziewać oraz jaki rodzaj zaangażowania będzie oczekiwany. Pozwoli to także zapewnić, aby każdy z członków zespołu miał możliwość, aby się wypowiedzieć i przekazać swoje uwagi, przemyślenia czy zastrzeżenia. Inną kwestią jest czy każdy uczestnik będzie chciał z takiej możliwości skorzystać. Dlatego ważny jest odpowiedni dobór metod zbierania propozycji lub/i aktywizacji uczestników.

Uczestniczyłem w różnych spotkaniach retrospektywy i moim zdaniem każda jest inna. Miałem okazję kilkakrotnie poprowadzić takie spotkanie i to z kolei dało mi zupełnie inną perspektywę. Myśląc o tym, zacząłem się zastanawiać nad strukturą takiego spotkania. Próbą zobrazowania jest poniższy diagram procesu retrospektywy.

retrospektywa_515px

Poszczególne kroki procesu są następujące:

Zbierz zespół/zaproś uczestników.
Pierwszym etapem jest zebranie uczestników spotkania w (najlepiej, choć nie zawsze jest to możliwe) jednym miejscu i czasie. Dokładny termin i miejsce spotkania to często element umowy wewnątrz zespołu. Jednakże dobrze jest, aby ktoś przypomniał lub zachęcił zespół do udania się na takie spotkanie lub przygotowanie się do niego. Pozwoli to także uniknąć niepotrzebnych opóźnień w jego rozpoczęciu lub wymówek odnoszących się do braku wiedzy o spotkaniu lub konieczności przygotowania się.

Przedstaw planowany przebieg spotkania
Osoba prowadząca spotkanie powinna wskazać w jaki sposób będziemy pracować, jakie elementy wykorzystamy oraz jakiego typu zaangażowanie będzie potrzebne. Dobrze także jak przypomni jaki jest cel ceremonii oraz na jakie zasady umówił się zespół dla tej ceremonii.

Przeprowadź działania
Osoba prowadząca moderuje spotkanie, pilnuje czasu, zgodnie z przyjętymi i zaproponowanymi do wykorzystania metodami. Może także podsumowywać poszczególne etapy oraz dotychczas zebrane wnioski. Może zachęcać do udziału milczących uczestników spotkania. Na spotkaniu mogą wystąpić takie aktywności jak: ocena działań ustalonych na poprzednim spotkaniu, zebranie tematów na bieżące spotkanie, ocena zadowolenia zespołu, przegląd kontraktu, wyjaśnienie zauważonych problemów czy inne. Po każdym działaniu, osoba prowadząca powinna ustalić z zespołem czy przechodzimy do kolejnej części spotkania czy jeszcze poświęcamy czas na dokończenie rozpoczętego tematu.

Podsumuj spotkanie/Zbierz wnioski
Osoba prowadząca zbiera wnioski lub prosi zespół o ich podsumowanie. Zachęca zespół do wybrania tych działań, które podejmie w kolejnym sprint. Działania mogą dotyczyć szeregu elementów składających się na pracę zespołu. Mogą np. dotyczyć ograniczenia marnotrawstwa w działaniach zespołu, komunikacji, reakcji na ocenę pracy zespołu czy innych.

Zakończ spotkanie
Osoba prowadząca podczas tego kroku dziękuje za wykonaną pracę, określa gdzie będą dostępne zebrane wnioski, podsumowanie oraz materiały. W ramach tego kroku może także poprosić o ocenę spotkania  pod kątem jego efektywności, zadowolenia zespołu. Taka ocena może być przydatna dla osoby prowadzącej – może pomóc w lepszym przeprowadzeniu kolejnego spotkania lub może być podstawą do wybrania w przyszłości innych metod zbierania informacji lub/i aktywizacji uczestników.

Ceremonia ta jest bardzo ważna. Tak jak planowanie sprint o którym pisałem miesiąc temu, wskazuje kierunek tego CO i JAK robimy w zakresie rozwoju produktu w poszczególnych sprint, tak retrospektywa wskazuje kierunek rozwoju zespołu oraz pozwala na zmianę sposobu jego działania. Ceremonia ta pozwala na to, aby tak, jak to określa wskazana na wstępie metoda: [start] zacząć robić, coś czego nie robiliśmy, czego wg zespołu zabrakło; [stop] przestać robić to, co nam utrudnia efektywną pracę oraz [continue] kontynuować to, co zespół ocenił jako cenne i czego warto się trzymać. Jest to zgodne z duchem scruma, zakładającym ciągłą inspekcję prac (zastanawiamy się nad tym co robimy oraz jak działamy), przejrzystość działań (pokazujemy jak pracujemy, jakie są efekty oraz mówimy otwarcie co nie działa i co powinniśmy zmienić) oraz adaptację (wprowadzamy zmiany i dostosowujemy działania do zebranych oczekiwań).

 

Ewolucja czy rewolucja?

15 lutego – to dzień, w którym Ministerstwo Finansów udostępniło dla podatników, w dedykowanej usłudze „Twój e-PIT”, automatycznie wypełnione deklaracje PIT za 2019 rok. Zainteresowani mogą się zalogować do usługi, wykorzystując określone dane dostępowe lub profil zaufany, zweryfikować i uzupełnić deklarację (np. o to jak przekażą 1% podatku lub wskazując ulgi), połączyć deklarację ze współmałżonkiem, a następnie wysłać wypełnioną deklarację, a następnie pobrać UPO (potwierdzenie złożonej deklaracji). Wszystko dzieje się w udostępnionej usługi. Wystarczy postępować zgodnie z instrukcjami. Można też nic nie robić i deklaracja zostanie złożona automatycznie w odpowiednim terminie . Wszystko dzieje się przez Internet – takich deklaracji złożonych przez Internet w zeszłym roku było ok. 16 mln, w 2016 – ok. 10 mln, a w 2012 – ok. 2mln (dane znalezione w Internecie).

Cofnijmy się teraz w czasie, zanim przyszedł rok 2008, gdy po raz pierwszy można było złożyć deklarację przez Internet (co zrobiło wtedy ok. 300 osób), deklaracje były wypełniane ręcznie (tzw. proces ręczny) na dedykowanych drukach lub przygotowanych do tego aplikacjach, które pozwalały na wydruk wypełnionej deklaracji i jej dostarczenie do właściwego urzędu skarbowego lub na bezpośrednie wysłanie deklaracji przez Internet.

Proces rozliczania deklaracji PIT, który można było wykorzystać na różnym etapie rozwoju tej usługi, jest zobrazowany na poniższym diagramie w BPMN, prezentujący 3 warianty składania deklaracji (od najstarszego papierowego, przez pośredni, do najnowszego):

rozliczenia_pit_570px

Zastanówmy się teraz czy z perspektywy podatników proces przejścia z PIT papierowego do w pełni elektronicznej wersji (nastąpiła tutaj tzw. elektronizacja procesu) był ewolucją (ang. evolution) czy rewolucją (ang. revolution). Zanim to zrobimy przytoczmy czym charakteryzują się takie zmiany.  Zbierając informacje zróżnych publikacji dostępnych w sieci Internet można powiedzieć, że:

Ewolucja Rewolucja
(E1) Zmiana następuje stopniowo, przyrostowo (R1) Następuje zastąpienie czegoś istniejącego, czymś całkowicie nowym
(E2) Zmiana w danym momencie dotyka określonego obszaru (R2) Zmiana dotyka wszystkich powiązanych obszarów za jednym razem
(E3) Ludzie mają więcej czasu, aby się przystosować do zmiany. Więcej osób identyfikuje się ze zmianą (R3) Ludzie nie mają czasu na dostosowanie się. Zmiana może być dla nich bardzo gwałtowna, a nawet bolesna.
(E4) Zmiany są komunikowane stopniowo i wraz z nimi są przeprowadzane odpowiednie działania edukacyjne (R4) Działania komunikacyjne i edukacja mogą być niewystarczające
(E5) Istnieje możliwość wycofania się z wprowadzonej w danym etapie zmiany i dostosowania jej założeń i zakresu (R5) Nie ma możliwości często wycofania się z wprowdzonej zmiany
Moim zdaniem proces przypomina działania zgodne z PDCA czy benchmarkingiem Moim zdaniem proces przypomina działania zgodne z reengineeringiem
Podsumowanie: zmiana przeprowadzana może mieć duży wpływ a być wykonywana rzadko (rewolucja) a może także być wykonywana często, ale posiadać mały wpływ (ewolucja). Jeżeli zmiany są częste i ogromnym wpływie może powstać chaos, a w momenie, gdy nie robimy zmian lub są one bardzo rzadko i mają mały wpływ, to wtedy mamy stagnację.

Patrząc na powyżej wskazane cechy i zachowanie podatników myślę, że można powiedzieć, że zmiana była ewolucyjna. Możliwość rozliczania deklaracji przez Internet została wprowadzona już w 2008 i co roku rosła liczba decydujących się na takie rozwiązanie. Mogli oni stopniowo pozyskiwać informacje o tym jak to wygląda, czy jest bezpieczne, co jest potrzebne, jakie są ograniczenia, problemy, słuchając zarówno specjalistów w tej dziedzinie, czytając artykuły, czy też zbierając informacje ze swojego otoczenia (połączenie cech E3 i E4 z tabeli powyżej). Teoretycznie nadal pozostaje możliwość rozliczenia deklaracji papierowo, więc cały czas pozostaje pewna furtka dla wprowadzających takie rozwiązanie (jakby zastosowanie punktu E5).

Samo przejście z deklaracji wypełnianej całkowicie po stronie podatnika do w dużym stopniu zautomatyzowania procesu i udostępnienia go w dedykowanej usłudze, jest rewolucyjne (samo ministerstwo określiło to w zeszłym roku jako „nową jakość”). Jest to wprowadzenie czegoś całkowicie nowego (cecha R1), co powoduje zmianę zachowań u podatników – mogą to zrobić jeszcze szybciej, wygodniej, z mniejszym ryzykiem popełnienia błędu. Ciężko tu mówić o tym, że jest to bolesne czy gwałtowne (cecha R3). Jednak jest to zmiana dotykająca wszystkich obszarów za jednym razem – zbierania informacji, przygotowania rozliczenia oraz składania deklaracji (R2). Wcześniejsze zmiany procesu dotykały części obszarów (cecha E2) – np. wypełniania deklaracji czy składania deklaracji (ręcznej po jej wydruku czy korzystając mechanizmów automatycznych). Zmiany między poszczególnymi wariantami (od najstarszego do najnowszego) są oznaczone kolorami na diagramie wraz z odpowiednimi komentarzami. Zaznaczone są także miejsca, gdzie określone kroki już nie występują w późniejszej wersji.

Pewnie dla pewnej grupy podatników, wypełnienie deklaracji w tradycyjnej formie, będzie najbardziej wygodne i będzie to jedyny akceptowalny sposób. Mają do tego jak najbardziej prawo, ale muszą się trzymać pewnych zasad. Mogą tak postępować, bo nie mają innego wyjścia, boją się lub nie akceptują innych dostępnych rozwiązań. Tacy podatnicy mogą wymagać przekazania większej liczby informacji lub dedykowanej edukacji, jeżeli wprowadzana zmiana zakładałaby ograniczenie stopniowe takiej możliwości (cecha E4) lub w pewnym momencie nastąpiłoby nagłe odcięcie takiej możliwości (cecha R4). Ciekawe czy taki punkt odcięcia nastąpi.

Mimo wszystko wydaje mi się, że patrząc całościowo, ta zmiana ma charakter ewolucyjny. Do określenia jej jako w pełni rewolucyjnej brakuje mi tego elementu odcięcia  – zastąpienia dotychczasowej usługi. Jeżeli podatnik ma prawo wyboru, to nadal „stara” wersja procesu będzie funkcjonować.  Myślę, że jest to dobry kierunek, zgodny z obowiązującymi trendami do ograniczania procesów opartych o papier (nie tylko ze względu na ekologię, ale także koszty obsługi takiego procesu) oraz zmniejszania pracochłonności wykonania czynności, które są obowiązkowe.

A co myślą czytelnicy mojego bloga? Czy moja interpretacja jest słuszna?

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

niespelnione_oczekiwania540px

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 niebieskiegoR(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:

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.

Proces planowania sprintu

Na początku stycznia na LinkedIn jeden z jego użytkowników udostępnił wpis ze strony agileinstitute.pl o tytule „Czy cel sprintu w Scrumie jest opcjonalny?”. Autorem artykułu jest Aleksander Kóska i pod jego udostępnieniem rozwinęła się ciekawa dyskusja. W trakcie dyskusji wyraziłem swoje zdanie, że moim zdaniem dobrze jest, gdy ten cel sprintu jest zdefiniowany, bo wiemy wtedy do czego zespół dąży i łatwiej podejmować decyzje, gdy pojawią się wątpliwości. O tym więcej za chwilę… Swoją drogą warto zapoznać się ze wskazanym artykułem oraz z powiązanymi treściami.

Po zapoznaniu się z tą dyskusją, zacząłem się zastanawiać jak w „rzeczywistości” wygląda proces planowania sprintu oraz jak on jest powiązany z określonym celem sprintu. Specjalnie jedno ze słów w powyższym zdaniu umieściłem w cudzysłowie, ponieważ będzie to pewne spojrzenie na ten proces. A proces ten, czego mam świadomość, może wyglądać różnie w zależności od specyfiki produktu, składu zespołu, jego dojrzałości agile’owej, a także zebranego doświadczenia w trakcie dotychczas zakończonych sprintów. Zaznaczam, że jest to spojrzenie z perspektywy product ownera. Gdyby zapytać różne zespoły lub product ownerów, pewnie można byłoby zidentyfikować różnice, ale myślę, że pewne ramy pozostałyby wspólne.

Zacznę od próby zobrazowania tego procesu na diagramie. Następnie spróbuję go przybliżyć. Do zobrazowania procesu użyłem notacji BPMN (pokolorowanej w specjalny sposób), której staram się używać, gdy próbuję graficznie przedstawić diagramy i koncepcje omawiane we wpisach na tym blogu.

planowanie_sprint2_470px

Na diagramie zostały umieszczone następujące kroki:
1) Określ cel sprintu
Choćby wstępnie, product owner powinien określić czy w kolejnym sprint zespół ma się skupić na dalszym rozwoju funkcjonalności, dodaniu nowej funkcjonalności, likwidacji długu technologicznego, poprawie błędów, dokończeniu zadań z bieżącego sprintu lub zmianie funkcjonalności po zebranych uwagach np. z pilotażu. Możliwości jest wiele, zależy to od produktu, etapu jego rozwoju oraz ustalonego wcześniej planu działań. Product owner określając cel sprintu kieruje się wizją produktu, do której dąży. Przygotowanie sprintu oraz sama ceremonia planowania odbywa się w odpowiednim momencie czasu (dlatego zastosowałem na starcie procesu zdarzenie start event – timer).
2) Wybierz elementy z backlog
Product owner może wybrać wstępną listę elementów, którymi powinien się zespół zająć w następnym sprint. Elementy wynikają z przyjętego celu sprintu oraz priorytetów w ramach backlogu (wejście do kroku procesu oznaczone za pomocą asocjacji na diagramie). Zadania powinny być już wycenione na refinement (polecam wpis na blogu agile247.pl na temat tej ceremonii). Podczas ich wyboru uwzględnia prędkość (ang. velocity – odsyłam do szczegółowej informacji na scrum.org) oraz możliwości (ang. capacity – odsyłam do szczegółowej informacji na scrum,org) zespołu (kolejne wejścia do tego kroku, które oznaczyłem na diagramie – są to elementy wykorzystywane podczas realizacji kroku). Efektem jest wstępna wersja sprint backlog (wyjście z kroku procesu).
3) Omów elementy z zespołem
Na ceremonii planowania, wstępny sprint backlog omawiany jest z zespołem, wyjaśniane są wątpliwości (jeśli się pojawią). Często pojawia się dyskusja o tym, czy zadania są możliwe do wykonania, czy jednak nie powinny być wykonane inne zadania – bazując na doświadczeniach wcześniejszych sprintów i tym, co się wydarzyło od momentu wyceny i omówienia danego zadania podczas refinement). Product owner powinien także omówić jak dane zadanie, które wybrał w poprzednim kroku, przyczynia się do realizacji celu sprintu, który także powinien przedstawić. Zespół z kolei patrząc na proponowany cel sprintu może zaproponować inne zadania, które jego zdaniem przyczynią się do realizacji celu.
4) Zaktualizuj elementy
Jeżeli to jest konieczne elementy sprint backlog są aktualizowane i wyceniane ponownie. Podczas tego kroku mogą się pojawić dodatkowe zadania, nowe lub wzięte z backlog lub mogą zostać jakieś zadania „zrzucone” do backlog. W tym kroku może także nastąpić wstępne przypisanie opiekunów elementów (wyjście z kroku) – na przykład zespół może określić, którymi zadaniami zajmie się w pierwszej kolejności i kto z zespołu podejmuje jakie kroki. Poszczególni członkowie zespołu sami wskazują, które zadania zamierzają zrealizować. Efektem jest zaktualizowany sprint backlog.
5) Potwierdź kompletność elementów
Krok, którego celem jest ostateczne potwierdzenie czy cały zespół wie i rozumie co jest do zrobienia, do czego dąży zespół (wskazane poprzez cel sprintu), jaki jest wstępny plan na realizację zadań oraz tego, że wszystkie konieczne zmiany w sprint backlog zostały wykonane.
6) Uruchom sprint
W tym momencie powstaje pewien rodzaj umowy między zespołem a product ownerem. Pozwala ona zespołowi skupić się na wykonywaniu zaplanowanych prac. Formalne uruchomienie sprintu następuje przeważnie w narzędziu wspierającym pracę zespołu, monitorowanie postępów, dokumentowanie działań. Takie narzędzie może także wspierać liczenie prędkości zespołu.

Powyższy proces jest ważnym elementem pracy w zespole agile’owym. Planowanie to ceremonia, która decyduje w dużym stopniu o tym jak dużymi krokami rozwija się produkt. Jeżeli capacity zespołu lub jego prędkość spada, zespół w porozumieniu z product ownerem podejmie na kolejny sprint mniejsze zobowiązanie. Efektem może być późniejsze dostarczenie oczekiwanej funkcjonalności dla klienta. Może także wystąpić sytuacja, gdy konieczne będzie ograniczenie wymagań odnośnie produktu.

Jak widać cel sprintu przewija się na każdym kroku tego procesu planowania. Pomaga decydować o tym, co powinno zostać podjęte w danej iteracji a co porzucone. Bez niego będzie o wiele trudniej. Planowanie jako czynność biznesowa, zgodnie z jej definicją, zakłada silną korelację między celem oraz sposobem dojścia do niego.

W definicji zawartej w business dictionary mamy zapis: „Podstawowa funkcja zarządzania obejmująca jeden lub wiele planów do osiągnięcia optymalnego połączenia potrzeb [czyli wymagań zapisanych w backlog i planie rozwoju produktu] z dostępnymi zasobami [capacity zespołu, jego umiejętności]. Proces planowania obejmuje: (1) identyfikację celów do osiągnięcia; (2) definiuje strategię do ich osiągnięcia; (3) tworzy lub organizuje niezbędne środki [omawiane podczas planowania] (4) wdraża, prowadzi i monitoruje kroki z zachowaniem odpowiedniej sekwencji [codzienne daily pozwala na weryfikację postępu prac, identyfikację problemów]”. W nawiasach kwadratowych umieściłem komentarze odwołujące się do treści poruszonych powyżej podczas opisu procesu planowania w agile.

Myślę, że zdefiniowanie celu dla sprintu tworzy całość z ceremonią oraz jest spójne z rozumieniem procesu planowania.

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.

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.