Integracja systemów: gdy programy w firmie nie rozmawiają

Integracja systemów: krótka odpowiedź

Integracja systemów to połączenie dwóch programów tak, żeby same przekazywały sobie dane. Zamówienie ze sklepu wchodzi wtedy do magazynu bez człowieka, a faktura powstaje z jednego źródła.

Bez tego połączenia tracisz trzy rzeczy. Czas ludzi, którzy przepisują dane z okna do okna. Pewność danych, bo dwa programy pokazują dwie różne liczby. Swobodę zmiany dostawcy, bo wyjście z programu robi się osobnym projektem.

Pierwsza strata jest najłatwiejsza do zauważenia, bo widać ją w grafiku zespołu. Dwie pozostałe są cichsze. Wracają dopiero przy reklamacji klienta i przy decyzji o zmianie programu.

To, gdzie żyją dane Twojej firmy, rozstrzyga się osobno i wcześniej. Tutaj zostajemy przy jednym pytaniu: co zrobić, gdy dwa programy nie chcą ze sobą rozmawiać.

Jak programy przekazują sobie dane

Jeden program wystawia drugiemu wejście, przez które można pobrać dane albo je zapisać. Połączenie działa samo: po każdej zmianie albo o ustalonej godzinie. Nikt niczego nie przepisuje i nikt o niczym nie przypomina.

W rozmowie z dostawcą usłyszysz na to skrót API, czyli właśnie takie wejście dla innych programów. Podajemy tę nazwę, bo pada w każdej ofercie. Dalej piszemy po prostu o połączeniu.

Dla Twojej firmy liczy się jedno: czy to wejście jest w cenie licencji, czy w dodatkowym pakiecie.

Tak właśnie łączy się ERP z CRM. ERP to jeden system do zarządzania firmą, w którym prowadzi się sprzedaż, magazyn i produkcję. CRM to program z kontaktami i historią rozmów z klientami. Handlowiec widzi wtedy stan zamówienia bez dzwonienia na produkcję.

Integracja to nie jest wysłanie pliku raz w miesiącu. Plik wysłany ręcznie to dalej praca człowieka i dalej dane sprzed kilku dni. Mówimy o połączeniu, które działa codziennie i bez nadzoru.

Trzy koszty braku integracji

Brak połączenia między programami nie wygląda na awarię. Nic się nie psuje, nikt nie dzwoni po pomoc. Koszt rozkłada się po cichu na trzy miejsca.

• Czas ludzi. Ktoś przepisuje dane, a potem ktoś drugi sprawdza, czy przepisał je dobrze. To praca, która nie dodaje nic do zamówienia klienta.
• Błędy w danych. Ta sama cena w dwóch programach zaczyna się różnić, a stan magazynu pokazuje dwie różne liczby. Reklamacja kosztuje więcej niż poprawka.
• Decyzje na starych danych. Raport powstaje raz w tygodniu, bo ktoś składa go ręcznie. Decyzja zapada wtedy na danych sprzed kilku dni.

Najmocniej widać to w firmie, która rośnie. Dopóki zamówień jest niewiele, ręczne przepisywanie mieści się w grafiku biura. Gdy zamówień przybywa, robi się z tego osobne zajęcie, którego nikt świadomie nie zaplanował.

Tak to często wygląda w firmach produkcyjnych, handlowych i usługowych z Legnicy, Lubina i Głogowa: urosły szybciej niż ich programy. Każdy program kupowano osobno i każdy z osobna działa dobrze. Problem zaczyna się na styku.

Uzależnienie od jednego dostawcy

Mechanizm jest prosty. Dane leżą w formacie dostawcy, a eksport wyciąga tylko część z nich. Wyjście z programu wymaga jego pomocy, a ta pomoc ma swoją cenę.

W ofertach zobaczysz na to angielskie określenie vendor lock-in, czyli uzależnienie od jednego dostawcy. Nie oceniamy tu dostawców ani ich pracy. Oceniamy zapisy umowy i to, czy eksport danych naprawdę działa.

Trzy rzeczy realnie zmniejszają to ryzyko, jeszcze zanim podpiszesz umowę:

• Opisane połączenie z innymi programami, dostępne w cenie licencji, a nie w pakiecie dokupowanym później.
• Pełny eksport na żądanie: dane razem z załącznikami i historią zmian, w formacie, który otworzy inny program.
• Zapis o wydaniu danych po zakończeniu umowy, z podanym terminem, formatem i opłatą.

To nie jest porada prawna i nie zastąpi przeczytania umowy przez prawnika. To lista rzeczy, o które pyta się na spotkaniu handlowym, zanim cena przykryje wszystko inne.

Przepisy idą w stronę łatwiejszego wyjścia

Unijny akt o danych (Data Act, rozporządzenie 2023/2854) jest stosowany od 12 września 2025 roku. Jego rozdział o zmianie dostawcy usług przetwarzania danych ma ułatwiać przeniesienie się do innej usługi w chmurze. Warunki i koszt wyjścia mają być znane przed zawarciem umowy.

Od 12 stycznia 2027 roku dostawca nie będzie już mógł pobierać opłat za samo przejście klienta do innej usługi. Do tego czasu wolno mu naliczyć opłatę obniżoną, nieprzekraczającą jego kosztów. Źródło: rozporządzenie (UE) 2023/2854, art. 25 i 29, tekst w unijnej bazie aktów prawnych EUR-Lex (eur-lex.europa.eu), stan na październik 2026.

Dla Twojej firmy to argument w negocjacjach z dostawcą usługi w chmurze. Przy programie zainstalowanym w biurze te przepisy nie pomogą i zostaje zapis w umowie. Zanim powołasz się na konkretny przepis, sprawdź jego brzmienie u prawnika.

Cztery pytania o dane

Te cztery pytania zadajesz każdemu dostawcy programu, od księgowości po obsługę zamówień i magazynu, niezależnie od branży i ceny. Odpowiedzi warto zapisać i poprosić o wskazanie miejsca w umowie.

1. Czy Wasz program umie przekazywać dane innym programom i czy to jest w cenie licencji?
2. Czy możemy wyeksportować wszystkie nasze dane, razem z załącznikami i historią zmian?
3. Czy program sam powiadamia inny program o zmianie, czy trzeba go dopytywać?
4. Co dzieje się z naszymi danymi po rozwiązaniu umowy: w jakim formacie, w jakim terminie i za ile?

Dobra odpowiedź brzmi konkretnie i da się ją przepisać do umowy. Odpowiedź wymijająca przesuwa temat na później, czyli na moment, w którym nie masz już nic do negocjacji.

Jak odróżnić odpowiedź, którą zapiszesz w umowie, od takiej, która nic nie znaczy.

Piętnaście pytań do dostawcy

Tę listę drukuje się i bierze na spotkanie. Obok każdego pytania zostaw miejsce na odpowiedź i na to, gdzie ten punkt jest zapisany w umowie. Cztery pierwsze znasz już z poprzedniej sekcji, piąte dotyczy przyszłości samego programu.

1. Czy program przekazuje dane innym programom i czy jest to w cenie licencji?
2. Czy możemy wyeksportować wszystkie nasze dane, razem z załącznikami i historią zmian?
3. Czy program sam powiadamia o zmianie, czy trzeba go dopytywać?
4. Co dzieje się z naszymi danymi po rozwiązaniu umowy: w jakim formacie, w jakim terminie i za ile?
5. Co się stanie z programem i danymi, jeśli dostawca zniknie? Czy kod jest otwarty albo czy narzędzie ma otwarty odpowiednik i społeczność? Dobra odpowiedź: kod zostaje, a wokół narzędzia są ludzie, którzy je znają. Program utrzymasz wtedy dalej, własnymi siłami albo z innym partnerem.
6. Kto przenosi dane ze starego programu i kto odpowiada za błędy w przeniesieniu?
7. Ile trwa wdrożenie i co musi zrobić nasz zespół?
8. Kto szkoli pracowników i ile szkoleń jest w cenie?
9. Kto ustawia uprawnienia i czy zmienimy je potem sami?
10. Jaki czas reakcji na zgłoszenie jest zapisany w umowie?
11. Jak często wychodzą aktualizacje i czy możemy odłożyć aktualizację na później?
12. Kto odbiera telefon w sierpniu i w okresie świątecznym?
13. Co podniesie cenę po pierwszym roku i o ile maksymalnie?
14. Ile kosztuje dodatkowe stanowisko i czy można z niego potem zrezygnować?
15. Jaki jest okres wypowiedzenia i co dzieje się z naszymi danymi w tym czasie?

Pytania od dziesiątego do piętnastego dotyczą już warunków współpracy, nie samego programu. Zbieramy je w jednym miejscu, bo trafiają do tej samej umowy. Osobno piszemy o tym, na co uważać w umowie IT.

Jeśli żaden gotowy program nie pasuje do sposobu pracy w Twojej firmie, zostaje oprogramowanie na zamówienie. Wtedy te same pytania o dane zadajesz wykonawcy, a odpowiedzi zapisujesz w umowie wdrożeniowej.

Gdy dostawca nie daje połączenia

Zamknięte drzwi nie kończą tematu. Najczęściej w grę wchodzi pięć dróg, od najprostszej do najpoważniejszej. Przy każdej piszemy, kiedy ma sens i czego nie rozwiąże.

1. Eksport i import plików po harmonogramie. Najprostsze i często wystarczające. Dane są jednak zawsze o jeden cykl starsze, więc do sprzedaży na żywo to za mało.
2. Połączenie z bazą danych programu. Szybkie i dokładne, ale tylko za zgodą dostawcy. Bez tej zgody odpada, bo potrafi unieważnić wsparcie techniczne.
3. Make, czyli usługa spinająca programy bez pisania kodu. Dobra do prostych przepływów i szybka w uruchomieniu. Potrzebuje jednak jakiegoś punktu zaczepienia po obu stronach: wejścia dla innych programów, plików na serwerze, skrzynki pocztowej albo dostępu do bazy.
4. Robot, który klika w programie jak człowiek. U dostawców usłyszysz na to skrót RPA. Działa, gdy innego wejścia nie ma, ale bywa, że po zmianie wyglądu programu przestaje działać i wymaga poprawki.
5. Migracja na inny system, zaplanowana na rok. Jako jedyna usuwa przyczynę. To osobny projekt z budżetem, nie poprawka na tydzień.

Bywa też szósta droga: dopłata do modułu integracyjnego u samego dostawcy. Warto o nią zapytać, zanim zaczniesz budować obejście.

Żadna z tych dróg nie jest darmowa. Koszt zależy od ilości danych, liczby wyjątków i tego, jak często dane mają się wymieniać. Pierwsza droga często w zupełności wystarcza i wtedy właśnie ją proponujemy.

Sam przebieg takiego wdrożenia opisujemy w tekście o tym, jak łączymy systemy w firmie. Tutaj patrzymy na to od strony decyzji, nie technicznych kroków.

Częste błędy przy wyborze drogi

Pierwszy błąd to łączenie wszystkiego naraz. Zacznij od jednego przepływu, który najczęściej wraca do ludzi, i dopiero potem dokładaj kolejne.

Drugi błąd to pominięcie wyjątków. Zamówienia nietypowe, korekty i zwroty rozstrzyga się na papierze przed uruchomieniem, nie po pierwszej pomyłce.

Trzeci błąd to brak jednego właściciela danych. Gdy dwa programy mogą zmienić tę samą cenę, ustal, który z nich decyduje.

Gdy program stoi na komputerze w biurze, traktujemy to jako stan przejściowy z planem przejścia. Wąska grupa firm naprawdę potrzebuje czegoś na miejscu i wtedy to zostaje, w najmniejszej możliwej wersji. Z naszego doświadczenia wersje w chmurze łączą się łatwiej, bo dostawcy częściej udostępniają w nich gotowe wejście dla innych programów. Nie każda jednak je ma, więc zapytaj o to dostawcę wprost.

Chmura też miewa przerwy po stronie dostawcy i zależy od Twojego łącza. Dlatego wdrażamy łącze zapasowe i trzymamy kopię najważniejszych danych poza tą jedną usługą.

Po wdrożeniu: integracja wymaga opieki

Połączenia między programami nie ustawia się raz na zawsze. Dostawca podnosi wersję albo zmienia coś u siebie i wymiana danych staje. To nie jest awaria z winy Twojej firmy, tylko normalny bieg rzeczy.

Dlatego po uruchomieniu ktoś musi pilnować tego połączenia i poprawiać je po zmianach u dostawcy. Ktoś musi zauważyć, że od wtorku nie przyszło żadne zamówienie, zanim zauważy to klient.

Jesteśmy partnerem technologicznym firm z Dolnego Śląska. Działamy jak Twój dział technologii, tylko bez etatu: wdrażamy, a potem opiekujemy się tym na co dzień. Zakres i czas reakcji ustala umowa, a wycenę podajemy po rozmowie.

Pytanie, które warto postawić przed startem, brzmi tak: kto utrzyma to połączenie w szóstym miesiącu? Osoba, która je ustawiała, będzie wtedy przy innym zadaniu.

Przykład: produkcja i magazyn

Weźmy firmę produkcyjną spod Lubina: 60 osób i trzy programy: sklep internetowy, magazyn i ERP. Dwie osoby przepisują zamówienia między nimi, a stan magazynu jest aktualny raz dziennie.

Po połączeniu z codziennej pracy znika kilka rzeczy. Nikt nie przepisuje zamówień, nikt nie tłumaczy klientowi, że towaru jednak nie ma, a reklamacja z błędnej ceny się nie zdarza.

Od czego zacząć, podpowiada tekst o tym, co warto zautomatyzować najpierw. Szerzej opisujemy to na stronie o automatyzacji procesów w firmie.

Przed pierwszym połączeniem warto też ustalić, gdzie żyją dane Twojej firmy, bo łatwiej łączy się programy, które stoją blisko siebie.

Zostaje jeszcze wybór samego programu: gotowe czy na zamówienie. Obie drogi bywają dobre, pod warunkiem że dane zostają Twoje.