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.

Reklama

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.

Reengineering – etapy w skrócie

Etapami składającymi się na proces reengineeringu są:

1. Identyfikacja procesów biznesowych, które zachodzą w firmie. 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. Więcej o tym etapie
2. Wybór procesu do reengineeringu. Firma nie jest w stanie podjąć się przeprojektowania wszystkich, czy też wielu procesów za jednym razem. Dlatego też musi wybrać określony proces. Więcej o tym etapie
3. Utworzenie zespołu reengineeringu. Wynikiem tego etapu jest określenie składu grupy roboczej, której zadaniem będzie przeprowadzenie reengineeringu.
4. Analiza procesu. Etap ten ma na celu określenie szczegółowego przebiegu procesu oraz określenie potrzeb klientów danego procesu.
5. Rekonstrukcja procesu. Odbywa się w całkowitym oderwaniu od procesu istniejącego.
6. Wdrożenie rekonstrukcji. Wdrożenie będzie przeprowadzane całościowo lub za pomocą projektów pilotażowych.

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

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?

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.

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

Zmienny chaos

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

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

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

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

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

Rózwój procesu jako likwidacja jego luk

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

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

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

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

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

Diagram klas – „reinżynieria” (etap 1)

Wcześniej zostały zaprezentowane dwa diagramy klas (pierwszy i drugi), które prezentowały w różny sposób, mniej lub bardziej poprawny, pewną dziedzinę. Na diagramach zostały wskazane metody, atrybuty oraz zostały opisane związki. Po dyskusjach na wcześniej wspomnianym forum, przemyślałem propozycje i postanowiłem, że stworzenie tego diagramu klas to będzie dobry przykład podejścia o charakterze reengineeringu lub benchmarkingu, zależy jak na to spojrzeć. Zacznę od początku, a to jest cecha bliska reengineeringu. Zastosuję wskazówki, wnioski z dyskusji, porównania się z doświadczeniami innych, co przypomina benchmarking (o różnicy między tymi dwoma podejściami, w zakresie procesów, postaram się napisać w kolejnym wpisie).

Kilka słów o tym, co chciałbym przedstawić:

• mamy klienta (klientów), który składa zamówienia on-line u dostawcy pewnych produktów,
• u dostawcy dostępne jest wiele produktów, o różnych cenach, parametrach, wadze itp.,
• zamówienie może się składać z od jednego do wielu produktów,
• za zamówienie klient może dokonać płatności na 3 różne sposoby: kartą kredytową, przelewem lub gotówką.

Mamy więc: Klienta, Zamówienie, Produkt oraz Płatność, co na diagramie można przedstawić następująco: