docCzym jest obieg dokumentów i BPM? - IT
download 
Reklamacja Transkrypt
Czym jest obieg dokumentów i BPM? - IT
Czym jest obieg dokumentów i BPM? Dlaczego pozornie prosty system obiegu dokumentów jest taki trudny do wdrożenia? Niedawno (14-15 Lipca 20100) odbyła się konferencja EOIF GigaCon 2010 poświęcona systemom obiegu dokumentów. Nie jest moim celem streszczanie tej konferencji, jednak po niej nasunęło mi się kilka przemyśleo. Pierwsze to, czym tak na prawdę są te systemy, po drugie, dlaczego ich wdrożenia są tak mało przewidywalne. Po kilku rozmowach z ich użytkownikami w kuluarach można odnieśd przekonanie, że analizy wymagao są tu niepotrzebne bo w większości przypadków to co zostaje, w efekcie wielu prób, wdrożone i odebrane jako koocowy produkt, niewiele ma wspólnego z wynikami pierwotnej analizy wymagao. Jednym z wielu przykładów jakie poznałem to pewien urząd, w którym analiza przedwdrożeniowa opisywała prawie 300 procesów, po wdrożeniu okazało się, że jest ich 15 (!). W efekcie projekty tego typu cechują się znacznie większym kosztem niż planowany lub nawet wstrzymaniem projektu z powodu wyczerpania funduszy. Dlaczego tak się dzieje? Otóż modelowanie przepływu pracy, dokumentów i procesów jest na etapie analizy bardzo często błędnie utożsamiane z „zapisywaniem tego co robią ludzie” co jest poważnym błędem. Elementem tworzącym momentami nawet chaos jest moim zdaniem także pewien bałagan pojęciowy, prelegenci (konsultanci) często bez podawania definicji używali takich pojęd jak: zarządzanie procesami, modelowanie procesów, mapowanie procesów, zarządzanie przepływem pracy, zarządzanie przepływem dokumentów, reinżynieria procesów, byd może pojawiały się jeszcze inne, które mi umknęły ale i to już daje obraz tego bałaganu. PODSTAWOWE DEFINICJE Bez nich trudno było niektórym prowadzid wykład a co dopiero coś wykazad. W metodykach modelowania, które stosuję funkcjonują więc proste i rozłączne definicje oraz ich ograniczenia zamiast wielu pojęd, których definicje są niejednoznaczne i wymagają uwagi przy ich stosowaniu. • • Produkt: byt (przedmiot, treśd lub zdarzenie) przedstawiający wartośd lub wymagany stan jako wejście dla procesu (także w oderwaniu od procesu go tworzącego np. książka ma wartośd dla czytelnika mimo braku kontaktu z jej autorem i drukarnią, zburzony dom ma wartośd jako oczyszczone pole nowej budowy i nie ma znaczenia kto i jak go wysadził w powietrze). Na diagramach są to produkt wejściowy i produkt wyjściowy. Proces: abstrakcja obrazująca (modelująca) działanie lub zespół działao, którego celem jest wytworzenie jasno określonego produktu; do wytworzenia produktu proces wymaga zasobów (człowiek, maszyny, …) a jeżeli jest procesem przetwórczym a nie twórczym, © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 1 • • • • • • wymaga dodatkowo innych produktów (surowców); proces ma więc wejście i wyjście oraz wymaga zasobów, tworzenie produktu może byd w jakiś sposób ograniczone. Proces odpowiada na pytanie co ma powstad (się stad). Podproces: proces współtworzący produkt swojego procesu nadrzędnego, jeżeli jeden produkt może składad się z elementów składowych będących także prostszymi produktami proces taki także może składad się prostszych procesów składowych tworzących produkty składowe, innymi słowy proces może zawierad podprocesy (procesy składowe, podrzędne). Proces elementarny: jeżeli dany produkt jest niepodzielnym bytem lub składa się z bytów, których samodzielne istnienie jest niemożliwe lub nielogiczne w danej sytuacji to proces, który tworzy taki produkt nazywamy procesem elementarnym. Ograniczenie: wszystko to co powoduje, że wewnętrzna swoboda procesu w tworzeniu (powstawaniu) jego produktu jest ograniczona. Ta definicja zrodziła się w trakcie mich badao jako efekt próby przejście ze specyfikowania wyłącznie tego co wolno na opis w postaci „wolno jakkolwiek chyba, że…” co w mojej autora jest precyzyjniejszą definicją. Procedura: jest to ograniczenie w postaci opisu (spisu) prac (czynności lub podprocesów) jakie muszą zostad wykonane wraz z kolejnością ich wykonywania by produkt powstał, procedura stanowi ograniczenie mówiące, że inaczej tego produktu nie można wytworzyd; jeżeli takiego ograniczenia nie ma procedur nie tworzy się. Procedura może określad, że czynności są wykonywane przez człowieka lub mogą zostad zautomatyzowane i wykonane przez maszynę (np. program komputera), w tym przypadku procedura musi stanowid sobą pełny algorytm. Stworzenie algorytmu nie zawsze jest możliwe. Procedura odpowiada na pytanie jak należy to zrobid i stanowi ograniczenie „swobody” tworzenia produktu procesu. Zdarzenie: produkt, byt nie mający czasu trwania, stanowiący stwierdzenie zaistnienia faktu, implementowany jest jako zapis (dane) o fakcie, o którym wiedzę chcemy posiadad (zachowad). Rola (w procesie): wykonawca odpowiedzialny za powstanie i jakośd produktu procesu lub czynności (w metodykach obiektowych zwany aktorem, pojęcia te będą to stosowane zamiennie). Powyższe definicje pojęd proces, produkt, rola można przedstawid za pomocą notacji BPMN (Business Process Modeling Notation, http://www.bpmn.org) stanowiącej obecnie standard de‘facto w projektach związanych z modelowaniem procesów. © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 2 Kilka słów komentarza na temat tego diagramu. Każdy proces ma jednoznacznie określony początek i koniec, są to jednoznacznie określone zdarzenia. Co do zasady produkt procesu jest (jest to także kryterium oceny czy to jest proces) samodzielnym produktem. Dane wejściowe i wyjściowe (wejście i wyjście procesu) to dająca się utrwalid treśd (to założenie to element pragmatyki modelowania biznesowego). Specyfika modelowania w kontekście systemów informacyjnych nakazuje traktowad rzeczy istotne jako treści do zapisania. Innymi słowy oprogramowania „będzie wiedziało” tylko to co jest możliwe do zapisania i przetwarzania. Jako uzupełnienie wskazano tu możliwośd rejestrowania pewnych danych bez wskazania miejsca ich użycia gdyż mogą byd wykorzystane w innym procesie (o tym w dalszej części tekstu na przykładach). Wykonawcą procesu lub osobą odpowiedzialną za niego jest Rola. Jest to człowiek. W swojej pracy i po kilku latach badao odszedłem od ogólnej koncepcji Roli jako wykonawcy (człowiek lub maszyna) na korzyśd Roli jako człowieka nakładając na modele organizacji pragmatykę biznesową modelowania organizacji gdzie za wszystko odpowiadają ludzie. Podstawowym powodem tego założenia była potrzeba modelowania przepływu pracy i wartości dodanej oraz uznanie, że człowiek jest użytkownikiem każdego urządzenia – w szczególności komputera – co ogromnie ułatwia proces analizy i zrozumienia zachowao organizacji. Podmiot to modelowana firma lub organizacja, w ramach Podmiotu funkcjonują Role (ludzie pracujący dla organizacji, zatrudnieni w niej). Gdzie tu procedury? Jak wspomniano proces to abstrakcja, realnymi bytami są dokumenty (ich treśd) i ludzie. Procedura to utrwalone w postaci dokumentu ograniczenie np. lista kontrolna, obligatoryjna ścieżka zatwierdzania, polityka bezpieczeostwa, inne. Powyższy diagram niesie kilka dodatkowych informacji, są to strzałki pokazujące relacje pomiędzy procesem a danymi. Strzałka (tu asocjacja skierowana) skierowana w stronę danych oznacza, że dane te w procesie powstają, strzałka skierowana od danych do procesu oznacza, że dane te są WYMAGANE w procesie. Tak więc, jeżeli © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 3 tworzymy ograniczenie mówiące jak należy proces realizowad, opis ten umieszczamy na modelu jako obligatoryjny dokument wejściowy (należy znad jego treśd). Podejście takie jak tu opisane, cechujące się ścisłym definiowaniem pojęd i ich wykorzystywaniem wyłącznie w zgodzie z tymi definicjami nazywa się podejściem formalnym. KORZYŚCI Z FORMALNEGO PODEJŚCIA DO MODELOWANIA Podstawową korzyścią jest jednoznaczny model organizacji niosący istotne informacje i oczyszczony z tak zwanych „śmieciowych danych” czyli tego co nam powiedziano o organizacji a nie jest istotne w kontekście projektu. Ta cecha formalnych metod modelowania procesów pozwala po pierwsze panowad nad złożonością modeli po drugie prowadzi do ich uogólnienia. Uogólnianie na tym etapie przynosi dużo korzyści gdyż po pierwsze modele staja się prostsze, opisują stan faktyczny i skupiają uwagę tylko na tym co istotne czyli na celu pracy a nie na tym jak jest w danym momencie wykonywana, bo nie raz może ona byd wykonana na wiele równoprawnych sposobów, których dokumentowanie jest właśnie „zaśmiecaniem” modeli. Zawsze istotny jest tylko produkt procesu i ewentualne ograniczenia w jego powstaniu. Praktyka pokazuje, że wiele map procesów zawierających dziesiątki diagramów tak na prawdę pokazuje warianty tego samego procesu. Bardzo często także to co jest modelowane jako jeden skomplikowany proces to tak na prawdę kilka procesów współdzielących dane (jest to bardzo często spotykany przypadek w audytach jakie prowadzę). PRZYKŁAD – FIRMA HANDLOWA Na zakooczenie przykład, który pokaże opisane zjawiska i korzyści z formalizacji. Poniższy diagram hipotetycznej firmy handlowej wykonano w zgodzie z powyższymi założeniami formalizacji. © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 4 Praktycznie każda firma coś oferuje więc: opracowuje oferty, obsługuje zamówienia oraz obsługuje swoich klientów. Bardzo często widuje powyższe czynności modelowane w postaci jednego procesu co postrzegam jako duży błąd (poza przypadkami gdy faktycznie ma to swoje uzasadnienie ale tych jest bardzo mało). Na szkoleniach, które prowadzę1, najczęściej zadawanym pytaniem jest pytanie „Jak identyfikowad procesy”. Otóż jednym ze skuteczniejszych kryteriów jest wyszukiwanie par zdarzeo kooca i początku procesu (metoda end-to-end), łączących łaocuch wydarzeo, które muszą się wydarzyd (dopuszczając oczywiście nieoczekiwane i niepożądane zakooczenie procesu przed czasem). Takie kryterium spełnia także wymogi pragmatyki biznesowej to znaczy poprawny proces daje gwarancję powstania produktu (znowu pamiętając o wydarzeniach mogących to zakłócid). W efekcie długi proces od zapytania po obsługę reklamacji nie jest procesem w rozumieniu tej definicji bo: 1. naiwnością było oczekiwanie każdorazowego zawarcia umowy sprzedaży dla każdej wysłanej oferty 1 http://zelinski.biz.pl/kursy oraz szkolenia stacjonarne © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 5 2. co najmniej nierozsądne jest założenie, że każdy sprzedany produkt będzie reklamowany. Jak widad firma tego typu ma trzy odrębne kluczowe procesy: Ofertowanie, Sprzedaż, Obsługa reklamacji. Każdy z nich jest inicjowany konkretnym zdarzeniem i każdy z nich, po zainicjowaniu doprowadzi do powstania produktu koocowego. Teraz chyba widad, że założenie sprzedaży i naprawiania wszystkiego co zaoferowano jest co najmniej nierozsądne. Na diagramie tym celowo pominąłem role by nie zaciemniad go, pragnę tu jednak zwrócid uwagę na kilka jego cech: 1. Oferta (produkt procesy Ofertowania) jest potrzebna do weryfikacji zamówieo w procesie Obsługi zamówieo (sprawdzamy czy treśd zamówienia jest zgodna z ofertą) ale nie wymusza zaistnienia zamówienia 2. Specyfikacja tego co sprzedano w procesie sprzedaży jest wymagana do oceny zasadności reklamacji w procesie obsługi reklamacji ale sam fakt sprzedaży nie implikuje reklamacji. 3. W ramach jednego procesu mamy do czynienia z więcej niż jednym dokumentem. Konkluzja: przepływ danych nie jest tożsamy z przepływem pracy! DLACZEGO NIEKTÓRE ROZWIĄZANIA SPRAWIAJĄ KŁOPOTY WDROŻENIOWE Jak częśd z Paostwa zapewne wie, bo doświadczyła tego, wdrożenie systemu workflow (używam tego pojęcia celowo zamiast obieg dokumentów czy zarządzanie procesami dla odróżnienia i wskazania go jako pewnej abstrakcji), przejście od map procesów z fazy analizy wymagao do implementacji w fazie wdrożenia potrafi sprawid wiele kłopotów. To co można bez problemu narysowad nie zawsze da się potem wdrożyd (zaimplementowad w kupionym oprogramowaniu). Dlaczego? Po pierwsze niesformalizowane modele w zasadzie nie nadają się implementacji w jakimkolwiek oprogramowaniu i są głównym ryzykiem w projekcie, a po drugie na rynku można spotkad dwa rodzaje oprogramowania: do zarządzania przepływem dokumentów i do zarządzania przepływem pracy. Jest to ogromna różnica gdyż większośd modeli procesów opisuje przepływ pracy zaś wiele produktów nazywanych „zarządzanie obiegiem dokumentów” faktycznie służy do zarządzania przepływem dokumentów. W efekcie ma miejsce próba dokonani niemożliwego. Na czym polega różnica? Źródło kłopotów tkwi w modelu danych (modelu dziedziny) dla obu tych rozwiązao. PRZEPŁYW DOKUMENTU Uproszczony model dla systemu zarządzania przepływem dokumentu: © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 6 Kluczowym obiektem jest Dokument, kolejne aktywności (etapy pracy) wykonują poszczególne Role. Sterowanie polega tu na nadawaniu dokumentowi, będącemu centralnym elementem, statusów (zarejestrowany, zatwierdzony, itp.), każda kolejna aktywnośd jest wymuszana aktywnym statusem Dokumentu. To co się dzieje z dokumentem, postrzegane jako jego przepływ, to tak na prawdę tabela stanów dokumentu czyli określenie w jakim stanie znajdzie się dokument i co powoduje zmianę tego stanu: Tak wiec dokument jest jeden (!) i on stanowi „bazę”, kojarzenie go z innymi wymaga pewnych nietypowych dla tego modelu danych zabiegów (między innymi żonglowanie atrybutami dokumentu) tu nie zobrazowanych z powodu ich dużej komplikacji, ale ta komplikacja to właśnie kłopoty (koszty) obsłużenia przepływu pracy narzędziem do obsługi przepływu dokumentów. Typowym problemem w © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 7 tego typu rozwiązaniach jest nie możnośd prostego obsłużenia wątków równoległych właśnie z powodu istnienia jednego niepodzielnego dokumentu (nośnika stanu procesu) jako bazy każdego procesu. Model referencyjny rozwiązujący ten problem udostępniło Workflow Management Coalition (WfMC)2. Stanowi on podstawę modelowanie dziedziny dla zarządzanie przepływem pracy. Model ten zakłada istnienie pewnych abstrakcyjnych bytów: Proces i Aktywnośd (tu przypominam początek tego tekstu, moją definicję procesu będącego łaocuchem czynności – są to abstrakcie, na diagramie zaznaczone kursywą). Model dziedziny WfMC wygląda tak: 2 http://www.wfmc.org/ © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 8 Jak widad proces składa się z jednej lub szeregu aktywności powiązanych z ich wykonawcami (Rola) zaś każda Aktywnośd może byd skojarzona z: wieloma różnymi danymi (np. dokumentem), wykonaniem pewnych akcji lub odwołaniem do innych aplikacji (tu może mied miejsce implementacja architektury SOA – wołanie usług), kolejne aktywności mogą byd warunkowane (sterowanie przepływem). Jak widad nie ma przeszkód by w takim modelu zaimplementowad rozwidlenia, tworzenie nowych dokumentów, zapisywad meta dane. Dla zainteresowanych: notacja BPMN implementuje właśnie taki model dziedziny dlatego można powiedzied, że jeżeli podczas analizy biznesowej modele wykonano w tej notacji z użyciem pełnej semantyki tej notacji, to program który miał by posłużyd do wdrożenia tych procesów MUSI na liście swoich wymagao mied pełną zgodnośd z powyższym modelem referencyjnym. Nie wolno łamad formalizmów notacji BPMN (semantyka i syntaktyka notacji), w przeciwnym wypadku wdrożenie procesów w formie opisanej diagramami się nie uda!3 Dlatego każda analiza biznesowa ukierunkowana na system obiegu dokumentów (czyli tak na prawdę przepływu pracy) musi zawierad etap formalizacji modeli procesów jeżeli projekt ma byd wykonywalny. ZARZĄDZANIE PROCESAMI BIZNESOWYMI Popularny skrót BPM (ang. Busienss Process management – Zarządzanie Procesami Biznesowymi) budzi coraz większe moje rozczarowanie wieloma firmami. To nowe słowo klucz (ang. buzzword) stało się ostatnio przyprawą do wielu ofert mającą je dodatkowo uatrakcyjnid. Czym jest BPM? Po krótkim wykładzie na temat procesów biznesowych mam nadzieje, że zauważyli Paostwo, że: 1. Przebieg procesu to zastany (odkryty) stan faktyczny 2. Przebieg procesu to skutek ograniczeo jakimi są zamawiane produkty (procesów), kompetencje pracowników, wymagao właścicieli, ryzyk biznesowych i wielu innych, nie raz trudnych nawet do wyspecyfikowania, elementów Tak więc czym to zarządzad? Procesem? Czy samo narysowanie diagramu przepływu pracy cokolwiek zmieni w organizacji? NIE, wie to każdy kto brał udział w projekcie „reinżynierii procesów” (BPR, ang. Business Process Reengineering, praktyka wręcz skompromitowana w latach 90-tych) wdrażał normy jakości ISO metodą najpierw dokumentacja ISO potem jej wdrożenie (to moim zdaniem powód kompromitacji idei wdrażania norm ISO w wielu organizacjach). 3 http://www.wfmc.org/wfmc-standards-framework.html lista produktów implementujących model danych WfMC © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 9 Całe środowisko organizacji to ludzi i komunikacja między nimi. Komunikujemy się bezpośrednio lub pośrednio za pomocą dokumentów (maile, komunikatory, dokumenty, inne). System4 taki można przedstawid ogólnie w następujący sposób: Procesy na tym diagramie „nie istnieją” jako bloczki schematu gdyż pokazano (celowo) wyłącznie realne byty i związki między nimi. Jeżeli jakiś ciąg zdarzeo, czynności doprowadza do powstania jakiejś treści lub zaistnienia zdarzenia i powtarza się (lub chcemy by się powtarzał) „ubieramy” go „nazwę” a na diagramach zaznaczamy symbolem oznaczającym proces. Na tym właśnie polega modelowanie procesów, które tym się różni od mapowania (rysowania), że nie jest tylko rysowaniem a analizą i dokumentowaniem jej wyników: zobrazowaniem tego co i po co się dzieje w organizacji. Co to więc jest to BPM? Moim zdaniem modele procesów (mapy procesów) to skutek, Wyjście procesu wdrażania zmian a nie jego Wejście!. Zarządzanie procesami polega na zarządzaniu ograniczeniami (np. poprzez tworzenie procedur, polityk bezpieczeostwa, itp.), które w efekcie skutkują takim a nie innym przepływem pracy. Miałem kontakt z wieloma firmami, które dały się namówid na projekt „Zarządzanie Procesami Biznesowymi”. Kupiły kosztowne narzędzia do modelowania procesów, zarządzania zasobami, monitorowania KPI (Key Performance Indicators, ang. Kluczowy miernik efektywności), zleciły kosztowne usługi mapowania i optymalizacji procesów. I co? I wszystko na półkę bo realne procesy dawno „rozeszły” się z tymi w dokumentacji. Dlaczego tak się dzieje? Bo proces to stan a nie cel zarządczy, ludzie pracują w sposób będący wynikiem warunków pracy a nie recepty. 4 System: Zespół elementów współdziałających (źr. Ogólna Teoria Systemów) © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 10 Woda płynie zawsze z góry i nie płynie pod górkę, wytyczenie biegu rzeki kijem na piasku niczego nie zmieni, zbudowanie betonowej rynny i nawet pomp (pod górkę…) jest nietrwałe (patrz ostatnie powodzie i wały przeciwpowodziowe). Zarządzanie procesami biznesowymi to tak na prawdę okresowe robienie zdjęd lotniczych nad rzekami, skuteczne sterowanie ich biegiem polega wyłącznie na tworzeniu właściwego środowiska a nie tylko koryt i wałów, jak się okazuje i tak nietrwałych, nie wytrzymują sytuacji ekstremalnych a to one budują przewagę firm na rynku. © Jarosław Żelioski 2010, http://IT-Consulting.pl © Jarosław Żeliński 2010 http://IT-Consulting.pl Strona 11
