Kierownik programu w firmie dystrybucyjnej dostaje od zarządu zadanie: do końca kwartału nowa platforma zamówień B2B ma rozmawiać z ERP, CRM-em i bramką płatności. Dostawca platformy twierdzi, że „ma gotowe API, więc integracja to kilka tygodni”. Dział IT szacuje to samo na pół roku. Dostawca ERP odpowiada, że udostępni dokumentację po podpisaniu osobnej umowy serwisowej. A zarząd chce znać jedną liczbę na posiedzeniu w przyszły wtorek.
Obie strony sporu mają trochę racji. Dostawca platformy mówi prawdę o swoim API, ale nie o API pozostałych systemów, o mapowaniu danych ani o tym, co się stanie, gdy płatność przyjdzie, a zamówienie w ERP się nie utworzy. Dział IT zna te problemy z doświadczenia, ale nie umie ich rozpisać tak, żeby zarząd zobaczył, skąd bierze się pół roku. Potrzebna jest metoda, która zamienia „integrację” na listę konkretnych elementów z liczbą osobodni przy każdym.
Ten artykuł pokazuje taką metodę. Rozkładamy projekt integracji systemów przez API na interfejsy, klasyfikujemy je według złożoności, liczymy przykładową integrację ERP, CRM i płatności w osobodniach i złotówkach, a potem przechodzimy przez koszty, których zwykle nie ma w pierwszej ofercie: limity API, licencje middleware, testy kontraktowe, opłaty operatorów płatności i utrzymanie. Na końcu znajdziesz listę pytań do dostawcy integracji.
Dlaczego „to tylko podpięcie API” jest najdroższym zdaniem w projekcie?
Bo opisuje mniej więcej jedną piątą pracy. Wywołanie API, które zwraca dane, to najprostsza część integracji i rzeczywiście da się ją zrobić w kilka dni. Reszta pracy to odpowiedzi na pytania, których to zdanie nie zadaje. Które pole w CRM odpowiada któremu polu w ERP i co zrobić, gdy w jednym systemie klient ma trzy adresy dostawy, a w drugim jeden? Co się dzieje, gdy ERP jest niedostępny przez dwie godziny w nocy z powodu kopii zapasowej? Jak uniknąć podwójnego zamówienia, gdy bramka płatności wyśle to samo powiadomienie dwa razy? Kto i jak dowie się, że od wczoraj 40 zamówień utknęło między systemami?
Skala problemu jest dobrze udokumentowana. W raporcie MuleSoft Connectivity Benchmark 2025, opartym na ankiecie wśród ponad 1 050 liderów IT, przeciętne przedsiębiorstwo zarządzało 897 aplikacjami, z których zintegrowanych było tylko 29%. Ankietowani deklarowali też, że 39% czasu zespołów IT pochłania projektowanie, budowa i testowanie integracji tworzonych na zamówienie. Integracje nie są więc pobocznym zadaniem projektu, tylko jedną z jego głównych pozycji kosztowych.
Drugi powód, dla którego to zdanie jest drogie: przenosi ryzyko na moment, w którym jest najdroższe. Jeśli w wycenie przyjęto, że integracja to „podpięcie API”, problemy z mapowaniem danych, brakującymi polami w API i niedostępnym środowiskiem testowym wychodzą w trakcie testów akceptacyjnych, kiedy harmonogram jest już napięty, a zespół rozliczany za każdy dzień. Ten sam problem odkryty w analizie kosztuje ułamek.
Wniosek dla kierownika programu: nie pytaj dostawcy, ile kosztuje „integracja”. Pytaj, ile kosztuje każdy interfejs osobno i co dokładnie obejmuje. Podstawowe pojęcia porządkuje hasło integracja systemów w naszym słowniku.
Z czego składa się wycena integracji systemów?
Podstawową jednostką wyceny jest interfejs, czyli jeden przepływ danych między dwoma systemami w określonym celu: „zamówienia z platformy do ERP”, „stany magazynowe z ERP do platformy”, „potwierdzenia płatności z bramki do ERP”. Interfejs ma kierunek, częstotliwość, format danych i właściciela po każdej stronie. Wycena „integracji z ERP” bez rozbicia na interfejsy jest jak wycena „remontu mieszkania” bez listy pomieszczeń.
Na każdy interfejs składa się sześć rodzajów pracy:
- Analiza i mapowanie danych. Ustalenie, które pola odpowiadają którym, jakie są słowniki (statusy, jednostki, waluty, stawki VAT) i co zrobić z rekordami, które nie pasują. To praca analityka z udziałem ekspertów biznesowych z obu stron.
- Budowa. Wywołania API, transformacje, zapisy, obsługa uwierzytelniania. Część, którą wszyscy widzą.
- Obsługa błędów i odporność. Ponawianie wywołań, kolejki na czas niedostępności systemu, idempotencja (żeby powtórzony komunikat nie utworzył drugiego zamówienia), kompensacja, gdy jeden krok się powiedzie, a drugi nie.
- Testy. Testy jednostkowe transformacji, testy integracyjne na środowiskach testowych obu stron, testy kontraktowe, testy end-to-end całego procesu biznesowego.
- Monitoring i operacje. Logowanie, alerty, panel z komunikatami, które utknęły, procedura ręcznej naprawy.
- Koordynacja. Komunikacja z dostawcami systemów po drugiej stronie, uzyskanie dostępów, uzgadnianie terminów okien wdrożeniowych.
Do tego dochodzi warstwa wspólna dla wszystkich interfejsów: sposób wymiany danych (bezpośrednie wywołania, kolejka komunikatów, platforma integracyjna), standard logowania i monitoringu oraz sposób zarządzania sekretami i dostępami. Buduje się ją raz, a jej koszt rozkłada się na wszystkie interfejsy. Przegląd wzorców tej warstwy znajdziesz w artykule o wzorcach i podejściach do integracji oprogramowania.
Jak klasyfikować interfejsy według złożoności?
Nie istnieje publiczny standard pracochłonności interfejsów, więc poniższe przedziały to nasze założenie do szacowania, a nie dane rynkowe. Służą do pierwszego przybliżenia i do sprawdzenia, czy oferta dostawcy jest w ogóle rozsądnego rzędu. Każdy przedział obejmuje wszystkie sześć rodzajów pracy z poprzedniej sekcji, a nie samo programowanie.
Interfejs prosty: 10–20 osobodni. Jednokierunkowy przepływ, okresowy (np. co 15 minut lub raz na dobę), po obu stronach udokumentowane REST API ze środowiskiem testowym, kilkanaście do dwudziestu kilku pól, proste słowniki. Przykład: eksport cennika z ERP do platformy sprzedażowej.
Interfejs średni: 20–45 osobodni. Dwukierunkowy albo zdarzeniowy (webhooki), ze statusami, które zmieniają się w czasie, mapowaniem kilku słowników, obsługą błędów i ponowień oraz wymaganiem, żeby powtórzony komunikat nie wywołał podwójnej operacji. Przykład: zamówienia z platformy do ERP i statusy realizacji z powrotem.
Interfejs złożony: 45–90 osobodni i więcej. System po drugiej stronie nie ma porządnego API, więc integracja idzie przez pliki, SOAP z niepełną dokumentacją, widoki bazy danych albo warstwę pośrednią; albo proces wymaga uzgadniania danych między systemami, transakcji wieloetapowych z kompensacją, migracji historii lub przetwarzania dużych wolumenów. Przykład: dwukierunkowa synchronizacja kartotek klientów między CRM a starszym ERP, w którym klient może mieć kilka kont.
Dwie rzeczy przesuwają interfejs między klasami bardziej niż technologia: jakość dokumentacji i dostępność środowiska testowego po drugiej stronie oraz czas reakcji dostawcy drugiego systemu. Interfejs, który technicznie jest prosty, staje się średni, gdy każde pytanie do dostawcy ERP czeka tydzień na odpowiedź. Dlatego przy klasyfikacji pytaj nie tylko „jakie jest API”, ale też „kto po drugiej stronie odpowiada na pytania i w jakim czasie”.
Z klasyfikacji wynika szybki test budżetu, który kierownik programu może zrobić sam, zanim zobaczy pierwszą ofertę. Policz interfejsy w każdej klasie, pomnóż przez przedział osobodni, dodaj 10–20% na warstwę wspólną i pomnóż przez stawkę dzienną. Program z czterema interfejsami prostymi, trzema średnimi i jednym złożonym to 4 × 10–20 + 3 × 20–45 + 1 × 45–90, czyli 145–305 osobodni, plus warstwa wspólna. Jeśli oferta dostawcy wynosi jedną trzecią tej liczby, nie znaczy to, że dostawca jest efektywny. Znaczy, że czegoś nie wycenił, i trzeba zapytać czego. Jeśli wynosi trzy razy więcej, zapytaj, które interfejsy dostawca uznał za złożone i dlaczego. Czasem ma rację, bo zna system po drugiej stronie lepiej niż Ty.
Jakie czynniki najmocniej podnoszą cenę integracji?
Poniższa tabela zbiera czynniki ceny, które warto przejść z dostawcą przed wyceną. Przy każdym podajemy, jak wygląda sytuacja tania i droga, oraz pytanie, które pozwala ją rozpoznać.
| Czynnik | Wariant tańszy | Wariant droższy | Pytanie do zadania przed wyceną |
|---|---|---|---|
| Jakość API drugiej strony | REST z opisem OpenAPI, sandbox, przykłady | Brak API, pliki, SOAP bez dokumentacji, widoki bazy | Czy jest specyfikacja API i działające środowisko testowe? |
| Kierunek i tryb przepływu | Jednokierunkowy, wsadowy, raz na dobę | Dwukierunkowy, zdarzeniowy, w czasie zbliżonym do rzeczywistego | Jak szybko dane muszą być po drugiej stronie i kto jest źródłem prawdy? |
| Mapowanie danych | Wspólne słowniki, kilkanaście pól | Różne modele danych, wiele słowników, pola wyliczane | Czy istnieje gotowe mapowanie pól i słowników zatwierdzone przez biznes? |
| Obsługa błędów | Ponowienie i alert wystarczą | Idempotencja, kompensacja, uzgadnianie danych | Co ma się stać, gdy jeden krok procesu się powiedzie, a drugi nie? |
| Wolumen i limity API | Kilkaset operacji dziennie | Setki tysięcy operacji, limity wywołań, potrzeba operacji wsadowych | Jaki jest dzienny wolumen i jakie limity ma nasz plan w systemie SaaS? |
| Bezpieczeństwo i zgodność | Klucz API, dane bez szczególnej ochrony | OAuth z rotacją, dane osobowe, dane płatnicze, audyt | Jakie dane płyną przez interfejs i kto odpowiada za ich ochronę? |
| Środowiska testowe | Pełne środowiska testowe po obu stronach | Brak sandboxa, testy na kopii produkcji lub na produkcji | Gdzie będziemy testować i kto przygotuje dane testowe? |
| Dostępność dostawcy drugiej strony | Odpowiedź w ciągu dnia, wspólny kanał | Pytania przez zgłoszenia serwisowe, płatne godziny konsultacji | Kto po drugiej stronie odpowiada na pytania techniczne i ile to kosztuje? |
| Warstwa integracyjna | Bezpośrednie wywołania między dwoma systemami | Platforma integracyjna z licencją, wiele systemów, kolejki | Czy potrzebujemy middleware i kto płaci za jego licencję? |
Z tabeli wynika praktyczna zasada: większość czynników ceny leży poza kodem. Dotyczą dokumentacji, środowisk, ludzi po drugiej stronie i decyzji biznesowych o danych. To dobra wiadomość dla kierownika programu, bo te czynniki można rozpoznać i częściowo usunąć przed startem, zanim zespół programistów zacznie rozliczać czas.
Jak wygląda przykładowa wycena integracji ERP, CRM i płatności?
Wróćmy do firmy z początku artykułu. Platforma zamówień B2B (zintegrowana z CRM) ma wymieniać dane z ERP i bramką płatności. Faktury wystawia ERP, który ma moduł do Krajowego Systemu e-Faktur; integracja ma przekazywać do platformy numer KSeF i status faktury, żeby klient widział je w swoim panelu.
Założenia: stawki z naszego cennika dla seniorów, czyli 1 440–2 080 zł netto za dzień (180–260 zł za godzinę); klasy złożoności jak w poprzedniej sekcji; ERP ma udokumentowane, choć niepełne API i środowisko testowe.
Rozpiska osobodni (dolna i górna granica):
- A. Zamówienia z platformy do ERP i statusy realizacji z powrotem (interfejs średni): 30–45 osobodni
- B. Ceny i stany magazynowe z ERP do platformy (prosty, bliżej średniego ze względu na ceny indywidualne): 15–25 osobodni
- C. Płatności: bramka, powiadomienia webhook, zwroty, uzgodnienie wpłat z ERP (średni): 20–35 osobodni
- D. Numer KSeF i status faktury z ERP do platformy (prosty): 10–15 osobodni
- E. Warstwa wspólna: kolejka, logowanie, monitoring, alerty, ponowienia: 15–25 osobodni
- Programowanie razem: 90–145 osobodni
- F. Testy kontraktowe, integracyjne i end-to-end, dane testowe: 20–30 osobodni
- G. Analiza mapowania danych i koordynacja z dostawcami systemów: 15–25 osobodni
- Razem: 125–200 osobodni
Arytmetyka:
- Dolna granica: 125 × 1 440 zł = 180 000 zł
- Górna granica: 200 × 2 080 zł = 416 000 zł
- Z rezerwą 20%: 216 000 – 499 200 zł
Rezerwa jest tu wyższa niż 15%, które zwykle przyjmujemy przy budowie aplikacji, bo w integracjach większa część ryzyka leży po stronie systemów, których nie kontrolujesz: niepełnego API, zmian wersji w trakcie projektu i dostępności ludzi po drugiej stronie.
W przeliczeniu na zespół 125–200 osobodni to ok. 7–11 osobomiesięcy przy 18 fakturowanych dniach w miesiącu, czyli na przykład trzy osoby przez 2,5–4 miesiące. To pozwala od razu sprawdzić realność terminu: jeśli zarząd oczekuje uruchomienia za sześć tygodni, potrzeba albo większego zespołu (co nie skraca czasu proporcjonalnie, bo koordynacja z dostawcami ma swoje tempo), albo węższego zakresu pierwszego etapu.
Najczęstszy sposób na skrócenie pierwszego etapu: uruchom najpierw interfejsy A i C, czyli zamówienia i płatności, a ceny i stany przez okres przejściowy importuj wsadowo raz na dobę. Statusy KSeF mogą poczekać na drugi etap, bo klient i tak dostaje fakturę tradycyjną drogą.
Ile kosztują limity API i dlaczego trzeba je policzyć przed startem?
Limity API to najczęściej pomijany koszt integracji z systemami SaaS, bo nie pojawiają się w ofercie dostawcy integracji, tylko w cenniku dostawcy systemu. Prawie każdy system SaaS ogranicza liczbę wywołań API w czasie, a limit zależy od wykupionego planu.
Dobry, publicznie udokumentowany przykład to HubSpot. Według dokumentacji HubSpot aplikacja prywatna na planach Free i Starter może wykonać 100 wywołań na 10 sekund i 250 000 wywołań dziennie na konto, na planie Professional 190 wywołań na 10 sekund i 625 000 dziennie, a na Enterprise 190 na 10 sekund i 1 000 000 dziennie. Istnieje też płatny dodatek zwiększający limity. Inne systemy mają inne liczby, ale mechanizm jest ten sam.
Dlaczego to ma znaczenie dla wyceny? Policzmy. Pierwsza synchronizacja 200 000 rekordów klientów przy limicie 100 wywołań na 10 sekund i jednym rekordzie na wywołanie to 20 000 sekund, czyli ok. 5,5 godziny ciągłej pracy, i to przy założeniu, że żadna inna integracja w tym czasie nie korzysta z tego samego limitu. Jeśli codzienny wolumen zbliża się do limitu dziennego, masz trzy wyjścia, a każde kosztuje: wyższy plan systemu SaaS, płatny dodatek zwiększający limity albo dodatkowa praca programistów nad operacjami wsadowymi, buforowaniem i synchronizacją przyrostową.
Co zrobić przed wyceną: dla każdego systemu SaaS w projekcie spisz limity API z dokumentacji dla Twojego planu, oszacuj dzienny wolumen operacji (z zapasem na wzrost) i sprawdź, czy API udostępnia operacje wsadowe. Jeśli wolumen przekracza połowę limitu, potraktuj to jako ryzyko i zaplanuj budżet na wyższy plan albo dodatkowe osobodni.
Na zużycie limitów wpływa też architektura interfejsu. Integracja, która co minutę odpytuje system „czy coś się zmieniło?”, zużywa limit nawet wtedy, gdy nic się nie dzieje: 1 440 wywołań na dobę na jeden typ obiektu, zanim przetworzy pierwszy rekord. Integracja oparta na powiadomieniach (webhookach), w której system źródłowy sam informuje o zmianach, zużywa wywołania tylko wtedy, gdy jest co przetwarzać. Budowa obsługi webhooków kosztuje więcej na starcie, bo wymaga publicznie dostępnego punktu odbioru, weryfikacji podpisów i obsługi powtórzeń, ale przy dużych wolumenach zwraca się na limitach i opóźnieniach. To decyzja, którą warto podjąć świadomie w analizie, a nie zostawić programiście w trakcie budowy.
Kiedy middleware lub iPaaS się opłaca i jak liczyć jego koszt?
Przy dwóch systemach bezpośrednie połączenie zwykle wystarczy. Przy pięciu systemach, które wymieniają dane w różnych kombinacjach, bezpośrednie połączenia zamieniają się w pajęczynę, w której każda zmiana w jednym systemie wymaga poprawek w kilku miejscach. Wtedy warto rozważyć warstwę pośrednią: szynę integracyjną, kolejkę komunikatów albo platformę integracyjną w modelu usługi (iPaaS).
Warstwa pośrednia ma koszt w dwóch miejscach. Pierwszy to licencja lub subskrypcja. Modele cenowe platform integracyjnych są różne: od liczby połączeń, od liczby środowisk, od wolumenu komunikatów, od liczby rdzeni obliczeniowych. Ceny rzadko są publiczne, a cenniki się zmieniają, dlatego nie podajemy tu kwot. Poproś każdego dostawcę platformy o wycenę dla Twojego wolumenu, liczby środowisk (produkcja, test, rozwój) i przewidywanego wzrostu na trzy lata. Pytaj wprost o koszt przekroczenia limitów i o minimalny okres umowy.
Drugi koszt to kompetencje. Platforma integracyjna wymaga ludzi, którzy ją znają. Jeśli po wdrożeniu nikt w firmie nie umie zmienić przepływu w platformie, każda zmiana staje się zleceniem dla zewnętrznego specjalisty.
Kiedy warstwa pośrednia się opłaca: gdy integrujesz więcej niż trzy, cztery systemy, gdy planujesz wymianę któregoś z nich w ciągu kilku lat (warstwa pośrednia izoluje pozostałe systemy od zmiany), gdy potrzebujesz centralnego monitoringu wszystkich przepływów albo gdy ten sam przepływ obsługuje wielu odbiorców. Kiedy się nie opłaca: przy dwóch, trzech systemach i stabilnym krajobrazie. Wtedy prosta kolejka i dobre logowanie wystarczą. Przy integracjach wystawiających własne API na zewnątrz rozważ też bramę API; jej rolę i wzorce opisuje artykuł o tym, czym jest API gateway.
Dlaczego testy kontraktowe i środowiska testowe to osobna pozycja budżetu?
Integracja psuje się zwykle nie w dniu uruchomienia, tylko kilka miesięcy później, gdy jedna ze stron zmieni API: doda wymagane pole, zmieni format daty, usunie wartość ze słownika. Jeśli nikt tego nie wykryje przed wdrożeniem, pierwszym sygnałem są reklamacje klientów albo niezgodności w księgowości.
Przed tym chronią testy kontraktowe. Każda ze stron integracji zapisuje swoje oczekiwania wobec drugiej (jakie pola, w jakim formacie, z jakimi wartościami) jako kontrakt, a automatyczne testy sprawdzają przy każdej zmianie kodu, czy kontrakt jest nadal spełniony. Wyjaśnienie metody znajdziesz w haśle contract testing, a praktyczne wdrożenie w architekturze mikroserwisów opisuje artykuł o testach kontraktowych i kompatybilności API.
Testy kontraktowe kosztują, bo wymagają trzech rzeczy: uzgodnienia kontraktów z drugą stroną, napisania testów i podpięcia ich do potoku ciągłej integracji. Przy systemach zewnętrznych, na których kod nie masz wpływu, część kontraktu weryfikuje się testami na ich środowisku testowym zamiast po obu stronach. W naszym przykładzie testy wszystkich rodzajów to 20–30 osobodni, czyli ok. 15–16% całego projektu. Jeśli oferta nie zawiera testów albo zawiera tylko „testy akceptacyjne po stronie klienta”, różnica nie zniknie, tylko przeniesie się na Twój zespół i na produkcję.
Osobnym kosztem są środowiska testowe po drugiej stronie. Część dostawców ERP i systemów branżowych udostępnia sandbox tylko w wyższych pakietach serwisowych albo za dodatkową opłatą. Brak środowiska testowego oznacza testy na kopii produkcji lub, w najgorszym przypadku, na produkcji, co zwiększa zarówno ryzyko, jak i pracochłonność. Zapytaj każdego dostawcę systemu po drugiej stronie, czy środowisko testowe jest w Twojej umowie, i wpisz koszt do budżetu, jeśli nie jest.
Jakie koszty płatności i regulacji trzeba doliczyć?
Integracja z bramką płatności ma koszt jednorazowy (budowa interfejsu) i koszt bieżący, którego nie ma w ofercie dostawcy integracji: prowizje od transakcji. Na przykład Stripe w Polsce podaje w cenniku stawkę 1,5% + 1 zł dla standardowych kart z EOG, 2,5% + 1 zł dla kart z Wielkiej Brytanii i 3,25% + 1 zł dla kart międzynarodowych, z dodatkowymi 2% przy przewalutowaniu. Inni operatorzy mają inne cenniki i warunki negocjowane przy większych wolumenach. Przy zamówieniu B2B za 5 000 zł prowizja 1,5% + 1 zł to 76 zł, więc przy tysiącu takich zamówień miesięcznie to 76 000 zł miesięcznie. Ta liczba powinna być w business case, a nie odkryta po pierwszej fakturze operatora.
Integracja płatności ma też wymagania, które podnoszą pracochłonność: obsługę powiadomień, które mogą przyjść kilka razy lub w innej kolejności, zwrotów częściowych, płatności nieudanych i uzgadniania wpłat z księgowością. Dlatego w naszym przykładzie interfejs płatności jest średni, a nie prosty, mimo że API operatorów płatności jest zwykle bardzo dobrze udokumentowane.
Drugi koszt regulacyjny w Polsce to KSeF. Według portalu Ministerstwa Finansów obowiązek wystawiania faktur w Krajowym Systemie e-Faktur dotyczy od 1 lutego 2026 roku firm, których sprzedaż w 2024 roku przekroczyła 200 mln zł, a od 1 kwietnia 2026 roku pozostałych przedsiębiorców, z wyjątkami przejściowymi do końca 2026 roku. Większość systemów ERP ma dziś moduły KSeF, ale każdy proces, który korzysta z faktur (portal klienta, windykacja, uzgadnianie płatności), może potrzebować numeru KSeF i statusu faktury. Jeśli Twój ERP nie przekazuje tych danych przez API, to dodatkowy interfejs w projekcie.
Fixed price czy time and materials: jak rozliczać projekt integracyjny?
Projekty integracyjne mają nietypowy profil ryzyka: duża część niepewności leży po stronie systemów i ludzi, których ani Ty, ani dostawca integracji nie kontrolujecie. To wpływa na wybór modelu rozliczenia.
Stała cena ma sens dla interfejsu, który ma udokumentowane API, działające środowisko testowe, zatwierdzone mapowanie danych i znaną osobę kontaktową po drugiej stronie. Wtedy dostawca może rzetelnie oszacować pracę, a Ty dostajesz przewidywalność. Przy interfejsach z niewiadomymi stała cena będzie zawierała wysoką rezerwę albo prowadziła do sporów o to, czy „niedziałające API dostawcy ERP” jest w zakresie.
Time and materials ma sens dla interfejsów złożonych i niepewnych. Kontrolę zapewniasz budżetem na interfejs, cotygodniowym raportem postępu i jasnym kryterium zakończenia.
Model, który w projektach integracyjnych zwykle działa najlepiej, to podział na etapy. Pierwszy etap to analiza w stałej cenie: inwentaryzacja interfejsów, sprawdzenie API i środowisk po każdej stronie, mapowanie danych, klasyfikacja złożoności. Jej wynikiem jest lista interfejsów z wyceną. Następnie interfejsy proste i średnie z kompletną analizą można wycenić ryczałtowo, a złożone w time and materials z limitem budżetu. Mechanizm podziału ryzyka w stałej cenie opisaliśmy w artykule o tym, kto naprawdę płaci za przeniesienie ryzyka w fixed price.
O co zapytać dostawcę integracji przed podpisaniem umowy?
Lista pytań, która pozwala porównać oferty i wychwycić założenia przemilczane przez dostawcę:
- Na ile interfejsów rozbiliście projekt i ile osobodni przypisaliście każdemu? Brak rozbicia uniemożliwia porównanie ofert i rozliczanie zmian.
- Co dokładnie obejmuje każdy interfejs? Kierunek, częstotliwość, mapowanie, obsługa błędów, idempotencja, monitoring.
- Jakie założenia przyjęliście o API i środowiskach po drugiej stronie? Jeśli oferta zakłada sandbox, którego nie ma, wycena jest nieaktualna.
- Jak testujecie i czy w zakresie są testy kontraktowe? Kto przygotowuje dane testowe i na jakich środowiskach odbywają się testy.
- Jak wygląda monitoring i obsługa błędów po uruchomieniu? Kto dostaje alert, w jakim czasie reaguje, jak naprawia się komunikaty, które utknęły.
- Jakie koszty po stronie dostawców systemów i licencji przewidujecie? Plany SaaS ze względu na limity API, licencje middleware, płatne środowiska testowe, godziny konsultacji dostawcy ERP.
- Kto jest właścicielem kodu integracji i konfiguracji platformy integracyjnej? Dostęp do repozytorium i dokumentacja przepływów.
- Co się dzieje, gdy dostawca systemu po drugiej stronie zmieni API? Kto to wykrywa, kto naprawia i w jakim trybie rozliczenia.
Sygnały ostrzegawcze: jedna kwota za „integrację z ERP” bez rozbicia, brak słowa o obsłudze błędów i monitoringu, testy „po stronie klienta”, założenie, że wszystkie systemy mają gotowe API, bez sprawdzenia, oraz brak pozycji na analizę mapowania danych. Każdy z nich nie musi oznaczać złej woli, ale każdy oznacza koszt, który pojawi się później. Jeśli projekt integracyjny już trwa i te koszty właśnie się pojawiają, warto najpierw zrobić przegląd tego, co zostało zbudowane, zanim zamówi się kolejny etap.
Ile kosztuje utrzymanie integracji po uruchomieniu?
Integracja nie jest skończona w dniu uruchomienia. Systemy po obu stronach się zmieniają, dostawcy SaaS wydają nowe wersje API i wycofują stare, zmieniają się przepisy (stawki, formaty dokumentów), a biznes dodaje nowe pola i statusy. Każda taka zmiana wymaga przeglądu mapowań, testów i czasem przebudowy fragmentu interfejsu.
Nie ma publicznego źródła, które mierzyłoby koszt utrzymania integracji, więc podajemy założenie do budżetu: 10–20% kosztu budowy rocznie. Dla przykładu z tego artykułu (180–416 tys. zł) to ok. 18–83 tys. zł rocznie. Dolny koniec dotyczy stabilnego krajobrazu, w którym większość systemów to dojrzałe ERP z rzadkimi zmianami API. Górny koniec dotyczy integracji z wieloma systemami SaaS, które często wydają nowe wersje API.
Na ten koszt składają się: monitoring i reagowanie na alerty, ręczna naprawa komunikatów, które utknęły, aktualizacje po zmianach wersji API, aktualizacje bibliotek i zabezpieczeń oraz drobne zmiany mapowań zgłaszane przez biznes. Do tego koszty bieżące niezależne od pracy: subskrypcje platformy integracyjnej, wyższe plany SaaS ze względu na limity, prowizje płatnicze.
Najlepszym sposobem na obniżenie kosztu utrzymania jest jakość budowy: testy kontraktowe, które wychwytują zmiany przed produkcją, monitoring, który pokazuje problem, zanim zgłosi go klient, i dokumentacja przepływów, dzięki której zmianę może zrobić osoba, która integracji nie budowała.
Jak zacząć: od mapy interfejsów do wiarygodnej wyceny?
Zanim zaprosisz dostawców do ofertowania, przygotuj trzy rzeczy. Po pierwsze, mapę interfejsów: listę przepływów danych z kierunkiem, częstotliwością i celem biznesowym każdego z nich. Po drugie, dla każdego systemu informację o API: czy jest, w jakim standardzie, czy jest dokumentacja i środowisko testowe, jakie są limity w Twoim planie i kto po drugiej stronie odpowiada na pytania. Po trzecie, wolumeny: ile zamówień, płatności, rekordów klientów dziennie, dziś i za trzy lata. Podstawy techniczne dla osób nietechnicznych porządkuje hasło API w słowniku.
Z takim materiałem dostawcy będą wyceniać to samo, a Ty porównasz oferty po interfejsach, a nie po jednej kwocie. Metody szacowania projektów IT w ogóle opisuje hasło wycena projektu IT.
Jeśli chcesz przejść ten proces z nami, zespół software development w ARDURA Consulting realizuje integracje systemów przez API i middleware. Zaczynamy od analizy, która kończy się mapą interfejsów z klasyfikacją złożoności, listą ryzyk po stronie systemów zewnętrznych i wyceną w osobodniach z jawnymi stawkami. Testy integracyjne i kontraktowe może przejąć nasz zespół testowania oprogramowania. Szersze tło, czyli to, jak podchodzimy do łączenia systemów w spójną architekturę, opisuje artykuł o integracji systemów IT.