Pytania o … SIPOC

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.

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

Reklama

SIPOC na bazie diagramu BPMN

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.

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

Sieć wyzwań dla procesu

Brak właściciela, przeładowany krokami nie wnoszącymi wartości dodanej, bez metryk, niespełniający oczekiwań odbiorcy … to tylko cztery wyzwania, które stoją przed procesami biznesowymi, spośród 11 wymienionych w artykule, na który ostatnio trafiłem – chodzi o artykuł „The 11 most common business process challenges and how to defeat them”, który polecam (skłania do refleksji). Wymieniłem te 4 wybrane, ponieważ o tych między innymi wielokrotnie pisałem na swoim blogu w różnym ujęciu:

• o właścicielu procesu i jego roli,
• o krokach istotnych dla procesu, jak i tych, które nie wnoszą wartości dla procesu (dla poszczególnych kroków można określić dla kogo są te kroki), czy można je pominąć czy może wartość, którą w noszą jest zauważalna,
• o metrykach, efektywności czy sprawności procesu,
• o niespełnionych oczekiwaniach.

Wszystkie wymienione (wyzwania, stąd (CXX) od ang. Challenge, oznaczenia wykorzystane na diagramie) we wskazanym artykule to (pozwalam sobie je przytoczyć w formie listy bo nie ja je wymyśliłem i zebrałem, zachowując oryginalne nazwy – w sprawie szczegółów odsyłam do wskazanego powyżej artykułu, gdzie każdy podpunkt jest dokładnie opisany; tłumaczenia dodane pomocniczo w nawiasach): „

• (C1) Business process not defined (proces nie jest zdefiniowany),
• (C2) Business process not owned (proces biznesowy bez właściciela),
• (C3) Purpose not understood (cel procesu nie jest zrozumiany),
• (C4) Business process not followed (nikt nie podąża za procesem),
• (C5) Customer not understood (Odbiorca/Klient nie jest poznany/nie zostały poznane jego potrzeby),
• (C6) Supplier not understood (Dostawca nie jest poznany/uczestnicy nie rozumieją jego potrzeb/nie znają go),
• (C7) Cumbersome to execute (Proces jest uciążliwy do wykonywania),
• (C8) Loaded with non-value added work (Przeładowany pracą, która nie wnosi wartości dodanej),
• (C9) Performance not measured (Proces nie jest pomierzony pod kątem wydajności),
• (C10)  Not linked to strategy (Nie połączony ze strategią),
• (C11) Don’t understand what business they are really in (Brak zrozumienia dla biznesu, w którym funkcjonuje)”.

Po zapoznaniu się z artykułem, zacząłem się zastanawiać czy nie można stworzyć między nimi diagramu powiązań, wykorzystując do tego myślenie systemowe. Moim zdaniem pewne elementy pociągają za sobą inne:

• Ciężko na przykład mówić o zmierzeniu procesu (C9), jeżeli nie wiemy gdzie są granice procesu, jakie kroki się na niego składają (C1).
• Z racji, że to właściciel powinien pilnować tego jak funkcjonuje proces, czy jest zrozumiały i jakie są zależności między dostawcą, procesem a jego odbiorcą – czyli podejście SIPOC. Gdy jego zabraknie (C2) to proces dzieje się w „swojej” formie (C7) lub nie jest wykorzystywany wcale (C4). Elementy te zostały zaznaczone na czerwono (gdy nikt nie dba o proces, nie mierzy go, nie weryfikuje, nie dostosowuje do branży, to pojawiają się kolejne problemy).

Na diagramie wskazałem więcej takich powiązań. Skutkiem „kumulacji” różnych braków (wyzwań) jest to, że proces może być uciążliwy (C7) dla uczestników lub szukają oni obejść, nie chcą stosować się do przyjętych reguł lub przestają podążać wg procesu (C4) – zaznaczone na szaro na diagramie.

Zaprezentowane zależności to przykład mający na celu zobrazowanie idei, o której myślałem i bardzo subiektywne spojrzenie z mojej strony. Zachęcam moich czytelników do komentarzy i sugestii.  

Myślenie systemowe, o którym wspominam powyżej, pozwala na zaprezentowanie wpływu pewnych elementów na siebie, oznaczając zarówno kierunek, jak i rodzaj wpływu (pozytywny/negatywny). W powyższym przykładzie mamy oznaczenie konsekwencji jednego wyzwania (choć w momencie gdy wystąpi można je nazwać zaniedbaniem/luką) na inne. Połączone potęgują wrażenie chaosu oraz powodują narastanie kosztów czy długu technologicznego.

Nieudany proces

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

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

Czas realizacji a “szybkość” procesu

Składając różne elementy procesu, o których pisałem na blogu, można utworzyć uogólniony proces, który:

• zmienia wejścia procesu w wyjście procesu, na co zwracana jest uwaga w modelu SIPOC.
• ma wejścia i wyjścia procesu, uzależnione od rodzaju procesu.
• posiada kroki dodające wartość dla odbiorcy procesu (kroki oznaczone na diagramie jako VAP) lub tylko dla innych interesariuszy zainteresowanych (kroki na diagramie oznaczone jako VAI) procesem.
• obsługuje wyjątki lub alternatywne ścieżki przebiegu procesu.

Każdy realizowany proces można opisać za pomocą jego czasu realizacji, czyli Delivery Cycle Time. Wartość ta informuje jak długo trwa proces od jego zainicjowania przez Klienta, na przykład poprzez złożenie zamówienia, dostarczenie dokumentu, złożenie zapytania, po zakończenie procesu, rozumiane jako dostarczenie produktu, na przykład przedmiotu zamówienia, akceptacji dokumentu, odpowiedzi na zapytanie.

Wartość ta interesuje nie tylko odbiorcę procesu, ale także księgowość, inwestorów oraz inne grupy interesariuszy. Biorąc pod uwagę powtarzalność procesu, najlepszą sytuacją, gdy w danym czasie, na przykład miesiąca, można zrealizować kilka, kilkanaście lub więcej przebiegów procesu.

Na bazie tych informacji można byłoby spróbować obliczyć “szybkość” procesu. Dostarczając 1 produkt w czasie T, możemy potencjalnie policzyć liczbę dostarczanych produktów, obsługiwanych zamówień w czasie jednostki czasu, np. miesiąca, czyli [Miesiąc/T] sztuk/per miesiąc.

Sformułowanie “szybkość” używam w cudzysłowach, aby zaznaczyć potoczne rozumienie tego słowa, przez porównanie na przykład do szybkości drukowania (10 kartek/minut). Obok tego pojęcia funkcjonuje także pojęcie “prędkości” (wartości z wektorem). W przypadku procesów pojęcia te też podlegają próbie rozróżnienia, wychodząc od pojęć z terminologii angielskiej.

Dlaczego taki proces?

Często wykonuję zakupy w interneciem, mam okazję korzystać z różnych sklepów. Ich systemy do sprzedaży elektronicznej są mniej lub bardziej rozbudowany. Czas dostawy jest podany z większą lub mniejszą dokładnością. Poza jednym przypadkiem, opisanym na blogu, przy okazji wpisu “Diagram Venna w akcji” nie miałem problemów z otrzymaniem zamówionego produktu w akceptowalnym czasie. Dlatego diagram ze wskazanego wpisu posłuży mi do dzisiejszego wpisu.

Na powyższym diagramie znajduje się zmodyfikowana reprezentacja, tego nieudanego procesu, tak, aby pasowała do różnych przypadków procesów. Elementy z mojej perspektywy, czyli Klienta, zostały przedstawione w postaci procesu. Elementy od strony sklepu internetowego, czyli Dostawcy, zostały przedstawione jako wsad (baza Produkty), wynik (baza Finanse) i zasoby (element Pośrednika) niezbędne do przeprowadzenia tego procesu. Linia przerywana obrazuje, że realizacja części procesu jest rozłożona w czasie. Pośrednikiem może być kurier, podmiot usług pocztowych, punkt odbioru itp.

Będąc projektantem, wykonawcą czy odbiorcą takiego procesu można zadać pytanie “Dlaczego taki proces?”. Pytanie tak postawione jest dość ogólne, dlatego łatwiej na nie odpowiedzieć wykorzystując następujące pytania (nie jest to zestaw zamknięty):

• Czego oczekuje i ceni Klient?
  Na to pytanie częściowo odpowiedziałem we wstępie. Oczekuje, że znajdzie poszukiwany produkt, będzie on dostępny i w łatwy i bezproblemowy sposób uda się go zamówić. Natomiast realizacja procesu przebiegnie w akceptowalnym i zgodnym z deklaracjami czasie.
  Więcej o stronie Klient w modelu SIPOC.
• Czego oczekuje i ceni Dostawca?
  Po pierwsze, chce, aby jego produkty znalazły nabywców, że proces zamówień pozwoli je wybrać oraz zamówić. Na diagramie świadczy o tym strzałka z kierunkiem od Bazy Produkty do Procesu.
  Po drugie, że otrzyma przychód z produktu, o czym świadczy strzałka z kierunkiem od Procesu do Bazy Finanse.
  Po trzecie, że wybrani Pośrednicy zrealizują proces zgodnie z oczekiwaniami.
  Więcej o stronie Klient w modelu SIPOC.
• Jakie są słabe i mocne strony procesu?
  Wielokrotnie na blogu pisałem o ocenie procesu, jego opomiarowaniu.
• W czym proces jest lepszy od analogicznego procesu?
  To pytanie odnosi się do benchmarkingu oraz postawionych celów dla jakości usługi.

Proces dla sprawozdań finansowych

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.

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.

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

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.

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

Pytania o realizację procesu

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:

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

PoDajCie dAlej, czyli trochę o PDCA

Wielokrotnie w organizacji można się spotkać z sytuacją, gdy dana informacja, dokument jest przekazywana zgodnie ze strukturą organizacyjną lub w poprzek struktury. Różne działania w jednym Pionie funkcjonalnym mogą odbić się w innym Pionie. Można usłyszeć, że „oni tak robią, może też spróbujemy? Osiągają dobre efekty”. Takie sformułowanie może się zarówno odnosić do komunikacji, zarządzania projektami, realizacji procesów, wprowadzaniu zmian czy po prostu w ramach określonego procesu. Np. Zmiana wyceny pracy, wprowadzenie rozliczeń wewnętrznych między współpracującymi jednostkami, nie zawsze musi oznaczać, że taki sposób postępowania przyjęty został przez wszystkich. A co jeśli się sprawdza? Albo zaobserwowano, że można go było zmienić i zaadaptować? Dobre rozwiązania warto podawać dalej, weryfikować i aktualizować, w szczególności, gdy dane jednostki są uczestnikami jednego z głównych procesów organizacji.

Na powyższym diagramie wskazano różnej długości procesy, w które zaangażowane są jednostki z różnych pionów. W ramach każdego z tych procesów konieczne jest zadbanie o spójność działania, tak, aby proces był efektywny i sprawny. Dodatkowo zaznaczono – poprzez znaczek dokumentu – miejsca styku jednostek, potencjalne miejsca, gdzie występują różnice w działaniu i które należy zbadać. Kierunki dalszego dostosowania – podaj dalej – zostały zaznaczone linią przerywaną. W ich likwidacji może być pomocne podejście PDCA.

Podejście PDCA (tzw. Cykl Deminga) zakłada, że po Zaplanowaniu działań (ang. Plan), następuje ich realizacja (ang. Do), po czym efekt zaplanowanych i zrealizowanych działań jest sprawdzany (ang. Check). Po sprawdzeniu i określeniu różnic, możliwości, koniecznych modyfikacji następuje ich wdrożenie (ang. Act). Wdrożenie nie następuje samo w sobie, zostaje zaplanowane, działania są włączone do dotychczasowych planów. Sam proces zaczyna się od początku. W pewnym momencie na kolejnych punktach styczności proces ulegnie poprawie. Doświadczenia (ang. lessons learned) można podać dalej do kolejnego punktu i rozpocząć proces doskonalenia procesu od początku (a raczej go dalej kontynuować).