Procesy nie wróciły. Jak przenieść obieg dokumentów na nowy system, nie zatrzymując firmy

Kiedy dostawca systemu ERP przywrócił moduł, który wcześniej wyłączył z powodów, których nie znam, mógłbym odetchnąć i wrócić do starego obiegu dokumentów. Nikt nie wrócił. Ludzie, którzy codziennie pracują na dokumentach, zostali w nowym obiegu, który powstał w międzyczasie, trochę z wyboru, a trochę z musu. To najlepszy test wdrożenia, jaki znam, i nie da się go zaplanować.

Ten tekst jest o tym, jak do tego doszło. Nie o technice, tylko o kolejności. Bo przenieść działający proces na nowy system, nie zatrzymując firmy, to głównie kwestia tego, co zrobić najpierw, a co zostawić na później.

Nowy system rośnie wokół starego

Ten sposób ma nazwę. Martin Fowler opisał go w 2004 roku jako „strangler fig”, od figowca, który kiełkuje w koronie drzewa, puszcza korzenie wzdłuż pnia i rośnie, aż stare drzewo da się usunąć, a figowiec stoi sam. W oprogramowaniu znaczy to: zamiast przepisywać stary system od zera i przełączać się w jeden dzień, buduje się nowy po brzegach starego, kawałek po kawałku, i stary wyłącza się dopiero wtedy, gdy nowy robi już wszystko.

Tak samo robią najwięksi. Pod koniec października ludzie z Anthropic opowiadali w podcaście Latent Space, jak przepisali swój główny serwer API z Pythona na Rust. Nie wyłączyli starego systemu w piątek, żeby w poniedziałek uruchomić nowy. Postawili nową wersję obok starej, puścili do obu prawdziwy ruch i porównywali, czy odpowiadają tak samo. Przełączali stopniowo, dopiero gdy odpowiedzi się zgadzały. Liczyło się jedno: porównanie na prawdziwym ruchu, zanim ktokolwiek przełączył.

W firmie z jednym systemem ERP i jednym obiegiem dokumentów zasada jest ta sama. Tylko zamiast ruchu z całego świata są faktury od kontrahentów, a zamiast automatycznego porównania są czujne oczy księgowości.

Punkt wyjścia: prosty obieg, który działał

Przez lata firma pracowała na obiegu dokumentów wbudowanym w ERP. Był stary i prosty: skan, rozpoznanie tekstu, skan dopięty jako załącznik do dokumentu jednego z trzech rodzajów, przychodzącego, wychodzącego albo wewnętrznego. Potem dokument trafiał w obieg, w którym ustawiało się dwie rzeczy: kto ma go zobaczyć i jaki ma status.

To wystarczało. Nikt nie narzekał na brak funkcji, bo ludzie mieli w głowie te dwie informacje, osobę i status, i całą resztę dopowiadali sobie sami.

Dwie zmiany z zewnątrz

Spokój skończyły dwie rzeczy, na które firma nie miała wpływu.

Dostawca zapowiedział wygaszenie starego modułu i zachęcał do przejścia na swój nowy, rozbudowany system zarządzania procesami.

Przyszedł KSeF. Od 1 lutego 2026 wszystkie firmy muszą odbierać faktury przez Krajowy System e-Faktur. Wersja ERP, która miała go obsługiwać, miała się ukazać tuż przed tym terminem. Czyli bez czasu na spokojne testy.

Spróbowaliśmy najpierw zrobić to, co podpowiadał dostawca. Nowy system procesów okazał się trudny do dopasowania do tego, jak firma naprawdę pracowała. I im bardziej próbowaliśmy go dopasować, tym więcej było trzeba: dodatkowych licencji, dodatkowego modułu programistycznego do kontrolek, kolejnych zależności. Każdy krok w stronę systemu oddalał nas od procesu, który działał.

Jeśli przy każdej próbie dopasowania lista potrzebnych rzeczy rośnie, to nie jest jeszcze wdrożenie. To jest sygnał, że system i proces mówią innymi językami.

Najpierw zrozumieć, potem budować

Kiedy wyszła wersja ERP z obsługą KSeF, usiadłem i sprawdziłem, co właściwie zawiera. Okazało się, że to nic więcej niż dodatkowa lista dokumentów z identyfikatorami. Żadna czarna skrzynka, tylko dane, które da się przeczytać.

Wtedy rachunek się odwrócił. Zamiast walczyć z dużym systemem, który trzeba było naginać do procesu, prościej było dobudować na tej liście własny obieg, który od początku mówi językiem procesu. Ta decyzja nie zapadła na początku. Zapadła dopiero wtedy, gdy jasnym już było na czym budować. Wcześniej byłaby zgadywaniem.

Pierwszy krok: ten sam język, wąski wycinek

Nowy obieg zaczął od dwóch informacji, które ludzie znali ze starego: kto ma widzieć dokument i jaki ma status. Nie dodałem niczego, czego nie było wcześniej. Użytkownik, który otwierał nowy obieg, widział znajome pojęcia w nowym miejscu.

I zaczął od jednego wycinka: tylko dokumenty przychodzące i tylko te, które przyszły przez KSeF. Wszystko inne, skany papierowych faktur, dokumenty wewnętrzne, wychodzące, dalej szło starym obiegiem. Przez jakiś czas firma pracowała w dwóch obiegach naraz, z jasną granicą między nimi. To był mój odpowiednik puszczania ruchu do starej i nowej wersji jednocześnie.

Potem doszły statusy i synchronizacja z ERP, tak żeby zmiana w jednym miejscu była widoczna w drugim. Każdy z tych kroków był mały i każdy dało się sprawdzić na prawdziwych dokumentach, zanim przyszedł następny. Kiedy coś poszło nie tak, pisałem o tym w notatkach z Pracowni, jak przy numerze dokumentu złożonym z części.

Nagle wszystko naraz

Plan zakładał, że stary obieg będzie działał jeszcze długo, a nowy będzie przejmował kolejne rodzaje dokumentów po kolei. Wtedy, na początku października, dostawca odłączył stary moduł. Najpewniej przez pomyłkę, bo później go przywrócił, ale do tego czasu firma nie miała innego obiegu niż nowy.

Uratowała mnie jedna decyzja z samego początku: obieg od pierwszej wersji był zbudowany z osobnych modułów. Dzięki temu w krótkiej, szybkiej pętli doszły kolejne części, prawie nie ruszając tych, które już działały: obsługa skanów, repozytorium dokumentów z decyzją, czy dany dokument w ogóle trafia do obiegu, potem dokumenty wewnętrzne i wychodzące. Gdybym zaczął od jednego dużego programu, każda z tych zmian groziłaby zepsuciem tego, co już było w użyciu.

Dziewięć etapów w trzy tygodnie

Z każdym wydaniem powstawał krótki opis zmian. Kiedy teraz go czytam, widać, jak szybko to szło, kiedy plan przestał obowiązywać. Od 7 do 29 października obieg przeszedł dziewięć etapów:

Etap	Daty	Co przyniósł
1. Poprawki i przegląd obiegu	7.10	szybsza synchronizacja z ERP, nawigacja, przegląd całego obiegu
2. Skany i podpowiedzi z plików	7–13.10	obsługa skanów, rozpoznawanie danych z PDF
3. Lista życzeń księgowości	14.10	pełny wgląd, repozytorium, sprawy, import ze skanera
4. Konta i bezpieczeństwo	14–15.10	samodzielna zmiana i reset hasła, dziennik bezpieczeństwa
5. Role i listy po testach księgowości	15–21.10	rola „tylko swoje dokumenty”, nowy układ list
6. Utrzymanie i połączenie z ERP	21–22.10	ochrona formularzy, migracje bazy, link do karty w ERP
7. Dokumenty wychodzące i wewnętrzne	22.10	własna numeracja, „w odpowiedzi na”, oryginał papierowy
8. Obieg sterowany przez aplikację	27.10	ERP już tylko uruchamia obieg, dalej decyduje nowy system
9. Lista zmian księgowości	27–29.10	typy dokumentów, filtry, ostrzeżenie o powtórzonym numerze

Dwie rzeczy widać w tej tabeli od razu. Trzy z dziewięciu etapów mają w nazwie księgowość: listę życzeń, testy i listę zmian. I etap ósmy, w którym nowy obieg przestał być nakładką i stał się miejscem, w którym zapada decyzja o stanie dokumentu. Do tego momentu oba systemy mogły się nawzajem poprawiać. Od niego ERP tylko uruchamia obieg, a każda późniejsza zmiana po stronie ERP jest cofana i zapisywana w historii karty. To nie maszyna cofa decyzję człowieka. Człowiek dalej decyduje, tylko w jednym miejscu, a ERP przestał być tym miejscem; w historii karty zostaje, kto i kiedy próbował zmienić status po starej stronie. Jedna decyzja podejmowana w dwóch miejscach prędzej czy później staje się dwiema różnymi decyzjami. Przełączenie nastąpiło dopiero wtedy, gdy wszystko inne już działało.

Ludzie projektują resztę

Kiedy procesy przeniosły się do nowego obiegu z konieczności, zaczęły przychodzić zmiany, których nie wymyśliłbym przy biurku. Wynikały po prostu z pracy osób, które go używały:

• przejście z karty jednego dokumentu od razu do następnego, bez powrotu do listy, bo przy wielu fakturach pod rząd każdy powrót to strata czasu;
• samodzielna zmiana hasła, żeby nikt nie musiał o nią prosić;
• podpowiedzi tam, gdzie ludzie się zatrzymywali;
• coraz więcej ustawień przeniesionych z plików konfiguracyjnych do panelu administratora: statusy, powiązania z polami w ERP, role ustalone według tego, kto w praktyce co powinien widzieć.

Ten ostatni punkt jest ważniejszy, niż wygląda. Dopóki konfiguracja siedzi w plikach, każda zmiana procesu wymaga autora. Kiedy jest w panelu, proces może zmieniać się razem z firmą.

Test, którego nie da się zaplanować

Kiedy stary moduł wrócił, nikt nie poprosił o powrót. Nie dlatego, że ktoś tego zabronił. Nowy obieg po prostu robił to samo co stary, w znanym języku, a do tego rzeczy, o które ludzie sami poprosili.

Na żadnym spotkaniu wdrożeniowym nie usłyszałbym tak jednoznacznej oceny. Wdrożenie jest skończone wtedy, gdy ludzie mogą wrócić do starego systemu i nie wracają.

Co z tego wynika

• Zacznij od języka, który ludzie już znają. Nowy system może robić więcej, ale pierwszego dnia powinien mówić tym samym językiem co stary.
• Wytnij wąski kawałek, resztę zostaw tam, gdzie działa. Dwa obiegi obok siebie, z jasną granicą, są bezpieczniejsze niż jedno wielkie przełączenie.
• Najpierw zrozum dane, potem wybierz drogę. Decyzja „budujemy sami” albo „bierzemy gotowe” bez zrozumienia, na czym się buduje, to zgadywanie.
• Moduły od pierwszego dnia. Nie wiesz, kiedy plan przestanie obowiązywać. Moduły pozwalają przyspieszyć bez psucia tego, co już działa.
• Ostrzegaj, zamiast blokować, tam, gdzie decyduje człowiek. Gdy dokument o tym samym numerze od tego samego kontrahenta jest już w obiegu, obieg ostrzega, ale nie zatrzymuje. Czasem to duplikat, a czasem ten sam numer sprzed roku. Rozstrzyga człowiek.
• Brak odpowiedzi to nie brak dokumentu. Gdy połączenie z ERP chwilowo zawodzi, obieg niczego nie odpina. Inaczej przerwa w sieci wyglądałaby jak usunięcie dokumentów.
• Każde zdarzenie ma autora, a każde działanie ślad. Pełne logi i podpis pod każdą zmianą, także maszyny, o czym „Każde zdarzenie ma autora”.
• Zmiany z pracy, nie z biurka. Najlepsze funkcje przychodzą od ludzi, którzy używają systemu codziennie.
• Mierz system, nie ludzi. Statystyki pokazują, gdzie dokumenty utykają i wracają, a nie kto pracuje wolniej. W opisie zmian przyjęte jest to wprost: statystyki systemu, nie osób.
• Miarą jest to, czy ludzie wracają.

Jedna myśl na drogę

Najwięcej tej historii zrobiły dwie rzeczy, które nie były moim pomysłem: zapowiedź dostawcy i jego pomyłka. Pierwsza dała powód, żeby zacząć, druga zmusiła do przyspieszenia. Na żadną nie miałem wpływu. Wpływ miałem na to, żeby w chwili, gdy plan się sypie, mieć system zbudowany z małych części i ludzi, którzy już znają jego język.

---

Źródła

• Martin Fowler, „Strangler Fig Application” (2004, tytuł zmieniony w 2019)
• Latent Space, „Opus 5.5”: przepisanie serwera API z Pythona na Rust, z pracą obu wersji równolegle (27 października 2026)
• Ministerstwo Finansów, „Krok po kroku: jak odebrać fakturę w KSeF” (obowiązek odbierania od 1 lutego 2026)