Integracja systemów IT w firmie — jak połączyć to, co już masz

Większość firm, z którymi pracuję, nie ma problemu z brakiem oprogramowania – ma problem z tym, że ma go za dużo i nic ze sobą nie rozmawia. ERP osobno, sklep osobno, system magazynowy osobno, CRM w arkuszu, a księgowość dostaje pliki mailem. Dane są, tylko trzeba je ręcznie przepisywać z jednego okna do drugiego. To nie jest awaria, którą widać. To codzienny podatek od chaosu – kilka godzin tygodniowo na osobę, których nikt nie liczy. W tym wpisie wyjaśniam, dlaczego systemy ze sobą nie gadają, jak technicznie się je łączy (po ludzku, bez żargonu) i – co najważniejsze – dlaczego prawie nigdy nie trzeba wymieniać całego środowiska, żeby to naprawić.

Dlaczego systemy IT ze sobą nie rozmawiają

Krótka odpowiedź: bo nikt ich do tego nie zaprojektował. Każdy program kupowałeś osobno, w innym roku, od innego dostawcy, żeby rozwiązać jeden konkretny problem. ERP miał ogarnąć fakturowanie, sklep miał sprzedawać, system magazynowy miał pilnować stanów. Każdy z nich robi swoje dobrze. Problem zaczyna się tam, gdzie te światy muszą się spotkać – bo zamówienie ze sklepu musi trafić do magazynu, a faktura do ERP.

Te punkty styku zwykle łata człowiek. Ktoś rano eksportuje plik ze sklepu, wgrywa do ERP, koryguje stany ręcznie w magazynie. Działa – do pierwszej pomyłki, urlopu albo skoku sprzedaży. Najczęstsze przyczyny, dla których systemy milczą:

• Brak wspólnego „języka” – jeden system nazywa klienta numerem NIP, drugi wewnętrznym ID, trzeci adresem e-mail. Nikt nie wie, że to ten sam klient.
• Zamknięte oprogramowanie – starszy system nie ma żadnego sposobu, żeby się z nim „dogadać” z zewnątrz. Wtedy zostają obejścia, o których piszę niżej.
• Dane w różnych formatach – daty, kwoty, jednostki, kodowanie polskich znaków. Drobiazgi, które wywracają automatyczny transfer.
• Decyzja, że „na razie wystarczy ręcznie” – i to „na razie” trwa trzy lata.

Ile naprawdę kosztuje brak integracji

Lubię liczby, więc policzmy. Załóżmy, że dwie osoby spędzają po godzinie dziennie na przeklejaniu danych między systemami. To 2 godziny dziennie, około 40 godzin miesięcznie. Przy stawce 60–80 zł za godzinę kosztu pracodawcy to 2400–3200 zł miesięcznie – samego czasu, bez liczenia błędów.

A błędy są droższe niż czas. Źle przepisany stan magazynowy to sprzedaż czegoś, czego nie ma. Pominięta faktura to problem z księgowością. Literówka w adresie to zwrot przesyłki. Te koszty są rozproszone, więc rzadko ktoś je sumuje – ale w skali roku to często kilkadziesiąt tysięcy złotych ukrytych w „tak się u nas pracuje”.

Do tego dochodzi koszt, którego w ogóle nie widać w tabelce: brak wiarygodnych danych do decyzji. Jeśli liczby w trzech systemach się nie zgadzają, to żadnemu z nich do końca nie ufasz. O tym, jak z połączonych danych zbudować sensowny obraz firmy, pisałem osobno przy okazji dashboardów analitycznych dla firm.

Jak technicznie łączy się systemy – cztery podejścia po ludzku

Integracja brzmi groźnie, ale w praktyce sprowadza się do czterech sposobów, w jakich jeden program może podać dane drugiemu. Tłumaczę każdy bez żargonu – bo decyzja, którego użyć, należy do mnie, ale warto żebyś rozumiał, za co płacisz.

API – system pyta, system odpowiada

API to po prostu „okienko”, przez które jeden program może zapytać drugi: „daj mi wszystkie zamówienia z dzisiaj” albo „dopisz tego klienta”. To najczystszy i najbardziej niezawodny sposób. Jeśli oba systemy mają API – a większość nowoczesnych ma – integracja jest przewidywalna i tania. Wadą jest to, że jeden system musi aktywnie zapytać drugi, więc dane są aktualne dopiero w momencie zapytania.

Webhooki – system sam daje znać

Webhook to odwrotność API: zamiast pytać co minutę „czy jest nowe zamówienie?”, system sam wysyła sygnał w sekundzie, w której coś się wydarzy. „Właśnie wpłynęła płatność” – i reszta procesu rusza natychmiast. To najlepsze rozwiązanie tam, gdzie liczy się czas reakcji. Wymaga jednak, żeby system źródłowy w ogóle umiał wysyłać takie sygnały.

Middleware – tłumacz pośrodku

Czasem dwa systemy mają API, ale mówią zupełnie różnymi „językami” i nie da się ich połączyć wprost. Wtedy stawiam pośrednika – warstwę, która odbiera dane z jednego, tłumaczy je na format zrozumiały dla drugiego i przekazuje dalej. Middleware pilnuje też kolejności, ponawia próby przy chwilowej awarii i loguje, co się przez niego przewinęło. To serce większości poważniejszych integracji.

ETL – przenoszenie danych hurtem

ETL (pobierz – przekształć – załaduj) to podejście do dużych paczek danych, zwykle raz na jakiś czas: w nocy przenieś wszystkie wczorajsze transakcje do hurtowni raportowej, po drodze je porządkując. Nie nadaje się do reakcji „na żywo”, ale jest niezastąpiony tam, gdzie chodzi o raportowanie i analizę większych zbiorów.

Podejście	Kiedy ma sens	Aktualność danych
API	oba systemy nowoczesne, dane na żądanie	na zapytanie
Webhooki	liczy się reakcja w czasie rzeczywistym	natychmiast
Middleware	systemy mówią różnymi formatami, złożona logika	zależnie od konfiguracji
ETL	raportowanie, duże paczki danych	partiami (np. co noc)

Integracja ERP z aplikacjami webowymi

To najczęstszy scenariusz, z jakim do mnie przychodzą. ERP jest sercem firmy – trzyma kontrahentów, towary, faktury, stany – ale jest niewygodny dla ludzi, którzy nie księgują na co dzień. Handlowiec nie będzie klikał w ERP, żeby sprawdzić status zamówienia. Klient tym bardziej.

Rozwiązaniem zwykle nie jest wymiana ERP, tylko nałożenie na niego wygodnej aplikacji webowej – lekkiego panelu, do którego logują się handlowcy albo klienci, a który pod spodem czyta i zapisuje dane wprost do ERP. ERP zostaje tym, czym jest, ale ludzie pracują w interfejsie zrobionym pod nich, nie pod księgowość. Typowe połączenia, które stawiam:

• Sklep / aplikacja → ERP – zamówienie z sieci ląduje od razu jako dokument w ERP, bez przepisywania.
• ERP → aplikacja – stany magazynowe i ceny widoczne na bieżąco tam, gdzie sprzedajesz.
• ERP → panel klienta – klient sam sprawdza status zamówienia i pobiera faktury, zamiast dzwonić do biura.

Automatyczna wymiana danych w praktyce

Integracja to dopiero rura – prawdziwa wartość pojawia się, kiedy popłyną przez nią całe procesy bez udziału człowieka. Połączenie systemów i automatyzacja procesów to dwie strony tej samej monety: najpierw dane muszą móc się przemieszczać, potem można na nich oprzeć automatyczny przepływ pracy. Przykładowy łańcuch, który da się złożyć z gotowych klocków:

• klient składa zamówienie w aplikacji,
• webhook natychmiast tworzy dokument w ERP,
• magazyn dostaje powiadomienie do realizacji,
• po wysyłce klient automatycznie dostaje numer przesyłki,
• dane sprzedażowe lądują w hurtowni do raportu.

Nikt niczego nie przepisuje, a każdy krok zostawia ślad. Jeśli chcesz wejść głębiej w samo projektowanie takich przepływów, rozwijam ten temat przy okazji workflow automation – narzędzi i strategii.

Najpierw gotowe konektory, custom dopiero gdy trzeba

Tu jest mój uczciwy kompromis, bo nie chcę sprzedawać Ci więcej, niż potrzebujesz. Sporo połączeń między popularnymi systemami – znane ERP, znane sklepy, znane platformy – ma już gotowe konektory. Jeśli taki istnieje i robi to, czego potrzebujesz, to go używam. Jest tańszy, szybszy do wdrożenia i ktoś go utrzymuje za mnie.

Po dedykowaną integrację sięgam dopiero wtedy, gdy gotowiec nie istnieje albo nie obejmuje Twojej logiki – bo masz nietypowy proces, starszy system bez API albo reguły, których żaden uniwersalny konektor nie zna. Wtedy custom ma sens, bo robi dokładnie to, co Twoja firma, a nie „średnią dla wszystkich”. Kolejność jest zawsze ta sama: najpierw sprawdzam, czy da się gotowcem, dopiero potem proponuję pisanie od zera.

Kiedy integrować, a kiedy wymienić system

Najważniejsza wiadomość całego wpisu: w większości przypadków nie musisz wymieniać niczego – wystarczy połączyć to, co już masz. Wymiana środowiska to projekt na miesiące, ryzyko paraliżu firmy i koszt liczony w dziesiątkach tysięcy. Integracja jest tańsza, szybsza i mniej ryzykowna, bo ludzie pracują dalej w narzędziach, które znają.

Są jednak granice, gdzie uczciwie powiem „tu integracja nie wystarczy”:

• Integruj, gdy systemy robią swoją robotę dobrze, a problemem jest tylko brak połączenia między nimi.
• Integruj, gdy system jest stary, ale stabilny – często da się go „otoczyć” nowoczesną warstwą bez ruszania środka.
• Wymieniaj, gdy system nie nadąża za firmą, dostawca przestał go rozwijać albo utrzymanie kosztuje więcej niż nowe rozwiązanie.
• Wymieniaj, gdy braki funkcjonalne są tak duże, że żadna nakładka ich nie załata.

W praktyce najczęściej kończy się na drodze pośredniej: zostawiamy sprawdzone systemy, łączymy je integracją, a wymieniamy tylko ten jeden element, który realnie blokuje rozwój. Bez rewolucji, za to z efektem widocznym w tygodniach, nie w kwartałach.

Od czego zacząć

Nie zaczynam od technologii, tylko od mapy: które dane są przepisywane ręcznie, ile to kosztuje czasu i gdzie najczęściej pojawiają się błędy. Z tej mapy zwykle od razu widać dwa, trzy połączenia, które dają największy zwrot przy najmniejszym nakładzie – i od nich startujemy, zamiast od razu „integrować wszystko ze wszystkim”.

Jeśli masz kilka systemów, które ze sobą nie rozmawiają, i czujesz, że Twój zespół traci czas na przeklejanie danych – napisz do mnie. Spojrzę na to, co już masz, powiem wprost, co da się połączyć gotowcem, a gdzie potrzebna jest dedykowana integracja – i ile to realnie kosztuje, zanim cokolwiek zaczniemy.