Zobacz dokument

2
Podczas prowadzonych przez nas wdrożeń narzędzi Business Intelligence, bardzo często spotykamy się
z problemem nieadekwatnego do naszych potrzeb układu danych źródłowych. Mniejsze czy większe
niedopasowanie występuje niemal w każdym projekcie, dlatego postanowiłem zebrać i opisać najczęściej
występujące problemy wdrożeniowe. Mam nadzieję, że powstanie w ten sposób rodzaj „przewodnika”, który
pomoże Czytelnikom zarówno dobrze wybrać, jak też dobrze wdrożyć odpowiednie dla nich narzędzie Business
Intelligence.
Zauważyliśmy 10 najczęściej występujących problemów z danymi – postaram się je szerzej omówić w dwóch
kolejnych numerach Controllingu i Zarządzania. Są to:
1.
2.
3.
4.
5.
6.
Brak danych.
Scalenie i nałożenie na siebie danych z różnych systemów (różne obszary merytoryczne).
Scalenie danych bieżących z archiwalnymi (np. przy zmianie systemu informatycznego).
Deduplikacja danych (jeden kontrahent w pięciu postaciach, literówki itp.).
Mapowanie danych (np. wyciągnięcie wymiarów z konta księgowego, grupowanie produktów).
Umożliwienie ewidencji historii zmian danych (gdy potrzebujemy np. znać stan Rachunku Wyników wg
danych na określony dzień).
7. Brak dedykowanych mechanizmów uzupełniających przeliczeń (np. alokacji, czy kalkulacji kosztów).
8. Wyliczanie stanów na dany dzień (historii) – stany magazynowe, stan zatrudnienia, stany należności i
zobowiązań.
9. Cache’owanie danych historycznych dla typowych / częstych zapytań / raportów.
10. Rozdzielenie danych bieżących i archiwalnych – problem wydajności.
Najgorzej jest oczywiście wtedy, gdy danych … po prostu nie ma. Wtedy zostaje nam albo pogodzenie się z tym
stanem rzeczy, albo stworzenie jakiegoś obejścia, zastępczej ewidencji, która przynajmniej częściowo taką lukę
uzupełni. Trzeba tu jednak bardzo uważać, aby nie wpaść w pułapkę „Excelozy”, czyli zjawiska, w którym firma
obrasta setkami arkuszy Excela, pełniących de facto rolę pomocniczych baz danych. (Ostatnio w jednym z
zapytań ofertowych pojawiło się zagadnienie „Zapewnienia bezpieczeństwa nieformalnych źródeł danych”…).
„Exceloza” jest o tyle groźna, że często owe „pomocnicze” arkusze stają się de facto źródłami absolutnie
krytycznych dla funkcjonowania Firmy informacji – w praktyce niezabezpieczonymi w jakikolwiek sposób. Wiele
razy widziałem takie pliki z rejestrami np. podpisanych umów, terminami wygaśnięcia kontraktów serwisowych,
warunkami gwarancyjnymi dla poszczególnych Klientów, czy kolejnymi wersjami cenników produktów – leżały
sobie spokojnie na ogólnodostępnym dysku, niezabezpieczone przed utratą, skopiowaniem, czy
nieautoryzowanym dostępem…
Żeby było jasne – nie ma nic złego we WPISYWANIU danych przy pomocy EXCELA (jest to nawet bardzo
wygodne narzędzie do tego celu), groźne może być na dłuższą metę PRZECHOWYWANIE danych w tym
narzędziu. Plik można utracić znacznie łatwiej niż serwerowe repozytorium bazy danych …
Zatem zalecane przez nas rozwiązanie problemu braku pomocniczych ewidencji, to tworzenie ich tak, aby dane
trafiały do bezpiecznej bazy danych (a narzędziem do ich wprowadzenia może być oczywiście nasz poczciwy
EXCEL, przeglądarka www, czy jakakolwiek inna postać formularza). Dane będą bezpieczniejsze, a ich
wykorzystanie w narzędziach BI znacznie łatwiejsze, stabilniejsze i dające się zautomatyzować.
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581
3
To się zdarza bardzo często – potrzebujemy skonfrontować ze sobą dane o sprzedaży i płatnościach, sprzedaży
i reklamacjach, zamówieniach i stanach magazynowych, sprzedaży i liczbie wizyt u danego Klienta,
zamówieniach i produkcji itp. Często „u źródła” występują one w różnych bazach danych, różnych formatach.
Nawet gdy wszystko dzieje się w obrębie jednego zintegrowanego pakietu, bardzo często ta sama kolumna w
różnych tabelach nosi różne nazwy itp. Większość współczesnych narzędzi BI ma możliwość łączenia danych z
różnych źródeł, jest to łatwiejsze, lub trudniejsze – dość ciekawie rozwiązano rzecz w Tableau. Jest tam
wbudowanych ok. 50 sterowników do różnych źródeł danych, ale co ciekawe, w jednym tzw. ekstrakcie danych
możemy nakładać na siebie tabele pochodzące z różnych źródeł. Wówczas nasz model danych może wyglądać
na przykład tak:
Jak widzimy, w jednej analizie nakładamy na siebie tabele z danymi sprzedażowymi z bazy Oracle, danymi
o Klientach i produktach z MS SQL SERVER i pomocnicze dane demograficzne z … arkusza EXCELA. Tabele
możemy łączyć różnymi relacjami (czyli definiować, która tabela „filtruje” którą – czy „Lewa Prawą”, czy „Prawa
Lewą”, czy bierzemy część wspólną z obu, czy bierzemy pełen zakres obu tabel – wtedy mamy odpowiednio
„Left Join”, „Right Join”, „Inner Join” lub „Full Outer Join” i w zależności od typu relacji mamy pełny lub
ograniczony zakres danych, niepowiązane rekordy wyświetlają się jako „nulle”, albo wcale ich nie widać itp.)
Wymaga to oczywiście pewnej wprawy i znajomości logiki danych – to jest ten etap wdrożenia, na którym
można „zrobić sobie krzywdę” i zdefiniować np. model oparty na iloczynie kartezjańskim, w którym wszystko
wiążemy ze wszystkim i możemy wygenerować jakąś gigantyczną i nie mającą sensu liczbę rekordów w tabeli
wynikowej. Trzeba zatem wiązać tabele według tych kolumn, dla których ma to sens (np. „NIP” pomiędzy
tabelą „Kontrahenci” a tabelą „Faktury”)
Rzecz występuje bardzo często. Nasz poprzedni system pracował z bazą danych np. Progress, albo MS SQL,
a „przesiedliśmy się” na Oracle, albo MySQL. A potrzebujemy wieloletnich analiz np. trendów sprzedażowych,
czy historii płatności danego Kontrahenta. Co wtedy?
Aby uniknąć żmudnego „dziobania” w starym i nowym narzędziu oraz niebagatelnych kosztów migracji pełnej
bazy danych ze starego do nowego systemu (zwykle w takiej sytuacji przenosimy jakieś wielkości graniczne –
np. tylko „Bilans Otwarcia”, ewentualnie tylko nierozliczone pozycje na dzień uruchomienia nowego systemu),
najlepiej jest „zrzucić” dane z obu systemów do zewnętrznego narzędzia Business Intelligence. Oczywiście, w
przypadku „starego” systemu, będzie to działanie jednorazowe, tworzące „Archiwum danych”, w przypadku
„nowego” zwykle jest to powiązane z normalnym wdrożeniem narzędzia BI. Aby jednak te dane „widziały się”
ze sobą, nie wystarczy że będziemy je mieli w dwóch „sąsiednich” kostkach OLAP, czy tabelach. Tutaj bardzo
przydatna jest funkcja „Append to Datasource”, występująca w niektórych narzędziach BI. Daje ona możliwość
(po uprzednim „zmapowaniu” części wspólnej obu źródeł danych, czyli wyznaczeniu odpowiadających sobie
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581
4
kolumn w obu źródłach danych) „doklejenia” rekordów z jednego źródła danych do kolejnego – tak jakbyśmy
po prostu dokleili kolejne wiersze w tabeli. W efekcie uzyskujemy JEDNO źródło danych zarówno dla danych ze
starego systemu, jak też nowego – i to z tą samą granulacją danych!
Warto zwrócić uwagę coś takiego, jak „unia danych” – gdy źródłami danych są np. identyczne pliki CSV dla
różnych zakresów czasowych, krajów, czy produktów, można je bardzo łatwo połączyć w „Unię”, dzięki czemu
będą one rozpoznawane jako jedno źródło danych. Warto zapytać o takie funkcjonalności dostawcę naszego
narzędzia BI, zarówno „Append to Datasource”, jak też „Data Union” mogą być kapitalnie pomocne w scaleniu
danych z różnych systemów.
To jeden z najczęściej występujących problemów. Można (i należy!) go rozwiązać na kilku etapach:
1.
2.
3.
U źródła – czyli na etapie ewidencji, wdrażając rozmaite procedury weryfikujące, listy/ raporty
kontrolne, wyłapując i weryfikując kontrahentów o tym samym NIPie, adresie, podciągu znaków
w nazwie itp.)
Na etapie ETL, czyli zasilania danymi narzędzia BI – takie procedury deduplikacyjne są standardowym
rodzajem skryptów ETL.
W samym narzędziu BI – tutaj zwykle mamy do dyspozycji kilka narzędzi.
Zawsze warto zdefiniować kilka analiz „weryfikacyjnych”, wyłapujących np. zdublowane rekordy w bazie
danych – większość współczesnych narzędzi BI ma możliwość już na etapie analizy danych wykonywania
operacji typu „Hide”, „Group”, „Exclude”, „Rename”. Można to zrobić w bardzo prosty sposób nawet
na etapie wizualizacji danych – wyłapując np. elementy wybitnie odstające:
Tutaj bardzo przydatna może być opcja „View Data”, czyli podglądu danych szczegółowych dla danego
obiektu:
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581
5
Dzięki temu możemy błyskawicznie wyłapać zduplikowane obiekty.
Kolejna rzecz – warto sprawdzić, czy nasze narzędzie BI daje możliwość wyłapania różnego typu
„niezmapowanych” obiektów. Może się to odbywać przy pomocy np. komunikatu „Unknown”,
jak w przykładzie poniżej:
Mamy tu fragment analizy na mapie ze znacznikiem pokazującym, że są tu 2 rekordy o statusie „unknown” –
czyli „nieznane systemowi”. Klikając na ów szary prostokąt możemy zobaczyć przyczynę (w pole „Miasto”
wpisano Województwo) oraz rozwiązać problem wpisując poprawne mapowanie:
Co istotne, nie wstrzymuje to procesów ETL, to Użytkownik decyduje, czy chce takim danym zaufać, czy nie.
To również bardzo ważna rzecz – mieliśmy w przeszłości wiele razy do czynienia z sytuacją, gdy odświeżenie
Hurtowni Danych potrafiło zatrzymać się z powodu jakiegoś drobnego błędu w danych, powodując spore
zakłócenia w funkcjonowaniu Firmy…
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581
6
To zagadnienie ma kilka aspektów. Pierwszy – to oczywiście możliwość zdefiniowania nowych wymiarów/
przekrojów analitycznych na podstawie innych wymiarów (np. podciągu znaków konta czy indeksu). Warto
zweryfikować możliwość skorzystania w naszym narzędziu BI z tzw. Splittera, który może jednym kliknięciem
przekształcić np. wymiar „Imię i Nazwisko” w dwa osobne wymiary „Imię” i „Nazwisko” jak na przykładzie
poniżej:
(nie mniej ciekawy jest tzw. „Custom Split”, dający możliwość wyznaczenia, jak dane mają być rozdzielone
i w oparciu o jakie znaki
Oczywiście, niezależnie od tego, co możemy zrobić „jednym kliknięciem”, pozostają nam również znane z
Excela, a stosowane w różnych narzędziach funkcje rozdzielania tekstu typu „Left”, czy „Right”. Bardzo przydają
się one w sytuacjach, gdy chcemy np. „wyłuskać” 5 i 6 znak z indeksu i stworzyć z nich oddzielny wymiar.
Ale nie mniej ciekawe jest tworzenie nowych wymiarów na podstawie poziomu miar – np. klasyfikacji ABC
Klientów, czy produktów. Kiedyś było to dość skomplikowane, dziś wystarczy napisać dość prosty warunek, np:
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581
7
I nasz nowy wymiar jest gotowy do użycia:
Równie częstym zjawiskiem jest problem tzw. „długich ogonów”, czyli wielkości o marginalnym znaczeniu,
które zaciemniają nam całą analizę. Może to powodować efekty takie jak poniżej. Jak widzimy, połowa obszaru
analizy poświęcona jest danym o zupełnie marginalnym znaczeniu. Jeśli mamy możliwość zgrupowaniu ich
na ekranie np. w ten sposób:
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581
8
I oznaczenia aliasem „Pozostałe”, to nasza analiza sporo zyskuje na czytelności – a zostaje jeszcze miejsce
na inne ciekawe elementy analizy, jak trend, czy KPI:
Oczywiście, to dopiero początek listy, kolejne ciekawe aspekty modelowania danych i dopasowywania ich
do naszych potrzeb opiszę w kolejnym artykule – zapraszam serdecznie!
Witold Kilijański, Prezes Zarządu
NewDataLabs sp. z o.o.
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581
9
- Jesteśmy jedynym w Polsce Partnerem Tableau w 100% skoncentrowanym na wdrożeniach tej technologii.
- Pomagamy Klientom nauczyć się Tableau oraz wdrożyć nowe podejście do pracy z danymi,
oferowane przez tę technologię.
- Projektujemy raporty, dashboardy i wizualizacje.
- Pomagamy zamodelować dane na potrzeby importu do Tableau.
- Świadczymy usługi Asysty Powdrożeniowej (zdalnie/online lub w siedzibie Klienta).
- Szkolimy obecnych oraz przyszłych użytkowników Tableau.
[email protected]
601 79 77 83
al. T. Boy'a - Żeleńskiego 28/4,
51-160 Wrocław
https://newdatalabs.com/
Niniejsza publikacja zawiera jedynie ogólne informacje i bazuje na doświadczeniach i analizach konsultantów
NDLS. Niniejsza publikacja nie jest substytutem profesjonalnego doradztwa, nie powinna być wykorzystywana
jako podstawa do podejmowania decyzji lub działań, które mogą mieć wpływ na firmę. Przed podjęciem
jakichkolwiek decyzji lub podjęciem jakichkolwiek działań należy przeprowadzić indywidualną konsultację.
NDLS nie ponosi odpowiedzialności za jakiekolwiek straty poniesione przez jakąkolwiek firmę czy osobę,
która opiera się na tej publikacji.
Copyright © NDLS 2017
NDLS sp. z o.o., 51-160 Wrocław, al. T. Boy’a – Żeleńskiego 28 lok.4, NIP 895 205 25 28, REGON 362492669 KRS 0000575114, kapitał
zakładowy 100 000 PLN, opłacony w całości, nr konta: 03 1020 5226 0000 6202 0520 0581