Niewydolność dotychczasowych systemów, rozwój firmy (w tym wejście w nowe obszary działalności), pojawiające się nowe rozwiązania i możliwości automatyzacji procesów, zakończenie obsługi przez dotychczasowego wytwórcę oprogramowania, potrzeba integracji danych i procesów, konieczność integracji w ramach grupy kapitałowej - to przykłady przesłanek mogących uzasadniać wymianę systemu finansowo-księgowego (FK). Zmiana taka nie następuje z dnia na dzień. Jest to pewien proces, początkowo decyzyjny, później także techniczny i zazwyczaj trwa on minimum kilka miesięcy. Przyjrzyjmy się poszczególnym etapom - poczynione wskazówki pomogą uporządkować to niełatwe przedsięwzięcie i uniknąć pewnych błędów czy niepotrzebnych kosztów.
Badając zasadność wymiany systemu finansowo-księgowego na inny w pierwszej kolejności należy dokładnie rozpoznać i zinwentaryzować to, co aktualnie użytkowane jest w jednostce. W szczególności powinno się ustalić, jakie oprogramowanie jest stosowane i jakie procesy obsługuje. Jeżeli nie posiadamy systemu zintegrowanego klasy ERP, to najpewniej poszczególne prowadzone komputerowo księgi rachunkowe są rozproszone i posiadają własne, odrębne bazy danych, być może obsługiwane przez różne tzw. silniki baz danych. Przykładowo osobne (niezintegrowane ze sobą) jest wówczas oprogramowanie FK, magazynowe, kadrowo-płacowe, moduł zarządzania produkcją itp. Dokładna inwentaryzacja tego oprogramowania, ze wskazaniem, jakie typy baz danych użytkuje i gdzie one się znajdują, może ułatwić prace na dalszych etapach. Warto wspomnieć, że stale aktualizowany wykaz zbiorów (plików baz danych) tworzących księgi rachunkowe powinien znajdować się w polityce rachunkowości jednostki, wraz z określeniem ich struktury, wzajemnych powiązań oraz ich funkcji w organizacji całości ksiąg rachunkowych i w procesach przetwarzania danych (por. art. 10 ust. 1 pkt 3 ustawy o rachunkowości).
To bardzo ważny etap, bowiem od identyfikacji potrzeb (czyli precyzyjnych odpowiedzi na pytania "czego nie ma, a co byśmy chcieli, by było") zależeć będzie trafność doboru nowego oprogramowania, zakresu modułów jakie pozyskamy, niezbędnego sprzętu, konfiguracji sieci i licencji towarzyszących. Wśród przykładów zidentyfikowanych potrzeb (które oczywiście mogą występować łącznie) można wymienić:
Po zidentyfikowaniu potrzeb niekiedy warto wykonać jeszcze jeden krok - tzn. upewnić się, że nie jest możliwe osiągnięcie tych zamierzeń przy wykorzystaniu obecnie użytkowanego oprogramowania. Być może służby finansowo-księgowe nie wykorzystują pewnych funkcjonalności (z niewiedzy o ich istnieniu lub z przyzwyczajenia) bądź też wystarczające okaże się dokupienie pewnych modułów bądź zlecenie dotychczasowemu dostawcy oprogramowania pewnych prac dostosowawczych czy integracyjnych. Pamiętać należy, że wymiana oprogramowania jest procesem kosztownym (to koszt nie tylko licencji, ale i wdrożenia, testowania, czy szkoleń) oraz niosącym za sobą pewne ryzyka.
Mając zidentyfikowane potrzeby oraz orientacyjny, dopuszczalny budżet przedsięwzięcia możemy przystąpić do analizy dostępnych na rynku rozwiązań. Warto zapoznać się z ofertami wielu dostawców - zidentyfikować moduły jakie oferują, sprawdzić czy są dostępne interesujące nas funkcje (np. służące do automatycznego wyliczania różnic kursowych), sprawdzić czy producent oferuje usługi integracji nabytej platformy programowej z innymi systemami (np. ze wspomnianymi już platformami handlu internetowego). Dane te w początkowej fazie procesu decyzyjnego można pozyskać ze stron internetowych dostawców oraz ze wstępnych rozmów z nimi. Można spróbować także zasięgnąć opinii o oprogramowaniu np. u któregoś z użytkujących je naszych kontrahentów.
Elementem rozpoznania rynku jest też poziom cen. Te mogą się bardzo istotnie różnić, oferując podobne funkcjonalności. Należy sprawdzić ceny zarówno samych licencji na interesujące nas moduły, jak i kosztów dodatkowych stanowisk, kosztów opieki posprzedażowej, kosztów aktualizacji, licencji towarzyszących itp. Niekiedy obserwuje się sytuacje nabywania przez jednostki przeskalowanej w stosunku do potrzeb szeroko rozumianej infrastruktury informatycznej, która następnie wykorzystywana jest w znacząco mniejszym zakresie. Czy przykładowo w firmie zatrudniającej kilku pracowników warto nabywać moduł kadrowo-płacowy? Prawdopodobnie rozsądniejszym rozwiązaniem będzie outsourcing takiej usługi.
Dostawcy zazwyczaj oferują wersje demonstracyjne oprogramowania - warto uzyskać do nich dostęp i zapoznać się z tym, z czym być może jednostka będzie pracować przez lata. Można zwrócić uwagę na ergonomię interfejsu - jakkolwiek znaczenie ręcznego wprowadzania danych będzie wobec postępującej automatyzacji malało, to jednak wciąż pozostaje to czynnikiem istotnym. Nie bez znaczenia jest też łatwość obsługi (mierzona np. tym, czy służby finansowo-księgowe będą w stanie po przeszkoleniu samodzielnie zdefiniować nową lub zmodyfikować istniejącą definicję dekretu lub typ dokumentu bez konieczności każdorazowego angażowania pracowników twórcy oprogramowania) i szeroko rozumiana elastyczność.
Najważniejszymi czynnikami branymi pod uwagę przy wyborze konkretnej oferty będzie adekwatność proponowanych rozwiązań do zgłoszonych potrzeb oraz koszty licencji i wdrożenia. Nie są to bynajmniej czynniki jedyne.
Warto zwrócić uwagę na to, czy dostawca oprogramowania oferuje usługę migracji danych, a jeśli tak, to w jakim zakresie oraz jaka byłaby cena takiej usługi (a koszty są niemałe, zwłaszcza gdy dotychczasowe i nowe oprogramowanie działa na innych silnikach baz danych). Możliwe są następujące modele konwersji:
Wybór będzie wypadkową tych wszystkich, a także wcześniej wspomnianych czynników: oferowanych funkcjonalności, kosztów licencji, wdrożenia, aktualizacji, oferty w zakresie migracji, szkoleń i opieki powdrożeniowej, niezbędnych inwestycji w hardware, łatwości obsługi i innych. Decyzja powinna być podjęta przez kierownictwo jednostki przy współudziale informatyków oraz osób zarządzających sferą finansowo-księgową jednostki, oraz przy wskazanym współudziale kierowników działów mających użytkować poszczególne moduły.
Jest to etap pracy od podstaw, tzn. dobór, zakup, dostawa i konfiguracja serwerów, zestawów komputerowych, urządzeń wejścia i wyjścia, urządzeń sieciowych i towarzyszących. Na tym etapie następuje instalacja i integracja wymaganych baz danych i oprogramowania aplikacyjnego, a także integracja sieci.
Po wykonaniu usprzętowienia i zainstalowaniu wymaganego oprogramowania rozpoczyna się etap związany z konfiguracją i parametryzacją oprogramowania do potrzeb użytkownika. Bardzo istotne znaczenie będzie tu mieć dokładny opis procesów gospodarczych, jakie występują w jednostce. To zazwyczaj w oparciu o ten dokument konfigurowane są stanowiska z przypisanymi modułami, schematy udostępniania, kontroli i akceptacji dokumentów, tworzone są algorytmy przetwarzania danych. Czas trwania i koszt tego etapu są proporcjonalne do stopnia złożoności procesów gospodarczych w jednostce, dlatego może on być czasochłonny. Dostawcy oprogramowania mają wypracowane własne procedury postępowania. Implementowane funkcjonalności są tu (powinny być) wielopłaszczyznowo testowane (testy "przejścia przez przykład").
Odrębnym etapem wdrożenia będzie migracja danych. Jeśli alokowane do nowej bazy danych mają być nie tylko słowniki, ale także zapisy ksiąg z okresów sprzed wdrożenia, to niezbędne jest przeprowadzenie testów przeliczeń - chodzi o to, czy np. zestawienie obrotów i sald za dowolny okres wygenerowane przy użyciu dotychczasowego oprogramowania i oprogramowania nowego będzie dokładnie takie samo. I tu dochodzimy do bardzo istotnej kwestii: otóż nawet, jeśli przeniesione do nowego oprogramowania będą całe zbiory danych tworzące księgi za okresy wcześniejsze, z możliwością generowania z nich kart kontowych czy zestawień obrotów i sald, to ma to tylko znaczenie ułatwiające dostęp do starszych danych. Księgami rachunkowymi za okresy sprzed wdrożenia nowego oprogramowania pozostają bowiem zbiory utworzone i zaksięgowane wówczas (choćby dlatego, że utworzono je za pomocą dotychczasowego oprogramowania, którego nazwa powinna widnieć na wydrukach (por. art. 13 ust. 4 pkt 1 ustawy o rachunkowości). Jeżeli zatem nie zamierzamy utrzymywać dotychczasowego oprogramowania w stanie umożliwiającym odczyt ksiąg przez okres wymagany w rozdziale 8 ustawy o rachunkowości, to księgi te należy przenieść na trwały nośnik danych lub wydrukować, zabezpieczyć i zarchiwizować.
Jeśli migracji będą podlegały tylko dane słownikowe, to należy wygenerować je w postaci, jakiej wymaga integrator. Tu przydatna będzie wspomniana wcześniej inwentaryzacja posiadanych zasobów - dane do słowników mogą znajdować się w różnych bazach. Pamiętać należy o przestrzeganiu zasad związanych z udostępnieniem danych osobowych podmiotowi trzeciemu (jeśli migrujemy np. słownik pracowników).
Po skonfigurowaniu i sparametryzowaniu oprogramowania, w tym po utworzeniu wzorców dokumentów i definicji dekretów można przystąpić do etapu testowania wdrożenia pod kątem działania jako całości - chodzi o szeroko pojętą poprawność przetwarzania i udostępniania danych. Ten etap realizuje jeszcze dostawca, choć oczywiście mogą w nim uczestniczyć osoby z jednostki, zgłaszając na bieżąco swoje uwagi. Powinno się tu przetestować poszczególne procesy, np. w jednostce handlowej od przyjęcia zamówienia i jego zatwierdzenia, przez etap zaliczkowania, dostawy i fakturowania, rozchodu z magazynu i jego wyceny z uwzględnieniem przyjętej metody, rozliczenia należności, emisji danych do właściwych plików JPK.
Po wykonaniu szczegółowych, całościowych testów i uzyskaniu ich pozytywnego rezultatu, zarząd podejmuje decyzję o przyjęciu oprogramowania do stosowania, określając datę rozpoczęcia użytkowania całości lub określonych modułów w wyznaczonych sekwencjach czasowych (wskazane jest by było to począwszy od pierwszego dnia miesiąca) i dokonując stosownych zmian w polityce rachunkowości w obszarze określonym w art. 10 ust. 1 pkt 3 i 4 ustawy o rachunkowości. Zmiana oprogramowania nie jest zmianą stosowanych zasad rachunkowości, dlatego nie musi następować z pierwszym dniem roku obrotowego (chyba że wraz ze zmianą oprogramowania modyfikuje się zasady wyceny, np. towarów z metody FIFO na średnioważoną).
W okresie przed przyjęciem oprogramowania do używania należy oczywiście odpowiednio wcześniej przeszkolić użytkowników i udostępnić im stosowne instrukcje obsługi.
W momencie rozpoczęcia użytkowania wdrożonego oprogramowania przez przeszkolonych użytkowników zaczyna się etap powdrożeniowy. Pierwsze miesiące możemy określić jako etap eksploatacji nadzorowanej. Obarczony jest on ryzykiem, którego poziom zależy od jakości wdrożenia i stopnia przeszkolenia kadry. Na tym etapie należy notować wszelkie dostrzeżone anomalie, błędy, niekompletności transferów, niezamierzone blokady dostępów, awarie i zawieszenia się oprogramowania (określmy je zbiorczym mianem incydentów). Warto stworzyć ewidencję takich incydentów, gdzie użytkownicy poszczególnych stanowisk zamieszczaliby datę, miejsce i okoliczności wystąpienia oraz ich naturę (skutek). Niektóre błędy będą musiały być usuwane na bieżąco przez dostawcę oprogramowania, a inne - o niekrytycznym znaczeniu - będą zgłaszane pakietami podczas kolejnych wizyt zespołu wdrożeniowego.
Na tym etapie użytkownicy raportów generowanych przez nowo wdrożony system powinni zachować stosowną dozę krytycyzmu i ostrożności (z uwagi na wspomniane podwyższone ryzyko etapu zaraz po wdrożeniu). Przykładowo przed wysłaniem do urzędu skarbowego pierwszego wygenerowanego przez nowy system pliku JPK_VAT z deklaracją warto sprawdzić w szczególności:
Z przeprowadzanych w tym trybie procedur kontrolnych zasadne jest sporządzanie notatek służbowych i załączanie ich do dokumentacji związanej z wdrożeniem.
Nie należy oczekiwać, że nowo wdrożony system będzie od razu działał bez incydentów. Będą one następstwem nie tyle niestarannego wdrożenia, co raczej złożoności stworzonych powiązań, relacji i algorytmów lub niedostatecznego przeszkolenia, które tak naprawdę w istotnym zakresie odbywa się na już użytkowanym oprogramowaniu, którego wszyscy dopiero się uczą.
| ||||||||||||
|
||||||||||||
