Dodatki do enova365 na zamówienie: kiedy warto rozszerzyć system

Standardowe moduły enova365 pokrywają większość potrzeb firm, ale każda organizacja ma swoje nietypowe procesy. Jedna firma nalicza rabaty według reguł, których nie przewidział żaden producent. Inna musi wysyłać dane do systemu partnera w ściśle określonym formacie. Często kończy się to arkuszem obok ERP i ręcznym przepisywaniem. Brakującą funkcję można jednak dopisać do samego systemu, bo enova365 ma otwarte SDK.

Najpierw konfiguracja, potem kod

Zanim zamówisz dodatek, sprawdź, czy problemu nie rozwiąże sam system. enova365 ma rozbudowaną konfigurację: cechy, czyli dodatkowe pola na kartotekach i dokumentach, definicje dokumentów, workflow, własne wydruki i raporty. Sporo „brakujących funkcji” okazuje się kwestią ustawień. Dobry konsultant zacznie rozmowę właśnie od tego pytania, a nie od wyceny programowania.

Dodatek ma sens, gdy konfiguracja nie wystarcza. Dzieje się tak, kiedy potrzebna jest logika, której nie da się wyklikać, integracja z zewnętrznym systemem albo nowy ekran dopasowany do sposobu pracy zespołu.

Typowe przykłady dodatków

• automatyczne generowanie dokumentów według reguł firmy, np. zamówień do dostawców po przekroczeniu stanu minimalnego
• nietypowe wydruki, raporty i zestawienia dla zarządu
• integracje z systemami partnerów, sklepami, WMS czy bankami
• dodatkowe kontrole i blokady chroniące przed błędami, np. przed sprzedażą klientowi z przeterminowanymi należnościami
• kreatory skracające powtarzalne operacje do kilku kliknięć

Jak policzyć, czy dodatek się zwróci

Dodatek opłaca się, gdy proces powtarza się często, zajmuje dużo czasu albo generuje błędy. Dobrą miarą jest czas, który zespół traci miesięcznie na ręczną pracę. Jeśli jest go dużo, inwestycja zwykle szybko się zwraca.

Rachunek jest prosty. Ustal, ile razy w miesiącu wykonywana jest operacja, ile minut trwa i ile osób się nią zajmuje. Dodaj koszt błędów: korekty faktur, zwroty, nadgodziny przy zamknięciu miesiąca, spóźnione wysyłki. Porównaj tę sumę z ceną wykonania dodatku i jego utrzymania w kolejnych latach. Utrzymanie łatwo pominąć, a dodatek to kod, który żyje razem z systemem i trzeba go sprawdzać przy nowych wersjach.

Kiedy lepiej poczekać z zamówieniem

• Proces zmienia się co kilka tygodni i nikt w firmie nie potrafi go jednoznacznie opisać.
• Operacja zdarza się kilka razy w roku, więc ręczna praca kosztuje mniej niż programowanie.
• Problem wynika z braku przeszkolenia zespołu, a nie z braku funkcji.
• Producent zapowiada podobną funkcję w standardzie w jednej z najbliższych wersji.

Dlaczego zgodność z SDK ma znaczenie

Ważne, by dodatek był napisany zgodnie z zasadami SDK. Wtedy działa także po aktualizacjach enova365 i nie blokuje rozwoju systemu.

Rozwiązania pisane obok systemu, np. skrypty zapisujące dane bezpośrednio do bazy z pominięciem logiki biznesowej, działają do pierwszej większej zmiany struktury danych. Potrafią też ominąć kontrole poprawności, przez co w bazie lądują zapisy, których program normalnie by nie przyjął. Dodatek zbudowany na SDK korzysta z tych samych mechanizmów co moduły standardowe, w tym z uprawnień użytkowników. Mimo to przed każdą aktualizacją wersji trzeba go sprawdzić na kopii bazy. Jak to zaplanować, opisujemy w tekście o bezpiecznej aktualizacji enova365.

Od opisu procesu do testów na Twoich danych

W FX2 mamy programistów SDK enova365. Zaczynamy od opisu procesu, przygotowujemy rozwiązanie etapami i testujemy je na danych firmy. Więcej o podejściu do oprogramowania na zamówienie przeczytasz na stronie systemów dedykowanych.

Po stronie firmy najwięcej zależy od dobrego opisu. Spisz, kto wykonuje proces, jakie dane wchodzą, co ma powstać na końcu i jakie zdarzają się wyjątki. Przykładowe dokumenty i arkusze, w których dziś liczysz coś ręcznie, skracają analizę bardziej niż długi opis słowny. Wyznacz też jedną osobę, która będzie odpowiadać na pytania programisty i zaakceptuje wynik testów. Bez niej projekt wydłuża się, bo każde pytanie krąży po kilku działach.

Jak wygląda projekt dodatku etap po etapie

1. Analiza. Programista z konsultantem rozmawiają z osobami, które wykonują proces, i oglądają, jak dziś wygląda praca w systemie i w arkuszach.
2. Opis rozwiązania. Powstaje krótki dokument: co dodatek robi, w których miejscach systemu się pojawia, jakie ma uprawnienia i co dzieje się w sytuacjach wyjątkowych.
3. Pierwsza wersja. Najpierw powstaje najczęstszy scenariusz, bez wszystkich wyjątków, żeby zespół mógł szybko sprawdzić, czy kierunek jest dobry.
4. Testy na kopii bazy. Użytkownicy pracują na swoich danych, ale bez ryzyka dla bazy produkcyjnej, i zgłaszają poprawki.
5. Uruchomienie i opieka. Dodatek trafia do bazy produkcyjnej, a przy kolejnych wersjach enova365 jest sprawdzany i w razie potrzeby dostosowywany.

Podział na etapy ogranicza ryzyko obu stron. Jeśli po pierwszej wersji okaże się, że proces trzeba zmienić, poprawka kosztuje mniej, niż gdyby gotowy dodatek trzeba było przebudować.

Jeśli potrzeba jest na tyle duża, że zastanawiasz się, czy nie lepiej zbudować osobnej aplikacji, przeczytaj porównanie systemu dedykowanego i gotowego oprogramowania. Dodatek wygrywa wtedy, gdy dane i tak żyją w enova365, a użytkownicy nie chcą przełączać się między programami.

Pytania, które padają przed zamówieniem dodatku

Czy dodatki przetrwają aktualizacje enova365?

Tak, jeśli są napisane zgodnie z SDK. Przy dużych zmianach w nowych wersjach sprawdzamy i dostosowujemy je w ramach opieki.

Ile trwa przygotowanie dodatku?

Proste rozszerzenia to zwykle dni lub kilka tygodni, większe projekty realizujemy etapami.

Co, jeśli po roku zmieni się nasz proces?

Dodatek można rozbudować albo zmienić. Im lepiej był opisany na starcie i im więcej parametrów da się ustawić bez programowania, np. progów kwotowych czy list kontrahentów, tym mniejsza będzie ta zmiana.

Do kogo należy kod dodatku?

To zależy od umowy, dlatego trzeba to ustalić przed startem prac. Zapisz w niej, czy firma dostaje kod źródłowy, kto może go później rozwijać i na jakich zasadach odbywa się opieka po wdrożeniu.