Połączenie AI z systemami, w których pracuje Twoja firma

Podłączyć się można przez API, przez webhooki albo przez wymianę plików i odczyt z bazy. Najwygodniejsze jest API — system udostępnia opisane operacje, a my odczytujemy i zapisujemy dane w kontrolowany sposób. Webhooki to powiadomienia wysyłane przez system w momencie zdarzenia, dzięki czemu nie trzeba go stale odpytywać. Wymiana plików albo odczyt z bazy zostaje tam, gdzie interfejsu po prostu nie ma. Kolejność nie jest przypadkowa: im dalej od API, tym więcej opóźnień, wyjątków i miejsc, w których integracja urwie się po aktualizacji systemu.

Większość rozmów o integracji zaczyna się od pytania, czy da się połączyć system A z systemem B. Naszym zdaniem to złe pierwsze pytanie, bo odpowiedź prawie zawsze brzmi „da się" — różnica leży w tym, ile będzie kosztować utrzymanie tego połączenia przez kolejne lata. Dlatego zaczynamy od innego pytania: co konkretnie ma się wydarzyć w drugim systemie, jak często i kto to zauważy, gdy się nie wydarzy. Jeśli odpowiedź brzmi „chcemy mieć wszystko w jednym miejscu", to nie jest jeszcze wymaganie, tylko życzenie — a integracja zbudowana na życzeniu rozrasta się w nieskończoność, bo nigdy nie wiadomo, kiedy jest skończona.

Między własnym konektorem a gotowym łącznikiem w n8n albo Make wybieramy gotowy, dopóki się da. Własny kod jest przyjemniejszy do pisania i daje pełną kontrolę, ale to Wy płacicie za jego utrzymanie: za każdą zmianę wersji API, za każdą aktualizację biblioteki i za to, że po roku ktoś musi wejść w ten kod od nowa. Własny konektor piszemy wtedy, gdy gotowy nie obsługuje operacji, której naprawdę potrzebujecie, albo gdy wolumen danych rozsadza limity narzędzia. Kolejność jest tu ważniejsza, niż się wydaje: wybór narzędzia to ostatnia decyzja w projekcie integracyjnym, a nie pierwsza.

Najpierw sprawdzamy, czy „nie ma API" znaczy naprawdę „nie ma", czy tylko „nikt u nas o nie nie pytał". Zaskakująco często interfejs istnieje, ale jest w wyższym pakiecie, wymaga aneksu albo zgłoszenia przez opiekuna handlowego. Dopiero gdy to odpadnie, schodzimy niżej: eksport plików uruchamiany cyklicznie przez sam system, raporty wysyłane na skrzynkę, odczyt z bazy danych, jeśli macie do niej prawo i zgodę. Każdy z tych wariantów działa, ale każdy jest umową z systemem, którego nie kontrolujecie — i trzeba to powiedzieć na początku, a nie po pierwszej awarii.

Osobno traktujemy automatyzację klikania w cudzym interfejsie. Uważamy, że to nie jest integracja, tylko zakład o to, że nikt nie przesunie przycisku ani nie zmieni nazwy zakładki — a przy aktywnie rozwijanym produkcie ten zakład przegrywa się regularnie. Robimy takie rozwiązania wyłącznie wtedy, gdy proces jest naprawdę kosztowny, a innej drogi nie ma, i mówimy wprost, że budżet na utrzymanie będzie tu większy niż w każdym innym wariancie. Krytykujemy przy tym praktykę, a nie dostawców: zamknięty interfejs bywa świadomą decyzją produktową i sam w sobie nie jest niczyją winą.

Gdy dostawca po prostu nie chce współpracować, dźwignia leży nie po naszej stronie, tylko po Waszej — to Wy jesteście stroną umowy i to Wasze zgłoszenie ma wagę. Podpowiadamy, o co zapytać i jak sformułować wymaganie technicznie, ale rozmowę handlową prowadzicie sami. A jeśli kluczowy system jest jednocześnie zamknięty i niezastępowalny, uczciwiej jest rozmawiać o jego wymianie w perspektywie kilku lat niż o obejściu, które trzeba będzie naprawiać co kwartał. Wolimy stracić zlecenie na tym etapie, niż oddać rozwiązanie, które psuje się szybciej, niż zdąży się zwrócić.

1. 01Sprawdzamy, czy interfejs faktycznie nie istniejeDokumentacja, pakiety licencyjne, wtyczki i moduły dodatkowe. Zdarza się, że API jest, tylko trzeba je włączyć i zapłacić za wyższy plan — a to i tak zwykle tańsze niż obejście.
2. 02Szukamy drogi wyjścia danych, którą system już maCykliczny eksport, raport na skrzynkę, plik na dysku sieciowym, odczyt z bazy. Wybieramy tę, która zmienia się najrzadziej, a nie tę, którą najszybciej podłączyć.
3. 03Wyceniamy utrzymanie, zanim wycenimy budowęPrzy obejściu koszt utrzymania jest głównym kosztem projektu, więc podnosimy go jako pierwszy. Wycena bez tej pozycji byłaby wprowadzaniem Was w błąd.
4. 04Ustalamy, co się dzieje, gdy obejście przestanie działaćKto dostaje alert, kto ma wrócić do pracy ręcznej i na jak długo. Obejście bez planu awaryjnego to tylko przesunięcie problemu na gorszy moment.

Automat dostaje osobne konto techniczne z uprawnieniami ograniczonymi do tego, co proces naprawdę robi — ten, który tylko czyta zamówienia, nie ma prawa kasować kartotek. Klucze i tokeny trzymamy w miejscu przeznaczonym do sekretów, nie w treści przepływu, i ustalamy zasady ich wymiany. Przy OAuth pilnujemy, żeby autoryzacja nie wisiała na prywatnym koncie pracownika, który kiedyś odejdzie z firmy. Osobno spisujemy, jakie dane osobowe przechodzą przez którą usługę — to materiał dla Waszego rejestru czynności przetwarzania.

Najczęstszy antywzorzec wygląda tak: integracja startuje na koncie administratora, „na razie, żeby w ogóle zadziałało", i tak zostaje na lata. Rozumiemy, skąd to się bierze — pełne uprawnienia usuwają jedną klasę problemów w dniu wdrożenia i dokładają inną, której nie widać przez pierwsze miesiące. Uważamy, że wąskie konto techniczne to nie formalność dla audytu, tylko element działającego systemu: gdy automat nie ma prawa czegoś zepsuć, nie trzeba potem ustalać, czy to on zepsuł. Jeśli Wasz system nie pozwala nadać wąskich uprawnień, wolimy zapisać to jako znane ryzyko, niż udawać, że go nie ma.

Odradzamy też najwygodniejsze rozwiązanie świata, czyli podpięcie autoryzacji pod prywatne konto pracownika. Działa od ręki i przestaje działać w dniu, w którym ten pracownik zmienia hasło albo odchodzi z firmy — a wtedy awaria spada na osobę, która o istnieniu integracji dowiaduje się przy okazji. To samo dotyczy kluczy wklejanych w treść przepływu: wygodne przy pierwszym uruchomieniu, kłopotliwe przy pierwszym przekazaniu projektu komukolwiek innemu.

• Osobne konto techniczne dla przepływu, zamiast jednego wspólnego do wszystkiego
• Zakres uprawnień spisany operacja po operacji, razem z odpowiedzią, po co dana operacja jest potrzebna
• Wskazana osoba po Waszej stronie, która odpowiada za dostępy po zakończeniu wdrożenia
• Zgoda na trzymanie kluczy w magazynie sekretów i ustalony termin ich wymiany
• Lista danych osobowych przechodzących przez każdą usługę — do Waszego rejestru czynności

Mapowanie pochłania najwięcej czasu, bo różne systemy prawie nigdy nie opisują tej samej rzeczy tak samo. Trzeba uzgodnić identyfikator klienta, przetłumaczyć statusy zamówień, ujednolicić format dat, kraje, jednostki i stawki VAT, a przede wszystkim rozstrzygnąć, który system jest źródłem prawdy dla danego pola. Do tego dochodzą duplikaty, rekordy niekompletne i pytanie, co się dzieje, gdy ten sam rekord zmieni się po obu stronach w tym samym czasie. Te decyzje podejmuje osoba znająca dane merytorycznie, my zapisujemy je w mapie pól i wdrażamy.

Najczęstsze nieporozumienie brzmi: mapowanie to zadanie techniczne, więc zróbcie je u siebie i dajcie znać, jak skończycie. Naszym zdaniem jest odwrotnie — techniczna jest tu ostatnia godzina pracy, a cała reszta to decyzje biznesowe, których nikt z zewnątrz nie podejmie za Was. Co znaczy status „w realizacji" w firmie, w której magazyn i handlowcy używają go do dwóch różnych rzeczy? Który system ma rację, gdy adres klienta różni się w CRM i w ERP? To pytania o to, jak działa firma, a nie o to, jak działa API — i dlatego prosimy o osobę znającą dane, a nie o kolejny dostęp.

W sporze o synchronizację dwukierunkową stajemy po jednej stronie: dla każdego pola wybieramy jeden system jako źródło prawdy, nawet gdy technicznie da się synchronizować w obie strony. Dwukierunkowa synchronizacja tego samego pola jest najdroższą rzeczą w całej integracji, bo wymaga rozstrzygnięcia każdego konfliktu — a konflikty pojawiają się dokładnie wtedy, gdy nikt nie patrzy. Wyjątki robimy świadomie i zawsze z regułą rozstrzygania zapisaną wprost, nie domyślną. Sama mapa pól nie jest przy tym dokumentem na czas wdrożenia: to jedyne miejsce, w którym za dwa lata sprawdzicie, dlaczego coś działa właśnie tak.

Integracja psuje się, bo jest umową między dwoma systemami, które rozwijają się niezależnie od siebie. Dostawca podnosi wersję API i wycofuje starą, zmienia nazwę pola, dokłada wymagany parametr, zaostrza limity zapytań, zmienia format eksportu albo skraca ważność tokenów. Żadna z tych zmian nie jest błędem po jego stronie — to normalne życie produktu. Błędem jest założenie po stronie kupującego, że raz zbudowane połączenie będzie działać samo, bo przecież działało.

Płaci za to zawsze właściciel procesu, tylko czasem robi to świadomie, a czasem cudzym czasem — godzinami pracownika, który po cichu wrócił do ręcznego przepisywania, bo „ostatnio to się rozjeżdżało". Naszym zdaniem koszt utrzymania powinien pojawić się w rozmowie w tym samym zdaniu co koszt budowy i to my mamy obowiązek go podnieść, zanim padnie pytanie o cenę. W perspektywie kilku lat uważamy, że utrzymanie integracji potrafi kosztować więcej niż jej zbudowanie — nie dlatego, że coś zrobiono źle, tylko dlatego, że budowa jest jednorazowa, a zmiany po drugiej stronie nie są. Wolimy powiedzieć to przed podpisaniem umowy i przegrać na tle tańszej oferty, niż tłumaczyć się z tego po pierwszej awarii.

Z tego samego powodu uważamy, że integracja bez monitoringu jest gorsza niż jej brak. Brak integracji widać od pierwszego dnia i ktoś radzi sobie ręcznie; cicha awaria wygląda dokładnie tak samo jak działający system, tylko dane przestają dopływać — a wychodzi to przy zamknięciu miesiąca, inwentaryzacji albo reklamacji klienta. Zdrowa integracja ma alert kierowany do konkretnej osoby, kolejkę operacji do ponowienia i miejsce, w którym widać, co nie przeszło. To nudna część projektu i zwykle pierwsza wycinana z budżetu — naszym zdaniem błędnie, bo jest jedyną, która sama się o siebie upomni.

Jeśli proces uruchamia się kilka razy w miesiącu i zajmuje jednej osobie kilkanaście minut, odradzamy integrację. Nie zwróci się w żadnym rozsądnym horyzoncie, a dołoży element, który trzeba utrzymywać, monitorować i tłumaczyć nowym pracownikom. Powiemy to na pierwszej rozmowie, zamiast wystawić fakturę i zostawić Was z konektorem, o którym za rok nikt nie będzie pamiętał, po co powstał. Integracja opłaca się tam, gdzie coś dzieje się często, powtarzalnie i kosztuje więcej niż sam czas — bo błąd w przepisaniu ma konsekwencje w zamówieniu, magazynie albo rozliczeniu.

Drugi przypadek, w którym odradzamy, to proces, który dopiero się kształtuje. Integracja zamraża reguły — jeśli za miesiąc zmienicie sposób pracy, trzeba ją przerobić, a przerabianie bywa droższe niż zbudowanie od zera. Trzeci to system z ogłoszonym terminem wymiany: budowanie mostu do budynku przeznaczonego do rozbiórki wygląda na oszczędność tylko w tym kwartale, w którym zapada decyzja. Czwarty jest najtrudniejszy do powiedzenia na głos — brak osoby po Waszej stronie, która weźmie na siebie decyzje o danych. Bez niej integracja i tak powstanie, tylko na naszych domysłach, a domysły wychodzą przy pierwszym raporcie zarządczym.

Ręczne przepisywanie danych ma przy tym jedną przewagę, o której w ofertach się nie wspomina: nie psuje się po cichu. Człowiek, który nie zdążył przenieść zamówień, powie o tym; przepływ, który przestał je przenosić, nie powie nic. Dlatego zanim zaproponujemy integrację, pytamy, ile realnie kosztuje dziś praca ręczna — nie w poczuciu uciążliwości, tylko w minutach i w konsekwencjach błędu. Jeśli po tej rozmowie wychodzi, że taniej jest zostawić, jak jest, mówimy to wprost. Sprzedanie integracji, która się nie zwróci, udaje się raz; my wolimy pracować z tym samym klientem drugi i trzeci raz.

• Proces uruchamia się rzadko, a jego ręczne wykonanie zajmuje kilkanaście minut
• Reguły procesu zmieniają się szybciej, niż zdąży powstać wdrożenie
• Jeden z łączonych systemów ma ogłoszony termin wymiany
• Nikt po stronie firmy nie chce wziąć na siebie decyzji o znaczeniu pól
• Dane są potrzebne raz, na potrzeby jednej migracji, a nie na stałe
• Koszt ewentualnego błędu jest niższy niż koszt utrzymania połączenia