← Blog / Strategia i koszty

Integracja systemów po przejęciu firmy: kolejność ERP i CRM

Opublikowano: 29 września 2026 Aktualizacja: 14 października 2026

W dniu zamknięcia transakcji przejęta spółka musi wystawić fakturę, a centrala chce na koniec miesiąca zobaczyć jej wynik we własnym raporcie. Wszystko inne, czyli wspólny ERP, jeden CRM i jedna kartoteka klientów, może poczekać, bo w pierwszym roku integracji systemów po przejęciu firmy więcej zależy od kolejności prac niż od tempa migracji.

Temat wrócił we wrześniu przy SAP Innovation Awards 2026. W relacji SAP z gali z 21 września integracja biznesu po dużych przejęciach międzynarodowych stoi obok transformacji obejmujących dziesiątki spółek grupy, a przykładem jest Qemetica, która w 2024 roku przejęła zakłady produkcyjne w USA i Holandii. Według tego tekstu po przejęciu trzeba było przede wszystkim zintegrować nowe spółki z grupą, czyli ujednolicić procesy, dane i zasady zarządzania.

Co musi działać w dniu zamknięcia

Lista dnia pierwszego jest krótka i dobrze ją spisać przed podpisaniem umowy, bo każde zadanie spoza niej zabiera ludzi tym, które są na niej.

• Fakturowanie bez przerwy. Według portalu KSeF Ministerstwa Finansów obowiązek wystawiania faktur w KSeF objął od 1 lutego 2026 roku firmy ze sprzedażą powyżej 200 milionów złotych w 2024 roku, a od 1 kwietnia 2026 roku większość pozostałych podatników. Przy zakupie udziałów spółka zachowuje NIP, a jej fakturowanie w KSeF działa dalej, o ile system, z którego wysyła faktury, nie należał do grupy sprzedającego. Przy wydzieleniu części biznesu (carve-out) nowy podmiot potrzebuje własnego NIP, uprawnień w KSeF i systemu, który potrafi przez KSeF fakturować, zanim wystawi pierwszą fakturę.
• Raport do spółki matki. Centrala potrzebuje bilansu próbnego przejętej spółki w planie kont grupy. Przy pierwszym zamknięciu miesiąca wystarczy tabela przypisań kont lokalnych do kont grupy i plik ładowany do systemu konsolidacyjnego, a automatyzacja może poczekać do kolejnych zamknięć.
• Obsługa klienta. Klient dzwoni pod ten sam numer i oczekuje, że konsultant zobaczy jego zamówienia i reklamacje, więc w dniu zamknięcia CRM przejętej spółki zostaje bez zmian.

Wspólne logowanie, intranet i przeniesienie skrzynek pocztowych mają znaczenie dla ludzi, ale nie dla przychodu ani sprawozdawczości, i mogą iść drugim torem.

Carve-out i umowa TSA

Gdy kupujesz część firmy, a nie całą spółkę, systemy zwykle zostają u sprzedającego. Pomostem jest umowa o usługach przejściowych (transitional service agreement, TSA), w której sprzedający przez określony czas prowadzi dla kupującego ERP, płace albo helpdesk za miesięczną opłatą. Dzięki niej biznes działa od pierwszego dnia, ale dla IT umowa ma trzy pułapki.

Pierwsza dotyczy zakresu: TSA obejmuje utrzymanie, rzadko zmiany. Sprzedający nie ma interesu w budowaniu interfejsów do systemów kupującego, więc każde nowe połączenie z grupą trzeba wynegocjować osobno albo zbudować po swojej stronie na danych, które sprzedający udostępni. Druga dotyczy wyjścia, bo koniec TSA oznacza migrację danych z cudzego systemu, a prawo do eksportu danych historycznych, jego format i termin trzeba zapisać w umowie, ponieważ po podpisaniu negocjuje się je znacznie trudniej. Trzecia to czas: przedłużenie TSA jest przedmiotem nowych negocjacji, w których kupujący ma słabszą pozycję, więc harmonogram wyjścia z TSA jest od początku także harmonogramem budżetu.

Współistnienie zamiast natychmiastowej migracji

Odruch wielu grup brzmi: „przenieśmy ich na nasz SAP w ciągu roku”. Rok to mało na migrację spółki, której procesów nikt w grupie jeszcze dobrze nie zna, a migracja pod presją terminu kończy się zwykle przeniesieniem wszystkich dawnych wyjątków do systemu grupy. Rozsądniejszy plan zakłada okres współistnienia: przejęta spółka pracuje na swoim ERP, a z grupą łączy ją warstwa integracji, która przekłada dane z jednego modelu na drugi.

W tej warstwie lądują najpierw przepływy, których grupa potrzebuje od razu: salda lub księgowania do konsolidacji, zamówienia i faktury między spółkami grupy, dane klientów dla wspólnej sprzedaży. Platforma integracyjna, czy to SAP Integration Suite, czy inne narzędzie klasy iPaaS, ma tu tę zaletę, że po późniejszej migracji ERP podmienia się jeden koniec połączenia, a reszta grupy tego nie odczuwa.

Dla finansów SAP ma osobny wariant współistnienia. Według dokumentacji SAP o Central Finance rozwiązanie pozwala podłączyć systemy SAP w różnych wersjach oraz systemy spoza SAP do centralnego S/4HANA bez przerywania ich pracy, zmapować konta, centra zysku i centra kosztów na wspólny zestaw danych podstawowych i replikować księgowania finansowe i kontrolingowe. Centrala ma wtedy wyniki przejętej spółki w jednym miejscu, chociaż spółka dalej pracuje na swoim systemie, co ma znaczenie także wtedy, gdy przejmowana polska firma używa lokalnego ERP spoza SAP. Dla porządku: to osobny projekt z serwerem replikacji, mapowaniem i ładowaniem początkowym, więc na dzień zamknięcia się nie nadaje, a sens ma wtedy, gdy grupa i tak planuje centralny S/4HANA albo przejmuje kolejne spółki. Wtedy wybór między harmonizacją, Central Finance i hubem integracyjnym przestaje dotyczyć jednego przejęcia, a staje się pytaniem o integrację ERP w grupie kapitałowej na lata.

Dlaczego CRM zwykle łączy się przed ERP

Gdy uzasadnienie biznesowe przejęcia stoi na sprzedaży, czyli na wspólnych klientach, sprzedaży krzyżowej i jednym opiekunie dużego odbiorcy, wspólny widok klienta jest potrzebny dużo wcześniej niż wspólna księga główna. Konsolidacja CRM jest przy tym mniej ryzykowna, bo nie dotyka podatków, zamknięcia okresu ani sprawozdania finansowego. Błędnie przypisany opiekun klienta to poprawka w CRM, podczas gdy błąd w ERP potrafi skończyć się korektą deklaracji VAT.

Konsolidacja nie musi oznaczać połączenia dwóch organizacji Salesforce w jedną. Salesforce w przewodniku decyzyjnym dla architektów o Data 360 wymienia fuzje i przejęcia jako jedną z typowych przyczyn, dla których firma ma kilka organizacji, a udostępnianie danych między instancjami opisuje jako pomost na czas, gdy konsolidacja nie jest od razu możliwa. Fizyczne scalenie ma sens, gdy obie firmy sprzedają podobnie i będą miały jeden zespół handlowy. Jeśli przejęta spółka sprzedaje inaczej, na przykład przez dystrybutorów zamiast bezpośrednio, dwie organizacje ze wspólną warstwą danych klienta mogą zostać rozwiązaniem trwałym.

Od tej kolejności jest jeden ważny wyjątek. Jeśli w przejętej spółce zamówienie powstaje w CRM i stamtąd trafia do ERP, migracja CRM pociąga za sobą przebudowę całego przepływu order-to-cash, więc CRM i ERP przenosi się wtedy razem albo CRM czeka.

Kolizje danych podstawowych

Najwięcej pracy kryje się w danych, których nikt nie liczył w due diligence. Klient o numerze 100234 istnieje w obu systemach i w każdym oznacza inną firmę, a ten sam odbiorca występuje w obu pod różnymi numerami i z różnymi warunkami płatności. W polskich spółkach naturalnym kluczem dopasowania kontrahentów jest NIP, choć zawodzi przy oddziałach, odbiorcach zagranicznych i osobach fizycznych.

Indeksy materiałowe kolidują podobnie. Ten sam numer potrafi oznaczać inny produkt, a ten sam produkt ma w każdej spółce inną jednostkę miary, przez co zamówienie wewnątrz grupy na 100 sztuk przyjeżdża jako 100 kartonów.

Plan kont bywa najprostszy, o ile nikt nie próbuje od razu przestawić spółki na plan grupy. Jeśli przejęta firma pracuje na SAP, dokumentacja SAP o typach planów kont przewiduje, że jednostka gospodarcza ma obowiązkowy operacyjny plan kont, a plan kont grupy i plan krajowy można jej przypisać dodatkowo. Spółka może więc dalej księgować według polskich wymogów, a raport do grupy powstaje przez przypisanie kont. Przy systemie spoza SAP to samo przypisanie trzeba utrzymywać w warstwie integracji albo w Central Finance.

Wszystkie trzy przypadki sprowadzają się do jednej decyzji: gdzie przechowywać tabele odwzorowań starych i nowych numerów.

Clean Core w czasie łączenia

Projekt integracji po przejęciu produkuje kod tymczasowy: pole Z na stary numer klienta, raport Z do porównania sald, program Z, który co noc czyta tabele przejętej spółki. Tymczasowy kod w ERP ma skłonność do przeżywania projektu, dla którego powstał, i po kilku latach nikt już nie pamięta, że miał zniknąć po migracji.

Zasada Clean Core daje tu prostą regułę: to, co służy tylko okresowi przejściowemu, buduje się poza rdzeniem, w warstwie integracji albo w aplikacji obok ERP, a z samego ERP korzysta się przez standardowe API. Tabele odwzorowań numerów, przekształcenia planu kont i logika porównań zostają wtedy w jednym miejscu, które po migracji można wyłączyć w całości, bez przeglądania systemu w poszukiwaniu obiektów Z. Dlaczego to się opłaca także poza okresem przejściowym, opisujemy we wpisie o wynoszeniu rozszerzeń poza rdzeń.

Czego nie widać przed zamknięciem

Cały powyższy plan stoi na liście interfejsów przejmowanej spółki, a ta lista przed zamknięciem jest zwykle niepełna. Kupujący widzi to, co sprzedający włożył do data roomu: wykaz systemów, licencje, czasem diagram architektury. Eksport przelewów do banku uruchamiany skryptem na komputerze głównej księgowej, wymiana EDI z największym odbiorcą obsługiwana przez zewnętrzną firmę albo arkusz z makrem, który zasila raport sprzedaży, wychodzą na jaw dopiero przy pierwszym wspólnym zamknięciu miesiąca, kiedy ktoś w centrali pyta, skąd się biorą liczby. Dlatego inwentaryzacja interfejsów jest pierwszym zadaniem po zamknięciu, a w budżecie integracji trzeba zostawić rezerwę na połączenia, których nie ma w żadnym dokumencie z due diligence. Ile ich będzie, okaże się dopiero po pierwszym kwartale.

FAQ

#Strategia integracji #Migracja #SAP #Salesforce #Clean Core