Analiza bez analizy

Niedoceniane metadane

Niedawno dostawcy zaczęli forsować nową koncepcję, którą nazywają Master Data Management (MDM). Przyświeca jej założenie, że firma utrzymuje centralne repozytorium, zawierające wszystkie informacje dotyczące znaczenia poszczególnych danych. Są to klasyczne metadane, a oprócz nich także procedury związane z transformacją (procesem ETL), audytem itp.

Wypada podkreślić, że nie chodzi tutaj o procedury, które dokonają agregacji informacji, ale raczej o narzędzia pozwalające opisać poszczególne zasoby i procedury pozyskiwania określonych wartości (formuły wyliczeniowe, miejsce i znaczenie poszczególnych składników wyliczeń). W ten sposób można określić pewne grupy pojęciowe i wskazać, w których miejscach infrastruktury znajdują się odpowiednie dane.

Zarówno Business Object, IBM, Microsoft, jak i SAS oferują rozwiązania, w których raport budowany jest na pewnych abstrakcyjnych pojęciach - w oderwaniu od danych, tak by można było dostarczyć rozwiązania niezależne od technologii bazodanowej. W rozwiązaniu SAS serwer metadanych zawiera instrukcję, w jaki sposób pobrać sumę zleceń w zadanym okresie z systemu źródłowego, nazwać ją i udostępnić kolejnym warstwom systemu BI.

Rozwiązania mają jednak pewną wadę: kopię wyliczonej informacji trzeba gdzieś na chwilę przechować. Dochodzi wtedy do sytuacji, gdy narzędzie analityczne uzyskuje dane, co do aktualności których nie można mieć 100% pewności. Problem ten producenci platform BI próbują rozwiązać w ten sposób, że oprócz przepisu na wyliczenie określonej wartości można zdefiniować warunek sprawdzający, czy dane uległy zmianie od momentu zlecenia operacji. Tego typu rozwiązania ma Oracle czy BEA w ramach narzędzi AquaLogic. Nie każda platforma daje taką możliwość i często jedynym rozsądnym mechanizmem jest wykorzystanie parametru czasu ważności zapytania (timeout).

Nie widać tendencji czy zabiegów standaryzacyjnych, które miałyby na celu stworzenie wspólnej warstwy metadanych operacyjnych. Być może popularyzacja architektury SOA i przemodelowanie struktury aplikacji sprawi, że łatwiej będzie zarządzać metadanymi. Może. Na razie jedynym sposobem na uzyskanie pełnego opisu metadanych jest szczegółowe dokumentowanie zmian w systemach. Dedykowany serwer metadanych może to tylko ułatwić.

W krainie wskaźników

Baza OLAP jest wielowymiarową reprezentacją danych pochodzących z hurtowni danych lub z baz transakcyjnych. W odróżnieniu od struktur relacyjnych, gdzie obowiązuje zasada, iż staramy się nie powielać informacji w różnych tabelach, OLAP (podobnie jak hurtownia danych) właśnie dzięki redundancji pozwala szybciej działać określonym zapytaniom. Równocześnie przy generowaniu struktury można określić wymiary, według których analizowane będą dane. Na przykład informacje o wartości sprzedaży mogą być rozbite według regionu, czasu (z określoną hierarchią) i sieci sklepów i produktu.

Na tym etapie zaczynają się uwidaczniać różnice w filozofiach produktów różnych producentów, z czego wynika wiele niuansów przekładających się na rzeczywistą użyteczność rozwiązań. Mechanizm tworzenia własnych hierarchii pozwoli np. odwzorować dowolną strukturę firmy czy regionów sprzedaży, ale nie w każdej platformie mechanizm ten jest bardzo elastyczny. Jeżeli firma ma niestandardowe okresy rozliczeniowe, warto upewnić się, czy można definiować dowolne hierarchie czasowe.

Kolejna sprawa: gdy powstaje struktura OLAP, pewne informacje znajdą się poza podstawową strukturą, ale warto zapewnić użytkownikowi odwołanie się do nich, jeśli uzna to za potrzebne (nawet w formie zagregowanej). Niemal wszystkie zestawienia generowane na podstawie kostek OLAP mogą powstać w "czystym" SQL-u. Ale dzięki specjalnej strukturze danych i gotowym agregatom kostka wygeneruje zestawienie natychmiast. To samo zestawienie serwer transakcyjny będzie liczył znacznie dłużej, czasem nawet 100 razy!

Kolejnym istotnym elementem związanym z analizą są tzw. wskaźniki KPI (Key Performance Indicator) opisujące w syntetyczny sposób kondycję firmy w określonym obszarze. Do wyliczenia wskaźnika wykorzystywane są dane z wielu obszarów, czasami z różnych systemów informatycznych. Podstawowe pytanie brzmi: czy ostatnie zasilenie hurtowni czy kostki powoduje konieczność przeliczenia wskaźnika KPI, a jeżeli tak, to jak zrobić to jak najszybciej?

Warto też zadbać o to, aby istniała możliwość przejścia od "suchego" wskaźnika do danych, na podstawie których został wyliczony, jeśli wartość wskaźnika okaże się daleka od wartości oczekiwanej.

Szukanie zamiast analizy

Dane pobierane automatycznie z hurtowni czy kostek niosą w sobie tylko pewien wycinek informacji o tym, co dzieje się w firmie. Znacznie więcej informacji znajduje się zwykle w rozmaitych dokumentach, arkuszach kalkulacyjnych, umowach itp. Niestety, to źródło danych z założenia nie ma określonej struktury.

Wprowadzenie formatów dokumentów biurowych, które będą opierać się na XML, uproszczą sposób automatycznej obróbki takiej informacji, ale nawet Open-XML czy ODF nie wskaże, w którym akapicie znajduje się ostateczna kwota, jaką obejmuje dana umowa. Nie pokaże też komórki zawierającej sumę kosztów w bilansie. Do tego dochodzą informacje jakościowe, zwykle nieostre, ale istotne. O tym, czy podpisany kontrakt jest dobry, czy zły dla firmy może wypowiedzieć się prawnik, bo wnioskowanie automatyczne na podstawie jej treści na niewiele się zda.

Na to wszystko nakłada się problem związany z miejscem zapisu dokumentu. Co prawda coraz więcej portali firmowych jest automatycznie centralnym repozytorium plików, ale czasami tych portali jest kilka, działy tworzą odrębne serwery plików, czy nawet ostateczna wersja dokumentu znajduje się jedynie na laptopie pracownika tylko okresowo synchronizującego swoje dane z centralnym repozytorium.

Do przeszukiwania zasobów dokumentowych można użyć narzędzi typu Desktop Search lub działających w skali całej firmy rozwiązań wyszukiwawczych uwzględniających uprawnienia użytkowników, klasyfikację informacji itp. Zasięg wyszukiwania może być różny - od przeszukiwania indeksów pełnotekstowych portalu wewnętrznego, po przeszukiwanie wszystkich dostępnych zasobów. Takim rozwiązaniem jest Google Search Appliance, rozwiązanie sprzętowo-programowe, które po podłączeniu do sieci analizuje zawartość korporacyjnych zasobów, przy czym nie jest to jedynie proste "indeksowanie" zawartości plików.

W ramach projektu OneBox for Enterprise Google udostępnił interfejsy API pozwalające klientom dodawać własne mechanizmy do jego rozwiązań sprzętowo-programowych. Pozwala to wskazać źródła danych, określić sposób prezentacji wyników wyszukiwań, a przede wszystkim - zdefiniować sposób interpretowania poszczególnych fragmentów zapytania oraz jak mają być konstruowane zapytania. Na marginesie warto dodać, że ten mechanizm daje znacznie większe możliwości niż proste filtry do wyszukiwania w treści plików w danym formacie obecne w rozwiązaniach Desktop Search.

Firma Business Object ogłosiła, że Google będzie korzystać z jej mechanizmów do wyszukiwania danych - zarówno w rozwiązaniach sprzętowo-programowych Google Search Appliance, jak i w oprogramowaniu Google Desktop Search. Business Objects chce także stworzyć mechanizm pozwalający na wyszukiwanie informacji w raportach Crystal Reports i Web Intelligence. Analogiczne rozwiązania będą oferować lub wkrótce zaoferują m.in. Salesforce.com, Oracle (tylko wyszukiwanie zamówień) czy Cognos. Prowadzi to do tego, że wpisując frazę w wyszukiwarce w tle uruchamia się proces analizy BI. Co ciekawe, dostępne są też rozwiązania wyszukujące informacje w bazach Microsoft Exchange.

Podobne rozwiązanie oferuje IBM. Pod koniec maja br. firma udostępniła narzędzie, które łączy mechanizmy wyszukiwania w zasobach przedsiębiorstwa z raportami i analizami BI. WebSphere Content Discovery for Business Intelligence jest z jednej strony mechanizmem, za pomocą którego można przeszukiwać dane generowane przez system BI, a z drugiej - rozwiązaniem pozwalającym wykonać procedury text mining, czyli analizę danych bez formalnej struktury. WebSphere Content Discovery for BI pozwala też zadawać zapytania ad hoc do systemów BI bez formalnego tworzenia raportu i konieczności uczenia się, jak taki raport zbudować.

Nieusuwalny "interfejs białkowy"

Automatyczna analiza kondycji firmy jest możliwa tylko w zakresie przewidzianym przez konkretne rozwiązanie, a dokładniej, to co zostało opracowane w ramach wdrożenia. Tzw. interfejs białkowy jest w praktyce nie do zastąpienia. Można agregować automatycznie dane, tworzyć rozbudowane zestawienia, definiować wskaźniki KPI, ale... do wysnuwania daleko posuniętych wniosków wciąż najlepszy jest człowiek.

Człowiek sprawdza się zwłaszcza w sytuacjach nieoczekiwanych, gdy pozornie wszystko przebiega prawidłowo, ale kierownictwo przeczuwa, że firma ma problemy. Zewnętrzny analityk i arkusz Excela są najlepszym możliwym systemem BI i systemem wspomagania decyzji. Bardzo istotne jest, by były dokładnie opisane zasady liczenia agregatów, ale niestety akurat ta część dokumentacji powdrożeniowej jest bardzo uboga.

Wspomaganie decyzji to dziedzina znacznie bardziej skomplikowana, niż by wynikało z jej prostej nazwy. Jakiekolwiek narzędzia nie zostałyby wdrożone w celu wspomagania decyzji - czy będzie to generator raportów, hurtownia z narzędziami analitycznymi, czy mechanizmy ETL połączone z dedykowaną aplikacją, czy nawet mechanizmy wyszukiwawcze - wyniki muszą przejść etap interpretacji przez człowieka. Taki analityk biznesowy musi rozumieć zasady działania wdrożonego narzędzia, jego możliwości, a zwłaszcza ograniczenia. Musi ponadto znać realia branżowe, by móc odnieść liczby i wskaźniki do rzeczywistości. Tego się nie da pominąć, ani nawet zbytnio uprościć.


TOP 200