Oprogramowanie na zamówienie ma sens wtedy, gdy kluczowy proces twojej firmy nie mieści się w żadnym gotowym systemie, a obejścia kosztują więcej niż budowa. W pozostałych przypadkach wystarcza gotowy system albo gotowy system z dobudowanym jednym elementem. Poniżej kryteria, którymi można to sprawdzić, zanim poprosisz o pierwszą wycenę.
Trzy drogi: gotowy system, dobudowany element, budowa od zera
- Gotowy system. Wdrażasz istniejące oprogramowanie (ERP, CRM, sklep, magazyn) i dopasowujesz proces firmy do jego możliwości, w granicach konfiguracji.
- Gotowy system plus dobudowany element. Zostajesz przy znanym systemie i dokładasz wtyczkę, konektor albo małą aplikację, która obsługuje jeden brakujący proces.
- Budowa od zera. Powstaje nowy system pisany pod twoje procesy.
Większość firm powinna zacząć od pierwszej drogi i przejść do dalszych tylko wtedy, gdy ma konkretny powód.
Kiedy gotowe oprogramowanie wystarcza
Gotowy system jest dobrym wyborem, gdy:
- twój proces jest standardowy dla branży (fakturowanie, magazyn, księgowość, sklep),
- masz mało specyficznych reguł, które trudno wyrazić w konfiguracji,
- nie planujesz zmian w procesie w najbliższych latach,
- liczy się szybki start i ograniczone ryzyko,
- dostawca ma sprawdzoną dokumentację i wsparcie.
Gotowe rozwiązania mają jedną przewagę, której budowa na zamówienie nie ma: rozwija je wielu użytkowników, więc typowe błędy i wymagania prawne są w nich zwykle obsłużone wcześniej. Pamiętaj jednak, że to ogólna zasada, a nie gwarancja. Zawsze sprawdź, jak dostawca informuje o zmianach.
Kiedy proces firmy nie mieści się w gotowym narzędziu
Sygnały, że gotowy system przestaje wystarczać:
- pracownicy prowadzą równolegle arkusz kalkulacyjny, bo system nie obsługuje ważnego przypadku,
- te same dane trzeba wpisywać w dwóch lub trzech miejscach,
- zasady cen, rabatów lub dostaw są tak złożone, że konfiguracja przypomina programowanie,
- proces jest przewagą firmy, której nie chcesz dopasowywać do cudzego narzędzia,
- potrzebujesz specyficznych raportów lub widoków dla pracowników terenowych.
Zanim uznasz, że potrzebujesz budowy od zera, upewnij się, że problem nie wynika ze złej konfiguracji lub braku szkolenia. Rozmowa z dostawcą gotowego systemu bywa tańsza niż projekt.
Brakujący element zamiast nowego systemu
Często najlepszy wariant jest pośredni: zostajesz przy systemie, który działa, i dobudowujesz pojedynczy element. Przykłady typów takich elementów: połączenie sklepu z programem magazynowym, moduł do wyceny, aplikacja dla handlowców zbierająca zamówienia, wtyczka rozszerzająca sklep.
Zalety: mniejszy koszt, krótszy czas, znany system pod spodem. Wady: zależność od platformy bazowej. Zmiana jej wersji może wymagać poprawek twojego elementu, o czym niżej w sekcji o kosztach.
Takie rozwiązanie zwykle wymaga, żeby system bazowy miał udokumentowany sposób rozbudowy (interfejs API, mechanizm wtyczek, zestaw programistyczny). Sprawdź to w dokumentacji, zanim zamówisz dobudowę.
Koszty, które pojawiają się po wdrożeniu
Cena wdrożenia to początek wydatków. Po uruchomieniu pojawiają się:
- aktualizacje platform, na których oprogramowanie działa, i dopasowania po ich zmianach,
- hosting, kopie zapasowe i monitoring,
- poprawki błędów i drobne zmiany zgłaszane przez użytkowników,
- szkolenie nowych pracowników,
- rozwój: nowe wymagania biznesowe i prawne.
Przy gotowych systemach część tych kosztów jest ukryta w abonamencie. Przy oprogramowaniu na zamówienie trzeba je ustalić w umowie. Zapytaj wykonawcę, kto odpowiada za utrzymanie, na jakich zasadach i co się stanie, gdy projekt przestanie być rozwijany.
Prawa do kodu i dane osobowe
Dwie sprawy prawne warto uzgodnić na piśmie przed startem. Nie jest to porada prawna, a umowy skonsultuj z prawnikiem.
Prawa autorskie do kodu. Według ustawy o prawie autorskim program komputerowy jest chroniony jak utwór literacki, a prawa majątkowe obejmują zwielokrotnianie, zmiany i rozpowszechnianie. Prawa majątkowe do programu stworzonego przez pracownika w ramach obowiązków przysługują pracodawcy, o ile umowa nie stanowi inaczej. Przy wykonawcy zewnętrznym warto więc zapisać, kto i w jakim zakresie może kod używać, zmieniać i przekazać innej firmie. Pytanie praktyczne: czy za rok będziesz mógł zlecić rozwój komuś innemu?
Dane osobowe. Jeśli wykonawca będzie miał dostęp do danych osobowych klientów lub pracowników, zwykle potrzebna jest umowa powierzenia przetwarzania. UODO wskazuje, że powierzenie trzeba udokumentować, a umowa powinna między innymi określać przedmiot, czas i cel przetwarzania, rodzaj danych, przetwarzanie wyłącznie na polecenie administratora, zasady podpowierzenia oraz zwrot lub usunięcie danych po zakończeniu.
Pytania, które warto zadać przed decyzją
- Jaki konkretnie proces ma obsłużyć nowe oprogramowanie i co dziś w nim nie działa?
- Czy to da się rozwiązać konfiguracją lub dodatkiem do znanego systemu?
- Kto będzie korzystał z narzędzia i jak często?
- Z jakimi systemami musi się łączyć?
- Kto utrzymuje je po wdrożeniu i na jakich zasadach?
- Czy dostaniesz dostęp do kodu i dokumentacji?
- Jak wygląda plan na wypadek zmiany wykonawcy?
- Jak będziesz odbierać pracę: etapami, z wersją do sprawdzenia?
Dobry wykonawca odpowie bez wymijania, a część pytań sam zada tobie.
Jak porównać drogi w praktyce
Zestaw dwie lub trzy opcje w tabeli, z tymi samymi wierszami: co obsługuje twój kluczowy proces bez obejść, ile osób musi to utrzymywać, jakie są koszty cykliczne, kto odpowiada za zgodność z przepisami i zmianami platform, jak wyglądałby powrót, gdyby wybór okazał się zły. Odpowiedzi „nie wiem” też wpisz. Pokazują, o co zapytać dostawcę lub wykonawcę, zanim podpiszesz umowę.
Podsumowanie
Zacznij od gotowego systemu, rozważ dobudowanie brakującego elementu i budowę od zera zostaw na sytuacje, w których proces naprawdę nie ma odpowiednika. Przed decyzją policz koszt utrzymania, ustal prawa do kodu i zasady postępowania z danymi. Jeśli chcesz omówić swój przypadek, opis usług M8T i sposobu współpracy znajdziesz na stronie.