Proces na papierze i proces w praktyce#
Diagram może pokazać rzeczywisty sposób działania firmy, jeśli powstaje na podstawie sprawdzonych informacji i ma jasno określony zakres. Zawsze będzie uproszczeniem. Jego wiarygodność zależy od tego, czy zachowuje elementy ważne dla postawionego pytania: działania, decyzje, odpowiedzialność, oczekiwanie czy wyjątki.
W procedurze obsługi reklamacji mogą występować cztery kroki: przyjąć zgłoszenie, ocenić problem, odpowiedzieć klientowi i zamknąć sprawę. Osoba pracująca przy zgłoszeniach prawdopodobnie dopowie więcej. Czasem brakuje opisu usterki. Czasem odpowiedzi udziela serwis, a czasem potrzebna jest decyzja przełożonego. Bywa też, że kompletna sprawa czeka, ponieważ nikt nie zauważył wiadomości w skrzynce.
Te szczegóły nie muszą trafić na jeden rysunek. Trzeba jednak wiedzieć, które z nich decydują o tym, co chcemy zrozumieć lub poprawić.
Najpierw ustalmy, co opisujemy#
Załóżmy, że firma chce sprawdzić, gdzie zgłoszenia przechodzą między zespołami. Interesuje ją organizacja pracy, a nie budowa programu do rejestrowania spraw. Początkiem analizowanego procesu będzie wpłynięcie zgłoszenia, a końcem przekazanie odpowiedzi i zamknięcie sprawy.
Przykład jest fikcyjny i służy pokazaniu obiegu pracy. Nie określa terminów ani obowiązków wynikających z przepisów o reklamacjach. W rzeczywistym projekcie takie wymagania trzeba ustalić osobno i uwzględnić w procesie.
Do opisania kolejności działań można wykorzystać diagram aktywności UML. Podział na kolumny, nazywane partycjami lub torami, pozwala dodatkowo wskazać odpowiedzialność. W tym przypadku wystarczą dwa obszary: obsługa klienta i serwis.
Poniższy rysunek przedstawia roboczy opis procesu. Pokazuje też powrót do sprawdzenia zgłoszenia po otrzymaniu uzupełnienia.
Przejście między kolumnami pokazuje zmianę odpowiedzialności. Pętla po lewej stronie oznacza, że uzupełnienie może wymagać ponownego sprawdzenia. Rysunek nie zawiera osobnych ścieżek dla poszczególnych wyników oceny, ponieważ w tym widoku interesuje nas przekazanie sprawy, a nie sposób rozstrzygnięcia reklamacji.
Od razu widać też ważne ograniczenie: przedstawiona ścieżka zakłada, że klient odpowie na prośbę o uzupełnienie. Co dzieje się, jeśli odpowiedź nie nadejdzie? Tego jeszcze nie ustalono. Diagram należy traktować jako materiał do weryfikacji, dopóki ta kwestia pozostaje otwarta. Nie wolno odczytywać narysowanej pętli jako zgody na dowolnie długie oczekiwanie.
Jak sprawdzić, czy tak rzeczywiście jest#
Najwięcej informacji daje przejście przez konkretne, zakończone sprawy. Można wybrać zwykłe zgłoszenie, jedno wymagające uzupełnienia i jedno, przy którym wystąpił problem. Następnie z osobami obsługującymi te sprawy odtworzyć, co działo się po kolei.
Przy każdym przekazaniu warto zapytać, skąd kolejna osoba dowiaduje się o zadaniu. Czy otrzymuje powiadomienie w systemie? Wiadomość e-mail? Czy zagląda do wspólnego arkusza? Odpowiedź pozwala sprawdzić, czy strzałka na diagramie odpowiada działającemu mechanizmowi.
Relacje pracowników można porównać z historią zmian w systemie, wiadomościami i dokumentami. Każde z tych źródeł pokazuje część obrazu. Rejestr systemowy nie wyjaśni rozmowy telefonicznej, której nikt nie odnotował. Pamięć uczestnika może z kolei pomijać rzadkie odstępstwa. Rozbieżności warto zapisać i wyjaśnić, zanim uznamy model za opis stanu obecnego.
Nieformalne działania także należą do rzeczywistości. Jeżeli pracownik musi dzwonić do serwisu, żeby sprawa ruszyła, usunięcie telefonu z diagramu nie uprości procesu. Utrudni jedynie zrozumienie jego zależności.
Ten sam rysunek nie odpowie na każde pytanie#
Pokazany diagram pozwala wskazać miejsca przekazywania pracy, ale nie dowodzi, że właśnie tam pojawiają się opóźnienia. Odległość między prostokątami nie oznacza czasu. Jeden krótki krok na rysunku może trwać tydzień, a kilka kolejnych czynności może zająć minutę.
Gdy firma chce ustalić przyczynę długiej obsługi, potrzebuje także danych o rzeczywistych sprawach: chwili przyjęcia, rozpoczęcia oceny, przekazania wyniku oraz czasie oczekiwania na uzupełnienie. Warto rozróżnić czas wykonywania pracy od czasu spędzonego w kolejce. Diagram pomaga przyporządkować pomiary do etapów; same pomiary trzeba jednak zebrać.
Podobnie jest z wyjątkami. Jeżeli raz na jakiś czas zgłoszenie wymaga udziału zewnętrznego specjalisty, znaczenie tego wariantu zależy od celu analizy. Może być mało istotny dla ogólnego przedstawienia obiegu, a kluczowy dla planowania obsady i terminów. Rzadkość nie jest wystarczającym powodem, żeby coś pominąć.
Opis stanu obecnego i propozycja zmiany#
Podczas rozmowy o procesie łatwo przejść od „tak pracujemy” do „tak powinniśmy pracować”. Ktoś proponuje automatyczne przypomnienie, ktoś inny jednego właściciela sprawy. To wartościowe pomysły, ale wymagają odrębnego zapisu.
Model stanu obecnego, często określany jako as-is, opisuje sprawdzony sposób działania. Model docelowy, czyli to-be, przedstawia uzgodnioną propozycję. Przy obu warto podać zakres i datę, a przy propozycji także status decyzji. Dzięki temu można porównać, co zmiana ma poprawić i jakie nowe zadania powstaną.
UML jest jedną z możliwości przedstawienia takiej analizy. Jeżeli firma korzysta z BPMN, notacji przeznaczonej do modelowania procesów biznesowych, warto rozważyć pozostanie przy wspólnym języku. O wyborze powinny decydować pytania, na które model ma odpowiadać, oraz to, czy jego odbiorcy potrafią go odczytać.
Wiarygodny obraz ma opisane granice#
Przy gotowym diagramie powinno być jasne, kogo i jakiego fragmentu pracy dotyczy, na podstawie czego go sporządzono oraz które kwestie pozostają niewyjaśnione. Proces może wyglądać inaczej w innym oddziale albo przy innym rodzaju zgłoszenia.
Dobry model pozwala osobie wykonującej tę pracę powiedzieć: „tak, ten rysunek oddaje nasz sposób działania w opisanych sytuacjach”. Jeżeli przy okazji ujawnia niewidoczne wcześniej oczekiwanie, niejasną odpowiedzialność czy pomijaną ścieżkę, daje firmie konkretny materiał do dalszych decyzji.