Integracje systemów i API
Systemy, między którymi nikt nie musi już ręcznie przenosić danych. Dane przepływają automatycznie, a gdy coś pójdzie nie tak, wiadomo, co i kiedy.
Narzędzia, na których pracujemy
- Make
- n8n
- Zapier
- HubSpot
- Pipedrive
Objaw, po którym poznaje się brak integracji
Ktoś w firmie ma w kalendarzu cykliczne zadanie „eksport do arkusza”. Albo dwa systemy pokazują inną liczbę zamówień i wszyscy wiedzą, któremu wierzyć. Albo nowy klient trafia do CRM-u dopiero po tym, jak handlowiec wróci z delegacji.
Narzędzia nie są tu winne. Brakuje ustalenia, który system jest źródłem prawdy dla każdego pola. Bez tego ustalenia integracja sprawi, że systemy będą się nawzajem nadpisywać: szybciej niż człowiek i bez śladu.
W ProcessPilot ustalamy to przed pierwszą linijką integracji.
Co ustalamy przed pierwszą linijką
- Kierunek: dla każdego pola jeden system jest źródłem, pozostałe je odczytują. Dwukierunkowość tylko tam, gdzie naprawdę musi być, i zawsze z regułą rozstrzygania konfliktów.
- Częstotliwość: natychmiast po zdarzeniu czy paczką co godzinę. To różnica w koszcie i w limitach API, nie kwestia gustu.
- Zachowanie przy błędzie: ponowienie, kolejka, alert do konkretnej osoby. Integracja, która przy błędzie po prostu przestaje działać, jest gorsza od jej braku, bo nikt tego nie zauważy.
- Zakres danych: tylko pola, które są komuś potrzebne po drugiej stronie. Kopiowanie wszystkiego „na wszelki wypadek” to nadmiarowe przetwarzanie danych osobowych.
Na czym budujemy integracje: Make, n8n czy własna usługa
Tam, gdzie wystarczy platforma niskokodowa, używamy Make lub n8n: utrzymanie jest tańsze, a zmianę może wprowadzić także ktoś z Twojej strony. Tam, gdzie potrzebna jest własna logika, wolumen jest duży albo API jest nietypowe, piszemy usługę pośredniczącą.
Wybór opisujemy w wycenie razem z konsekwencją: kto będzie mógł to utrzymywać po zakończeniu wdrożenia. To zwykle ważniejsze niż sama technologia.
Co zostaje po nas
- Dokumentacja przepływów: co skąd dokąd, jak często i co się dzieje przy błędzie.
- Panel z historią wykonań i możliwością ręcznego ponowienia.
- Alerty do wskazanego kanału, gdy przepływ zatrzyma się dłużej niż na ustalony czas.
Pytania do tej strony
Nasz system nie ma API. Da się coś zrobić?
Zwykle tak, choć drożej i mniej elegancko: import i eksport plików po harmonogramie, dostęp do bazy w trybie odczytu albo integracja przez warstwę raportową. Sprawdzamy to przed wyceną, bo różnica w nakładzie bywa dwukrotna.
Co się stanie, gdy dostawca zmieni API?
Przepływy mają monitoring i alerty, więc zmiana wychodzi na jaw w dniu, w którym nastąpiła, a nie na koniec miesiąca. Takie poprawki robimy w ramach opieki powdrożeniowej i to jeden z głównych powodów, żeby ją mieć.
Czy integracja spowolni nasze systemy?
Nie, jeśli jest dobrze zaprojektowana: ruch idzie poza godzinami szczytu albo w małych paczkach. Ryzyko pojawia się przy odpytywaniu systemu źródłowego co kilka sekund, dlatego częstotliwość ustalamy w projekcie, zamiast zostawiać domyślną wartość z narzędzia.
Kto zauważy, że integracja przestała działać?
Monitoring, a nie osoba, która za tydzień zauważy brak danych. Przed uruchomieniem ustalamy dla każdego przepływu, po jakim czasie cisza oznacza awarię i kto dostaje wtedy alert.