Dług technologiczny w arkuszu - ukryty koszt zarządzania firmą w Excelu

Excel na starcie firmy jest dobrym wyborem — do momentu, w którym tymczasowy plik cicho staje się systemem operacyjnym całej organizacji. To przejście nie ma daty i nie przychodzi z ostrzeżeniem. Ma za to swoją cenę, płaconą w walutach, których nie widać w żadnym budżecie. ‍

June 25, 2026

Marcin Koszałka

‍Plik nazywa się „zamowienia_2026_v3_FINAL_poprawione.xlsx", waży 40 MB i otwiera się pół minuty. Korzysta z niego osiem osób, z czego dwie wiedzą, jak działa makro przeliczające marże, a jedna z nich właśnie złożyła wypowiedzenie. Obok żyje drugi plik ze stanami magazynowymi, który zgadza się z pierwszym mniej więcej w 90 procentach, i nikt nie potrafi powiedzieć, skąd bierze się pozostałe 10. Co miesiąc ktoś robi kopię „na wszelki wypadek", więc w katalogu sieciowym leży kilkanaście wersji o nazwach, które już dawno przestały cokolwiek znaczyć.

Żadna z tych rzeczy nie wydarzyła się z dnia na dzień i żadna nie jest niczyją winą. Nikt nie podjął decyzji „zbudujmy krytyczny system operacyjny w arkuszu kalkulacyjnym". Plik po prostu rósł razem z firmą, dokładano do niego kolejne zakładki w odpowiedzi na kolejne realne potrzeby, aż w którymś momencie - niezauważonym - przestał być pomocą, a stał się fundamentem. Tak wygląda firma, która urosła szybciej niż jej narzędzia.

To dość częsta sytuacja i wbrew pozorom nie świadczy źle o organizacji. Świadczy o tym, że firma działała: sprzedawała, rosła, rozwiązywała problemy najszybszym dostępnym sposobem. Kłopot polega na tym, że narzędzie dobrane do jednej skali rzadko nadaje się do następnej, a moment, w którym trzeba je wymienić, nie przychodzi z ostrzeżeniem. Ten tekst jest o tym, jak rozpoznać, że ten moment nadszedł - i co zrobić, zanim koszt zacznie rosnąć szybciej niż firma.

Excel jako środowisko testowe procesów

Zacznijmy od rzeczy, którą łatwo przeoczyć w tekście, który za chwilę będzie Excel krytykował: na wczesnym etapie firmy arkusz jest dobrym wyborem. Nie kompromisem ani złem koniecznym.

Mała organizacja dopiero wypracowuje swoje procesy. Struktura danych zmienia się co kilka tygodni, role się przesuwają, część pomysłów okazuje się nietrafiona i trzeba je wycofać. W takim środowisku największą wartością narzędzia jest to, że zmianę można wprowadzić natychmiast i bez kosztów. Dodanie kolumny, przebudowa zestawienia, nowy sposób liczenia marży - wszystko to zajmuje minuty i nie wymaga niczyjej zgody ani sprintu deweloperskiego. Arkusz pełni wtedy funkcję środowiska testowego, w którym firma prototypuje swój przyszły model operacyjny, nie ponosząc kosztu utrwalenia rozwiązań, których za kwartał może już nie być.

Do tego dochodzi niski próg automatyzacji prostych czynności. Formuły, tabele przestawne, Power Query, makra VBA - to wszystko leży w zasięgu osoby, która nie jest programistą, ale rozumie swój fragment biznesu. Cykliczny raport z powtarzalnego źródła danych można zautomatyzować w kilka godzin, bez stawiania zlecenia w dziale IT, którego być może jeszcze nie ma. Dla zespołu liczącego kilka osób to po prostu wystarcza, a często wystarcza z naddatkiem.

Kłopot zaczyna się w jednym konkretnym punkcie: gdy prototyp cicho staje się produkcją. Plik, który miał być tymczasowy, obrasta zakładkami, makrami i zależnościami między skoroszytami. Rośnie razem z firmą i z każdym kwartałem staje się bardziej bezwładny. Każda zmiana struktury wymaga teraz przejrzenia wszystkich formuł, które się do niej odwołują - a tych są setki i nikt nie ma ich pełnej mapy. Autorzy najstarszych makr często już w firmie nie pracują, więc fragmenty arkusza działają na zasadzie „nie ruszamy, bo działa". Elastyczność, która była największą zaletą na starcie, po cichu zamienia się w koszt utrzymania. To wciąż ta sama cecha - łatwość zmiany - tyle że teraz każda zmiana niesie ryzyko, że coś gdzie indziej przestanie się liczyć.

Sygnały, że granica została przekroczona

Trudność polega na tym, że to przejście nie ma daty. Nie ma dnia, w którym arkusz „przestaje wystarczać" - jest tylko narastające tarcie, do którego zespół się przyzwyczaja, aż przestaje je zauważać. Dlatego zamiast czekać na jeden moment, warto wypatrywać konkretnych sygnałów. Każdy z nich osobno da się zracjonalizować. Dopiero razem układają się w obraz organizacji, która przerosła swoje narzędzie.

‍

Brak integracji z systemami księgowymi i KSeF

Arkusz nie wystawi faktury ustrukturyzowanej i nie odbierze jej przez API Krajowego Systemu e-Faktur. Firma fakturująca w Excelu musi ręcznie przenosić dane do programu księgowego, a stamtąd dalej do KSeF - i to samo robić w drugą stronę, gdy trzeba dopasować płatność do dokumentu. Każde takie przejście to nie tylko dodatkowa praca, ale przede wszystkim miejsce, w którym powstaje błąd: przeniesiona nie ta kwota, pominięta pozycja, faktura wystawiona dwa razy. Dopóki KSeF był opcją, dało się to traktować jako niewygodę. Wraz z wejściem obowiązku korzystania z systemu ten sam problem przestaje być kwestią wygody, a staje się ryzykiem regulacyjnym - bo proces oparty na ręcznym przepisywaniu nie skaluje się do wolumenu i tempa, jakich wymaga obowiązkowe e-fakturowanie.

Brak realnego bezpieczeństwa danych

Plik xlsx można skopiować na pendrive, wysłać mailem albo wgrać na prywatny dysk i żaden mechanizm tego nie odnotuje. Nie ma kontroli dostępu na poziomie pojedynczego rekordu, nie ma logu zmian, nie ma realnej możliwości odebrania uprawnień osobie odchodzącej z firmy - bo kopia, którą zdążyła sobie zapisać, zostaje przy niej. Dla organizacji przetwarzającej dane osobowe oznacza to praktyczną niemożność wykazania zgodności z RODO w razie incydentu: nie da się odpowiedzieć na pytanie „kto, kiedy i co zobaczył", skoro system takiej ewidencji w ogóle nie prowadzi.

Sprawa robi się poważniejsza, gdy firma podlega dyrektywie NIS2 albo dostarcza usługi podmiotom, które jej podlegają. Wymogi systematycznego zarządzania ryzykiem, kontroli dostępu i raportowania incydentów są w praktyce nie do spełnienia w środowisku opartym na plikach - nie dlatego, że ktoś jest niedbały, ale dlatego, że plik z natury nie udostępnia narzędzi, które te wymogi zakładają. Podobnie wygląda to z certyfikacją ISO 27001, coraz częściej wymaganą w przetargach i poważniejszych relacjach B2B. Żaden audytor nie zaakceptuje systemu zarządzania bezpieczeństwem informacji, w którym repozytorium danych operacyjnych jest katalogiem skoroszytów na dysku sieciowym, a polityka dostępu sprowadza się do tego, kto zna ścieżkę do folderu.

Brak kompleksowości

Standardowe możliwości arkusza kończą się szybciej, niż się wydaje. Automatyczne powiadomienie kontrahenta o zmianie statusu zamówienia. Rezerwacja stanu magazynowego w momencie potwierdzenia sprzedaży, tak żeby ten sam towar nie został obiecany dwóm klientom. Walidacja danych wprowadzanych równolegle przez kilkanaście osób. Połączenie z systemem kurierskim, żeby etykieta i numer przesyłki powstawały same. Każda z tych rzeczy jest technicznie wykonalna w Excelu - ale każda wymaga pracy programisty: VBA, skryptów, czasem osobnej aplikacji pośredniczącej, która spina arkusz z resztą świata.

I tu pojawia się sedno: dokładając te elementy jeden po drugim, firma w praktyce finansuje budowę własnego systemu ERP na raty. Tyle że buduje go bez architektury, bez dokumentacji, bez testów i bez żadnej gwarancji ciągłości - bo całość trzyma się na wiedzy kilku osób i na założeniu, że makra nie przestaną nagle działać po aktualizacji pakietu Office. To najdroższy możliwy sposób dojścia do systemu, który i tak na końcu trzeba będzie zbudować porządnie.

Brak analityki opartej na sprzężeniu zwrotnym

W poprawnie zorganizowanej firmie obieg informacji jest dwukierunkowy. W dół idą produkt i decyzje, w górę wraca rzetelna informacja o tym, co faktycznie się wydarzyło. Zarząd ustala cele, a z poziomu operacji wraca obraz realizacji: rzeczywiste marże, rotacja zapasów, wąskie gardła, odchylenia od planu. Ta pętla sprzężenia zwrotnego jest tym, co pozwala firmą zarządzać, a nie tylko ją obserwować.

Excel tę pętlę przerywa - nie dlatego, że nie potrafi liczyć, tylko dlatego, że dane są rozproszone. Żeby zobaczyć pełny obraz, ktoś musi ręcznie zebrać liczby z kilku plików, ujednolicić formaty, pogodzić rozbieżności i zagregować całość w jeden raport. Zanim ten raport trafi na biurko osoby decyzyjnej, mija nierzadko kilka tygodni, a opisuje on stan sprzed jeszcze dłuższego czasu. W efekcie decyzje zapadają na podstawie obrazu sprzed miesiąca albo - gdy nie ma czasu czekać - zwyczajnie na wyczucie. Firma cały czas generuje dane, których nie zdąży użyć, zanim się zdezaktualizują.

Trzy rachunki, których nikt nie wystawia

Najtrudniejsze w tym wszystkim jest to, że koszt utrzymywania firmy w arkuszu nie pojawia się w żadnej pozycji budżetu. Excel jest „za darmo" - licencja już dawno opłacona, plik nic nie kosztuje. Rachunek przychodzi gdzie indziej, w trzech walutach, których księgowość nie sumuje.

‍

Pierwszy to czas zespołu. Godziny spędzane co miesiąc na ręcznym zbieraniu danych, uzgadnianiu rozbieżności między plikami, przepisywaniu faktur i tłumaczeniu nowym osobom, „jak to działa". To praca, która nie tworzy żadnej wartości - tylko podtrzymuje działanie narzędzia - a wykonują ją zwykle ci, których czas jest najcenniejszy, bo to oni jako jedyni rozumieją całość.

Drugi to ryzyko. Błąd w przepisanej kwocie, faktura niezgłoszona do KSeF na czas, kopia danych osobowych na prywatnym dysku byłego pracownika. Każde z tych zdarzeń ma niezerowe prawdopodobieństwo i potencjalnie wysoką cenę - karę, utracony kontrakt, nieudany audyt. Ryzyko nie jest kosztem, dopóki się nie zmaterializuje, dlatego tak łatwo je ignorować. Ale to nie znaczy, że go nie ma; znaczy tylko, że płaci się je nieregularnie i naraz.

Trzeci, najtrudniejszy do zmierzenia, to gorsze decyzje. Firma, która działa na danych sprzed miesiąca, reaguje wolniej niż konkurencja patrząca na żywe liczby. Nie zauważa w porę, że marża na jednej grupie produktów spadła, że zapas innej rośnie szybciej niż sprzedaż, że jeden kanał zaczyna przynosić straty. Tego kosztu nie da się zafakturować, bo polega on na okazjach, których nie wykorzystano, i problemach, które urosły, zanim ktokolwiek je zauważył.

Żaden z tych trzech rachunków nie jest widoczny w zestawieniu kosztów. Wszystkie trzy są realne.

‍

Tańsze alternatywy i koszt długu technologicznego

Gdy firma uzna w końcu, że arkusz przestał wystarczać, naturalnym odruchem jest szukanie rozwiązania pośredniego - czegoś tańszego i prostszego niż „prawdziwy" system. Zwykle chodzi o jeden z trzech wariantów: tani system pudełkowy kupiony w abonamencie, aplikację napisaną na zamówienie przez lokalnego dewelopera, albo zestaw narzędzi SaaS spiętych ze sobą automatyzacjami - jeden program do faktur, drugi do magazynu, trzeci do CRM, a między nimi łańcuch integracji.

Każdy z tych wariantów wygląda inaczej, ale wszystkie łączy ten sam mechanizm: niska cena wejścia jest w istocie kredytem. Firma płaci mało dziś, w zamian zaciągając zobowiązanie, które spłaci później - w momencie, gdy prowizoryczne rozwiązanie trzeba będzie sprofesjonalizować. Ten moment przychodzi zawsze. Można go odsunąć, nie da się go uniknąć, a przybiera on jedną z trzech postaci.

Pierwsza to awaria. Pada integracja po cichej zmianie API u jednego z dostawców, deweloper, który pisał aplikację, przestaje odbierać telefon, kończy się wsparcie dla używanej wersji oprogramowania. Firma odkrywa wtedy, że nie ma ani dokumentacji, ani nikogo, kto zna kod na tyle, by go bezpiecznie naprawić - a system, który stanął, obsługiwał właśnie sprzedaż.

Druga to konieczność dokooptowania modułu, którego pierwotnie nie przewidziano. Najlepszym aktualnym przykładem jest obsługa KSeF. W systemie pudełkowym taki moduł może po prostu nie istnieć i trzeba czekać, aż dostawca go doda - jeśli w ogóle. U lokalnego dewelopera jego dopisanie oznacza ingerencję w kod nieruszany od lat, którego logiki nikt już dobrze nie pamięta. W układance z narzędzi SaaS to kolejne narzędzie do utrzymania i kolejne dwie integracje, które mogą paść - a wtedy wracamy do punktu pierwszego.

Trzecia to wzrost. Rozwiązanie zaprojektowane dla dziesięciu użytkowników i kilkuset zamówień miesięcznie musi nagle obsłużyć pięćdziesiąt osób i wolumen większy o rząd wielkości. Rzeczy, które działały „wystarczająco dobrze" przy małej skali - brak walidacji, ręczne kroki, milczące założenie, że wszyscy się znają i nie wejdą sobie w drogę - przy większej skali zamieniają się w codzienne błędy.

W każdym z tych scenariuszy pojawia się ten sam koszt: refactoring, czyli przebudowa rozwiązania tak, żeby nadawało się do dalszego rozwoju. I tu jest właściwe sedno całej sprawy: refactoring prowizorki kosztuje zwykle tyle samo co wdrożenie docelowego systemu, a często więcej. Obejmuje bowiem nie tylko nową budowę, ale też odtworzenie wiedzy o tym, jak stara rzecz w ogóle działała, naprawę danych, które przez lata zdążyły się zniekształcić, i przeprowadzenie tego wszystkiego przy zachowaniu ciągłości operacyjnej - bo firma nie może na czas migracji przestać sprzedawać. Dług technologiczny działa jak każdy inny dług: im później go spłacasz, tym wyższe odsetki zdążyły narosnąć.

‍

Odoo jako odpowiedź na całą klasę problemów

Wymienione problemy nie są od siebie niezależne - wynikają z jednej przyczyny: dane i logika żyją w wielu miejscach, które nie wiedzą o swoim istnieniu. Rozwiązanie musi więc zaadresować je u źródła, czyli te miejsca scalić, a nie dokładać kolejne.

Odoo jest platformą ERP o otwartym kodzie, w której sprzedaż, zakupy, magazyn, produkcja, księgowość, HR i e-commerce działają jako moduły na jednej, wspólnej bazie danych. To pozornie techniczny szczegół, ale z niego wynika cała reszta. Skoro wszystkie obszary korzystają z tych samych danych, znika cała kategoria pracy polegającej na przenoszeniu informacji między nimi - a wraz z nią znika klasa błędów, które przy tym przenoszeniu powstawały.

W praktyce wygląda to tak:

Potwierdzenie zamówienia automatycznie rezerwuje stan magazynowy i tworzy podstawę do wystawienia faktury.
Faktura trafia do księgowości bez przepisywania, a obsługa KSeF jest realizowana w module księgowym, a nie przez ręczny eksport do osobnego programu.

Uprawnienia definiuje się per rola i per rekord - jedna osoba widzi wszystko, inna tylko zamówienia swojego regionu - a każda istotna zmiana jest zapisywana w historii. Ten log to nie tylko porządek; to materiał dowodowy, którego oczekuje audytor przy RODO, NIS2 czy ISO 27001, a którego arkusz z definicji dostarczyć nie umie. Pętla sprzężenia zwrotnego, o której była mowa wcześniej, działa tu z samej konstrukcji: skoro dane agregują się na bieżąco, raport o sprzedaży, marżach czy rotacji jest widokiem na żywe dane, a nie zestawieniem składanym ręcznie raz w miesiącu.

Z perspektywy działu IT - albo osoby, która pełni jego rolę - istotne są dwie rzeczy.

Pierwsza to jedno środowisko do utrzymania zamiast zestawu plików, skryptów i subskrypcji, z których każda ma własne hasło, własną awarię i własnego dostawcę.
Druga to brak uzależnienia od jednego producenta: otwarty kod i standardowa baza danych oznaczają, że dane należą do firmy i dają się wyeksportować, a system można hostować w chmurze albo na własnej infrastrukturze, zależnie od wymogów.

Rozszerzenia realizuje się w udokumentowanym frameworku, więc rozwój systemu nie generuje długu tego samego typu, co doklejanie kolejnych makr do arkusza - bo powstaje w sposób, który da się potem przeczytać, przetestować i przekazać następnej osobie.

Warto przy tym uczciwie powiedzieć, że samo Odoo nie jest magią. Źle wdrożone potrafi powielić te same problemy w droższym opakowaniu - o czym za chwilę. Jego przewaga nie polega na tym, że „jest lepszym programem", tylko na tym, że adresuje całą opisaną klasę problemów jednocześnie, zamiast łatać każdy z osobna.

‍

Od czego zacząć: najpierw struktura, potem system

Najczęstszy błąd na tym etapie to potraktowanie wdrożenia ERP jako projektu czysto narzędziowego - jakby chodziło o wymianę jednego programu na drugi. Tymczasem arkusze budowane przez lata są czymś więcej niż zbiorem danych. Są zapisem faktycznej struktury operacyjnej firmy: tego, jak naprawdę krąży dokument, kto za co odpowiada, gdzie zapadają decyzje i w którym miejscu proces istnieje wyłącznie w czyjejś głowie. Dlatego pierwszym krokiem powinna być ocena tej struktury, a nie wybór oprogramowania.

Taka ocena prowadzi do jednego z dwóch wniosków. Jeśli analiza pokaże, że procesy odwzorowane w Excelu są zasadniczo zdrowe, a jedynym realnym problemem jest narzędzie, to zadanie sprowadza się do przeniesienia ich do systemu mniej więcej jeden do jednego. To wariant najszybszy i najtańszy - firma w gruncie rzeczy wie, jak chce pracować, brakuje jej tylko środowiska, które tę pracę uniesie.

Jeśli jednak struktura jest wadliwa - te same dane wprowadza się w trzech miejscach, odpowiedzialności się dublują albo nikną, część obiegu nie jest nigdzie zapisana - to przeniesienie jej do ERP niczego nie naprawi. Przeciwnie: utrwali istniejące wady w droższym i trudniejszym do zmiany opakowaniu, bo to, co w arkuszu dało się obejść ręcznie, w systemie staje się sztywną regułą. W tym wariancie właściwa kolejność jest inna: najpierw analiza procesów, potem ich uporządkowanie, i dopiero na końcu wdrożenie. Pominięcie środkowego kroku jest najdroższym skrótem, jaki można w tym miejscu wybrać.

Stąd bierze się rola, jakiej warto oczekiwać od partnera wdrożeniowego. Dobry partner powinien umieć tę ocenę przeprowadzić, zanim cokolwiek zacznie konfigurować - i uczciwie powiedzieć, który z dwóch wariantów dotyczy konkretnej firmy, nawet jeśli ten trudniejszy oznacza dla niego więcej pracy do uzgodnienia z klientem na samym wstępie. Wdrożenie, które zaczyna się od pytania „jakie macie procesy", a nie od „który moduł włączamy", ma po prostu większą szansę się zwrócić.

„Ale przecież Excel działa" - i inne uzasadnione wątpliwości

Każda firma rozważająca taką zmianę napotyka kilka tych samych zastrzeżeń. Żadne nie jest głupie i żadnego nie powinno się zbywać jednym zdaniem.

„Excel jest darmowy, a system kosztuje." To prawda co do faktury, ale nie co do całkowitego kosztu. Jak pokazaliśmy wyżej, arkusz ma swoją cenę - płaconą w czasie zespołu, ryzyku i jakości decyzji - tylko nie pojawia się ona w pozycji „oprogramowanie". Pytanie nie brzmi „darmowe kontra płatne", lecz „który koszt jest większy i który rośnie szybciej".

„Wdrożenie ERP to ogromny projekt, nie dla firmy naszej wielkości." Bywało tak kiedyś i wciąż bywa, gdy ktoś próbuje wdrożyć wszystko naraz. Modułowa budowa pozwala jednak zacząć od obszaru, który boli najbardziej - najczęściej jest to sprzedaż razem z magazynem i fakturowaniem - i dokładać kolejne elementy w miarę potrzeb. Dobrze poprowadzone wdrożenie jest etapowe, a nie jednorazowym skokiem na głęboką wodę.

„Nasi ludzie znają Excel, a nowego systemu będą musieli się uczyć." To realny koszt i nie należy go bagatelizować. Warto go jednak zestawić z kosztem alternatywnym: utrzymywaniem wiedzy o coraz bardziej zagmatwanym arkuszu w głowach kilku osób, z których każda jest pojedynczym punktem awarii. System, którego trzeba nauczyć się raz, bywa tańszy niż arkusz, którego trzeba uczyć każdą nową osobę od zera i którego i tak nikt nie rozumie w całości.

Co z tego wynika

Excel pozostaje dobrym środowiskiem dla firmy, która dopiero kształtuje swoje procesy - i nie ma powodu z niego rezygnować, dopóki tę funkcję pełni. Rzecz w tym, by zauważyć moment, w którym przestaje być środowiskiem testowym, a zaczyna być systemem operacyjnym, na którym opiera się działanie całej organizacji.

Firma, która ten moment przegapi, nie dostanie za to rachunku w żadnym konkretnym miesiącu. Zapłaci go inaczej: czasem zespołu zużywanym na podtrzymywanie narzędzia, ryzykiem regulacyjnym, które tli się aż do incydentu, i decyzjami podejmowanymi na podstawie danych, które zdążyły się zdezaktualizować. Te koszty nie są widoczne w żadnym budżecie - co nie znaczy, że nie istnieją. Znaczy tylko, że nikt ich nie zsumował.

Najlepszy moment, żeby spłacić dług technologiczny, był wtedy, gdy zaciągano go nieświadomie. Drugi najlepszy jest teraz - zanim odsetki urosną.