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 liczba 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 syste- mu”. Celem było udokumentowanie architektury logicznej i powiązanych z nią zasobów oraz przyporządkowanie funkcji biznesowych (elementów procesów biznesowych) do po- szczególnych aplikacji. Nie rozwodząc się, okazało się to wręcz niemożliwe w czasie, jaki zaplanowano na tę 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 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 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 spaghetti systems) jest czasami wręcz szkodliwa działalność dostawców różnego rodzaju systemów rapor- towania, BI, rozbudowanych makr do arkuszy kalkulacyjnych itp. Pada magiczne i niewinne polecenie: „Proszę mi podać jakiś login i hasło do bazy danych finansowych, to pokażę 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.
Jak to wygląda? To co spotykam często (diagram obok):
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 „supersystem 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 więc 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 (do- brze, 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 programik 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 że wielu admini- stratoró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 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 prostu 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 niemałym ryzykiem. Centralizacja tej wiedzy to niekoniecznie stosowny „etat”, to może być po prostu aktualizowana dokumentacja. ◊
it-consulting.pl