Od Excela do automatyzacji raportowania: projekt AS-IS i TO-BE

Excel nie jest problemem samym w sobie. Problem zaczyna się wtedy, gdy arkusz pełni jednocześnie rolę bazy danych, integracji, silnika reguł, raportu i archiwum — a jedyną dokumentacją procesu jest pamięć osoby, która „wie, którego przycisku nie naciskać w poniedziałek”.

Stan AS-IS

Modelowy proces miesięcznego raportowania:

• 14 plików z różnych działów,
• 3 źródła systemowe,
• 18 arkuszy roboczych,
• ręczne kopiowanie danych,
• formuły zmieniane lokalnie,
• 2 osoby uzgadniające wynik,
• publikacja przez e-mail,
• brak centralnego rejestru błędów.

Proces trwa dwa dni kalendarzowe, z czego około 11 godzin to praca aktywna. Największe ryzyko nie wynika z funkcji Excela, lecz z braku kontroli wersji, walidacji i jednoznacznej definicji KPI.

Zanim powstanie automatyzacja

Należy ustalić:

1. właściciela każdego źródła,
2. format i termin dostarczenia,
3. definicję każdej miary,
4. klucz łączenia danych,
5. sposób obsługi braków,
6. reguły korekty,
7. odbiorców i poziomy dostępu,
8. moment zamknięcia okresu.

Automatyzowanie nieustalonej definicji KPI jedynie przyspiesza spór o to, która liczba jest prawdziwa.

Architektura TO-BE

Proponowany przepływ:

harmonogram
→ pobranie źródeł
→ zapis wersji surowej
→ walidacja struktury
→ transformacja
→ testy jakości
→ wyliczenie KPI
→ porównanie z progami
→ akceptacja
→ publikacja
→ archiwum i log

Excel może pozostać warstwą prezentacji lub plikiem eksportowym. Nie powinien być jedynym miejscem przechowywania logiki i historii.

Źródła danych

Preferowana kolejność:

1. API lub kontrolowany eksport systemowy,
2. zapytanie do hurtowni lub widoku raportowego,
3. plik dostarczany według jawnego kontraktu,
4. automatyzacja UI jako rozwiązanie pomostowe.

Dla każdego źródła trzeba przechowywać nazwę, datę, wersję, sumę kontrolną lub inny identyfikator oraz status walidacji.

Walidacje

Minimalny zestaw:

• zgodność kolumn i typów,
• unikalność klucza,
• kompletność wymaganych pól,
• zakres dat,
• dozwolone wartości słownikowe,
• suma kontrolna wolumenu lub kwot,
• porównanie z poprzednim okresem,
• próg odchylenia,
• reguła blokująca publikację.

Walidacja musi rozróżniać ostrzeżenie i błąd krytyczny. Inaczej każde odchylenie albo zatrzyma proces, albo zostanie zignorowane.

Harmonogram i zależności

Raport nie powinien startować tylko dlatego, że zegar pokazuje 8:00. Powinien sprawdzić, czy wszystkie źródła osiągnęły stan gotowości. Dla brakującego pliku potrzebne są:

• czas oczekiwania,
• ponowienie,
• powiadomienie właściciela,
• eskalacja,
• decyzja o publikacji częściowej.

Harmonogram jest więc procesem, a nie pojedynczym zadaniem cron.

Kontrola błędów

Każde wykonanie powinno mieć identyfikator. Log musi pozwalać odpowiedzieć:

• które źródło zawiodło,
• ile rekordów odrzucono,
• jaka reguła zadziałała,
• kto zatwierdził wyjątek,
• jaka wersja logiki wyliczyła KPI,
• czy raport został wysłany,
• kto go otrzymał.

Bez tego automatyzacja jest szybka aż do pierwszego pytania audytora.

Pomiar przed i po

KPI wdrożenia:

• czas aktywnej pracy,
• czas kalendarzowy,
• liczba ręcznych kroków,
• liczba korekt po publikacji,
• liczba odrzuconych rekordów,
• terminowość,
• koszt miesięczny,
• czas od wykrycia do poprawy błędu.

Wynik należy porównywać po okresie stabilizacji, nie po pierwszym szczęśliwym uruchomieniu.

Przykład praktyczny

Przykład modelowy

AS-IS:

• 11 h pracy aktywnej,
• 16 ręcznych operacji kopiowania,
• 4 korekty w kwartale,
• publikacja T+2.

TO-BE po stabilizacji:

• 2,5 h pracy, głównie na wyjątki i akceptację,
• automatyczne pobranie 12 z 14 źródeł,
• dwa źródła plikowe z walidacją,
• publikacja T+1 do godz. 10:00,
• pełny rejestr wykonania.

Redukcja pracy aktywnej:

(11 - 2,5) / 11 × 100% = 77,3%

Nie oznacza to redukcji etatu o 77,3%. Oznacza odzyskanie 8,5 godziny w cyklu raportowym i zmniejszenie zależności od ręcznego kopiowania.

Tabela decyzyjna

Checklista

• [ ] Zdefiniowano właścicieli i kontrakty źródeł.
• [ ] Każdy KPI ma definicję, formułę i właściciela.
• [ ] Dane surowe są archiwizowane lub odtwarzalne.
• [ ] Walidacje mają progi ostrzegawcze i blokujące.
• [ ] Publikacja wymaga spełnienia warunków gotowości.
• [ ] Istnieje identyfikator wykonania i pełny log.
• [ ] Excel pełni świadomie wybraną rolę, a nie wszystkie role naraz.

Ryzyka i ograniczenia

• Ukryta logika: formuły i makra mogą zawierać reguły niewidoczne w dokumentacji.
• Jakość źródeł: automatyzacja nie poprawi błędnych danych bez walidacji i właściciela.
• Dystrybucja: raport może zawierać dane wrażliwe i wymagać kontroli odbiorców.
• Zmiana definicji: KPI musi być wersjonowany wraz z datą obowiązywania.

Następny krok

1. Zbuduj katalog źródeł i KPI.
2. Narysuj przepływ AS-IS oraz punkty korekty.
3. Zaprojektuj strefę surową, walidacje i log.
4. Uruchom jeden raport pilotażowy i zmierz 30/60/90 dni.

Źródła i data weryfikacji

• Google SRE — Monitoring Distributed Systems
• OpenTelemetry — signals: traces, metrics and logs
• OpenAPI Specification 3.2.0
• OMG — Business Process Model and Notation 2.0

Data weryfikacji źródeł: 1 sierpnia 2026 r.