Przy enova365 dobrze od początku rozdzielić dwie sprawy. Konfiguracja merytoryczna — moduły, uprawnienia, schematy — to praca partnera wdrożeniowego. Środowisko, na którym to wszystko ma działać, czyli sprzęt, system, sieć, baza i kopia, to nasza część. Problemy zaczynają się wtedy, gdy nikt nie zajął się tą drugą.

Gdzie stoi baza

enova365 pracuje na serwerze bazy danych i to on decyduje o wydajności całości. W małej firmie spotyka się instalację na jednym z komputerów pracowniczych albo na osobnym urządzeniu. Drugi wariant proponujemy zawsze, gdy z programu korzysta więcej niż dwie osoby — nie ze względu na moc, tylko na dostępność.

Komputer z bazą nie może być usypiany ani wyłączany o końcu dnia. Ustawiamy zasilanie na pracę ciągłą, wyłączamy wygaszanie i tłumaczymy zespołowi, dlaczego tego sprzętu się nie dotyka. To brzmi banalnie, a jest najczęstszą przyczyną porannego zgłoszenia „program nie startuje”.

Dysk i pamięć

Baza danych jest wrażliwa przede wszystkim na dysk. Talerzowy nośnik pod bazą to najczęstsza przyczyna narzekań na wolne działanie programu — i najprostsza do usunięcia. Przesiadka na dysk półprzewodnikowy daje efekt większy niż jakakolwiek inna pojedyncza zmiana.

Drugim czynnikiem jest pamięć na komputerze z bazą. Serwer bazy trzyma w niej dane, do których sięga się najczęściej; przy jej niedoborze zaczyna czytać z dysku i wszystko zwalnia. Sprawdzamy realne zużycie podczas pracy firmy, a nie o ósmej rano przy pustym programie.

Sieć

Stanowiska pracujące na bazie łączymy kablem. Sieć bezprzewodowa przy pracy na bazie danych daje zrywane sesje i błędy zapisu, których przyczyny szuka się potem godzinami w samym programie. Komputer z bazą musi mieć stały adres — ustawiony ręcznie albo przypisany na stałe przez router.

Zapora systemowa na komputerze z bazą musi przepuszczać ruch do serwera bazy. To druga najczęstsza przyczyna zgłoszeń „stanowisko nie widzi programu”, zaraz po adresacji.

Kopia bazy

Kopiowanie plików bazy przy działającej usłudze daje plik, którego zwykle nie da się odtworzyć. Kopia musi być wykonywana mechanizmem serwera bazy, zapisywana poza tym komputerem i — co najważniejsze — sprawdzana przez odtworzenie. Kopia, z której nikt nigdy nic nie odtworzył, nie jest zabezpieczeniem.

Przy firmach, w których program obsługuje kadry i płace, zwracamy uwagę na to, żeby kopia obejmowała wszystkie bazy, a nie tylko główną. To pomyłka, która wychodzi w najgorszym momencie.

Zasilanie awaryjne

Nagłe wyłączenie komputera z bazą w trakcie zapisu potrafi uszkodzić bazę tak, że jej odtworzenie zajmie więcej czasu niż jakakolwiek naprawa sprzętu. Urządzenie podtrzymujące zasilanie przez kilkanaście minut i zamykające system poprawnie traktujemy przy takich instalacjach jako element obowiązkowy.

Praca zdalna

enova365 bywa udostępniana pracownikom pracującym z domu. Robimy to przez zabezpieczone połączenie z siecią firmy, a nie przez wystawienie zdalnego pulpitu wprost do internetu — ta druga droga jest jedną z najczęstszych przyczyn poważnych incydentów w małych firmach.

Aktualizacje

Wersje programu na stanowiskach i na serwerze muszą się zgadzać. Aktualizację planujemy poza okresem rozliczeniowym, po wykonaniu kopii i tak, żeby objęła wszystkie stanowiska za jednym razem. Zostawienie jednego komputera ze starą wersją oznacza pracownika, który nie może się zalogować, i telefon następnego ranka.

Podział odpowiedzialności

Mówimy jasno, gdzie kończy się nasz zakres: nie konfigurujemy modułów, nie ustawiamy schematów księgowych i nie doradzamy w sprawach kadrowych. Zajmujemy się warstwą, na której program stoi. Gdy zgłoszenie dotyczy działania samego programu, wskazujemy partnera wdrożeniowego — i odwrotnie, gdy partner mówi, że „to sprzęt”, wchodzimy my.

Taki podział, ustalony na początku współpracy, oszczędza firmie odsyłania od jednych do drugich w momencie, gdy coś nie działa.

Wersja przeglądarkowa i wersja instalowana

Program bywa udostępniany na dwa sposoby: jako aplikacja instalowana na stanowisku albo przez przeglądarkę. Każdy z nich stawia inne wymagania. Wersja przeglądarkowa wymaga serwera obsługującego takie połączenia i przenosi obciążenie na stronę serwera; wersja instalowana wymaga zgodnych wersji na wszystkich stanowiskach.

Ustalamy to na początku, bo od tego zależy cała reszta przygotowań — od mocy komputera z bazą po sposób udostępnienia programu pracownikom zdalnym.

Konta użytkowników i licencje

Liczba jednoczesnych sesji bywa ograniczona licencją. Objawia się to komunikatem o braku wolnych licencji, który pojawia się zwykle wtedy, gdy ktoś nie wylogował się przed wyjściem, a nie wtedy, gdy faktycznie pracuje komplet osób.

Ustawiamy automatyczne kończenie nieaktywnych sesji i pokazujemy zespołowi, że zamknięcie okna to nie to samo co wylogowanie. To zgłoszenie, które potrafi wracać co tydzień, dopóki nikt tego nie wytłumaczy.

Wydruki i szablony dokumentów

Firmy modyfikują szablony faktur i dokumentów magazynowych pod własne potrzeby. Przy migracji na nowy serwer albo przy aktualizacji te modyfikacje trzeba przenieść osobno — nie idą razem z bazą.

Robimy ich kopię przed każdą większą zmianą. Odtwarzanie ich później, na podstawie pamięci pracowników, bywa pracą na kilka godzin.

Integracje z innymi systemami

Program bywa spięty ze sklepem internetowym, z bankiem, z systemem kurierskim albo z platformą sprzedażową. Każda z tych integracji ma własne wymagania co do wersji i własny sposób uwierzytelniania.

Po aktualizacji sprawdzamy je po kolei, bo to właśnie one najczęściej przestają działać — a objaw pojawia się dopiero przy pierwszym zamówieniu albo pierwszym przelewie.

Monitorowanie bazy

Przy większych instalacjach warto obserwować rozmiar bazy, czas wykonywania kopii i wolne miejsce na dysku. Baza rosnąca szybciej niż zwykle bywa objawem problemu — na przykład niekontrolowanego przyrostu dziennika transakcji.

Ustawiamy proste powiadomienia o kończącym się miejscu. Zapełniony dysk pod bazą to jedna z najbardziej gwałtownych awarii, jakie mogą spotkać firmę w środku dnia pracy.

Plan na wypadek awarii serwera

Ustalamy, co dzieje się, gdy komputer z bazą przestaje działać: skąd odtwarzamy kopię, na jakim sprzęcie, ile to potrwa i kto w firmie może podjąć decyzję. Przy dobrze przygotowanym planie odtworzenie to godziny, a nie dni.

Przy stanowiskach krytycznych proponujemy trzymanie sprawdzonego komputera poleasingowego jako zapasu. Kosztuje ułamek tego, co dzień przestoju księgowości na przełomie miesiąca.

Podział ról

Konfiguracja modułów, uprawnienia merytoryczne i schematy księgowe to praca partnera wdrożeniowego. Sprzęt, system, sieć, baza, kopia, aktualizacja techniczna i praca zdalna — to nasza część. Ten podział ustalamy na starcie, żeby w dniu awarii nikt nie odsyłał firmy do kogoś innego.

Fakturę wystawiamy zawsze, a wycenę podajemy przed rozpoczęciem pracy. Telefon odbieramy całą dobę, co przy programach księgowych ma znaczenie w ostatnich dniach miesiąca.

Środowisko testowe obok produkcyjnego

Firmy, które często zmieniają konfigurację albo pracują na integracjach, zyskują na posiadaniu osobnej kopii środowiska do testów. Sprawdza się na niej aktualizacje, nowe szablony i zmiany w integracjach, zanim trafią do pracy.

Nie wymaga to osobnego serwera — wystarczy odtworzona kopia bazy pod inną nazwą i oznaczone stanowisko. Ważne jest tylko, żeby nikt nie pomylił środowisk, dlatego wyraźnie je oznaczamy.

Powiązane teksty