Czym jest nowoczesny Excel?

Od arkusza kalkulacyjnego do aplikacji biznesowej

Kiedy słyszysz „Excel", prawdopodobnie wyobrażasz sobie siatkę komórek, kilka formuł SUMA i może jeden wykres kołowy do prezentacji na zebraniu. To obraz sprzed dekady.

Producent promuje Excel jako jeden z głównych elementów platformy Microsoft 365 — obok Teams, SharePointu czy Power Automate. To pozycjonowanie ma jednak drugie dno: Excel można rozbudowywać, łącząc go z innymi elementami platformy oraz z narzędziami takimi jak Python czy zewnętrzne API, tworząc coś więcej niż sam arkusz kalkulacyjny — pełnoprawną aplikację biznesową z własnym interfejsem, automatyzacją i integracjami, które zwykle kojarzą się z dedykowanym oprogramowaniem. Powstaje w ten sposób rozwiązanie, które potrafi wyeliminować typowe ograniczenia samego Excela. Robią to najczęściej sami pracownicy, rzadziej dział IT — osoby, które dobrze znają swój proces i potrafią kreatywnie połączyć dostępne narzędzia w rozwiązanie, jakiego nikt formalnie nie zaprojektował.

Marketing wokół „nowoczesnego Excela" najczęściej sprowadza się do nowych formuł — LET, LAMBDA, dynamiczne tablice. Tymczasem dla wielu użytkowników Excel z czasem robi się raczej prostszy niż bardziej zaawansowany: proste tabelki, podstawowe analizy, pojedynczy wykres. To pozorna sprzeczność: prawdziwa siła nowoczesnego Excela nie leży w liście nowych funkcji, tylko w tej cichej, oddolnej rozbudowie opisanej wyżej — arkuszu, który po latach okazuje się kręgosłupem jakiegoś procesu.

Ten problem dobrze widać również w praktyce pracy Interim Managera. W projektach, w których pracuję z zespołami finansowymi, wielokrotnie spotykam osoby, które przeszły szkolenia z Excela, znają wiele funkcji i potrafią poprawnie ich używać, ale mają trudność z przełożeniem tej wiedzy na rozwiązanie konkretnego problemu biznesowego.

Problem często polega na tym, że szkolenia koncentrują się na samym narzędziu — jak zagnieździć funkcję, jak zbudować tabelę przestawną, jak działa dana formuła — zamiast pokazywać, jak połączyć te elementy w rozwiązanie rzeczywistego procesu. Uczestnik wychodzi więc z większą znajomością funkcji Excela, ale niekoniecznie z umiejętnością zaprojektowania rozwiązania problemu, z którym mierzy się na co dzień. Brakuje właśnie tego pomostu między możliwościami Excela a konkretnym przypadkiem biznesowym, w którym te możliwości rzeczywiście coś zmieniają.

Nowoczesny Excel nie zaczyna się od funkcji LET, makr VBA ani integracji z AI. Zaczyna się od osoby, która widzi problem w swoim procesie i nie chce przyjąć, że „tak już jest".

To ktoś, kto zamiast ręcznie kopiować dane między plikami, szuka sposobu, aby ten proces zautomatyzować. Kto zamiast kolejny raz przygotowywać ten sam raport, buduje narzędzie, które zrobi to za niego i zespół. Kto traktuje Excela jako środowisko, w którym można przetestować, zaprojektować i wdrożyć rozwiązanie realnego problemu, a nie tylko miejsce na prostą tabelę i wykres. To także ktoś, kto nie boi się eksperymentować i testować nowych rozwiązań — na przykład zbudować dynamiczny system analityczny, oparty na modelu probabilistycznym i statystycznym w Pythonie, do prognozowania wyników i symulacji, które mają podnieść jakość analiz.

W tym sensie o nowoczesnym Excelu decyduje sposób myślenia, a nie konkretny zestaw funkcji: odwaga, by nie rozłożyć rąk przed niedoskonałym procesem, tylko spróbować go uporządkować — krok po kroku, z użyciem narzędzi, które są pod ręką.

Nie każde takie rozwiązanie powinno pozostać w Excelu. Czasem stanie się prototypem aplikacji, czasem trafi do bazy danych, Pythona albo systemu webowego. Ale bardzo często wszystko zaczyna się od jednej osoby, która powiedziała: „spróbuję to rozwiązać".

Nowoczesny Excel nie oznacza „wszystko w Excelu"

To ważne rozróżnienie w myśleniu o Excelu.

Nowoczesne rozwiązanie nie polega na tym, aby każdą funkcję budować wewnątrz jednego skoroszytu. Wręcz przeciwnie.

Excel może być najlepszym miejscem dla jednej części rozwiązania, podczas gdy inne zadania powinny zostać przekazane innym technologiom. Przykładowo:

• Excel może odpowiadać za modelowanie, analizę i interfejs użytkownika
• VBA za automatyzację i obsługę procesów
• Power Query za pobieranie i transformację danych
• SQL za pracę z bazą danych
• Python za przetwarzanie danych, algorytmy i bardziej zaawansowaną analitykę
• API za komunikację pomiędzy systemami
• aplikacja webowa za prezentację wyników użytkownikom, którzy nie potrzebują pracować bezpośrednio w Excelu

Dlatego pytanie „Excel czy Python?" albo „Excel czy aplikacja webowa?" często nie ma większego sensu.

Lepsze pytanie brzmi: która część rozwiązania powinna zostać zbudowana w której technologii?

Warto przy tym uczciwie nazwać, gdzie Excel sobie nie radzi, wskazując konkretne mechanizmy zamiast ogólników. Excel liczy lokalnie, na RAM-ie i procesorze jednego komputera, więc przy naprawdę dużych zbiorach danych brakuje mu mocy, którą łatwo skalować po stronie serwera. Analiza historii zakupowej klientów, na przykład obliczenie wskaźnika CHURN dla dużej bazy, potrafi trwać wiele godzin, a przy dużej historii i szerokim asortymencie nawet kilka dni — i to licząc na samym serwerze, nie w Excelu. W takiej sytuacji Python + SQL jest w zasadzie jedynym sensownym wyborem, bo tylko on pozwala rozłożyć takie obliczenia w czasie, zautomatyzować je i uruchamiać cyklicznie, tak żeby analityk czy dział sprzedaży mieli dostęp on demand do najnowszych wyników zamiast czekać na każde odświeżenie od nowa. Jest też ograniczenie, o którym rzadko się mówi: współautorstwo w czasie rzeczywistym w Excelu przestaje działać, gdy skoroszyt zawiera makra VBA — model taki jak Metis, mimo całej automatyzacji, wciąż nie pozwala kilku osobom edytować się jednocześnie tak, jak w Arkuszach Google.

Excel niekoniecznie sprawdza się też jako miejsce archiwizacji dużych zbiorów danych obsługiwanych przez większy zespół, jeśli brakuje jasnej polityki higieny danych i konsekwencji w jej stosowaniu — bez tego łatwo o rozjazd wersji, sprzeczne definicje tych samych pól czy ciche błędy, które ujawniają się dopiero po fakcie. Czasami to właśnie system ERP jest lepszym narzędziem do zbierania i archiwizacji danych czy przygotowywania danych i wstępnych raportów — a Excel powinien wchodzić do gry dopiero na etapie dalszej analizy. Podobnie Excel niekoniecznie będzie dobrym rozwiązaniem do analiz statystycznych czy ekonometrycznych, które trwają odpowiednio długo — obliczenia iteracyjne na dużych próbkach danych lepiej sprawdzają się w środowiskach zaprojektowanych właśnie do tego typu pracy.

W tych obszarach Python jest po prostu lepszym narzędziem, a przekazanie mu takich zadań świadczy o dojrzałym podejściu do architektury, nie o porażce arkusza. Wniosek jest prosty: warto świadomie łączyć Excel z technologiami, które nadrabiają jego słabości. Reszta tego artykułu pokazuje, jak takie hybrydowe podejście wygląda w praktyce.

Excel jako węzeł w sieci systemów

Nowoczesny Excel nie musi działać w izolacji — i wiele osób w gruncie rzeczy robi to już od dawna, tylko w najprostszej, ręcznej formie. Pobieranie danych z systemu ERP do Excela w celu ich analizy to codzienność w niejednej firmie. Różnica polega na tym, że taki przepływ danych zwykle kończy się na jednorazowym eksporcie i ręcznym wklejeniu, zamiast być częścią świadomie zaprojektowanego workflow. Wystarczy tę samą logikę ubrać w automatyzację, żeby Excel stał się częścią większego ekosystemu, w którym integruje dane zarówno je pobierając, jak i wysyłając do Pythona działającego na serwerze.

Takie podejście pozwala wykorzystać to, w czym każde narzędzie jest najlepsze. Cięższe obliczenia — na przykład prognozy budowane metodami machine learning, które potrafią zająć trochę czasu — najlepiej wykonać po stronie Pythona na serwerze, a nie wewnątrz samego arkusza. Python w tle liczy i przygotowuje „ciężkie" zapytania oraz dane, udostępniając wyniki przez API, a Excel pobiera je z powrotem przez Power Query, bez ręcznego kopiowania i wklejania.

W Metis arkusz komunikuje się w ten sposób między innymi z bazą danych oraz SharePointem, skąd automatycznie pobiera pliki źródłowe. Wykonane operacje pozostawiają przy tym ślad pozwalający ustalić, co zostało zmienione, kiedy i przez jaki mechanizm.

Excel staje się w ten sposób jednym z węzłów większej architektury, obok bazy danych, systemów przechowywania plików, automatyzacji VBA, API czy innych aplikacji — a nie jedynym miejscem, w którym coś się dzieje.

Do pisania samych zapytań Power Query, czyli kodu w języku M, można wykorzystać AI — potrafi zaproponować szkielet zapytania. Obowiązuje tutaj zasada, że warto rozumieć składnię i możliwości M, bo to, co się rozumie, łatwiej kontrolować.

VBA jako dyspozytor, nie tylko wykonawca

Dobrze pokazuje to Metis, wspomniany już wcześniej model finansowo-operacyjny stworzony dla firmy zajmującej się importem B2B i e-commerce.

To, co najczęściej umyka w dyskusjach o VBA, to zakres automatyzacji, jakie potrafi wykonywać — od prostych makr po całe łańcuchy zadań wykraczające poza sam arkusz.

Kliknięcie przycisku w arkuszu nie musi oznaczać, że to sam Excel wykonuje całą pracę. VBA może zamiast tego spakować dane, wysłać je na serwer, na którym działa aplikacja Python, i zlecić jej wykonanie właściwego zadania — przeliczenia, importu, generowania pliku. Excel w tym układzie pełni funkcję interfejsu i punktu startowego procesu — resztę pracy wykonuje coś innego.

Kiedy taka operacja się zakończy, cały łańcuch potrafi się zamknąć automatyczną informacją zwrotną — na przykład powiadomieniem wysłanym na kanał Discorda. W praktyce wygląda to tak: dedykowany kanał notyfikacji odbiera wiadomości od botów odpowiadających poszczególnym procesom — jeden informuje o zaimportowaniu nowych progów pakowania z pliku źródłowego, inny o wygenerowaniu propozycji, jeszcze inny o zapisaniu danych do bazy. Każdy wpis pokazuje, co się wydarzyło, kto lub co zainicjowało operację (w tym wypadku excel_vba) i skąd pochodziły dane.

To zmienia charakter automatyzacji. Zamiast czekać przy komputerze na zakończenie makra, użytkownik dostaje potwierdzenie tam, gdzie i tak pracuje na co dzień — w komunikatorze zespołu.

Warto przy okazji rozdzielić dwie rzeczy: pisanie logiki VBA i jej utrzymanie. Natywny edytor VBA w Excelu nadaje się w praktyce głównie do jednego zadania — zainstalowania krótkich skryptów, które importują do skoroszytu właściwy kod napisany gdzie indziej, najczęściej w VS Code. Sam kod warto pisać i utrzymywać poza Excelem. Synchronizacja modułów pomiędzy edytorem a skoroszytem odbywa się przez eksport/import plików .bas i .cls — dzięki temu kod VBA można trzymać w repozytorium, przeglądać różnice między wersjami i pracować na nim tak samo jak nad każdym innym projektem programistycznym.

Przy pisaniu kodu VBA może pomóc AI — potrafi szybko wygenerować szkielet procedury czy zaproponować rozwiązanie problemu. Warto jednak wcześniej zapoznać się ze składnią i metodologią VBA, zamiast polegać wyłącznie na AI. Sprawdza się tu prosta zasada: jak coś rozumiesz, możesz to udoskonalić.

Takie makra można wstawić do wstążki Excela — w Metis pojawiają się dzięki temu dodatkowe karty „SnapShots & GitHub” oraz „Builder” — elementy, których nie ma w standardowej instalacji Office. To nie funkcja wbudowana w Excela, tylko konsekwencja własnego kodu: VBA potrafi dodawać do wstążki nowe karty i przyciski, które uruchamiają automatyzacje wykraczające poza sam arkusz — na przykład wysyłanie danych do zewnętrznej bazy, generowanie plików czy zlecanie zadań aplikacjom działającym na serwerze. W Metis przyciski takie jak „Generate File” czy „Save to Metis” pozwalają jednym kliknięciem wykonać taką operację.

Warto przy okazji wspomnieć o Office Scripts — opartym na TypeScript następcy makr, dostępnym w Excelu online. Office Scripts nie jest jednak obecnie pełnym zamiennikiem VBA: skrypt działa w obrębie samego skoroszytu i nie ma dostępu do lokalnego systemu ani zasobów komputera, a do uruchomienia wymaga pliku przechowywanego w OneDrive lub SharePoincie oraz połączenia z internetem. To może się z czasem zmienić, ale obecnie Office Scripts sprawdza się głównie w rozwiązaniach chmurowych — do integracji z lokalnymi systemami wciąż lepiej nadaje się VBA.

Excel przestaje być więc wyłącznie miejscem, w którym wykonuje się obliczenia. Staje się częścią procesu biznesowego.

Skala, z którą Excel potrafi sobie poradzić

Excel może być znacznie większy i bardziej złożony, niż wielu osobom się wydaje. Jednym z mitów dotyczących Excela jest przekonanie, że duży skoroszyt automatycznie oznacza problem z wydajnością.

Sama wielkość pliku czy liczba arkuszy nie mówi jeszcze, czy rozwiązanie jest dobrze zaprojektowane. O jego praktycznej użyteczności decydują między innymi architektura modelu, liczba zależności, sposób wykonywania obliczeń, automatyzacja oraz sposób przechowywania i pobierania danych. Problemy z wydajnością rzeczywiście mogą się pojawić — ale zwykle wtedy, gdy duży skoroszyt buduje osoba bez doświadczenia i nieostrożnie dobiera formuły oraz formatowanie warunkowe, które przy dużej skali potrafi znacząco spowolnić przeliczanie arkusza.

Tymczasem sama liczba zajętych komórek nie mówi jeszcze wiele o złożoności modelu. Komórka zawierająca wartość i komórka zawierająca formułę to z punktu widzenia modelu dwie zupełnie różne rzeczy.

Jeżeli arkusz zawiera milion komórek z danymi, Excel przede wszystkim przechowuje te wartości. Jeżeli natomiast zawiera milion komórek z formułami, musi dodatkowo zarządzać zależnościami pomiędzy nimi i wykonywać obliczenia.

W praktyce oznacza to, że 1,7 miliona formuł jest znacznie bardziej znaczącą informacją o złożoności skoroszytu niż 2 miliony wypełnionych komórek.

Dobrym przykładem jest właśnie Metis. Sam widok zakładek na dole ekranu — dziesiątki arkuszy takich jak "Agent Directives", "Matrix Costs", "Initial Data" czy "Packing – Tiers" — daje przedsmak skali, a pełne statystyki tego konkretnego skoroszytu potwierdzają wrażenie:

• 215 arkuszy
• ponad 2 miliony komórek z danymi
• prawie 1,7 miliona formuł

To oznacza, że znaczna część tego skoroszytu nie jest po prostu magazynem danych. Excel wykonuje w nim ogromną liczbę obliczeń.

Duży arkusz może zawierać miliony rekordów, ale wykonywać stosunkowo niewiele obliczeń. Duży model może natomiast zawierać setki tysięcy lub miliony formuł, których wyniki są od siebie zależne. Wtedy Excel nie tylko przechowuje dane — jest silnikiem obliczeniowym całego rozwiązania. Dzięki makrom taka aplikacja potrafi też sama dostosować zakresy danych do faktycznego wolumenu konkretnego klienta — na przykład przez dynamiczne przeliczanie granic tabel przy każdym imporcie — więc formuły nie są sztywno przypisane do stałej liczby wierszy i nie wymagają ręcznej ingerencji w strukturę arkusza przy każdej zmianie ilości danych.

LET i LAMBDA — porady przy budowaniu dużych modeli

Nowoczesny Excel zmienił się nie tylko dzięki VBA, Power Query czy możliwościom integracji z bazami danych. Dużą zmianę przyniosły również nowe możliwości budowania samych formuł.

Szczególnie interesujące są funkcje LET i LAMBDA.

Funkcja LET pozwala nadawać nazwy wynikom pośrednim wewnątrz jednej formuły. Zamiast wielokrotnie powtarzać to samo obliczenie, można wykonać je raz, nadać mu czytelną nazwę i wykorzystać dalej w tej samej formule.

Ma to znaczenie nie tylko dla czytelności. W dużych modelach oznacza to możliwość zamykania większej części logiki w jednej formule, zamiast rozbijania jej na wiele kolumn pomocniczych, tabel i arkuszy.

LAMBDA idzie jeszcze dalej — pozwala tworzyć własne funkcje w Excelu bez konieczności pisania VBA. Funkcja może przyjmować argumenty, wykonywać zdefiniowaną logikę i zwracać wynik — podobnie jak funkcje w językach programowania.

W połączeniu z LET daje to coś znacznie ważniejszego niż „kolejną funkcję Excela". Skoroszyt zaczyna mieć własną warstwę funkcji biznesowych.

Należy jednak zachować umiar. LET bardzo łatwo wykorzystać zbyt agresywnie i stworzyć formułę, która zamiast upraszczać model zaczyna go komplikować. Istnieje też twardy limit 8 192 znaków dla jednej formuły, więc przy rozbudowanej logice można po prostu dojść do granicy możliwości pojedynczego wyrażenia.

Przy dużych modelach dobrze sprawdza się też coś znacznie prostszego: zwykła formuła JEŻELI (IF), która pozwala pominąć drogą obliczeniowo gałąź formuły, gdy warunek na to nie wskazuje. Excel stosuje tzw. short-circuit evaluation — jeśli warunek jest fałszywy, druga, cięższa gałąź formuły w ogóle nie zostaje policzona. W praktyce oznacza to, że zamiast uruchamiać skomplikowaną logikę dla każdego wiersza, można ją owinąć w prosty warunek (np. sprawdzający, czy wiersz w ogóle zawiera dane) i wykonywać ją tylko tam, gdzie faktycznie jest potrzebna.

Te same zasady rozsądku dotyczą też wyboru formatu pliku. W rozbudowanych skoroszytach, liczących setki arkuszy i miliony formuł, warto zapisywać plik jako .xlsb (Excel Binary Workbook) zamiast .xlsx — format binarny zajmuje mniej miejsca na dysku i zauważalnie szybciej się otwiera oraz zapisuje. Nie oznacza to, że każdy plik powinien być XLSB: przy prostych arkuszach .xlsx pozostaje naturalnym wyborem, zwłaszcza gdy liczy się kompatybilność z innymi narzędziami. W dużych aplikacjach Excelowych to jednak jeden z tych drobnych, świadomych wyborów architektonicznych, które realnie wpływają na komfort pracy.

Kilka praktycznych zasad przy budowaniu dużego modelu:

• LET — używaj do porządkowania i upraszczania logiki, nie do upychania całego modelu w jednej komórce.
• LAMBDA — buduj nią własne funkcje biznesowe tam, gdzie wcześniej sięgało się po VBA, ale zadanie nie wymaga integracji poza arkuszem.
• JEŻELI jako strażnik — owijaj nim drogą obliczeniowo logikę, żeby dzięki short-circuit evaluation Excela uruchamiała się tylko tam, gdzie faktycznie jest potrzebna.
• Podział logiki — złożoną logikę dziel rozsądnie między LET, LAMBDA, kolumny pomocnicze i inne warstwy rozwiązania, tak aby model pozostał czytelny i możliwy do utrzymania.
• Format pliku — przy dużej skali (setki arkuszy, miliony formuł, dużo VBA) zapisuj jako .xlsb; przy prostych arkuszach zostań przy .xlsx.

Excel jako miejsce do prototypowania: case study LeadFold

Zanim padnie decyzja o budowie dedykowanej aplikacji, często warto zbudować pierwszą wersję rozwiązania właśnie w Excelu — miejscu, w którym można szybko przetestować nowy pomysł, zanim zainwestuje się w budowę pełnej aplikacji. Model logiki biznesowej, dashboard operacyjny czy nawet szkielet hurtowni danych da się poskładać szybciej niż w klasycznym stosie technologicznym — wykresy, wskaźniki KPI i logikę obliczeniową można ułożyć obok siebie i od razu przetestować na prawdziwych danych, bez czekania na frontend czy schemat bazy.

Dobrze pokazuje to historia LeadFold, platformy do automatyzacji sprzedaży B2B. Projekt zaczął się właśnie w Excelu — to tam po raz pierwszy testowano integrację z API modeli językowych i budowano mechanikę dynamicznych promptów: system, w którym prompt do AI składa się na bieżąco z danych o kliencie i jest edytowalny wprost w komórkach arkusza, bez udziału programisty, zamiast być sztywnym, gotowym szablonem. Excel posłużył więc jako poligon doświadczalny — pozwolił szybko sprawdzić, czy pomysł na dynamiczne prompty i generowanie spersonalizowanych ofert w ogóle ma sens biznesowy, zanim ktokolwiek napisał linijkę kodu docelowej aplikacji.

Zdobyte przy tym doświadczenie posłużyło do budowania kolejnych, nowych rozwiązań. Dynamiczne prompty, scoring czy automatyzacja z kontrolą, przetestowane najpierw w Excelu, znalazły potem zastosowanie w bardziej rozbudowanych, produkcyjnych systemach — część z nich można zobaczyć w portfolio Origami Effect.

To samo podejście sprawdza się przy prototypowaniu dashboardów i dedykowanych hurtowni danych w ogóle. Zamiast od razu projektować schemat bazy i interfejs webowy, można w Excelu szybko rozłożyć strukturę danych, dograć wykresy i KPI, sprawdzić, czy taki układ w ogóle ma sens biznesowy — a dopiero sprawdzoną koncepcję przenieść do docelowej technologii. Nie każde rozwiązanie musi więc od razu zaczynać się jako pełny system. Czasami najszybszą drogą do sprawdzenia pomysłu jest arkusz, który po walidacji koncepcji świadomie się „wyrasta" i oddaje pałeczkę bardziej dopasowanej technologii.

Excel jako platforma do pracy z AI

Kolejnym etapem tej ewolucji jest wykorzystanie Excela jako środowiska do orkiestracji modeli sztucznej inteligencji oraz nadawania danym formy narracyjnej — czyli zamiany suchych liczb w zrozumiały opis, interpretację czy rekomendację.

W praktyce oznacza to bezpośrednie podłączenie arkusza do API różnych modeli językowych (Claude, Grok, OpenAI i inne) i wysyłanie tego samego zestawu danych oraz tego samego promptu do kilku z nich jednocześnie. Odpowiedzi wracają do skoroszytu i można je porównać obok siebie, bez przełączania się między aplikacjami.

Dobrze pokazuje to arkusz „Clio – AI Prompts" ze skoroszytu Artemis, modelu inwestycyjnego dla projektu deweloperskiego. Każda kolumna to osobny prompt przypisany do konkretnego modelu (Claude, Grok, gpt-4o-mini), z zdefiniowanym zakresem danych źródłowych (worksheet i range) oraz limitem tokenów. Jeden prompt każe modelowi wcielić się w konsultanta ds. kosztów budowy i ocenić breakdown CAPEX dla konstrukcji i przegród budynku, inny — w konsultanta MEP i zweryfikować pozycje instalacji technicznych, kolejny — w specjalistę od wykończeń wnętrz czy FF&E. Każdy z nich odbiera inny zakres komórek z arkuszy „Floors — Definitions&Size" czy „Investment-Construct&Elevation" i zwraca ustrukturyzowaną ocenę: czy koszt jednostkowy mieści się w widełkach rynkowych, czy pozycja w ogóle powinna się tam znaleźć, co brakuje w zestawieniu.

Ma to sens przede wszystkim tam, gdzie liczby z arkusza wymagają interpretacji lub narracji — na przykład przy analizie CAPEX, ocenie ryzyk czy komentarzu do wyników modelu finansowego. Prompt i zakres danych pozostają zarządzane bezpośrednio z Excela, więc zmiana pytania albo źródła danych zajmuje sekundy, a nie wymaga przechodzenia przez osobne narzędzie.

W tym układzie Excel przestaje być tylko odbiorcą gotowych wyników z AI. Staje się warstwą, w której definiuje się pytania, dostarcza kontekst liczbowy i zestawia odpowiedzi różnych modeli w jednym miejscu.

To rozwiązanie pozwala oswoić się z potencjałem AI bez konieczności budowania od razu dedykowanej aplikacji webowej. Zamiast sięgać po gotowe narzędzia, można zbudować własne rozwiązanie dopasowane dokładnie do specyfiki firmy — trzeba je oczywiście najpierw sprawdzić i przetestować na prawdziwych przypadkach. Przetestowanie orkiestracji promptów bezpośrednio w arkuszu daje gotową matrycę logiczną, którą w przyszłości można łatwo przenieść do produkcyjnych dashboardów w React.

Od arkusza do aplikacji

W praktyce można wyobrazić sobie kilka poziomów rozwoju rozwiązania:

• Arkusz — dane + formuły.
• Model — dane + logika biznesowa + scenariusze.
• Narzędzie — model + interfejs + automatyzacja.
• Aplikacja biznesowa — narzędzie + kontrola procesu + integracje.
• System — aplikacja + baza danych + API + inne aplikacje + orkiestracja AI.

Nie każda firma potrzebuje wszystkich tych poziomów. Czasami wystarczy dobrze zaprojektowany arkusz. Czasami potrzebny jest zaawansowany model finansowy. Czasami warto stworzyć dedykowaną aplikację Excel. A czasami Excel powinien być tylko jedną z warstw większego systemu.

Kluczowe jest określenie, jakiego problemu biznesowego rozwiązanie ma dotyczyć, a dopiero później wybór technologii.

Dobrze pokazuje to Quantis — system analityczny do zarządzania promocjami i cenami, który tę samą logikę doprowadził już do etapu pełnoprawnej aplikacji webowej. Dla każdej promocji system liczy m.in. lift sprzedażowy, udział sprzedaży promocyjnej i elastyczność cenową, a AI zamienia te liczby w czytelny komentarz: ocenę, czy promocja rzeczywiście napędza sprzedaż, czy klienci nie uzależnili się od rabatu, oraz konkretne rekomendacje dla działu handlowego. To ten sam mechanizm co w Artemis — dane napędzają model, AI nadaje im formę zrozumiałą dla osoby podejmującej decyzję — tylko przeniesiony już poza sam Excel, do dedykowanego dashboardu.

Czym więc jest nowoczesny Excel?

Nowoczesny Excel wykracza daleko poza kolejną wersję starego narzędzia z odświeżonym interfejsem czy zwykły „Excel z makrami".

To sposób projektowania rozwiązań, w którym Excel jest wykorzystywany tam, gdzie daje największą wartość, a pozostałe elementy systemu są budowane w technologiach odpowiednich do konkretnego zadania.

Excel może być:

• arkuszem
• modelem finansowym
• aplikacją operacyjną
• interfejsem użytkownika
• silnikiem obliczeniowym
• klientem API
• narzędziem automatyzacji
• platformą do porównywania i wykorzystania modeli AI
• częścią systemu analitycznego

Granica nie przebiega więc między „Excelem" a „IT". Przebiega między ręcznym wykonywaniem procesu a rozwiązaniem, które ten proces automatyzuje i porządkuje.

Ta postawa ma dziś realne techniczne możliwości. Excel jest częścią ekosystemu Microsoft 365 i może łączyć się z narzędziami takimi jak Power Query, VBA, Power Automate, bazy danych czy usługi API. Dzięki temu arkusz może stać się nie tylko miejscem analizy, lecz także interfejsem i punktem startowym procesu biznesowego.

Nowoczesny Excel to przede wszystkim narzędzie w rękach osoby, która zna swój proces na tyle dobrze, by dostrzec problem i mieć odwagę go rozwiązać — a nie zbiór modnych funkcji czy próba zastąpienia każdego systemu jednym skoroszytem.

Czasem rozwiązaniem będzie prosty arkusz. Czasem model z automatyzacją. Czasem prototyp, z którego wyrośnie aplikacja, baza danych albo większy system. Ważne, że wszystko zaczyna się od decyzji, by nie rozłożyć rąk i nie uznać ręcznej pracy za nieuniknioną.