Z badania przeprowadzonego na zlecenie firmy Informatica wynika, że statystycznie aż w 86 proc. firm dostęp do środowisk bazodanowych mają pracownicy działów biznesowych. W co trzeciej firmie dostęp do środowisk bazodanowych nie jest w żaden sposób ograniczany – prawa dostępu i modyfikacji informacji zapisanych w bazie danych mają wszyscy pracownicy. Jednocześnie w wielu firmach funkcjonuje wiele odrębnych baz danych, często nieobjętych korporacyjną polityką bezpieczeństwa. Własnym środowiskiem bazodanowym najczęściej dysponują działy sprzedaży i marketingu. Bazy danych stworzone i zarządzane przez pracowników działów handlowych i marketingowych funkcjonowały aż w 94 proc. analizowanych firm. Średnio w jednej firmie funkcjonuje dziewięć różnych środowisk bazodanowych, którymi zazwyczaj zarządzają inne osoby. W firmach zatrudniających więcej niż 1000 osób ilość funkcjonujących równolegle baz danych jest jeszcze wyższa. (źr. IDG).

Po przeczytaniu tego artykułu przypomniałem sobie pewien projekt ale po kolei.

Mógłby ktoś powiedzieć, że to (wiele baz i wielu uprawnionych) sztuczny problem bo „jakoś z tym żyjemy”. Jednak okazuje się, że po pewnym czasie …

Krótka historyjka.

Swego czasu zatrudniono mnie do projektu związanego z modelowaniem (tak to zostało nazwane) „istniejącego systemu”. Celem było udokumentowanie architektury logicznej i powiązanych z nią zasobów oraz przyporządkowanie funkcji biznesowych (elementów procesów biznesowych) do poszczególnych aplikacji. Nie rozwodząc się, okazało się wręcz nie możliwe w czasie jaki zaplanowano na te pracę. System IT w tej firmie rósł wraz z nią. Informatycy programiści, na polecenie zarządu, dopisywali ad-hoc kolejne „użytki”, robili to pod presją czasu (nowe produkty, kolejne promocje, wszystko na wczoraj). Po pewnym czasie, jakkolwiek wiadomo było jakie programy są (dostałem ich specyfikację), nikt nie wiedział co jest z czym powiązane, gdzie i na czym. O wiedzy na temat uprawnień w tych wzajemnych połączeniach (funkcje dopisywane albo w procedurach bazy danych wbudowanych, albo w rozwijanych aplikacjach, wzajemne odwołania po ODBC czy bezpośrednio do bazy)  nie wspomnę, takie pytanie było tam tabu.

Po co ten model? Otóż w w trakcie było wdrożenie systemu CRM, który miał to uporządkować, zastąpić  znaczną część tych „drobnych systemów” ale nie wszystkie. Pytanie brzmiało: co i w jakiej kolejności można wyłączać i zastępować nowymi modułami systemu CRM? Powiem tak: nie udało się. Bardzo długo (nie znam końca wdrożenia) nie udało się przejść na nowy CRM.

Szkodliwe oferty

Drugim, poza powyższym, powodem narastającego bałaganu (to się nazywa spagetti systems) jest czasami wręcz szkodliwa działalność dostawców różnego rodzaju systemów raportowania, BI, rozbudowanych makr do arkuszy kalkulacyjnych itp. Pada magiczne i niewinne pytanie „proszę mi podać jakiś login i hasło do bazy danych finansowych to pokaże Pani jak można robić analizy danych”, „to jest bardzo tani, dużo tańszy od hurtowni danych, także bardzo dobry system Business Intelligence”. Często nabywcami tych rozwiązań są menedżerowie, więc ich prośby „hasło i login do bazy proszę” raczej „nie znoszą sprzeciwu”. W efekcie mamy to co opisał dziennikarz IDG.

Inny cytat: Prawie trzy czwarte badanych (72%) przyznało się do tego, że wynoszą z firmy należące do niej dane. Najchętniej przywłaszczane są dane osobowe klientów (robi to 26% badanych), dokumenty działu HR i dane marketingowe (po 25% badanych). Co dziesiąty, jeśli tylko ma okazję, kradnie z firmy listy osób mających stracić pracę. Metody kradzieży nie są skomplikowane. 23% osób zapisuje je na kartach pamięci i laptopach. Kolejne 13% używa do tego urządzeń przenośnych. (źr. IDG).

To wynoszenie jest możliwe głównie i tylko dlatego, że pracownik ma bezpośredni dostęp do danych (pliki, dostęp do serwera, itp.). Jeżeli dane są udostępniane wyłącznie przez aplikację, która je przetwarza, szybkie i niezauważone skopiowanie setek czy tysięcy rekordów o klientach czy pracownikach jest niemożliwe. Po drugie większość aplikacji ma możliwość zapisywania wszystkiego tego co i kto w niej robi, sama ta świadomość powstrzymuje niejednego złodzieja danych.

Jak to wygląda?

To co spotykam często:

Po kolei. Każdy proces biznesowy ma jakiegoś właściciela (nie zawsze formalnie ale zawsze jest ktoś kto „oberwie” jak coś się tu nie uda ;)). Rolą właściciela procesu jest podejmowanie decyzji i robi ktoś konkretny ze struktury organizacyjnej (jakiś konkretny menedżer).

Do bieżącej pracy wykorzystuje on raporty dostępne np. we wdrożonym systemie ERP. Pojawia się nagle ktoś z ofertą na „super system BI, tani i skuteczny, trzeba tylko się podłączyć do bazy tego ERP”. Wariant właściwy (jeśli już podłączamy się do tej bazy a nie tworzymy pośredniej np. hurtowni danych) powinien polegać na ich pobieraniu za pośrednictwem aplikacji zarządzającej tymi danymi, tu jest to nasz ERP. Powinien powstać (powinno się użyć istniejącego) interfejs (na diagramie kulka w kieliszku pomiędzy ERP a programem analitycznym :)) .  To jednak wymaga małego „projektu” a po drugie od razu wyjdzie na jaw, że ktoś kupuje taki „program analityczny”.

Co wiec się robi? Łamiąc zasady „podpinamy” program analityczny bezpośrednio do danych (linia przerywana program analityczny Baza Danych). Na wszelki wypadek, żeby nie wieszał się, dajemy mu największe możliwe uprawnienia (dobrze gdy tylko do odczytu) i z głowy. Efekt? Po kilku latach w dużych firmach nikt nie wie kto i do czego ma dostęp.

Architektura Korporacyjna

Wdrożenie hurtowni danych i systemu BI to nie tylko raporty itp. ale właśnie centralizacja dostępu do danych i panowanie nad tym kto do czego ma dostęp. W małej firmie, gdzie najczęściej taki progamik analityczny jest jeden i zainstalowany za czyjąś zgodą, nie ma dużego problemu, w większych firmach stanowi to poważne zagrożenie. To kolejny powód by przestrzegać zasad projektowania architektury, mimo tego, że wielu administratorów i nie tylko, uważa,  że „to utrudnianie sprawnego działania”.

Powyższy diagram uproszczony, to namiastka właśnie czegoś co nazywa się architekturą korporacyjną ([[diagram wykonany w notacji ArchiMate, stosowanej do dokumentowania architektury korporacyjnej]]). Nie chodzi o to by narysować każdy szczegół, chodzi o to by jednak wiedzieć co się ma i co z czym jest powiązane. To kosztowne i po co? Między innymi po to by w dowolnym momencie można było powiedzieć czy i jak coś można zmienić. Mogę oszacować ile powyższa firma oszczędziła na poprawnym projektowaniu poprzedzającym implementacje i tworzeniu dokumentacji. Mogę także oszacować ile straciła na kilkuletnim opóźnieniu wdrożeniu systemu CRM, który kupiła, i wiem, że ten drugi koszt wielokrotnie przerósł pierwotne oszczędności na panowaniu nad rozwojem i systemu i jego dokumentacji, której po protu nie było.

Kto za to odpowiada?

Nie sądzę by miał to być jakiś informatyk, sądzę, że ktoś powinien być obciążony odpowiedzialnością za całą logikę procesów i zasobów IT je wspierających. Im bardziej ta wiedza będzie rozproszona (pionami, dziedzinowo itp.) tym większe ryzyko,że „coś pójdzie nie tak”. Jakakolwiek ingerencja w istniejący system lub oszacowanie skutków (analiza ryzyka) jakiejś  usterki (np. awaria UPS’a) może być łatwe, przy centralnym zarządzaniu architekturą korporacyjną.  Przy rozproszeniu tej wiedzy, każda decyzja będzie wymagała wręcz burzy mózgów, a i tak będzie obłożona nie małym ryzykiem. Centralizacja tej wiedzy to nie koniecznie stosowny „etat”, to może być po protu aktualizowana dokumentacja.