Kiedy gotowy SaaS przestaje wystarczać i warto zbudować własny system?

Sprawdza się, gdy problemem jest brak widoczności i ręczne skakanie między narzędziami. Ryzyko wdrożenia jest umiarkowane, bo nie zmieniasz od razu systemów źródłowych. Ograniczenie też jest jasne: panel nie naprawi konfliktów danych, jeśli kilka systemów nadal może nadpisywać ten sam stan.

Warstwa integracyjna z orkiestracją i walidacją

Ten wariant jest potrzebny, gdy dane przepływają między wieloma usługami, ale nikt nie kontroluje semantyki procesu. Sama integracja API nie wystarcza. Potrzebna jest warstwa, która normalizuje dane, waliduje reguły, rozstrzyga konflikty i decyduje, co ma się wydarzyć dalej.

Różnica między zwykłą synchronizacją a orkiestracją jest praktyczna. Synchronizacja przenosi rekord zamówienia z e-commerce do ERP. Orkiestracja sprawdza, czy klient nie ma blokady płatniczej, czy wszystkie pozycje są dostępne w jednym magazynie, czy zamówienie wymaga podziału na dwie wysyłki, czy trzeba wstrzymać dokument do ręcznej akceptacji i który system powinien dostać kolejny status jako pierwszy. Dopiero potem wysyła polecenia do ERP, WMS i kanału sprzedaży oraz zapisuje przyczynę decyzji.

W takim układzie trzeba jasno wskazać system źródłowy dla każdej encji lub atrybutu. Klient może mieć źródło w CRM, stan magazynowy w WMS, dokument rozliczeniowy w ERP, ale status procesu zamówienia już we własnej warstwie. Bez tego każdy system próbuje być prawdą jednocześnie.

Dla firm działających na mieszance lokalnego ERP i kilku usług SaaS to często najrozsądniejszy kierunek. Zwłaszcza wtedy, gdy gotowe integracje przenoszą rekordy bez logiki biznesowej. W takich sytuacjach porządkowanie integracji Subiekt z e-commerce zaczyna się nie od kolejnego dodatku, tylko od ustalenia, kto ma prawo zmienić który stan i w jakiej kolejności.

Własny moduł domenowy dla krytycznego procesu

To najdalej idący wariant. Budujesz wydzielony obszar z własnym modelem danych, regułami i interfejsem, bo proces jest już częścią przewagi operacyjnej. Przykładem może być moduł orkiestracji zamówień, rozliczeń prowizyjnych, akceptacji kredytowej albo planowania kompletacji.

Tu przydaje się anti-corruption layer, czyli warstwa tłumacząca pojęcia starego lub zewnętrznego systemu na model własnej domeny. Bez niej zespół łatwo przeniesie ograniczenia SaaS do nowego rozwiązania i nazwie to modernizacją.

Taki moduł daje największą kontrolę, ale wymaga dyscypliny: wersjonowania zdarzeń, testów kontraktowych integracji, jawnego modelu uprawnień i planu współistnienia ze starym krajobrazem. Z obserwacji projektowych wynika jeden powtarzalny problem: awarie integracji rzadko są spektakularne. Zwykle są ciche i psują dane po trochu. Dlatego sens ma oparcie integracji na kontraktach, monitoringu i obserwowalności, a nie na założeniu, że zewnętrzne API zawsze odpowie poprawnie. W tym obszarze pomocne są wymagania z OWASP ASVS dotyczące kontroli dostępu, walidacji i śladu operacyjnego.

Przejęcie procesu powinno być etapowe. Najpierw nowa warstwa czyta zdarzenia i raportuje rozbieżności. Potem podejmuje decyzje w ograniczonym zakresie, na przykład tylko dla jednego kanału sprzedaży albo wybranych typów zamówień. Dopiero później staje się systemem sterującym.

Polska i UE: co jest obowiązkiem prawnym, a co problemem architektonicznym

W realiach Polski i UE temat nie kończy się na pytaniu, gdzie stoi serwer. Dla wielu firm ważniejsze są trzy rzeczy: transfer danych poza Europejski Obszar Gospodarczy, warunki powierzenia przetwarzania i możliwość odtworzenia decyzji systemu. To trzeba rozdzielić, bo obowiązki prawne i konsekwencje techniczne nie są tym samym.

Po stronie prawnej trzeba sprawdzić, czy dostawca daje poprawną podstawę przetwarzania i transferu danych, czy umowa powierzenia jest precyzyjna, czy lista podwykonawców jest jawna i czy wiadomo, gdzie dane są przechowywane. Przy transferach poza EOG liczą się nie tylko deklaracje marketingowe, ale też mechanizmy kontraktowe i realny model podpowierzenia. Po wyroku Schrems II sama ogólna obietnica zgodności nie wystarcza, jeśli organizacja nie potrafi ocenić, kto faktycznie ma dostęp do danych i na jakiej podstawie.

Po stronie architektonicznej liczy się coś innego: czy da się ograniczyć zakres danych wysyłanych do zewnętrznej usługi, czy eksport danych jest pełny i użyteczny technicznie, czy logi pozwalają odtworzyć decyzję systemu, czy retencja danych jest konfigurowalna i czy można odseparować dane wrażliwe od operacyjnych. To wpływa na koszt integracji, ryzyko lock-in i możliwość późniejszej migracji.

Przy ocenie dostawcy w Polsce i UE sprawdziłbym przede wszystkim pięć punktów:

• Eksport danych — czy obejmuje pełne rekordy, historię zmian i relacje, a nie tylko płaski CSV do raportu.
• Logi i audyt — czy można odtworzyć kto, kiedy i z jakiego powodu zmienił stan procesu.
• Podwykonawcy i lokalizacja przetwarzania — czy dostawca ujawnia łańcuch przetwarzania i regiony danych.
• Minimalizacja danych — czy integracja pozwala wysyłać tylko niezbędne atrybuty, zgodnie z zasadą ograniczenia zakresu.
• Warunki wyjścia — czy po zakończeniu współpracy da się pobrać dane i bezpiecznie usunąć je po stronie dostawcy.

W kontekście RODO znaczenie ma nie slogan o zgodności, tylko privacy by design z art. 25 oraz rozliczalność z art. 5 ust. 2. Pierwsza zasada wymaga, by kontrola i minimalizacja danych były częścią rozwiązania od początku. Druga oznacza, że organizacja musi umieć wykazać, co zrobiła z danymi i dlaczego. Jeśli obecny produkt utrudnia realizację tych obowiązków, problem nie jest już wyłącznie zakupowy.

Drugi temat to vendor lock-in. Nie chodzi o samo korzystanie z jednego dostawcy. Chodzi o sytuację, w której firma nie może szybko zmienić procesu, wyeksportować pełnych danych albo przejąć logiki bez kosztownego przepisywania wszystkiego. Własna warstwa pośrednia bywa wtedy nie luksusem, tylko polisą techniczną.

Na rynku polskim dochodzi jeszcze lokalny kontekst ERP, handlu i rozliczeń. Jeżeli zagraniczny produkt nie rozumie lokalnych dokumentów, stanów magazynowych, specyfiki B2B albo kolejności zdarzeń w operacji, próba dopasowania firmy do produktu bywa droższa niż przejęcie krytycznej logiki u siebie.

Jak zacząć bez przepalenia budżetu i bez nowego lock-in

Pierwszy zakres powinien zamknąć jeden krytyczny problem end-to-end. Nie portal klienta. Nie nowy CRM. Nie ogólną platformę operacyjną. Jeden przepływ, który dziś generuje koszt, ryzyko albo opóźnienie. Najczęściej będzie to orkiestracja zamówień, walidacja danych między systemami, obsługa wyjątków lub akceptacje.

Minimalny sensowny zakres obejmuje zwykle model danych dla kilku kluczowych encji, jawnie zapisane reguły biznesowe, historię zdarzeń i decyzji, panel wyjątków dla operacji oraz metryki sukcesu mierzone od początku działania rozwiązania.

Jeśli firma nie ma danych wejściowych, najpierw powinna je zebrać. Liczba ręcznych interwencji, typy wyjątków, czas korekt, źródła błędów, liczba eskalacji do IT, czas wdrożenia zmiany procesu. Bez tego rozmowa o zwrocie z inwestycji będzie opinią, nie decyzją.

Równie ważne jest ownership po stronie klienta. Jeżeli wykonawca ma zbudować własny moduł, klient powinien kontrolować repozytorium kodu, środowiska, dokumentację architektury, model danych, backlog reguł biznesowych i monitoring. Inaczej firma tylko zamieni lock-in dostawcy SaaS na lock-in software house'u.

Dobry pierwszy etap kończy się jednym z trzech wyników. Albo nowa warstwa przejmuje proces i daje podstawę do dalszej rozbudowy. Albo okazuje się, że wystarczy uporządkować integracje i zostać przy obecnym narzędziu. Bywa też mniej wygodna prawda: problemem nie był system, tylko nieustalony proces i brak właściciela decyzji.

Jeżeli środowisko obejmuje starsze systemy wewnętrzne, przejęcie logiki powinno iść etapami, podobnie jak przy migracji z legacy. Najpierw identyfikujesz krytyczny przepływ i ryzyko regresji, potem uruchamiasz odczyt zdarzeń, następnie ograniczoną decyzyjność, a dopiero na końcu pełne sterowanie.

Jeśli wystarczy przejąć walidację, wyjątki i kolejność decyzji, nie buduj całego systemu. Przejmij tylko ten fragment procesu, którego obecny SaaS nie potrafi kontrolować bez stałej pracy ręcznej.