Modelowanie procesów biznesowych - BPM Trendsbpmtrends.pl/pdf2/Prezentacja1.pdf · Organizacja nie ucząca się •Przypadek z życia nie stosowania zasad analizy procesów biznesowych

BPMN – identyfikacja procesów, dlaczego i jak?

Piotr Biernacki – MGX Infoservice

• Wiele osób kwestionuje potrzebę identyfikacji i udokumentowania procesów biznesowych.

• Wykład ma przybliżyć podstawowe reguły modelowania za pomocą notacji BPMN, uzmysłowić jakie są konsekwencję braku identyfikacji procesów i pokazać dlaczego model BPMN lepiej nadaje się do analizy procesów niż ich opis słowny.

• Przedstawione również będą podstawowe konstrukcje BPMN, zakres ich wykorzystywania, znaczenie dobrych praktyk i metody weryfikacji umiejętności modelowania.

• Objęty normą ISO/IEC 19510:2013 BPMN jest jedynym powszechnym standardem modelowania procesów biznesowych.

2 Identyfikacja procesów - dlaczego i jak (C) MGX 2015

Nowoczesne systemy obiegu pracy nie

wymagają modelowania procesów

•Taki tekst spotykają Państwo często w ustach dostawców rozwiązań. – Nasze systemy dostarczają narzędzi do:

• Identyfikacji procesów

• Ręcznej ich realizacji

• Rejestracji najczęstszych ścieżek realizacji procesu

więc wcześniejsza analiza jest zbyteczna

– Nasze narzędzia mają wbudowane optymalne sposoby realizacji procesów

• Doświadczenie zdobywaliśmy podczas n wdrożeń i nasi klienci byli zadowoleni

więc jak je wdrożycie będziecie działać najsprawniej.

•Hola, czy aby na pewno?


Organizacja nie ucząca się

• Przypadek z życia nie stosowania zasad analizy procesów biznesowych

– Duża organizacja zaimplementowała system obiegu pracy wspomagający jej działanie i

… uzyskała pogorszenie WSZYSTKICH parametrów pracy:

• zadania wykonywano dłużej,

• osobami o wyższych kompetencjach,

• nie uzyskano pożądanych parametrów procesów.

– Przyczyną tego był brak jasno sprecyzowanych wymagań dla zamawianego systemu wynikający ze szczątkowej analizy procesów w organizacji

– Niezadawalające wyniki wdrożenia spowodowały decyzję o zmianie systemu „na lepszy”. Nie przeprowadzono analizy procesów bo przecież analiza została po poprzednim nieudanym wdrożeniu.

• Czy to kolejne wdrożenie może się udać?

Identyfikacja procesów - dlaczego i jak (C) MGX 2015 4

Kryteria sukcesu / porażki podczas wdrażania

systemów IT.

• Wdrożenie Systemu IT Sukces – tylko wszyscy niezadowoleni czy to częste zjawisko?

• Kiedy wdrożenie jest sukcesem a kiedy porażką – czy nastąpiła poprawa biznesu?

• Oczywiście termin i koszt wdrożenia są ważne ale najważniejsze są wymierne (finansowo) korzyści z wdrożenia.

– czy system zostało odebrany?

• Odebranie systemu IT jest sukcesem dostawcy ale nie zawsze – odbiorcy.

– czy dostawa jest dokładnie zgodna z zamówieniem?

• Otoczenie procesów się zmienia dlatego realizacja wdrożenia na stan z „przedwczoraj” może być zupełną porażką na „jutro”.

• Uwaga. Poprawę należy rozpatrywać w kontekście organizacji a nie pojedynczego zadania


Kryteria sukcesu / porażki podczas wdrażania

systemów IT.

• Przyczyna porażki – brak analizy lub analiza nieprawidłowa

• Analiza fragmentu organizacji, gdzie najmniej „zmęczy” ludzi

• Brak analizy skali projektu – „na prototypie działało”

– brak nadzoru nad zmianami procesów

• Uporczywe trzymanie się stron zapisów z umowy

• Nie podążanie za zmieniającymi się wymaganiami procesów

– analiza systemowa zamiast biznesowej

• Wiem jak będzie realizowane ale nie wiem co potrzebuję

• Udowadnianie, że wybrany system jest „najlepszy”

– podejście typu – w aplikacji można zrobić wszystko ale kto to „wszystko” ma zrobić

• Klient nie ma kompetencji

• Producent – rozszerzenie zakresu umowy

– zewnętrzni analitycy biznesowi

• Kiepska analiza, ale firma nie ma kryteriów odbioru więc przyjmuje ją za dobrą monetę.


Jak zwiększyć szansę na sukces

podczas wdrażania systemów IT?

• Budowanie kompetencji biznesowych w organizacji – Szkolenia, Uczelnie, Coaching

• Przekształcenie modelu procesów biznesowych w narzędzie pozyskiwania, utrzymywania i rozpowszechniania wiedzy o procesach nie tylko na potrzeby wdrożenia Workflow – Logika procesów

– Uwarunkowania procesów (skala, otoczenie)

– Kompetencje zawodowe (macierz odpowiedzialności RACIs)

– Inwentaryzacja wsparcia

– Wymagania procesów

• Automatyzacja procesów (w tym Workflow) przynosi kolosalne korzyści tylko wtedy, gdy są twarde kryteria oceny tego co chcemy uzyskać a to wymaga kadry, która wie jak się tego dowidzieć.


Budowanie kompetencji biznesowych

w organizacji

• Identyfikacja procesów

– Dobór metod – w tym:

• Referencyjnej struktury procesów (np. APQC PCF)

• Notacji (BPMN)

• Sposobu prowadzenia projektów

• Zakresu identyfikacji

• Narzędzi wspierających

– Przeszkolenie zespołu analizującego procesy

• Szczegółowe dla osób dokumentujących procesy

• Ogólnego (szkolenie z czytania modeli) – dla pozostałych uczestników projektu

– Zamodelowanie procesów

– Weryfikacja poprawności (konsultanci wew./zewnętrzni)

• Zidentyfikowane procesy i ich otoczenie są podstawą do wyboru narzędzia wspierającego.


Modelowanie w narzędziach Workflow

• Narzędzia Workflow posiadają własne narzędzia do modelowania są one jednak:

– Nakierowane na konfigurację obiegu a nie na analizę pracy

– Często poza standardami

– Często mało wydajne

– Wybór ich jako narzędzia do modelowania jest de facto wyborem narzędzia implementacji

• Dobre narzędzia Workflow potrafią komunikować się z narzędziami do modelowania poprzez standardy:

– XPDL (XML Process Description Language)

– BPMN DI

lub odczytywać natywne formaty narzędzi do modelowania (np. igxml)


Dlaczego rozpoczynać od analizy

procesów? • Dlaczego automatyzujemy procesy?

– Obniżenie kosztów procesu

– Zmniejszenie obciążenia zasobów

• Bezpośrednie

• W innych procesach (np. raportowanie)

• Przeniesienie obciążenia na „tańsze zasoby”

– Skrócenie czasu operacji

– Zmniejszenie ryzyka usterki

– Skrócenie czasu pozyskiwania informacji o aktualnych wartościach mierników

• Planowanie zmian

• Wzmożenie nadzoru

– Sprostanie wymogom klientów

• Czyli te same korzyści ale po stronie klienta

• Automatyzacja to koszt – korzyści muszą być większe

• Zautomatyzowany bałagan pozostaje bałaganem



procesów?

•Skąd wiemy, czy automatyzacja przyniesie korzyści? – „Wszyscy tak robią”

– Jeśli coś „robi się samo” to musi być taniej

– A może?

• Znamy koszt procesu

• Wiemy, jaki będzie koszt procesu /ów po zautomatyzowaniu

• Wiemy jaki będzie koszt automatyzacji

• Wiemy jakie zagrożenia występują w tym procesie

• Wiemy, jak zmieni się ryzyko w procesach

• Wiemy, jaki będzie koszt wdrożenia

• Wiemy, czy już warto automatyzować

•Automatyzacja nie zawsze przynosi korzyści – Ale tego nam dostawcy nie powiedzą.



procesów?

•Tylko rozpoznanie procesów, ich uwarunkowań i wymagań PRZED rozpoczęciem ich automatyzacji / kolejnego etapu ich automatyzacji pozwala nam odpowiedzieć na pytania: – Czy już warto automatyzować procesy?

– Jaka powinna być kolejność wdrażania automatyzacji?

•Od dostawcy oczekujemy zaspokojenia naszych potrzeb, a nie dostawy „worka” często zbytecznych funkcjonalności.

•Tylko przeprowadzona analiza pozwala nam sformułować rzeczywiste wymagania w stosunku do narzędzi oferowanych nam przez dostawców


Co powinna obejmować analiza?

•Identyfikację procesów w organizacji – Lub potwierdzenie poprzednich identyfikacji

•Wybór procesów potencjalnie do automatyzacji – Rozwojowe (strategia)

– Operujące na dużych ilościach transakcji

– Wymagające usprawnienia (analiza mierników i ryzyka)

– Wymagające współdziałania z innymi zautomatyzowanymi procesami

– Wymagające efektywniejszego nadzoru

•Analizę otoczenia procesów – Uwarunkowania

– Komunikacja z procesami innych organizacji

– Inwentaryzację systemów wspierających 13 Identyfikacja procesów - dlaczego i jak (C) MGX 2015

Co powinna obejmować analiza?

•Zamodelowanie procesów wg stanu aktualnego – Analiza przebiegu

• Potencjalne miejsca automatyzacji

• Istotne dane w procesie

• Powiązania pomiędzy procesami

• Komunikacja z innymi organizacjami

– Analiza wymagań

• Uzasadnienia biznesowe

•Proponowane modele procesów docelowych

•Analiza kosztów procesu przed i po automatyzacji – Pełna analiza wymaga symulacji


Jak analizować?

•Kto powinien modelować i wykonywać analizy? – Zespół wewnętrzny

• Często brak doświadczenia

• Inne „ważne” zadania

– Konsultanci zewnętrzni

• Nastawienie na oddanie pracy

• Brak wewnętrznych (u odbiorcy) kompetencji na wyznaczenie im zadań i prawidłowego odbioru

– Firmy wdrażające oprogramowanie

• Tłumaczenie, że dostarczany produkt „jest właśnie waszą potrzebą”

• Analiza „po łebkach” bo za to im nie płacą


Czym jest model procesu

a czym mapa procesów?

… i jakie są konsekwencje mylenia tych pojęć?

• Mapa procesu służy pokazaniu zależności pomiędzy elementami procesu / procesami

– Mapa nie opisuje jak potrzeba jest przekształcana w jej zaspokojenie,

– nie nadaje się do badania sprawności

• Model służy zobrazowaniu funkcjonowania procesu

– pełne, sparametryzowane modele procesów mogą służyć do ich symulacji / wykonania w narzędziach wspierających realizację procesów,

– nie nadaje się do analizy przestrzeni

• Mylenie pojęcia mapy i modelu powoduje:

– Błędy w zrozumieniu istoty procesów

– Niespójność modeli

– Braki w identyfikacji obszarów


Jak modelować?

•Czego oczekujemy od notacji: – Będzie zrozumiała dla odbiorcy biznesowego

– Nie będzie limitować modelującego

– Pozwoli przekazać wystarczającą ilość informacji

– Pozwoli na precyzyjną definicję logiki przepływu

– Będzie zrozumiała dla dostawców

– Będzie zrozumiała dla partnerów z którymi musimy omawiać współpracę

•Innymi słowami notacja powinna być zgodna z jakimś standardem


Jak modelować?

• BPMN

– Precyzyjny, powszechny standard dedykowany do modelowania procesów biznesowych nie związany z żadnym z producentów

• UML

– Standard „programistów”, dobry na etapie wdrożenia, gorszy – analizy. Narzędzia symulacyjne nie wykorzystują UML.

• EPC

– „Standard” jednego producenta, nieefektywny w dużych modelach

• Swimlane/Cross functional

– Powszechny, ale niedoprecyzowany

• „Własna” notacja

– Ryzyko nieporozumień z innymi organizacjami

• Zwykły diagram przepływu

– Bardzo niedoprecyzowany


Jak modelować?

• Dlaczego BPMN?

– Stabilny standard – ISO/IEC 19510:2013

• Posiada niezależną polską certyfikację (IBS PAN)

– Silne wsparcie – ponad 75 producentów oprogramowania oficjalnie wspierających ten standard w tym:

• Mocno reprezentowany w : – Administracji Publicznej – Na uczelniach

– Wspierający inne powszechne standardy:

• WS-BPEL • XPDL

– Kompletny:

• Modelowanie przebiegu procesu w organizacji (orkiestracja)

• Modelowanie współpracy pomiędzy organizacjami (choreografia)

• Analiza komunikacji (konwersacja)

• Standard przeznaczony JEDYNIE do modelowania procesów biznesowych


Czym jest BPMN?

• Business Process Model and Notation – BPMN, (Notacja i Model Procesu Biznesowego) jest:

– stabilną graficzną notacją

• opracowana w 2004 roku przez BPMI.(Obecnie BPI DTF komitet w OMG)

• aktualna wersja 2.0.2 – 01.2014

– służącą do opisu kroków, zdarzeń i logiki realizacji procesu biznesowego.

– zaprojektowaną tak, aby umożliwić odzwierciedlenie:

• przepływu procesu

• komunikacji pomiędzy różnymi procesami u różnych uczestników

• istotnych danych w procesie.

– Opisaną normą ISO/IEC 19510:2013 Międzynarodowej Organizacji Normalizacyjnej.

– Jednoznaczność modeli BPMN umożliwia ich symulacje, jeśli narzędzie do modelowania potrafi ją wykonać.

Identyfikacja procesów - dlaczego i jak (C) MGX 2015 20

Diagram procesu biznesowego

– podstawowe obiekty

• Elementy procesu – Okręgi – zdarzenia

– Zaokrąglone prostokąty – czynności

– Romby – bramki

• Elementy łączenia obiektów – Linia ciągła – przepływ procesu

– Linia przerywana – przepływ komunikatów

– Linia kropkowana – powiązania

– Linia podwójna – opcjonalnie konwersacje

• Miejsca realizacji procesu – Prostokąty izolowane – Baseny / Uczestnicy

– Prostokąty wewnętrzne – Tory / Role biznesowe

• Dane – Prostokąty z zgiętym rogiem – dane

– Cylindry – składnice danych

• Artefakty – Adnotacje

– Grupy

– Powiązania

– (Komunikaty)

Ba

se

n

To

r To

r

Adnotacja

Grupa

Komuikat

Zdarzenie

Czynność

Bramka


Jakie są największe zagrożenia

w modelowaniu z BPMN?

• Niezrozumienie co jest procesem w kontekście BPMN

– Koncepcja żetonu

• Błędy w wybranych konstrukcjach uniemożliwiające:

– Prawidłową interpretację modelu

– Jego późniejszą automatyzację (jeśli konieczna)

• Źle dobrany sposób przedstawienia diagramu w stosunku do percepcji odbiorcy

• Niezrozumienie prawidłowych konstrukcji BPMN

– Najczęściej przy zaawansowanym modelowaniu

• Wiele tych zagrożeń związanych jest z niekompetencją:

– Modelujących

– Odbiorców


Jakie są największe zagrożenia

w modelowaniu z BPMN?

•Brak ciągłości zmian – Akcyjność modelowania i pogłębionej weryfikacji

•„Przekomplikowanie” – Prezentacja rozwiązań musi dawać proste, jednoznaczne

odpowiedzi

•Niedomknięcie koła DMAIC – Definiuj

– Mierz

– Analizuj

– Implementuj

– Controluj


Certyfikacja jako metoda na weryfikację

kompetencji

• OMG Certified Expert in BPM 2™

– Certyfikacja BPMN tylko z nazwy. Dwa poziomy:

• Fundamental

• Business Intermediate

– Tak naprawdę w Fundamental BPMN to tylko ok.40% pytań:

– W Intermediate jeszcze mniej – 35%

– Można zdać egzamin z BPMN 2.0 nie znając BPMN

• Polski certyfikaty BPMN – IBS PAN

– Dwa poziomy:

• Certyfikat podstawowych kompetencji BPMN

• Zaawansowany certyfikat BPMN

• Polski Certyfikat BPMN – ILiM

– Dwa poziomy: BPMN Junior i BPMN Senior

– Część Europejskiego Systemu Certyfikacji Logistyków

• W obu polskich 100% pytań dotyczy BPMN:


Zamiast podsumowania

• Korzyści z zastosowania BPMN w identyfikacji procesów PRZED wdrożeniem systemów IT

– Powszechny standard

• Możliwość stosowania jeden notacji dla różnorodnych projektów

• Łatwość komunikacji modeli z innymi uczestnikami (partnerzy, dostawcy, analitycy)

– Kompletność standardu

• Nie ma ryzyka, że nie da się precyzyjnie odwzorować sytuacji biznesowej

– Dostępność narzędzi - różnorodne narzędzia wspierające

• Darmowe – dobre na rozpoczęcie „zabawy” z modelowaniem

• Komercyjne – wyższa efektywność i w rezultacie tańsze stosowanie (niższy koszt przygotowania modelu)

– Uniwersalność

• Nadaj się zarówno do prostych prezentacji jak i złożonych analiz.


Zamiast podsumowania

• Korzyści ze szkoleń BPMN w celu przygotowania się do wdrożenia Workflow

– Skrócenie czasu (i kosztu) opanowania notacji

– Pozyskanie dobrych praktyk modelowania

– Poznanie notacji i przykładów użycia

– Poznanie technik służących:

• optymalizacji procesów

– Jakościowa – Ilościowa

• przygotowaniu dokumentacji na potrzeby wdrożeń systemów IT wspierających pracę przedsiębiorstw

• Korzyści z certyfikacji BPMN

– Wiarygodna weryfikacja kompetencji w zakresie modelowania

– Redukcja ryzyka związanego z analizą biznesową


I najważniejsze

Żeby wiedzieć

jak

najpierw trzeba wiedzieć

co


Pytania i odpowiedzi

Piotr Biernacki

MGX Infoservice

Wilanowska 14a / 1ab

00-422 Warszawa

GSM +48 601 24 26 35

tel. +48 22 71 111 71

[email protected]

www.mgx.com.pl, www.igrafx.com, www.bpmn.org


Documents

Modelowanie procesów biznesowych - BPM Trendsbpmtrends.pl/pdf2/Prezentacja1.pdf · Organizacja nie ucząca się •Przypadek z życia nie stosowania zasad analizy procesów biznesowych