Oprogramowanie na zamówienie czy gotowe rozwiązanie (SaaS)?

Według Mesterséges Intelligencia Központ Kft., firmy programistycznej z Budapesztu, gotowe oprogramowanie (SaaS) wystarcza, jeśli obejmuje procesy firmy; oprogramowanie na zamówienie opłaca się wtedy, gdy firma działa inaczej niż zwykle albo gdy samo oprogramowanie stanowi przewagę biznesową.

W skrócie: jeśli gotowy produkt bez prac programistycznych obejmuje większość procesów, a firma może się do niego dostosować, gotowe rozwiązanie jest szybszą drogą. Jeśli firma działa inaczej, niż zakładają gotowe produkty, trzeba połączyć wiele systemów albo kontrola nad danymi i dalszym rozwojem jest kwestią strategiczną, opłaca się rozwiązanie na zamówienie. Często dobrą odpowiedzią jest połączenie obu: gotowa podstawa z uzupełnieniami na zamówienie.

Co oznaczają oprogramowanie na zamówienie, gotowe oprogramowanie i SaaS?

Te trzy pojęcia odpowiadają na dwa różne pytania: pierwsze dotyczy tego, dla kogo powstało oprogramowanie, a drugie tego, w jaki sposób trafia ono do użytkownika.

Oprogramowanie na zamówienie: program stworzony na zlecenie, zgodnie z potrzebami konkretnej firmy. Potrafi to, o co zamawiający poprosił w specyfikacji, i działa tak, jak pracuje się w tej firmie, a o kierunku dalszego rozwoju również decyduje zamawiający.
Gotowe (pudełkowe) oprogramowanie: produkt tworzony dla wielu klientów, który firma licencjonuje i zazwyczaj instaluje oraz eksploatuje na własnych komputerach lub serwerze. Można je kształtować za pomocą ustawień, ale logikę działania określa producent.
SaaS (Software as a Service, oprogramowanie jako usługa): gotowe oprogramowanie, które producent uruchamia we własnej chmurze, a firma korzysta z niego w ramach abonamentu, przez przeglądarkę lub przez interfejs programistyczny. Interfejs programistyczny (API, application programming interface) to punkt połączenia, przez który dwa programy wymieniają dane bez udziału człowieka.

Zgodnie z definicją chmury obliczeniowej amerykańskiego Narodowego Instytutu Standaryzacji i Technologii (NIST) w modelu SaaS użytkownik korzysta z działającej w chmurze aplikacji dostawcy i nie zarządza leżącą u jej podstaw infrastrukturą (siecią, serwerami, systemem operacyjnym, pamięcią masową) ani nawet poszczególnymi funkcjami aplikacji, z wyjątkiem ograniczonych ustawień na poziomie użytkownika (NIST SP 800-145). Na tym polega jednocześnie siła i ograniczenie SaaS: producent zdejmuje z firmy ciężar eksploatacji, ale to on decyduje też o tym, co i kiedy zmienia się w produkcie.

Trzecia droga: gotowa podstawa z uzupełnieniami na zamówienie

Decyzja rzadko jest wyborem typu „albo–albo”. W wielu firmach realną drogą jest pozostawienie gotowego produktu do typowych zadań, takich jak księgowość, poczta e-mail czy praca biurowa, i tworzenie rozwiązań na zamówienie tam, gdzie firma naprawdę działa inaczej niż pozostałe. Najczęstsze formy rozwiązania hybrydowego:

Integracja: program stworzony na zamówienie łączy gotowe systemy przez API lub webhooki, dzięki czemu danych nie trzeba ręcznie przepisywać. Webhook to automatyczne powiadomienie, które jeden system wysyła drugiemu, gdy zajdzie określone zdarzenie, na przykład gdy wpłynie nowe zamówienie.
Moduł na zamówienie: obok gotowego systemu powstaje własna aplikacja dla procesu, którego gotowy produkt nie obejmuje, na przykład dla szczególnej reguły ustalania cen, harmonogramowania produkcji albo ewidencji branżowej.
Własny interfejs nad gotowym systemem: klienci lub pracownicy terenowi otrzymują prosty interfejs dopasowany do ich zadania, a w tle pracuje gotowy system.

Zaletą drogi hybrydowej jest to, że firma płaci za prace programistyczne tylko tam, gdzie coś jest naprawdę nietypowe. Wadą jest to, że części na zamówienie muszą nadążać za zmianami interfejsu gotowego systemu, dlatego integracja wymaga rejestrowania zdarzeń i sygnalizowania błędów, a ktoś musi zadbać o jej utrzymanie. O łączeniu systemów i automatyzacji powtarzalnej pracy piszemy na stronie Automatyzacja procesów.

Kryteria decyzji w jednej tabeli

Kryterium	Przemawia za gotowym oprogramowaniem (SaaS), jeśli…	Przemawia za rozwiązaniem na zamówienie, jeśli…
Dopasowanie do procesów	proces jest typowy, a firma akceptuje dostosowanie się do oprogramowania	firma działa inaczej niż zwykle i chce tę odmienność zachować
Przewaga konkurencyjna	dany obszar nie odróżnia firmy od konkurencji	samo oprogramowanie jest przewagą biznesową albo jej nośnikiem
Liczba integracji	trzeba połączyć się z niewieloma systemami i istnieją do nich gotowe konektory	trzeba połączyć wiele systemów albo nie ma do nich gotowych konektorów
Dane i rezygnacja	producent udostępnia pełny eksport w formacie czytelnym maszynowo, a warunki rezygnacji są jasne	model danych i kontrola nad systemem to kwestia strategiczna
Użytkownicy i model licencjonowania	niewielu użytkowników i przewidywalna liczba pracowników	wielu lub szybko przybywających użytkowników, gdy decydująca jest opłata za użytkownika
Szybkość startu	system musi szybko zacząć działać, a gotowe funkcje wystarczają	start może poczekać na prace programistyczne albo może następować etapami
Kto zajmuje się utrzymaniem?	firma nie ma własnych zasobów IT, a utrzymanie po stronie producenta wystarcza	jest ktoś, kto będzie eksploatował system: własny zespół lub wykonawca na podstawie umowy
Miejsce przechowywania danych i zgodność	miejsce przechowywania danych i umowa producenta spełniają oczekiwania	dane muszą pozostać w określonym miejscu albo obowiązują je rygorystyczne przepisy branżowe

Nie wszystkie wiersze muszą wskazywać tę samą stronę. Jeśli większość kryteriów przemawia za gotowym produktem, warto od niego zacząć. Jeśli jednak najważniejsze wiersze (dopasowanie, przewaga konkurencyjna i integracje) wskazują na rozwiązanie na zamówienie, warto zaplanować wszystko dokładniej i przynajmniej dla jednej grupy funkcji przygotować konkretne porównanie.

Od czego zależy całkowity koszt posiadania?

Całkowity koszt posiadania (ang. total cost of ownership, w skrócie TCO) to nakłady w całym okresie użytkowania oprogramowania, a nie tylko cena na starcie. Struktura kosztów obu dróg jest różna, dlatego porównanie jednego roku może wprowadzać w błąd: warto patrzeć na planowany okres użytkowania.

W przypadku gotowego oprogramowania i SaaS koszt kształtują zazwyczaj:

abonament, który często rośnie wraz z liczbą użytkowników i wybranym pakietem;
moduły dodatkowe i wyższe pakiety, jeśli potrzebna funkcja jest dostępna tylko w nich;
wdrożenie, konfiguracja i przeszkolenie pracowników;
integracje i dostosowanie, które często wykonuje osobny partner;
rezygnacja: eksport danych i ich przeniesienie, jeśli kiedyś trzeba będzie zmienić system.

W przypadku oprogramowania na zamówienie:

prace programistyczne, których koszt zależy przede wszystkim od rozmiaru funkcjonalnego oprogramowania;
eksploatacja: hosting, monitorowanie i aktualizacje bezpieczeństwa;
utrzymanie i dalszy rozwój w miarę zmian potrzeb firmy;
zachowanie wiedzy: dokumentacja i pełny kod źródłowy, aby system nie zależał od jednej osoby.

Koszt rozwiązania na zamówienie można zaplanować, jeśli zakres się mierzy, a nie szacuje na wyczucie. Rozmiar funkcjonalny tworzonego oprogramowania mierzymy w punktach funkcyjnych COSMIC (ISO/IEC 19761), a na tej podstawie powstają oferta i harmonogram; metodę opisuje strona Wycena. To, która droga będzie w dłuższej perspektywie tańsza, zależy od liczby użytkowników, częstotliwości zmian i liczby integracji. Nie ma na to ogólnej odpowiedzi, jest tylko wyliczenie dla konkretnego przypadku.

Uzależnienie od producenta i przenoszenie danych

O uzależnieniu od producenta (ang. vendor lock-in) mówimy wtedy, gdy przejście na inny produkt jest tak trudne lub kosztowne, że firma praktycznie nie może zrezygnować z dotychczasowego. Przyczyną może być zamknięty format danych, niepełny eksport, wiele ustawień związanych wyłącznie z danym produktem albo umowa, którą trudno wypowiedzieć.

Unijny akt w sprawie danych (Data Act, rozporządzenie (UE) 2023/2854) jest stosowany od 12 września 2025 r. i w osobnym rozdziale reguluje zmianę dostawcy usług przetwarzania danych; jego motywy zaliczają do tych usług również SaaS. Tekst rozporządzenia przewiduje między innymi (sprawdzono 17 października 2026 r.):

Warunki zmiany dostawcy muszą zostać określone w pisemnej umowie, a okres wypowiedzenia potrzebny do rozpoczęcia zmiany dostawcy może wynosić najwyżej dwa miesiące (art. 25).
Na wniosek zmianę dostawcy należy umożliwić bez zbędnej zwłoki, w okresie przejściowym wynoszącym najwyżej 30 dni kalendarzowych, w trakcie którego usługa musi nadal działać; jeśli jest to technicznie niewykonalne, dostawca może, podając uzasadnienie, wskazać okres przejściowy wynoszący najwyżej siedem miesięcy (art. 25).
Umowa musi wyczerpująco wymieniać dane, które można przenieść, i zapewniać okres co najmniej 30 dni kalendarzowych na odzyskanie danych (art. 25).
Od 12 stycznia 2027 r. dostawca nie może pobierać opłat za proces zmiany dostawcy; do tego czasu może pobierać jedynie obniżone opłaty, które nie mogą przekraczać jego kosztów bezpośrednio związanych ze zmianą dostawcy (art. 29).

Ważny wyjątek: przepis o opłatach i niektóre obowiązki techniczne nie mają zastosowania do usług, których główne cechy w większości zbudowano na zamówienie, z myślą o potrzebach jednego klienta, i które nie są oferowane na szeroką skalę komercyjną (art. 31). Jeśli gotowy system przetwarza dane osobowe w imieniu firmy, obowiązki nakłada na dostawcę również ogólne rozporządzenie o ochronie danych (RODO): po zakończeniu świadczenia usługi, zależnie od decyzji administratora, usuwa on lub zwraca wszystkie dane osobowe (art. 28 ust. 3 lit. g RODO). To informacja, a nie porada prawna.

Przepisy poprawiają warunki, ale rezygnację firma musi zaplanować sama, najlepiej już przy wyborze. Warto sprawdzić:

w jakim formacie można wyeksportować wszystkie dane, na przykład jako CSV (plik tekstowy z wartościami rozdzielonymi przecinkami), JSON (ustrukturyzowany, czytelny maszynowo format tekstowy) lub kopię zapasową bazy danych, i czy eksport obejmuje załączniki, notatki i rejestr zmian;
czy istnieje udokumentowane API, przez które dane można pobierać także na bieżąco;
czy eksport próbny pozwala sprawdzić, że dane da się wczytać do innego systemu;
co umowa mówi o wypowiedzeniu, opłacie za zmianę dostawcy i usunięciu danych.

Do kogo należy kod źródłowy?

W przypadku gotowego oprogramowania i SaaS firma kupuje prawo do korzystania: kod źródłowy pozostaje u producenta, a o losie produktu (nowych funkcjach, zmianach cen, wycofaniu produktu) decyduje producent. Samo w sobie nie jest to problemem, jeśli produkt jest stabilny, a dane można wyeksportować.

W przypadku rozwiązania na zamówienie kwestię kodu źródłowego i praw do korzystania reguluje umowa, dlatego warto wyraźnie określić, do kogo należy kod, czy zamawiający otrzyma pełny kod źródłowy i dokumentację oraz czy system może dalej rozwijać inny wykonawca. U nas również kwestie kodu źródłowego i praw do korzystania reguluje umowa. O innych ważnych punktach umowy piszemy w artykule Jak wybrać firmę programistyczną?.

Ocena zależy od rodzaju systemu

Powyższe kryteria mają charakter ogólny, ale w poszczególnych rodzajach systemów ich waga jest różna. W systemie zarządzania przedsiębiorstwem kluczową kwestią jest relacja między dostosowaniem a możliwością aktualizacji; piszemy o tym w artykule ERP na zamówienie czy dostosowany gotowy ERP?. W systemie zarządzania relacjami z klientami dużo znaczą specyficzny proces sprzedaży i licencja liczona za użytkownika, zob. artykuł Kiedy opłaca się stworzyć CRM na zamówienie?. W sklepie internetowym szybki start platform abonamentowych stoi naprzeciw swobody rozbudowy. Więcej w artykule Sklep internetowy: platforma abonamentowa czy rozwiązanie na zamówienie?. O tworzeniu systemów biznesowych w ogólności można przeczytać na stronie Oprogramowanie biznesowe.

Lista kontrolna przed decyzją

Odpowiedzi na poniższe pytania zazwyczaj same wyznaczają drogę:

Czy potrafimy opisać proces na tyle szczegółowo, by sprawdzić go punkt po punkcie podczas prezentacji gotowego produktu?
Jaką część procesu gotowy produkt obejmuje za pomocą ustawień, bez prac programistycznych?
Czy ten obszar odróżnia firmę od konkurencji, czy działa podobnie w każdej firmie?
Z iloma systemami trzeba się połączyć i czy istnieją do nich gotowe konektory wspierane przez producenta?
Ilu użytkowników będzie pracować w systemie za kilka lat i jak zmieni się wraz z tym abonament?
Czy otrzymamy pełny, czytelny maszynowo eksport i czy sprawdziliśmy go eksportem próbnym?
Gdzie dane są przechowywane i przetwarzane i czy spełnia to wymagania firmy dotyczące ochrony danych i przepisów branżowych?
Kto będzie eksploatował i dalej rozwijał system i co się stanie, jeśli ten partner wypadnie z gry?
Ile czasu zostało do uruchomienia i czy system może startować etapami?

Typowe błędy

Porównywanie list funkcji zamiast procesu: dwa produkty mogą obiecywać tę samą funkcję, a różnica polega na tym, jak pasuje ona do codziennej pracy firmy. Warto przejść prezentację na własnych, prawdziwych przypadkach.
Porównywanie tylko kosztów pierwszego roku: abonament rośnie wraz z liczbą pracowników, a eksploatacja i dalszy rozwój systemu na zamówienie rozkładają się na lata.
Zapominanie o rezygnacji: eksport danych trzeba sprawdzić przy wyborze, a nie przy wypowiedzeniu umowy.
Zbyt wiele dostosowań w gotowym produkcie: powyżej pewnego progu aktualizacja wielokrotnie dostosowywanego gotowego systemu wymaga więcej pracy niż utrzymanie dobrze wydzielonego modułu na zamówienie.
Wymiana wszystkiego naraz: przejście etapami (najpierw jeden moduł, potem kolejny) wiąże się z mniejszym ryzykiem niż jedna duża, jednorazowa zmiana.

Częste pytania

Kiedy opłaca się tworzyć oprogramowanie na zamówienie?

Wtedy, gdy firma działa inaczej, niż zakładają gotowe produkty, i chce tę odmienność zachować; gdy trzeba połączyć wiele systemów, a nie ma do nich gotowych konektorów; albo gdy samo oprogramowanie jest przewagą biznesową. Jeśli gotowy produkt bez prac programistycznych obejmuje większość procesów, zazwyczaj jest on szybszą drogą. Mówimy to już podczas pierwszej konsultacji.

Czy oprogramowanie na zamówienie jest w dłuższej perspektywie droższe?

Niekoniecznie, ale nie jest też automatycznie tańsze. Abonament gotowego oprogramowania rośnie wraz z liczbą użytkowników i pakietami, a w systemie na zamówienie stałym kosztem są eksploatacja i dalszy rozwój. To, co wyjdzie taniej, zależy od planowanego okresu użytkowania, liczby pracowników, integracji i częstotliwości zmian; warto to wyliczyć dla konkretnego przypadku.

Co stanie się z naszymi danymi, jeśli zrezygnujemy z SaaS?

Zależy to przede wszystkim od umowy, dlatego warto ją sprawdzić już przy wyborze. Zgodnie z unijnym aktem w sprawie danych umowa musi wyczerpująco określać dane, które można przenieść, i zapewniać co najmniej 30 dni kalendarzowych na ich odzyskanie; dane osobowe zaś zgodnie z RODO należy po zakończeniu świadczenia usługi usunąć lub zwrócić, zależnie od decyzji administratora. W praktyce eksport próbny pokazuje, na ile dane nadają się do użycia w innym systemie.

Czy można połączyć oba rozwiązania?

Tak, i w wielu firmach jest to realna droga: gotowy system pozostaje do typowych zadań, integracja na zamówienie łączy go z pozostałymi systemami, a moduł na zamówienie powstaje dla tego, czym firma się wyróżnia. Warunkiem jest to, by gotowy system był dostępny przez udokumentowane API.

Do kogo będzie należał kod źródłowy?

W przypadku gotowego oprogramowania i SaaS kod źródłowy należy do producenta, a firma otrzymuje prawo do korzystania. W przypadku rozwiązania na zamówienie kwestie kodu źródłowego i praw do korzystania reguluje umowa, także u nas.

Jak możemy pomóc?

Mesterséges Intelligencia Központ Kft. tworzy oprogramowanie na zamówienie i łączy gotowe systemy, a tam, gdzie oszczędza to realną pracę, także za pomocą sztucznej inteligencji: modele językowe OpenAI (ChatGPT), Anthropic (Claude) i Google (Gemini) podłączamy do istniejących systemów. Pierwsza konsultacja jest bezpłatna i mówimy wtedy również, jeśli wystarczy gotowy produkt. Jeśli potrzebne jest rozwiązanie na zamówienie, mierzymy jego rozmiar funkcjonalny w punktach funkcyjnych COSMIC, a na tej podstawie powstają oferta i harmonogram. Na życzenie zawieramy umowę o zachowaniu poufności (NDA), a po przekazaniu zapewniamy również eksploatację i utrzymanie. Kwestie kodu źródłowego i praw do korzystania reguluje umowa.

Szczegóły znajdą Państwo na stronie Tworzenie oprogramowania na zamówienie. Jeśli chcieliby Państwo porozmawiać z nami o swojej sytuacji, prosimy do nas napisać, korzystając z danych kontaktowych podanych na stronie Kontakt.