Gotowy moduł do sklepu czy projekt dedykowany: jak liczyć zwrot

Gotowy moduł do sklepu wygrywa z projektem dedykowanym zawsze wtedy, gdy problem jest typowy, a różnice w Twoim procesie da się pokryć konfiguracją. Projekt dedykowany ma sens dopiero, gdy proces daje przewagę albo żaden moduł nie obsługuje go bez obejść. Poniżej pokazuję, jak tę decyzję liczę z klientami, na jakich założeniach i gdzie najczęściej widzę błędy w rachunku.

Dlaczego ta decyzja wraca w każdym sklepie

Każdy rozwijający się sklep internetowy dochodzi do momentu, w którym standard platformy przestaje wystarczać. Dział sprzedaży chce promocji, których PrestaShop nie liczy sam, a klienci pytają o produkty składane z opcji. Pojawia się pytanie: szukamy dodatku czy zamawiamy własne rozwiązanie?

Z mojej perspektywy software house’u odpowiedź „zbudujmy to” jest najwygodniejsza, bo to największe zlecenie. Dlatego zaczynam od pytania odwrotnego, o którym pisałem w tekście o tym, kiedy nie budować systemu. Jeśli gotowe narzędzie robi to, czego potrzebujesz, pisanie własnego jest kosztem bez zwrotu.

Jak liczę zwrot: gotowy moduł do sklepu a projekt dedykowany

Zwrot liczę prosto: ile godzin pracy i ile błędów rocznie usuwa rozwiązanie, w porównaniu z tym, ile kosztuje zakup, wdrożenie i utrzymanie. Najczęściej pomijany element to utrzymanie, bo pojawia się dopiero po odbiorze.

Do porównania biorę cztery składniki po obu stronach:

• koszt wejścia: licencja modułu albo wycena projektu, plus konfiguracja i testy,
• czas do efektu: moduł działa po instalacji i konfiguracji, projekt dedykowany po analizie, programowaniu i odbiorze,
• utrzymanie: aktualizacje razem z platformą, poprawki po zmianach w sklepie, zgodność z innymi dodatkami,
• ryzyko: przy module ryzykujesz, że czegoś nie obsłuży, przy projekcie, że przekroczy budżet albo termin.

Rozbicie kosztu projektu dedykowanego opisałem szerzej w tekście o tym, od czego zależy wycena systemu. Tu wystarczy zasada: porównuj koszt całkowity w horyzoncie kilku lat, a nie fakturę z pierwszego miesiąca.

Przykład z jawnymi założeniami: promocje ilościowe w hurtowni

Weźmy hurtownię na PrestaShop, która chce promocji typu 5+1 i gratisów do zestawów. Wszystkie liczby poniżej to założenia przykładu, nie dane z wdrożenia.

1. Załóżmy, że handlowiec poprawia ręcznie rabaty w zamówieniach przez godzinę dziennie, czyli około 20 godzin w miesiącu.
2. Załóżmy, że raz w tygodniu klient dostaje fakturę z błędnie naliczonym gratisem, a korekta zajmuje obsłudze i księgowości po godzinie.
3. Razem daje to około 24 godzin w miesiącu pracy, która nie sprzedaje niczego nowego.
4. Moduł kosztuje licencję i kilka godzin konfiguracji oraz testów. Projekt dedykowany to analiza, programowanie reguł koszyka, testy z fakturami i korektami oraz późniejsze utrzymanie.

Przy takich założeniach moduł zwraca się po kilku tygodniach, a projekt dedykowany dopiero po wielu miesiącach, o ile nie trzeba go przepisywać przy aktualizacji sklepu. Podstaw własne godziny i stawki, a kolejność zwykle się nie zmieni, jeśli promocje są typowe.

Ten scenariusz nie jest wymyślony od zera. W Web Systems zrobiliśmy moduł WS Promotions X+Y dla PrestaShop, który powstał dla hurtowni z branży dentystycznej i działa produkcyjnie w jej sklepie. Nalicza w koszyku promocje typu 1+1, 2+1, 5+1 albo 20+3 oraz gratisy z innych produktów w stałej cenie netto albo za 0 zł. Rabat jest zwykłą regułą koszyka przypisaną do produktu, więc PrestaShop sam liczy VAT, faktury i korekty, a moduł nie używa nadpisań klas.

Kiedy gotowy moduł do sklepu wystarczy, a kiedy potrzebny jest projekt

Moduł wystarczy, gdy Twoja potrzeba mieści się w jego opcjach, a ograniczenia są dla Ciebie akceptowalne. Przed zakupem czytam właśnie listę ograniczeń, nie listę funkcji.

Sytuacja	Gotowy moduł	Projekt dedykowany
Promocje ilościowe i gratisy na jednej platformie	zwykle tak	rzadko się opłaca
Konfigurator produktu z opcjami i dopłatami	zwykle tak	gdy wycena zależy od zewnętrznych danych
Reguły zależne od danych z ERP lub umów indywidualnych	częściowo	często tak
Kilka sklepów w trybie multistore	sprawdź wymagania	bywa konieczny

Przykład z ostatniego wiersza jest realny: WS Promotions X+Y w wymaganiach ma wprost zapisane, że trybu multistore nie obsługuje. Dla jednego sklepu to bez znaczenia, dla sieci sklepów na jednej instalacji to powód do rozmowy o innym rozwiązaniu.

Drugi przykład: produkty składane z opcji w WooCommerce

Weźmy sklep z ceramiką, który sprzedaje filiżanki z opcjonalnym spodkiem i grawerem. Kolor graweru zależy od koloru filiżanki, a pole na tekst pokazuje się tylko wtedy, gdy klient wybierze grawer.

Taki przypadek opisuje dokumentacja wtyczki Woo Product Fields Pro dla WooCommerce, którą rozwijamy dla WooCommerce. Pola typu lista, checkbox i tekst grupuje się w zestawy przypisane do produktów, każda opcja może podnosić, obniżać albo nie zmieniać ceny, a warunki logiczne ukrywają pola zależnie od wcześniejszych wyborów. Cenę opcji można wpisać na stałe albo pobrać z innego produktu, np. spodka sprzedawanego osobno.

Projekt dedykowany zaczyna mieć sens dopiero, gdy wycena zależy od czegoś spoza sklepu, np. od cennika producenta pobieranego na bieżąco. Wtedy rozmawiamy o integracji, a nie o polach produktu.

Błędy w rachunku, które widzę najczęściej

• Porównanie licencji z wyceną bez utrzymania. Własny kod też trzeba aktualizować, a ten koszt rośnie razem z długiem technologicznym.
• Brak opisu potrzeby. Bez listy wymagań nie da się sprawdzić, czy moduł wystarczy. Pomaga krótki brief z wymaganiami systemu, nawet na jedną stronę.
• Kupno modułu bez testu na kopii sklepu. Kolizje z innymi dodatkami wychodzą dopiero przy prawdziwych zamówieniach.
• Dopisywanie funkcji, których nikt nie użyje. Projekt dedykowany kusi, żeby przy okazji zbudować wszystko, co przyszło do głowy na spotkaniu.

Moja rekomendacja

Zanim zamówisz wycenę projektu, spisz trzy najczęstsze sytuacje, w których standard sklepu zawodzi, i sprawdź, czy gotowy moduł do sklepu obsługuje je konfiguracją. Jeśli tak, policz zwrot na swoich godzinach i przetestuj go na kopii sklepu. Jeśli nie, masz gotowy materiał do rozmowy o projekcie dedykowanym i możesz umówić rozmowę o współpracy. Gdy problemem są promocje w PrestaShop, zacznij od sprawdzenia, czy moduł X+Y pokrywa Twoje zasady rabatowe, zanim zamówisz cokolwiek pisanego od zera.