Projekt a proces – „magia” trójkąta

Zdaję sobię sprawę, że stosując brzytwę Ockhama nie powininem tego robić, a mówiąc o procesie, raczej trudno mówić o projekcie. Jednakże załóżmy na chwilę, że problem zakupowy przedstawiony w poprzednim wpisie jest projektem. Projekt ten ma jasno zdefiniowany cel (realizacja zakupów) i określone ramy realizacji. Zgodnie z metodyką zarządzania projektami można przyjąć, że ten projekt funkcjonuje w ramach trójkąta ograniczeń: budżet, czas, zakres.

W opisywanym przypadku zakres jest znany: lista zakupów. Czas oczekiwanej realizacji też mamy ustalony. Zastanówmy się nad 3 elementem: budżetem. Jakby wpłynął na realizację tego projektu, gdyby go zmiejszyć albo okazał się niewystarczający.
Załóżmy, że koszt zakupu danego produktu jest wyższy w sklepie, który wybraliśmy.
Możemy:

•  szukać dalej w innych sklepach, co zwiększy czas realizacji;
• zrezygnować z zakupu, co zmniejszy zakres i koszt zakupów, który można inaczej wykorzystać lub potraktować jako oszczędność;

Strzałki na diagramie wskazują zależności między poszczególnymi elementami. Istotne jest założenie, że podejmując daną decyzję – poszukiwanie lub rezygnacja – trzymamy się tego, że pozostałe elementy są stałe. Podobną analizę można by wykonać zaczynając od innego kąta trójkąta. Skutki jednak byłyby inne.

Wróćmy jednak na chwilę do samego procesu. Powyższe przypadki i decyzje mogą powodować nawroty w procesie, zmiany priorytetów, modyfikację kolejności wykonywania zakupów. Każdy nawrót wpływa na czas realizacji procesu i w zależności od podjętych decyzji, na jego koszt oraz efekt. Realizacja procesu ma przynieść efekty (=efektywność) osiągnięte w akceptowany sposób (=sprawność). Powyższy przykładowy diagram w BPMN prezentuje te nawroty.

Reklama

Proces a projekt

Ostatnio w jednym z wywiadów przedstawionych na stronie Ebizq.net pojawiło się pytanie: „How do project management and business process management relate to each other?”. To pytanie, dotyczące relacji zarządzania projektami i zarządzania procesami biznesowymi, przyciągnęło moją uwagę, na moje zainteresowanie obydwoma dziedzinami. Spotykałem się z różnym zestawieniem relacji, ale najczęściej opierało się na różnicy między projektem a procesem z punktu widzenia organizacji, powtarzalności, granic czasowych i sposobu oceny.

We wspomnianym wywiadzie dziedziny te zostały umieszczone na dwóch biegunach – diagram poniżej. Z jednej strony efektem zarządzania projektami może być zmiana procesu biznesowego, a sama jego realizacja może pozwolić na ocenę realizacji celów projektów, w zakresie np. zaplanowanej zmiany w pracochłonności, zmianie efektywności procesu czy likwidacji wąskich gardeł. Równocześnie uczestnicy procesu mogą wskazać zmiany, które należy wykonać, bądź to w postaci bieżących ulepszeń, bądź poprzez realizację inicjatywy projektowej. Z kolei samo zarządzanie projektem też może się odbywać w ramach określonego procesu działań.

W odpowiedzi na powyższe pytanie pojawia się również dodatkowa kwestia. Zarządzanie procesami biznesowymi jest szersze niż zarządzanie projektem. Myśle, że ta kwestia jest dość oczywista. W ramach wszystkich procesów przedsiębiorstwa niektóre z procesów mogą dotyczyć właśnie zarządzania projektami – proces zgłaszania zmian, proces zarządzania zmianą, proces monitoringu projektów, proces oceny korzyści projektów itd. Dla pewnych jednostek organizacyjnych mogą to być procesy główne, a dla niektórych procesy pomocnicze.

Weźmy na przykład osobę, która wykonuje czynności operacyjne, będące częścią procesu głównego. Równocześnie może zostać zaproszona jako ekspert dziedzinowy do pracy w projekcie w celu przedstawienia obecnego przebiegu procesu lub danego jego kroku

Co dostarczają kroki procesu?

Ostatnio spotkałem się z pojęciem diagramu procesu, który na bazie kroków procesu równocześnie wskazuje, co one dostarczają. Jest to tzw. Process-Deliverable Diagram (w skrócie PDD). Jest to diagram, który łączy w sobie elementy z dwóch obszarów:

• kroków/czynności składających się na proces, zaprezentowanych za pomocą diagramu czynności (ang. activity diagram) z notacji UML,
• obiektów dostarczanych przez proces, zaprezentowanych za pomocą diagramu klas (ang. class diagram) z notacji UML;

Pierwszym procesem, który przyszedł mi na myśl, gdy przeczytałem o tym diagramie, był proces realizacji projektu, zaprezentowany na powyższym przykładowym diagramie. Począwszy od inicjalizacji projektu, przez realizację jego kolejnych działań po wdrożenie, na każdym etapie dostarczany (ang. deliver) jest określony “produkt”. Produkty w całości lub częściowo są wykorzystywane na kolejnych etapach procesu. Te produkty można potraktować jako produkty końcowe procesu. Mogą być np. podstawą kolejnych zmian, przeprowadzania szkoleń, wyjaśniania reklamacji, analizy luk procesu.

Podobne rozwiązanie zostało zastosowane przy prezentacji wejść i wyjść w ramach realizacji procesu rekrutacji.

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 zmiany jakości usługi

W ostatnim wpisie wskazałem, że rozwój usługi z punktu widzenia jakości dla odbiorcy, odbywa się w kilku etapach.

Są to następujące etapy:

1. Zdefiniuj wskaźniki jakości dla usługi – w opisywanym przykładzie z zamówieniem taksówki, jest to czas dojazdu taksówki do klienta od momentu jej zamówienia;
2. Określ jakie są oczekiwania rynku – w opisywanym przykładzie jest to czas do 10 minut;
3. Określ jakie są wartości wskaźnika firm referencyjnych – np. jedna z firm konkurencyjnych zapewnia dojazd w ciągu 7 minut;
4. Oszacuj jaki powinien być cel dla wskaźnika na przyszłość – np. określamy, że dla większości zamówień czas oczekiwania ma być do 8 minut; Idealnie byłoby zejść do 5 minut; W tym kroku określane są także wartości dla punktów przełamania. Zidentyfikowanie momentu w którym następuje punkt nasycenia, jest istotne, aby nie określić celu na poziomie, którego osiągnięcie nie będzie uzasadnione poniesionymi kosztami. Koszty wprowadzenia zmian mogą być różne w zależności od liczby modyfikowanych elementów, zaangażowanych zasobów, a także czasu, w którym cel ma zostać osiągnięty. To wyważenie jest związane ze stworzeniem odpowiedniego planu działania, o który jest kolejnym krokiem procesu.
5. Stwórz plan działania i działaj– np. sprawdzamy jak się układają zamówienia z określonych obszarów, jakie były czasy przejazdów, patrząc także na miejsca postoju taksówek i czas reakcji kierowców. Plan działania może też przewidywać jakie elementy dodatkowe wprowadzić przy realizacji usługi, aby czas dłuższy od konkurencji, jednak był akceptowalny;
6. Zweryfikuj plany działania i zaktualizuj – tutaj konieczna jest obserwacja rynku, zachowań konkurencji oraz reagowania na sytuację, gdy wprowadzone zmiany nie przyczyniają się do określonego celu. Szczególnie gdy koszt wprowadzenia zmian przestaje być akceptowalny lub nie da się go uzasadnić poprzez osiągane efekty.

Przejście przez powyższy proces to jakby przechodenie przez kroki PDCA. Najpierw mamy planowanie (kroki 1-5), potem wykonanie (krok 5), weryfikacja (krok 6) a na koniec przeprowadzenie zmiany (krok 6). Największy nacisk jest na krok planowania, w którym określamy podstawę działania, umiejscawiamy jej parametry względem rynku i określamy gdzie chcemy się znaleźć na przyszłość. Kolejne etapy mogą zostać wsparte przez inne techniki (m.in. związane z zarządzaniem projektami). Ważnym elementem całego procesu jest komunikacja, aby uczestnicy procesu byli świadomi gdzie są i do jakiego stanu zmierzamy – o tym elemencie pisałem już wielokrotnie.

Zmiana procesu – ponownie „magia” trójkąta

We wpisie o słabym ogniwie procesu, skupiłem się na procesie zakupu biletu w biletomacie. Problem, na który napotkałem dotyczył odrzucania monet oraz banknotów przez biletomat. Wskazany krok procesu „Rozpoznaj banknoty/monety” jest słabym ogniwem procesu. Po którymś razie, jako ćwiczenie, postanowiłem napisać do „właściciela” biletomatów uwagę, że „biletomat odrzucał banknoty 10 zł (starym, pomimo, że wyświetlał możliwość płatności nimi) a także wszystkie monety (5 zł, 10 gr, 50 gr itd). […] podobnie biletomat w tramwaju. […] braku dostosowania do nowych banknotów.”. Niestety jeszcze nie otrzymałem odpowiedzi.

Po kilku dniach, przeczytałem artykuł w prasie lokalnej, że zamiast dostosowania biletomatów, aby lepiej radziły sobie z różnymi monetami i banknotami, nastąpi ich wymiana na całkowicie nowe biletomaty. Pewnie korzyścią dodatkową ma być dostosowanie do już długo przygotowywanej karty aglomeracyjnej.

Projekt zakupu, oprogramowania, instalacji obecnych biletomatów był określony przez określony zakres wymagań, koszt i czas realizacji. Teraz projekt wymiany znowu wymagać będzie czasu, instalacji oraz oprogramowania. Dodatkowo mamy kwestię poradzenia sobie ze starymi biletomatami. Równocześnie jednak oprogramowanie i mechanizmy w nowych mają dawać więcej użytkownikom końcowym. Może udałoby się dostosować stare biletomaty. Nie wiem jakie są szczegóły, więc ciężko analizować dalej.

Z punktu widzenia użytkowników, całkowita wymiana to znacznie dłuższy czas oczekiwania niż pewnie dostosowanie istniejących. Zakładając, że wdrożenie niniejszego procesu obsługi, związane było z pewnymi kosztami, czasem i zakresem – niebieskie elementy diagramu powyżej, działania zmierzające do jego poprawy, takie jak dostosowanie istniejących, rozbudowa istniejących oraz wymiana, wpływają odpowiednio na czas, zakres oraz koszt. Dana czynność może też wpływać na więcej niż jedną część trójkąta. Na diagramie zostało zaprezentowanych kilka możliwości.

Model długi ogon a procesy

Ostatnio trafiłem na stronę Lulu.com, która pozwala (informacja ze strony) na publikowanie przez autorów z całego świata książek i oferowanie ich do sprzedaży. Autor nie musi szukać wydawnictwa, które zrealizuje jego publikację. Rejestruje się na stronie, zamieszcza materiał w odpowiedniej kategorii i czeka aż jeden z „czytelników” zamówi jego książkę. Platforma łączy autorów z czytelnikami. Czytelnik szuka publikacji, którymi jest zainteresowany a każdego dnia w serwisie może się pojawić nowy autor z nową publikacją w danej tematyce.

Model ten, nazywany modelem Długiego ogona, zakłada (definicja na podstawie książki Business Model Generation, którą polecam), że dostarczamy mniejsze ilości (pojedyncze publikacje poszczególnych autorów) większej liczby usług (publikacje autorów z całego świata). Można powiedzieć, że pojedyncze publikacje są niszowe i tylko pewna część z nich się sprzeda (trafi do druku).

Na platformie łączą się 2 procesy, inicjowane przez dwóch różnych uczestników – autora i czytelnika. Pierwszy z nich to dostarczenie publikacji przez autora, a drugi, już wielokrotnie przeze mnie prezentowany proces zakupowy. W przypadku autora, załóżmy, że nowego, proces w uproszczeniu może odbywać się wg schematu, przygotuj publikację, zarejestruj się, opublikuj, co prezentuje powyższy diagram.

Zakładając, że w serwisie pojawia się nowy czytelnik, proces przebiegać może zgodnie ze schematem – wybór książki, rejestracja opłata, realizacja – szczegóły na przykładzie zakupów w internecie np. w czerwonym procesie, który opublikowałem jakiś czas temu). Dla procesu na takiej platformie istotne są kroki – „Wybór rodzaju dostawy” i odpowiadająca mu „Realizacja zamówienia”.

Na danej platformie są realizowane różne procesy przez wielu uczestników. W zależności od modelu działania platformy, procesy mogą być niezależne albo tworzyć jeden powiązany ciąg. Innym rozwiązaniem, nie działający już mechanizm Lego Factory, gdzie zamówienie i pomysł na produkt, pochodził od jednej strony – Klienta (projekt klocków i ich zamówienie), a realizacja odbywała się jako wynik procesu.

Proces publikacji artykułu

Po opublikowaniu ostatniego wpisu, wyszła ciekawa kwestia. Autor cytowanego artykułu wskazał w komentarzu, że opublikowana treść powstała bez jego wiedzy i akceptacji, na bazie artykułu o tematyce zwinnego modelowania sprzed 4 lat, który zawiera wspomniane przeze mnie elementy. W szczególności zawiera element udziału interesariuszy projektów w poszczególnych etapach modelowania zwinnego a nie tylko na końcu.

Kwestia publikacji artykułów, przemyśleń, analiz bez akceptacji i autoryzacji w innych serwisach, często w zmienionej formie, jest zjawiskiem myślę dość częstym w Internecie. Kilka lat temu, kolega powiedział mi, że czytał mój artykuł na pewnej stronie. Moje zdziwienie było duże, ponieważ nie znałem nawet wspomnianego serwisu. Nie wiedziałem, że został tam opublikowany, wręcz skopiowany z innego serwisu, z drobnymi różnicami w nagłówku i stopce. Skontaktowałem się z redaktorem tego innego serwisu, i okazało się, że nikt o niego nie prosił. Ostatecznie artykuł w nieakceptowanym miejscu zniknął.

Tak sięzastanawiam, że, aby być zgodnym z obowiązującymi zasadami, serwisy te powinny postąpić inaczej. Po pierwsze spytać o możliwość publikacji, a po drugie uzyskać autoryzację określonej treści artukułu. W obydwu przypadkach jednak kroki te nie wystąpiły. Ciekawe w ilu przypadkach zapełnianie treścią stron odbywa się w taki sposób, z nadzieją, że autor nie trafi na strony i na przykład nie poprosi o usunięcie lub opłatę za opublikowaną treść.

Na powyższym diagramie (w BPMN) spróbowałem przedstawić kroki takiego procesu. Kilkakrotnie miałem już telefon lub zapytanie mailowe o zgodę na wykorzystanie artykułu zgodnie z taką procedurą.

Czynności dla wartości procesu

Odbierając zwrot jednej z przesyłek na poczcie, przypomniałem sobie o jednym z zadań, które kiedyś musiałem wykonywać. Co tydzień, musiałem „dostarczyć” przesyłkę z jednego końca miasta na jego drugi koniec. Przesyłka miała dotrzeć tego samego dnia, do godziny 12, tak, aby obiorca (Klient) mógł wykorzystać dane z przesyłki w swoich działaniach. Proces, bo o nim można mówić, wyglądał jak na poniższym diagramie:

Zastanówmy się jak elementy tego procesu wpływają na wartość dostarczaną Klientowi. Klient płacił miesięcznie określony ryczał za dostarczony materiał – stała cena. Z jego puntku widzenia istotne były elementy: termin dostarczenia, zawartość oraz cena, którą płaci – co przypomina omawiany wczesniej trójkąt ograniczeń: zakres-cena-czas. Dostarczona przesyłka miała dla nego określoną wartość, mógł ją dalej wykorzystać w zaplanowanych ramach czasowych. Nie było dla niego istotne, kto i w jaki sposób dostarczy przesyłkę.

Z kolei dostawca, rozliczał się z kurierem niezależnie. Planował przygotowanie przesyłki. Ustał termin odbioru i dostarczenia z kurierem, biorąc pod uwagę takie elementy jak wielkość przesyłki, okres miesiąca/roku, pogodę, informację o natężeiu ruchu czy dostępność kuriera.

Do czego zmierzam? Chciałbym zobrazować na tym prostym przykładzie, 3 rodzaje działań rozróżnianych przez literaturę, decydujących o wartości procesu dla klienta i mogących go ewentualnie przekonać do zaplaty więcej za efekt procesu.
Te 3 rodzaje działań to:

• czynności dodające, zmieniające wartość (na niebiesko) – np. terminowa dostawca i przygotowanie przesyłki,
• czynności bez wartości dodanej (na zielono) – np. rozliczenia z kurierem, z klientem,
• czynności umożliwiające wzrost wartości (na żółto) – np. przygotowanie materialów na przesyłkę z wyprzedzeniem, rezerwacja kuriera, co może ewentualnie przyczynić się do skrócenia czasu dostawy. Inny przykład to przekazanie przesyłki kurierowi.

Czarno na białym – o językach i procesie

Pozostańmy jeszcze przy klimacie zakupowym. W poprzednich newsach skupiałem się na realizacji zakupów jak na procesie, potem wskazywałem skutki wzrostu ceny czy niedostępności danego produktu. Tworzenie listy zakupów, określanie sklepów, potencjalnej drogi do przebycia, umiejscowienie jej w czasie i przestrzeni odbywa się jakby równocześnie, dynamicznie, w sposób, trzeba przyznać, który trudno ubrać w ramy. Próbowałem to w najprostszy sposób uporządkować. Można jednak na to spojrzeć inaczej. Patrzyłem na umysł jak białą skrzynkę (ang. white box) – próbowałem przedstawić jej procesy.

Potraktujmy umysł jak tzw. czarną skrzynkę (ang. black box). Musimy wykonać listę zakupów, zleconą przez kogoś innego lub po prostu stworzoną stopniową. Bierzemy ją pod obróbkę i czarna skrzynka proponuje. Można powiedzieć, że tworzymy zapytanie o pewnym formacie: „Podaj mi trasę po sklepach dla zdefiniowanego koszyka zakupów”. Czy nie przypomina to zapytania do bazy danych bądź systemu analizy danych?

„SELECT DISTINCT [ELEMENTY TRASY] FROM [BAZA INFORMACJI] WHERE [PRODUKTY] IN [ZDEFINIOWANA LISTA] ORDER BY [IDENTYFIKATOR POZYCJI] ASC

Do czego zmierzam? Po pierwsze, do generacji języków programowania. Podany przykład jest uproszczonym stwierdzeniem dla języków tzw. 4 generacji (4GL). Takie zapytanie jest przepisywana na kolejne poziomy z generacji języków programowania, aż schodzimy do poziomu właściwego dla języka maszynowego, wykonywania pojedynczych operacji. Pewnie specjaliści od budowy mózgu powiedzieliby, że na najniższym poziomie w mózgu też można mówić o pseudo „języku maszynowym”. Wszystko to odbywa się w czarnej skrzynce, a odbiorca nie musi znać szczegółów. Tak jak my nie wiemy, co się dzieje w mózgu, gdy myślimy.

Równocześnie, przytoczone przykłady obrazują dwa sposoby reprezentacji procesów biznesowych, odbywające się w interakcji między 2 podmiotami/aktorami. Pierwszy operacje białej skrzynki, ten drugi czarnej skrzynki.