Power Query vs VBA — kiedy co wybrać?
Power Query i VBA to w gruncie rzeczy oba narzędzia automatyzacji — ale zaprojektowane do różnych zadań. Power Query odpowiada za transformację danych (ETL, łączenie źródeł, czyszczenie). VBA odpowiada za automatyzację aplikacji Office (formularze, mailing, drukowanie, sterowanie skoroszytem). Oba są dosyć stare, ale nawet w dobie AI obronną ręką wychodzą z określonych zadań — pytanie nie brzmi „które z nich jest lepsze", tylko „w jakim zadaniu chcesz po nie sięgnąć".
Pytanie pada na każdym szkoleniu, które prowadzę: „Mam już skrypt VBA, który robi mi raport co poniedziałek. Czy warto przepisywać to na Power Query?". Krótka odpowiedź brzmi: czasami tak, czasami nie. Dłuższa wymaga zrozumienia, co tak naprawdę robi każde z tych narzędzi.
Czym jest Power Query, a czym VBA
VBA to język programowania — Visual Basic for Applications. Skrypty, pętle, warunki, manipulacja obiektami Excela. Wszystko, co napiszesz w kodzie, możesz wywołać przyciskiem.
Power Query to silnik ETL (Extract, Transform, Load) zaszyty w Excelu i Power BI. Zamiast pisać kod, budujesz pipeline transformacji: „pobierz to, połącz z tym, odfiltruj, pogrupuj". Pod spodem generuje się kod w języku M, ale 90% pracy wykonuje się klikami.
Te narzędzia zostały zaprojektowane do innych zadań. VBA to skalpel — robisz dokładnie to, co chcesz, ale ponosisz pełen koszt utrzymania. Power Query to kombajn — szybko ogarnia powtarzalne przekształcenia, ale kiepsko nadaje się do logiki niestandardowej.
Kiedy Power Query wygrywa zdecydowanie
1. Pobieranie danych z wielu źródeł. Excel + CSV + SQL + API + folder z plikami? Power Query robi to bez najmniejszej zadyszki. W VBA każde źródło to inna biblioteka, inny obiekt, inny zestaw błędów do złapania.
2. Przekształcenia powtarzalne co tydzień. Filtruj kolumny, usuwaj duplikaty, zmieniaj typy, łącz tabele po kluczu. To jest dokładnie to, do czego Power Query został zbudowany. Skrypt VBA robiący to samo będzie 3-4 razy dłuższy i znacznie bardziej wrażliwy na zmiany.
3. Wieloosobowy zespół. Pipeline w Power Query rozumie każdy analityk, który widział kiedyś Excela. Kod VBA (zwłaszcza pisany odręcznie) jest w pewnym sensie przeniesieniem sposobu rozumowania danego pracownika. Jeśli nie został opatrzony komentarzami — często może być trudno wyłapać logikę, która za nim stoi. W razie gdyby twórca makra zdecydował się „kontynuować karierę poza strukturami firmy", może być ciężko naprawić jego dzieło, które jak wiadomo, zepsuje się w najmniej odpowiednim momencie.
4. Logowanie i audyt. Każdy krok w Power Query jest widoczny, nazwany i edytowalny. W VBA żeby zrozumieć co robi pętla, musisz ją przeczytać linijka po linijce.
5. Łatwa przesiadka do Power BI. Jeśli zrozumiesz działanie Power Query w Excelu, będziesz mógł bez żadnego problemu wykorzystać te same procesy podczas ładowania danych do Power BI.
Kiedy VBA wciąż ma sens
1. Interakcja z użytkownikiem. Formularze, dialogi, MsgBox, sprawdzanie czy użytkownik wprowadził poprawne dane. Power Query nie ma UI poza edytorem — nie zatrzyma się w połowie i nie zapyta o cokolwiek.
2. Logika sterująca aplikacją. Otwieranie i zamykanie skoroszytów, drukowanie, wysyłanie maili przez Outlooka, generowanie PDFów. To nie jest transformacja danych — to automatyzacja Office'a. VBA został do tego zaprojektowany.
3. Złożone reguły biznesowe na poziomie wiersza. Power Query potrafi dużo, ale jeśli reguła brzmi „dla każdego klienta sprawdź historię transakcji z ostatnich 12 miesięcy, znajdź anomalie i zaproponuj korektę" — to brzmi jak skrypt, nie jak pipeline.
4. Dziedziczone systemy. Jeśli firma ma 200 makr, na których stoi miesięczne zamknięcie, nie przepisujesz wszystkiego od jutra na Power Query. Jedna rzecz na raz — jeśli już jest to konieczne, najpierw testuj rozwiązanie poza najgorętszym okresem.
Pułapki, w które zespoły wpadają
Pułapka 1: „VBA jest szybsze". Mit. W zadaniach typu ETL Power Query często jest szybsze, bo silnik M optymalizuje plan wykonania (query folding, lazy evaluation). VBA wykonuje wszystko liniowo. Wyjątek: bardzo małe zbiory danych (poniżej 1000 wierszy) na bardzo prostych operacjach.
Pułapka 2: „Power Query nie obsługuje warunków". Obsługuje. if then else w M wygląda inaczej
niż w VBA, ale działa. Custom Column z formułą warunkową załatwia 80% przypadków.
Pułapka 3: „Mam już VBA, więc dorobię kolejne makro". Jeśli zjadłeś zęby na VBA — luz. Jeśli nie — jesteś na najlepszej drodze do makra-monstrum. Po którymś zależnym makrze nikt już nie wie, co wywołuje co, a poprawka jednej procedury może wywalić cały projekt. Power Query wymusza myślenie pipeline'owe — każdy krok jest nazwany i widoczny.
Pułapka 4: „Power Query wystarczy do wszystkiego". A czy widelcem da się zjeść każdą potrawę? Widziałem zespoły, które próbowały zbudować w Power Query system zatwierdzania faktur. Po kilku miesiącach poddali się i napisali to w VBA w dwa tygodnie. Jaki z tego wniosek? Że dostarczanie danych (nawet zdegenerowanych) wykonujemy za pomocą Power Query, a łączenie wielu czynności, procesów i budowę UX wykonujemy z pomocą VBA. No i zupę jemy łyżką a nie widelcem 😉
Strategia migracji — pragmatyczna
Jeśli masz dziedziczone makra i myślisz o porządkach:
- Zidentyfikuj co naprawdę robi każde makro. Być może większość z nich okaże się czystym ETL.
- Zacznij od najczęściej używanego raportu. Przepisz pipeline na Power Query, VBA zostaw tylko do operacji końcowych (formatowanie, drukowanie, wysyłka).
- Mierz czas. Jeśli refresh w Power Query zajmuje mniej niż VBA — super. Jeśli kod VBA działa szybciej — ekstra. Używaj właściwych narzędzi, jednak zwróć uwagę na skalowalność — Power Query z reguły radzi sobie z tym lepiej.
- Nie przepisuj wszystkiego. Niektóre makra przeżyją swoich autorów. Akceptuj to i nie marnuj tygodni na refaktor czegoś, co działa od dekady.
Podsumowanie w jednym zdaniu
Power Query do transformacji danych, VBA do automatyzacji aplikacji. Granica jest cienka, ale istnieje. Zespoły, które ją widzą, oszczędzają tygodnie pracy.
Jeśli chcesz przejść przez Power Query w Excelu w praktyce — od pierwszego pipeline'u po zaawansowany język M — zapraszam na szkolenie. A jeśli czujesz, że VBA wciąż jest częścią Twojego ekosystemu i chcesz to robić solidnie — mam też szkolenie z VBA. Albo przyjdź na oba — chętnie przegadam z Tobą scenariusze wykorzystania tych narzędzi.