Sklepy Internetowe są narażone na wystąpienie problemu na każdym etapie obsługi zamówienia. Problemy z bazą danych mogą uniemożliwić użytkownikowi złożenie zamówienia. Żle wgrany patch może spowodować nieprzewidywalne zachowanie się systemu, który albo nagle zacznie "gubić zamówienia", albo będzie zmieniał ich zawartość. W bardziej złożonych systemach, kłopoty sprawiają interfejsy z zewnętrznymi aplikacjami, takimi jak narzędzia do obsługi magazynu czy finansowo-księgowe. Brak porządnie przeprowadzonych testów regresji (zgodności wstecznej z nową funkcjonalnością) może unieruchomić sprzedaż na długo. Im większa firma, im więcej punktów styku, tym większe prawdopodobieństwo wystąpienia błędu. Szybkie jego usunięcie zależy od sprawnego rozwiązania pięciu zagadnień:

1. Analiza: szukaj rozwiązania a nie winnego

Najczęstszym błędem popełnianym w sytuacji kryzysowej jest uciekanie od istoty problemu i szukanie przede wszystkim głowy do ścięcia. Przez całą firmę przelatują dziesiątki maili pełnych wzajemnych oskarżeń i usprawiedliwień. W CC takich wiadomości prawie zawsze występują licznie nazwiska dyrektorów, wiceprezesów, a nawet prezesów. Takie boksowanie zużywa od kilku godzin do kilku dni, podczas gdy problem narasta lub jego rozwiązanie się oddala.

Dlatego w przypadku wykrycia błędu pierwszymi czynnościami do wykonania są

1. Dokładna diagnoza problemu. Jeśli jest błąd, to musi mieć on swoją przyczynę. Bez jej wykrycia nie uda się żaden z następnych kroków. Identyfikacji musi podlegać zarówno konkretny fragment systemu / oprogramowania, który generuje błąd, jak i sposób w jaki się pojawić (o ile wcześniej nie było). Odkrycie, że złe wyświetlanie cen jest spowodowane złym znakiem dziesiętnym (np. kropka zamiast przecinka), powstałym po ostatnim imporcie cennika, jest może banalne. Ale pozwala na zaplanowanie dalszych działań. Jeżeli diagnoza będzie nieprecyzyjna lub błędna, dalsze działania mogą doprowadzić do eskalacji skutków i zwiększyć koszt walki z kryzysem.
2. Podjęcie działań minimalizujących skutki. Czasami trzeba wyłączyć sklep, żeby nie generować zamówień niemożliwych do obsłużenia lub potencjalnie groźnych dla wizerunku firmy bądź kosztów (w obsłudze klienta, reklamacjach itp.). Czasami trzeba będzie zrezygnować z części automatycznych działań na rzecz dokładnej, ręcznej weryfikacji każdej faktury, przesyłki czy listu przewozowego.

Mając te dwie czynności za sobą można przystąpić do przygotowania procesu naprawczego. Oczywiście, w realnym świecie, od osoby zarządzającej sklepem wymaga się symultanicznego rozwiązania tych zagadnień. Działania minimalizujące skutki i program naprawczy powinny pojawić się niemal jednocześnie. O ile jest to oczywiście możliwe - czasami problem jest zbyt skomplikowany, żeby w kilkadziesiąt minut wypracować jego rozwiązanie. Plan naprawczy powinien uwzględniać elementy systemu wymagające poprawienia, czas ich realizacji oraz zespoły, które się tym zajmą.

2. Zlecenie: konkretne czynności dla konkretnych osób

Plan ma szanse zostać zrealizowany wyłącznie wtedy, gdy za rozwiązanie poszczególnych zadań będą odpowiedzialne konkretne osoby, a czas rozwiązania zadania zostanie z nimi dokładnie skonsultowany. Nieważne czy zrobią to osobiście, czy wyznaczą podwładnych. Ważne, bo to Pan Kowalski był rozliczany z postępu w pracach.

3. Wsparcie: bądź centrum kompetencji

Skoro są osoby odpowiedzialne za poszczególne zadania, musi również pojawić się koordynator całego procesu. Czasami zostanie na niego wyznaczony pracownik działu Helpdesk. Częściej będzie to jednak właściciel sklepu lub całego procesu eCommerce po stronie biznesowej lub działów IT (w mniejszych firmach z reguły będzie to jedna i ta sama osoba). Z mojego doświadczenia wnioskuję, że najskuteczniejszą osobą jest właściciel biznesowy platformy - to jemu najbardziej zależy na rozwiązaniu problemu.

Rolą koordynatora jest

1. Zapewnienie dostępności zasobów. Często usunięcie poważnego błędu będzie wymagało oderwania wielu osób od ich codziennej pracy i skierowania do nowych obowiązków. Żadnemu szefowi to się nie spodoba. Bardziej skomplikowane awarie będą wymagały wspólnej przestrzeni pracy - sali konferencyjne, tele- lub wideokonferencji, Internetowego chatboardu.
2. Zapewnienie wiedzy. Koordynator musi agregować wiedzę docierającą do niego z różnych miejsc, segregować ją pod kątem poprawności i przydatności i dystrybuować dalej, unikając przeładowania informacjami członków zespołu.
3. Trzymanie "książki kontaktowej". Czasami do wyjaśnienia problemu niezbędne będzie zdobycie wiedzy od osób spoza zespołu kryzysowego. Te osoby trzeba zidentyfikować, następnie trzeba im konkretnie powiedzieć jakich informacji muszą udzielić, a następnie dokonać dystrybucji pozyskanego materiału do osób zainteresowanych.

4. Monitoring: pańskie oko sklep uleczy

Nie ma nic gorszego niż zostawienie problemu bez nadzoru. Cykliczne monitorowanie postępów prac naprawczych może być irytujące, ale jest skuteczne. Oczywiście częstotliwość należy dobrać ostrożnie. Zadawane co 10 minut pytanie "Jak idzie?" nie przybliża rozwiązania, a adresata pytania może doprowadzić do ataku furii. Warto natomiast:

• Potwierdzać dostarczenie wszystkich narzędzi i informacji - "Dotarł do Ciebie mój mail z danymi? Nie? Zaraz wypalę na płycie i podrzucę Ci na biurko!)
• Kontrolować czas wykonania zadania - "Godzinę temu mówiłeś, że to zajmie najwyżej 10 minut. Są jakieś nowe problemy?"
• Rozładowywać pojawiające się niebezpieczne napięcie mogące skutkować destrukcyjnym konfliktem wewnątrz zespołu - "Wiem, że siedzicie tu już 12 godzin. Zamawiam pizzę na koszt firmy. Co sobie życzycie?"
• Negocjować - "OK. Napisanie sklepu od nowa zgodnie z Twoją propozycją zajmie nam zbyt dużo czasu. Zostawienie obecnej sytuacji też nie wchodzi w grę. Znajdźmy rozwiązanie pośrednie."

Zespół MUSI czuć, że koordynator interesuje się rozwiązaniem problemu i chce pomóc, zamiast stawiać się w roli poganiacza niewolników.

5. Potwierdzenie: Wszyscy wiedzą, że jest OK

Mamy już 100 proc. cząstkowych zleceń zamkniętych. Poszczególni członkowie zespołów meldują wykonanie swoich zadań. Ale po spięciu wszystkiego razem okazuje się, że dalej nic nie działa lub błąd zniknął w jednym miejscu... Aby pojawić się w następnym. A tymczasem nikogo w biurze już nie ma - pracownicy rozeszli się w poczuci dobrze spełnionego obowiązku.

Problem może zostać uznany za rozwiązany a zespół zwolniony z obowiązków dopiero w chwili, gdy wykonane zostaną wszystkie testy, a koordynator potwierdzi poprawność działania systemu! Członkowie zespołu muszą być tego świadomi i pozostawać do dyspozycji nawet po zrealizowaniu przydzielonych im zadań.

W przeciwnym wypadku zamiast pochwały od prezesa można oczekiwać kolejnej zawalonej nocy i następnego pasma siwych włosów na głowie.

Kto ma wykrywać błędy?

W dużych firmach informatycznych i telekomunikacyjnych pracują dedykowane zespoły testerów. Mają one doskonałe umiejętności w wykrywaniu błędów, ocenianiu wagi i opisywaniu. Niestety, najczęściej rola testerów kończy się w momencie tzw. release - przekazania oprogramowania do produkcyjnego działania lub dystrybucji. Potem wykrywanie błędów spada na barki użytkowników biznesowych - zwykłych pracowników firmy lub co gorsza klientów.

Lepiej, żeby problemy znajdywali ci pierwsi - dlatego muszą być świadomi swojego wpływu na jakość sklepu internetowego. Właściciel sklepu musi walczyć z podejściem typu "Do tej pory tak było i nigdy nic się złego nie działo", "Chciałem zgłosić, ale jakoś zapomniałem". I zapewnić, że wszyscy wiedzą jak i do kogo zgłaszać problemy, które znajdują.

It's not a bug! It's a feature!

Tak też może być. Po dokładnej analizie problemu okazuje się, że system działa zgodnie z oczekiwaniami... twórcy. Użytkownik biznesowy może jedynie mieć pretensje do niewystarczającej analizy wymagań. I doprowadzić do modyfikacji. Ale zarządzanie procesem wprowadzania zmian to już inny temat ;-)