Zarządzanie pro­ce­sa­mi biz­ne­so­wy­mi to tak na praw­dę okre­so­we robie­nie zdjęć lot­ni­czych nad rze­ka­mi, sku­tecz­ne ste­ro­wa­nie ich bie­giem pole­ga wyłącz­nie na two­rze­niu wła­ści­we­go śro­do­wi­ska a nie tyl­ko koryt i wałów, jak się oka­zu­je i tak nie­trwa­łych, nie wytrzy­mu­ją sytu­acji eks­tre­mal­nych a to one budu­ją prze­wa­gę firm na rynku.

Niedawno (14 – 15 Lipca 2010) odby­ła się kon­fe­ren­cja EOIF GigaCon 2010 poświę­co­na sys­te­mom obie­gu doku­men­tów. Nie jest moim celem stresz­cza­nie tej kon­fe­ren­cji, jed­nak po niej nasu­nę­ło mi się kil­ka prze­my­śleń. Pierwsze to, czym tak na praw­dę są te sys­te­my, po dru­gie, dla­cze­go ich wdro­że­nia są tak mało prze­wi­dy­wal­ne. Po kil­ku roz­mo­wach z ich użyt­kow­ni­ka­mi w kulu­arach moż­na odnieść prze­ko­na­nie, że ana­li­zy wyma­gań są tu nie­po­trzeb­ne bo w więk­szo­ści przy­pad­ków to co zosta­je, w efek­cie wie­lu prób, wdro­żo­ne i ode­bra­ne jako koń­co­wy pro­dukt, nie­wie­le ma wspól­ne­go z wyni­ka­mi pier­wot­nej ana­li­zy wyma­gań. Jednym z wie­lu przy­kła­dów jakie pozna­łem to pewien urząd, w któ­rym ana­li­za przed­wdro­że­nio­wa opi­sy­wa­ła pra­wie 300 pro­ce­sów, po wdro­że­niu oka­za­ło się, że jest ich 15 (!). W efek­cie pro­jek­ty tego typu cechu­ją się znacz­nie więk­szym kosz­tem niż pla­no­wa­ny lub nawet wstrzy­ma­niem pro­jek­tu z powo­du wyczer­pa­nia fun­du­szy. Dlaczego tak się dzie­je? Otóż mode­lo­wa­nie prze­pły­wu pra­cy, doku­men­tów i pro­ce­sów jest na eta­pie ana­li­zy bar­dzo czę­sto błęd­nie utoż­sa­mia­ne z ?zapi­sy­wa­niem tego co robią ludzie? co jest poważ­nym błę­dem. (tu stresz­cze­nie, kom­plet­ny doku­ment PDF do pobra­nia, link na koń­cu tekstu)

Elementem two­rzą­cym momen­ta­mi nawet cha­os jest moim zda­niem tak­że pewien bała­gan poję­cio­wy, pre­le­gen­ci (kon­sul­tan­ci) czę­sto bez poda­wa­nia defi­ni­cji uży­wa­li takich pojęć jak: zarzą­dza­nie pro­ce­sa­mi, mode­lo­wa­nie pro­ce­sów, mapo­wa­nie pro­ce­sów, zarzą­dza­nie prze­pły­wem pra­cy, zarzą­dza­nie prze­pły­wem doku­men­tów, rein­ży­nie­ria pro­ce­sów, być może poja­wia­ły się jesz­cze inne, któ­re mi umknę­ły ale i to już daje obraz tego bałaganu. […]

Korzyści z formalnego podejścia do modelowania

Podstawową korzy­ścią jest jed­no­znacz­ny model orga­ni­za­cji nio­są­cy istot­ne infor­ma­cje i oczysz­czo­ny z tak zwa­nych ?śmie­cio­wych danych? czy­li tego co nam powie­dzia­no o orga­ni­za­cji a nie jest istot­ne w kon­tek­ście pro­jek­tu. Ta cecha for­mal­nych metod mode­lo­wa­nia pro­ce­sów pozwa­la po pierw­sze pano­wać nad zło­żo­no­ścią mode­li po dru­gie pro­wa­dzi do ich uogól­nie­nia. Uogólnianie na tym eta­pie przy­no­si dużo korzy­ści gdyż po pierw­sze mode­le sta­ja się prost­sze, opi­su­ją stan fak­tycz­ny i sku­pia­ją uwa­gę tyl­ko na tym co istot­ne czy­li na celu pra­cy a nie na tym jak jest w danym momen­cie wyko­ny­wa­na, bo nie raz może ona być wyko­na­na na wie­le rów­no­praw­nych spo­so­bów, któ­rych doku­men­to­wa­nie jest wła­śnie ?zaśmie­ca­niem? modeli.

Zawsze istot­ny jest tyl­ko pro­dukt pro­ce­su i ewen­tu­al­ne ogra­ni­cze­nia w jego powstaniu.

Praktyka poka­zu­je, że wie­le map pro­ce­sów zawie­ra­ją­cych dzie­siąt­ki dia­gra­mów tak na praw­dę poka­zu­je warian­ty tego same­go pro­ce­su. Bardzo czę­sto tak­że to co jest mode­lo­wa­ne jako jeden skom­pli­ko­wa­ny pro­ces to tak na praw­dę kil­ka pro­ce­sów współ­dzie­lą­cych dane (jest to bar­dzo czę­sto spo­ty­ka­ny przy­pa­dek w audy­tach jakie pro­wa­dzę). Na zakoń­cze­nie przy­kład, któ­ry poka­że opi­sa­ne zja­wi­ska i korzy­ści z formalizacji. […]

Konkluzja: prze­pływ danych nie jest toż­sa­my z prze­pły­wem pracy!

Dlaczego niektóre rozwiązania sprawiają kłopoty wdrożeniowe

Jak część z Państwa zapew­ne wie, bo doświad­czy­ła tego, wdro­że­nie sys­te­mu work­flow (uży­wam tego poję­cia celo­wo zamiast obieg doku­men­tów czy zarzą­dza­nie pro­ce­sa­mi dla odróż­nie­nia i wska­za­nia go jako pew­nej abs­trak­cji), przej­ście od map pro­ce­sów z fazy ana­li­zy wyma­gań do imple­men­ta­cji w fazie wdro­że­nia potra­fi spra­wić wie­le kło­po­tów. To co moż­na bez pro­ble­mu nary­so­wać nie zawsze da się potem wdro­żyć (zaim­ple­men­to­wać w kupio­nym opro­gra­mo­wa­niu). Dlaczego?

Po pierw­sze nie­sfor­ma­li­zo­wa­ne mode­le w zasa­dzie nie nada­ją się imple­men­ta­cji w jakim­kol­wiek opro­gra­mo­wa­niu i są głów­nym ryzy­kiem w pro­jek­cie, a po dru­gie na ryn­ku moż­na spo­tkać dwa rodza­je opro­gra­mo­wa­nia: do zarzą­dza­nia prze­pły­wem doku­men­tów i do zarzą­dza­nia prze­pły­wem pra­cy. Jest to ogrom­na róż­ni­ca gdyż więk­szość mode­li pro­ce­sów opi­su­je prze­pływ pra­cy zaś wie­le pro­duk­tów nazy­wa­nych ?zarzą­dza­nie obie­giem doku­men­tów? fak­tycz­nie słu­ży do zarzą­dza­nia prze­pły­wem doku­men­tów. W efek­cie ma miej­sce pró­ba doko­na­ni nie­moż­li­we­go. Na czym pole­ga róż­ni­ca? Źródło kło­po­tów tkwi w mode­lu danych (mode­lu dzie­dzi­ny) dla obu tych rozwiązań. […]

Dla zain­te­re­so­wa­nych: nota­cja BPMN imple­men­tu­je wła­śnie taki model dzie­dzi­ny dla­te­go moż­na powie­dzieć, że jeże­li pod­czas ana­li­zy biz­ne­so­wej mode­le wyko­na­no w tej nota­cji z uży­ciem peł­nej seman­ty­ki tej nota­cji, to pro­gram któ­ry miał by posłu­żyć do wdro­że­nia tych pro­ce­sów MUSI na liście swo­ich wyma­gań mieć peł­ną zgod­ność z powyż­szym mode­lem refe­ren­cyj­nym. Nie wol­no łamać for­ma­li­zmów nota­cji BPMN (seman­ty­ka i syn­tak­ty­ka nota­cji), w prze­ciw­nym wypad­ku wdro­że­nie pro­ce­sów w for­mie opi­sa­nej dia­gra­ma­mi się nie uda!

Dlatego każ­da ana­li­za biz­ne­so­wa ukie­run­ko­wa­na na sys­tem obie­gu doku­men­tów (czy­li tak na praw­dę prze­pły­wu pra­cy) musi zawie­rać etap for­ma­li­za­cji mode­li pro­ce­sów jeże­li pro­jekt ma być wykonywalny.

Zarządzanie procesami biznesowymi

Popularny skrót BPM (ang. Busienss Process mana­ge­ment ? Zarządzanie Procesami Biznesowymi) budzi coraz więk­sze moje roz­cza­ro­wa­nie wie­lo­ma fir­ma­mi. To nowe sło­wo klucz (ang. buz­zword) sta­ło się ostat­nio przy­pra­wą do wie­lu ofert mają­cą je dodat­ko­wo uatrak­cyj­nić. Tak więc czym to zarzą­dzać? Procesem? Czy samo nary­so­wa­nie dia­gra­mu prze­pły­wu pra­cy cokol­wiek zmie­ni w orga­ni­za­cji? NIE, wie to każ­dy kto brał udział w pro­jek­cie ?rein­ży­nie­rii pro­ce­sów? (BPR, ang. Business Process Reengineering, prak­ty­ka wręcz skom­pro­mi­to­wa­na w latach 90-tych) wdra­żał nor­my jako­ści ISO meto­dą naj­pierw doku­men­ta­cja ISO potem jej wdro­że­nie (to moim zda­niem powód kom­pro­mi­ta­cji idei wdra­ża­nia norm ISO w wie­lu organizacjach).

Całe śro­do­wi­sko orga­ni­za­cji to ludzi i komu­ni­ka­cja mię­dzy nimi. Komunikujemy się bez­po­śred­nio lub pośred­nio za pomo­cą doku­men­tów (maile, komu­ni­ka­to­ry, doku­men­ty, inne).[…] Jeżeli jakiś ciąg zda­rzeń, czyn­no­ści dopro­wa­dza do powsta­nia jakiejś tre­ści lub zaist­nie­nia zda­rze­nia i powta­rza się (lub chce­my by się powta­rzał) ?ubie­ra­my? go ?nazwę? a na dia­gra­mach zazna­cza­my sym­bo­lem ozna­cza­ją­cym pro­ces. Na tym wła­śnie pole­ga mode­lo­wa­nie pro­ce­sów, któ­re tym się róż­ni od mapo­wa­nia (ryso­wa­nia), że nie jest tyl­ko ryso­wa­niem a ana­li­zą i doku­men­to­wa­niem jej wyni­ków: zobra­zo­wa­niem tego co i po co się dzie­je w organizacji.

Co to więc jest to BPM? Moim zda­niem mode­le pro­ce­sów (mapy pro­ce­sów) to sku­tek, Wyjście pro­ce­su wdra­ża­nia zmian a nie jego Wejście!. Zarządzanie pro­ce­sa­mi pole­ga na zarzą­dza­niu ogra­ni­cze­nia­mi (np. poprzez two­rze­nie pro­ce­dur, poli­tyk bez­pie­czeń­stwa, itp.), któ­re w efek­cie skut­ku­ją takim a nie innym prze­pły­wem pracy.

Miałem kon­takt z wie­lo­ma fir­ma­mi, któ­re dały się namó­wić na pro­jekt ?Zarządzanie Procesami Biznesowymi?. Kupiły kosz­tow­ne narzę­dzia do mode­lo­wa­nia pro­ce­sów, zarzą­dza­nia zaso­ba­mi, moni­to­ro­wa­nia KPI (Key Performance Indicators, ang. Kluczowy mier­nik efek­tyw­no­ści), zle­ci­ły kosz­tow­ne usłu­gi mapo­wa­nia i opty­ma­li­za­cji pro­ce­sów. I co? I wszyst­ko na pół­kę bo real­ne pro­ce­sy daw­no ?roze­szły? się z tymi w doku­men­ta­cji. Dlaczego tak się dzie­je? Bo pro­ces to stan a nie cel zarząd­czy, ludzie pra­cu­ją w spo­sób będą­cy wyni­kiem warun­ków pra­cy a nie recepty.

Woda pły­nie zawsze z góry i nie pły­nie pod gór­kę, wyty­cze­nie bie­gu rze­ki kijem na pia­sku nicze­go nie zmie­ni, zbu­do­wa­nie beto­no­wej ryn­ny i nawet pomp (pod gór­kę?J) jest nie­trwa­łe (patrz ostat­nie powo­dzie i wały przeciwpowodziowe).

(peł­na treść opra­co­wa­nia dostęp­na do naby­cia klik­nij poniżej)

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie.) Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.