Z bada­nia prze­pro­wa­dzo­ne­go na zle­ce­nie fir­my Informatica wyni­ka, że sta­ty­stycz­nie aż w 86 proc. firm dostęp do śro­do­wisk bazo­da­no­wych mają pra­cow­ni­cy dzia­łów biz­ne­so­wych. W co trze­ciej fir­mie dostęp do śro­do­wisk bazo­da­no­wych nie jest w żaden spo­sób ogra­ni­cza­ny – pra­wa dostę­pu i mody­fi­ka­cji infor­ma­cji zapi­sa­nych w bazie danych mają wszy­scy pra­cow­ni­cy. Jednocześnie w wie­lu fir­mach funk­cjo­nu­je wie­le odręb­nych baz danych, czę­sto nie­ob­ję­tych kor­po­ra­cyj­ną poli­ty­ką bez­pie­czeń­stwa. Własnym śro­do­wi­skiem bazo­da­no­wym naj­czę­ściej dys­po­nu­ją dzia­ły sprze­da­ży i mar­ke­tin­gu. Bazy danych stwo­rzo­ne i zarzą­dza­ne przez pra­cow­ni­ków dzia­łów han­dlo­wych i mar­ke­tin­go­wych funk­cjo­no­wa­ły aż w 94 proc. ana­li­zo­wa­nych firm. Średnio w jed­nej fir­mie funk­cjo­nu­je dzie­więć róż­nych śro­do­wisk bazo­da­no­wych, któ­ry­mi zazwy­czaj zarzą­dza­ją inne oso­by. W fir­mach zatrud­nia­ją­cych wię­cej niż 1000 osób ilość funk­cjo­nu­ją­cych rów­no­le­gle baz danych jest jesz­cze wyż­sza. (źr. IDG).

Po prze­czy­ta­niu tego arty­ku­łu przy­po­mnia­łem sobie pewien pro­jekt ale po kolei.

Mógłby ktoś powie­dzieć, że to (wie­le baz i wie­lu upraw­nio­nych) sztucz­ny pro­blem bo jakoś z tym żyje­my”. Jednak oka­zu­je się, że po pew­nym czasie …

Krótka historyjka.

Swego cza­su zatrud­nio­no mnie do pro­jek­tu zwią­za­ne­go z mode­lo­wa­niem (tak to zosta­ło nazwa­ne) ist­nie­ją­ce­go sys­te­mu”. Celem było udo­ku­men­to­wa­nie archi­tek­tu­ry logicz­nej i powią­za­nych z nią zaso­bów oraz przy­po­rząd­ko­wa­nie funk­cji biz­ne­so­wych (ele­men­tów pro­ce­sów biz­ne­so­wych) do poszcze­gól­nych apli­ka­cji. Nie roz­wo­dząc się, oka­za­ło się wręcz nie moż­li­we w cza­sie jaki zapla­no­wa­no na te pra­cę. System IT w tej fir­mie rósł wraz z nią. Informatycy pro­gra­mi­ści, na pole­ce­nie zarzą­du, dopi­sy­wa­li ad-hoc kolej­ne użyt­ki”, robi­li to pod pre­sją cza­su (nowe pro­duk­ty, kolej­ne pro­mo­cje, wszyst­ko na wczo­raj). Po pew­nym cza­sie, jak­kol­wiek wia­do­mo było jakie pro­gra­my są (dosta­łem ich spe­cy­fi­ka­cję), nikt nie wie­dział co jest z czym powią­za­ne, gdzie i na czym. O wie­dzy na temat upraw­nień w tych wza­jem­nych połą­cze­niach (funk­cje dopi­sy­wa­ne albo w pro­ce­du­rach bazy danych wbu­do­wa­nych, albo w roz­wi­ja­nych apli­ka­cjach, wza­jem­ne odwo­ła­nia po ODBC czy bez­po­śred­nio do bazy) nie wspo­mnę, takie pyta­nie było tam tabu.

Po co ten model? Otóż w w trak­cie było wdro­że­nie sys­te­mu CRM, któ­ry miał to upo­rząd­ko­wać, zastą­pić znacz­ną część tych drob­nych sys­te­mów” ale nie wszyst­kie. Pytanie brzmia­ło: co i w jakiej kolej­no­ści moż­na wyłą­czać i zastę­po­wać nowy­mi modu­ła­mi sys­te­mu CRM? Powiem tak: nie uda­ło się. Bardzo dłu­go (nie znam koń­ca wdro­że­nia) nie uda­ło się przejść na nowy CRM.

Szkodliwe oferty

Drugim, poza powyż­szym, powo­dem nara­sta­ją­ce­go bała­ga­nu (to się nazy­wa spa­get­ti sys­tems) jest cza­sa­mi wręcz szko­dli­wa dzia­łal­ność dostaw­ców róż­ne­go rodza­ju sys­te­mów rapor­to­wa­nia, BI, roz­bu­do­wa­nych makr do arku­szy kal­ku­la­cyj­nych itp. Pada magicz­ne i nie­win­ne pyta­nie pro­szę mi podać jakiś login i hasło do bazy danych finan­so­wych to poka­że Pani jak moż­na robić ana­li­zy danych”, to jest bar­dzo tani, dużo tań­szy od hur­tow­ni danych, tak­że bar­dzo dobry sys­tem Business Intelligence”. Często nabyw­ca­mi tych roz­wią­zań są mene­dże­ro­wie, więc ich proś­by hasło i login do bazy pro­szę” raczej nie zno­szą sprze­ci­wu”. W efek­cie mamy to co opi­sał dzien­ni­karz IDG.

Inny cytat: Prawie trzy czwar­te bada­nych (72%) przy­zna­ło się do tego, że wyno­szą z fir­my nale­żą­ce do niej dane. Najchętniej przy­własz­cza­ne są dane oso­bo­we klien­tów (robi to 26% bada­nych), doku­men­ty dzia­łu HR i dane mar­ke­tin­go­we (po 25% bada­nych). Co dzie­sią­ty, jeśli tyl­ko ma oka­zję, krad­nie z fir­my listy osób mają­cych stra­cić pra­cę. Metody kra­dzie­ży nie są skom­pli­ko­wa­ne. 23% osób zapi­su­je je na kar­tach pamię­ci i lap­to­pach. Kolejne 13% uży­wa do tego urzą­dzeń prze­no­śnych. (źr. IDG).

To wyno­sze­nie jest moż­li­we głów­nie i tyl­ko dla­te­go, że pra­cow­nik ma bez­po­śred­ni dostęp do danych (pli­ki, dostęp do ser­we­ra, itp.). Jeżeli dane są udo­stęp­nia­ne wyłącz­nie przez apli­ka­cję, któ­ra je prze­twa­rza, szyb­kie i nie­zau­wa­żo­ne sko­pio­wa­nie setek czy tysię­cy rekor­dów o klien­tach czy pra­cow­ni­kach jest nie­moż­li­we. Po dru­gie więk­szość apli­ka­cji ma moż­li­wość zapi­sy­wa­nia wszyst­kie­go tego co i kto w niej robi, sama ta świa­do­mość powstrzy­mu­je nie­jed­ne­go zło­dzie­ja danych.

Jak to wygląda?

To co spo­ty­kam często:

metody dostepu do danych - notacja ArchiMate
Diagram meto­dy dostę­pu do danych – przykład

Po kolei. Każdy pro­ces biz­ne­so­wy ma jakie­goś wła­ści­cie­la (nie zawsze for­mal­nie ale zawsze jest ktoś kto obe­rwie” jak coś się tu nie uda ;)). Rolą wła­ści­cie­la pro­ce­su jest podej­mo­wa­nie decy­zji i robi ktoś kon­kret­ny ze struk­tu­ry orga­ni­za­cyj­nej (jakiś kon­kret­ny menedżer).

Do bie­żą­cej pra­cy wyko­rzy­stu­je on rapor­ty dostęp­ne np. we wdro­żo­nym sys­te­mie ERP. Pojawia się nagle ktoś z ofer­tą na super sys­tem BI, tani i sku­tecz­ny, trze­ba tyl­ko się pod­łą­czyć do bazy tego ERP”. Wariant wła­ści­wy (jeśli już pod­łą­cza­my się do tej bazy a nie two­rzy­my pośred­niej np. hur­tow­ni danych) powi­nien pole­gać na ich pobie­ra­niu za pośred­nic­twem apli­ka­cji zarzą­dza­ją­cej tymi dany­mi, tu jest to nasz ERP. Powinien powstać (powin­no się użyć ist­nie­ją­ce­go) inter­fejs (na dia­gra­mie kul­ka w kie­lisz­ku pomię­dzy ERP a pro­gra­mem ana­li­tycz­nym :)) . To jed­nak wyma­ga małe­go pro­jek­tu” a po dru­gie od razu wyj­dzie na jaw, że ktoś kupu­je taki pro­gram analityczny”.

Co wiec się robi? Łamiąc zasa­dy pod­pi­na­my” pro­gram ana­li­tycz­ny bez­po­śred­nio do danych (linia prze­ry­wa­na pro­gram ana­li­tycz­ny Baza Danych). Na wszel­ki wypa­dek, żeby nie wie­szał się, daje­my mu naj­więk­sze moż­li­we upraw­nie­nia (dobrze gdy tyl­ko do odczy­tu) i z gło­wy. Efekt? Po kil­ku latach w dużych fir­mach nikt nie wie kto i do cze­go ma dostęp.

Architektura Korporacyjna

Wdrożenie hur­tow­ni danych i sys­te­mu BI to nie tyl­ko rapor­ty itp. ale wła­śnie cen­tra­li­za­cja dostę­pu do danych i pano­wa­nie nad tym kto do cze­go ma dostęp. W małej fir­mie, gdzie naj­czę­ściej taki pro­ga­mik ana­li­tycz­ny jest jeden i zain­sta­lo­wa­ny za czy­jąś zgo­dą, nie ma duże­go pro­ble­mu, w więk­szych fir­mach sta­no­wi to poważ­ne zagro­że­nie. To kolej­ny powód by prze­strze­gać zasad pro­jek­to­wa­nia archi­tek­tu­ry, mimo tego, że wie­lu admi­ni­stra­to­rów i nie tyl­ko, uwa­ża, że to utrud­nia­nie spraw­ne­go działania”.

Powyższy dia­gram uprosz­czo­ny, to namiast­ka wła­śnie cze­goś co nazy­wa się archi­tek­tu­rą kor­po­ra­cyj­ną ([[dia­gram wyko­na­ny w nota­cji ArchiMate, sto­so­wa­nej do doku­men­to­wa­nia archi­tek­tu­ry kor­po­ra­cyj­nej]]). Nie cho­dzi o to by nary­so­wać każ­dy szcze­gół, cho­dzi o to by jed­nak wie­dzieć co się ma i co z czym jest powią­za­ne. To kosz­tow­ne i po co? Między inny­mi po to by w dowol­nym momen­cie moż­na było powie­dzieć czy i jak coś moż­na zmie­nić. Mogę osza­co­wać ile powyż­sza fir­ma oszczę­dzi­ła na popraw­nym pro­jek­to­wa­niu poprze­dza­ją­cym imple­men­ta­cje i two­rze­niu doku­men­ta­cji. Mogę tak­że osza­co­wać ile stra­ci­ła na kil­ku­let­nim opóź­nie­niu wdro­że­niu sys­te­mu CRM, któ­ry kupi­ła, i wiem, że ten dru­gi koszt wie­lo­krot­nie prze­rósł pier­wot­ne oszczęd­no­ści na pano­wa­niu nad roz­wo­jem i sys­te­mu i jego doku­men­ta­cji, któ­rej po pro­tu nie było.

Kto za to odpowiada?

Nie sądzę by miał to być jakiś infor­ma­tyk, sądzę, że ktoś powi­nien być obcią­żo­ny odpo­wie­dzial­no­ścią za całą logi­kę pro­ce­sów i zaso­bów IT je wspie­ra­ją­cych. Im bar­dziej ta wie­dza będzie roz­pro­szo­na (pio­na­mi, dzie­dzi­no­wo itp.) tym więk­sze ryzyko,że coś pój­dzie nie tak”. Jakakolwiek inge­ren­cja w ist­nie­ją­cy sys­tem lub osza­co­wa­nie skut­ków (ana­li­za ryzy­ka) jakiejś uster­ki (np. awa­ria UPS’a) może być łatwe, przy cen­tral­nym zarzą­dza­niu archi­tek­tu­rą kor­po­ra­cyj­ną. Przy roz­pro­sze­niu tej wie­dzy, każ­da decy­zja będzie wyma­ga­ła wręcz burzy mózgów, a i tak będzie obło­żo­na nie małym ryzy­kiem. Centralizacja tej wie­dzy to nie koniecz­nie sto­sow­ny etat”, to może być po pro­tu aktu­ali­zo­wa­na dokumentacja.

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.