Ryzyka wdrożeń systemów obiegu dokumentów i przepływu pracy Jarosław Żeliński – niezależny analityk systemowy i biznesowy Ryzyka wdrożeń systemów obiegu dokumentów i przepływu pracy (c) Jarosław Żeliński http://IT-Consulting.pl/

O mnie… Projekty analityczne między innymi dla… Od 1991 roku w branży IT i zarządzania Od 1998 roku jako niezależny analityk, projektant i firma IT-Consulting.pl Dziesiątki publikacji w prasie branżowej i gospodarczej Członek Stowarzyszenia Doradców Gospodarczych Wykładowca Katedry Systemów Informacyjnych Wydziału Przedsiębiorczości Akademii Morskiej w Gdyni Kilkudziesięciu odbiorców usług doradczych, małe, średnie i duże firmy zarówno informatyczne jak i ich klienci oraz administracja publiczna. Poświadczenie bezpieczeństwa wydane przez ABW Publikacje między innymi w … (c) Jarosław Żeliński http://IT-Consulting.pl/

Agenda Typowe cele wdrożeń Panowanie nad procesem Nadzór procesu Typowe ryzyka zakupu systemu obiegu dokumentów: Brak możliwości definiowania nowych dokumentów i procesów Brak możliwości zarządzania posiadanym zasobem wiedzy Przyczyna tych ryzyk: Wybór rozwiazania (produktu) przed analizą wymagań – nie istnieją „systemy od wszystkiego”. (c) Jarosław Żeliński http://IT-Consulting.pl/

System workflow - documentflow Przenosi (implementuje) do systemu informatycznego rzeczywisty model działania firmy Stanowi sposób na automatyzację rutynowych czynności Chroni firmę przez skutkami „nadmiaru pracy” – nadzoruje „każdą sprawę” Pozwala wykonać raport „stanu wszystkich spraw w firmie” Pozwala w łatwy sposób wpleść klienta w proces (samoobsługa na stronie WWW, podgląd stanu zamówienia, inne) Zarządza dokumentami – pozwala stworzyć archiwum dokumentów Jest obecnie najlepszym sposobem na wdrożenie zarządzania wiedzą w firmie (c) Jarosław Żeliński http://IT-Consulting.pl/

Wdrożenie Wdrożenie obiegu dokumentów wymaga: Analizy procesów i przepływu dokumentów Opracowania map procesów Określenia wymagań dla oprogramowania obsługującego obieg dokumentów (przepływu pracy) Pominięcie etapu modelowania i analizy powoduje: Ryzyko wielu poprawek na etapie wdrożenia Ryzyko pomięcia istotnych zdarzeń Ryzyko przełożenia do systemu obiegu dokumentów nieoptymalnych scenariuszy Ryzyko pominięcia istotnych danych Zmiany i modyfikacje na modelu (na diagramach) są o rząd (a bywa, że dwa rzędy!) wielkości tańsze niż zmiany wprowadzane do wdrażanego już oprogramowania (c) Jarosław Żeliński http://IT-Consulting.pl/

Proces nie raz nie jest prosty… Wiele dokumentów Wiele ról w procesie Wiele sposobów podejmowania decyzji JEDEN PROCES! (c) Jarosław Żeliński http://IT-Consulting.pl/

Model (wzorzec) – Maszyna stanowa Wzorzec projektowy najczęściej stosowany do budowy systemów obiegu dokumentów Model zakłada, że wiedza o statusach jest związana z Obiektem (dokumentem) Sprawdza się dla nieskomplikowanej i przewidywalnej obsługi dokumentów np. zatwiedzonych dowodów księgowych Sprawia problem w sytuacjach gdy proces tworzy pośrednie dokumenty, wymagana jest obsługa „spraw”. (c) Jarosław Żeliński http://IT-Consulting.pl/

Systemy obiegu dokumentów Dokument (obiekt) biznesowy może przyjmować stany w zasadzie nieprzewidywalne na etapie analizy. Stany te  mogą być (i nie raz są!) skutkiem wprowadzania lub zmian reguł biznesowych a nie cech dokumentu. Tak więc znane na początku wdrożenia statusy faktury: przyjęta, zaksięgowana, zapłacona, mogą się zmienić po wprowadzeniu np. wewnętrznego zarządzenia o treści: dokumenty rodzące koszty przekraczające 10 tys. złotych muszą być dodatkowo zatwierdzane przed Zarząd. Jaki mamy efekt? Wiele dokumentów, nie tylko faktury ale i umowy czy reklamacje nagle muszą obsłużyć nowy status: do zatwierdzenia przez Zarząd. Mamy tu lawinową modyfikację systemu. Zmiana zasad wymaga ingerencji we wszystkie obiekty stanowe mogące „podpaść” pod nową regułę. Jak je wszystkie szybko i jednoznacznie zidentyfikować w systemie? Co mamy? System obiegu dokumentów wymagający ingerencji dostawcy przy każdej zmianie zasad … (c) Jarosław Żeliński http://IT-Consulting.pl/

Meta-Model WfMC Workflow Management Consortium zapropnowało meta model (jako wzorzec) rozdzielający statusy od kontekstu, bazujący na aktywnościach z logiką kolejnych kroków przechowywana osobno. repozytorium (c) Jarosław Żeliński http://IT-Consulting.pl/

Zalecane BPMN/XPDL Konsorcjum WfMC opracowało wspomniany metamodel. Format XPDL opisu procesu jest zgodny z metamodelem WfMC Notacja BPMN jest zgodna z XPDL. Stosowanie notacji BPMN na etapie analizy oraz wymaganie implementacji procesów zgodnie z powstałymi modelami od dostawcy systemu, daje duże szanse powodzenia projektu. (c) Jarosław Żeliński http://IT-Consulting.pl/

Metadane (źr. http://www.archiwa.gov.pl/) Warto korzystać ze standardów i wymagać ich (c) Jarosław Żeliński http://IT-Consulting.pl/

Metamodel procesu Wydzielenie reguł biznesowych i kompetencji z modeli procesów… (c) Jarosław Żeliński http://IT-Consulting.pl/

Analiza wymagań - audyt (c) Jarosław Żeliński http://IT-Consulting.pl/

Kucharz taniego fastfooda Kucharz renomowanej restauracji Jaki kierunek obrać Kucharz taniego fastfooda Kompetencje wykonawcy w procesie a szczegółowość opisu procesu Szczegółowość scenariusza (procedury, procesu) Kucharz renomowanej restauracji Kompetencje wykonawcy (c) Jarosław Żeliński http://IT-Consulting.pl/

(c) Jarosław Żeliński http://IT-Consulting.pl/

Kluczowe ryzyka wyboru systemu przed analizą Skoro spotykamy (co najmniej) dwa wzorce modelowania obiektu stanowego w systemach, to wybór systemu ze wzorcem nie pasującym do specyfiki firmy skończy poważnymi kłopotami podczas wdrożenia (c) Jarosław Żeliński http://IT-Consulting.pl/

Który model i kiedy… Możemy spotkać się z sytuacją gdy: zachowanie obiektu jest jego własną cechą, reaguje na swoje otoczenie – wzorzec SM zachowanie obiektu jest mu narzucone z zewnątrz – obiekt jest „zwykłym” obiektem o stanie zależnym od wykonanych na nim operacji Przypadek 1. to standardowe proste i przewidywalne wnioski urlopowe, faktury kosztowe itp., typowe statusy dowodów księgowych. Przypadek 2. to pozostałe sytuacje gdy proces jest sterowany przez wykonawcę lub modelowany „na życzenie”. Przykładem systemów uniwersalnych są te zbudowane z dwóch podsystemów: repozytorium i motor procesowy. Repozytorium zarządza cyklem życia dokuemntów, przechowuje ich metadane (metryka dokumentu), ale to jakie one (dokumenty) będą przyjmowany statusy „wie” motor procesu a nie dokument (ten zna jedynie swój aktualny status). Co ciekawe samo repozytorium (mające wbudowany system monitowania) pozwala obsłużyć wiele przypadków zarządzania przepływem dokumentów, szczególnie tych ad-hoc. Są to systemy pracujące na bazie wzorca publisher-subscriber (c) Jarosław Żeliński http://IT-Consulting.pl/

Przykład wdrożenia na bazie wzorca publisher-subscriber: jeden system (model) obsługuje całą biurowość urzędu zatrudniającego ponad 1000 urzędników… (c) Jarosław Żeliński http://IT-Consulting.pl/

Systemy ERP i integracja z workflow Systemy ERP najczęściej pozwalają tylko na obsługę dowodów księgowych i ich standardowych statusów (np. dla faktury kosztowej: wprowadzona, zaakceptowana, zaksięgowana, zapłacona). Przebiegi specyficzne dla firmy takie procedury zarządzania kosztami, ścieżki weryfikacji, kontrola zamówień itp. łatwiej wdrożyć z pomocą dużo bardziej uniwersalnych systemów workflow/docflow Stosowanie specjalizowanych systemów (tu system zarządzania przepływem pracy) wydaje się łatwiejsze i mniej kosztowne… (c) Jarosław Żeliński http://IT-Consulting.pl/

Dwa największe źródła ryzyk Specyfikacja w postaci listy wymagań funkcjonalnych i niefunkcjonalnych niestety nie chroni przed ryzykiem kosztownych zmian w przyszłości. Jedynym wyjściem jest wyspecyfikowanie w dokumencie wymagań  szczegółów wymaganej logiki biznesowej w postaci projektu (modelu struktury wzorca)  jakiego oczekujemy od systemu. Stosowanie niesformalizowanych notacji na etapie analizy i projektowania prowadzi do niejednoznacznych modeli, wtedy nie wiemy co tak na prawdę otrzymamy, nie mamy żadnego sposobu (dokumentacja wymagań) wykazania czy dostarczony produkt jest TYM CO POTRZEBUJEMY (co zamówiliśmy). (c) Jarosław Żeliński http://IT-Consulting.pl/

Co, kiedy i czym (jak) modelujemy Systemy pojęciowe i notacje Np. BMM Cele biznesowe Np. ArchiMate lub BPMN Model logiczny procesów Abstrakcja systemu Np. BPMN lub dedykowane Model wykonawczy procesów – realizacja Zarządzanie przepływem pracy Diagram: Źr. http://www.bptrendsassociates.com/ (c) Jarosław Żeliński http://IT-Consulting.pl/

X Wybór systemu na rynku (c) Jarosław Żeliński http://IT-Consulting.pl/

Pytania…. Jarek Żeliński, dziękuję… Ale czasami, po analizie reguł biznesowych, łatwiej nieco zmienić sposób pracy i użyć pasującego gotowego systemu bez kastomizacji…. (c) Jarosław Żeliński http://IT-Consulting.pl/