Proces 3POL w handlu on-line

Ostatnio, w krótkim czasie przeczytałem dwa różne artykuły na temat sklepów internetowych i szeroko pojętego handlu on-line. Pierwszy z artykułów „Proces zakupu w e-sklepie – zwiększ zyski ulepszając koszyk na zakupy” (ze strony http://www.praktycznymarketing.pl/) skupia się na idei, powstaniu, analizie i możliwościach ulepszenia koszyka jako narzędzia obsługi sprzedaży internetowej. Drugi z kolei, został opublikowany w magazynie Gazeta MŚP. Artykuł pt. „Czy mój sklep internetowy jest efektywny?” skupiał się na możliwościach poprawy całego procesu. Trzeba przyznać, że obydwa artykuły mają jedną cechę wspólną – próbują w różnym czasie odpowiedzieć na dwa pytania:

• Jak zatrzymać klienta w sklepie?
• Jak spowodować, aby klient nie opuścił naszego sklepu bez wykonania zakupu?

Gdyby poszperać w Internecie można by jeszcze poszukać wcześniejszego artykułu o problemach związanych z tworzeniem się sklepów internetowych i zachęcania potencjalnych klientów do wykonywania zakupów on-line.

Kwestie te układają się w 3 etapowy proces (proces 3POL): Przyciągnij->Przeprowadź->Popraw on-line.

Każdy z tych etapów zależy od realizacji poprzedniego, a dokładnie od wyników poprzedniego etapu. Można by rozrysować wejścia i wyjścia poszczególnych kroków. Dodatkowo ostatni krok może wpłynąć również na pierwszy.

Na przykład, w ramach analizy zachowań użytkowników („Przeprowadź”) serwisu okazało się, że szukają oni możliwości zapłaty punktami popularnych sieci lojalnościowych. Gdyby hipotetycznie taki mechanizm udałoby się wdrożyć („Popraw”), to wtedy można byłoby puścić w mediach informację („Przyciągnij”), u nas zapłacisz („Przeprowadź”) tylko punktami lub podobnie.

Inny przykład, z analiz zachowań wynika, że użytkownicy bardzo często usuwają produkty z koszyka i dodają w ich miejsce nowe, podobne („Przeprowadź„). Takie wnioski aż proszą się, aby przeanalizować możliwość tworzenia 1 czy 3 koszyków tymczasowych lub o pomyśleć o innych udogodnieniach („Popraw„). Można także udostępnić wyszukiwarkę z rozszerzonymi opcjami i sprawdzić z których opcji najczęściej użytkownicy korzystają.

Reklama

Jak „podejmowane” są decyzje w procesie w BPMN?

Niektóre sklepy komputerowe stosują praktykę, że podczas rozliczania transakcji weryfikują cenę produktu z wewnętrzną bazą/stroną internetową. Klient wybierając produkt na półce prosi o jego udostępnienie, a następnie decyduje się bądź nie na jego zakup. W takim sklepie mówiąc, że jest zainteresowany, może usłyszeć, że cena jest wyższa, niższa lub taka sama. Poniższy przykładowy diagram w BPMN prezentuje właśnie taki proces – jest to proces, którego rzeczywiście doświadczyłem. Pozostawiłem pewne elementy bez ostatecznego rozwiązania, ponieważ każdy mógłby zachować się inaczej, sklep mógłby postąpić inaczej. Nie będę wskazywał jak postąpiłem, nie jest to istotne z punktu widzenia tematu, który chcę poruszyć.

W trakcie takiego procesu mamy różne momenty decyzyjne, oznaczone przez znaki w kształcie rombów na diagramie. W tym wypadku zostały zastosowane elementy charakterystyczne na diagramów w BPMN. Takie sytuacje zakupowe są idealnym przykładem do prezentacji elementów decyzyjnych na procesie. W powyższym przykładzie obydwa zastosowane elementy – „z pięciokątem w środku” oraz „z krzyżykiem” – oznaczają przypadki, gdy tylko z jedna z dalszych ścieżek diagramu może zostać zastosowana. Są one wyłacząjące się (ang. exclusive).

Pierwszy z nich – „z krzyżykiem” – opiera się na weryfikacji warunku, sprawdzeniu wartości dla określonych danych (ang. exclusive data-based). W przykładzie następuje sprawdzenie warunku dotyczącego ceny (na diagramie specjalnie go nie umieściłem aby to omówić w treści). Klient sprawdza, czy zawiera się w kwocie, którą przeznaczył na zakup. Sprzedawca porównuje dwie ceny – cenę z spółki i cenę z systemu. W zależności od wyniku następują różne komunikaty.

Drugi z nich – „z pięciokątem w środku” dotyczy oczekiwania na zdarzenie innej osoby, klienta, jako wynik jego zachowania, zrealizowanych działań (ang. exclusive event-based). W niniejszym przykładzie jest to wynik analizy produktu przez Klienta. Tak naprawdę sprzedawca może jedynie czekać, ponieważ nie wie co sprawdza Klient i jaka będzie jego ostateczna decyzja. Oczekuje określone zdarzenia – chcę kupić lub rozmyśliłem się. Można by jeszcze dodać opcję – chciałbym zobaczyć podobne produkty albo wróci do początku procesu.

Wyjątek czy alternatywa?

W trakcie przedstawiania abonenckiego modelu biznesowego wskazałem w części wykonywanej po stronie systemu dwie sytuacje, które kończyły proces z efektem innym niż oczekiwany przez użytkownika. Efektem oczekiwanym przez użytkownika było „Udostępnienie dokumentu”. Zamiast mogło się pojawić zdarzenie „Brak dostępu” lub zdarzenie „Brak opłaty”.
Potem trafiłem na artykuł o rozróżnianiu ścieżek alternatywnych i wyjątków, zamieszczony na stronie ModernAnalyst.com – „Document Decisions Separately and Explicitly – A Proposed Use Case Scenario Best Practice”. Artykuł wskazywał 2 pojęcia:

• „Alternate paths (options) are the result of an actor’s choice.”
• „Exception paths (errors) are the result of the system’s choice.”

Pierwsze z nicj wskazuje na alternatywne działania użytkownika, a drugie na działania systemu w wyniku napotkanych problemów (wyjątków). Rozróżnienie takie jest jak najbardziej logiczne, ponieważ użytkownik często ma wiele opcji do wyboru. Każda z nich może zakończyć się poprawnie lub zostać przerwana. Przerwanie może być wynikiem błędu użytkownika, brakiem wykonania pewnych działań poza systemem lub po prostu natrafieniem przez system na wyjątek. Wyjątki mogą być różne. Przykładem dla tych drugich są wskazane powyżej sytuacje, w których system wykonując zaplanowane sprawdzenia trafia na wyjątek, co nie pozwala na prawidłowe zakończenie procesu, czyli przejście tzw. ścieżki głównej (przejście procesu bez wyjątków, do „Udostępnienia dokumentów”). Więcej o wyjątkach we wpisie „Obsługa wyjątków w wymaganiach”

Co może być przykładem alternatywnego działania użytkownika?

Na powyższym diagramie (przykład w BPMN) zaprezentowano dwie ścieżki obsługi przez użytkownika sytuacji, gdy otrzyma komunikat o braku dokonania opłaty. Pierwsza z nich pozwala na prawidłowe dokończenie procesu – uzyskanie dostępu do poszukiwanego dokumentu. Druga z kolei, powoduje, że użytkownik przestaje korzystać z usług serwisu. Dzięki przedstawieniu różnych opcji użytkownika, obok tych standardowych, otrzymujemy pełniejszy obraz procesów, które mogą wystąpić w danym modelu biznesowym. W przedstawianym przekładzie mogą to być: „Rejestracja”, „Wyszukiwanie zasobów”, „Rezygnacja”, lub „Opłacenie”.