Posts Tagged ‘SIPOC’

h1

Pytania o … SIPOC

Listopad 24, 2019

W książce Lean Banking” (F. Majorana, A. Morelli) można znaleźć poniższy diagram, który wskazuje „przykład kolejnych czynności , jakie muszą zostać wykonane, aby sporządzić poprawnie SIPOC”. Diagram na potrzeby wpisu został przetłumaczony oraz lekko zmodyfikowany (co widać na diagramie).

Spróbujmy odpowiedzieć na postawione pytania na bazie procesu realizacji zamówienia przy użyciu sklepu internetowego, którego przykład wykorzystuję często na blogu. Jest to proces „łatwo” dostępny dla większości użytkowników sieci Internet. Taki użytkownik ma możliwość poznania całego przebiegu procesu od jego zainicjowania aż do samego końca (otrzymania zamówionego produktu). W sytuacjach problemowych (np. brak zamówionego produktu lub inny problem), to właśnie do niego jest kierowana odpowiednia informacja z prośbą o podjęcie decyzji co dalej z procesem. Użytkownik wybierając konkretny produkt orientuje się przeważnie kto jest jego dostawcą, jaka jest jego cena na rynku oraz parametry.

sipoc_pytania_full

Odpowiedzi na pytania mogą być następujące (punkty odpowiadają numerom pytań na diagramie a odpowiedzi są poglądowe):

  1. Jest to proces realizacji zamówienia ze sklepu internetowego z dostarczeniem produktu w sposób wskazany przez Klienta. Klient płaci z zamówiony produkt w wybrany sposób (wybierając z opcji dopuszczonych przez sklep, po spełnieniu określonych warunków).
  2. Pytania odnoszą się do granic procesu. Określenie tego, gdzie zaczyna i kończy dany proces jest istotne z różnych względów. W przypadku procesu zamówienia można przyjąć, że złożenie zamówienia jest początkiem procesu a dostarczenie produktu jest jego końcem. W zależności od tego, czy Klient jest nowy lub istniejący, w trakcie tego procesu następuje rejestracja lub nie nowego użytkownika sklepu internetowego. Jednakże to, że Klient się zarejestruje nie oznacza, że złoży zamówienie – może je np. zapisać na przyszłość. Zarejestrowani użytkownicy mogą przeważnie skorzystać z większej liczby opcji oraz udogodnień jakie daje dany sklep.
  3. Output’em procesu jest:
    a. produkt dostarczony do Klienta za pomocą ustalonego sposobu dostawy oraz
    b. zaksięgowana płatność za produkt na koncie sklepu
  4. Beneficjentem output’ów są:
    3a. Klient;
    3b. Działa finansowy sklepu internetowego oraz dostawcy produktów;
  5. Od output’u:
    3a. Klient oczekuje, że produkt jest zgodny w parametrach z zamówionym produktem, że nie jest uszkodzony; jest kompletny;
    3b. Firma oczekuje, że dokonana płatność przez Klienta dotarła we właściwej wysokości na konto sklepu;
  6. Aby proces miał szansę zaistnieć to:
    a. Produkt musi być w magazynie sklepu;
    b. Dostawca produktu dysponuje możliwościami uzupełnienia produktu na zamówienie;
    c. Sklep internetowy musi być dostępny dla użytkowników (strona musi działać a serwery były w stanie obsłużyć ruch);
    d. Sklep musi obsługiwać różne formy płatności;
    e. Sklep musi mieć ustalone mechanizmy dostawy produktów;
    f. Pośrednicy uczestniczący w procesie są gotowi na przewóz produktów;
    g. Powinien istnieć określony regulamin sklepu określający prawa i obowiązki poszczególnych stron transakcji (Klienta oraz sklepu jako całości);
    h. Ceny produktów są adekwatne do produktów;
    i. Klient musi wybrać produkt, określić parametry zamówienia oraz je potwierdzić.
    Warunki zaistnienia procesu są wynikową możliwości technicznych, posiadanych zasobów oraz planowanych do osiągnięcia efektów. Input’y w ramach procesu są łączone i pozwalają na osiągnięcie output’ów – na poszczególnych krokach procesu są jego wejściami przekształcanymi w wyjścia.
  7. Dostawcą input’ów są: dział zamówień sklepu (6a), producent produktów (6b), dział techniczny wraz z wsparciem firmy hostingowej (6c-6d), dział dystrybucji (6e-6f), sklep jako całość (6g-6h) oraz Klient (6i);
  8. Input’y wskazane powyżej powinny się charakteryzować tym, że:
    a. Są dostępne w momencie czasu, w którym Klient decyduje się na złożenie zamówienia;
    b. Produkty dostępne w sklepie w zakresie parametrów są zgodne z rzeczywistością;
    c. Formy płatności oferowane przez sklep funkcjonują poprawnie i bez zakłóceń;
    d. Firmy pośredniczące działają w ramach zgodnych z regulaminem sklepu;
    Sposób ich wykorzystania oraz efekty są zgodne z regulaminem sklepu;

Powyższe odpowiedzi składają się na uogólniony przykład. Przykładając je do konkretnego procesu uległyby większym lub mniejszym zmianom. Wskazując konkretne produkty (ich rodzaj, charakter) można byłoby dodać dodatkowe wymagania/charakterystyki lub wymagania przy których proces może zaistnieć.

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

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