Posts Tagged ‘SIPOC’

h1

Nieudany proces

Październik 16, 2017

Miesiąc temu pisałem we wpisie o procesie zamówienia, w którym firma dostarczająca produkt informowała mnie o każdym zrealizowanym i planowanym kroku z bardzo dużą dokładnością. Proces zakończył się sukcesem, w szacowanym terminie – produkt został dostarczony. Mogę powiedzieć, że każdy z przekazanych statusów odzwierciedlał sytuację rzeczywistą. Do każdego z elementów SIPOC (o którym pisałem już wielekrotnie) można przyporządkować określone obiekty z podanego procesu.

Dzisiaj wrócę również do tematu procesu zamówienia. Jednakże niestety muszę przytoczyć przykład rzeczywistego procesu, w którym to fakt, byłem informowany o każdym etapie realizacji, ale niestety komunikaty nie odzwierciedlały rzeczywistości, patrząc z mojej perspektywy. Na początku wszystko wyglądało identycznie: złożyłem zamówienie, czyli wybrałem produkt, podałem parametry zamówienia, zapłaciłem, a produkt został wysłany, o czym poinformował mnie pierwszy komunikat. I tu się podobieństwa kończą. Następny komunikat stwierdzał: uzgodniono termin przesunięcia dostawy. Nie było ani kontaktu mailowego ani telefonicznego od firmy kurierskiej. Ok, machnąłem ręką, nowy termin był w ostateczności akceptowalny, jak nie dojdzie produkt będę się martwił.

nieudanyprocess450px

Kolejny komunikat poinformował: brak kontaktu z odbiorcą, produkt zwrócony. I w tym momencie już nie było ciekawie. Ani nie wiedzieliśmy, że kurier jednak nie przyjedzie, ani nie podał wcześniej szacowanej godziny dostawy, a na koniec pomimo aktywnego telefonu i przebywania w strefie objętej zasięgiem – kontaktu nie było. Skończyło się reklamacją skierowaną do firmy kurierskiej. Wielokrotnie zamawialiśmy produkty u tego dostawcy i z wykorzystaniem kuriera – nigdy nie było problemów.

Potem okazało się, że produkt wrócił do firmy, u której zamawiałem produkt, a po kilku dniach nastąpił zwrot środków na konto.  Choć niestety nie mam zamówionego produktu, czy element oczekiwanego “wyjścia” (ang. output) w ramach modelu SIPOC nie został zrealizowany zgodnie z oczekiwaniami. Zostałem z “wejściem” (ang. input) – swoją potrzebą oraz środkami na koncie. Dostawca produktu (ang. Supplier) oraz Odbiorca produktu/Klient (ang. Client) uczestniczyli w tym procesie, ale nie można powiedziec, że są zadowoleni – z jednego strony produkt nie został sprzedany, a z drugiej dostarczony. Sam proces  (ang. process)“podobno” – podkreślam to słowo – został zrealizowany, choć mam wątpliwości, czy z tak funkcjonującym kurierem wszystkie kroki rzeczywiście zostały zrealizowane.

Powyższy diagram obrazuje taką zmianę sytuacji, z oznaczeniem, że nastąpiła kolejna zmiana strony obsługującej oraz w procesie nie ma statusu „produkt dostarczony”.

Reklamy
h1

Proces dla sprawozdań finansowych

Luty 13, 2015

Przeglądając poprzednie wpisy, trafiłem ponownie na sformułowanie “elektronizacja procesu„, a po wpisaniu go do wyszukiwarki z czystej ciekawości, trafiłem na artykuł o przygotowywaniu spawozdań finansowych. Dokładnie chodziło o artykuł dot. zmiany procesu przygotowywania sprawozdań finansowach z papierowego/ręcznego na bardziej zautomatyzowany, oparty o dane przechowywane w formie elektronicznej.

Z jednej strony procesu, na tzw. wejściu mamy spływające dane finansowe od różnych podmiotów (tzw. dostawców) oraz obowiązując reglacje (m.in. Ustawa o rachunkowości, MSSF itd.). Z drugiej strony, odbiorców/klientów, np. podmioty regulujące działanie rynku finansowego, do których są przekazywane sprawozdania w określonym formacie, tworzące tzw. wyjście. Zebranie danych, przygotowanie sprawozdań i przekazanie w ustalonym formacie stanowią proces. Wskazane obiekty oraz kroki to elementy SIPOC. Na poniższym diagramie przedstawione jest to wizualnie.

sprawozd450

Taki proces może odbywać się ręcznie, w oparciu o dostępne narzędzia. Jeżeli jednak chcemy go usprawnić, zautomatyzować czy ustandaryzować, z pomocą przychodzi język XBRL. XBRL (ang. Extensible Business Reporting Language) jest standardem opracowanym do realizacji takich działań jak: usprawnienie wymiany, interpretacja, analiza i prezentacji sprawozdań gospodarczych (nie tylko finansowych). Można powiedzieć, że XBRL to język do modelowania sprawozdaw czości finansowej. Jego zastosowanie pozwala na realizację zasygnalizowanych powyżej celów. Istotne jest to, że stosowanie takiej ustandaryzowanej formy to także oszczędność czasu i kosztów w podmiocie, co obecnie ma bardzo duże znaczenie dla budowy przewagi konkurencyjnej. W kolejnym newsie postaram się przybliżyć bardziej ten język.

Wróćmy jednak do powyższego diagramu, na którym dodany został krok Transformacji raportów. W ramach tego kroku otrzymane dane wejściowe są przetwarzane na raporty w tym języku, zrozumiałe przez stosowane w procesie narzędzia. Zastosowanie analogicznego rozwiązania przez dostawców raportów, spowodowałoby, że poprawiłaby się znacznie sprawność procesu. Możliwość przekazania ich dalej w tym formacie, zmniejsza liczbę transformacji raportów z jednej postaci do drugiej.

h1

Dwa kroki procesu – różnorodność rozwiązań

Maj 1, 2014

Wyobraź sobie, że chcesz kupić książkę. Jakie wersje książki potencjalnie mogą Cię zainteresować? Wydanie w miękkiej okładce, w sztywnej, wersja pocket, wersja na czytnik elektroniczny, audiobook, druk na żądanie. Możliwości jest jak widać kilka. Możesz otrzymać książkę w ciągu kilku sekund lub kilku dni. Gdy lubisz trzymać książkę w ręku, słyszeć szelest, postawić książkę na półce – pomimo długiego oczekiwania, zamówisz książkę np. w sztywnej oprawie. Gdy chcesz jedynie mieć lekturę w podróży, jedną z wielu na czytniku, wybierzesz wersję elektroniczną.

W poprzednim wpisie o modelu długiego ogona wyróżniłem dwie powiązane czynności procesu „Wybór rodzaju procesu” (lewa strona poniższego diagramu) oraz „Realizacja zamówienia” (prawa strona poniższego diagramu). Na diagramie umieściłem pogrupowane w zależności od realizacji powyższe wersje książki.

Diagram2

Wskazane czynności są sposobem dostarczenia zamówienia dla klienta. W zależności od dokonanego wyboru, biorąc pod uwagę dwa „skrajne” rozwiązania:

  • wersja na czytnik elektroniczny – proces jest krótki, może zostać zakończony w przeciągu kilku-kilkunastu minut, w całości zrealizowany w ramach platformy sprzedażowej, bez angażowania dodatkowych jednostek,
  • wydruk na żądanie – proces jest dłuższy, trwa kilka – kilkanaście dni, realizowany jest w dużym stopniu poza platformą, angażuje zarówno jednostki powiązane (drukarnia), jak i zewnętrzne (poczta, firma kurierska, pracownik punktu odbioru zamówienia),

Oceniając realizację takiego procesu, konieczne jest właściwe zdefiniowanie mierników uwzględniających różne realizacje procesu i jego cechy charakterystyczne (SIPOC).

h1

Pytania o realizację procesu

Lipiec 20, 2013

Ostatnio wysyłając przesyłke, postanowiłem sprawdzić, za pomocą dostępnych narzędzi, jaki jest status przesyłki – czy dotarła, czy została odebrana. Udało mi się sprawdzić I przy okazji pomyślałem, że tak naprawdę jest to pewien proces rozciągnięty w czasie, gdzie inicjatorem jest nadawca przesyłki, a na końcu procesu jest odbiorca przesyłki. Istotnym elementem procesu są komunikaty przekazywane od obsługującego proces do odbiorcy – takim komunikatem jest przekazanie informacji do odbiorcy o oczekującej przesyłce w miejscu odbioru.

Proces od strony podmiotu obsługującego można zobrazować następująco:

Diagram1

W przypadku tego procesu, patrząc z perspektywy metody SIPOC można powiedzieć, że mamy: Dostawcę (nadawca przesyłki), Wejście (rodzaj przesyłki, dane odbiorcy, waga, inne parametry), Proces (realizacja przesyłki), Wyjście (przesyłka dostępna w miejscu docelowym, komunikat do odbiorcy), Klient (odbiorca przesyłki).

Jako nadawca – Klient – chciałem wiedzieć jak jest realizowany proces przesyłki.
Pytania, które mógłbym zadać, przykładowo:

  • Jaki poziom szczegółowości postępu procesu (statusy) jest potrzebny? Np. Nadany, przesłany, odebrany. Więcej o statusach.
  • Jakie informacje o przesyłce (wejście, wyjście) powinny być dostępne? np. Numer przesyłki, miejsce nadania itp.
  • Jakie informacje z realizacji procesu są mi potrzebne? np. Daty realizacji.
  • Do kiedy mogę sprawdzić, czy przesyłka dotarła? np. 2 tygodnie od zakończenia procesu, gdybym nie mógł sprawdzić przesyłki na bieżąco.

 

Informacja dodatkowa z procesu, to ile czasu może trwać dostarczenie określonej przesyłki do danego miejsca, gdyby korzystał częściej z tego mechanizmu. Jest to cenne, aby wiedzieć z jakim wyprzedzeniem lub po jakim czasie może druga strona zareagować na przesłaną informację.

h1

Materializacja ryzyka jako „inicjator” procesu

Lipiec 11, 2011

Załóżmy, że został wdrożony system informatyczny wspierający główne procesy biznesowe. W trakcie realizacji projektu, w ramach Rejestru Ryzyk, który jest jednym z elementów zarządzania ryzykiem, umieszczono ryzyko „błędne wykorzystanie aplikacji”. Ryzyko to zostało wskazano jak możliwe do wystąpienia po wdrożeniu systemu. Odpowiedzialność za to ryzyko ponosi właściciel systemu/danego procesu biznesowego.

W trakcie realizacji procesu biznesowego, użytkownik napotkał na problem i zgłosił go – nastąpiło wejście (w rozumieniu diagramu SIPOC) do procesu obsługi błędów. Problemem zajął się użytkownik i okazało się, że problem nie wynika z błędu systemu a z błędnego wykorzystania systemu przez użytkownika. Błędne wykorzystanie systemu – materializacja ryzyka – mogła nastąpić z niewiedzy, niekompletnych lub niezrozumiałych materiałów, braku wykorzystania dostępnych procedur itp.

Można powiedzieć, że materializacja ryzyka zainicjowała nowy proces – zaprezentowany na poniższym przykładowym diagramie BPMN.

Wejściem do procesu jest zgłoszenie błędnego wykorzystanie systemu, które powinno zostać wyjaśnione przez właściciela biznesowego procesu głównego, na przykład poprzez rozszerzenie materiałów pomocniczych, procedur lub dedykowaną komunikację.

We wskazanej sytuacji przygotowanie odpowiednich materiałów jest działaniem zmniejszającym wpływ tego ryzyka. Jednakże rzeczywistość biznesowa jest zawsze bardziej zróżnicowana niż przypadku opisane w materiałach czy procedurach. Często konieczna jest ich modyfikacja po jakimś czasie w wyniku zgłoszeń użytkowników końcowych czy obserwacji pierwszych linii wsparcia. Czasami następuje to również w wyniku materializacji ryzyka.

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).

h1

Wejścia i wyjścia w procesie

Kwiecień 13, 2011

Diagramy zaprezentowane w poprzednim wpisie – diagram procesu w BPMN oraz wizualizację myślenia systemowego – można spróbować połączyć na jednym diagramie, powstałym na bazie diagramu aktywności dla procesu biznesowego. Na poniższym diagramie zostały dodane wejścia do kroków i wyjścia z kroków (kierunek strzałek obrazuje to, czy dany obiekt jest wejściem czy wyjściem z danego kroku procesu).

Można zauważyć, że:

  • niektóre wejścia/wyjścia pasują do kwestii zobrazowanych na diagramie myślenia systemowego – np. „Akceptowalna stawka”;
  • niektóre kwestie z diagramu można potraktować jako cechę wejść/wyjść – np. „Liczba zgłoszeń” jest cechą „Listy zgłoszeń”;
  • niektóre kwestie z diagramu nie są związane z wejściami/wyjściami a bardziej są cechą charakterystyczną dla całego procesu – np. „Czas realizacji rekrutacji”;

Istotne jest to, że cechy wejść do poszczególnych kroków wpływają zarówno na realizację danego kroku, jak i całego procesu. Takimi cechami mogą być liczba zgłoszeń, jakość zgłoszeń, czas potrzebny na zapoznanie się z danym zgłoszeniem, stopień dopasowania poszczególnych zgłoszeń do opisu stanowiska pracy itd.

Świadomość takich powiązań ułatwia realizację procesu. W szczególności, gdy dany uczestnik procesu ma świadomość, że efekt (i jakość) realizacji jego zadania zostanie wykorzystany dalej w procesie, wpłynie na działania dalszych uczestników procesu. Właśnie do pokazania takich zależności w ramach procesu w kontekście produktów dla klientów wewnętrznych procesu można wykorzystać myślenie systemowe. Na analizie wejść/wyjść procesu jest oparte narzędzie SIPOC pochodzące z metodologii Six Sigma (ale o tym innym razem).