W 2005 roku napisałem dosyć radykalnie:
Jedną z prostych metod oceny wykonanej mapy procesów biznesowych jest sprawdzenie czy diagram zawiera symbole decyzyjne (z reguły są to romby z odnośnikami tak/nie). Jeżeli są, to nie jest to model procesów! Diagramy ze ścieżkami decyzyjnymi to procedury a nie procesy. Cechą charakterystyczną procesu w biznesie jest jego obligatoryjność i jednoznaczność. Czyli jeżeli uznajemy, że dany proces w firmie jest to znaczy, że jest a przedmiotem dyskusji może być jego wewnętrzna organizacja.
Przykład. Wykonujemy model Urzędu. Załóżmy, że jednym z celów funkcjonowania tego Urzędu jest wydawanie decyzji o malowaniu trawy (Process). Na wejściu (Inputs) będzie prośba petenta (wraz z wymaganymi załącznikami) o wydanie decyzji a na wyjściu (Outputs) wydana decyzja. Sposób podejmowania decyzji określa procedura i aktualny stan prawny (Constraints). Zasobem niezbędnym jest kompetentny pracownik (Resources). Decyzja jest zawsze, może zaś być pozytywna lub negatywna. Nie ma tu mowy o tym czy decyzja jest w ogóle wydawana bo JEST. Tak więc proces jest zawsze, jego wynik może być różny. Na poprawnej mapie procesów dla tego urzędu będzie więc między innymi symbol tego procesu ale żadnych ?rombów?. (polecam lekturę całego artykułu Modelowanie biznesowe czyli pilnowanie hochsztaplerów).
Nie raz spotykałem się krytyką tej tezy, no bo jak to, „ma nie być rombów decyzyjnych w procesie”? Otóż od dawna jestem zwolennikiem modelowania z użyciem reguł biznesowych i separowanie ich od modelu procesu. Na stronie Business Rules Group publikowany jest między innymi tak zwany Business Rules Manifesto (Manifest Reguł Biznesowych, jest także do pobrania wersja polska), który zawiera między innymi definicję reguł biznesowych:
Artykuł 2. [reguły biznesowe są ] Oddzielone od procesów, a nie zawierające się w nich. 2.1. Reguły są bezpośrednimi ograniczeniami narzuconymi na funkcjonowanie organizacji jak również mogą stanowić wsparcie dla jej funkcjonowania. 2.2. Reguły nie są procesami ani procedurami. Nie powinny być w nich zawarte. 2.3. Reguły mają zastosowanie ponad i pomiędzy procesami i procedurami. Powinny stanowić jeden spójny organizm, stosowany konsekwentnie w odpowiednich obszarach aktywności biznesowej.
Definicja procesu, którą nie raz tu przytaczałem:
Proces to przekształcenie wejścia w wyjście, z użyciem pewnych zasobów w obecności pewnych ograniczeń.
Proces biznesowy to powyższe, wzbogacone o „… gdzie wyjście (produkt) procesu stanowi dla odbiorcy większą wartość w stosunku do jego wejścia”.
Metod modelowania procesów jest wiele, ja używam notacji BPMN. Jest to dobrze opisany system pojęciowy i wygodny w stosowaniu. Z pomocą notacji BPMN można modelować procesy na dowolnym poziomie abstrakcji. Notacja ta powstała i jest rozwija w celu opisu procesów wykonywalnych, jednak to zastosowanie nazwał bym mimo wszystko niszowym. System pojęciowy BPMN jednak doskonale nadaje się do modelowania na wyższym, niż wykonanie, poziomie abstrakcji.
Zanim pokażę przykład, przytoczę inny popularny „obrazek”, a mianowicie strukturę piramidy obrazującą trzy poziomy modelowania organizacji. Żeby nie było nudno nie będzie to mój diagram, znany z poprzednich moich wpisów na tym blogu, a model a zapożyczony ze strony Business Process Trends. Robię to celowo, by zwrócić uwagę na to, że to powszechnie przyjęty podział, spotykany także u klasyków reorganizacji Rumllera i Brache’a i Rogera Burltona.
Model ze stron BPTrends ma następującą postać:
Jak widać tu także proces biznesowy to abstrakcja środkowej warstwy. Modele wykonawcze to ciągi czynności realizowanych przez ludzi (nie koniecznie z pomocą systemu komputerowego, także proceduralne). Na najniższym poziomie mamy ludzi, ich wiedzę i umiejętności (praca i szczegółowość jej opisu zależy od wiedzy i umiejętności wykonawcy). Mamy także IT bo procesy wykonywalne (ich modele) mogą być implementowane w systemach workflow.
Proces biznesowy, nie procedura i nie opis przepływu pracy, to prosty ciąg czynności, których celem jest konkretny rezultat: produkt procesu (jego wyjście). Tu pominę dokumenty (produkty czynności) by uprościć diagram.
Proces ma cel, stanowi prosty łańcuch pracy wykonawcy (Rola), radzi sobie z wydarzeniami „utrudniającymi”. Główny ciąg (oczekiwany) zaznaczono szara strzałką. Pozostałe „atrakcje” to czynności wymuszone pewnymi nie oczekiwanymi (a raczej nie chcianymi), ale przewidzianymi zdarzeniami. Tu nie ma „rombów”, bramek decyzyjnych bo one są cechą „procesów decyzyjnych”, procedur, a te to reguły biznesowe i „wiedza o biznesie” a nie proces biznesowy. Pewne czynności mogą być ograniczone Procedurą, która mówi, że „tylko tak wolno tę pracę wykonać”.
Kilka lat temu na jednej z konferencji, opisywałem zakres pracy nad wdrożeniem systemu ERP:
Analiza i zakres projektu to opis strategii. Jest to główny, stały element projektu: strategia firmy musi być ustalona przed jakimkolwiek projektem wdrażania zmian. Procesy biznesowe opisują jak to robimy. Tu jest miejsce na ewentualne optymalizacje (modyfikacje wewnątrz łańcucha wartości. I najważniejsze:
Opracowywanie wymagań to planowanie zmian. Nie ma sensu spisywanie szczegółów tej pracy, jeżeli wdrażane zmian spowoduje powstanie np. nowych procedur, wynikających z celu projektu. Zupełnie wystarczy posiadanie wiedzy o procesach i ich produktach (co i po co robimy). To jak one będą powstawały (w jaki sposób) będzie efektem wdrożenia np. nowego systemu ERP i istniejących ograniczeń, reguł biznesowych.
Kluczem jest posiadanie specyfikacji reguł biznesowych i modelu procesów na opisanym „środkowym” poziomie.
Reguły biznesowe to wewnętrzne (np. zarządzenia) lub zewnętrzne (prawo) ograniczenia. Na poprzednim diagramie pojawia się rola czyli wykonawca (tu rola działu HR – opis kompetencji pracowników czyli specyfikacja ról), Wykonawca posiada niezbędną wiedzą i umiejętności, potrafi obsługiwać „maszyny” (także oprogramowanie). Tak więc definicja mówiąca, że proces wykonuje się w środowisku ograniczeń i wymaga zasobów tak właśnie wygląda: zasoby to ludzie (role), ich wiedza i narzędzia pracy, ograniczenia to reguły biznesowe i procedury.
To, opisane tu podejście, to jedno z możliwych podejść. Praktyka pokazuje, że rzadko stosowane (wymaga doświadczonych konsultantów i znajomości tych metod pracy) ale też najskuteczniejsze. Modele procesów są relatywnie proste, sztuką takiej analizy jest wyodrębnienie reguł biznesowych. Co otrzymamy? Biznesowy know-how – najcenniejszą rzecz w firmie. I po to warto wykonać analizą biznesową: poznać i udokumentować swoją przewagę czyli firmowe know-how.
Jeżeli wpleciemy reguły biznesowe i procedury w model (mapy) procesów, to po pierwsze powstaną wielkie i trudne w odbiorze diagramy a po drugie zatracimy (ukryjemy w gąszczu obiektów na diagramie) całą wartość firmy czyli jej nagromadzoną wiedzę. Po trzecie…
… projekty związane z wymaganiami na oprogramowanie to definiowanie wymagań na narzędzie pracy. Jeżeli nie będzie możliwe, czy nawet łatwe, wyodrębnienie tego co musi umieć człowiek a co powinien robić program, projekt czekają kłopoty bo będzie to odkrywane dopiero w trakcie wdrożenia – a to bardzo kosztowna metoda.
Autorze,
Notacja BPMN jednoznacznie identyfikuje process jako zestaw/sekwencje Czynnosci (Activities) majacych na celu wykonanie pracy. Graficzna reprezentacja Procesu pbejmuje Elementy Przeplywu (Flow Objects), takie jak Czynnosci, Zdarzenia, Bramki Decyzyjne.
W tym kontekscie ograniczenie w postaci wyeliminowania bramek decyzyjnych z procesu jest chyba nadmiernym uproszczeniem?
Osobiscie podoba mi sie bardzo Panskie podejscie do problemu – process ma wejscie I wyjscie, pomiedzy ktorymi nastepuje przeksztalcenie, ograniczane zasobami I regulami, ktore jes szczegolnie przydatne w firmie o profile dzialalnosci jak w ktorej pracuje. Ale stwarza tez problem…
Pozwole sobie uzyc przykladu (ogolnego): w mojej firmie jeden z glownych procesow biznesowych – Obsluga klienta indywidualnego nabywajacego okreslony produkt – moze miec cztery rozne wyniki. Jeden z nich zalezy od wyniku sprawdzenia GLOWNEGO AKTORA (Klienta, czyli czy mozna z nim w ogole robic interes), pozostale zaleza od dostarczonej informacji LUB zdarzen zewnetrznych (determinuja czy klient zostanie obciazony koncowa platnoscia czy nie), oraz kazde z nich wystepuje na innym etapie realizowania uslugi.
W uproszczeniu wyglada to tak: klient zamawia usluge, dostaje wycene i wplaca zaliczke. Tylko po wplacie zaliczki nastepuje jego weryfikacja I jej wynik determinuje kontynuowanie procesu lub zwrot zaliczki I terminacja uslugi. jesli jest pozytywna obsluga trwa dalej – I nastepuje podpisanie kontraktu I dalsza realizacja uslugi. Jesli negatywna klient otrzymuje zwrot I decyzje odmowna.
W kontekscie preferowanej definicji proces ten jest nie do opisania. Chyba…
Pozdrawiam.
Pierwsza ważna rzecz w analizie to odróżnienie języka modelowania (opisu) od kontekstu tego co jest modelowane (modelowanie z użyciem BPMN to nie opis). Język polski jest bardzo bogaty (jak każdy inny mówiony), jednak np. na spotkaniach biznesowych nie przeklinamy (ograniczenie swobody użycia języka), a na niektórych spotkaniach skupiamy się z zasady tylko na celu działania, a nie na rozwiązywaniu „problemów wszelakich” (mimo, że wiemy iż istnieją). Eliminowanie bramek decyzyjnych to taki zabieg myślowy, którego celem jest skupienie się na celu (ścieżka optymistyczna czyli prawdziwy cel procesu) biznesowym. Owszem jest to uproszczenie, jego celem jest skupienie się na pryncypiach danego biznesu.
W Pana przykładzie proces jest inicjowany przez Klienta, wejściem jest to czego chce (klient mówi co chce, po co przyszedł). Wyjściem (produktem procesu) jest „zapis tego jak się to skończyło”, gdyż z natury rzeczy chcemy znać efekt naszej pracy. Owe cztery zakończenia to cztery statusy jednego końca procesu albo po prostu treść (informacja) tego jak się ten kontakt klienta z nami skończył. Podam prosty przykład: proces kształcenia zaczyna się zaświadczeniem o przyjęciu na studnia a kończy się dyplomem. Ten proces ma jeden koniec (produkt), jest nim dyplom, a nie pięć różnych końców czyli możliwych ocen ukończenia studiów. Owszem, wewnętrze tego procesu może być nafaszerowane złożoną logiką, jednak warto pamiętać, że proces biznesowy, jego faktyczny przebieg, to efekt reguł biznesowych oraz umiejętności wykonawcy. Tak więc proces jaki Pan opisał jest jak najbardziej do opisania, wystarczy nie zapominać, że mamy możliwość użycia kilka poziomów abstrakcji. Polecam mój niedawny wpis „Sekwencje a procesy„.
Tak więc na ogólnym poziomie każdy Pana przypadek pojawienia się Klienta kończy się zawsze jakąś informacją o tym jak się to skończyło (a to czy pozytywnie czy negatywnie wynika z treści takiej informacji). To jaki scenariusz w danym przypadku miał miejsce, zależy od tego w jakich warunkach się to odbywało. Niech Pan teraz spojrzy na potrzebę raportowania skuteczności (jakości) obsługi klientów: jakie informacje będzie Pan agregował by to ocenić? Zapewne zrobi Pan raport (zestawienie) wszystkich informacji o tym jak zakończyła się każda sprawa klienta, a każda ma jeden koniec, który może być albo rezygnacją z obsługi albo realizacją zamówienia. To się nazywa jeden koniec i możliwe dwa jego statusy. jeżeli uzna Pan, że ma Pan jednak cztery różne zakończenia, jak zrobi Pan raport efektów sprzedaży? Co do szczegółów polecam także ten wpis: Gdzie są szczegóły…