Koszt systemu dedykowanego: od czego zależy wycena

Koszt systemu dedykowanego zależy od czterech rzeczy: zakresu funkcji, liczby i jakości integracji, poziomu niepewności w projekcie oraz utrzymania po wdrożeniu. Dlatego rzetelna wycena prawie nigdy nie jest jedną kwotą, tylko przedziałem z wypisanymi założeniami. Poniżej pokazuję, z czego składa się cena, jak czytać ofertę software house’u i jak porównać dwie wyceny, które na pierwszy rzut oka różnią się wszystkim.

Patrzę na to z perspektywy wykonawcy, który takie wyceny przygotowuje. Najczęstszy problem nie leży w stawce godzinowej. Leży w tym, że zamawiający i wykonawca mają w głowie dwa różne systemy, a rozmawiają o jednej kwocie.

Od czego zależy koszt systemu dedykowanego

Na cenę wpływa przede wszystkim liczba procesów, które system ma obsłużyć, oraz liczba osób i innych systemów, które w nich uczestniczą. Stawka godzinowa ma znaczenie, ale mniejsze, niż się wydaje. Różnica w liczbie godzin między dobrze i źle opisanym zakresem bywa większa niż różnica stawek między firmami.

Gdy rozkładam wycenę na części, zwykle wychodzi taka lista:

• Zakres funkcjonalny: procesy, role użytkowników, ekrany, raporty, uprawnienia.
• Integracje: ERP, księgowość, kurierzy, płatności, hurtownie, systemy klientów.
• Dane: migracja z dotychczasowych arkuszy i programów, czyszczenie, mapowanie pól.
• Wymagania niefunkcjonalne: wydajność, bezpieczeństwo, dostępność, kopie zapasowe, logi.
• Organizacja projektu: analiza, projekt interfejsu, testy, wdrożenie, szkolenia.
• Utrzymanie: serwer, aktualizacje, monitoring, poprawki i drobny rozwój.

Każdy z tych punktów da się wycenić osobno. Jeżeli oferta ich nie rozdziela, trudno potem ustalić, za co właściwie płacisz i co da się przesunąć na później.

Zakres funkcji: dlaczego prosty panel rzadko jest prosty

Zakres to największa pozycja w budżecie i zarazem ta, którą najłatwiej niedoszacować. Jedno zdanie w zapytaniu ofertowym, na przykład „system do obsługi zamówień”, może oznaczać kilka ekranów albo kilkadziesiąt, zależnie od tego, ile wyjątków ma proces.

Weźmy przykład firmy dystrybucyjnej, która chce panelu dla handlowców. Przyjęcie zamówienia to jeden ekran. Potem dochodzą rabaty zależne od klienta, limity kupieckie, zamówienia częściowe, rezerwacje towaru, korekty i zwroty. Każdy taki wyjątek to logika, testy i obsługa błędów. Dlatego przed wyceną pytam klientów nie o to, jak proces działa zwykle, tylko co się dzieje, gdy coś idzie nie tak.

Drugi czynnik to role i uprawnienia. System dla jednego działu kosztuje mniej niż system, w którym handlowiec widzi swoich klientów, kierownik regionu cały region, a zarząd wszystko, razem z historią zmian. Uprawnienia dotykają każdego ekranu i każdego raportu, więc ich złożoność rozlewa się po całym projekcie.

Integracje i migracja danych, czyli koszty niewidoczne na makietach

Integracje często kosztują więcej niż sam interfejs, bo zależą od systemów, na które wykonawca nie ma wpływu. W wielu projektach to one, a nie ekrany, przesądzają o tym, jaki będzie koszt systemu dedykowanego. Połączenie z dobrze opisanym API to inna praca niż wymiana plików ze starym ERP, w którym nikt już nie pamięta znaczenia połowy pól.

Przy wycenie integracji sprawdzam trzy rzeczy: czy system po drugiej stronie ma API i dokumentację, kto po stronie klienta zna jego dane oraz co ma się dziać, gdy połączenie przestanie działać. Ostatnie pytanie bywa pomijane, a od niego zależy, czy integracja potrzebuje kolejek, ponawiania i powiadomień o błędach. Szerzej opisuję to w tekście o projektowaniu skalowalnej architektury systemów.

Migracja danych to osobna pozycja. Przeniesienie kartoteki klientów z arkuszy wymaga ujednolicenia formatów, usunięcia duplikatów i decyzji, co zrobić z rekordami niepełnymi. Tę pracę zwykle trzeba wykonać razem z ludźmi z firmy, więc dobra wycena opisuje też ich rolę i czas, który muszą na nią poświęcić.

Ryzyko i niepewność: skąd biorą się widełki w wycenie

Widełki w wycenie nie są wykrętem, tylko informacją o tym, ile w projekcie jest niewiadomych. Im mniej szczegółowy opis, tym szerszy przedział i tym większy zapas, który wykonawca musi doliczyć, jeśli ma podpisać stałą cenę.

Źródła ryzyka są dość powtarzalne:

• proces nie jest spisany i każda osoba w firmie opisuje go inaczej,
• integracja z systemem bez dokumentacji i bez środowiska testowego,
• brak jednej osoby po stronie klienta, która podejmuje decyzje,
• wymagania prawne, które mogą się zmienić w trakcie projektu,
• termin narzucony z góry, niezależnie od zakresu.

Dobrym sposobem na zawężenie widełek jest płatny etap analizy przed wyceną całości. Kosztuje niewielką część projektu, a daje opis zakresu, makiety kluczowych ekranów i listę integracji. Na takim dokumencie da się porównywać oferty, a sam dokument zostaje u Ciebie, nawet jeśli ostatecznie wybierzesz innego wykonawcę.

Utrzymanie po wdrożeniu: koszt, o którym rozmawia się za późno

Wdrożenie nie kończy wydatków. System dedykowany potrzebuje serwera, aktualizacji bibliotek i frameworka, monitoringu, kopii zapasowych i kogoś, kto zareaguje, gdy coś przestanie działać. To koszt stały, który trzeba zaplanować w budżecie od pierwszego dnia, a nie po odbiorze. Pełny koszt systemu dedykowanego to suma budowy i kilku lat utrzymania.

W ofercie szukam odpowiedzi na kilka pytań. Ile kosztuje miesięczne utrzymanie i co w nim jest? Jak szybko wykonawca reaguje na awarię? Jak rozliczane są zmiany i rozwój po wdrożeniu? Kto ma dostęp do kodu i serwera? Jeżeli oferta milczy na ten temat, zapytaj wprost, zanim podpiszesz umowę na budowę.

Na utrzymanie wpływają też decyzje techniczne. Popularny, dobrze wspierany stos technologiczny łatwiej przekazać innemu zespołowi, a specjalistów od niego łatwiej znaleźć. Egzotyczne rozwiązania bywają tańsze na starcie i droższe przez kolejne lata.

Jak czytać wycenę software house’u

Dobra wycena mówi nie tylko, ile kosztuje system, ale też za co płacisz i przy jakich założeniach. Poniższa tabela pokazuje elementy, które powinny się w niej znaleźć, oraz sygnały, przy których warto dopytać.

Element	Co powinno być w ofercie	Sygnał ostrzegawczy
Zakres	lista funkcji lub procesów z podziałem na moduły	jedno zdanie opisu i jedna kwota
Założenia	co jest poza zakresem, jakie dane dostarcza klient	brak sekcji „poza zakresem”
Integracje	lista systemów i sposób połączenia	„integracje według potrzeb”
Testy i wdrożenie	środowisko testowe, procedura odbioru	brak wzmianki o testach
Utrzymanie	koszt miesięczny i zakres usług	„do ustalenia po wdrożeniu”
Prawa do kodu	kiedy i na jakich zasadach przechodzą na klienta	brak zapisu w ofercie

Zwróć uwagę na sekcję „poza zakresem”. To jedna z najcenniejszych części oferty, bo pokazuje, czego wykonawca nie zamierza robić, a co później może się pojawić jako dodatkowa płatna praca.

Osobny temat to sposób rozliczenia. Stała cena przenosi ryzyko na wykonawcę, więc zawiera zapas na niewiadome. Rozliczenie za czas pracy jest elastyczne, ale wymaga od Ciebie bieżącej kontroli budżetu i priorytetów. Żaden model nie jest z założenia tańszy, różnią się tym, kto płaci za niepewność.

Jak porównywać oferty, żeby nie porównywać różnych projektów

Porównuj oferty dopiero wtedy, gdy wszystkie dotyczą tego samego zakresu. Jeśli trzy firmy dostały jedną stronę opisu, każda wyceniła własną interpretację, a różnice w cenach mówią więcej o interpretacjach niż o firmach.

1. Przygotuj wspólny opis zakresu: procesy, role, integracje, dane do migracji.
2. Poproś o wycenę w podziale na moduły i etapy, a nie jedną kwotą.
3. Zestaw oferty w tabeli i sprawdź, czego brakuje w każdej z nich.
4. Zapytaj o założenia przy pozycjach, które różnią się najbardziej.
5. Porównaj koszt budowy razem z kosztem utrzymania przez pierwsze lata.

Przy wyborze pomaga też spojrzenie szersze niż cena: kto będzie po drugiej stronie, jak wygląda komunikacja, kto odpowiada za decyzje techniczne. Pisałem o tym w tekście o tym, kiedy outsourcing IT ma sens.

Przykład: jak rozpisuję koszt systemu dedykowanego

Dla ilustracji weźmy przykład wymyślony, ale typowy: hurtownia z jednym magazynem chce panelu B2B dla stałych klientów, połączonego z ERP. Klienci mają widzieć swoje ceny, składać zamówienia i pobierać faktury.

Rozpisałbym to na moduły: konta klientów i logowanie, katalog z cenami indywidualnymi, koszyk i zamówienia, dokumenty, integracja z ERP, panel administracyjny. Do tego analiza, projekt interfejsu, testy, wdrożenie i utrzymanie. Każdy moduł dostaje liczbę godzin z widełkami, a integracja z ERP najszersze widełki, dopóki nie zobaczę dokumentacji. Jeśli panel ma też działać jak sklep, dochodzą elementy opisane w tekście o budowie nowoczesnych platform e-commerce.

Tak rozpisana wycena pozwala ciąć zakres świadomie. Jeśli budżet się nie spina, można przesunąć na przykład pobieranie faktur do drugiego etapu, zamiast prosić wykonawcę o rabat, który i tak wróci w postaci uproszczeń, o których nikt nie powiedział.

Jeśli zbierasz oferty na system i chcesz sprawdzić, czy wyceny dotyczą tego samego zakresu, zacznij od spisania procesów, ról i integracji na jednej, dwóch stronach. Z takim opisem możesz porównać oferty, które już masz, albo omówić ze mną zasady współpracy. Wtedy koszt systemu dedykowanego przestaje być zagadką i staje się decyzją, którą da się uzasadnić przed zarządem.