Zróbmy więc wdrożenie którego nie przeżył nikt

Dobrze, może trochę przesadziłem. Nic mi nie wiadomo o ofiarach wdrożenia, ale gdyby jakieś były, to pewno byście o nich słyszeli.

Obiecałem dziś na moim Insta, że będzie historia …

Historia

To nie jest moja historia. Jestem w niej postronnym obserwatorem, jednak na tyle zafrapowanym, drapiącym się po głowie, że próbuję ratować świat z czwartego szeregu. Wiem, że nie uratuję, ale może ktoś uratuje czyjś.

O co chodzi

Jest sobie globalna firma sprzedająca globalny produkt do globalnego konsumenta przez globalnych sprzedawców (czy mówiłem, że to GLOBALNY produkt?). Przypominam więc, że mówimy o globalnym wdrożeniu ;). To znaczy, że wdrożenie odbywa się w 80 krajach, a jeden kraj to rynek od kilkudziesięciu tysięcy do kilkuset tysięcy aktywnych użytkowników. OK. Może nie jest to netflix, spotify but still …

Użytkownicy – sprzedawcy, logują się codziennie do programu lojalnościowego, aby wykazać przywiązanie do marki, promując nowe produkty, zdobywając punkty za zrobienie zdjęcia półki na której ów produkt się znajduje, czy wykonując inne rywalizacyjne, społecznościowe akcje. Ogólnie robią to, bo dostają punkty, z których mają jakieś benefity (promocje, nagrody itp.) co związuje ich z marką jeszcze bardziej a o to chodzi właśnie globalnemu podmiotowi 🙂

Rdzeniem systemu jest CRM, ale dookoła jest jeszcze kilka innych systemów. Użytkownicy mają tam utworzone konta, logują się za pomocą maila.

Zmiana

Logowanie się jednak do dwóch systemów (lub więcej) to jest jakaś trudność dla użytkowników. Dodatkowo została zidentyfikowana potrzeba logowania się do systemu lojalnościowego numerem telefonu.

Brzmi spoko. Dodatkowo idzie to w parze z małym refaktorem architektury. Czyli – wydzielmy część uwierzytelniania do osobnego system – zróbmy SSO. Nadal brzmi spoko. Otwieramy projekt.

Wybór pada na Azure B2C, ale w tej historii nie ma to większego znaczenia. Rozwiązanie oparte na jakiejś usłudze chmurowej w dzisiejszych czasach wydaje się oczywistym wyborem.

Migracja

Technicznie wygląda to tak, że teraz użytkownik, zamiast logować się do CRMa czy do SystemuX teraz będzie przechodził przez SSO Azura. W uproszczeniu flow migracji użytkownika wygląda tak. Dwa scenariusze:

1. Witaj sprzedawco, jeżeli logujesz się pierwszy raz przez Azure B2C (dla niego jest to przeźroczyste) wysyłam żądanie uwierzytelnienia do docelowego systemu. Poprawne uwierzytelnienie zwracane jest po podaniu maila i hasła (tego samego jak dotychczas). Jeżeli wszystko jest ok – użytkownik jest tworzony w Azure (zmigrowany). Może teraz np. dodać swój numer telefonu i nim się logować.
2. Witaj sprzedawco, system trzeci odpowiedział, że nie zna Twojego maila, proszę więc utwórz nowe konto (Azure B2c).

Ok, ale co w przypadku kiedy w 1. użytkownik zapomniał dotychczasowego hasła do CRMa? Żaden problem – generowane jest żądanie resetu hasła wysłane na podanego maila (też nic niezwykłego, standardowa procedura).

Gdzie te ofiary wdrożenia?

Projekt wykonany, przetestowany, różne scenariusze logowania sprawdzone, wszystko działa.

Teraz tylko brać market za marketem, customizować ich landing pages i jedziemy z nimi.

Pierwsze wdrożenie

Jak to przy wdrożeniach bywa, są trudności, błędy są na bieżąco naprawiane, dokręcamy wszystkie śrubki, wszystkie zespoły developersko wdrożeniowe – pełna para, ostatnie szlify –> pierwsze wdrożenie. Uff – sukces. Jesteśmy na prodzie. Dawej tego szampana. Medale rozdane.

I tutaj można by skończyć (pomimo jakiegoś tam podejścia trochę kaskadowego itp.), ale jak się pewnie domyślasz, coś chyba musiało pójść nie tak.

Przysłowiowy poniedziałek po wdrożeniu

– Hey Bob, hał ar ju, hał łos de łikend?

– Hiuston, łi hef a sirios problem

Znajome? 🙂

W kraju w którym odbyło się pierwsze wdrożenie, użytkownicy zaczęli zgłaszać problemy z logowaniem. Co więcej, średni ruch spadł o ponad 50% (sic!)

Co się stało?

Użytkownicy nie mogli się zalogować do systemu, bo zapomnieli haseł, które mieli zapisane w aplikacji (raz kiedyś wpisane i zapomniane). Ok, ale przecież migracja umożliwia reset hasła.

Tak. Prawda.

Niestety takie rozwiązanie nie działa gdy użytkownik zapomniał nie tylko hasła do systemu …

ale również do swojej skrzynki mailowej …

… kurtyna! …

To nie mój problem?

System po wdrożeniu działa poprawnie. Pamiętanie haseł do swoich prywatnych skrzynek mailowych nie jest odpowiedzialnością tego systemu. Jak pewnie możesz się domyślić, do biznesu to nie przemawia. Biznes jednego dnia stracił 50% ruchu aktywności użytkowników. To jest PROBLEM. Pytanie czyj i kto powinien go i jak rozwiązać. Nikt nie mógł tego przewidzieć, że użytkownicy nie pamiętają haseł do swoich skrzynek mailowych.

Konkluzje i konsekwencje

Być może to kwestia tego tylko kraju (kraj Ameryki Południowej), gdzie jak się okazało skrzynki zostały stworzone na jakieś fejkowe maile, tylko po to, aby zalogować się do tego systemu lojalnościowego.

Wdrażając zmianę do tak różnych rynków w tylu krajach, nie wiesz jak społeczność danego kraju traktuje taki byt jak adres mailowy. W tym konkretnym kraju i na te potrzeby założenie które jako mieszkańcy europy traktujemy jako pewnik, okazało się błędne.

Zabrakło wnikliwej analizy i szerszego kontekstu na poziomie ogółu – jak ludzie kraju X używają “technologii” jaką jest skrzynka mailowa. Nikt, nie sprawdził do końca w jaki sposób zarządzają kontem społecznościowym. Zresztą, jeżeli te maile zostały jakoś wygenerowane na potrzeby kont – nie znamy do końca tego procesu. Więcej jest tu pytań niż odpowiedzi.

W konsekwencji pierwszego wdrożenia kolejne rynki zostały poinformowane o zaistniałej sytuacji, więc mogły uruchomić kampanie uświadamiające użytkowników. Kolejny kraj ameryki wstrzymał jednak wdrożenie do momentu zweryfikowania sytuacji z kontami u siebie, nie chcąc podejmować ryzyka tak dużej utraty rynku.

W przypadku tego pierwszego wdrożenia, jedynym rozsądnym rozwiązaniem które nie spowoduje problemów z bezpieczeństwem jest zmapowanie istniejących maili z numerami telefonów … które jakoś użytkownicy musieliby przekazać przez istniejący system (nie jest to trywialne i wymagałoby customowego developmentu). Trzeba pamiętać, że “system” lojalnościowy to jedyna forma kontaktu z tymi użytkownikami, ponieważ nie możemy do nich wysłać maila z żadnym komunikatem, bo skrzynki mailowe nie są przez nich używane.

Oczywiście można by stworzyć im nowe konta lojalnościowe, ale wtedy stracą swoje “punkty” i inne rangi (ewentualnie później powiązać te konta – ale to jest sporo pracy na pierwszy rzut oka). Z drugiej strony, jeżeli ktoś nie ma dostępu do swojej skrzynki mailowej na której adresie używa danej aplikacji to czy powinniśmy się tym przejmować?

… niech rzuci pierwszy kamieniem ten/ta komu się to nigdy nie przytrafiło 😉

Co dla mnie i dla Ciebie z tej historii?

Again. Nigdy nie bierz rzeczy “pewnych” za pewne. Zostało tutaj poczynione niejawne założenie. Za mało zrozumienia użytkownika w jaki sposób pracuje z aplikacją, ale też kontekstu historycznego jak były zakładane konta itp.

Weź pod uwagę nie tylko język i czas danego kraju przy wdrożeniu, ale też “mindset” i kulturę używania technologi!

Jeżeli wdrażamy coś w dużej skali, wybierzmy sobie reprezentatywne markety na POC. Po wdrożeniu monitorujmy sytuację. Wtedy dopiero planujmy kolejne.

A Ty?

co byś zrobił/a na miejscu biznesu?

co byś zrobił/a na miejscu zespołu wdrożeniowego?

co byś zrobił/a na miejscu zespołu developerskiego?

co byś zrobił/a na miejscu sprzedawcy z “egzotycznego” kraju?

Chcesz się podzielić swoim poniedziałkiem po wdrożeniu 🙂 Zapraszam do komentarzy i na Insta lub Twittera