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. Jeśli koszt narzędzia jest niższy niż wartość tych godzin w ciągu roku albo dwóch, inwestycja się zwraca, a przy okazji znikają błędy typowe dla ręcznego przepisywania.

Drugą stroną rachunku jest to, czego dziś nie robicie, bo się nie da. 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. Rzetelne 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 często warto zautomatyzować

Zamówienia na aplikacje w małych i średnich firmach często dotyczą kilku powtarzalnych sytuacji. Jeśli któraś występuje u Was, 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. Własną aplikację planuje się dopiero potem.

Najpierw sprawdź gotowe rozwiązania

Jeśli proces obsłuży program dostępny w abonamencie, a przeszkodą jest wyłącznie wygląd albo brak jednej funkcji, nie ma powodu pisać czegoś od zera.

Warto sprawdzić trzy rzeczy: czy gotowy program obsługuje zdecydowaną większość Waszego procesu, czy resztę 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 dużo tańsze niż osobna aplikacja, zobacz integracje z ERP.

Formularze i arkusze online: kiedy wystarczą

Część problemów da się rozwiązać bez programisty. Formularz online połączony z arkuszem, wspólny kalendarz albo proste narzędzie do list zadań porządkują wiele spraw w małych firmach w kilka godzin i za niewielką opłatą.

Takie rozwiązania dobrze 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 częsty powód i zwykle najlepiej uzasadniony.

Gdy narzędzie ma dać przewagę nad konkurencją, a nie wyłącznie usprawnić pracę. Panel klienta, konfigurator z automatyczną wyceną albo portal zamówieniowy dla kontrahentów to rzeczy, które klienci porównują i które potrafią przesądzić o wyborze firmy.

Również wtedy, 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

Dobre projekty często 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ą, zamiast na moduły dodane, bo „może się przydać”.

Analiza przed kodowaniem to najtańszy etap

W oprogramowaniu najwięcej traci się na budowaniu funkcji, których potem nikt nie używa. Dlatego projekt zaczyna się od rozmów i obserwacji, a dopiero potem projektuje się ekrany.

Trzeba ustalić, 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 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, bo 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.

• 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, 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. Kilka minut rozmowy nad makietą potrafi oszczędzić 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, a pracownicy wiedzą, jak wygląda codzienna praca.

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

Ten wybór pojawia się na pierwszej rozmowie i zwykle zalecamy start od aplikacji 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: długiej pracy bez internetu na dużej ilości danych, 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 wielu projektach to rozsądny 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 pierwszego etapu projektu.

• 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ę często odkryciem, że część 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 dużo mniej niż 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 jeszcze 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ą się bardzo różnić. Obok kosztu warto porównać sposób pracy i to, co zostaje po projekcie.

• Analiza przed wyceną zamiast ceny podanej od razu
• Postęp pokazywany w krótkich odcinkach na środowisku testowym
• Przekazanie kodu, dokumentacji i dostępów
• Zasady utrzymania aplikacji po wdrożeniu i osoba za nie odpowiedzialna
• Podobny, działający projekt, który wykonawca może pokazać
• Sposób rozliczania zmian 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. 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. Taki układ może być w porządku, jeśli jest jasno opisany w umowie.

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ę.

• 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

Od czego zależy koszt aplikacji

Każdy projekt wyceniamy indywidualnie, po analizie. Koszt pierwszej działającej wersji zależy przede wszystkim od rodzaju narzędzia, liczby ról i integracji. Wstępną ocenę pomysłu odsyłamy bezpłatnie w 24 godziny, a pełną wycenę przygotowujemy na podstawie analizy.

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 i szybko przestaje wracać.

Przykład: firma serwisowa i panel zleceń

Przykładowy, typowy przypadek: firma serwisowa 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 ogranicza zgubione zgłoszenia. Dopiero po kilku miesiącach używania firma decyduje, jakie funkcje dołożyć, na podstawie tego, z czego serwisanci faktycznie korzystają.

Wykonawca z regionu czy z dowolnego miejsca

Aplikację można zbudować z wykonawcą z każdego miejsca w kraju, a dużą część pracy i tak wykonuje 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 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 szybko się zestarzeje.

Dobrze jest też wiedzieć, kto się tym zajmie, gdyby wykonawca zniknął. Ustala się to na etapie wyboru, a nie po dwóch latach, i dlatego kod, dokumentacja i dostępy mają znaczenie praktyczne.

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.

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 dowiedzieć się od użytkowników, co i dlaczego wciąż robią ręcznie, bo to gotowa 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 ciągnie się bez końca. 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. Warto porównywać, co dokładnie wchodzi w każdą ofertę, łącznie z tym, co dzieje się po wdrożeniu.

Przykłady potrzeb w małych firmach

Własna aplikacja kojarzy się z dużymi firmami, a dobre pomysły często pochodzą z małych zakładów i firm usługowych. Poniżej przykładowe, uogólnione 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. Szczegóły: 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.