Ostatnimi czasy większość firm decyduje się na implementację systemów do raportowania wykorzystujących interfejs „drag and drop”, porzucając powoli w zapomnienie systemy pozwalające na tworzenie raportów za pomocą zapytań SQL’owych. Przejście na tego typu systemy ma na celu ułatwienie i przyspieszenie pracy swoich analityków.
Firma oszczędza czas i pieniądze, które musiałaby zainwestować w wyszkolenie pracowników lub też znalezienie osób, które już wiedzę o SQL posiadają. Teoretycznie dzięki pracy na systemie z interfejsem „drag and drop” pracownik, zamiast głowić się nad napisaniem poprawnego zapytania SQL’owego potrzebnego do stworzenia raportu, musi jedynie przeciągnąć odpowiednie elementy w aktywne pole i w ten sposób otrzyma swój raport (czy też potrzebny zbiór danych). Teoretycznie tak powinno być, a jak jest w praktyce?
W dalszej części tekstu chciałabym się skupić na narzędziu BI stworzonym przez firmę MicroStrategy Desktop. Narzędzie to służy do analizy dużych ilości danych, tworzenia raportów (a także bardziej skomplikowanych dashboardów), jak również do bezpiecznej ich dystrybucji. Jest to system wyposażony w prosty i zgrabny interfejs użytkownika pozwalający na szybkie opanowanie zasad korzystania z narzędzia na poziomie wystarczającym do wykonywania codziennych obowiązków (nie piszę tutaj o zagłębianiu się we wszystkie opcje i „bajery”, które oferuje MicroStrategy Desktop).
Plusy
Trzeba przyznać, ze od strony wizualnej narzędzie to prezentuje się bardzo czytelnie. Użytkownika najpierw wita ekran pozwalający na wybór projektu na jakim chce pracować, a następnie po wybraniu odpowiedniego projektu wyświetla ekran z wyborem opcji do dalszej pracy – stworzenie nowego raportu, dokumentu, dashboardu czy metryki lub przejścia do folderów, a także listy subskrypcji (Rysunek 1). Ekran tworzenia raportów jest równie przejrzysty i pozwala na szybkie zorientowanie się, jak korzystać z tego narzędzia. Wszystkie tabele i widoki uporządkowane są w foldery, co zdecydowanie poprawia czytelność i pomaga w rozeznaniu się z jakim zbiorem danych ma się do czynienia. Aby to jeszcze bardziej ułatwić, twórcy pomyśleli nawet o tym by kolumny/pola zawierające dane tekstowe oznaczyć jednym kolorem, a numeryczne innym. Uporządkowane zbiory danych zebrane są w sekcji ‘ALL OBJECTS’ umieszczonej po lewej stronie ekranu. W tym miejscu użytkownik może również zmienić widok i wyświetlić jedynie elementy, które wykorzystał w swoim raporcie – pozwala na to opcja ‘REPORT OBJECTS’. Cała pozostała część ekranu pozostawiona jest na tworzenie raportów. Jak widać na załączonej grafice (Rysunek 2) narzędzie zostało zaprojektowane tak, by jego obsługa była jak najprostsza.
Ograniczenia narzędzia
Jak już na początku wspomniałam, MicroStrategy Desktop jest narzędziem wykorzystującym interfejs „drag and drop”, co ma pozwolić użytkownikowi na szybkie tworzenie raportu bez potrzeby zastanawiania się nad tym, jakie zapytanie SQL’owe siedzi pod spodem. Wydawać by się mogło, że takie narzędzie nie powinno mieć zbyt wielu ograniczeń i wad, a jednak, podczas pracy z MicroStrategy Desktop, natrafiłam na kilka utrudnień, które przy wykonywaniu niektórych tasków w systemie pozwalającym na pisanie zapytań SQL by nie wystąpiły.
Zacznijmy od pierwszego utrudnienia, które może porządnie zdezorganizować pracę analityka, czyli od tego, że użytkownik tworzy raporty trochę „na oślep”. Brak dostępu do MicroStrategy Developer sprawia, że uzyskanie stosunkowo podstawowych informacji o stworzonym raporcie stanowi duży problem. Jeżeli w systemie kilka folderów zawiera kolumny o tej samej nazwie, a w opisie raportu nie uwzględniono, z którego folderu pochodzą kolumny, to jedynie użytkownik z prawami Developera może pomóc odszyfrować na jakim folderze bazuje raport. O ile bardziej czytelne jest w tym przypadku proste zapytanie SQL gdzie jawnie podajemy bazie z jakiej tabeli chcemy odczytać dane?
W tym miejscu wypadałoby też wspomnieć o tak drobnej rzeczy, jaką jest możliwość wybrania wszystkich elementów z folderu, a która w MicroStrategy Desktop jest dość kłopotliwa. Niestety, jedyny sposób zrealizowania takiego zadania, to wybieranie elementów po kolei, co zdecydowanie nie oszczędza czasu, szczególnie kiedy trzeba sprawdzić, czy na pewno wybrane zostały wszystkie elementy.
Kolejny problem pojawia się też, kiedy użytkownik chce połączyć kolumny z kilku folderów. Jeżeli wcześniej nie udostępniono użytkownikom informacji o dozwolonych połączeniach danych pomiędzy folderami, to po drodze może on napotkać na sporą liczbę błędów. W tym momencie należy znowu zwrócić się o pomoc do zespołu technicznego, gdyż teoretyczne połączenie tabel mogło nie zostać zaprojektowane wcześniej w bazie i nie jest dostępne. Ponownie, SQL pozwala na dużo więcej, użytkownik decyduje o warunkach łączenia tabel, bo nie zostały one predefiniowane w bazie. Przy tym trzeba jednak bazować na założeniu, że użytkownik potrafi poprawnie połączyć tabele i nie pominie któregoś warunku w klauzurze join. Te predefiniowane połączenia tabel mają więc ochronić użytkownika przed wygenerowaniem niepoprawnego raportu, ale z drugiej strony mocno go ograniczają i spowalniają jego pracę. Zanim otrzyma odpowiedź od zespołu technicznego „Przesłany błąd oznacza, że połączenie między tabelami nie istnieje” (i w domyśle istnieć nie będzie) minie trochę czasu. Czynnikiem mającym duży wpływ na tego typu sytuacje jest również poziom znajomości przez pracownika danych, na których pracuje. Niestety działa to w dwie strony, natrafiłam na dużo przypadków, gdzie osoba dobrze znająca dane potrafiła przy pomocy SQL’a wyciągnąć z systemu prawidłowy zbiór potrzebnych danych, a w MicroStrategy Desktop, przez brak połączeń między folderami, musiała tworzyć kilka raportów, a następnie w Excelu robić kilka vlookup’ów, by osiągnąć ten sam efekt.
Sporym ograniczeniem MicroStrategy Desktop jest też brak możliwości tworzenia zapytań odpowiadających SQL’owemu UNION. Zespół techniczny z prawami dewelopera jest w stanie utworzyć taki widok w bazie, by następnie użytkownik mógł z niego skorzystać w MicroStrategy Desktop, ale niestety sam użytkownik już nie ma takiej możliwości. Jedynym rozwiązaniem z jakiego może w tym wypadku skorzystać, to stworzenie tzw. dokumentu, w którym można umieścić kilka raportów. W ten sposób za jednym kliknięciem użytkownik ściągnie wszystkie potrzebne dane do Excela, jednak musi się liczyć z tym, że każdy raport będzie na oddzielnym arkuszu. Znowu więc trzeba skorzystać z pomocy Excela.
Powyżej wspomniane minusy aplikacji to największe problemy, na jakie natrafiłam przy pracy z MicroStrategy Desktop. Nie oznacza to jednak, że narzędzie to nie góruje nad systemami opartymi na pisaniu zapytań SQL w żadnej kategorii. Jeżeli użytkownik potrzebuje tworzyć raporty, takie jak przedstawiono na Rysunku 3, to kilkoma kliknięciami jest w stanie je przygotować. Napisanie takiego zapytania SQL zajęłoby mu zdecydowanie więcej czasu i wymagało dużo większej wiedzy. Również szybkość generowania raportu i jego eksportu była znacznie lepsza, ale niestety nie zawsze. Jak każdy system i ten w tym aspekcie potrafi być, delikatnie mówiąc, kapryśny (oczywiście zależy to też w dużej mierze od tego, skąd aplikacja czerpie dane i jak napisane są zapytania SQL). Również wcześniej wspomniane predefiniowanie połączeń między tabelami można uznać za mały plusik, bo uniemożliwiają one użytkownikowi wykonanie niedozwolonych połączeń i wygenerowanie nieprawidłowego raportu.
Z punktu widzenia firm, raczej nie powinno dziwić, że MicroStrategy Desktop, czy systemy tego typu, zyskały ostatnimi czasy taką popularność. Są one proste w obsłudze, przyjazne dla nowych użytkowników (nauka obsługi takiego programu nie zajmuje dużo czasu) i pozwalają na szybkie tworzenie skomplikowanych raportów. Jednak przy dłuższym użytkowaniu można napotkać na kilka ograniczeń mogących zdezorganizować pracę. I tu pojawia się pytanie „jak bardzo zdezorganizują one pracę?”.
Zostaw komentarz