Dlaczego przeszedłem z finansów do programowania i jak mi to pomaga

Przez 3 lata byłem księgowym w Mars. General Ledger, Intercompany, Fixed Assets - na SAP-ie, w korporacji, gdzie każda złotówka musi się zgadzać do grosza. Od 8 lat programuję i buduję integracje API. I te lata w finansach to moja największa przewaga zawodowa.

Nie planowałem zostać programistą. Nie miałem takiego planu pięcioletniego. Nie siedziałem wieczorami na kursach Udemy marząc o Silicon Valley. Historia była dużo prostsza - i dużo bardziej typowa niż się wydaje.

Księgowość w Mars: fabryka precyzji

Zaczynałem w Mars na stanowisku księgowego. Dla tych, którzy nie znają struktury dużej korporacji: Mars to nie jest firma, gdzie księgowy siedzi sam z jednym zestawieniem. To globalna machina z centrum usług wspólnych, gdzie obsługujesz dziesiątki spółek jednocześnie.

Mój obszar to był General Ledger - księga główna. To serce każdego systemu finansowego. Odpowiadałem za zamknięcia miesięczne, uzgodnienia kont, reklasyfikacje. Do tego Intercompany - rozliczenia między spółkami w grupie. Jeśli Mars Polska kupował surowce od Mars Niemcy, to ja pilnowałem, żeby obie strony transakcji się zgadzały. W skali globalnej, z dziesiątkami spółek, to jest logistyczny koszmar, który musi zamknąć się co miesiąc co do grosza.

Fixed Assets - środki trwałe - to był trzeci filar. Amortyzacja, likwidacje, przeszacowania, inwentaryzacje. Brzmi nudno? Może. Ale to nauczyło mnie czegoś, czego żaden bootcamp programistyczny nie uczy: precyzji w myśleniu o danych. W finansach nie ma "mniej więcej". Albo bilans się zgadza, albo nie. Albo uzgodnienie międzyfirmowe bije się na zero, albo masz problem.

Wszystko to na SAP-ie. Kto pracował na SAP-ie wie, że to nie jest system intuicyjny. To potężne narzędzie, które wymaga znajomości transakcji, struktury danych, hierarchii kont. Kiedy dziś projektuję schemat bazy danych dla systemu finansowego, w głowie mam strukturę SAP-a - i wiem, dlaczego pewne rzeczy są zaprojektowane tak a nie inaczej.

Moment przełączenia: kiedy VBA zmienił perspektywę

Po jakimś czasie awansowałem na koordynatora standaryzacji procesów. Brzmi korporacyjnie - bo było korporacyjne. Ale w praktyce oznaczało to, że zarządzałem zespołem, który pisał makra VBA do automatyzacji raportów finansowych.

I tam coś się przełączyło.

Pamiętam konkretny moment. Jeden z raportów miesięcznych - uzgodnienie sald międzyfirmowych - wymagał ręcznego kopiowania danych z kilku źródeł, porównywania, zaznaczania różnic, formatowania. Proces trwał około 40 minut. Każdego miesiąca. Dla każdej pary spółek.

Napisałem makro VBA, które robiło to samo w 3 minuty. Kliknięcie jednego przycisku - dane zaciągnięte, porównane, różnice oznaczone kolorem, raport sformatowany i gotowy do wysyłki.

To nie było odkrycie programowania. To było odkrycie tego, co programowanie może zrobić dla ludzi, którzy nie programują. Zobaczyłem, jak zespół finansowy - mądre osoby, z certyfikatami ACCA i CMA - traci godziny na rzeczy, które komputer może zrobić w sekundy. I zacząłem pisać więcej VBA niż księgować.

To był pierwszy sygnał. Drugi przyszedł, kiedy zacząłem rozumieć, że ograniczenia VBA i Excela to nie jest problem narzędzia - to problem skali. Żeby naprawdę zautomatyzować procesy finansowe, potrzebowałem czegoś więcej. Potrzebowałem API, baz danych, systemów, które rozmawiają ze sobą bez ręcznego eksportu do CSV.

Przejście do IT: bez skoku w ciemno

Nie rzuciłem pracy w piątek, żeby w poniedziałek zostać programistą. Przejście było stopniowe i każdy krok budowany na poprzednim.

Z Mars przeszedłem do TPA Poland - firmy z sektora outsourcingu finansowego. Ale nie na stanowisko programisty. Zaczynałem jako ekspert od automatyzacji. Znałem procesy finansowe, znałem ich bolączki, a do tego umiałem pisać skrypty. To była kombinacja, której TPA potrzebowało.

Stałem się ekspertem od dwóch systemów: Saldeo Smart (platforma do obiegu dokumentów księgowych) i Enova365 (system ERP). Konfigurowałem, integrowałem, automatyzowałem. I coraz częściej dochodziłem do momentu, gdzie gotowe narzędzia nie wystarczały. Potrzebowałem napisać coś od zera.

Wtedy pojawiło się .NET Core. Pierwsza prawdziwa aplikacja API - nie makro w Excelu, nie skrypt w PowerShell, ale serwis, który wystawiał endpointy, łączył się z bazą danych, przetwarzał dane finansowe i zwracał wyniki w JSON-ie. To był moment, kiedy poczułem, że to jest moja ścieżka.

Z TPA Poland przeszedłem do Digital TPA jako główny programista backend. Nadal w sektorze outsourcingu finansowego - ale już po drugiej stronie. Nie konfiguruję systemów. Buduję je.

Ścieżka: finanse, automatyzacja, konfiguracja systemów, programowanie, full-stack. Każdy etap wynikał z poprzedniego. Żaden nie był stratą czasu.

Co mi daje doświadczenie z finansów - konkretnie

Tu jest sedno sprawy. Nie chodzi o to, że "różne doświadczenia są wartościowe" - to truizm, który nic nie znaczy. Chodzi o konkretną, mierzalną przewagę.

Rozumiem domenę bez onboardingu. Kiedy dostaję zlecenie na integrację systemu księgowego, nie zaczynam od pytania "co to jest konto kosztów". Wiem, jak działa plan kont. Wiem, że konto syntetyczne 401 to amortyzacja, a 409 to pozostałe koszty rodzajowe. Wiem, co to uzgodnienie międzyfirmowe i dlaczego eliminacje konsolidacyjne to koszmar na koniec kwartału. Wiem, dlaczego data waluty i data księgowania to dwie różne rzeczy - i dlaczego pomylenie ich w raporcie cashflow może dać wynik odchylony o miliony.

Klient mówi "potrzebuję raportu cashflow z podziałem na centra kosztów" - nie muszę googlować, co to centra kosztów. Mówi "interfejs do importu wyciągów MT940" - wiem, co to MT940, bo sam je uzgadniałem ręcznie w SAP-ie.

Oszczędza to tygodnie. Nie na kodowaniu - na zrozumieniu. Programista bez doświadczenia w finansach napisze ten sam kod co ja. Technicznie może być nawet lepszy. Ale najpierw spędzi dwa tygodnie na zrozumieniu domeny. Będzie pytał klienta o rzeczy, które dla księgowego są oczywiste. Będzie projektował model danych, który nie uwzględnia przypadków brzegowych znanych każdemu, kto kiedyś robił zamknięcie miesiąca pod presją czasu. Ja zaczynam od kodu, bo domenę już znam.

Rozmawiam z klientem jego językiem. To jest niedoceniana przewaga. Kiedy siadam z dyrektorem finansowym i omawiam integrację, nie potrzebuję tłumacza. Rozumiem jego problemy, bo sam je kiedyś miałem. Wiem, co go boli przy zamknięciu miesiąca. Wiem, dlaczego raport, który spóźnia się o dwa dni, to nie jest drobnostka - to jest problem, który kaskaduje na cały kalendarz sprawozdawczy.

To buduje zaufanie szybciej niż jakiekolwiek portfolio na GitHubie.

Widzę błędy w danych, które inny programista przepuści. Kiedy testuję integrację i widzę fakturę z VAT-em 23% na usługi wewnątrzwspólnotowe - wiem, że coś jest nie tak. Kiedy saldo konta rozrachunkowego nie bije się z saldem w systemie źródłowym - nie traktuję tego jako "drobna rozbieżność". Wiem, że w finansach drobnych rozbieżności nie ma.

Kilka frontów, jedna domena

Pracuję teraz na trzech frontach jednocześnie. Backend w Digital TPA, integracje API i AI dla DBA Finanse, własny SaaS Budda.

W Digital TPA - outsourcing finansowy. Buduję systemy, które obsługują procesy księgowe dla dziesiątek klientów. Moje doświadczenie z Mars, gdzie obsługiwałem te procesy ręcznie, bezpośrednio przekłada się na to, jak projektuję architekturę tych systemów.

DBA Finanse - integracje API i rozwiązania AI. Tu łączę systemy, które wcześniej nie rozmawiały ze sobą. Import danych z jednego ERP do drugiego, automatyczna klasyfikacja dokumentów, ekstrakcja danych z faktur. Znajomość struktury dokumentów finansowych - co jest na fakturze, co jest na wyciągu, jakie pola są obowiązkowe, a jakie opcjonalne - to wiedza, którą zdobywałem przez lata pracy w finansach.

Budda - mój własny SaaS dla branży budowlanej. Pozornie daleko od finansów. Ale kiedy zagłębiasz się w potrzeby firmy budowlanej, okazuje się, że połowa problemów to problemy finansowe: kosztorysy, faktury częściowe, rozliczenia podwykonawców, retencje, kaucje gwarancyjne. To nadal jest język, który rozumiem natywnie.

Rada dla tych, którzy zaczynali gdzie indziej

Widzę w branży IT dwa typy ludzi, którzy przeszli z innej dziedziny. Jedni traktują swoje poprzednie doświadczenie jako bagaż - coś, co ich spowolniło, lata stracone zanim "w końcu" trafili na właściwą ścieżkę. Drudzy traktują to jako fundament.

Bądź w drugiej grupie.

Jeśli byłeś logistykiem i teraz programujesz - znasz łańcuch dostaw lepiej niż ktokolwiek w Twoim zespole deweloperskim. Jeśli byłeś lekarzem - rozumiesz procesy kliniczne, które dla programisty są czarną skrzynką. Jeśli pracowałeś w HR - wiesz, jak naprawdę wyglądają procesy kadrowe, nie jak wyglądają w dokumentacji wymagań.

To jest Twoja domena. To jest coś, czego programista "od zawsze" nie ma i nie nauczy się z tutoriala ani z dokumentacji API. Dokumentacja powie mu, jakie endpointy ma system. Nie powie mu, dlaczego księgowy robi tę operację o 23:00 ostatniego dnia miesiąca i dlaczego system musi to obsłużyć bez timeoutu.

Kilka konkretnych rad:

Nie ukrywaj poprzedniego doświadczenia w CV. Wiele osób przechodzących do IT skraca sekcję o poprzedniej karierze do jednej linijki. Błąd. Rozwiń ją. Pokaż, jak Twoja domena łączy się z technologią.

Szukaj projektów na styku. Twoja największa wartość jest tam, gdzie Twoja domena spotyka się z kodem. Ja nie buduję gier komputerowych - buduję systemy finansowe. Bo tam moja przewaga jest największa.

Nie porównuj się z ludźmi, którzy programują od liceum. Oni mają na Ciebie 10 lat przewagi w algorytmach. Ty masz na nich 10 lat przewagi w rozumieniu prawdziwych problemów biznesowych. To nie jest gorsze - to jest inne. I dla wielu klientów cenniejsze.

Ucz się technologii, ale nie zapominaj domeny. Trzymaj rękę na pulsie w swojej poprzedniej branży. Czytaj, co się zmienia w przepisach, w standardach, w narzędziach. Ta wiedza się dezaktualizuje - ale odświeżanie jej jest dużo tańsze niż budowanie od zera.

Podsumowanie

Moja ścieżka nie była prosta ani zaplanowana. Z księgowości w Mars, przez automatyzację VBA, przez konfigurację systemów w TPA Poland, do backendowego developmentu w Digital TPA i własnego SaaS-a. Każdy etap wynikał z poprzedniego. Żaden nie był objazdem.

Finanse dały mi coś, czego nie da żaden kurs programowania: rozumienie domeny, w której buduję oprogramowanie. Rozumienie problemów klienta, zanim otworzy usta. Rozumienie, dlaczego pewne dane muszą się zgadzać co do grosza, a inne mogą mieć tolerancję.

Jeśli przeszedłeś do IT z innej branży - nie traktuj tego jako słabości. To Twoja domena i Twoja przewaga. Używaj jej.

Prowadzę działalność Deadline Maciej Woźniczka - buduję integracje API, rozwiązania AI i prototypy MVP/PoC, szczególnie dla firm z sektora finansowego i outsourcingowego. Jeśli Twoja firma potrzebuje kogoś, kto rozumie zarówno kod jak i procesy biznesowe - odezwij się. Pogadamy konkretnie, bez slajdów.