Planując wdrożenie lub rozwój platformy e-commerce, wiele firm wysyła zapytanie ofertowe do kilku software house'ów. Po kilku dniach otrzymuje odpowiedzi, często… diametralnie różne.
Jedna oferta opiewa na 300 tysięcy złotych, druga na 650 tysięcy, a trzecia przekracza milion.
Skąd biorą się tak duże różnice, skoro wszystkie firmy wyceniają ten sam projekt?
W praktyce bardzo często… nie wyceniają tego samego.
Choć wszystkie oferty dotyczą tej samej platformy e-commerce, mogą obejmować zupełnie inny zakres odpowiedzialności, poziom analizy, sposób projektowania architektury czy podejście do ryzyka. Różnice nie wynikają wyłącznie z liczby godzin pracy programistów. Znacznie częściej są konsekwencją decyzji podjętych jeszcze przed rozpoczęciem developmentu.
Dlatego porównywanie wyłącznie końcowej kwoty może prowadzić do błędnych decyzji biznesowych.
W tym artykule pokazujemy, jak czytać oferty software house'ów, które elementy mają największy wpływ na wycenę oraz jakie pytania warto zadać przed wyborem partnera technologicznego.
To jedno z najczęściej zadawanych pytań podczas wyboru partnera technologicznego. Na pierwszy rzut oka projekt wygląda identycznie. Ta sama platforma e-commerce, ten sam opis wymagań, ten sam termin realizacji. Mimo to otrzymane wyceny potrafią różnić się o kilkaset tysięcy złotych.
Najczęściej nie wynika to tylko z tego, że jedna firma „liczy drożej”, a druga „taniej”. Różnica polega na tym, co każda z nich uznaje za część projektu. W teorii obie dotyczą tego samego wdrożenia, ale w praktyce opisują dwa zupełnie różne zakresy odpowiedzialności.
Dwie oferty mogą dotyczyć tego samego projektu, a jednocześnie obejmować zupełnie inny zakres prac. Zanim porównasz ceny, sprawdź więc, co faktycznie zawiera każda wycena.
Poniżej opisujemy obszary, które najczęściej odpowiadają za różnice między ofertami.
Nie każdy software house rozpoczyna projekt od analizy (choć w naszej ocenie to naprawdę duży błąd). Część firm zakłada, że dokumentacja przekazana przez klienta jest kompletna i na jej podstawie przygotowuje wycenę. Inne rozpoczynają współpracę od warsztatów Discovery (to my!), podczas których weryfikują procesy biznesowe, architekturę, integracje oraz zakres pierwszego etapu wdrożenia. Oba podejścia mogą prowadzić do realizacji projektu, ale różnią się poziomem ryzyka.
Jeżeli analiza nie została wykonana na początku, część decyzji będzie musiała zostać podjęta już w trakcie developmentu. To często oznacza dodatkowe zmiany zakresu, wydłużenie harmonogramu i wzrost kosztów.
Pytanie do software house'u: Czy wycena została przygotowana na podstawie pełnej analizy projektu, czy jedynie wstępnych założeń?
Przeczytaj też: jak wygląda dobry warsztat discovery przed wdrożeniem e-commerce B2B.
W Commerce Weavers nie zaczynamy od rekomendacji technologii ani gotowej wyceny. Najpierw chcemy zrozumieć indywidualną sytuację klienta: jego model biznesowy, procesy, cele, ograniczenia oraz obecne środowisko technologiczne. Dlatego przed podjęciem kluczowych decyzji rozmawiamy z zespołem, analizujemy dostępne materiały i, w zależności od projektu, przeprowadzamy Discovery lub audyt. Bez tego moglibyśmy opierać rekomendacje na założeniach, które w rzeczywistości okażą się nieprawdziwe. A wtedy nawet poprawna technicznie decyzja może być niewłaściwa z perspektywy konkretnego biznesu. Dobra rekomendacja powinna wynikać z diagnozy, a nie ją poprzedzać.
Oferta powinna jasno określać, czy obejmuje zaprojektowanie architektury systemu i jaki jest zakres tego etapu.
Nie chodzi wyłącznie o wybór technologii. Architektura obejmuje również podział odpowiedzialności pomiędzy platformą e-commerce a systemami zewnętrznymi, sposób realizacji integracji, przepływ danych, kluczowe zależności pomiędzy komponentami oraz przygotowanie rozwiązania do dalszego rozwoju.
Warto sprawdzić, czy w ramach projektu zostaną określone między innymi:
odpowiedzialność poszczególnych systemów,
sposób wymiany danych i integracji,
kluczowe decyzje dotyczące skalowalności i bezpieczeństwa,
podejście do rozwoju kolejnych funkcjonalności,
zasady dokumentowania najważniejszych decyzji architektonicznych,
osoba lub rola odpowiedzialna za podejmowanie i utrzymanie decyzji architektonicznych.
Jeżeli ten etap zostanie pominięty lub ograniczony do bieżących ustaleń podczas implementacji, wiele decyzji będzie podejmowanych reaktywnie. To zwiększa ryzyko zmian zakresu, powstawania niepotrzebnych zależności oraz wzrostu kosztu kolejnych modyfikacji.
Istotne jest więc nie tylko to, czy „architektura” znajduje się w ofercie, ale również czy została potraktowana jako osobny obszar odpowiedzialności. Kluczowe założenia architektoniczne powinny zostać określone na wysokim poziomie możliwie wcześnie, ale nie jako coś ustalonego raz na zawsze. Dobra architektura pozostaje otwarta na zmiany wynikające zarówno z analizy przedwdrożeniowej, jak i z samego przebiegu wdrożenia.
Integracje należą do najbardziej złożonych elementów projektów e-commerce, a ich zakres może znacząco różnić się pomiędzy poszczególnymi ofertami.
Sformułowanie „integracja z ERP” to tylko jeden z możliwych scenariuszy. Platforma e-commerce może wymieniać dane również z PIM, CRM, WMS, OMS, systemami płatności, operatorami logistycznymi, marketplace'ami, narzędziami marketing automation, systemami lojalnościowymi, BI, platformami podatkowymi czy rozwiązaniami wykorzystywanymi przez partnerów biznesowych.
Każda z takich integracji może oznaczać zupełnie inny poziom złożoności. Jedna wycena może obejmować jedynie podstawową wymianę danych, druga również analizę procesów, mapowanie, mechanizmy kolejkowania, obsługę błędów, monitoring, ponawianie operacji i testy integracyjne.
Warto sprawdzić, które systemy zostały uwzględnione w wycenie, jaki zakres obejmuje każda integracja i kto odpowiada za przygotowanie oraz utrzymanie interfejsów. Trudno jednak oczekiwać, że oferta odpowie już na wszystkie szczegółowe pytania, na przykład dotyczące obsługi błędów, monitoringu czy scenariuszy awaryjnych. Ważniejsze jest to, czy oferta pokazuje wysokopoziomowe zrozumienie tych problemów i zadaje odpowiednie pytania. Konkretne rozwiązania, szczególnie szczegóły implementacyjne, najczęściej wychodzą dopiero na etapie warsztatu, audytu lub analizy.
Pytanie do software house'u: Czy wszystkie integracje zostały szczegółowo oszacowane wraz z zakresem danych, odpowiedzialnością stron, obsługą błędów i zależnościami od zewnętrznych dostawców, czy część z nich jest jedynie założeniem przyjętym do wyceny?
Nie każda wycena projektu e-commerce obejmuje taki sam zakres testów. Warto sprawdzić, czy oferta uwzględnia między innymi:
testy automatyczne,
testy manualne,
testy integracyjne,
testy wydajnościowe,
testy bezpieczeństwa,
wsparcie podczas odbiorów biznesowych.
Brak części z tych elementów nie musi oznaczać błędu. Zakres testów powinien wynikać z architektury, charakteru projektu oraz poziomu ryzyka. Ważne, aby był ustalony świadomie, a nie wynikał z nieprecyzyjnej wyceny lub próby obniżenia wartości oferty. Warto też sprawdzić, jak wygląda audyt jakości i wydajności już gotowej platformy. To dobry punkt odniesienia dla tego, czego oczekiwać na etapie wyceny.
Testy nie są dodatkiem do developmentu ani kosztem, który warto ograniczyć, kiedy szukamy oszczędności w projekcie. To inwestycja w jakość i stabilność platformy, która zwraca się w kolejnych etapach jej rozwoju. Dobrze zaprojektowane testy pozwalają wcześniej wychwycić potencjalne problemy, bezpieczniej wprowadzać zmiany i szybciej reagować, gdy coś zaczyna działać inaczej, niż powinno. W wielu przypadkach pozwalają wręcz uniknąć problemu, zanim odczuje go klient lub biznes. Przy platformie e-commerce B2B lub B2C rozwijanej przez lata ta inwestycja potrafi zwrócić się z nawiązką, bo każda kolejna zmiana może być wdrażana z większą pewnością i mniejszym ryzykiem.
Pytanie do software house'u: Jakie testy są częścią projektu i kto odpowiada za ich przygotowanie?
Wdrożenie platformy nie kończy się na napisaniu kodu. Projekt wymaga również przygotowania środowisk, procesu wdrażania, monitoringu oraz zasad utrzymania systemu po uruchomieniu produkcyjnym.
Oferta powinna jasno określać, czy obejmuje między innymi:
środowiska deweloperskie i testowe,
środowisko produkcyjne,
konfigurację CI/CD,
monitoring, logowanie i alerty,
kopie zapasowe oraz procedurę odtwarzania danych,
możliwość bezpiecznego rollbacku wdrożenia,
podstawowe mechanizmy bezpieczeństwa,
odpowiedzialność za utrzymanie infrastruktury po go-live.
Dobrze zaprojektowany proces DevOps wpływa nie tylko na stabilność platformy, ale również na tempo jej dalszego rozwoju. Im bardziej powtarzalny i zautomatyzowany, tym łatwiej wprowadzać kolejne zmiany bez zwiększania ryzyka dla środowiska produkcyjnego.
Warto też sprawdzić, czy monitoring pozwala jedynie wykryć, że platforma przestała działać, czy również szybko zdiagnozować źródło problemu. W bardziej złożonych projektach istotne są nie tylko metryki infrastruktury, ale także logi aplikacyjne, alerty oraz możliwość prześledzenia błędów pomiędzy poszczególnymi komponentami systemu.
To właśnie w tym obszarze często pojawiają się dodatkowe koszty już po podpisaniu umowy, szczególnie jeśli oferta software house'u nie określa jasno, kto odpowiada za hosting, monitoring, backupy, bezpieczeństwo i utrzymanie środowisk po uruchomieniu platformy.
Pytanie do software house'u: Czy przygotowanie infrastruktury, procesu wdrożeniowego, monitoringu i utrzymania środowisk po go-live jest częścią projektu?
Migracja jest jednym z najbardziej niedoszacowanych elementów projektów e-commerce.
Samo przeniesienie produktów lub klientów to zwykle dopiero początek. W praktyce trzeba również określić jakość danych źródłowych, sposób ich mapowania do nowego modelu oraz zakres informacji, które rzeczywiście powinny zostać przeniesione.
Oferta powinna jasno określać między innymi:
jakie dane będą migrowane,
kto odpowiada za ich przygotowanie i oczyszczenie,
czy przewidziano mapowanie danych pomiędzy starym i nowym systemem,
czy migracja obejmuje również historię zamówień, konta klientów, ceny, rabaty lub inne dane biznesowe,
czy migracja będzie wykonywana jednorazowo czy etapami,
czy przewidziano migrację próbną przed uruchomieniem produkcyjnym,
kto odpowiada za walidację i akceptację danych po migracji.
Warto też pamiętać, że problemem często nie jest sama migracja, ale jakość danych źródłowych. Duplikaty, niekompletne rekordy, niespójne formaty czy dane, które przez lata były utrzymywane według różnych zasad, mogą znacząco zwiększyć zakres prac.
Dlatego dobra oferta powinna uwzględniać nie tylko techniczne przeniesienie danych, ale również ich przygotowanie, testowanie i weryfikację po migracji.
Brak tych informacji może oznaczać konieczność realizacji dodatkowych prac już pod koniec projektu, kiedy margines na zmiany w harmonogramie i budżecie jest najmniejszy.
Pytanie do software house'u: Czy migracja danych została opisana i przypisana do konkretnych odpowiedzialności, czy jedynie wspomniana jako element wdrożenia?
Ta sama kwota w dwóch ofertach może oznaczać zupełnie inny poziom zobowiązania po stronie software house'u.
Warto sprawdzić przede wszystkim, w jakim modelu przygotowano wycenę: Fixed Price, Time & Materials czy modelu mieszanym. Sam model nie przesądza o jakości oferty. Kluczowe jest zrozumienie, kto ponosi ryzyko zmiany zakresu i w jaki sposób zmiany będą wpływały na końcowy budżet.
Oferta powinna jasno określać między innymi:
czy podana kwota jest ceną stałą czy estymacją,
jaka stawka lub sposób kalkulacji obowiązuje przy dodatkowych pracach,
jakie założenia przyjęto podczas estymacji,
co zostanie uznane za zmianę zakresu,
jak wygląda proces akceptacji dodatkowych prac,
czy przewidziano rezerwę na ryzyka,
jak często klient otrzymuje informacje o wykorzystaniu budżetu.
W przypadku Time & Materials szczególnie istotna jest transparentność wykorzystania budżetu. Przy Fixed Price równie ważne jest precyzyjne określenie zakresu i założeń, ponieważ zmiana wymagań może prowadzić do change requestów.
Pytanie do software house'u: Czy podana kwota jest zobowiązaniem, estymacją czy budżetem opartym na określonych założeniach i co stanie się z ceną, jeśli te założenia się zmienią? Pisaliśmy szerzej o tym, od czego zależy budżet wdrożenia na przykładzie Syliusa, ale większość tych zasad dotyczy estymacji w dowolnej technologii.
Sama liczba roboczogodzin nie mówi jeszcze, jaki zespół będzie realizował projekt. Warto sprawdzić nie tylko całkowity nakład pracy, ale również skład zespołu, poziom seniority, dostępność kluczowych specjalistów oraz to, które role zostały uwzględnione w cenie.
W zależności od projektu mogą to być między innymi:
senior developerzy,
architekt,
QA,
Project Manager lub Delivery Manager,
DevOps,
analityk biznesowy,
UX/UI.
Dwie oferty o podobnej liczbie godzin mogą więc oznaczać zupełnie inny sposób realizacji projektu. Jedna może obejmować pracę bardziej doświadczonego zespołu i większy udział specjalistów wspierających jakość oraz architekturę, druga może opierać się głównie na developmencie.
Równie istotny jest harmonogram. Krótszy termin realizacji może wymagać większego zespołu, ale zwiększenie liczby osób nie zawsze proporcjonalnie przyspiesza projekt. Im więcej osób pracuje równolegle, tym większego znaczenia nabierają komunikacja, koordynacja, podział odpowiedzialności i zależności pomiędzy zadaniami.
Pytanie do software house'u: Jaki zespół będzie faktycznie realizował projekt, które role są uwzględnione w cenie, kto odpowiada za kluczowe decyzje i jakie założenia przyjęto przy określaniu harmonogramu?
W wielu projektach największe ryzyko nie wynika z technologii, ale z błędnych założeń przyjętych na początku współpracy. Dlatego w bardziej złożonych wdrożeniach rekomendujemy rozpoczęcie od warsztatów. Pozwalają one zweryfikować wymagania biznesowe, architekturę oraz zakres projektu jeszcze przed przygotowaniem finalnej wyceny. Jeżeli po zakończeniu Discovery klient zdecyduje się realizować projekt z Commerce Weavers, koszt warsztatów odliczamy od wartości wdrożenia. Dzięki temu Discovery staje się inwestycją w lepsze przygotowanie projektu, a nie dodatkowym kosztem.
Nie należy porównywać wyłącznie końcowej ceny. Najpierw trzeba sprawdzić, czy oferty obejmują ten sam zakres: analizę i Discovery, development, integracje, migrację danych, testy, DevOps, zarządzanie projektem, uruchomienie oraz utrzymanie po go-live. Warto również porównać skład zespołu, model rozliczenia, harmonogram, założenia wyceny i elementy wyłączone z zakresu. Dopiero wtedy można ocenić, czy przedstawione kwoty rzeczywiście dotyczą porównywalnych projektów.
Różnica w cenie nie musi wynikać wyłącznie ze stawek software house'ów. Jedna firma może uwzględnić w ofercie analizę, architekturę, QA, DevOps, migrację i zarządzanie projektem, podczas gdy inna wycenia przede wszystkim development. Różne mogą być także przyjęte założenia, skład i doświadczenie zespołu, zakres odpowiedzialności oraz model rozliczenia. Dlatego niższa cena początkowa nie zawsze oznacza niższy koszt całego projektu.
Dobra wycena powinna pozwalać zrozumieć nie tylko ile projekt będzie kosztował, ale również za co klient płaci i na jakich założeniach oparto tę kwotę. Powinna określać zakres prac, role w zespole, model rozliczenia, harmonogram, integracje, migrację, testy, DevOps oraz odpowiedzialność stron. Równie ważne jest wskazanie elementów nieuwzględnionych w cenie i sytuacji, które mogą spowodować zmianę budżetu.
Nie ma jednego modelu odpowiedniego dla każdego projektu. Fixed Price może sprawdzić się przy dobrze zdefiniowanym i stabilnym zakresie. Time & Materials daje większą elastyczność, gdy wymagania mogą zmieniać się wraz z rozwojem projektu. W obu przypadkach kluczowe jest ustalenie zasad zarządzania zakresem, budżetem i zmianami. Sam model rozliczenia nie eliminuje ryzyka wynikającego z niepełnych lub błędnych założeń.
Tak. Niższa cena początkowa może wynikać z mniejszego zakresu, nieuwzględnienia części prac lub innych założeń dotyczących odpowiedzialności. Jeżeli podczas realizacji okaże się, że dodatkowo trzeba wykonać migrację, testy, integracje, prace DevOps czy zmiany architektoniczne, rzeczywisty koszt projektu może wzrosnąć. Dlatego warto analizować nie tylko cenę wdrożenia, ale również potencjalne koszty zmian, utrzymania i dalszego rozwoju platformy.
Wybór platformy e-commerce wpływa nie tylko na uruchomienie sklepu internetowego, ale również na jego rozwój, integracje...
Czytaj więcej →
Wybór platformy e-commerce może zacząć się od bardzo długiej listy nazw obecnych na polskim rynku: Shopify, Adobe Commer...
Czytaj więcej →
Coraz więcej producentów, dystrybutorów i firm handlowych rozwija sprzedaż równolegle w modelu B2B i B2C. Klienci biznes...
Czytaj więcej →
