Posts Tagged ‘core processes’

h1

Elementy wspólne dla podprocesów

Październik 3, 2015

Po dłuższej przerwie miałem okazję korzystać z jednego z płatnych parkingów, będącego pod centrów handlowych. Wjeżdżam, pobieram bilet, otwiera się szlaban i wjeżdzam. Parkuję a bilet umieszczam w portfelu, sprawdzając tylko odnotowaną godzinę wjazdu. Chowam do portfela i idę do centrum handlowego. Po jakimś czasie wracam na parking, udaję się do kasy i wtedy dopiero zdaję sobie sprawę, że coś się zmieniło. Bilet nie został wciągnięty do środka a sama kasa inaczej wygląda. Płacę.

Próbuję więc wyjechać i jestem mile zaskoczony, bo szlaban się sam otwiera. Zdziwiony, próbuję włożyć bilet do czytnika, a tutaj komunikat: “Dziękujemy za wizytę”, potem numer tablicy rejestracyjnej i komunikat: “Proszę wyjechać”. Wtedy obejrzałem bilet i zobaczyłem, że jest na nim więcej danych. O taka zmiana, zwiększenie automatyzacji. Nieświadomy tego, system sam zapamiętał samochód i sam go rozpoznał. Ja musiałem tylko nie zgubić biletu i go opłacić.

Przykład ten pokazuje w jaki sposób można przyspieszyć i uprościć proces, wykorzystując nowoczesne technologie. Krótszy czas oczekiwania przy wyjeździe.  Wydaje się, że bilet jest już niepotrzebny. Każdy samochód, który podjeżdża jest analizowany pod kątem godziny wjazdu, opłacenia biletu i możliwości wypuszczenia samochodu. Gdyby ktoś spróbował wyjechać samochodem nieopłaconym zostałby zatrzymany. Gdyby nie udało się odczytać tablicy rejestracyjnej, poproszony zostałby kierowca o przytknięcie biletu.

parking450

Powyższy diagram prezentuje 3 oddzielone w czasie czynności – podprocesy – wykonywane przez system, w różnych okresach czasu, składające się na jeden większy proces obsługi korzystającego z parkingu. Oparte są one na tym samym identyfikatorze i jego statusie. Pozwala to na zmianę ich składowych, jeżeli zachowane zostanie powiązanie identyfikatora (numer rejestracyjny/numer biletu) oraz statusu (wjazd, opłacony, wyjazd). Na diagramie na zielono są zaznaczone kroki oparte na tych danych – zapis, odczyt i analiza (czas wjazdu, czas postoju, numer biletu, numer tablicy). Teoretycznie można byłoby zrezygnować z wydawania biletu po jego opłaceniu, ale wtedy w sytuacji awaryjnej (brak odczytu tablicy) proces przebiegnie w oparciu o bilet, przyłożony do czytnika.

W powyższym przykładzie proces obsługi korzystającego z parkingu składa się z 3 kroków: przyjmij samochód, przyjmij opłatę, wypuść samochód. Na takim poziomie, takie 3 kroki są wystarczające do pokazania jak przebiega proces główny. Jeżeli chcemy poznać szczegóły, zapoznajemy się z poszczególnymi podprocesami. Między tymi krokami z punktu widzenia obsługujących parking, mają miejsce czynności nieistotne dla nich – szukanie miejsca przez kierowcę, opuszczanie pieszo i powrót na parking przez kierowcę, poruszanie się samochodem po parkingu. Czas przebiegu procesu głównego jest zmienny i niezależny od sposobu jego obsługi.

Reklamy
h1

SIPOC na bazie diagramu BPMN

Czerwiec 4, 2011

W wielu przedsiębiorstwach, które udostępniają swoim pracownikom – np. pracownikom obsługującym klientów – system informatyczny, funkcjonuje proces obsługi zgłoszeń błędów/problemów. Proces ten funkcjonuje obok zwykłych/głównych procesów (ang. core processes), wspieranych przez system informatyczny i w których biorą udział pracownicy. W kontekście systemu informatycznego pracownik staje się użytkownikiem (albo inaczej patrząc aktorem).

Ideę takiego procesu obrazuje poniższy diagram w BPMN.

Proces obsługi zgłoszeńW jednym z ostatnich wpisów wspomniałem o diagramie SIPOC. Jest on używany do zobrazowania przepływu pracy. Po rozwinięciu poszczególnych liter nazwy – umieszczonych także w odpowiednich miejscach na diagramie – mamy następujące elementy:

  • Supplier (S), czyli Dostawca – oznacza podmiot, który dostarcza informacje, zasoby do realizowanego procesu. Na powyższym diagramie jest to użytkownik systemu, który zgłasza problem – oznaczony przez (S).
  • Input (I), czyli zasoby wejściowe – oznacza informacje, zasoby dostarczane przez Dostawcę. Powyżej jest to zgłoszenie problemu/błędu z jego opisem, czasem wystąpienia, identyfikatorem transakcji/błędu, danymi identyfikacyjnymi użytkownika. Obiekty oznaczone przez (I).
  • Process (P), czyli proces – działania w określonej kolejności, które wykorzystuję zasoby wejściowe w celu zwiększenia ich wartości lub wytworzenia efektu końcowego (wyjściowego). W tym wypadku jest proces ze wskazanymi czynności zmierzającymi do znalezienia rozwiązania. Uczestnicy procesu analizują dostarczone informacje przez użytkownika. Wykorzystują przekazane dane kontaktowe w celu uzyskania dodatkowych wyjaśnień. Proces (P) składa się z kroków „Analiza zgłoszenia”, „Poszukiwanie rozwiązania” oraz „Wybór/Wskazanie rozwiązania”.
  • Output (O), czyli efekt wyjściowy – oznacza informacje, zasoby dostarczane przez proces. Na diagramie jest to rozwiązanie (jego opis), oznaczony przez (O).
  • Customer (C), czyli klient – oznacza podmiot, który otrzymuje efekt wyjściowy. W tym wypadku jest to inicjatora zgłoszenia, oznaczony przez (C).

Więcej o diagramie SIPOC można przeczytać u źródła (Six Sigma).