Program enova ERP - zakres modułów i sposób wdrożenia w firmie

Program enova ERP - co obejmuje system Soneta

Nazwa „program enova ERP” odnosi się do systemu enova365, który opracowała firma Soneta. Jest to oprogramowanie klasy ERP napisane w technologii Microsoft .NET i przeznaczone do zarządzania całą firmą: obejmuje działy handlowy i księgowy oraz kadrowo-płacowy. Dane z tych działów trafiają do jednej bazy, więc każdy dział pracuje na tych samych informacjach.

System działa w chmurze albo lokalnie. Użytkownik pracuje w oknie aplikacji na komputerze, w przeglądarce lub na telefonie albo tablecie. Producent dokumentuje aktualny zakres funkcji na stronie enova.pl, a ten artykuł porządkuje go od strony wyboru i wdrożenia.

Poniższa tabela wiąże obszary funkcjonalne opisane przez producenta z artykułami klastra enova365 na SoftwarePedii. Obszary bez osobnego artykułu wymieniono dla kompletności obrazu.

Reguła: obszar z listy producenta staje się elementem projektu dopiero wtedy, gdy ma właściciela procesu i dane wejściowe.

Reguła chroni przed najczęstszym błędem przy wyborze: kupieniem zakresu, który nikt nie potrafi zasilić danymi. Moduł bez właściciela pozostaje pusty, a firma płaci za utrzymanie funkcji, z których nie korzysta. Kolejność uruchamiania modułów omawia trzecia sekcja tego tekstu.

Wspólna baza danych i technologia .NET

Producent podkreśla, że enova365 ma wspólną bazę danych, dzięki czemu raz wprowadzona informacja jest widoczna we wszystkich miejscach. Klient działa w środowisku Windows i pozwala obsłużyć pełną funkcjonalność z klawiatury, co przyspiesza pracę na stanowiskach wystawiających wiele dokumentów dziennie.

Technologia .NET zapewnia zgodność z innymi rozwiązaniami tej samej platformy, co według opisu ułatwia integrację z pozostałymi systemami firmy. Założenia platformy przedstawia dokumentacja Microsoft Learn.

Co daje jedna baza, a czego nie daje

Wspólna baza usuwa przepisywanie danych, ale nie zwalnia z porządku w słownikach. Kartoteka kontrahenta założona dwa razy pod różnymi nazwami zostanie zapisana dwa razy w każdym module, który z niej korzysta. Poniższe zestawienie pokazuje różnicę względem układu z osobnych programów.

Różnicę spójności najlepiej widać na przykładzie transakcji. Poniższy szkic pokazuje sam mechanizm: sprzedaż zmniejsza stan magazynowy i tworzy zapis księgowy, a brak towaru przerywa cały dokument. Tabele są umowne i nie opisują struktury bazy enova365.

-- przykładowe tabele, nie schemat enova365
BEGIN TRY
    BEGIN TRANSACTION;

    INSERT INTO dbo.DokumentSprzedazy (Numer, KontrahentId, Wartosc)
    VALUES (N'FV/2026/0001', 17, 1230.00);

    UPDATE dbo.StanMagazynowy
    SET Ilosc = Ilosc - 10
    WHERE TowarId = 42 AND Ilosc >= 10;

    IF @@ROWCOUNT = 0
        THROW 50001, N'Brak towaru na stanie.', 1;

    INSERT INTO dbo.ZapisKsiegowy (DokumentNumer, Konto, Kwota)
    VALUES (N'FV/2026/0001', N'ROZRACHUNKI', 1230.00);

    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    IF @@TRANCOUNT > 0 ROLLBACK TRANSACTION;
    THROW;
END CATCH;

Przy trzech osobnych programach ten sam dokument wymagałby trzech wywołań, a przerwanie po drugim zostawiłoby fakturę bez zapisu księgowego. Jedna transakcja albo zapisuje wszystko, albo nic, i to jest praktyczny sens wspólnej bazy.

Chmura albo instalacja lokalna

Forma uruchomienia zmienia podział obowiązków, a nie sposób pracy użytkownika. W chmurze dostawca utrzymuje serwer i kopie zapasowe oraz aktualizuje platformę, więc firma odpowiada głównie za konfigurację i dane. Przy instalacji lokalnej te czynności należą do działu IT, który musi zaplanować kopie bazy i miejsce na wzrost danych.

Wybór wpływa też na integracje. Magazyn z terminalami i drukarkami etykiet pracuje w sieci lokalnej, więc połączenie z ERP w chmurze wymaga stabilnego łącza i przemyślanej kolejki wymiany. Przerwa w łączu nie może zatrzymać wydań na hali, dlatego dokumenty czekają w kolejce i przekazują się po odzyskaniu połączenia.

Jak dobrać zakres modułów programu enova ERP

System ma budowę modułową, więc firma nie musi uruchamiać wszystkiego jednocześnie. Zalecany sposób to zacząć od priorytetowych modułów, na przykład księgowości i kadr, a kolejne obszary, na przykład sprzedaż i magazyn, dołączać etapami wraz z rozwojem firmy. Oszczędza to koszt jednorazowego wdrożenia funkcji, z których część nigdy nie zostanie użyta.

Wybór pierwszego modułu wynika z tego, co w firmie boli najbardziej. Poniższa tabela przypisuje typowe objawy do obszaru, od którego warto zacząć. To reguła doboru, a nie specyfikacja produktu.

Kolejność uruchamiania wynika z zależności danych. Dokument magazynowy tworzy zobowiązanie lub należność, więc księgowość musi być gotowa wcześniej niż handel, który ją zasila. Kadry są zwykle niezależne od pozostałych obszarów i można je uruchomić równolegle. Odwrócenie kolejności oznacza dokumenty, które nie mają jeszcze gdzie się rozliczyć.

Cztery pytania przed decyzją

Przed ustaleniem zakresu warto odpowiedzieć na cztery pytania, które porządkują projekt niezależnie od branży.

• Wolumen dokumentów - ile dokumentów sprzedaży i przyjęć oraz list płac firma przetwarza miesięcznie, bo od tego zależy, które ręczne czynności warto zautomatyzować w pierwszej kolejności.
• Zależności między obszarami - czy magazyn zasila sprzedaż, a sprzedaż księgowość, bo zależny moduł trzeba uruchomić po tym, który go zasila.
• Wymogi prawne - które obowiązki sprawozdawcze system musi obsłużyć od pierwszego dnia pracy.
• Jakość danych wyjściowych - w jakim stanie są kartoteki i salda, które trzeba przenieść z dotychczasowych programów.

Decyzja o zakresie jest częścią szerszego rachunku opłacalności. Kryteria, według których warto porównać system ERP z obecnym arkuszem oraz z innymi programami, zestawia artykuł o tym, kiedy wdrożenie ERP w firmie się opłaca.

Dostosowanie programu enova ERP i integracje z magazynem

enova365 rośnie wraz z potrzebami użytkownika: zamiast kosztownej wymiany oprogramowania firma rozszerza funkcjonalność o kolejne moduły. Sam zakres konfiguracji, dostosowanie do rodzaju rozliczeń i dobór funkcji do branży opisuje artykuł o tym, jak dostosować program enova365 do specyfiki firmy.

Moduł magazynowy w enova365 pokrywa obrót towarowy, ale magazyny z adresacją lokalizacji i pracą na terminalach często korzystają z osobnego systemu klasy WMS. SoftwareStudio łączy Studio WMS.net z ERP enova firmy Soneta, co opisuje tekst o integracji ENOVA. Stronę produktu prowadzi serwis Studio WMS.net.

Podział własności danych przy integracji z WMS

Integracja działa, gdy każdy rekord ma jednego właściciela. Poniższy podział jest typowy dla połączenia ERP z systemem magazynowym i wymaga potwierdzenia w projekcie konkretnego wdrożenia.

Wymiana danych bez dublowania rekordów

Połączenie dwóch systemów musi znosić powtórzenia. Sieć zawiesi się w połowie przesyłania, a nadawca wyśle ten sam dokument ponownie. Odbiorca rozpoznaje powtórkę po kluczu zewnętrznym, czyli parze: system źródłowy i numer dokumentu w tym systemie. Unikalny indeks w bazie odbiorcy odrzuca drugi zapis zamiast tworzyć duplikat.

-- przykład: klucz zewnętrzny chroni przed podwójnym zapisem
CREATE UNIQUE INDEX UX_DokumentMagazynowy_Zrodlo
    ON dbo.DokumentMagazynowy (SystemZrodlowy, NumerZewnetrzny);

Błąd naruszenia indeksu nie oznacza awarii, tylko potwierdza, że dokument już dotarł. Import powinien go obsłużyć jako sukces, a pozostałe błędy kierować do kolejki do wyjaśnienia przez człowieka. Rozszerzenia tam, gdzie standard systemu nie wystarcza, przedstawia strona usług SoftwareStudio. Producent systemu i jego strategię rozwoju opisują artykuły o firmie Soneta i systemie enova365 oraz o tym, jak Soneta wspiera polskie przedsiębiorstwa.

Wdrożenie programu enova ERP z partnerem wdrożeniowym

System tej klasy wdraża zwykle zespół zewnętrzny, który zna zarówno produkt, jak i sposób pracy firmy. Ten rozdział opisuje podział ról, a nie kolejne etapy projektu. Etapy, od analizy po uruchomienie, omawia artykuł o tym, jak przebiega profesjonalne wdrożenie systemu ERP.

Największe ryzyko leży po stronie danych wyjściowych, które dostarcza firma. Partner skonfiguruje moduł, ale nie naprawi kartoteki towarów zawierającej setki zdublowanych pozycji, jeżeli nikt po stronie firmy nie ustali, która wersja jest właściwa.

Migracja danych i uprawnienia

Migracja obejmuje kartoteki oraz salda otwarcia wraz z dokumentami nierozliczonymi. Pełnej historii szczegółowej zwykle się nie przenosi, bo obciąża bazę, a nie wpływa na bieżące rozliczenia. Starsze dane pozostają w archiwum poprzedniego programu, dostępnym do odczytu.

Uprawnienia ustawia się według ról, a nie według osób. Księgowa widzi zapisy finansowe, magazynier dokumenty wydań, a kierownik przegląd obu obszarów. Rola opisana raz przydziela się każdemu nowemu pracownikowi bez ręcznego zaznaczania pojedynczych funkcji.

Reguła: odbiór wdrożenia opiera się na scenariuszach testowych z danymi firmy, a nie na pokazie danych przykładowych.

Scenariusz odbiorowy wynika z procesu: wystawić fakturę z pozycji z magazynu, przyjąć dostawę, zamknąć okres. Każdy z nich sprawdza na prawdziwych dokumentach, czy skutki zapisu pojawiły się we wszystkich modułach, których dotyczą.

Aktualizacje i zmiany przepisów w cyklu życia systemu

Według opisu producent regularnie aktualizuje system w reakcji na zmiany przepisów i zapewnia wsparcie techniczne. Dla firmy oznacza to cykl, w którym nowa wersja wymaga instalacji i sprawdzenia, a nie tylko obserwowania komunikatów.

Dobra praktyka polega na sprawdzeniu aktualizacji na kopii bazy, zanim trafi do pracy produkcyjnej. Kopię odtwarza się z kopii zapasowej, wykonuje na niej typowe operacje i dopiero po pozytywnym wyniku przenosi zmianę na środowisko produkcyjne. Termin aktualizacji warto ustawić poza okresami zamknięć, kiedy księgowość i magazyn pracują z największym obciążeniem. Model chmurowy przesuwa część tych czynności na dostawcę, ale odpowiedzialność za sprawdzenie własnych rozszerzeń i integracji pozostaje po stronie firmy.

Reguła: aktualizacja trafia do pracy produkcyjnej dopiero po przejściu testów na kopii bazy, a nie po samej instalacji.

Osobną kwestią są rozszerzenia własne, czyli raporty i wydruki oraz integracje dopisane przez wdrożeniowca. Po zmianie wersji mogą przestać działać, gdy zmienił się model danych, na którym się opierają. Przy każdej aktualizacji wykonuje się więc te same testy regresyjne na kopii bazy, a wyniki porównuje z poprzednim przebiegiem. Różnica w wyniku wskazuje, które rozszerzenie wymaga poprawki przed uruchomieniem na produkcji.

Zakres obsługi konkretnych zmian, na przykład sprawozdawczości podatkowej, opisuje osobno artykuł o JPK i eDeklaracjach. Tam też widać, dlaczego szczegółowych dat i numerów przepisów nie należy opierać na opisie ogólnym: obowiązują je aktualne komunikaty administracji podatkowej.