Dług zmiany, czyli co się dzieje, gdy organizacja przenosi problem na klienta

Duże zmiany organizacyjne często wyglądają dobrze z perspektywy prezentacji zarządczej.

Jest harmonogram. Są kamienie milowe. Jest projekt migracji. Są zespoły robocze. Jest komunikat, że proces został zakończony. Czasem nawet pojawia się zdanie o „sukcesie operacyjnym” albo „sprawnym przeprowadzeniu procesu”.

Problem zaczyna się wtedy, gdy po drugiej stronie tej zmiany stoi człowiek.

Klient. Pracownik. Użytkownik. Partner biznesowy.

Ktoś, kto nie patrzy na zmianę przez status projektu, tylko przez bardzo proste pytania:

Czy mogę korzystać z tego, co miało działać?
Czy wiem, co mam zrobić?
Czy ktoś mnie poinformował na czas?
Czy mam poczucie kontroli?
Czy w razie problemu dostaję spójną odpowiedź?

Jeżeli odpowiedź brzmi „nie”, to zmiana nie została dobrze przeprowadzona. Nawet jeśli formalnie została wdrożona.

Przeprowadzka bez kluczy

Kilka tygodni temu, jako wieloletni klient Citi, zostałem przeniesiony do VeloBanku. Przez blisko 20 lat korzystałem z usług jednego banku, po czym w wyniku dużej transakcji i migracji klientów znalazłem się w zupełnie nowej rzeczywistości.

Sama decyzja biznesowa nie jest tu najciekawsza. Firmy kupują, sprzedają, łączą się, przejmują aktywa, produkty i klientów. Tak działa rynek.

Ciekawsze jest to, jak taka zmiana została doświadczona przez klienta.

Na początku był problem podstawowy: poczucie braku pełnej, jasnej i wcześniejszej komunikacji. Klient banku nie ma obowiązku śledzić fuzji, przejęć i komunikatów branżowych. Ma natomiast prawo oczekiwać, że jeśli jego produkty, dane, dostęp do pieniędzy i codzienna obsługa zostają przeniesione do innej instytucji, to zostanie o tym poinformowany w sposób prosty, konkretny i z odpowiednim wyprzedzeniem.

Nie chodzi tylko o formalne spełnienie obowiązku informacyjnego.

Chodzi o doświadczenie zmiany.

Bo zmiana w banku to nie jest zmiana koloru ikonki w aplikacji. To dostęp do pieniędzy, poczucie bezpieczeństwa i zaufanie. Trzy rzeczy, których nie da się skutecznie migrować samym harmonogramem technicznym.

Operacja się udała, klient nadal czeka

Pierwsze dni po migracji były trudne. Problemy z dostępem, niepewność, trudność w uzyskaniu informacji, przeciążone kanały kontaktu. Można powiedzieć: zdarza się. Duże migracje bywają skomplikowane. Systemy bankowe są złożone. Dane są wrażliwe. Procesy regulowane.

Tylko że po kilku tygodniach nie mówimy już o pierwszym szoku.

Mówimy o jakości zmiany.

Minęły mniej więcej trzy tygodnie i okazało się, że coś, co miało zostać przeniesione automatycznie, w praktyce wymaga kolejnych działań po stronie klienta. Kolejnych dokumentów. Kolejnych podpisów. Kolejnych wizyt albo akceptacji w aplikacji. Kolejnych prób ustalenia, co właściwie działa, a co tylko wygląda, jakby działało.

Przykład?

Przelew własny z konta firmowego na konto osobiste.

Z perspektywy klienta to nie jest zaawansowana operacja finansowa. To raczej codzienna bankowa higiena. Loguję się, wybieram rachunek, robię przelew.

W praktyce okazało się, że funkcjonalność nie działa. W oddziale usłyszałem, że trzeba podpisać odpowiednie porozumienie dotyczące dostępu do konta i po 48 godzinach wszystko powinno zacząć działać. Procedura brzmiała rozsądnie: dokument, termin, oczekiwanie.

Mijają dni. Nie działa.

Telefon do banku przynosi inną informację: ta funkcjonalność w ogóle nie działa.

I tu zaczyna się prawdziwy problem.

Nie chodzi już tylko o niedziałającą funkcję. Chodzi o niespójność informacji, brak jasnej odpowiedzialności i poczucie, że klient sam musi koordynować proces, którego nie projektował.

Dług zmiany

W technologii mówi się często o długu technologicznym. To koszt decyzji podejmowanych szybko, tymczasowo, z założeniem, że „poprawimy później”.

Podobne zjawisko istnieje w zarządzaniu zmianą. Można je nazwać długiem zmiany.

Powstaje wtedy, gdy organizacja spieszy się z wdrożeniem, upraszcza komunikację, nie domyka procesów, nie przygotowuje ludzi z pierwszej linii, zakłada, że problemy „jakoś się obsłuży”, a klient lub pracownik „jakoś sobie poradzi”.

Tylko że „jakoś” rzadko oznacza dobrze.

Dług zmiany nie znika w dniu uruchomienia systemu. On tylko zmienia właściciela.

Najpierw jest po stronie zespołu projektowego.
Potem trafia do oddziałów.
Potem do infolinii.
Potem do reklamacji.
A na końcu ląduje u klienta.

Klient płaci za ten dług swoim czasem, cierpliwością i zaufaniem.

Dzwoni. Jeździ. Pisze. Podpisuje. Czeka. Tłumaczy swoją sytuację kolejnym osobom. Słyszy różne odpowiedzi w różnych kanałach. I z czasem przestaje pytać: „kiedy to zacznie działać?”.

Zaczyna pytać: „czy ktoś tam w ogóle widzi całość?”.

To bardzo niebezpieczny moment dla każdej organizacji.

Bo problemy techniczne można naprawić. Formularze można poprawić. Funkcjonalności można uruchomić. Ale poczucie, że nikt nie panuje nad sytuacją, zostaje znacznie dłużej.

Zmiana nie kończy się w systemie

Organizacje często patrzą na zmianę od środka.

Czy migracja została zakończona?
Czy system został uruchomiony?
Czy produkty zostały przeniesione?
Czy komunikaty zostały wysłane?
Czy zgody zostały zebrane?
Czy procedury są dostępne?

To ważne pytania. Ale niewystarczające.

Klient pyta inaczej:

Czy mogę zrobić przelew?
Czy wiem, co mam podpisać?
Czy informacja z oddziału i infolinii jest taka sama?
Czy ktoś potrafi mi powiedzieć, co naprawdę działa?
Czy muszę sam prowadzić prywatne śledztwo w sprawie własnego konta?

Jeżeli organizacja odpowiada na pytania wewnętrzne, ale nie odpowiada na pytania klienta, to zmiana jest domknięta tylko formalnie.

A formalne domknięcie zmiany nie oznacza, że ludzie jej doświadczają jako uporządkowanej, bezpiecznej i sensownej.

Automatyzacja bez odpowiedzialności

W tej historii szczególnie ciekawe jest napięcie między automatyzacją a odpowiedzialnością.

Z perspektywy klienta część rzeczy miała wydarzyć się automatycznie. Produkty miały zostać przeniesione, dostęp zachowany, funkcjonalności uruchomione, a nowa rzeczywistość miała po prostu działać.

W praktyce pojawiła się seria ręcznych działań: podpisz dokument, zaakceptuj regulamin, odwiedź oddział, poczekaj, zadzwoń, złóż reklamację, sprawdź ponownie.

Automatyzacja, która wymaga od klienta ciągłej interwencji, przestaje być wygodą. Staje się labiryntem.

A kiedy system pokazuje funkcję, która nie działa, klient nie myśli o architekturze IT, zależnościach procesowych ani wyjątkach migracyjnych.

Myśli prościej:

Dlaczego znowu tracę czas?

Lekcja dla każdej organizacji

Ta historia nie jest tylko o bankach.

To historia o każdej firmie, która przeprowadza zmianę i skupia się głównie na tym, żeby dowieźć projekt, a za mało na tym, żeby człowiek po drugiej stronie wiedział, co się dzieje.

Może chodzić o wdrożenie nowego systemu CRM.
Może chodzić o reorganizację.
Może chodzić o zmianę procedur obsługi klienta.
Może chodzić o nowy model pracy.
Może chodzić o połączenie firm.
Może chodzić o zmianę strategii.

Mechanizm jest podobny.

Jeżeli ludzie nie wiedzą, co się dzieje, zaczynają tworzyć własne interpretacje.
Jeżeli dostają niespójne informacje, tracą zaufanie.
Jeżeli muszą sami odkrywać proces, rośnie frustracja.
Jeżeli nikt nie bierze odpowiedzialności za całość, każda drobna trudność staje się dowodem chaosu.

Dlatego w zmianie nie wystarczy zaplanować system, proces i komunikat.

Trzeba zaplanować doświadczenie człowieka.

Co zobaczy jako pierwsze?
Czego się przestraszy?
Jakie pytania zada?
Gdzie utknie?
Kto mu pomoże?
Czy osoby z pierwszej linii będą mówiły jednym głosem?
Co zrobimy, gdy coś nie zadziała?

To są pytania, które często wydają się miękkie. W praktyce są bardzo twarde, bo wpływają na zaufanie, reputację, koszty obsługi, liczbę reklamacji i lojalność klientów.

Higiena zmiany

Po kilku tygodniach od migracji nie oczekuję cudów. Wystarczyłaby spójność.

Jeżeli coś nie działa, warto powiedzieć, że nie działa.
Jeżeli wymaga dokumentu, wszystkie kanały powinny mówić to samo.
Jeżeli funkcjonalność jest niedostępna, nie powinna udawać dostępnej.
Jeżeli klient ma coś zrobić, powinien wiedzieć dokładnie co, po co i z jakim skutkiem.

To nie są luksusy.

To higiena zmiany.

Zmiana nie kończy się wtedy, kiedy organizacja uzna, że ją wdrożyła. Zmiana kończy się wtedy, kiedy człowiek po drugiej stronie odzyskuje poczucie kontroli.

Może działać.
Wie, co ma zrobić.
Rozumie swoje opcje.
Dostaje spójne informacje.
Nie czuje się sam z konsekwencjami czyjegoś niedopracowanego procesu.

Bo w zmianie najważniejsze nie jest to, czy system raportuje sukces.

Najważniejsze jest to, czy człowiek po drugiej stronie nie czuje, że został przeniesiony jak mebel.

Nawet meble zabezpiecza się folią bąbelkową.

Klientów, pracowników i użytkowników warto zabezpieczyć jeszcze lepiej: dobrą komunikacją, spójnym procesem i odpowiedzialnością za całość doświadczenia.

Jeśli Twoja organizacja przygotowuje dużą zmianę: wdrożenie systemu, reorganizację, zmianę procesów lub integrację zespołów, warto zadać jedno pytanie wcześniej:

kto zapłaci dług tej zmiany, jeśli nie domkniemy jej dobrze?

W Agile For Future pomagamy projektować zmiany tak, żeby nie kończyły się na slajdzie, tylko działały w praktyce.


Napisz komentarz

Twój adres email nie zostanie opublikowany. Wymagane pola są oznaczone *