Jak konsultanci AI określają zakres własnego zamiennika SaaS

Każdy konsultant warty swojej stawki dziennej określa zakres zastąpienia oprogramowania SaaS rozwiązaniem własnym w ten sam sposób: dzieli każde narzędzie na części widoczne oraz te, które muszą działać bezbłędnie za każdym razem. SaaS (oprogramowanie wynajmowane w modelu miesięcznym) to w większości ekrany, przepływy pracy i raporty opierające się na mniejszym rdzeniu rejestracji danych. AI sprawiła, że odbudowa pierwszej połowy stała się tania. Druga połowa to miejsce, w którym projekty wymiany upadają, a dobry zakres służy ustaleniu, jaka część rachunku za subskrypcję faktycznie tam trafia.

Oto jak krok po kroku powstaje zakres własnego zamiennika SaaS i jedno pytanie, które decyduje o większości z nich. (Nazwy dostawców i dane z badań podane poniżej są aktualne na dzień publikacji; traktuj szczegóły jako opis stanu z danego momentu).

Co tak naprawdę zawiera zakres zastąpienia oprogramowania SaaS?

Inwentaryzację zadań, a nie listę funkcji. Konsultant tworzy listę wszystkich zadań wykonywanych przez narzędzie, osób mających z nimi styczność oraz skutków błędnego wyniku. Ścieżki zatwierdzania, pulpity i formularze trafiają do jednej kolumny. Przepływy pieniężne, stany magazynowe, podatki i ewidencja pracowników — do drugiej. Produktem końcowym jest ta mapa, ocena ryzyka dla każdego zadania oraz lista wszystkich systemów, z którymi narzędzie jest po cichu połączone.

Pytanie oceniające stanowi sedno sprawy: gdyby ten wynik był błędny, jak byś się o tym dowiedział i ile by to kosztowało? Nieaktualny pulpit zauważa się od razu i nic to nie kosztuje. Błędna kwota wypłaty wychodzi na jaw przy rozliczeniu podatkowym i kosztuje realne pieniądze.

Dlaczego warto podzielić produkt na dwie warstwy?

Ponieważ AI drastycznie obniżyła koszt jednej warstwy, pozostawiając drugą bez zmian. Warstwę interfejsu (formularze, pulpity, narzędzia wewnętrzne, przepływy zatwierdzania) można obecnie szybko odbudować; obecne modele generują działające aplikacje internetowe w kilka godzin — dokładnie to ustaliliśmy, pytając czy GPT-5.6 może zbudować działający POS. Warstwa infrastruktury wygląda inaczej: przetwarzanie płatności, zgodność ze standardem PCI (zasady bezpieczeństwa kart egzekwowane przez dostawców płatności), stany magazynowe przy jednoczesnych transakcjach (dwie kasy sprzedające tę samą, ostatnią sztukę) oraz spójne raporty (sumy zgadzające się z wpłatą na konto bankowe). Ta warstwa nie jest trudna ze względu na długość kodu. Jest trudna, ponieważ wynik „prawie poprawny” nie ma tam żadnej wartości, a udowodnienie poprawności kosztuje więcej niż wygenerowanie kodu.

Lepsze modele również nie usuwają tego ograniczenia. Wąskim gardłem jest weryfikacja i odpowiedzialność, a nie generowanie kodu, dlatego rzetelny zakres wycenia weryfikację. Generowanie to wersja demonstracyjna. Weryfikacja to faktura.

Co tak naprawdę udowodniło zastąpienie SaaS w Klarnie?

Głośna historia o tym, że „zastąpiliśmy nasz SaaS sztuczną inteligencją”, to w rzeczywistości lekcja określania zakresu. Pod koniec 2024 roku prezes Klarny ogłosił, że firma rezygnuje z Salesforce i Workday w ramach reorganizacji opartej na AI, a nagłówki donosiły, że AI całkowicie zastępuje SaaS. Dalsze doniesienia ujawniły bardziej szczegółowy obraz: Klarna przeniosła HR do innego dostawcy, a swoje potrzeby w zakresie CRM zaspokoiła połączeniem alternatywnych narzędzi i własnych integracji, uzupełnionych o AI¹. Licencjonowany bank realizujący jeden z najbardziej agresywnych programów AI w branży fintech nadal utrzymywał swoje systemy ewidencji (wiarygodne źródło danych biznesowych) na sprawdzonych platformach, przebudowując jedynie elementy pomocnicze.

To nie był brak odwagi. To był prawidłowo działający zakres.

Jakie liczby uzasadniają projekt wymiany?

Najpierw eliminacja marnotrawstwa, potem budowanie. Raport Zylo 2026 SaaS Management Index, oparty na analizie ponad 40 milionów zarządzanych licencji, szacuje medianę wydatków na SaaS na 9 455 USD rocznie na pracownika, wskazuje, że średnio 36% licencji pozostaje niewykorzystanych, oraz pokazuje, że jednostki biznesowe kontrolują 81% wydatków na SaaS, podczas gdy dział IT bezpośrednio zarządza zaledwie 15%². Konsultant ocenia Twój stos technologiczny w odniesieniu do tych danych przed zaproponowaniem jakichkolwiek zmian: anuluje niewykorzystane licencje, konsoliduje nakładające się narzędzia i dopiero wtedy tworzy listę kandydatów do odbudowy.

Narzędzia trafiające na krótką listę mają wspólny profil: wysokie koszty cykliczne, zadania usytuowane głównie w warstwie interfejsu oraz niewielkie konsekwencje w przypadku awarii. Projekt uzyskuje akceptację, gdy koszt subskrypcji rośnie szybciej niż koszt budowy i utrzymania, a każde zadanie wymagające bezwzględnej poprawności może pozostać na infrastrukturze zarządzanej przez kogoś innego.

Gdzie w tym procesie mieści się POS?

Na najbardziej wymagającym końcu spektrum. System POS wygląda jak projekt interfejsu — siatka przycisków i koszyk — dlatego właściciele zakładają, że jego zakres określa się jak w przypadku pulpitu nawigacyjnego. Proporcje są jednak odwrotne. Ekrany realizacji transakcji to tylko mały fragment produktu; cała reszta to płatności, certyfikowany sprzęt do płatności kartą, stany magazynowe odporne na jednoczesną sprzedaż na dwóch kasach, reguły podatkowe i spójne raporty zamknięcia dnia. Gdy system POS popełnia błąd, popełnia go w kwestii pieniędzy — każdego dnia.

Dlatego konsultanci określają zakres odbudowy systemu POS tak samo, jak Klarna określiła zakres dla księgi głównej: dostosowany interfejs, sprawdzona infrastruktura. Taki podział wymagał kiedyś zespołu programistów. Dziś to osobna kategoria produktów: narzędzie Build firmy Final przekształca polecenie napisane w zwykłym języku w proces realizacji transakcji, który możesz przejrzeć i wdrożyć, a także pozwala podłączyć własną sztuczną inteligencję przez protokół MCP, aby budować w oparciu o tę samą infrastrukturę handlową. Płatności, stany magazynowe, raportowanie i sprzęt pozostają w warstwie, która jest już zweryfikowana.

Jak zatem określić zakres własnego zamiennika SaaS?

Podziel każde narzędzie na dwie warstwy, oceń każde zadanie na podstawie kosztu niewykrytego błędu i wyceniaj weryfikację, a nie kod. Swobodnie odbudowuj interfejsy i przepływy pracy, pozostawiając systemy ewidencji na infrastrukturze, o której poprawność dba ktoś inny. Zanim odbudujesz jakiekolwiek narzędzie we własnym zakresie, zapytaj: gdyby jego wynik był błędny, jak szybko bym się o tym dowiedział? Jeśli odpowiedź brzmi „nienatychmiast”, to zadanie powinno pozostać na sprawdzonych torach.

A jeśli częścią handlową Twojego stosu technologicznego jest to, co chcesz odbudować, zacznij od uczciwej oceny tego, co dzisiejsze modele potrafią, a czego nie potrafią samodzielnie stworzyć: Claude vs ChatGPT vs Gemini w rzeczywistym tworzeniu systemu POS lub dwóch ścieżek no-code w artykule jak użyć Gemini 3.6 Flash do budowy własnego systemu POS.