OBIEG DANYCH, DOKUMENTÓW, INFORMACJI A PROCES BIZNESOWY ZARZĄDZANIE PROCESAMI BIZNESOWYMI A OBIEG DOKUMENTÓW Z jednej strony trudno się nie zgodzić z tezą, że elektroniczny obieg dokumentów to przyszłość. Z drugiej mam wrażenie, że podejście technokratyczne zmierzające do wyeliminowania papieru jest jednak chybione. Między innymi dlatego, że paradoksalnie papier jest najtrwalszym i najbezpieczniejszym w relacji do ceny sposobem przechowywania informacji a jego zużycie rośnie nie tylko w Polsce. DOKUMENTY I PROCESY Demagogią jest twierdzenie, że koszt przechowywania dokumentu elektronicznego to tylko kilka mikrometrów dysku i koszt tego mini obszaru. Prawdziwym kosztem przechowania dokumentu elektronicznego jest koszt całej infrastruktury wraz z jej zabezpieczeniem. Gdyby było inaczej każdy z nas miał by już w firmie elektroniczne super archiwum. Po drugie obieg dokumentów to nie zarządzanie procesami. Dokumenty są tylko jednym z elementów mapy procesów organizacji. Więc systemy obiegu dokumentów to wsparcie zarządzania zorientowanego na procesy a nie systemy zarządzania procesami biznesowymi. Ale po kolei. Wielu konsultantów utożsamia pojecie obiegu dokumentów, obiegu informacji z procesami biznesowymi i ich zarządzaniem. Jest to moim zdaniem kluczowe nieporozumienie, żeby nie powiedzieć błąd. Proces biznesowy to działanie charakteryzujące się przede wszystkim wnoszeniem wartości dodanej, obecność papieru czy dokumentu w wersji elektronicznej nie ma tu nic do rzeczy. Na mapie procesów biznesowych dokumenty i ich kolejne wersje stanowią produkty procesów (nie jedyne). Proces polegający na podjęciu decyzji to praca człowieka niosąca dużą wartość dodaną ale nie obieg dokumentów będących śladami po niektórych tylko procesach w firmie. Inny przykład: procesem jest wyprodukowanie podzespołu i nie ma to nic wspólnego z systemem obiegu dokumentów. Gdzieś po drodze będzie proces powstania dokumentacji technicznej ale to jeden z elementów systemu zarządzania procesami w firmie, jego podsystem. Tak więc na pewno systemy obiegu dokumentów, obiegu informacji są ważnymi elementami w każdej organizacji ale są to tylko produkty i to nie wszystkie na mapie procesów biznesowych firmy dlatego właśnie nazywanie systemów klasy workflow systemami BPM (Business Process Management) uważam za poważne nadużycie. Jarosław Żelioski 2007
Kolejna ślepa uliczka jaką dostrzegam w reklamach systemów klasy workflow to wskazywanie jako głównej korzyści ich wdrożenia narzucenie ścisłej kontroli poczynaniom pracowników. Nie znam przypadku wdrożenia systemu zakończonego sukcesem, którego głównym celem było kontrolowanie pracowników wbrew ich woli. Typowym przykładem są różnego typu restrykcyjne systemy kontroli czasu pracy czy kontroli pracy przy komputerze, nadzór urzędnika tą metodą także się nie sprawdza. Lepszy jest moim zdaniem system informatyczny zaprojektowany tak by pomagał pracownikom osiągać ich cele. On niejako wdraża się sam. Systemy kontroli i restrykcji, nawet jeżeli udaje się je wdrożyć, są bardzo kosztowne i często bojkotowane przez ludzi. Jednak coś w tym jest, obieg dokumentów (danych) czasami staje się modelem procesów. KIEDY I CO MODELOWAĆ JEŻELI CZEGOŚ NI E MO Ż NA N AR YSOW AĆ TO ZN AC ZY, ŻE TO NI E ISTNI EJE! Powyższe odnosi do istoty procesów i zarządzania nimi. Żeby jednak czymkolwiek zarządzać należy to najpierw opisać czyli udokumentować. Dokumentem takim jest tu mapa procesów biznesowych. Jest ona niczym innym jak modelem firmy z perspektywy jej funkcjonowania. Jak wykonać mapę procesów czyli model firmy? Model firmy powinien w sposób jasny i zrozumiały dla jej pracowników opisywać firmę, jej cel rynkowy oraz wszelkie jej wewnętrzne i zewnętrzne zachowania oraz reakcje. Poza tym, jest niezbędny do przewidywania zachowań firmy w tym także do przygotowania jej do wdrożenia systemów informacyjnych. PROCESY Proces: zbiór działań wzajemnie powiązanych lub wzajemnie oddziałujących, które przekształcają wejścia w wyjścia (wg. PN-EN ISO 9000:2000, p.3.4.1). Rozszerzając to na procesy biznesowe można powiedzieć: Proces (definicja ICOM): zespół czynności lub działań, których celem jest osiągnięcie oczekiwanego rezultatu. Rezultat ten jest osiągany poprzez przetworzenie stanu wejścia procesu w stan wyjściowy. Przetworzenie to sterowane jest za pomocą z góry ustalonych reguł. Do osiągnięcia tak określonego rezultatu wymagane określone zasoby. (ICOM Process: Input, Controll, Output, Mechanizm). Proces biznesowy: spójny zespół działań, których celem jest osiągnięcie określonej wartości w postaci produktu. Do wytworzenia produktu wymagane są: zasoby, inne produkty lub półprodukty (surowce) oraz reguły (zasady) według których tworzony jest produkt. Produkt musi dać się opisać (zdefiniować) i być mierzalny. Jedną z prostych metod oceny wykonanej mapy procesów biznesowych na poziomie organizacji (tak zwany pierwszy poziom czyli co robimy ) 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 kluczowych procesów! Diagramy ze ścieżkami decyzyjnymi to procedury (opisy jak to robimy ) a nie procesy. Jarosław Żelioski Strona 2 2008-02-14
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 struktura. 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 (Control). 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 na tym poziomie jest zawsze, jego wynik może być różny. Na poprawnej mapie procesów pierwszego poziomu dla tego urzędu będzie więc między innymi symbol tego procesu ale żadnych rombów. Romby (decyzje) są cechą opisu od tak zwanego drugiego poziomu czyli opisu tego jak to robimy (przepływ pracy, procedury). Znamy je między innymi z dokumentacji do ISO. (workflow). CZY ZAWSZE WIEMY KIEDY PROCES A KIEDY PROCEDURA, A MOŻE SCENARIUSZ? Nowoczesne metody modelowania pozwalają na pewną swobodę stosowanych konwencji. Polega ona na tym, że coraz częściej spotykamy się z łączeniem poziomów modelowania. Celem takich działań jest pokazanie tego co istotne a nie wszystkiego co wiemy. Rozróżnienie procesów i procedur jest proste wtedy gdy chcemy procesy implementować. Można przyjąć, że wersja możliwa do implementacji (czyli w pełni dokładna), np. w systemie workflow, to procedura (workflow) zaś wszelkie jej uogólnienia to już procesy. Nie spotkałem się z definicją ściśle rozgraniczającą procedurę od procesu. Bywa, że pojęcia te są używane nawet zamiennie. Dlatego coraz częściej można się spotkać z pojęciem scenariusza czynności jako opisem realizacji procesu jako sekwencji czynności. Drugim powodem zamiennego stosowania tych pojęć jest przyjęta w danym projekcie metoda opisu organizacji. Można się spotkać z dwiema podstawowymi: od ogółu do szczegółu (top-down) oraz od szczegółu do ogółu (bottom-up). Obie mają wady i zalety. W każdym razie spotykamy się z tym, że na najwyższym poziomie uogólnienia mówimy o procesach a na najniższym o procedurach lub właśnie dla ułatwienia o scenariuszach. Scenariuszem najczęściej nazywa się opis wykonania czynności przez jedna osobę. Pojęcie to jest także wykorzystywane w modelowaniu oprogramowania w metodzie stosującej przypadki użycia. PRODUKTY I PROCESY A ICH DOKUMENTOWANIE Należy więc stwierdzić jedną rzecz: panuje straszny bałagan pojęciowy wywołany tym, że mamy do czynienia niestety z modą na procesy i wielu producentów aplikacji ma ambicję użyć magicznej sekwencji słów business process management nawet, jeżeli to nie ma sensu. W wiec czym problem? Podsumujmy. Po pierwsze proces biznesowych to sekwencja zdarzeń (czynności) w firmie a nie w systemie IT. System co najwyżej może pomagać je śledzić i kontrolować, może je także odzwierciedlać. Po drugie: nie należy mylić trzech Jarosław Żelioski Strona 3 2008-02-14
rzeczy: modelowania, zarządzania i informatycznego wspomagania procesów biznesowych. Na rynku, niezależnie od tego jak same się określają, mamy do czynienia z rozwiązaniami wspomagającymi modelowanie procesów i zarządzanie procesami, są to takie pakiety jak MS Visio, igraphicx, ARIS i wiele innych. Pakiety takie jak Ultimus czy FileNet to systemy zarządzania obiegiem informacji (w tym dokumentów) w firmach, choć same o sobie często mówią, że zarządzają procesami biznesowymi. Pamiętajmy, że proces to czynności a nie papier ani jego elektroniczna reprezentacja. Dokument lub plik, rekord bazy danych to co najwyżej namacalne produkty procesów. Zintegrowane systemy informatyczne coraz częściej mają w nazwie słowa zorientowane procesowo lub zorientowane na procesy. To już bliższe prawdy stwierdzenia, gdyż są one właśnie tak zbudowane by implementacja systemu polegała niemalże wprost na przepisaniu do nich modeli procesowych (map procesów). Tak więc zorientowane na procesy są: Ultimus, FileNet, SAP BusinessOne i inne. Wdrożenie tych systemów polega (w dużym uproszczeniu) na wpisaniu do nich map procesów. Po tej czynności system taki jest dopasowany do stylu pracy firmy. Różnica między nimi polega np. na tym, ża system SAP to system ERPII, FileNet to system typu document flow management itp. czyli każdy z nich wspiera inny obszar pracy w firmie. A gdzie systemy typu IBM WebSphere czy BizTalk? To są systemy będące w pewnym sensie generatorem aplikacji. Mając model procesowy firmy można go ucieleśnić właśnie z pomocą jednego z tych (są jeszcze inne) systemów. Systemy tego typu są też używane jako narzędzie do integracji innych systemów. W takim przypadku spełniają rolę systemów midlleware. Dlaczego? Systemy takie to motory aplikacyjne. Zdefiniowane procesy ubierają w ciało w ten sposób, że definiuje się proces (regułę), dane wejściowe i ich źródło, dane wyjściowe i ich cel. Jak widać definicja bardzo ogólna ale tak to właśnie wygląda. MAPA PROCESÓW BIZNESOWYCH Mapa procesów to obraz przedstawiający wszystkie czynności i ich agregacje, czyli procesy, jakie wewnątrz organizacji są realizowane w celu wytworzenia finalnego produktu (lub produktów). Produktem może być przedmiot ale także usługa (a raczej stan jaki po niej zostaje). Wszystko co ma cechy i cenę oraz przedstawia jakąś wartość dla kupującego jest produktem. Cechą procesu na mapie procesów jest jego istnienie i brak możliwości pominięcia. Np. proces wydawania decyzji w Urzędzie jest realizowany bo decyzja zawsze musi się pojawić w odpowiedzi na złożenie podanie o jej wydanie. Może ona być pozytywna lub negatywna, może wymagać opinii biegłego lub nie, może wymagać sprawdzenia wcześniejszych innych decyzji itp. To jednak określa procedura wydawania decyzji. Proces jest niezmienny. MAPA PRZEPŁYWU PRACY Procedury to właśnie opisy sposobu realizacji funkcji opisanych przez procesy. Tu dopiero jest miejsce na romby. Procedurami definiuje się np. sposób pracy systemów obiegu dokumentów (informacji) w firmach. Procedura to jeden z elementów nazywanych Jarosław Żelioski Strona 4 2008-02-14
Controll w definicji procesu. Procedury są opisywane za pomocą symboli takich jak czynność, decyzja, dokument, interfejs itp. PRZYKŁ AD Poniżej prosty przykład metody top-down. Pokaże tu w jaki sposób można doprowadzić do zgodności pomiędzy mapą procesów a systemem workflow (użyto notacji BPMN). Najpierw tworzymy opis celu pracy firmy: Proszę zwrócić uwagę na to, że na końcu umieściłem dokument Protokół odbioru a nie wytworzony podzespół. Jest on produktem firmy jest w systemie może zostać zidentyfikowany tylko jako ślad po jego przekazaniu. Na powyższym diagramie widać miejsce bez produktu pomiędzy wytworzeniem a przyjęciem do magazynu. Można w tym momencie się zastanowić czy to jest jeden proces czy dwa. Tu mamy do podjęcia decyzje co chcemy pokazać i jak to kontrolować. Można przekształcić te dwa procesy w jeden ale można przyjąć, że chcemy kontrolować to co schodzi z taśmy produkcyjnej. W tym drugim przypadku należy wprowadzić nowy dokument, który będzie produktem rozliczenia się tokarza z magazynierem. Wtedy model będzie wyglądał tak: Jarosław Żelioski Strona 5 2008-02-14
Protokół wydania może być także dokumentem związanym z kontrola jakości. Na zakończenie mamy wydanie produktu: Ten diagram można nazwać właśnie procedurą lub scenariuszem. NA ZAKOŃCZENIE Jak wykonać najprostszy test tego w jakim stopniu system nazywany zarządzaniem procesów i obiegu dokumentów czy został wdrożony w 100%? Zapytać w firmie czy można już przestać używać pakietu biurowego czy poczty elektronicznej, lokalnego lub sieciowego dysku na dokumenty itp. Definicja nieco przewrotna jednak pokazuje, że procesy, zarządzanie nimi i ich modelowanie to niekończący się proces w każdej firmie. Jarosław Żelioski Strona 6 2008-02-14
2007 Jarosław Żelioski Absolwent Wojskowej Akademii Technicznej, nauczyciel akademicki. Po skooczeniu studiów i pracy na uczelni od 1991 roku w firmie Bonair S.A. Po okresie zarządzania projektami, realizacji analiz przedwdrożeniowych i studiów wykonywalności zakooczył pracę w firmie w 1998 roku jako dyrektor marketingu i sprzedaży. Następnie jako dyrektor marketingu giełdowego Apexim S.A. w 1998 był autorem strategii rozwoju firmy przyjętej przez zarząd i akcjonariuszy. W roli menedżera rozwoju produktów Elektrim S.A. w roku 2001 stworzył strategię integracji i rozwoju spółek internetowych. Podobny projekt realizował dla spółki z grupy kapitałowej TP S.A. firmy Incenti S.A. w roku 2002. W roku 2003 doradzał w obszarze nowych strategii i usług zarządowi Optimus S.A. W roku 2004 jako szef zespołu planowania i analiz w Exatel S.A. (dawniej Telenergo S.A.) współtworzył plan marketingowy i prognozy rynkowe. Obecnie Członek Stowarzyszenia Doradców Gospodarczych. Od 2004 roku już jako niezależny konsultant pomaga wielu firmom, dużym a także tym małym zatrudniającym czasem tylko kilkanaście osób. Specjalizuje się w tworzeniu modeli biznesowych, map i modeli procesów biznesowych oraz analizach strategicznych. Od początku swej działalności publikuje swoje prace w prasie branżowej i gospodarczej oraz w portalu IT-Consulting.pl, którego jest wydawcą. Od 2005 roku wykładowca na Wydziale Przedsiębiorczości Akademii Morskiej w Gdyni. http://it-consulting.pl Jarosław Żelioski Strona 7 2008-02-14