Posts Tagged ‘proces współpracy’

h1

Poza basenem, czyli proces współpracy

Styczeń 11, 2016

W poprzednim wpisie, skupiłem się na procesie odbywającym się w ramach danej jednostki, gdy to pracownik odbiera bilet od pasażera i samodzielnie przeprowadza proces przy użyciu narzędzia. Cofnijmy się jednak o krok a dokładnie 2 kroki wcześniej, zanim konduktor rozpoczął weryfikację biletu. Z racji, że miałem bilet internetowy, najpierw zostałem poproszony o bilet a następnie o dokument osoby wskazanej na bilecie do potwierdzenia tożsamości. Te 2 kroki są zaprezentowane na poniższym diagramie.

prosba_o_bilet_1_450px

Na powyższym diagramie, można zauważyć, że także są wykorzystane tzw. baseny jednakże nie jeden, a dwa. Każdy z nich obrazuje innego uczestnika procesu a komunikacja odbywa się za pomocą komunikatów i reakcji na nie. Jest to tzw. proces współpracy (ang. collaboration process). W tym procesie pojawiają się już zdarzenia początkowe (ang. start event) i zdarzenia końcowe (ang. end event) w każdym z basenów oraz można powiedzieć, że nie jest on “ciągły” w ramach jednego basenu. Proces wychodzi jakby poza dany basen i oczekuje reakcji z drugiego basenu na wysłany komunikat.

Przykłady dla procesu współpracy w innych sytuacjach znajdują się w moich poprzednich wpisach:

Reklamy
h1

Proces współpracy – obsługa reklamacji

Sierpień 18, 2015

Kolejny raz odwołam się do własnych doświadczeń. Otrzymałem sms o treści: „Przypominamy, że do DD.MM.RRRRr. należy opłacić składkę za ubezpieczenie. Nr Polisy, Kwota i Numer rachunku”. Nadawcą jeden z ubezpieczycieli. Czytam sms i jestem coraz bardziej zaskoczony – nie mam ubezpieczenia u tego ubezpieczyciela. Numer rachunku ani polisy nic mi nie mówi. Oznacza to jedno, ktoś nie otrzymał powiadomienia o składce, a trafiło do niewłaściwej osoby.

Postanowiłem, że temat wyjaśnię – zgłoszę jakby reklamację. Zacząłem od formularza Kontaktowego na stronie – inne opinie/reklamacje. Wypełniam formularz – dane sprawy, numer polisy, o co chodzi – na razie wszystko z sms, potem imię i nazwisko (myślę ok), a potem PESEL, e-mail i zacząłem przeglądać formularz do końca. Zatrzymałem się na oświadczeniach i zdałem sobie sprawę, że nie chcę podawać tych danych. Pomyślałem, że może jest inny sposób.

Analityk_450px

(szczegóły po powiększeniu)

Przeszukałem stronę i znalazłem inny sposób na wyjaśnienie sprawy. Spytałem profilaktycznie czy to dobre miejsce i zapytałem w jaki sposób mogę rozwiązać kwestię. „Druga” strona poprosiła o minimum danych: numer polisy, numer telefonu i imię oraz nazwisko. Takie minimum danych mogłem podać. Po chwili przypuszczenia się potwierdziły – osoba ubezpieczona podała błędny numer lub przepisując do systemu zrobiony został błąd. Zgłosiła do poprawy i wskazała, że w ciągu 2 dni roboczych powinni usunąć numer. Od „drugiej” strony mogło to być tylko jednorazowe działanie a może też przyczynić się do zmian, zmierzających do uniknięcia takich sytuacji w przyszłości (zgodnie z metodologią 8D).

Obsługa tego procesu wyglądała jak na powyższym diagramie – szybko, prosto i bez podawania nadmiarowych danych. Jest to przykład tzw. procesu współpracy (ang. collaboration process), który wielokrotnie wykorzystywałem do prezentacji procesów. Doceniam takie proste rozwiązania. Powinna być szybka ścieżka obsługi takich zgłoszeń we wcześniej wspomnianym formularzu. Liczę, że planowane wykreślenie rzeczywiście nastąpi. Ciekawe czy otrzymam powiadomienie o zakończeniu sprawy.