Excel Power Query: automatyzacja raportów jakości bez pisania makr

Otwieram arkusz z danymi z kontroli, patrzę na daty w trzech różnych formatach i wiem, że za tydzień ktoś znowu będzie to ręcznie kleił. Power Query w Excelu to nie szybszy sposób kopiowania komórek — to przeniesienie całego rytuału przygotowywania raportu w miejsce, gdzie dzieje się raz i potem tylko odświeża.

Dlaczego ręczne raporty jakości to problem systemowy, nie dyscyplinarny

W każdym audycie wewnętrznym, który prowadziłem, prędzej czy później wracał ten sam wątek: raport z działań korygujących powstawał ręcznie, z pliku, który ktoś dostał mailem, przekleił, poprawił i wysłał dalej. Za każdym razem inna osoba, inny moment, inne założenia. Power Query rozwiązuje to inaczej niż makro — zapisuje transformację jako kroki, nie jako kod, więc proces jest czytelny również dla kogoś, kto nie pisze VBA. W narzędziu dostępnych jest ponad 300 funkcji transformacji danych: czyszczenie duplikatów, usuwanie błędów i wartości null, standaryzacja dat, liczb i tekstów.

Drugi problem to źródła. Dane z kontroli przychodzą z pliku CSV z linii, z arkusza od dostawcy i z eksportu z systemu pomiarowego. Ręcznie oznacza to trzy różne formaty i trzy różne godziny. Merge i append w Power Query pozwalają je połączyć w jednym kroku, niezależnie od tego, czy dane mają ten sam układ kolumn, czy trzeba je dopasować po kluczu. Wtedy raport przestaje być dziełem przypadku — każde odświeżenie daje ten sam wynik, o ile źródło się nie zmieniło.

Power Query kontra makra VBA: nie chodzi o to, które jest lepsze

Widziałem wdrożenia, w których Power Query pobierało dane, a logikę specyficzną dla klienta dopisywał VBA. To nie jest kompromis, to podział pracy: Power Query robi to, co powtarzalne (import, czyszczenie, scalanie), VBA robi to, co wymaga logiki warunkowej albo integracji z zewnętrznym systemem. W jednym z wdrożeń opisanych publicznie pobieranie danych do aplikacji zostało zautomatyzowane właśnie przez Power Query, co ograniczyło ilość kodu VBA i uprościło utrzymanie. Dashboard po stronie użytkownika nie zmienił się — zmieniło się to, ile trzeba było dopisać, żeby go zasilić.

Drugi argument za Power Query jest audytowy, nie techniczny. Kroki zapisane w edytorze są widoczne w kolejności, w jakiej zostały wykonane, można je nazwać i skomentować. Przy pytaniu audytora „skąd wzięła się ta liczba w raporcie” nie trzeba odtwarzać czyjegoś toku myślenia z arkusza — wystarczy otworzyć zapytanie i pokazać kolejność transformacji. To ta sama logika, którą stosuję w IATF 16949: zapis procesu musi być na tyle jasny, żeby dało się go sprawdzić bez osoby, która go tworzyła.

Przykład z praktyki

Zespół jakości u dostawcy motoryzacyjnego dostawał co tydzień trzy pliki: jeden z systemu pomiarowego, jeden z reklamacji klienta, jeden z wewnętrznego rejestru niezgodności. Do każdego raportu tygodniowego trzeba było dopasować numery części, ujednolicić formaty dat i policzyć wskaźniki. Robiła to jedna osoba, zawsze w piątek, zawsze pod presją wysyłki.

Zamiast kolejnej wersji arkusza z formułami, powstało jedno zapytanie, które pobiera trzy pliki, dopasowuje numery części i zwraca gotową tabelę do arkusza z dashboardem. W pierwszym tygodniu trzeba było dopracować reguły standaryzacji dat — okazało się, że jeden z systemów zapisuje datę w innym formacie, niż zakładał zespół. Po poprawce raport odświeża się w kilka minut, a osoba, która wcześniej spędzała nad nim piątkowe popołudnie, robi coś innego. Nie zniknęły błędy w danych źródłowych — zniknęła ręczna praca wokół nich.

Co z tego wynika

Nie zaczynałbym od przepisywania wszystkich raportów jakości na Power Query. Zacząłbym od jednego, który powtarza się najczęściej i pochłania najwięcej ręcznej pracy — i sprawdziłbym, czy źródła da się ustabilizować, zanim dotknę transformacji. Jeśli dane przychodzą w formacie, który zmienia się co miesiąc, żadne narzędzie tego nie naprawi. Automatyzacja raportu ma sens wtedy, gdy sam proces jest na tyle powtarzalny, żeby dało się go zapisać.