Komunikacja jako efekt procesu

Ostatnio na blogu „Analiza systemowa”  przeczytałem artykuł „Nie ulec pokusie zadowolenia wszystkich”  i zacząłem się zastanawiać co poza wymienionymi krokami oraz wskazanymi w komentarzu można zrobić.

Pierwsza myśl to kwestia zarządzania ryzykiem, do czego można podejść zgodnie z PROCĄ, o której pisałem wcześniej. W szczególności ma to istotne znaczenie, gdy wchodzimy z nowym produktem, do nowej grupy odbiorców na danym rynku lub chcemy zaistnieć na nowym rynku. To, co może się wydarzyć na rynku lub „wrócić” w postaci informacji zwrotnej od użytkowników powinno być przedmiotem zarządzania ryzykiem. Np. Jednym z zagrożeń może być niewłaściwe wykorzystanie produktu lub nieprzyjęcie się produktu na rynku. Wskazane w komentarzu do artykułu pojawienie się substytutów także jest pewnym ryzykiem. Dla każdego zidentyfikowanego w ten sposób ryzyka można przygotować odpowiednią strategię postępowania i z dużym prawdopodobieństwem można powiedzieć, że nie będzie to akceptacja. Bardziej skłaniałbym się ku zapobieganiu. A co może tym pomóc? Właśnie druga kwestia, o której warto pamiętać…

Komunikacja. Wdrożenie produktu, począwszy od jego opracowania, przez przygotowanie po działania promocyjne jest swego rodzaju procesem. Na każdym jego etapie konieczne jest patrzenie przez pryzmat tego, co chcemy zakomunikować i komu. Powyższy diagram prezentuje odbiorców komunikacji i przykładowe mechanizmy wspierające. Spirala na środku diagramu wskazuje, że komunikacja inicjowana jest wewnętrz firmy, najpierw w kierunku pracowników, którzy powinni rozumieć po co i co zamierza firma stworzyć i dla kogo, wprowadzane są badania rynku itd. Jest to „proces” ciągły, który jest inicjowany, a jego efekty są wykorzystywane w procesie wdrożenia nowego produktu i usługi. Komunikacja na poszczególnych ramieniach trójkąta musi być spójna. Nie ma nic gorszego jak sytuacja, gdy klient, który zachęcony reklamą dowiaduje się od pracownika firmy, że jest inaczej. Wspomniana trójca czas, koszt oraz jakość określa również ramy działań związanych z komunikacją, ponieważ komunikacja też kosztuje i jest kosztem wdrożenia lub utrzymania rozwiązania produktu, może już nie samego projektu, ale jest zestawiana z osiąganymi korzyściami z produktu.

Komunikacja osmotyczna = wzorzec publish/ subscribe?

Poprzedni wpis dotyczący komunikacji osmotycznej został skomentowany na innym blogu („Komunikacja osmotyczna czyli po Brzytwie przypadków użycia” na it-consulting.pl/blog), ze wskazaniem, że „komunikacja osmotyczna” to inna nazwa dla wzorca „publish/subscribe”. Muszę przyznać, że nie do końca się mogę zgodzić.

Należy zwrócić uwagę na pojęcie „Subscriber” – oznacza ono, że odbiorca podłączył się do huba, rozdzielnika, czy tematu. „Publisher” określa kto i do czego może się „subscriber” podłączyć. Komunikacja jest jednokierunkowa i wskazuje na pewne rozdzielenie „publikującego” oraz „subskrybującego”, o czym można poczytać na stronach MSDN.

W przypadku komunikacji osmotycznej jest mowa bardziej o dynamicznych rozwiązaniach, gdzie „odbiorcy” nie subskrybowali danej informacji, a jedynie reagują na nią bądź nie. Komunikacja jest w takiej sytuacji dwukierunkowa i nie ma określenia kto, czym może się zainteresować i czy może się wypowiedzieć. Reakcja odbiorcy może spowodować dalszą reakcję innych osób. O ile dobrze rozumiem w przypadku modelu „publish/subscribe” odbiorca komunikatu musiałby określić ponownie swoich „subscriber’ów”.

Moim zdaniem Alistair Cockbourn spojrzał z wyższego poziomu abstrakcji i nie skupił się na rozwiązaniu systemowym. Rozwiązanie z wzorcem „publish/subscribe” umiejscawia rozważania na poziomie rozwiązań informatycznych, wspierane przez odpowiednie modele, narzędzia, opisy wymagań. Jednakże nie zawsze o to chodzi.

Dlatego też, brzytwa Ockhama raczej nie znajduje tutaj zastosowania – trudno mówić o powieleniu bytów. Jednakże zaznaczam, że jest to moja opinia. Mogę się jedynie zgodzić, że od komunikacji osmotycznej możemy przejść do wskazanego wzorca, choć można by spróbować także poszukać innych rozwiązań „biznesowych” wspominanych przy metodach zwinnych.

Komunikacja osmotyczna a proces

Załóżmy, że w pewnej jednostce ma miejsce proces składający się z 4 kroków.  W celu zaspokojenia potrzeby inicjatora procesu należy zawsze wykonać wszystkie 4 kroki. Każdy z kroków realizowany jest w osobnym 4 osobowym zespole. Taką sytuację obrazuje poniższy diagram:W trakcie procesu, wykonawca kroku 2, po jego podjęciu z wewnętrznej kolejki zadań, zwraca się do pozostałych członków zespołu z pytaniem. Elipsa umiejscowiona wokół wykonawcy obrazuje potencjalnych odbiorców zadanego pytania. Jedni z nich zareagują na pytanie, a inni nie. Najprawdopodobniej odpowiedź padnie od członków zespołu, jednakże może także wywołać reakcję członka zespołu odpowiedzialnego za krok 3. Może to być prosty komunikat o czym nie można zapomnieć albo na co zwrócić uwagę podczas realizacji zadania.

Jest to specyficzne dla tzw. komunikacji osmotycznej, która może pozytywnie wpłynąć na realizację procesu. Słyszenie o problemie lub poznanie go z wyprzedzeniem może ułatwić rozwiązanie postanowionego problemu.

Alistair Cockburn przytacza na swojej stronie definicję stwierdzającą, że „komunikacja osmotyczna oznacza, że informacja przepływa w tle słyszana przez członków zespołu, dzięki czemu mogą zapoznać się z informacją jakby przez osmozę. Zwykle jest to realizowane przez zespół siedzący w jednym pomieszczeniu. W momencie, gdy jedna osoba zadaje pytanie, inni w pomieszczeniu mogą albo zareagować lub zignorować pytanie, zaangażować się w dyskusję lub kontynuować swoją pracę.”

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.

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:

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

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

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

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

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

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

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.

Poziom akceptacji

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.

Poza basenem, czyli proces współpracy

W poprzednim wpisie, skupiłem się na procesie odbywającym się w ramach danej jednostki, gdy to pracownik odbiera bilet od pasażera i samodzielnie przeprowadza proces przy użyciu narzędzia. Cofnijmy się jednak o krok a dokładnie 2 kroki wcześniej, zanim konduktor rozpoczął weryfikację biletu. Z racji, że miałem bilet internetowy, najpierw zostałem poproszony o bilet a następnie o dokument osoby wskazanej na bilecie do potwierdzenia tożsamości. Te 2 kroki są zaprezentowane na poniższym diagramie.

prosba_o_bilet_1_450px

Na powyższym diagramie, można zauważyć, że także są wykorzystane tzw. baseny jednakże nie jeden, a dwa. Każdy z nich obrazuje innego uczestnika procesu a komunikacja odbywa się za pomocą komunikatów i reakcji na nie. Jest to tzw. proces współpracy (ang. collaboration process). W tym procesie pojawiają się już zdarzenia początkowe (ang. start event) i zdarzenia końcowe (ang. end event) w każdym z basenów oraz można powiedzieć, że nie jest on “ciągły” w ramach jednego basenu. Proces wychodzi jakby poza dany basen i oczekuje reakcji z drugiego basenu na wysłany komunikat.

Przykłady dla procesu współpracy w innych sytuacjach znajdują się w moich poprzednich wpisach: