Archive for Styczeń 2013

h1

Oczekując na zdarzenie

Styczeń 31, 2013

Telefon z recepcji hotelowej przypomniał mi o moim zamówieniu. Informacja była prosta, że w tej chwili nie mogą zrealizować zamówienia. Powiedziałem, że mogę poczekać nawet godzinę. No właśnie, złożyłem zamówienie i czekałem na wynik, w sumie nieistotne było dla mnie jakie czynności przed czy po telefonie wykonują żeby zrealizować moje zamówienie. Czy sprawdzają listę zamówień? Czy pytają tych co się opóźniają ze zwrotami? Jak się komunikują między recepcją a osobami realizującymi? Dla mnie ważny jest efekt, że po zgłoszeniu zamówienia, po jakimś czasie mogę się spodziewać pukania do drzwi. Oczekuję jakby na określone zdarzenie, a dokładniej zareaguję na zdarzenie, które nastąpi.

hotelowy1

W ten sposób działa proces w przypadku tzw. czarnej skrzynki. W centrum zainteresowania są operacje, komunikaty wykonywane/wysyłane przez jedną ze stron i ich efekt. Na powyższym diagramie recepcję/obsługę można traktować jako czarną skrzynkę.

Czas między zgłoszeniem a zdarzeniem „pukania do drzwi” może wpłynąć na:

  • ocenę realizacji procesu, jego efektywności,
  • postępowanie w przyszłości, że wcześniej zacznę proces (wcześniejsze zgłoszenie),
  • ewentualne skrócenie czasu, który będę oczekiwać na realizację,
  • rezygnację z usług i realizację ich w inny sposób,
  • ewentualne zasygnalizowanie czasu akceptowalnego oczekiwania w momencie zgłoszenia.

Z punktu widzenia recepcji/obsługi, mogą wpisać w informacji dla gościa, że czas oczekiwania na zamówienie może trwać tyle i tyle, a także w którym momencie gość zostanie powiadomiony o przedłużeniu czasu realizacji – podobnie jak w przypadku rozpatrywania reklamacji.

W zależności od punktu widzenia, wnioski są różne. W przypadku recepcji/obsługi przyjęcie zamówienia jest podobnym punktem, ale zgłoszenie możliwości odbioru jest jeszcze ważniejszym, ponieważ oznacza, że można zrealizować kolejne zamówienie innego gościa, który także ocenia proces realizacji, o innych lub podobnych akceptowalnych parametrach.

Reklamy
h1

Równoczesne ścieżki procesu

Styczeń 27, 2013

Uruchamiam w pewien weekend swój komputer i po kilku sekundach widzę komunikat o braku możliwości odczytu dysku. Dobra restartuję go i zastanawiam się co się mogło stać. Próbuję ustalić przyczynę problemu i znaleźć możliwe rozwiązania, zgodnie z metodologią 8D, o której pisałem ponad rok temu. Próbuję komend na poziomie linii poleceń, sprawdzania dysku, uruchomienia trybu awaryjnego, załadowania poprzedniej wersji. Wszystkie działania wykonywałem sekwencyjnie. Ostatecznie skończyło się na instalacji systemu od początku. Mówi się trudno.process_rownoczesny_450

Wrzuciłem płytkę, zmieniłem tymczasowo kolejność źródeł uruchomienia systemu. Wreszcie pojawił się ekran – uruchom system z dysku lub zainstaluj system. Wybrałem to drugie i po kilku ekranach zaczyna się kopiowanie plików. A tu nagle zaskoczenie, mogłem równocześnie konfigurować przyszły system. Ooo…, coś nowego. Zwykle działo się to sekwencyjnie – najpierw kopiowanie potem parametry lub na odwrót. A tu taka oszczędność czasu.

Powyższy przykład można zobrazować diagramem w BPMN przy wykorzystaniu elementów pozwalających na rozdzielenie procesu na dwie równoczesne ścieżki (tzw. parallel gateway). Element początkowy rozdziela ścieżkę a element końcowy łączy. Przejście do dalszej części procesu możliwe jest dopiero po zakończeniu obydwu ścieżek. Gdyby czynności były sekwencyjnie ułożone nie byłoby tego elementu. Przed rozdzieleniem były pewne zadania istotne dla obydwu ścieżek, a potem były zadania będące efektem wszystkich wcześniej zakończonych kroków – uruchomienie systemu po raz pierwszy w wybranej wersji językowej i dla danego użytkownika.

h1

Ale to nie tak działa…

Styczeń 24, 2013

Setny wpis, a sama liczba 100 na przełomie stycznia i lutego kojarzy się z studniówką, do której przygotowują się licealiści. Wybór miejsca, jedzenia, muzyki, stroju, partnera itd. Można powiedzieć, że weryfikowana jest pewna lista kontrolna. A kolejne czynności układają się w proces. Tak to można określić. Kwestia przypomina mi pewną historię. Pamiętam jak kiedyś w czasie okresu przygotowań do studniówki, wychowawczyni klasy zadecydowała, że na wychowawczej będziemy wybierać pary do poloneza, znaczy się ona będzie wybierać.

Więc zaczęła wybierać, najpierw partnerka (nieistotne czy alfabetycznie, czy tak jak siedziały w klasie), a potem dobierała partnera. I tak szło, partnerka-partner, partnerka-partner, i było coraz ciekawiej. Można powiedzieć że był to powtarzalny proces z dwoma czynnościami, który zgodnie z jej założeniami procesu, kończył się, gdy wszyscy będą posiadać parę lub skończą się partnerki lub partnerzy. W sumie nieistotne, które zdarzenie zakończyło proces. Kroki na poniższym diagramie w BPMN, poza zielonym zdarzeniem, oznaczają proces założony przez wychowawczynię.

polonez2a450

Jednak sytuacja, nie była taka idealna, gdy próbowała wybrać jednego z partnerów, powiedział, że nie jest to możliwe, ponieważ już się umówił na parę do poloneza – jednym słowem jest zajęty. Wiedział widocznie z kim chcę iść i poczynił odpowiednie kroki wcześniej. Pojawiło się nowe zdarzenie w procesie (oznaczone na zielono na diagramie), które wprowadziło zamieszanie. Efektem jest alternatywna (a może wyjątkowa?) ścieżka postępowania – tłumaczenie, zmiana jego decyzji, poszukanie rozwiązania. Wychowawczyni nie do końca wiedziała jak zareagować – było to, co czego się nie spodziewała.

Czasami jest też tak w rzeczywistości, ktoś zakłada określony przebieg procesu, zbiera informację i w pewnym momencie trafia na jednego uczestnika, który miał potwierdzić proces, który stwierdza: „Ale to działa tu inaczej, ja robię to i to, a wtedy i wtedy, to…”. Dlatego tak istotne jest zaangażowanie uczestników procesu w przygotowanie procesu. W innym przypadku narażamy się na ryzyko, że jakieś zdarzenie zniweluje efekty naszej dotychczasowej pracy, a czas potrzebny na opracowanie procesu wydłuży się. Warto się wcześniej przygotować, zebrać eksperów dziedzinowych, przedstawić cel opisu procesu, jakie są granice procesu i zachęcić do zaangażowania. Warto także uzyskać potwierdzenie od osób zaangażoanych czy zgadzają się na założenia procesu lub wcześniej zarysowane jego granice.

h1

Nazwy kroków procesu

Styczeń 17, 2013

Po zamieszczeniu ostatnich wpisów, wszedłem na już cytowane przeze mnie forum analityków biznesowych – ModernAnalyst.com. Pojawił się na głównej stronie bardzo ciekawy artykuł dotyczący języka BPMN. Artykuł dotyczył przejścia w diagramach BPMN od antywzorów do najlepszych praktyk – „Efficient BPMN: from Anti-Patterns to Best Practices„. Dzisiaj chciałbym się skupić na 1 antywzorcu.

Po przeczytaniu artykułu, otworzyłem aplikację, w której tworzę diagramy, zacząłem od prawie najnowszego diagramu z prezentacją granic procesu i musiałem przyznać, że diagram nie jest zgodny z najlepszymi praktykami w zakresie nazewnictwa. W całym diagramie zastosowałem różne formy nazw czynności – rzeczowniki czy różne formy czasownikowe.

granice_procesu_popr450

Zgodnie z antywzorcem nr 1 (Anti-Pattern #1: Inconsistent Naming) podanym przez autora artykułu:

  • nazwy czynności powinny składać się z silnych czasowników i nazw właściwych dla domeny – w tym obszarze wybrane diagramy wymagają poprawek, ponieważ czasami stosuję dość nieprecyzyjne nazwy kroków,
  • bramki nie powinny mieć nazw – nie używam nazw,
  • nazwy czynności nie powinny zwierać „lub” i „i” – nie używam łączników w nazwach czynności, rozbijam je w przypadku i, a dla lub dodaję bramki,
  • nazwy powinny być krótkie, a szczegóły w dokumentacji – z racji, że staram się diagramem uzupełnić wpis, czasami nazwy są dłuższe a czasami krótsze,

Powyższy diagram prezentuje sposób zastosowania pierwszego wymogu – nowe nazwy otoczone przerywaną linią. Rzeczywiście proces wygląda lepiej i wskazuje jednoznacznie na zadania do wykonania.

h1

Proces a projekt

Styczeń 10, 2013

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

procaproj450

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

h1

Granice procesu

Styczeń 3, 2013

Czasami mówimy „Muszę zrobić przelew” i wtedy mamy pewnie na myśli proces od momentu określenia danych odbiorcy, poprzez zalogowanie do serwisu on-line, wypełnienie danych, autoryzację i wylogowanie. Z punktu widzenia Klienta proces zaczyna się wcześniej niż proces postrzegany przez operatora systemu. Operator określa, że wykonanie przelewu jest możliwe dla zalogowanego użytkownika, z odpowiednimi uprawnieniami (dostępnymi opcjami), limitami oraz możliwościami autoryzacji przelewu.

Można powiedzieć, że granice procesu są różne – jedne szersze, a drugie węższe.

granice_procesu450

Na powyższym diagramie:

  • kolorem czerwonym oznaczone są kroki poza granicami procesu w systemie, o którego przebiegu decyduje operator systemu on-line;
  • kolorem niebieskim oznaczone są kroki automatyczne, wykonywane w tle, istotne dla przeprowadzenia procesu;
  • kolorem szarym oznaczone są kroki pozwalające na dostęp do systemu, danej funkcji systemu i wyjście z systemu; obok możliwości wykonania przelewu ich efektem – w szczególności weryfikacji uprawnień – może być udostępnienie innych funkcji;
  • kolorem żółtym oznaczone są elementy właściwego procesu pozwalającego na wykonanie przelewu.

Patrząc od żółtych kroków, mamy najwęższe granice procesu. Uwzględniąc wszystkie kolory mamy najszersze granice.