Gdy nie ma dwustronnej komunikacji

Ostatnio, korzystając z punktów sprzedaży związanych z telefonią komórkową, w celu naprawy telefonu, niestety doświadczyłem tego, co oznacza brak dwustronnej komunikacji. Jedna z sieci punktów sprzedaży korzysta, tak zrozumiałem, z usług serwisantów i w ich imieniu przyjmuje zgłoszenia naprawy, odbiera opłaty i przekazuje naprawione telefony klientom. Jak się okazało przy kontaktach z punktem, nie mają wiedzy co się dzieje ze zgłoszeniem, ile będzie trwać, jaki jest potencjalny koszt (pomimo, że wielu serwisantów podaje szacunkowe ceny prac), nie są w stanie od ręki sprawdzić statusu zgłoszenia, a także nie przewidują elektronicznego rozliczania się opłatami z tytułu napraw.

Najciekawsze w tym wszystkim jest to, że dziwią się potem, że komunikacja z Klientem odbywa się w innej formie niż przekazana Klientowi – zamiast dzwonić piszą smsy, a zamiast wiadomości sms pojawiają się telefony. Dodatkowo nie wskazują ograniczeń w płatności za usługę. Obsługa spraw skutecznie zniechęca do kolejnych kontaktów z danym punktem.

Jak się okazuje, proces wygląda jak na poniższym diagramie.

punkt_sprzedazy450

Co można byłoby wprowadzić w celu usprawnienia procesu?

  • zdalne zgłaszanie w systemie serwisanta telefonów do naprawy;
  • sprawdzanie statusu po danych identyfikacyjnych sprawy;
  • ustawianie w momencie zrealizowania płatności np. kartą w punkcie sprzedaży, automatycznej transakcji obciążenia na rzecz serwisanta. Odpowiednie oznaczenie przelewu w łatwy sposób pozwalałoby zidentyfikowanie pobranych opłat po stronie serwisanta;
  • informowanie serwisanta cyklicznie o sprawach do odebrania z danego punktu sprzedaży;
  • wysyłkę wiadomości sms o przyjęciu zgłoszenia, zakończeniu realizacji, przekazaniu do punktu sprzedaży, zgodnie ze zmianą statusu sprawy;

Można powiedzieć, że zabrakło mechanizmów pozwalających na dwustronną komunikację między serwisantem a pośrednikiem (punktem sprzedaży). Taki brak komunikacji odbija się na Kliencie, który nie wie z kim rozmawia. Klienta nie interesuje, kto fizycznie naprawia telefon, dla niego istotne jest to, aby zgłoszenie zostało przyjęte, otrzymał uzgodnione informacje (np. o wycenie, czasie realizacji) i został poinformowany o możliwości odbioru telefonu po zakończeniu naprawy. Chodzi przede wszystkim o odpowiedź na pytanie o przebieg realizacji zgłoszenia. W opisanym przypadku zmaterializowały się wszystkie rodzaje ryzyk – operacyjne, interpretacji, terminu oraz niespełnienia oczekiwań klienta.

Tłumaczenia w stylu, że my jesteśmy tylko pośrednikiem, nie odpowiadamy za realizację są nieprofesjonalne, jeżeli oddaję telefon do naprawy w danym punkcie. Podobnie odsyłanie Klienta bezpośrednio do serwisanta aby z nim wyjaśniał różne kwestie, jest strzałem w stopę. Rozumiem, że chcą odesłać swoich klientów do innego podmiotu, nawet jeżeli na przykład, przy okazji, klient byłby zainteresowany wykupieniem jakiś dodatkowych usług lub produktów. Przez brak odpowiedniej komunikacji tracą szansę na dalszą sprzedaż/obsługę, niestety.

Reklama

Diagram venna ponownie w akcji

W ostatnim wpisie poruszyłem uwierzytelniania oraz autoryzacji użytkownika, w ramach którego elementami są:

  • użytkownicy, którą próbują skorzystać z zasobów/aplikacji;
  • żądania wykonywane przez użytkowników, choćby takie podstawowe jak utworzenie (ang. create) , odczyt (ang. read), zmiana (ang. update) lub usunięcie (ang. delete) obiektów;
  • kontrola dostępów do wykonania poszczególnych żądań;

Elementy te można zobrazować na diagramie Venna.

vienna_uprawnien_v1

W momencie, gdy użytkownik wywołuje żądanie, do którego miał przypisany (nadany) dostęp, to zostanie ono wykonane – jest to sytuacja z samego centrum diagramu, oznaczona jako obszar A.

W przypadku użytkowników, w danym momencie, możemy mówić o trzech sytuacjach:

  • użytkownicy bez dostępu i możliwości zgłoszenia żądania (obszar bez fragmentów wspólnych z pozostałymi) – obszar z nazwą Użytkownicy;
  • użytkownicy z nadanymi dostępami, ale z nich nie korzystający – obszar B;
  • użytkownicy próbujący wywoływać żądania bez nadanych dostępów – obszar C;

W przypadku dostępów,w danym momencie mamy:

  • dostępy, które nie są możliwe do wykorzystania poprzez żądania użytkownika – obszar z nazwą Dostępy;
  • dostępy przypisane do użytkowników – obszar B;
  • dostępy przypisane do określonych żądań – obszar D;

W przypadku żądań w danym momencie mamy:

  • żądania, które nie są wykonywane przez użytkowników, bez przypisanych dostępów – obszar z nazwą Żądania;
  • żądania, które próbują wywołać użytkownicy, dla których nie są przewidziane takie dostępy – obszar C;
  • żądania, które mają przypisane dostępy, ale nie są wywoływane przez użytkowników – obszar D;

Powyższe rozróżnienia to próba spojrzenia na autentykację i autoryzację użytkowników, zalogowanych lub nie do systemu w danym momencie. To tak jakby w pewnym momencie zamrozić stan systemu, z wywoływanymi żądaniami użytkowników.

Autentykacja lub/i autoryzacja – razem czy osobno?

Wiele aplikacji dostępnych przez przeglądarkę lub jako osobny program wymaga przejścia ekranu logowania się. Należy podać login/identyfikator/e-mail oraz hasło. System w odpowiedzi sprawdza, czy dane są prawidłowe. W przypadku błędu weryfikacji, nie pozwala na przejście dalej. Jeżeli są poprawne, udostępnia aplikację. Nie wszystkie jednak opcje mogą być dostępne dla danego użytkownika – choćby w aplikacji próbnej lub z rozbudowaną hierarchią użytkowników.

Pierwszy etap to tzw. autentykacja (ang. authentication) lub bardziej po polsku uwierzytelnianie użytkownika. Jest to czynność realizowana na bazie komunikacji użytkownika i systemu, mająca sprawdzić, czy użytkownik (osoba logująca się) jest tym, za kogo się podaje. Weryfikacja polega na sprawdzeniu jest autentyczności. Odbywa się to przy założeniu, że tylko określony użytkownik zna/posiada parę login/hasło lub dodatkowe elementy używane przy identyfikacji (odpowiedzi na zdefiniowane pytania, tokeny). Czasami ta czynność może odbywać się w sposób niezauważalny dla użytkownika (w zależności od zastosowanych mechanizmów). Jest to pierwszy krok na poniższym diagramie.

autentyk450

Drugi etap to autoryzacja, czyli sprawdzenie, czy ropoznany użytkownik ma uprawnienia do dostępu/wykorzystania lub innej czynności wykonywanej na danym obiekcie. O autoryzacji pisałem w poprzednim wpisie (czyli o umożliwieniu instalacji na stacji roboczej). Jest to trzeci krok na powyższym diagramie.

Trudno mówić o poprawnym przeprowadzeniu procesu autoryzacji bez informacji o użytkowniku, w “imieniu” którego ten proces ma zostać przeprowadzony. Można stwierdzić, że wynik procesu uwierzytelniania jest wejściem dla procesu autoryzacji. Z tego wniosek, że te procesy przeważnie występują razem, o ile aplikacja, system informatyczny lub dane takiej kontroli wymagają. W pewnych sytuacjach, autoryzacja może nastąpić jedynie o dane identyfikacyjne skąd nastąpiło żądanie – np. określony numer MAC komputera przy dostępie do sieci bezprzewodowej. Choć w sumie weryfikacja numerów MAC jest pewnym rodzajem autentykacji (podobnie jak para login/hasło lub linie papilarne zapisane w bazie).

Zainteresowanych szczegółami różnych sposobów autoryzacji oraz uwierzytelniania odsyłam na przykład do książki „Bezpieczeństwo danych w systemach informatycznych„.