Wczorajsza kon­fe­ren­cja EOIF GigaCon była dla mnie kolej­ną oka­zją do podzie­le­nia się z jej gość­mi, moimi oraz cudzy­mi doświad­cze­nia­mi, cudzy­mi czy­li tymi, któ­rych bywam nie raz świad­kiem. Poproszono mnie o wygło­sze­nie refe­ra­tu na temat sys­te­mów zarzą­dza­nia prze­pły­wem pra­cy i kon­se­kwen­cja­mi korzy­sta­nia z nich w tak zwa­nej chmu­rze (clo­ud com­pu­ting). Przy oka­zji, dla porząd­ku i tytu­łem wpro­wa­dze­nia, powie­dzia­łem kil­ka słów o tym, czym w ogó­le tego typu sys­te­my są i jakie są ryzy­ka ich wdrażania.

BPM – czym jest

Krótkie pod­su­mo­wa­nie tego czym jest BPM (Business Process Management). BPM to przede wszyst­kim zarzą­dza­nie, a nie tyl­ko jed­no czy kil­ka zadań połą­czo­nych w ​„logicz­ny ciąg”. BPM to cała dys­cy­pli­na zaj­mu­ją­ca się pod­no­sze­niem efek­tyw­no­ści orga­ni­za­cji poprzez opty­ma­li­za­cję pro­ce­sów w niej zacho­dzą­cych. Proces to coś co zacho­dzi w gra­ni­cach orga­ni­za­cji łącząc ludzi, zaso­by, prze­pływ infor­ma­cji, two­rzy okre­ślo­ną wartość.

Powyżej mamy defi­ni­cję zaczerp­nię­tą ze stron fir­my Gartner, któ­rą uwa­żam, że jed­ną z peł­niej­szych. Dalej mój dia­gram, któ­ry czę­sto pre­zen­tu­ję, obra­zu­ją­cy kom­plet wie­dzy jaką nale­ży posia­dać by móc mówić o tym, że pro­ces został udo­ku­men­to­wa­ny i zro­zu­mia­ny. Są to ogra­ni­cze­nia (pra­wo, wewnętrz­ne regu­ły biz­ne­so­we) oraz wyko­naw­ca pro­ce­su dys­po­nu­ją­cy okre­ślo­na wie­dzą, upraw­nie­nia­mi i narzę­dzia­mi pracy.

Trzeci dia­gram, waż­ny dla zro­zu­mie­nia tego czym jest ​„wspo­ma­ga­nie prze­pły­wu pra­cy i doku­men­tów”, poka­zu­je ogól­na archi­tek­tu­rę opro­gra­mo­wa­nia ​„work­flow”. Oprogramowanie takie skła­da się, naj­ogól­niej rzecz bio­rąc, z repo­zy­to­rium doku­men­tów oraz tak zwa­ne­go sil­ni­ka pro­ce­so­we­go (zarzą­dza pro­ce­sem). Repozytorium to nic inne­go jak archi­wum doku­men­tów elek­tro­nicz­nych. Silnik pro­ce­so­wy to kom­po­nent odpo­wie­dzial­ny za zarzą­dza­nie kolej­no­ścią wyko­ny­wa­nia zadań i ich przy­dzie­la­niem do wła­ści­wych osób. Należy tak­że pamię­tać, że prze­pływ pra­cy w orga­ni­za­cji jest nad­zo­ro­wa­ny postę­pem efek­tów tych prac, te zaś to nic inne­go jak powsta­ją­ce tre­ści (doku­men­ty, tak­że w posta­ci pól róż­nych formularzy).

Tak więc opro­gra­mo­wa­nie nazy­wa­ne work­flow (nie raz docu­ment­flow) to nie to samo co opro­gra­mo­wa­nie wspo­ma­ga­ją­ce BPM. Mam nadzie­ję, że kon­fron­ta­cja defi­ni­cji BPM i archi­tek­tu­ry tych apli­ka­cji, jasno to poka­zu­je. Na co nale­ży uwa­żać? Kilka ele­men­tów, na któ­re war­to zwró­cić uwa­gę w ofer­tach przed wybo­rem rozwiązania:

1. Aplikacja rekla­mo­wa­na jako ​„obieg fak­tur kosz­to­wych” (wnio­sków urlo­po­wych i innych kon­kret­nych typów doku­men­tów) to naj­praw­do­po­dob­niej pro­ste repo­zy­to­rium z wbu­do­wa­nym sys­te­mem prze­ka­zy­wa­nia dostę­pu do doku­men­tu kolej­nym oso­bom z usta­lo­nej listy. Tego typu apli­ka­cje nada­ją się do zarzą­dza­nia (zatwier­dza­nie i archi­wi­za­cja) np. dowo­da­mi księ­go­wy­mi, bar­dzo praw­do­po­dob­ne, że jed­nak nie pora­dzą sobie, bez duże­go nakła­du pra­cy po stro­nie dostaw­cy, np. z pro­ce­sem obsłu­gi zapy­tań ofer­to­wych czy np. rekla­ma­cji, gdyż tu poza doku­men­tem otrzy­ma­nym z zewnątrz, powsta­ją nowe powią­za­ne doku­men­ty, ich prze­twa­rza­nie może zacho­dzić wie­lo­ma róż­ny­mi dro­ga­mi, a sam moduł repo­zy­to­rium (archi­wum doku­men­tów) naj­czę­ściej nie nada­je się do tego typu zasto­so­wań. Tego typu apli­ka­cje bar­dzo czę­sto, poza moni­to­wa­niem ter­mi­nów, nie pozwa­la­ją na budo­wa­nie roz­bu­do­wa­nych rapor­tów na potrze­by BPM.
2. Narzędzia do mode­lo­wa­nia pro­ce­sów biz­ne­so­wych wbu­do­wa­ne w tego typu opro­gra­mo­wa­nie, pra­wie zawsze mają ogra­ni­cze­nia wyni­ka­ją­ce z archi­tek­tu­ry dane­go opro­gra­mo­wa­nia i zasto­so­wa­nych wewnętrz­nych wzor­ców, czę­sto są to tyl­ko tak zwa­ne ​„maszy­ny sta­no­we”, któ­re pozwa­la­ją jedy­nie na budo­wa­nie pro­ce­sów pole­ga­ją­cych na prze­łą­cza­niu sta­tu­sów kon­kret­nych doku­men­tów (for­mu­la­rzy) w odpo­wie­dzi na defi­nio­wa­ne zda­rze­nia. Stosowanie takie­go narzę­dzia np. na eta­pie ana­li­zy przed-wdro­że­nio­wej, pro­wa­dzi czę­sto do znacz­ne­go ogra­ni­cze­nia zakre­su takiej ana­li­zy, do wie­lu zadań są to narzę­dzia po pro­tu nie­przy­dat­ne. Zastosowanie przed wdro­że­niem (a zale­ca się nawet przed wybo­rem dostaw­cy i roz­wią­za­nia) narzę­dzia do ana­li­zy i mode­lo­wa­nia pro­ce­sów, pozwa­la­ją­ce­go na sko­rzy­sta­nie z wszyst­kich zalet nota­cji np. BPMN (obec­nie prak­tycz­nie już stan­dard w takich pro­jek­tach) pozwa­la oce­nić na ile ogra­ni­cze­nia kon­kret­ne­go opro­gra­mo­wa­nia wpły­ną na utra­tę moż­li­wo­ści zaspo­ko­je­nia wszyst­kich potrzeb organizacji.
3. Repozytorium doku­men­tów powin­no pozwa­lać na auto­ma­tycz­ne wer­sjo­no­wa­nie doku­men­tów, nie powin­no pozwa­lać na przy­pad­ko­we usu­nię­cie doku­men­tu, powin­no pozwa­lać na budo­wa­nie wie­lu, wła­snych, roz­bu­do­wa­nych sys­te­mów meta­da­nych (cechy doku­men­tów), gdyż jest to stan­dar­do­wy spo­sób na kla­sy­fi­ko­wa­nie doku­men­tów (bez tego np. trud­no je póź­niej wyszu­kać czy pogrupować).
4. Narzędzie tego typu powin­no pozwa­lać użyt­kow­ni­kom na samo­dziel­ne budo­wa­nie kolej­nych nowych sche­ma­tów pro­ce­sów prze­pły­wu pra­cy bez koniecz­no­ści anga­żo­wa­nia pro­gra­mi­stów. Workflow, jako apli­ka­cja, powin­no być plat­for­mą budo­wy takich prze­pły­wów a nie opro­gra­mo­wa­niem zawie­ra­ją­cym wyłącz­nie ​„zamó­wio­ne” pro­ce­sy. Brak tej cechy, samo­dziel­ne budo­wa­nie kolej­nych prze­pły­wów, to prak­tycz­nie dys­kwa­li­fi­ka­cja narzę­dzia w rozu­mie­niu BPM.

Cloud computing

Regularnie spo­ty­kam defi­ni­cje tego ter­mi­nu, więk­szość z nich bazu­je na róż­nych for­mach out­so­ur­cin­gu. Proponuje defi­ni­cję, któ­ra obec­nie chy­ba naj­traf­niej odda­je to czym jest clo­ud com­pu­ting (prze­twa­rza­nie w chmurze):

Ta uogól­nio­na defi­ni­cja pod­kre­śla, że clo­ud com­pu­ting to przede wszyst­kim pro­sto­ta, wrę­cza auto­ma­ty­za­cja, roz­po­czę­cia i rezy­gna­cji z korzy­sta­nia z zaso­bu. To głów­na, moim zda­niem, cecha odróż­nia­ją­ca ​„chmu­rę” od zna­nych już usług w rodza­ju SaaS (Software as a Service) czy ASP (Application Service Provider). Warto tak­że zwró­cić uwa­gę na to, że z per­spek­ty­wy praw­nej czym innym jest ​„dzier­ża­wa opro­gra­mo­wa­nia” a czym innym jest ​„usłu­ga prze­twa­rza­nia”. Innymi sło­wy czym innym jest wypo­ży­cze­nie od kogoś (dzier­ża­wa) kal­ku­la­to­ra a czym inny­mi pła­ce­nie komuś za wyko­ny­wa­nie obli­czeń, to nie jest to samo. Cloud Computing to czę­sto wła­śnie opła­ta za przetwarzanie.

Ważna rzecz to bez­pie­czeń­stwo. Spotykam się z wie­lo­ma opi­nia­mi praw­ny­mi na temat tego kto prze­twa­rza dane i kie­dy. Samo posia­da­nie danych i mani­pu­lo­wa­nie nimi to ich prze­twa­rza­nie. Jednak prze­twa­rza­nie pli­ku nie musi ozna­czać prze­twa­rza­nia (dostę­pu do) jego tre­ści. Zarządca prze­strze­ni dys­ko­wej nie­wąt­pli­wie prze­twa­rza nasze pli­ki, ale czy aby na pew­no zawsze prze­twa­rza dane w nich zawar­te? Składowanie danych w posta­ci zako­do­wa­nej powo­du­je, że usłu­go­daw­ca prze­twa­rza nasze pli­ki (np. wyko­nu­je ich regu­lar­ne kopie zapa­so­we), ale czy prze­twa­rza zawar­te w tych pli­kach tre­ści? Nie, jeże­li są to więc np. zako­do­wa­ne dane oso­bo­we (typo­we tak zwa­ne wraż­li­we dane) to usłu­go­daw­ca nie prze­twa­rza tych danych (nie ope­ru­je dany­mi osób) a jedy­nie pli­kiem zawie­ra­ją­cym te dane w posta­ci zako­do­wa­nej, więc nie ma on dostę­pu do danych osobowych.

Moim zda­niem, Ci praw­ni­cy, któ­rzy for­su­ją tezę, że dane zako­do­wa­ne tak­że nale­ży trak­to­wać jako dane prze­twa­rza­ne, pró­bu­ją wyka­zać, że fir­ma wywo­żą­ca maku­la­tu­rę powsta­łą w nisz­czar­kach doku­men­tów, prze­twa­rza dane, któ­re tam były zawar­te… Na szczę­ście dla mnie, są tak­że praw­ni­cy zga­dza­ją­cy się ze mną. Problem ten – moim zda­niem – jest efek­tem tego, że sło­wo ​„dane” ozna­cza zarów­no dane cyfro­we jaki­mi są jakie­kol­wiek bity na nośni­kach, jak i treść zro­zu­mia­łą dla czło­wie­ka napi­sa­ną w jakimś języ­ku (źr. słow­nik j.p. PWN):

dane 1. ?fak­ty, licz­by, na któ­rych moż­na się oprzeć w wywo­dach? 2. ?infor­ma­cje prze­twa­rza­ne przez komputer?

gdzie ​„infor­ma­cje prze­twa­rza­ne przez kom­pu­ter” to mię­dzy inny­mi ich cyfro­wa for­ma jaką jest każ­dy plik danych na dys­ku mają­cy nazwę. Tu więk­szość praw­ni­ków, nie mają­ca głę­bo­kiej wie­dzy tech­nicz­nej, myli się trak­tu­jąc uży­te w usta­wach sło­wo ​„dane” lite­ral­nie, zapo­mi­na­jąc, że ma ono nie­ste­ty wię­cej niż jed­no znaczenie.

Na zakończenie

Tak wiec BPM to sfe­ra zarzą­dza­nia orga­ni­za­cją a nie tyl­ko jakieś opro­gra­mo­wa­nie, ono może jedy­nie wspie­rać to zarzą­dza­nie. Zły wybór opro­gra­mo­wa­nia z regu­ły pro­wa­dzi do pogor­sze­nia spraw­no­ści orga­ni­za­cji (przy­kła­dy poda­wał na tej kon­fe­ren­cji Pan Piotr Biernacki), nie raz pro­wa­dzi to do zarzu­ce­nia korzy­sta­nia z tego opro­gra­mo­wa­nia. Dlatego kolej­ność: naj­pierw wybór opro­gra­mo­wa­nia i jego dostaw­cy a potem wdro­że­nie, naj­czę­ściej koń­czy się poraż­ką lub co naj­mniej znacz­nie gor­szy­mi efek­ta­mi niż ocze­ki­wa­ne (obie­ca­ne).

Oprogramowanie work­flow, w tak zwa­nej chmu­rze, ma wie­le zalet, jed­nak ma tak­że poważ­ną wadę: kło­po­tli­wa inte­gra­cja z lokal­ny­mi sys­te­ma­mi (np. ERP) wyni­ka­ją­ca z tego, że doku­men­ty poko­nu­ją zawsze podwój­ną dro­gę od naszej loka­li­za­cji do usłu­go­daw­cy i z powro­tem. W przy­pad­ku małych firm (mała ilość danych) z regu­ły nie sta­no­wi to pro­ble­mu. Dla dużych firm może to być nawet barie­ra nie do poko­na­nia, dla­te­go tak zwa­na ​„chmu­ra pry­wat­na” czy­li lokal­na insta­la­cja może być jedy­nym wyjściem.

Na koniec: zanim zawrze­cie Państwo umo­wę na taką usłu­gę war­to się skon­sul­to­wać z praw­ni­kiem wyspe­cja­li­zo­wa­nym w tego typu usługach.