Oprogramowanie dedykowane a rozwiązania masowe - kryteria decyzji i tabela koszt-ryzyko

Oprogramowanie dedykowane a rozwiązania masowe - na czym polega różnica

Rozwiązaniem masowym nazywa się system produkowany dla wielu klientów jednocześnie, na przykład program pudełkowy, aplikację w modelu SaaS albo stronę na gotowym szablonie. Producent tworzy jedną wersję, którą sprzedaje wielu firmom, i dzieli koszt rozwoju między nich. Oprogramowanie dedykowane powstaje dla jednego zamawiającego, według jego procesów, i to on ponosi cały koszt wytworzenia.

Z tej różnicy wynika większość pozostałych. System masowy jest tańszy na starcie i szybszy w uruchomieniu, ale narzuca własny sposób pracy. System dedykowany odwzorowuje proces zamawiającego, ale wymaga analizy i testów oraz późniejszego utrzymania. Ogólny opis pojęcia znajduje się na stronie o oprogramowaniu na zamówienie, a szczegóły umowy - w artykule o dedykowanym oprogramowaniu na zamówienie, gdzie omówiono specyfikację i prawa do kodu.

Porównanie cech obu modeli

Tabela zestawia cechy, które najczęściej rozstrzygają o wyborze.

Żadna kolumna nie wygrywa w każdym wierszu. Rozstrzyga to, która cecha jest dla danej firmy ważniejsza: szybkość uruchomienia czy zgodność z procesem.

Granica konfiguracji systemu masowego

Systemy masowe da się dopasować w ograniczonym zakresie. Producent udostępnia parametry i pola własne. Dochodzą do nich edytor procesów zatwierdzania i szablony wydruków, a także interfejs API. Za ich pomocą firma dostosowuje system do swoich reguł. Do pewnej granicy jest to najtańsza droga, bo koszt dopasowania jest krótki, a wsparcie ma po swojej stronie producent.

Granica pojawia się wtedy, gdy reguła procesu nie mieści się w żadnym parametrze. Przykładem może być rozliczenie, którego wynik zależy od trzech dokumentów jednocześnie, albo kolejność operacji narzucona przez klienta i różna dla każdego z nich. Zamawiający zaczyna wtedy obchodzić system arkuszami i ręcznymi uzgodnieniami, a system przestaje być jedynym źródłem prawdy. Podobny mechanizm opisuje artykuł o ewidencji palet w Excelu i granicy arkusza.

Sygnały przekroczenia granicy

Cztery objawy sugerują, że konfiguracja systemu masowego przestała wystarczać.

• Równoległy arkusz - część danych prowadzi się poza systemem, bo brakuje w nim pola lub reguły.
• Ręczne przepisywanie - te same dane wpisuje się w dwóch miejscach z powodu braku integracji.
• Obejścia procesu - pracownicy stosują nieopisane skróty, aby system w ogóle przyjął dokument.
• Rosnąca lista życzeń - te same zgłoszenia do producenta wracają co kilka miesięcy bez realizacji.

Koszt całkowity i ryzyko - tabela porównawcza

Cena zakupu jest tylko jednym składnikiem kosztu całkowitego. W modelu masowym dochodzą opłaty cykliczne za licencje albo subskrypcję. Trzeba doliczyć koszt integracji i dopasowania oraz koszt obejść, gdy system nie obsługuje reguły. W modelu dedykowanym koszt wytworzenia dominuje na początku, a później przechodzi w koszt utrzymania i rozwoju. Ogólne zasady oceny kosztów w projektach IT opisuje sekcja o optymalizacji kosztów w Microsoft Learn.

Poniższa funkcja T-SQL jest przykładowa i pokazuje sposób liczenia kosztu całkowitego w wybranym horyzoncie. Parametry przyjmują wartości z oferty każdego wariantu, dzięki czemu oba modele liczy się tym samym wzorem.

CREATE FUNCTION dbo.KosztCalkowity
(
    @Wdrozenie     decimal(12,2),
    @OplataRoczna  decimal(12,2),
    @ZmianyRocznie decimal(12,2),
    @Lata          int
)
RETURNS decimal(12,2)
AS
BEGIN
    RETURN @Wdrozenie + (@OplataRoczna + @ZmianyRocznie) * @Lata;
END;

Wzór nie uwzględnia kosztu obejść ani kosztu przestoju, dlatego wynik należy traktować jako dolną granicę. Przy porównaniu warto policzyć oba warianty dla kilku horyzontów, ponieważ model dedykowany zwykle wypada gorzej w krótkim okresie, a lepiej w długim.

Koszt a liczba użytkowników

Opłaty w modelu masowym zwykle rosną razem z liczbą użytkowników albo modułów, a w modelu dedykowanym zależą raczej od infrastruktury i zakresu umowy serwisowej. Firma, której liczba użytkowników szybko rośnie, powinna więc policzyć oba warianty dla przewidywanej skali, a nie dla stanu obecnego. W małych zespołach jest odwrotnie: niewielka liczba stanowisk sprawia, że licencje kosztują mało, a koszt wytworzenia systemu dedykowanego trudno rozłożyć.

Kryteria decyzji o wyborze modelu

Wybór modelu zależy od charakteru procesu, a nie od upodobań zamawiającego. Procesy standardowe, takie jak księgowość czy obsługa poczty, nie dają przewagi konkurencyjnej, więc nie ma powodu płacić za ich napisanie od nowa. Procesy, w których firma różni się od rynku, są dobrym kandydatem do dedykowanego rozwiązania.

Reguła: proces, który odróżnia firmę od konkurencji, opłaca się zamówić na miarę, a proces standardowy opłaca się kupić.

Pytania przed decyzją

Cztery pytania porządkują rozmowę przed wyborem.

• Czy proces jest unikalny - czy gotowe systemy obsługują go bez obejść, sprawdzone na demonstracji z własnymi danymi.
• Jaki jest horyzont użytkowania - im dłużej system ma działać, tym mniejsze znaczenie ma wyższy koszt początkowy.
• Ile integracji jest potrzebnych - każda dodatkowa integracja podnosi koszt w obu modelach, ale w różny sposób.
• Kto utrzyma rozwiązanie - czy zamawiający ma zespół IT albo umowę serwisową z wykonawcą.

Prototyp ograniczający ryzyko

Gdy proces jest niepewny albo dopiero się kształtuje, dobrym kompromisem bywa mały prototyp dedykowany. Obejmuje jeden proces, działa na prawdziwych danych i jest oceniany przez użytkowników po kilku tygodniach pracy. Wynik daje odpowiedź, czy proces wymaga własnego rozwiązania, czy wystarczy konfiguracja systemu masowego, a koszt pomyłki ogranicza się do prototypu.

Kiedy rozwiązanie masowe jest lepszym wyborem

Argumenty za oprogramowaniem dedykowanym łatwo przecenić, dlatego trzeba jasno wskazać sytuacje, w których gotowy system wygrywa. Pierwsza to proces, który u większości firm wygląda tak samo, na przykład fakturowanie albo ewidencja czasu pracy. Producent takiego systemu zebrał doświadczenia z wielu wdrożeń i zawarł je w gotowych funkcjach, których nie trzeba wymyślać od nowa.

Drugą sytuacją jest brak zespołu, który utrzyma własną aplikację. Rozwiązanie masowe przenosi na producenta aktualizacje i poprawki bezpieczeństwa oraz część wsparcia. Trzecią jest krótki horyzont użytkowania: gdy firma potrzebuje narzędzia na rok lub dwa, koszt wytworzenia systemu dedykowanego może się nie zwrócić.

Rozwiązanie masowe ma także własny ekosystem: dokumentację i szkolenia oraz społeczność użytkowników i partnerów wdrożeniowych. Nowa osoba w zespole uczy się popularnego systemu z gotowych materiałów, a przy dedykowanym korzysta wyłącznie z dokumentacji przekazanej przez wykonawcę.

Model hybrydowy - gotowe jądro i rozszerzenia

Wybór nie musi być rozłączny. Coraz częściej firma kupuje system masowy do procesów standardowych, a brakujące funkcje dopisuje jako osobne aplikacje, które komunikują się z jądrem przez interfejs API. Zaletą jest zachowanie ścieżki aktualizacji po stronie producenta, a wadą konieczność utrzymania interfejsu, który może się zmienić przy nowej wersji systemu.

Warstwa integracyjna jest wtedy osobnym produktem, który trzeba zaprojektować i utrzymywać. Mechanizmy wymiany przez REST i kolejki oraz mapowanie danych opisuje artykuł o integracji WMS z ERP. Zasady projektowania interfejsów HTTP zbiera dokumentacja Microsoft Learn o projektowaniu API.

Interfejs, z którego korzystają rozszerzenia, powinien mieć numer wersji, a zmiany niekompatybilne wprowadza się jako nową wersję. Zamawiający dostaje wtedy czas na dostosowanie rozszerzeń, zanim stara wersja interfejsu zostanie wyłączona.

Przykład z logistyki

Firma logistyczna może używać gotowego systemu księgowego i systemu ERP do procesów finansowych, a proces magazynowy prowadzić w dedykowanym rozwiązaniu, które odwzorowuje jej układ lokalizacji i sposób kompletacji. Mapę takich systemów pokazuje artykuł o oprogramowaniu logistycznym. Granica między systemami przebiega w miejscu, w którym kończy się standardowy proces, a zaczyna proces własny firmy.

Koszt wyjścia i migracja danych

Każdy wybór ma koszt zmiany, który ujawnia się dopiero po latach. W modelu masowym wyjście oznacza eksport danych w formacie oferowanym przez producenta, który nie zawsze zachowuje wszystkie powiązania między dokumentami. W modelu dedykowanym wyjście zależy od praw do kodu i jakości dokumentacji przekazanej przez wykonawcę.

Migracja danych między systemami składa się z czterech czynności, które warto zaplanować jeszcze przed wyborem modelu.

• Mapowanie pól - zestawienie pól systemu źródłowego z polami docelowymi wraz z regułami przekształceń.
• Czyszczenie danych - usunięcie duplikatów i uzupełnienie braków przed wczytaniem do nowego systemu.
• Praca równoległa - okres, w którym oba systemy działają, a ich wyniki są porównywane.
• Plan powrotu - warunek wycofania uruchomienia i sposób przywrócenia poprzedniego stanu.

Im głębiej system jest osadzony w procesach, tym droższe jest wyjście. Z tego powodu przy wyborze modelu warto zapytać, jak wyglądałaby migracja za kilka lat, i uwzględnić odpowiedź w kryteriach decyzji.

Agencja interaktywna czy software house

Rozróżnienie masowego i dedykowanego dotyczy także stron oraz aplikacji internetowych. Agencja interaktywna buduje zwykle serwisy na gotowych systemach zarządzania treścią i szablonach, co dobrze sprawdza się przy stronach informacyjnych i sklepach o standardowym przebiegu. Software house pisze aplikacje od podstaw, według specyfikacji, z modelem danych i regułami biznesowymi zamawiającego.

Ta różnica przekłada się na koszt, ponieważ programowanie od zera wymaga analizy i testów oraz utrzymania, a modyfikacja szablonu wymaga głównie pracy graficznej i konfiguracyjnej. Wybór zależy od tego, czy zamawiający potrzebuje wizytówki i prostego sklepu, czy narzędzia, które realizuje proces firmy. Różne rodzaje aplikacji opisuje strona o aplikacjach na zamówienie.

Szablon a aplikacja od podstaw

Szablon zawiera gotowe układy i komponenty, a zamawiający dostarcza treść. Aplikacja od podstaw zawiera logikę, której nie da się przenieść z innego projektu, bo wynika z procesu konkretnej firmy. Zamawiający powinien zapytać wykonawcę, w którym z tych dwóch modeli powstaje wycena, bo od tego zależy zarówno cena, jak i ryzyko przy późniejszych zmianach.

Ryzyka dedykowanego oprogramowania i sposoby ich ograniczania

Dedykowane oprogramowanie ma własne ryzyka, które da się opisać i ograniczyć. Zależność od jednej osoby w zespole wykonawcy zmniejsza obowiązkowa dokumentacja i przegląd kodu. Rozrost zakresu ogranicza specyfikacja z kryteriami akceptacji, a utratę kontaktu z wykonawcą - prawa do kodu i jego przekazanie.

Wybór wykonawcy jest osobnym zagadnieniem, opisanym w artykule o kryteriach oceny dostawcy oprogramowania na zamówienie. Utrzymanie po wdrożeniu, czyli kopie zapasowe i aktualizacje oraz obsługę zgłoszeń, omawia tekst o oprogramowaniu na zamówienie a obsłudze IT. Korzyści z programowania dedykowanego dla firm zbiera strona o usługach programowania dla firm.

Wykonawca oprogramowania na zamówienie powinien przedstawić zarówno możliwości, jak i ograniczenia takiego podejścia. SoftwareStudio wycenia projekty indywidualnie, a szczegóły zakresu opisuje oferta usług. Kontakt w sprawie rozmowy o wyborze modelu jest dostępny pod numerem +48 533 322 626.