Kiedy opłaca się własna aplikacja, a kiedy lepiej kupić gotowe

Rachunek, który rozstrzyga

Punkt wyjścia jest prosty: ile godzin miesięcznie zajmuje dziś praca, którą miałaby wykonywać aplikacja. Przepisywanie danych między systemami, ręczne zestawienia, odpowiadanie na te same pytania klientów, szukanie informacji w kilku miejscach.

Godzina dziennie u dwóch osób to około pięciuset godzin rocznie. Przy takim rachunku narzędzie za kilkanaście tysięcy złotych zwraca się w pierwszym roku — a przy okazji znikają błędy, które przy ręcznym przepisywaniu są nieuniknione.

Drugą stroną rachunku jest to, czego nie robicie, bo nie ma jak. Zamówienia, których nie przyjmujecie, bo obsługa nie wyrabia. Klienci, którzy dzwonią z pytaniem o status, bo nie mają jak sprawdzić sami. To trudniejsze do policzenia, ale często ważniejsze.

Rachunek na jednej stronie: co wpisać po obu stronach

Rachunek z poprzedniego rozdziału łatwo zrobić zbyt optymistycznie. Po stronie korzyści wpisuje się wszystkie oszczędności, a po stronie kosztów tylko cenę pierwszej wersji. Uczciwe porównanie wymaga kilku pozycji więcej.

Obie kolumny warto policzyć w perspektywie kilku lat, tak samo jak przy porównaniu z licencjami. Jeśli w grę wchodzi gotowy system, jego koszty i ograniczenia opisujemy w artykule jaki ERP dla małej firmy.

Procesy, które najczęściej warto zautomatyzować

Większość zamówień na aplikacje w małych i średnich firmach dotyczy kilku powtarzalnych sytuacji. Jeśli któraś brzmi znajomo, warto policzyć, ile czasu dziś zajmuje.

W każdym z tych przypadków warto najpierw sprawdzić, czy nie wystarczy gotowe narzędzie albo rozszerzenie obecnego systemu — dopiero potem planować własną aplikację.

Najpierw sprawdź gotowe rozwiązania

Jeśli proces obsłuży program dostępny w abonamencie, a jedyną przeszkodą jest to, że wygląda brzydko albo nie ma jednej funkcji — nie ma powodu pisać czegoś od zera.

Warto sprawdzić trzy rzeczy: czy gotowy program obsługuje osiemdziesiąt procent Waszego procesu, czy pozostałe dwadzieścia da się obejść organizacyjnie i ile kosztuje w skali roku. Ta trzecia liczba bywa zaskakująco wysoka przy większej liczbie użytkowników.

Częstą i pomijaną drogą pośrednią jest rozszerzenie systemu, który już macie. Dopisanie modułu do istniejącego sklepu albo systemu magazynowego bywa kilkukrotnie tańsze niż osobna aplikacja — zobacz integracje z ERP.

Formularze i arkusze online: kiedy wystarczą

Nie każdy problem wymaga programisty. Formularz online połączony z arkuszem, wspólny kalendarz albo proste narzędzie do list zadań rozwiązują wiele problemów małych firm w kilka godzin i za niewielką opłatą.

Takie rozwiązania świetnie sprawdzają się na początek: pozwalają uporządkować proces i zobaczyć, czego naprawdę potrzebuje zespół. Często okazuje się, że to wystarcza na lata.

Granica pojawia się, gdy dane zaczynają się rozjeżdżać, kilka osób edytuje to samo jednocześnie, potrzebne są uprawnienia albo połączenie z systemem firmy. Wtedy prosty arkusz zaczyna kosztować więcej czasu, niż oszczędza.

Kiedy własne narzędzie ma sens

Gdy proces jest na tyle nietypowy, że żaden gotowy program go nie obsługuje bez ręcznych obejść. To najczęstszy powód i zwykle najbardziej uzasadniony.

Gdy narzędzie ma być przewagą konkurencyjną, a nie tylko usprawnieniem. Panel klienta, konfigurator z automatyczną wyceną albo portal zamówieniowy dla kontrahentów to rzeczy, które klienci porównują — i wybierają firmę, która je ma.

I gdy koszt licencji gotowego rozwiązania w skali kilku lat przekracza koszt napisania własnego. Przy dużej liczbie użytkowników ten próg bywa przekroczony szybciej, niż się wydaje.

Pierwsza wersja: najmniejszy zakres, który już pomaga

Najlepsze projekty zaczynają się od wersji, która robi jedną rzecz dobrze. Zamiast systemu obsługującego wszystkie procesy firmy powstaje narzędzie do jednego, najbardziej uciążliwego zadania.

Taka wersja powstaje szybciej, kosztuje mniej i od razu trafia do użytkowników. Po kilku tygodniach używania wiadomo, co jest naprawdę potrzebne, a co było tylko pomysłem na etapie rozmów.

Kolejne funkcje dokłada się na podstawie realnego użycia. Dzięki temu budżet idzie na rzeczy, z których ludzie korzystają, a nie na moduły, które powstały, bo „może się przydać”.

Analiza przed kodowaniem to najtańszy etap

Największe pieniądze w oprogramowaniu traci się nie na kodowaniu, tylko na budowaniu czegoś, czego nikt potem nie używa. Dlatego projekt zaczyna się od rozmów i obserwacji, a nie od projektowania ekranów.

Kluczowe pytanie brzmi: kto wykonuje dany proces, w jakiej kolejności, gdzie sięga po dane i co robi, gdy coś idzie nie tak. Ostatnia część jest najważniejsza, bo to właśnie wyjątki decydują o tym, czy narzędzie obsłuży realną pracę.

Z tych rozmów powstaje dokument z listą funkcji, opisem ról i szkicami ekranów. Warto, żeby był Wasz niezależnie od dalszej współpracy — pozwala porównać oferty kilku wykonawców na tej samej podstawie.

Opis potrzeb od firmy: co przygotować przed pierwszą rozmową

Analiza prowadzona przez wykonawcę idzie sprawniej, gdy firma przychodzi z własnym opisem. Nie musi to być specyfikacja techniczna — wystarczą dwie strony zwykłego tekstu, pisane językiem firmy, a nie programistów.

• Jaki problem ma zniknąć i po czym poznamy, że zniknął
• Kto będzie korzystał z aplikacji i na jakich urządzeniach
• Jak proces wygląda dziś, krok po kroku
• Najczęstsze wyjątki: co się dzieje, gdy coś idzie nie tak
• Skąd pochodzą dane i gdzie mają trafić
• Czego aplikacja na pewno nie ma robić w pierwszej wersji

Ostatni punkt bywa najcenniejszy. Świadome wyłączenie czegoś z zakresu chroni budżet lepiej niż jakikolwiek zapis w umowie, bo zamyka dyskusję, zanim się zacznie.

Rozmowy z użytkownikami i test makiet

Zanim powstanie pierwsza linijka kodu, warto pokazać przyszłym użytkownikom makiety ekranów — nawet proste, narysowane w narzędziu do projektowania. Pięć minut rozmowy nad makietą oszczędza tygodnie przeróbek gotowego systemu.

Najcenniejsze uwagi padają od osób, które będą korzystać z aplikacji codziennie: magazynierów, serwisantów, handlowców. Zarząd wie, czego firma potrzebuje; pracownicy wiedzą, jak to wygląda w praktyce.

Dobrze jest też obserwować, jak ktoś wykonuje zadanie dziś. Zwykle wychodzą przy tym kroki, o których nikt nie wspomniał w rozmowie, bo robi je odruchowo.

Aplikacja webowa czy mobilna

To pytanie pada na pierwszej rozmowie i prawie zawsze odpowiedź brzmi: zacznij od webowej. Działa w przeglądarce, na każdym urządzeniu, bez instalowania czegokolwiek i bez czekania na akceptację w sklepie z aplikacjami.

Aplikacja instalowana ze sklepu ma sens, gdy potrzebuje rzeczy, których przeglądarka nie daje: pracy bez internetu, powiadomień push, dostępu do skanera w trybie ciągłym albo pracy w terenie na słabym zasięgu.

Trzecia droga to aplikacja instalowalna z przeglądarki. Wygląda i działa jak mobilna, ma ikonę na ekranie i potrafi pracować offline, a powstaje z tego samego kodu co wersja webowa. W większości projektów to najrozsądniejszy kompromis.

Bezpieczeństwo i dane w aplikacji

Aplikacja firmowa przechowuje dane klientów, zamówienia, ceny i często dane osobowe. Bezpieczeństwo trzeba zaplanować od początku, a nie dokładać po uruchomieniu.

• Indywidualne konta i uprawnienia zależne od roli
• Szyfrowane połączenie i bezpieczne przechowywanie haseł
• Logowanie dwuskładnikowe dla kont z szerokimi uprawnieniami
• Dziennik zmian: kto i kiedy zmienił ważne dane
• Automatyczne kopie zapasowe z testem odtworzenia
• Aktualizacje bibliotek i serwera po uruchomieniu

Integracje: ERP, płatności, poczta, mapy

Aplikacja rzadko działa sama. Pobiera dane z systemu magazynowego, wysyła powiadomienia mailem, przyjmuje płatności albo pokazuje trasy na mapie. Każde takie połączenie trzeba zaplanować i wycenić.

Warto ustalić, który system jest źródłem prawdy dla danych — ceny w ERP, zlecenia w aplikacji — i jak aplikacja zachowa się, gdy drugi system będzie chwilowo niedostępny.

Przy integracjach z systemami handlowymi często okazuje się, że część potrzeb da się rozwiązać samą integracją, bez budowania nowej aplikacji. Opisujemy to przy integracjach ERP.

Budowa w odcinkach zamiast jednego wielkiego wdrożenia

Projekt, w którym klient przez pół roku nie widzi nic, a potem dostaje gotową całość, kończy się zwykle odkryciem, że połowa działa inaczej, niż sobie wyobrażał.

Sensowna praca wygląda inaczej: dwutygodniowe odcinki, po każdym działający fragment na środowisku testowym. Widzicie postęp i możecie reagować, dopóki zmiana jest tania — poprawka po dwóch tygodniach kosztuje ułamek tego, co przebudowa gotowego systemu.

Drugą zaletą jest kolejność. Najważniejsze funkcje powstają pierwsze i można ich używać, zanim projekt się skończy. Przy dłuższych projektach to bywa różnica między narzędziem używanym od trzeciego miesiąca a takim, które czeka pół roku.

Odbiór etapu: jak testować przed akceptacją

Praca w odcinkach działa tylko wtedy, gdy po każdym odcinku ktoś naprawdę sprawdza wynik. Kliknięcie kilku przycisków na spotkaniu to pokaz, a nie odbiór.

Test warto oprzeć na realnych przypadkach z ostatnich tygodni: konkretnym zleceniu, konkretnym kliencie, konkretnej pomyłce z arkusza. Sprawdzać powinny osoby, które będą z aplikacji korzystać, na urządzeniach, na których będą pracować — także na telefonie w terenie.

Zgłoszenie błędu powinno zawierać kroki, oczekiwany wynik i to, co faktycznie się stało. Warto od razu oddzielić błędy blokujące pracę od uwag kosmetycznych, bo tylko te pierwsze wstrzymują odbiór.

Jak wybrać wykonawcę

Oferty na tę samą aplikację potrafią różnić się kilkukrotnie. Zamiast porównywać same kwoty, warto porównać sposób pracy i to, co zostaje po projekcie.

• Czy wykonawca zaczyna od analizy, czy od razu podaje cenę?
• Czy pokazuje postęp w krótkich odcinkach na środowisku testowym?
• Czy przekazuje kod, dokumentację i dostępy?
• Kto będzie utrzymywał aplikację po wdrożeniu i na jakich zasadach?
• Czy może pokazać podobny, działający projekt?
• Jak rozlicza zmiany zakresu w trakcie prac?

Kod, dostępy i to, co zostaje po projekcie

Po zakończeniu projektu powinniście dostać pełny kod źródłowy, dokumentację i dostępy do wszystkich środowisk. To nie jest oczywistość i warto sprawdzić to w umowie, zanim prace się zaczną.

Bywają umowy, w których wykonawca zachowuje prawa albo udostępnia aplikację w modelu abonamentowym — gdy przestajecie płacić, system się wyłącza. To bywa uczciwy układ, jeśli jest jasno opisany; problem zaczyna się wtedy, gdy nie jest.

Osobną sprawą są konta w usługach zewnętrznych: hosting, domena, usługi płatnicze, narzędzia pomocnicze. Wszystkie powinny być założone na firmę, a nie na wykonawcę.

• Umowa bez zapisu o przekazaniu kodu źródłowego
• Hosting wyłącznie u wykonawcy, bez możliwości przeniesienia
• Brak dokumentacji technicznej po zakończeniu prac
• Konta w usługach zewnętrznych założone na wykonawcę
• Opłata za każdą zmianę treści, także jednozdaniową

Co zapisać w umowie

Umowa na oprogramowanie chroni obie strony, jeśli jasno opisuje zakres i zasady współpracy. Warto zadbać o kilka zapisów, zanim zaczną się prace.

• Zakres pierwszej wersji z listą funkcji
• Sposób zgłaszania i wyceny zmian zakresu
• Przekazanie kodu źródłowego, dokumentacji i dostępów
• Zasady odbioru każdego etapu
• Warunki utrzymania i poprawek po wdrożeniu
• Na kogo zakładane są konta w usługach zewnętrznych

Rzędy wielkości

Podanie ceny bez analizy byłoby zgadywaniem, ale można pokazać zakresy, w których mieszczą się projekty dla małych i średnich firm. Poniższe kwoty dotyczą pierwszej działającej wersji, nie docelowego systemu ze wszystkimi pomysłami.

Uruchomienie: dane startowe i pierwszy tydzień

Aplikacja bez danych jest pusta, a dane w małych firmach leżą zwykle w arkuszach, starych programach i skrzynkach mailowych. Import trzeba zaplanować jako osobne zadanie: z usunięciem duplikatów, ujednoliceniem formatów i sprawdzeniem wyniku przez kogoś z firmy.

Warto wyznaczyć konkretny dzień przełączenia i krótko po nim zablokować edycję starego arkusza. Długa praca równoległa w dwóch miejscach kończy się tym, że żadne z nich nie jest aktualne.

Pierwszy tydzień dobrze zaplanować tak, żeby wykonawca był łatwo dostępny, a w firmie była osoba zbierająca pytania i uwagi. Wiele zgłoszeń okazuje się wtedy kwestią przyzwyczajenia, a nie błędem, i szybko przestaje wracać.

Przykład: firma serwisowa i panel zleceń

Typowy przypadek z firm z regionu: firma serwisowa z okolic Lublina przyjmuje zgłoszenia telefonicznie i mailem, zapisuje je w arkuszu, a serwisanci dostają listę zleceń SMS-em. Klienci dzwonią z pytaniem o status, a po wizycie ktoś ręcznie przepisuje dane do faktury.

Pierwsza wersja aplikacji obejmuje tylko obieg zlecenia: przyjęcie zgłoszenia, przypisanie serwisanta, statusy widoczne w telefonie i automatyczne powiadomienie klienta. Kolejny etap łączy zakończone zlecenia z systemem do fakturowania.

Już pierwsza wersja zmniejsza liczbę telefonów z pytaniem o status i eliminuje zgubione zgłoszenia. Dopiero po kilku miesiącach używania firma decyduje, jakie funkcje dołożyć — na podstawie tego, z czego serwisanci naprawdę korzystają.

Wykonawca z regionu czy z dowolnego miejsca

Aplikację można zbudować z wykonawcą z każdego miejsca w kraju, a większość pracy i tak odbywa się na odległość. Lokalny wykonawca ma jednak przewagi na etapie analizy i wdrożenia.

Łatwiej umówić się na warsztaty w firmie, zobaczyć, jak wygląda praca na magazynie czy w serwisie, i przeszkolić użytkowników na miejscu. Przy projektach, w których aplikacja zmienia sposób pracy wielu osób, te spotkania mają duże znaczenie.

Firmom z Lublina i regionu pomagamy w obu formach — więcej przy aplikacjach webowych w Lublinie.

Co się dzieje po uruchomieniu

Aplikacja nie jest meblem — po wdrożeniu żyje dalej. Zmieniają się przepisy, systemy, z którymi się integruje, i sposób pracy w firmie. Warto przewidzieć budżet na utrzymanie już przy planowaniu projektu.

Typowy zakres to aktualizacje bezpieczeństwa, monitoring dostępności, kopie zapasowe i pula godzin na drobne zmiany. Bez tego aplikacja zestarzeje się w tempie, którego nikt nie planował.

Warto też przewidzieć, kto się tym zajmie, gdyby wykonawca zniknął. To pytanie, które warto zadać na etapie wyboru, a nie po dwóch latach — i dlatego kod, dokumentacja i dostępy mają znaczenie praktyczne, nie formalne.

Jak sprawdzić, czy aplikacja się zwróciła

Rachunek z początku artykułu warto powtórzyć kilka miesięcy po wdrożeniu. Tym razem na realnych danych, a nie na szacunkach.

Najprostsze miary to czas, który zespół oszczędza na zadaniach wykonywanych dotąd ręcznie, liczba błędów i reklamacji, liczba obsłużonych zleceń przy tym samym zespole oraz to, czy klienci korzystają z nowych możliwości, na przykład samodzielnego sprawdzania statusu.

Jeśli aplikacja nie przynosi oczekiwanych korzyści, zwykle przyczyną jest to, że część pracy nadal odbywa się poza nią. Warto zapytać użytkowników, co i dlaczego wciąż robią ręcznie — to najlepsza lista poprawek.

Najczęstsze błędy przy zamawianiu oprogramowania

Pierwszy: zamówienie wszystkiego naraz. Lista życzeń zebrana od wszystkich działów daje projekt, który nigdy się nie kończy. Lepiej zacząć od jednego procesu i rozbudowywać na podstawie realnego użycia.

Drugi: pominięcie osób, które będą narzędzia używać. Aplikacja zaprojektowana wyłącznie z zarządem trafia do ludzi, którzy pracują inaczej, niż zakładano — i wraca do nich arkusz kalkulacyjny.

Trzeci: wybór wykonawcy wyłącznie po cenie. Różnica w wycenie zwykle wynika z różnicy w zakresie, a nie w stawce. Warto porównywać, co dokładnie wchodzi w każdą ofertę — łącznie z tym, co dzieje się po wdrożeniu.

Przykłady potrzeb w firmach z Lubelszczyzny

Własna aplikacja kojarzy się z dużymi firmami, a wiele dobrych pomysłów pochodzi z małych zakładów i firm usługowych. Poniżej przykładowe potrzeby, które dobrze pasują do podejścia opisanego w tym artykule.

W każdym z tych przypadków pierwsza wersja obejmuje jedno zadanie i nie wymaga przebudowy całej firmy. Takie projekty prowadzimy także poza Lublinem — zobacz aplikacje webowe w Świdniku i w Białej Podlaskiej.

Rozwój po pierwszym roku

Aplikacja, która się sprawdziła, zwykle zaczyna obrastać nowymi pomysłami. To dobry znak, ale też moment, w którym łatwo stracić kontrolę nad zakresem i budżetem.

Pomaga prosta zasada: raz na kwartał zbiera się pomysły od użytkowników, ocenia je według korzyści i kosztu, a do realizacji trafiają tylko te z najlepszym stosunkiem. Reszta czeka na kolejny przegląd.

Warto też co jakiś czas sprawdzić, czy aplikacja nadal jest potrzebna w obecnej formie. Rynek gotowych narzędzi się zmienia i czasem po kilku latach bardziej opłaca się przejść na gotowe rozwiązanie niż rozwijać własne.