Coraz częściej spotykam się z pytaniami na temat modelowania procesów biznesowych w kontekście ich optymalizacji. Pojawiają się także przy tej okazji, pytanie o symulacje. Widuje wiele lepszych i gorszych pomysłów. Moim zdaniem, po pierwsze należy sobie odpowiedzieć na pytanie co w danym momencie optymalizujemy: wewnętrzną strategię firmy czy wydajność (efektywność) w określonej sytuacji.

Optymalizacja ma dwa poziomy: poziom “co i po co robimy” oraz poziom “jak to robimy”. Ten drugi jest “poniżej” pierwszego, to bardziej szczegółowe ujęcie modelu. Najpierw należy jednak optymalizować celowość prac, w szczególności to, czy każdy etap czemuś służy. Na tym poziomie optymalizujemy procesy biznesowe a nie ich efektywność. Tu “walczymy” z ich logiką. Tu mamy procesy biznesowe jako “coś co tworzy produkt”. Po upewnieniu się, że logika tych procesów, słusznie nazywana “wewnętrznym łańcuchem wartości dodanej”, jest poprawna,  analizujemy poszczególne prace (zadania, czynności) i zastanawiamy się czy ich  efektywność jest najlepsza jaką możemy osiągnąć.

Etap procesów modelujemy, że tak powiem, klasycznie. Te modele opisuje tu bardzo często. Problem zaczyna się przy modelowaniu szczegółów czynności.

Swego czasu zafundowałem sobie szkolenie z zakresu “[[Lean Management]]”. Były to dwudniowe warsztaty z obszaru optymalizacji pracy, głównie tak zwanej “biurowej”. Lean to obszar “jak to robimy”. Tu przekonałem się, że każdy problem należy traktować indywidualnie. Jednym jednak z kluczowych problemów jakie napotkaliśmy było udokumentowanie “stanu rzeczy”. Okazało się, że gdy praca wre, często nie  jest to “proces” a dynamicznie zmieniające się środowisko. Nie raz można użyć procedury na opisanie tego co kto robi, jednak nie zawsze jest to możliwe: często silnie obciążone “etapy pracy”, to co jest czynnością na mapie procesu, to mały zespół z jego kierownikiem, rolą kierownika jest stała optymalizacja obciążenia tego zespołu. Próby zapisania tego jako mapy procesu idą w kierunku algorytmizacji tych prac i to jest niestety bardzo często ślepa uliczka: powstają monstrualne, nigdy nie ukończone, diagramy, bo zawsze jest “jeszcze jeden wariant scenariusza”.  Co robić? Tu należy wybrać “właściwy sposób” dokumentowania dla każdego indywidualnego przypadku. W zasadzie mamy trzy możliwości:

1. procedura (scenariusz)
2. reguły biznesowe i decyzyjne
3. mapa sytuacyjna (np. plan pomieszczenia i biurek)

Pierwsza metoda to “algorytmizacja” pracy, opracowujemy najlepszy scenariusz wykonania zadania i czynimy go jedynym dopuszczalnym.  Jedna procedura powinna opisywać pracę jednej osoby (atomowa czynność/zadanie), sposób opisu to może być diagram ale lepiej jest użyć punktowanej listy, gdyż taka procedura musi  być czytelna i przystępna dla tej osoby. Tu idziemy w kierunku taśmy produkcyjnej, praca taka musi być w 100% przewidywalna.

Druga metoda to sposób na rozwiązanie problemu efektywności tam, gdzie warunki pracy się zmieniają zależnie od pory dnia, roku, sezonu, koniunktury. W tym przypadku mamy np. mały zespół i jego kierownika. Rolą kierownika jest podejmowanie decyzji o obciążeniu pracą członków zespołu i nadzorowaniu przestrzegania reguł biznesowych. W sytuacjach nie objętych regułami, kierownik podejmuje sam decyzje lub eskaluje problem do przełożonego (zależnie od posiadanych uprawnień co także należy udokumentować).

Trzecia metoda to metoda polegająca na detalicznym opisaniu pracy w określonej przestrzeni np. ustalona trasa poruszania się wózków widłowych po magazynie albo miejsca przy biurkach zajmowane przez pracowników działu księgowości optymalizujące przekazywanie dokumentów miedzy sobą. Tu nie zawsze rozwiązaniem problemu jest elektroniczny obieg dokumentów, bo w wielu przypadkach nie da się wyeliminować (takie próby bywają nawet czasem zabójcze dla wydajności)  użycia papierowych dokumentów (nie tylko  sądy tak pracują). Ta metoda jest jednak opcjonalnym uzupełnieniem dwóch poprzednich.

Popatrzmy na fragment pewnego artykułu o Lean:

Mapa procesu

Jest to już dość skomplikowany dokument, który bazuje na wielu danych wejściowych, które należy zebrać.Generalnie metoda tworzenia mapy procesu jest następująca:

1) Określamy procesy, które będziemy chcieli zoptymalizować (najlepiej określić poszczególne stanowiska pracy, np. centrum obróbcze nr 1, 2, itd., stanowisko montażowe nr A1, A2, B1, B2, itd., stanowisko naprawcze, spawarka nr 1, 2…)

2) Określamy produkty, które są wykonywane na poszczególnych stanowiskach.

3) Zbieramy dane o dostępności stanowisk/urządzeń w określonym okresie czasu (np. zmiana/doba).

4) Określamy czas standardowy, w jakim jest wytwarzany dany produkt na danym stanowisku, w rozbiciu na setup (przezbrojenie) i czas wykonania 1 sztuki produktu. Przezbrojenie też warto rozbić na część wykonywaną w czasie maskowanym (gdy maszyna wykonuje detal, możemy przygotowywać jakiś etap przezbrojenia) i czasie zatrzymania maszyny (na przykład wymiana narzędzi w magazynku obrabiarki). Czas wykonania 1 sztuki też warto rozbić na czas pracy maszyny i czas pracy człowieka (na przykład każdą część należy ogradować po zdjęciu z maszyny).

5) Określamy jaką część naszych produktów będziemy musieli naprawiać (procentowo).

Są to dane wejściowe, które należy jeszcze obrobić. Robimy to przy pomocy matrycy wykonanej na przykład w MS Excellu.

(WCM, Lean Manufacturing, TPM, IFM… ale o co chodzi?: Mapa procesu).

Bardzo dobry przykład problemu. Mamy tu co prawda pomieszanie pojęć proces i zadanie (niestety bardzo powszechne) oraz produkt i faza, ale widać problem. Pierwsze co należy zrobić, to podzielić elementarny atomowy proces na atomowe, niepodzielne zadania (czynności). Upewnić się, że w danym momencie (jeden model) operujemy pojedynczym procesem a nie ich zlepkiem – co jest wręcz kluczem powodzenia takiej analizy. Niestety tu waśnie widać błąd w powyższym opisie: stanowisko pracy nie zawsze jest procesem, raczej jest pojedynczym zdaniem. Pamiętajmy, że proces tworzy produkt. Stanowisko, na którym ktoś wykonuje tylko dwa otwory wiertarką to zadanie a nie proces. Procesem jest np. kompletne zmontowanie obudowy czegoś tam.

Co robić? Po pierwsze oddzielić “grubą kreską” procesy od zadań. Proces to jedno zadanie lub seria zadań (czynności). Model takiego procesu pokazuje kolejność tych zadań, ewentualne warianty tej kolejności. Jeżeli ma to być “mapa”, proces musi być deterministyczny (przewidywalny w 100%). Jeżeli tylko okaże się, że liczba wariantów zaczyna nam w toku analiz rosnąć, jest to sygnał, że należy zrezygnować z pisania procedury i przejść na metodę  “zespół z kierownikiem”. Taki niepodzielny zespół jest reprezentowany na modelu procesów jako rola w osobie kierownika tego zespołu (lub jako nazwa tego zespołu). Dokumentacja “wnętrza” sprowadza się do listy reguł biznesowych oraz określenia liczebności zespołu.

Optymalizacja procedury może być prowadzona “na sucho” z pomocą symulacji. Tu sugeruje jednak zamiast excela, użyć programu pozwalającego stworzyć model scenariusza i przypisać do każdej czynności czas trwania, zasoby i liczbę instancji (czyli np. równoczesnych wykonawców). Optymalizacja pracy “zespołu” to jednak bieżące “planowanie, obserwacja i korygowanie”. To rola kierownika. Tu, jako metody dokumentacji, są w użyciu listy reguł i plany sytuacyjne.

Kilka lat temu opracowywałem dla PWPW optymalizację procesu obsługi wniosków o karty do elektronicznych tachografów i wydawanie kart kierowców do nich. Tu model procesu (BPMN) opisywał tylko wymagane ustawą i regulaminem etapy (np. czynność przyporządkowania wpłaty do wniosku). To jak najszybciej wprowadzać wnioski do oprogramowania zarządzającego nimi, jak przyporządkować wpłaty, w tym te niezidentyfikowane, czy jak zorganizować przyjęcie sterty papierowych wniosków z poczty, to były szkice sytuacyjne, rozmieszczenie mebli, zespoły zadaniowe i ich kierownicy (zmienne ilościowo, studenci przyjmowani ad-hoc na uowe zlecenie). Całość spinał model tego procesu ale poszczególne czynności były modelowane (dokumentowane) różnymi metodami zależnie od tego “na czym polegał problem”.

W przypadku problemu z identyfikowaniem procesów i zadań, gorąco ogradzam podejście opisane poniżej:

Umiejętność dekomponowania zadań uważam za kluczową jeśli chodzi o zarządzanie czasem. W różnych momentach prowadzenia szkolenia z tego tematu, starałem się formułować mniej lub bardziej zjadliwe procedury do przeprowadzania owej dekompozycji. W końcu mnie oświeciło i wpadłem na tę, jak sądzę, najprostszą, elegancką i skuteczną:)

Definiuj zadania maksymalnie czterogodzinne (źr. Touching the Void: Dekomponowanie zadań).

Jest to moim zdaniem jedna z najgorszych metod, gdyż zakłada nieistnienie zadań mogących trwać dłużej, w efekcie prowadzi to sztucznego, niczym nieuzasadnionego podziału – wprowadzania sztucznych etapów pracy. Podobnie błędne podejście to dzielenie zadań zawsze gdy procedura przekroczy określoną liczbę kroków albo dzielenia “skomplikowanych przypadków użycia” na mniejsze tylko dlatego, że scenariusz przekroczył dopuszczalna liczbę kroków. Tak proces biznesowy jak i przypadek użycia, są definiowane w swoich granicach zdarzeniem na wejściu i faktem wytworzenia produktu, dzielenie ich na “kawałki” to fałszowanie, wprowadzanie sztucznej, nieistniejącej złożoności.