BPMN identyfikacja procesów, dlaczego i jak? Piotr Biernacki MGX Infoservice

Transkrypt

1 BPMN identyfikacja procesów, dlaczego i jak? Piotr Biernacki MGX Infoservice

2 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

3 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? 3

4 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ć? 4

5 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 5

6 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ę. 6

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

8 Budowanie kompetencji biznesowych Identyfikacja procesów Dobór metod w tym: w organizacji 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. 8

9 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) 9

10 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 10

11 Dlaczego rozpoczynać od analizy 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ą. 11

12 Dlaczego rozpoczynać od analizy 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 12

13 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

14 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 14

15 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ą 15

16 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 16

17 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 17

18 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 18

19 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 Kompletny: XPDL Modelowanie przebiegu procesu w organizacji (orkiestracja) Modelowanie współpracy pomiędzy organizacjami (choreografia) Analiza komunikacji (konwersacja) Standard przeznaczony JEDYNIE do modelowania procesów biznesowych 19

20 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 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ć. 20

21 Basen Tor Tor 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) Zdarzenie Adnotacja Czynność Grupa Bramka Komuikat 21

22 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 22

23 Jakie są największe zagrożenia Brak ciągłości zmian w modelowaniu z BPMN? 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 23

24 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: 24

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

26 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ą 26

27 I najważniejsze Żeby wiedzieć jak najpierw trzeba wiedzieć co 27

28 Pytania i odpowiedzi Piotr Biernacki MGX Infoservice Wilanowska 14a / 1ab Warszawa GSM tel piotr.biernacki@mgx.com.pl