Proces rezerwacji pokoju

W czasie urlopu, w hotelowej restauracji obserwowałem różne konfiguracje gości przy stolikach. Z obserwacji można było mylnie lub nie wywnioskować skład „grupy”. Raz było to 2 osób (para, koleżanki, koledzy), 2+1, 2 lub więcej jako rodzina. Innym razem wyglądało to na dziadkowie, mama i dziecko a czasami rodzice, dziecko i babcia (2+1+1). Można takie zestawienia tworzyć.

Zacząłem się jednak zastanawiać jak wybierają liczbę i rodzaj pokoi a może decydują się na dostawkę. Cena, wygoda, relacje, wiek, samodzielność, palacze itd. – to wszystko może wpływać na te decyzje. W końcu przez cały pobyt taki wybór raczej zostanie zachowany. Proces mógłby wyglądać jak na poniższym diagramie.

Niektóre wybory mogłyby powodować ograniczenia. Np. 1 osobowy pokój nie ma dostawki, można wziąć 3 osobowy ale wtedy płaci się jak za dorosłego, może być apartament ale wtedy koszt jest z innego przedziału. Kolejna rzecz to zaliczki. Kolejna to wyposażenie pokoju 2 osobowego – łóżka osobne czy łóżko małżeńskie itd.

Każda taka opcja to decyzja do podjęcia przez przyszłego gościa hotelu. Hotel z kolei, przyjmuje rezerwacje na bieżąco, są one potwierdzane, anulowane – co powoduje, że w czasie realizacji procesu, sytuacja i kontekst jego wykonania może zmienić się całkowicie. Cofnięcie się do poprzedniego kroku lub przerwanie i rozpoczęcie od początku wiąże się z innymi możliwościami.

Z punktu widzenia Klienta można rozpisać drzewka decyzyjne a z punktu widzenia systemu reguły biznesowe.
Sam proces rezerwacji wycieczki/hotelu jest dłuższy, tak, jak to opisywałem we wpisie „Proces rezerwacji wycieczki – tani czy komfortowy?”. W niniejszym wpisie, można powiedzieć, że skupiłem się na jednym kroku – wyborze szczegółowych parametrów wycieczki/hotelu.

Reklama

Co z tymi nazwami kroków?

Ostatnio ponownie trafiłem na artykuł na Modern Analyst, o tytule „Efficient BPMN: from Anti-Patterns to Best Practices”. Artykuł dotyczy tworzenia modeli/diagramów procesów opartych o najlepsze praktyki (ang. best practices) zamiast o błędne sposoby postępowania, tzw. antywzorców (ang. anti-pattern). Ten artykuł to dobra okazja, do ponownego zweryfikowania czy stosuję pierwszą z zasad, dotyczącą stosowania właściwych nazw kroków.

Sformułowanie “ponownie” nie jest tutaj przypadkowe, ponieważ już jakiś czas temu skupiłem się na blogu, na tych zasadach. Przejrzałem moje diagramy na blogu przygotowane od tamtego wpisu, czyli przez okres ponad 2 lat.

Przypomnę najpierw o czym mówią zasady w zakresie nazewnictwa kroków:

• (A) nazwy czynności powinny składać się z silnych czasowników i nazw właściwych dla domeny.
• (B) bramki nie powinny mieć nazw,
• (C) nazwy czynności nie powinny zwierać „lub” i „i”,
• (D) nazwy powinny być krótkie, a szczegóły w dokumentacji.

Z moich poszukiwań wynika, że nazewnictwo kroków poprawiło się w pierwszym obszarze (A) i drugim obszarze (B). Niestety znalazłem przykład w obszarze (C). Co można w takiej sytuacji zrobić? Artykuł proponuje rozbicie kroków, czyli uproszczenie nazw. Taka sytuacja jest zaprezentowana na poniższym diagramie. Diagram pochodzi z wpisu o ograniczeniach konfiguracji procesu.

Obszar w którym została wykonana zmiana został zaznaczony na diagramie. W miejsce usuniętego kroku, który nie jest jednoznaczny, zostały wstawione kroki o jednoznacznych nazwach wraz z określeniem momentu wystąpienia każdego z nich w trakcie realizacji procesu.

Jeżeli chodzi o obszar (D) to nie stosuję rozbudowanych nazw. Tylko w wyjątkowych sytuacjach nazwy są bardziej rozbudowane, co jest związane z treścią przekazu. Wygląda na to, że tworzone diagramy na potrzeby wpisów spełniają coraz lepiej powyższe reguły. Dlatego poszukam przykładów i ich poprawy dla kolejnych antywzorców wymienionych w artykule, czyli: niespójne używanie bramek (ang. gateways), słaby wygląd diagramu (ang. diagram layout), niekonsekwentne stosowanie zdarzeń (ang. events).