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.

Reklama

Pytania o kroki procesu ręcznego

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

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

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

• zweryfikować kroki będące objawami marnotrawstwa – np. zbieranie podpisu od klienta,
• określić kroki tworzące wartość dodaną – np. możliwość pożyczenia żelazka,
• wykorzystać doświadczenia reinżynierii lub benchmarkingu proccesów – wystarczyłoby odwiedzić inny hotel i zobaczy jak rozwiązał proces.

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

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

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

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

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

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

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

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

Zwinne modelowanie?

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

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

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

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

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

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

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

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

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

Tempo realizacji reengineeringu

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

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

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

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

Rózwój procesu jako likwidacja jego luk

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

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

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

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

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

Założenia procesu – warstwa reinżynierii

Załóżmy, że:

• mamy wdrożyć rozwiązanie informatyczne do obsługi dla procesu sprzedaży produktu przez internet;
• w przedsiębiorstwie istnieją systemy zarządzania relacjami z klientem, zarządzania łańcuchem dostaw
• proponowane rozwiązanie ma zintegrować różne systemy występuje w przedsiębiorstwie

W takiej sytuacji analizę można rozpocząć od odpowiedzi na następujące kategorie pytań:

• Jakie udogodnienia oferowane są dla klienta?
• W jaki sposób firma chce wspomagać decyzje klienta?
• Jaki są cele firmy oraz procesu?
• Z jakich źródeł danych proces może, ma, musi korzystać?
• Jakie systemy informatyczne będą wykorzystywane w procesie?
• Jakie informacje firma posiada o rynku, o klientach, jakie informacje potrafi zdobyć?
• Jakie znaczenie ma dany proces wśród procesów przedsiębiorstwa?

Można zadawać kolejne pytania. Celem ich jest ustalenie tzw. kontekstu procesu (który docelowo przyczynia się do stworzenia tzw. słownika procesu). Uzasadnieniem tego faktu jest to, iż odpowiedzi na powyższe pytania są uzależnione od gałęzi/dziedziny gospodarki, w którym ma miejsce dana sprzedaż, czy obsługa klienta. Innego typu zależności będą występować w przypadku sprzedaży elementów wyposażenia mieszkania, a inne w przypadku przemysłu spożywczego.

Prowadząc taką analizę, poruszamy kwestie dotyczące dwóch warstw procesu. W przypadku założonego procesu, warstwa reinżynierii mogłaby w skrócie przebiegać następująco:

1. Zapoznanie się z ofertą/produktami
2. Wybranie produktu i złożenie zamówienia
3. Przekazanie oraz przetworzenie zamówienia
4. Sprawdzenie możliwości realizacji zapłaty
5. Sprawdzenie możliwości dostarczenia produktu
6. Ustalenie sposobu/miejsca dostarczenia
7. Realizacja zamówienia
8. Obsługa posprzedażna oraz transakcje powiązane

Warstwy procesu

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

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

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

Kryteria wyboru procesu

W ramach etapu 2 reengineeringu następuje wybór procesu. Podmiot gospodarczy może wybrać proces wg wielu kryteriów. A. Węgrzyn w książce pt. „Benchmarking. Nowoczesna metoda doskonalenia przedsiębiorstwa.” wskazuje takie kryteria:

• kryterium skali problemów powodowanych przez dany proces,
• kryterium znaczenia danego procesu dla prawidłowego funkcjonowania firmy,
• kryterium kosztu,
• kryterium terminowości,
• kryterium tego, jak prawdopodobne są korzystne efekty rekonstrukcji danego procesu.

Reengineering – identyfikacja procesów

Pierwszym etapem reengineeringu, bardzo ważnym dla efektów całego działania, jest identyfikacja procesów biznesowych, które zachodzą w firmie. Działania, ich dokładność, poziom szczegółowości w ramach etapu wpływają na korzyści z zastosowania reengineeringu. Należy zwracać uwagę zarówno na te procesy opisane, jak i ukryte. Pracownicy mogą nie mieć świadomości, że pewne ich działania są częścią większego procesu – efekty ich pracy stają się wejściem dla działań innej jednostki bądź osoby.

Firma powinna odejść od patrzenia na działalność firmy poprzez strukturę organizacyjną, podział funkcjonalny. Powinna nauczyć się patrzeć całościowo. W procesach uczestniczą różne jednostki organizacyjne, które wykonują zróżnicowane czynności/zadania. Trzeba ułatwić komunikację między nimi, usprawnić wymianę informacji, zminimalizować przerwy między końcem jednego etapu a początkiem następnego.

Etap ten skupia się na identyfikacji procesów biorąc pod uwagę czas, koszt, znaczenie (priorytetu), problemy pojawiające się przy realizacji danego procesu. Należy także zdefiniować początek i koniec procesu. Istotne jest to, aby zwrócić uwagę pracownikom co jest rozumiane jako krok procesu, aby odpowiadając na pytania zespołu analitycznego, mogli wskazać wszystkie zależności między ich pracą a pracę innych pracowników podmiotu gospodarczego. Konieczne jest stworzenie atmosfery, która pozwoli na swobodne wyrażanie opinii o procesach i zgłaszanie uwag/problemów.

Reengineering a komunikacja w firmie?

„Restrukturyzacja procesów, która zgodnie ze swą ideą przebiega poprzez przemyślenie i zaprojektowanie od nowa procesów, może spowodować, że zostaną naruszone aktualne kanały komunikacji między różnymi pracownikami. Pracownicy, którzy wymieniają między sobą informacje lub dzielą się wiedzą, w wyniku zmiany przebiegu procesu, jego zinformatyzowania, mogą stracić połączenie między sobą. Mogą się nie odnaleźć w nowych realiach funkcjonowania przedsiębiorstwa. Jeden z pracowników może zostać przeniesiony lub zwolniony, ponieważ jego umiejętności mogą zostać ocenione jako już nieistotne. Firma traci pewien zasób wiedzy, a pracownik, który się z nim komunikował musi poszukać nowej osoby, która pozwoli mu na starcie swoich doświadczeń z nowym kontekstem, z doświadczeniami innych. Firmy decydujące się na przeprojektowywanie procesów biznesowych często nie zdają sobie sprawy z kanałów, sieci połączeń występujących poza określonymi grupami roboczymi.”

Więcej o wpływie reengineeringu na komunikację w firmie można przeczytać w artykule.