Przepływ pracy i dokumentów – czego wymagać

Mój nie­daw­ny refe­rat na temat tren­dów w wybo­rze i wdra­ża­niu sys­te­mów work­flow i zapro­sze­nie na kolej­ną kon­fe­ren­cję z tego zakre­su, skło­ni­ły mnie do prze­rzu­ce­nia cię­ża­ru refe­ra­tu z isto­ty prze­pły­wu doku­men­tów, na prze­pływ doku­men­tów w kon­tek­ście wdro­że­nia narzę­dzia. któ­re w tym poma­ga. Poniżej pre­zen­ta­cja ilu­stru­ją­ca referat:

Na koniec tego krót­kie­go wpi­su dodam, że w swej głów­nej czę­ści, sys­tem obie­gu doku­men­tów to jeden przy­pa­dek uży­cia.

(refe­rat był wygło­szo­ny na kon­fe­ren­cji EOIF GigaCon, 9 Października 2014 we Wrocławiu).

Przepływ pracy w chmurze – czyli cudzy worlkflow

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):

Slajd10

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.

Slajd14

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.

Hurtownie danych czyli Systemy od historii”

Wczoraj mia­ła miej­sce kon­fe­ren­cja: Business Intelligence GigaCon 2011. Więcej tu: Hurtownie danych jako stan­dar­do­we modu­ły COTS (Commercial off the shelf) nowo­pro­jek­tow­nych sys­te­mów dedy­ko­wa­nych December 6th.

Poruszyłem mię­dzy inny­mi pro­ble­ma­ty­kę: aspek­ty pro­jek­to­we sys­te­mów dedy­ko­wa­nych i dosto­so­wy­wa­nych oraz ?core doma­in? i poję­cie COTS (Szczegółowe infor­ma­cje http://​giga​con​.org/​b​i​_​2​011).

Nie jest moim celem powie­la­nie tu refe­ra­tu, dla­te­go tyl­ko kil­ka kwe­stii a potem mała uwa­ga na temat metod argu­men­ta­cji osób rekla­mu­ją­cych swo­je pro­duk­ty, ale po kolei.

Hurtownia danych jako skład historii

W swo­im refe­ra­cie wska­za­łem na hur­tow­nie danych i meto­dy skła­do­wa­nia tam danych oraz na poję­cie sys­tem dedy­ko­wa­ny”. I tak:

  1. MIT: Oprogramowanie dedy­ko­wa­ne to kosz­tow­ne, dłu­go wyko­ny­wa­ne i ryzy­kow­ne, pro­jek­ty two­rze­nia opro­gra­mo­wa­nia od zera dla klienta,
  2. PRAWDA: Oprogramowanie dedy­ko­wa­ne to opro­gra­mo­wa­nie (System) zapro­jek­to­wa­ne na bazie dobrze opi­sa­nych wyma­gań, zło­żo­ne z kom­po­nen­tów (typo­we goto­we kom­po­nen­ty to ERP, CRM, SCM, inne).

To zna­czy, że doce­lo­wo – jako sys­tem dedy­ko­wa­ny – klient otrzy­ma zestaw zin­te­gro­wa­nych kom­po­nen­tów (pod­sys­te­mów, apli­ka­cji). Możliwe jest, że nie­któ­re zosta­ną opra­co­wa­ne i wyko­na­ne spe­cjal­nie dla nie­go. Pełny Zintegrowany System wspo­ma­ga­ją­cy zarzą­dza­nie (wszyst­kie apli­ka­cje w fir­mie) naj­czę­ściej nawet w 90% skła­da się z opro­gra­mo­wa­nia goto­we­go (COTS ? Commercial of the shelf).

Kolejnym mitem jest teza, że koszt inte­gra­cji jest duży. Powiem tak: zły pro­jekt zawsze koń­czy się wyso­ki­mi kosz­ta­mi, pro­jekt inte­gra­cyj­ny także.

Praktyka poka­zu­je, że popraw­nie posta­wio­ne wyma­ga­nia oraz pro­jekt wyko­na­ny przed wybo­rem roz­wią­za­nia, to naj­czę­ściej pro­jek­ty, w któ­rych kosz­ty inte­gra­cji są wie­lo­krot­nie niż­sze od kosz­tów kasto­mi­za­cji sys­te­mów zin­te­gro­wa­nych ERP i para­dok­sal­nie trwa to krócej.

Po trze­cie wdra­ża­nie eta­pa­mi (apli­ka­cja po apli­ka­cji) pozwa­la na to, by te poszcze­gól­ne pod­sys­te­my pra­co­wa­ły na sie­bie bez cze­ka­nia na cał­ko­wi­te zakoń­cze­nie wdro­że­nia cało­ści, jak to ma miej­sce naj­czę­ściej pod­czas wdra­ża­nia duże­go i zin­te­gro­wa­ne­go sys­te­mu. Warto tak­że zauwa­żyć, że taka – tak zwa­na kom­po­nen­to­wa – archi­tek­tu­ra jest łatwa w mody­fi­ka­cji (moż­li­wa jest wymia­na dowol­ne­go skład­ni­ka bez szko­dy dla innych cze­go nie moż­na powie­dzieć o dużych sys­te­mach ERP). Przykład z sys­te­ma­mi BI (Business Inteligence), któ­re będę tu zwał Raportowaniem.

Ogólnie wyma­ga­nia na sys­tem wspo­ma­ga­ją­cy zarzą­dza­nie maja taką strukturę:

Diagram Przypadek uzycia

Diagram jest pro­sty. Chcę zwró­cić uwa­gę na to, że wie­le funk­cjo­nal­no­ści (może nawet wszyst­kie) sys­te­mów wspo­ma­ga­ją­cych zarzą­dza­nie moż­na na takie dwie kate­go­rie podzie­lić. Przypomnę, że dia­gra­my przy­pad­ków uży­cia to nie pro­jek­ty sys­te­mu” a ich spis tre­ści”. Projektem, na wyso­kim pozio­mie abs­trak­cji (ang. HLD czy­li [[Hihg Level Design]]), jest dopie­ro to:

Model komponentow

Załóżmy, że archi­tekt sys­te­mu stwo­rzył powyż­szy model. Decyzja pro­jek­to­wa: sys­tem trans­ak­cyj­ny obsłu­gu­je naszą spe­cy­fi­kę biz­ne­so­wą, jest odpo­wie­dzią na wyma­ga­nie: Obsługa tego co się teraz dzie­je. Opracowano dokła­da­nie wyma­ga­nia, na ryn­ku nie zna­le­zio­no wyma­ga­nych funk­cjo­na­li­ści i ta część sys­te­mu zosta­nie wytworzona.

W ramach wyma­gań jed­nak, jak widać na poprzed­nim dia­gra­mie, mamy tak­że wyma­ga­nie: Pokaż co wyda­rzy­ło się kie­dyś. Są to funk­cjo­nal­no­ści rapor­to­we. Raportowanie jako funk­cja sys­te­mu jest dość dobrze opa­no­wa­na, są na ryn­ku goto­we pro­duk­ty (jest ich wie­le). Więc z pro­jek­tu deve­lo­per­skie­go (opro­gra­mo­wa­nie pro­jek­to­wa­ne) wyłą­czo­no ten zakres i kupio­no pod­sys­tem, popu­lar­nie zwa­ny hur­tow­nia danych. Większość tego typu apli­ka­cji ma bar­dzo dobre, uni­wer­sal­ne inter­fej­sy, więc ich inte­gra­cja nie sta­no­wi żad­ne­go problemu.

System trans­ak­cyj­ny, pro­jek­to­wa­ny, w ogó­le nie zaj­mu­je się histo­rią, prze­twa­rza wyłącz­nie dane bie­żą­ce dzię­ki cze­mu stał się znacz­nie prost­szy, czy­taj tań­szy w wyko­na­niu. Wszelkie dane o histo­rycz­nych sta­nach naszych danych są w hur­tow­ni danych a tę mamy już goto­wą, taniej niż koszt wytwo­rze­nia podob­ne­go systemu.

I tak: ta część, któ­ra opi­su­je spe­cy­fi­kę naszej orga­ni­za­cji (ozna­czo­na na nie­bie­sko), to tak zwa­ne core doma­in” czy­li głów­ny ele­ment dzie­dzi­ny sys­te­mu. Jeżeli nie znaj­dzie­my na ryn­ku pro­duk­tu, któ­ry w 100% mu odpo­wia­da nale­ży wydzie­lić taki frag­ment i stwo­rzyć sobie dedy­ko­wa­ny. Kastomizacja goto­we­go pro­duk­tu zawsze jest kom­pro­mi­sem, naj­czę­ściej bar­dzo kosz­tow­nym. (wię­cej o prak­ty­ce pro­jek­to­wa­nia zwa­nej DDD).

Pojecie [[COTS (Commercial off the shelf)]], o któ­rym już na blo­gu nie raz wspo­mi­na­łem, to tu nasz goto­wy kom­po­nent: hur­tow­nia danych. W efek­cie wszel­kie funk­cjo­nal­no­ści zwią­za­ne z rapor­to­wa­niem imple­men­tu­je­my w tej hur­tow­ni, pozo­sta­łe musi­my wytwo­rzyć. To dodat­ko­wa korzyść: baza danych sys­te­mu trans­ak­cyj­ne­go sta­je się dużo prost­sza, czy­taj tań­sza, bo model danych nie musi obsłu­gi­wać historii”.

Jeżeli potrzeb­ne nam zaawan­so­wa­ne meto­dy rapor­to­wa­nia i ana­liz nale­ży raczej zaku­pić apli­ka­cję z rodza­ju Business Inteligence zamiast zle­cać dostaw­cy sys­te­mu (np. ERP) kolej­ne imple­men­to­wa­nie wyra­fi­no­wa­nych – kosz­tow­nych w opra­co­wa­niu i utrzy­ma­niu – raportów.

Przy oka­zji: uży­cie hur­tow­ni danych w tle”, to nic inne­go jak clo­ud com­pu­ting :), tu tak zwa­na chmu­ra prywatna”.

Demagogia na konferencji

Z ust oso­by pro­mu­ją­cej pewien pro­dukt zali­czo­ny do Business Intelligence padło stwier­dze­nie: Nasz pro­dukt jest pro­sty, pobie­ra dane do rapor­tów bez­po­śred­nio z sys­te­mu ERP, nie musi­my więc dodat­ko­wo inwe­sto­wać w pośred­ni­czą­cy sys­tem hur­tow­ni danych, kto­ry może mieć dane nie­ak­tu­al­ne. Tezę tę miał poprzeć dia­gram podob­ny do tego:

Demagodia OLAP vs Proste BI

U góry mam skom­pli­ko­wa­ny sys­tem BI” a na dole nasz pro­sty i łatwy w obsłu­dze sys­tem”. To jak by usu­nąć zie­lo­ny kom­po­nent z powyż­sze­go dia­gra­mu kom­po­nen­tów. Gdzie haczyk? Ano tu:

Model danych ERP vs OLAP

Górny dia­gram to przy­kład mode­lu danych dla hur­tow­ni danych. Jest pro­sty, w prak­ty­ce sko­men­to­wa­ny po ludz­ku”, jako meta­da­ne, jest czymś, z czym może pra­co­wać każ­dy, kto tyl­ko zna daną dzie­dzi­nę, taki model danych (tak zwa­na gwiaz­da) odwzo­ro­wu­je w pro­sty spo­sób zna­ne biz­ne­so­we pojęcia.

Diagram niżej to model danych nie­wiel­kie­go sys­te­mu biz­ne­so­we­go (model danych sys­te­mu ERP, mają­cy nawet tysią­ce rela­cyj­nych, nic nie mówią­cych zwy­kłe­mu śmier­tel­ni­ko­wi tabel, był­by w tej pro­por­cji zwy­kłą kolo­ro­wą nie­czy­tel­ną pla­mą…). Wykonanie samo­dziel­nie jakie­go­kol­wiek rapor­tu z tego dru­gie­go sys­te­mu tabel gra­ni­czy z cudem. Można przy­go­to­wać (admi­ni­stra­tor bazy) tak zwa­ne wido­ki” dla użyt­kow­ni­ków co nie zmie­nia fak­tu, że ich opra­co­wa­nie to wie­dza tajem­na” i nikt z biz­ne­su” sam tego nie zro­bi. I naj­waż­niej­sze: dostęp do peł­ne­go mode­lu danych naj­czę­ściej wyma­ga zła­ma­nia zasad bez­pie­czeń­stwa to jest udo­stęp­nie­nia danych z pomi­nię­ciem mecha­ni­zmów kon­tro­l­nych apli­ka­cji ERP.

Hurtownia danych to model stwo­rzo­ny pod kątem prze­twa­rza­nia fak­tów histo­rycz­nych na pro­stym mode­lu danych (dia­gram powy­żej, gór­ny, to tak zwa­na kost­ka OLAP). Opracowanie takie­go mode­lu wyma­ga spe­cjal­nej ana­li­zy i pro­jek­tu, ale nie zapo­mi­naj­my: ana­li­zę się robi raz a rapor­ty sta­le… tu prze­szko­lo­ny użyt­kow­nik biz­ne­so­wy sam daje radę bez problemu.

Tak więc sza­now­ni Państwo. Jeśli tyl­ko Wasza fir­ma jest bli­żej czo­łów­ki niż ogo­na ran­kin­gu ryn­ku w Waszej bran­ży, nie daj­cie się namó­wić na jeden zin­te­gro­wa­ny ERP i jakiś model refe­ren­cyj­ny, bo nawet jak uda się go wdro­żyć, to zmia­na cze­go­kol­wiek będzie trud­na a upgra­de do now­szej wer­sji nie­moż­li­wy. Opracowanie pro­jek­tu sys­te­mu skła­da­ją­ce­go się z kom­po­nen­tów, pozwo­li Wam dobrać naj­le­piej speł­nia­ją­ce Wasze wyma­ga­nia apli­ka­cje. Jak z kloc­ków LEGO moż­na zło­żyć dedy­ko­wa­ny sys­tem” poma­ga­ją­cy utrzy­mać prze­wa­gę na ryn­ku, a nie cofa­ją­cy Waszą fir­mą do pozio­mu innych pod­mio­tów w bran­ży”.

Prognozowanie

Problem w tym, że z tych samych danych róż­ne fir­my ana­li­tycz­ne potra­fią wycią­gnąć róż­ne wnio­ski. Nie mam wąt­pli­wo­ści, że w naj­bliż­szych cza­sie cze­ka nas wysyp firm spe­cja­li­zu­ją­cych się w ana­li­zie danych pły­ną­cych z inter­ne­tu, ale póki co, wnio­ski są fru­stru­ją­ce: nie potra­fi­my wia­ry­god­nie prze­wi­dy­wać tren­dów ryn­ko­wych. (Piotr Podleśny, pre­zes fir­my Atena, źr. Prognozy wyma­ga­ją zro­zu­mie­nia danych – Computerworld).

Nauka wyka­za­ła, że sama ana­li­za danych histo­rycz­nie nie sta­no­wi żad­nej pro­gno­zy. Do tak zwa­nej pre­dyk­cji wyma­ga­ny jest model przed­mio­tu”, któ­re­go zacho­wa­nia chce­my prze­wi­dy­wać. Czy to moż­li­we? Tak. Czy to łatwe? Znowu odpo­wiem: nie. Potrzebny jest model a nie tyl­ko dane histo­rycz­ne (te pozwa­la­ją wyłącz­nie na ana­li­zę tego co było), wię­cej o tym w arty­ku­le o meto­dach nauko­wych ana­li­zy.

Knowledge Management – systemy wspomagające zarządzanie wiedzą GigaCon

Mamy przy­jem­ność zapro­sić Państwa na II edy­cję bez­płat­nej kon­fe­ren­cji, któ­ra jest szan­są na uzy­ska­nie lep­szych wyni­ków i prze­wa­gi nad konkurencją.

Konferencję Knowledge Management ? sys­te­my wspo­ma­ga­ją­ce zarzą­dza­nie wie­dzą GigaCon kie­ru­je­my do osób decy­du­ją­cych o spo­so­bie funk­cjo­no­wa­nia przed­się­bior­stwa, odpo­wie­dzial­nych za zarzą­dza­nie prze­pły­wem infor­ma­cji, zarzą­dza­nie wie­dzą oraz dobór roz­wią­zań i tech­no­lo­gii słu­żą­cych wspie­ra­niu tych pro­ce­sów; osób odpo­wie­dzial­nych za opty­mal­ne wyko­rzy­sta­nie posia­da­nych zaso­bów wiedzy.
Tematyka kon­fe­ren­cji:
- Systemy zarzą­dza­nia doku­men­ta­mi (docu­ment management)
- Systemy obie­gu pra­cy (work­flow)
- Systemy wspo­ma­ga­nia pra­cy gru­po­wej (gro­upwa­re)
- Hurtownie danych (data warehouse)
- Portale kor­po­ra­cyj­ne (enter­pri­se portals)
- Intranet – wewnętrz­ny internet
- Systemy wspo­ma­ga­nia decy­zji, sys­te­my ekspertowe
- Systemy do zarzą­dza­nia naucza­niem na odle­głość (e‑learning, wide­okon­fe­ren­cje, dyskusje
on-line)
- Systemy do zarzą­dza­nia bez­pie­czeń­stwem i ochro­na informacji
Nasza kon­fe­ren­cja przy­bli­ży suk­ces Państwa firmy.
WSTĘP BEZPŁATNY!
Rejestracja na stronie: 
Partner kon­fe­ren­cji:
DYSANT Software
Firmy zain­te­re­so­wa­ne pre­zen­ta­cją roz­wią­zań pod­czas kon­fe­ren­cji pro­si­my o kon­takt z organizatorem.
Kontakt:
Sławomir Krajewski
tel. 22/427 32 82
slawomir.krajewski@software.com.pl

Konferencja DATA CENTER & STORAGE GigaCon ? Systemy baz danych oraz pamięci masowe dla przedsiębiorstw

Opis wydarzenia

Zapraszamy Państwa ser­decz­nie do udzia­łu w bez­płat­nej kon­fe­ren­cji poświę­co­nej tech­no­lo­giom, śro­do­wi­skom i narzę­dziom gwa­ran­tu­ją­cym nie­za­wod­ny i bez­piecz­ny dostęp do baz danych oraz zagad­nie­niom teo­re­tycz­nym i prak­tycz­nym zwią­za­nym z archi­tek­tu­rą i funk­cją pamię­ci masowych.

Proponowane sesje tematyczne:

- Usługi DataCenters
– Serwery baz danych dla DataCenter
– Systemy ope­ra­cyj­ne dla DataCenters
– Zarządzanie DataCenters
– Integracja baz danych, trans­fer danych
– Wydajne ser­we­ry i kla­stry dla DataCenters
– Bezpieczeństwo DataCenters
– Hurtownie danych
– Datamining
– Wirtualizacja serwerów
– Zalety i zasto­so­wa­nie archi­tek­tur sto­ra­ge: SAN i NAS
– Macierze dys­ko­we, stre­ame­ry, biblio­te­ki taśmo­we, autoloadery
– Składowanie, repli­ka­cja i inte­gral­ność sys­te­mów storage?owych
– Rozwiązania klastrowe
– Analiza potrzeb storage
– Ciągłość pro­wa­dze­nia biz­ne­su. disa­ster recovery
– Mobilne sys­te­my storage?owe
– Bezpieczeństwo, wydaj­ność, ska­lo­wal­ność i odpor­ność na kata­stro­fy sys­te­mów storage?owych
– Zarządzanie sprzę­tem i opro­gra­mo­wa­niem storage
– Backup i archi­wi­za­cja danych
– Nowe tren­dy na ryn­ku pamię­ci masowych

Konferencja skie­ro­wa­na jest do sze­ro­kie­go krę­gu odbior­ców wyko­rzy­stu­ją­cych lub zamie­rza­ją­cych wdra­żać oma­wia­ne tech­no­lo­gie i narzę­dzia. Osoby, któ­re zapra­sza­my do udzia­łu to oso­by z bran­ży infor­ma­tycz­nej, ban­ko­wej i finan­so­wej, prze­my­słu, tele­ko­mu­ni­ka­cji, ubez­pie­czeń, han­dlu oraz administracji.

Dodatkowe infor­ma­cje na stronie 

agen­da:

GigaCon Systemy dla przedsiębiorstw ? konferencja dzień drugi

Konferencja i reflek­sje po refe­ra­tach czy­li o czym mówio­no i jakie myśli mi się po tym nasu­nę­ły. Mówiono o sys­te­mach wspo­ma­ga­ją­cych zarzą­dza­nie fir­mą, obie­giem doku­men­tów czy prze­pły­wem pra­cy. Z wie­lu powo­dów, nie będę tu jed­nak pisał o kon­kret­nych pre­le­gen­tach czy mar­kach dostaw­ców, no chy­ba, ze fak­tycz­nie będzie to war­te pokazania ;).

Czytaj dalej… GigaCon Systemy dla przed­się­biorstw ? kon­fe­ren­cja dzień dru­gi”