Sam zbuduję sobie BI — to przecież takie proste

Skąd bierze się to przekonanie

Tutoriale na YouTube są świetnie zrobione. Prowadzący otwiera Power BI Desktop, wgrywa plik CSV z czystymi danymi, przeciąga kolumny, łączy tabele strzałkami, buduje dashboard — wszystko w 20 minut. Wygląda znajomo. ChatGPT na pierwsze pytanie pisze działający kod SQL. A GUI systemu ERP — zakładka "Faktury", lista z kolumnami, wartości — wygląda jak zwykła tabela.

Z tych obserwacji wynikają naturalne wnioski. Tyle że każda z nich jest złudzeniem — nie dlatego że ktoś kłamie w tutorialu, ale dlatego że tutorial pokazuje jedną warstwę systemu BI. Trzy poprzednie — i najtrudniejsze — są poza kadrem.

Złudzenie pierwsze: "można to zrobić bez programowania"

Kafelki, strzałki, okienka z polami do przeciągania — narzędzia no-code wyglądają jak układanie puzzli. Żadnego kodu. Tylko że kafelki i strzałki to wizualizacja logiki, nie jej zamiennik. Każde połączenie, każda transformacja, każda reguła biznesowa — "zaległa należność to faktura nierozliczona po terminie plus trzy dni robocze" — jest gdzieś zakodowana. W narzędziu no-code ta logika jest ukryta za interfejsem. Kiedy coś pójdzie nie tak, nie wiadomo gdzie szukać błędu, bo nie wiadomo co narzędzie zrobiło pod spodem.

Pod kafelkami jest kilka warstw — i każda ma swój język. Żeby wyciągnąć dane z bazy ERP pisze się zapytania w SQL albo skrypty w Pythonie. Żeby je oczyścić i przekształcić — znowu SQL, albo Python z bibliotekami do pracy z danymi, albo Power Query z własnym językiem M, albo coś zupełnie innego zależnie od wybranego stosu. Żeby zbudować model analityczny w Power BI — DAX, który wygląda trochę jak Excel ale nim nie jest i rządzi się własnymi zasadami. A żeby to wszystko działało automatycznie, codziennie, niezawodnie — potrzebny jest jeszcze kod do harmonogramowania i monitorowania: Bash, Python, Task Scheduler, cron, Airflow, cokolwiek — zależnie od środowiska. Kafelki w Power BI Desktop to warstwa widoczna. Wszystko poniżej to kod, w różnych językach, z różną logiką — i to właśnie jest poza kadrem tutoriala.

Złudzenie drugie: "w Power BI łączy się tabelki strzałkami"

W tutorialu: plik CSV z 200 wierszami. Kolumny mają czytelne nazwy — klient, data, kwota. Brak duplikatów, brak pustych pól, brak niespójnych formatów dat. Autor pliku zadbał o to przed nagraniem.

W rzeczywistości baza enova365 albo Comarch XL ma kilkadziesiąt tabel z nazwami technicznymi. Kolumna przechowująca typ dokumentu to liczba — wartość 301 oznacza fakturę sprzedaży, 302 fakturę zakupu, 128 paragon — a lista liczy kilkadziesiąt pozycji i nie jest nigdzie udokumentowana dla kogoś z zewnątrz. Przed połączeniem tabelek strzałką trzeba wiedzieć które tabele zawierają faktury, które płatności, jak sparować rozliczenie z dokumentem gdy jedno zobowiązanie spłacane jest w kilku ratach, jak odfiltrować dokumenty testowe wpisane przez księgowość "żeby sprawdzić".

To nie jest wiedza z tutoriali. To jest kilka godzin siedzenia w bazie i rozumienia jak konkretny system ERP przechowuje dane.

Złudzenie trzecie: "ChatGPT napisze mi kod"

ChatGPT naprawdę pisze kod SQL i Python. Działa — na ogólnym przypadku, z przykładową tabelą.

Nie wie że w konkretnym systemie faktury korygujące mają ten sam typ dokumentu co oryginalne, tylko z ujemną kwotą — i żeby aging się zgadzał trzeba je odpowiednio sparować, inaczej każda korekta zawyża zaległości. Nie wie że umowy najmu są w Excelu bo "ktoś kiedyś tak ustawił", a nie w systemie ERP — i że ten Excel ma trzy wersje, z czego dwie są nieaktualne. Nie wie że w jednym z modułów data płatności to data wystawienia dokumentu plus termin — a w innym pole jest wypełniane ręcznie przez księgowość i zdarzają się tam wpisane lata 1900.

ChatGPT nie uruchomi kodu o 6:00 rano, nie sprawdzi czy dane się załadowały, nie wyśle alertu gdy coś przestanie działać, nie poprawi kodu gdy dostawca systemu ERP wypuści aktualizację która zmienia strukturę tabel. I nie powie "nie rób tego sam" — bo nie zna kontekstu.

Złudzenie czwarte: "GUI systemu pokazuje proste tabele"

Zakładka "Faktury" w systemie ERP: lista z kolumnami numer, data, kontrahent, kwota, termin płatności. Wygląda jak tabela — jedna, czytelna, oczywista.

To co widać w interfejsie to wynik kilkunastu złączeń między tabelami bazy, który dostawca systemu zamienił w czytelny ekran. Użytkownik widzi fakturę jako jeden wiersz — w rzeczywistości dane siedzą w kilku powiązanych zbiorach: nagłówek dokumentu, pozycje, rozrachunki, płatności. Żeby wyciągnąć "ile firma X zalega od ponad 60 dni" trzeba złączyć nagłówki z rozrachunkami, odjąć zapłacone, przeliczyć daty od dziś, wykluczyć noty odsetkowe i dokumenty wewnętrzne — i uzyskać wynik zgodny z raportem z systemu ERP, żeby dało się go zweryfikować. Kilka godzin pracy zanim pojawi się pierwsza poprawna liczba.

Co naprawdę wchodzi w skład budowania BI

Nie żeby zniechęcić — żeby pokazać co faktycznie jest na liście gdy "budujemy BI":

Etap	Co to znaczy w praktyce
Audyt danych	Co jest w bazie, jakie tabele, jaka jakość, gdzie są luki. Bez tego budujesz na ślepo — i dowiadujesz się o brakach gdy coś nie wychodzi.
Modelowanie	Projekt struktury analitycznej (star schema) — innej niż operacyjna baza ERP. Tabele faktów, wymiary, klucze.
ETL	Kod który pobiera dane ze źródła, czyści je, przekształca i ładuje. Codziennie. Automatycznie. Z obsługą błędów i alertami gdy coś padnie.
Logika biznesowa	Definicja "zaległej należności", "aktywnej umowy", "kosztu operacyjnego" — zapisana w kodzie, nie w głowie jednej osoby.
Model Power BI	Relacje między tabelami, miary DAX, formatowanie, filtry krzyżowe. To warstwa czwarta — i osobna umiejętność.
Testowanie	Porównanie wyników z systemem ERP. Liczby muszą się zgadzać — inaczej nikt nie będzie ufał raportom.
Utrzymanie	Aktualizacje systemu ERP zmieniają strukturę bazy. Potrzeby firmy się zmieniają. Ktoś musi śledzić i reagować — nie jednorazowo, ale przez cały czas działania systemu.

Tutorial na YouTube pokazuje jeden z tych punktów — zwykle ostatni, czyli robienie wykresu w Power BI. Sześć wcześniejszych jest poza kadrem, bo nie ma z czym tego zrobić w 20 minut.

Kiedy warto spróbować samemu

To nie jest artykuł przeciwko samodzielności. Da się samemu — w konkretnych warunkach:

→ Dane są w jednym miejscu i są czyste — dobrze prowadzony Excel albo prosta baza z kilkoma tabelami
→ Masz czas — samodzielne wdrożenie zajmuje wielokrotnie dłużej niż zlecone, bo każdy problem trzeba rozwiązać po raz pierwszy
→ Znasz SQL i Python — albo masz kogoś w firmie kto zna. ChatGPT to narzędzie dla kogoś kto już rozumie kod, nie zamiennik tej wiedzy
→ Ryzyko błędu w danych jest niskie — raporty wewnętrzne, nie finansowe, nie podpisywane
→ Zakres jest mały: jedno źródło, jeden dashboard, ograniczona logika biznesowa

Jeśli dane siedzą w systemie ERP z kilkoma modułami, potrzebujesz raportów finansowych na których opierasz decyzje, a dane mają się odświeżać automatycznie — to nie jest projekt na weekend po obejrzeniu tutoriali.

Jeśli chcesz wiedzieć z czym realnie mierzysz się zanim podejmiesz decyzję — sprawdź wstępną ocenę projektu na podstawie kilku pytań o swoje dane.

Nie chodzi o to żeby nie próbować. Chodzi o to żeby wiedzieć na co się decydujesz — i żeby decyzja "zlecam" lub "robię sam" była świadoma, a nie podjęta po obejrzeniu dwudziestominutowego tutoriala z gotowym plikiem CSV w opisie.