Punkty przełamania dla usługi

Czasami korzystam z przejazdów taksówkami. Najczęściej w momencie zamówienia słyszę, że czas oczekiwania na przyjazd: „do 10 min”. Oczekuję jednak, że ten czas będzie krótszy i równocześnie nie będę musiał stać na dworze i czekać. Nie potrzebuję innych możliwości poza pewnością, że taksówka w czasie tego czasu przyjedzie. Gdy otrzymuje sms o tym, że taksówkarz już nadjechał jest to dla mnie coś dodatkowego, powodującego, że następny razem prawdopodobnie skorzystam z tej samej korporacji. Gdybym dostawał sms o tym, że zamówiono taksówkę, taksówkarz wyjechał, a następnie dopiero dojechał byłaby to dla mnie część nadmiarowa.

Na podstawie powyższego przykładu można wskazać tzw. punkty przełamania (ang. breakpoints). Pojęcie to pochodzi z modelu o nazwie QUPER. Model ten wspomaga definiowanie, parametryzowanie oraz planowanie zmian w wymaganiach dotyczących jakości. Jakość jest wtedy traktowana jako nowy wymiar w kontekście do kosztu i wartości. Punktami przełamania są:

• punkt użyteczności (ang. utility breakpoint), kiedy usługa nieużyteczna staje się użyteczna – w powyższym przykładzie jest to dla mnie sytuacja, gdy czas oczekiwania na taksówkę jest akceptowalny i jest zgodny z deklarowanym. Zamówienie taksówki i dojazd w zaplanowanym czasie jest możliwy.
• punkt różnicowania (ang. differentation breakpoint), kiedy usługa jest przedmiotem przewagi konkurencyjnej. Dla mnie w powyższym przykładzie jest ta możliwość otrzymania informacji o przyjeździe taksówki.
• punkt nasycenia (ang. saturation breakpoint), kiedy parametry usługi są nadmiarowe względem oczekiwań (wzrost jakości jest nadmiarowy). W przykładzie, takim elementem są te smsy o różnych zdarzeniach. To, że dostanę sms o wyjeździe taksówki nie oznacza, że dotrze w określonym czasie.

Po zapoznaniu się z tym modelem, przypominają mi się moje wpisy odnośnie wartości procesu. W podawanych przykładach także można byłoby zidentyfikować powyższe punkty. Jednakże uzależnione jest to od perspektywy, z której analizujemy proces (czy rynek, klient, akcjonariusze itp.).

Od strony korporacji wzrost jakości usługi może zostać wprowadzony zgodnie z kilkuetapowym procesem oceny i zmiany usługi.

Reklama

Model długi ogon a procesy

Ostatnio trafiłem na stronę Lulu.com, która pozwala (informacja ze strony) na publikowanie przez autorów z całego świata książek i oferowanie ich do sprzedaży. Autor nie musi szukać wydawnictwa, które zrealizuje jego publikację. Rejestruje się na stronie, zamieszcza materiał w odpowiedniej kategorii i czeka aż jeden z „czytelników” zamówi jego książkę. Platforma łączy autorów z czytelnikami. Czytelnik szuka publikacji, którymi jest zainteresowany a każdego dnia w serwisie może się pojawić nowy autor z nową publikacją w danej tematyce.

Model ten, nazywany modelem Długiego ogona, zakłada (definicja na podstawie książki Business Model Generation, którą polecam), że dostarczamy mniejsze ilości (pojedyncze publikacje poszczególnych autorów) większej liczby usług (publikacje autorów z całego świata). Można powiedzieć, że pojedyncze publikacje są niszowe i tylko pewna część z nich się sprzeda (trafi do druku).

Na platformie łączą się 2 procesy, inicjowane przez dwóch różnych uczestników – autora i czytelnika. Pierwszy z nich to dostarczenie publikacji przez autora, a drugi, już wielokrotnie przeze mnie prezentowany proces zakupowy. W przypadku autora, załóżmy, że nowego, proces w uproszczeniu może odbywać się wg schematu, przygotuj publikację, zarejestruj się, opublikuj, co prezentuje powyższy diagram.

Zakładając, że w serwisie pojawia się nowy czytelnik, proces przebiegać może zgodnie ze schematem – wybór książki, rejestracja opłata, realizacja – szczegóły na przykładzie zakupów w internecie np. w czerwonym procesie, który opublikowałem jakiś czas temu). Dla procesu na takiej platformie istotne są kroki – „Wybór rodzaju dostawy” i odpowiadająca mu „Realizacja zamówienia”.

Na danej platformie są realizowane różne procesy przez wielu uczestników. W zależności od modelu działania platformy, procesy mogą być niezależne albo tworzyć jeden powiązany ciąg. Innym rozwiązaniem, nie działający już mechanizm Lego Factory, gdzie zamówienie i pomysł na produkt, pochodził od jednej strony – Klienta (projekt klocków i ich zamówienie), a realizacja odbywała się jako wynik procesu.