Mam na myśli systemy, nie tylko infrastrukturę w sensie nowych

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.
D OKUMENTY 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
Obieg danych, dokumentów, informacji a proces biznesowy
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.
K IEDY I CO MODELOWAĆ
J E Ż ELI
C Z E GO Ś N I E MO Ż N A N AR YSO W A Ć T O ZN A C ZY , Ż E T O N I E
I ST N I E JE !
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.
P ROCESY
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
Obieg danych, dokumentów, informacji a proces biznesowy
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).
C ZY
ZAWSZE WIEMY KIED Y PROCES A KIEDY PRO CEDURA , 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.
P RODUKTY I PROCESY A ICH DOKUMENTOWAN IE
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
Obieg danych, dokumentów, informacji a proces biznesowy
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.
M APA
PROCESÓW BIZNESOWY CH
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.
M APA
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
Obieg danych, dokumentów, informacji a proces biznesowy
Controll w definicji procesu. Procedury są opisywane za pomocą symboli takich jak
czynność, decyzja, dokument, interfejs itp.
P R ZY K Ł A D
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
Obieg danych, dokumentów, informacji a proces biznesowy
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
Obieg danych, dokumentów, informacji a proces biznesowy
© 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