Enova365 to system, z którym pracuje wielu naszych klientów i z którym regularnie spotykamy się na audytach w nowo przejmowanych środowiskach - zazwyczaj wtedy, gdy firma przekazuje obsługę IT do nas. Schemat bywa podobny: firma ma enovę od kilku lat, system działa, ale dostęp zdalny jest powolny, nikt do końca nie wie gdzie są backupy, a aktualizacja wydana przez producenta wisi "na później", bo ostatnia skończyła się godzinami nerwów. Zanim dojdzie do awarii, infrastruktura pod enovę jest właściwie niewidoczna - a potem staje się problemem numer jeden.

Ten tekst jest praktycznym przewodnikiem po tym, jak środowisko pod enova365 powinno wyglądać i jakie decyzje podejmuje się najczęściej źle. Piszemy z perspektywy firmy, która utrzymuje takie środowiska u klientów w modelu outsourcingu IT - a sama, od strony księgowości i fakturowania, też pracuje na enovie.

Architektura enova365 - trzy warstwy i trzy interfejsy

Enova365 jest systemem w architekturze trójwarstwowej: baza danych, logika biznesowa, interfejs użytkownika. Producent (Soneta) udostępnia trzy interfejsy do tej samej bazy: okienkowy (klasyczny, Windows Forms, opisywany też jako Standard), przeglądarkowy (Multi, HTML5 przez ASP.NET Core) oraz mobilny (Android i iOS). Wszystkie trzy pracują na tej samej instalacji i tej samej bazie SQL - można je używać równolegle, bez duplikowania danych.

To rozróżnienie jest istotne, bo większość decyzji infrastrukturalnych dotyczy nie samej "enovy", tylko tego, gdzie stawiamy każdą z warstw i jak użytkownicy do nich docierają.

SQL Server Express czy Standard pod enova365 - limity i kiedy je odczuwasz

Enova365 w aktualnych wersjach wspiera Microsoft SQL Server 2016, 2017, 2019, 2022 oraz 2025, zarówno w edycji Standard, jak i Express. Wybór między nimi nie jest techniczną drobnostką, bo SQL Server Express - choć darmowy - ma twarde limity, które przy rozwoju firmy potrafią uderzyć w najmniej oczekiwanym momencie.

Ograniczenia Express (w wersjach do 2022 włącznie) są następujące:

• rozmiar pojedynczej bazy: 10 GB (według aktualnej dokumentacji Microsoft limit w SQL Server 2025 Express został podniesiony do 50 GB - to świeża zmiana, ale wciąż ograniczenie)

• pamięć buforu (buffer pool): 1410 MB - niezależnie od tego, ile RAM ma fizycznie serwer, SQL nie wykorzysta więcej

• wykorzystanie CPU: 1 socket lub 4 rdzenie, co osiągnie pierwsze

• brak SQL Server Agent - czyli brak wbudowanego schedulera do automatycznych backupów, konserwacji indeksów czy DBCC CHECKDB

• brak zaawansowanych funkcji HA (AlwaysOn, mirroring), brak Profilera, ograniczony zakres replikacji

Dla firmy, która właśnie startuje z enovą, kilku operatorów wystawia faktury, a księgowość prowadzona jest na jednej spółce - Express bywa wystarczający. Problem pojawia się w typowym scenariuszu SMB: rośnie liczba dokumentów, dochodzi moduł handlowy z historią magazynu, ktoś włącza DMS z załącznikami w bazie, kadry mają pełną historię zatrudnienia i rozliczeń. W ciągu 2-3 lat baza podchodzi pod limit, a to, co wczoraj działało sprawnie, zaczyna się dusić, bo SQL nie ma pamięci na cache.

Drugi, rzadziej omawiany problem Express: brak SQL Server Agent oznacza, że backup trzeba zorganizować zewnętrznie. W teorii można to zrobić skryptem PowerShell w Harmonogramie Zadań Windows albo narzędziem trzecim. W praktyce - bardzo często w ogóle tego nie ma, bo nikt się tym nie zajął na etapie wdrożenia.

Z doświadczenia: jeżeli firma planuje z enovy korzystać poważnie i przez kilka lat, sensowniej jest od razu wstawić SQL Server Standard (własny lub w licencji Runtime, którą Soneta udostępnia do enovy). Koszt licencji rozkłada się na lata, a potem nie trzeba robić migracji "pod presją", gdy baza przestanie się otwierać.

Dlaczego enova365 w wersji okienkowej nie działa wydajnie przez VPN

Wzorzec, który często spotykamy, wygląda tak: na każdym komputerze operatora zainstalowana jest enova365 w wersji okienkowej, a sam SQL Server stoi na serwerze w serwerowni. W biurze, przez lokalną sieć - działa dobrze. Schody zaczynają się, gdy pracownicy chcą się podpiąć z domu albo z drugiego oddziału, przez VPN.

Komunikacja klienta okienkowego z SQL Serverem odbywa się protokołem TDS (Tabular Data Stream), który nie jest zaprojektowany pod łącza WAN. Jest tak zwanym "chatty protocol" - jedno otwarcie okna z listą dokumentów potrafi wygenerować kilkadziesiąt round-tripów do serwera. Przy łączu lokalnym (RTT poniżej 1 ms) tego się nie zauważa. Przy VPN-ie z 30-40 ms opóźnienia - każde otwarcie listy to kilka sekund czekania zamiast ułamka. Zapisanie dokumentu, przebudowanie widoku, podgląd wydruku - to samo. Przy dłuższych dystansach i kiepskich łączach robi się praca bolesna.

Do tego dochodzi szyfrowanie VPN (dodaje narzut), zrywy połączenia, które potrafią zostawić wiszące transakcje, oraz pasmo - bo niektóre widoki i raporty pobierają megabajty danych. Da się tak pracować, ale nie jest to rozwiązanie produkcyjne dla całej firmy.

Wniosek jest prosty: klient okienkowy i SQL Server powinny się widzieć po LAN, z opóźnieniem liczonym w ułamkach milisekund. Jeżeli użytkownik jest fizycznie daleko, nie przybliżamy SQL-a do użytkownika - przybliżamy użytkownika do SQL-a.

Serwer terminali (RDS) dla enova365 - zalecana architektura dostępu zdalnego

Rozwiązanie, które dokumentuje sama Soneta i które sprawdza się dla większości instalacji z rozproszonymi użytkownikami, wygląda tak: w tej samej sieci, w której stoi SQL Server, uruchamiamy serwer terminali (Remote Desktop Services na Windows Server). Na nim instalujemy enovę365 w wersji okienkowej. Użytkownicy łączą się z serwerem terminali przez RDP (Pulpit Zdalny) - z biura, z domu, z oddziału.

Zalety takiej architektury:

Po pierwsze, ruch SQL zostaje w LAN. Użytkownik przez RDP przesyła tylko obraz ekranu i sygnały klawiatury - to niewielki ruch, który po RDP idzie płynnie nawet przy 30-50 ms opóźnienia i paśmie rzędu pojedynczych Mb/s. Aplikacja rozmawia z bazą po gigabitowej sieci wewnętrznej, więc odczuwalna wydajność jest taka sama, jakby pracownik siedział w biurze.

Po drugie, aktualizacja enovy oznacza aktualizację w jednym miejscu. Nie trzeba chodzić po kilkunastu komputerach i podnosić wersji klienta - aktualizujemy raz, na serwerze, i cała firma pracuje już na nowym buildzie.

Po trzecie, kontrola dostępu staje się znacznie prostsza. Uprawnienia do enovy zarządzamy przez role w samej enovie, ale to, kto w ogóle może się zalogować do serwera terminali, kontrolujemy na poziomie Active Directory. Przy odejściu pracownika wyłączamy konto AD i temat jest zamknięty - nie trzeba się martwić, że u kogoś został zainstalowany klient z zapisanymi parametrami połączenia.

Po czwarte, z perspektywy bezpieczeństwa RDP przez RD Gateway z TLS i MFA (albo RDP tunelowany przez VPN do dedykowanej sieci zarządzania) jest łatwiejszy do zabezpieczenia niż szerokie otwieranie portu SQL-a w firewallu.

Model ten - serwer SQL plus serwer aplikacji plus RDS - Soneta dokumentuje wprost jako jedną z zalecanych architektur hostingowych dla enovy.

Enova365 Multi czy wersja okienkowa - którą wybrać

Wersja Multi (webowa, HTML5) jest alternatywą albo uzupełnieniem powyższego schematu. Działa na serwerze IIS lub w trybie ASP.NET Core, a użytkownicy łączą się z nią przeglądarką - Chrome albo Edge. Producent deklaruje, że funkcjonalnie Multi daje niemal to samo co wersja okienkowa, i w bieżących wersjach enovy tak właśnie jest.

Gdzie Multi sprawdza się bardzo dobrze: akceptacje dokumentów przez menedżerów, pulpity pracownicze, CRM, rozliczenia delegacji, praca handlowców w terenie, podgląd raportów, praca mobilna. Wszędzie tam, gdzie sesja jest krótka i nie wymaga intensywnej pracy z klawiaturą na gęstych formularzach.

Gdzie wersja klasyczna często wygrywa w praktyce: dekretacja księgowa, szybkie wystawianie serii dokumentów, masowe edytowanie kart towarów, zaawansowana konfiguracja. Nie wynika to z braków funkcjonalnych Multi, tylko z przyzwyczajeń użytkowników i z tego, że klasyczny interfejs Windows Forms daje bardzo szybką nawigację skrótami klawiszowymi, które księgowe wykonują odruchowo po latach pracy. Tutaj trzeba uczciwie powiedzieć - to przede wszystkim kwestia subiektywnych preferencji. Część księgowych po przeniesieniu na Multi nie chce wracać, część kategorycznie nie zamierza zmieniać przyzwyczajeń.

Dobrą decyzją nie jest wybór "albo-albo". Można uruchomić oba interfejsy równocześnie, na tej samej bazie, i dać każdemu użytkownikowi narzędzie, w którym pracuje efektywnie. Księgowość zostaje na Standardzie na RDS, menedżer loguje się przez Multi z domu, handlowiec używa aplikacji mobilnej w aucie.

Podział serwerów pod enova365 - SQL, aplikacja i terminale osobno

Jeżeli decydujemy się na serwer terminali, pojawia się pokusa, żeby wszystko zrobić na jednej maszynie: SQL, aplikacja, RDS, domena, czasem jeszcze fileserver i backup. Dla mikrofirmy z paroma użytkownikami to działa. Dla SMB z dziesiątkami operatorów, księgowością i magazynem - zwykle się to źle kończy.

Model, który rekomendujemy w instalacjach powyżej kilkunastu użytkowników, to trzy osobne role (w praktyce najczęściej trzy maszyny wirtualne na jednym albo dwóch hostach, ale funkcjonalnie rozdzielone):

Serwer SQL. Dedykowany tylko bazie. Ma swoją pulę RAM, swoje dyski (najlepiej SSD w RAID1 albo RAID10, z osobnymi wolumenami na pliki danych, logi transakcyjne i backupy). Aktualizacje systemu operacyjnego i samego SQL-a planujemy niezależnie od reszty. Tutaj też jest sens włączać Standard Edition, jeżeli firma tego potrzebuje - płacimy za rdzenie tylko na jednej maszynie, nie na całym stosie.

Serwer aplikacji (enova365 Serwer). Logika biznesowa i - jeżeli używamy Multi - serwer interfejsu przeglądarkowego. Soneta w swoich wymaganiach zaleca wręcz, żeby serwer logiki biznesowej i serwer interfejsu użytkownika były na osobnych maszynach. W aktualnych wersjach enova365 opartych o .NET 8 wymagany jest Windows Server 2016 lub nowszy, 16 GB RAM i 4 rdzenie jako wartość startowa.

Serwer terminali (RDS). Zupełnie inny profil obciążenia - dużo pamięci per sesja, GPU dla wygody pracy, obsługa drukarek, przekierowanie urządzeń. Wydajność tej maszyny skaluje się z liczbą jednoczesnych użytkowników. Przy większych zespołach warto rozdzielić RDS na farmę z dwoma-trzema hostami i broker sesji.

Dlaczego segregacja odpowiedzialności opłaca się nawet w małej firmie? Kilka konkretnych powodów. Aktualizacja SQL Servera czy jego restart po aktualizacji bezpieczeństwa nie wymaga wyrzucania użytkowników z terminali - sesje zostają, tylko chwilowo nie działa enova. Restart RDS po aktualizacji nie dotyka logiki biznesowej i przez chwilę, gdy użytkownicy są wylogowani, i tak cała reszta systemu pracuje (na przykład integracje z bankowością czy e-commerce). Backup SQL Servera nie rywalizuje o dyski z profilami użytkowników na RDS. Jeżeli wąskim gardłem stanie się pamięć, widać od razu na której warstwie - i tę warstwę można skalować oddzielnie, bez konieczności powiększania całego monolitu.

Z perspektywy utrzymania jest to po prostu tańsze w dłuższym okresie, bo każda awaria zamyka się w swojej roli i nie pociąga za sobą pozostałych. Tę samą logikę stosujemy przy projektowaniu infrastruktury serwerowej dla większości klientów, niezależnie od tego, czy podstawowym obciążeniem jest enova, plikoserwer czy aplikacja branżowa.

Backup bazy enova365 - polityka, okres przechowywania i testy odtwarzania

Audyty u nowych klientów bardzo często pokazują jeden z poniższych scenariuszy:

• Backup istnieje, ale leży na tym samym dysku co baza danych.

• Backup istnieje, ale nikt od roku nie sprawdził, czy da się z niego odtworzyć.

• Na SQL Express ustawiono "backup" w Harmonogramie Zadań, który wywala się co drugi tydzień, bo zmienił się użytkownik serwisowy.

• Backupy są, ale przechowywane są tylko przez 7 dni i kiedy problem wychodzi po miesiącu (ktoś skasował dokumenty w grudniu, a zorientowano się w styczniu), nie ma do czego wracać.

• Backup Enovy robiony jest z poziomu aplikacji, ale plik .bak zostaje lokalnie i nigdy nie trafia do zewnętrznej lokalizacji.

Sensowna polityka nowoczesnego backupu dla instalacji enovy wygląda mniej więcej tak: pełny backup co noc, kopie różnicowe co kilka godzin, kopie logu transakcyjnego dla bazy w trybie FULL recovery (jeżeli zależy nam na odtwarzaniu do punktu w czasie). Pliki backupu trafiają na osobny wolumen, a stamtąd - na zewnętrzną lokalizację (NAS w innej lokalizacji, chmura, backup offsite). Okres przechowywania kopii dostosowujemy do przepisów i do rzeczywistych potrzeb - dla księgowości krótszy okres zwyczajnie się nie obroni. Okresowo, raz na miesiąc albo kwartał, wykonujemy testowy restore na drugą bazę i weryfikujemy, że system się podnosi. DBCC CHECKDB w regularnym harmonogramie, żeby nie obudzić się z uszkodzoną bazą, której nie da się odtworzyć, bo backupy od tygodnia zawierają już uszkodzenie.

Tego typu dyscyplinę trudno utrzymać bez kogoś, kto ma to wpisane w zakres obowiązków - stąd tak często backup jest pierwszą rzeczą, którą naprawiamy, przejmując wsparcie IT nowej firmy.

Aktualizacje enova365 i konwersja bazy danych - jak to robić bezpiecznie

Enova365 jest aktualizowana regularnie - nowe wersje wychodzą co kilka tygodni, a dodatkowo Soneta wydaje wersje "przepisowe", które trzeba wdrożyć w określonym terminie (KSeF, zmiany podatkowe, ZUS, PIT). Każda większa aktualizacja wymaga konwersji bazy danych - czyli migracji schematu do nowej wersji. Aktualizacje oprogramowania i patch management dla enovy mają więc odrębny charakter niż dla typowych aplikacji biurowych - nie da się ich zautomatyzować bezobsługowo.

Konwersja jest operacją, która dla dużej bazy może trwać od kilkunastu minut do kilku godzin, w czasie której praca na systemie nie jest możliwa. Producent wprost o tym informuje w komunikatach przy wydaniu wersji typu "wersja wymaga konwersji bazy danych".

Proces aktualizacji powinien wyglądać z grubsza tak:

To, co regularnie wywraca ten proces: dodatki partnerskie, które nie mają jeszcze wersji zgodnej z nową enovą; modyfikacje wykonane pod starszą wersję, które trzeba zaktualizować; brak backupu "tuż przed" konwersją i brak ścieżki powrotu. W przypadku większych aktualizacji warto robić próbną konwersję na kopii bazy, żeby zmierzyć czas i wyłapać problemy przed oknem produkcyjnym.

W firmach, w których prowadzimy obsługę informatyczną, aktualizacje enovy i ich konwersje są po prostu częścią harmonogramu - księgowa nie musi pilnować ich sama, a okno serwisowe planujemy z wyprzedzeniem, żeby wypadło poza terminem wysyłki deklaracji.

Po czym poznać dobrze utrzymaną infrastrukturę enova365

Z perspektywy zarządu firmy korzystającej z enovy wszystko, o czym pisaliśmy powyżej, jest detalami technicznymi, którymi nie powinien się zajmować. Firma kupiła enovę, żeby prowadzić księgowość, handel i magazyn, a nie żeby mieć kolejny projekt IT do nadzoru.

Dobrze utrzymana infrastruktura pod enovę wygląda następująco: ktoś monitoruje wydajność SQL-a i serwera aplikacji, zanim użytkownicy zauważą problem. Aktualizacje enovy, Windowsa, SQL Servera mają jeden spójny harmonogram i ktoś ponosi odpowiedzialność za to, że się dzieją. Backupy są robione, weryfikowane i jest procedura odtwarzania, którą ktoś naprawdę testował. Przy incydencie jest kogo wezwać i ten ktoś ma dostęp do środowiska oraz rozumie, jak to działa. Planowanie pojemności - dysków, RAM-u, licencji SQL - dzieje się zanim coś się skończy, nie po fakcie.

Taką pracę można robić samodzielnie, własnym działem IT, i w dużych organizacjach tak się dzieje. W małych i średnich firmach najczęściej nie ma osoby, która miałaby to wszystko na głowie obok swoich innych obowiązków - i wtedy sensowne jest oddanie tego na zewnątrz, w modelu outsourcingu IT. Obsługa informatyczna enovy nie jest przy tym czymś egzotycznym - to dokładnie ten sam zestaw zadań (serwery, aktualizacje, backupy, monitoring), który wykonuje się dla każdego poważnego systemu biznesowego, tylko z dodatkową znajomością specyfiki produktu Sonety.

Najczęstsze pytania o infrastrukturę enova365 (FAQ)

Czy SQL Server Express wystarczy do obsługi enova365?

Tak, ale tylko dla małych instalacji. SQL Server Express ma limit rozmiaru bazy 10 GB (50 GB w wersji 2025), 1410 MB buforu pamięci i może używać maksymalnie 4 rdzeni procesora. Dla mikrofirmy z kilkoma operatorami, która prowadzi jedną spółkę i nie obciąża systemu dużym wolumenem dokumentów, jest to rozwiązanie w zupełności wystarczające. Dla rozwijającej się firmy średniej wielkości limit 10 GB zostanie osiągnięty w ciągu 2-3 lat - i wtedy trzeba przejść na SQL Server Standard, najlepiej zanim baza fizycznie przestanie się otwierać.

Jakie wersje Microsoft SQL Server wspiera enova365?

Aktualnie wspierane są SQL Server 2016, 2017, 2019, 2022 oraz 2025 - zarówno w edycji Standard, jak i Express. Lista jest aktualizowana przez Sonetę i starsze wersje (2012, 2014) są stopniowo wycofywane. Dla nowych wdrożeń rekomendujemy najnowszą stabilną wersję SQL Servera, która jest wspierana przez producenta zarówno enovy, jak i Microsoft.

Czy enova365 w wersji okienkowej działa przez VPN?

Technicznie działa, ale praktycznie nie jest to rozwiązanie produkcyjne. Klient okienkowy komunikuje się z SQL Serverem protokołem TDS, który generuje bardzo dużo krótkich zapytań do bazy - przy opóźnieniu VPN rzędu 30-40 ms każde otwarcie listy, zapis dokumentu czy podgląd wydruku trwa kilka razy dłużej niż w LAN. Zamiast łączyć użytkownika z SQL-em przez VPN, lepszym wzorcem jest postawienie serwera terminali (RDS) w tej samej sieci co SQL - użytkownik łączy się wtedy przez RDP, a ruch bazodanowy pozostaje lokalny.

Czy wersja webowa enova365 (Multi) ma te same funkcje co wersja okienkowa?

Producent deklaruje, że funkcjonalnie wersja Multi odpowiada wersji okienkowej i w bieżących wydaniach enovy tak właśnie jest. Różnice są głównie ergonomiczne - w klasycznej wersji Windows Forms praca z klawiaturą jest szybsza, co doceniają zwłaszcza księgowe pracujące w skrótach. Multi wygrywa tam, gdzie ważna jest praca z dowolnego urządzenia i krótkie sesje (akceptacje, pulpity menedżerskie, CRM). Oba interfejsy można uruchomić równocześnie na tej samej bazie.

Ile trwa konwersja bazy danych przy aktualizacji enova365?

Od kilkunastu minut do kilku godzin - zależy od rozmiaru bazy, wykorzystywanych modułów i wydajności serwera SQL. Dla małej bazy (poniżej 1 GB) konwersja to zwykle kwestia kilku minut. Dla dużej bazy handlowej z wieloma latami historii i modułem DMS konwersja może zająć 2-4 godziny. Dlatego planujemy ją w oknie serwisowym poza godzinami pracy i zawsze wykonujemy pełny backup przed rozpoczęciem.

Czy trzeba rozdzielać SQL Server, serwer aplikacji enova365 i serwer terminali na osobne maszyny?

Dla mikrofirmy nie. Dla instalacji powyżej kilkunastu użytkowników - zalecamy podział. Osobne role (SQL, serwer aplikacji, RDS) pozwalają na niezależne skalowanie każdej warstwy, niezależne okna serwisowe, lepszą izolację przy awarii i prostsze rozpoznawanie wąskich gardeł wydajnościowych. Soneta w wymaganiach technicznych wprost zaleca osobne maszyny dla serwera logiki biznesowej i serwera interfejsu użytkownika.

Jak powinien wyglądać backup bazy enova365?

Pełny backup codziennie w nocy, kopie różnicowe lub logu transakcyjnego w ciągu dnia, pliki przechowywane w zewnętrznej lokalizacji (NAS offsite, chmura), okres przechowywania dostosowany do przepisów - dla księgowości często 12 miesięcy jako punkt wyjścia, choć ostateczny okres zależy od polityki firmy i wymagań branżowych. Kluczowe jest okresowe testowanie odtwarzania z backupu na drugą bazę - backup, którego nie sprawdzono, nie jest backupem. Dodatkowo warto uruchamiać regularne DBCC CHECKDB, żeby nie przechowywać kopii zawierającej uszkodzoną bazę.

Czy potrzebuję osobnego administratora do utrzymania enova365?

Dla pojedynczej instalacji enovy w małej firmie pełnoetatowy administrator nie jest potrzebny. Potrzebna jest natomiast osoba albo firma, która ma wpisane w zakres obowiązków: monitorowanie serwera SQL, regularne aktualizacje enovy i systemu operacyjnego, backupy i ich testowanie, reakcję na incydenty. Może to być wewnętrzny informatyk, obsługujący również inne systemy w firmie, albo zewnętrzny zespół w modelu outsourcingu IT - w większości firm średniej wielkości ten drugi wariant wychodzi taniej i daje lepszą ciągłość przy urlopach czy rotacji personelu. Kluczowe jest to, że temat ma konkretnego właściciela, a nie że leży "po stronie księgowej, która zna enovę".

Czy enova365 wymaga Windows Server na serwerze aplikacji?

Nie jest to wymóg sztywny - Soneta oficjalnie wspiera uruchomienie serwera aplikacji enova365 zarówno na Windows Server, jak i na Linuksie (w tym w kontenerach Docker i Kubernetes). Architektura enovy opiera się o .NET 8, który jest wieloplatformowy. Wariant linuksowy jest technicznie wspierany, ale rzadko stosowany w klasycznych wdrożeniach SMB - standardem pozostaje Windows Server 2016 lub nowszy, jako najlepiej opisany w dokumentacji, najczęściej spotykany u partnerów wdrożeniowych i najprostszy w utrzymaniu. Linuksowy serwer aplikacji widujemy głównie tam, gdzie firma idzie świadomie w stronę Cloud Native. Niezależnie od wyboru platformy serwera - klient okienkowy (wersja Standard) działa wyłącznie na Windows.

Co to jest licencja SQL Server Runtime dla enova365?

To specjalna licencja SQL Server Standard, którą Soneta udostępnia klientom enovy w cenie niższej niż standardowa licencja Microsoft, pod warunkiem że SQL Server używany jest wyłącznie do obsługi enovy. Jest to wygodny sposób na ominięcie limitów Express bez ponoszenia pełnego kosztu licencji SQL Server Standard kupowanej bezpośrednio u Microsoft. Szczegóły warunków licencji warto potwierdzić u Autoryzowanego Partnera Sonety.

Jak wygląda nasza obsługa IT dla firm korzystających z enova365

W Helpwise IT zajmujemy się obsługą informatyczną firm, które używają enovy365 jako systemu ERP. W praktyce znaczy to, że bierzemy odpowiedzialność za środowisko - serwery, SQL-a, RDS-y, backupy, aktualizacje, reakcję na incydenty - tak, żeby od strony klienta widać było tylko to, że system działa i że po wyjściu nowej wersji KSeF nikt nie musi nerwowo dzwonić w sprawie terminu.

Utrzymanie enovy nie jest u nas "dodatkiem za ekstra cenę". Wdrożenia, aktualizacje, wymiana dysku, migracja na nowy serwer czy przygotowanie środowiska pod kolejny oddział są wliczone w stałą opłatę za obsługę IT. Nazywamy to "bateriami w zestawie" - i traktujemy jako model, który jest uczciwy wobec klienta: umowa jest jedna, budżet przewidywalny, a my nie zarabiamy na tym, że coś się psuje.

Jeżeli rozpoznajecie któryś z opisanych wyżej scenariuszy - rozproszona praca przez VPN po SQL-u, baza zbliżająca się do 10 GB na Expressie, backup, którego nikt od dawna nie testował, aktualizacja odkładana, bo "ostatnio wyszło źle" - to jest dokładnie ten moment, w którym warto usiąść i przejrzeć środowisko z kimś z zewnątrz. Niezależnie od tego, czy skończy się to pełnym przejęciem obsługi IT, czy tylko jednorazowym wsparciem IT przy uporządkowaniu infrastruktury - zwykle łatwiej się potem rozmawia, gdy środowisko jest przewidywalne.