Wdrożenie oprogramowania w Poznaniu - szkolenia użytkowników i odbiór

Wdrożenie oprogramowania poza instalacją

Instalacja programu na serwerze zajmuje godziny, a wdrożenie oprogramowania w firmie trwa tygodnie albo miesiące. Różnicę wypełnia praca, której nie widać w instalatorze: dopasowanie konfiguracji do procesów, przeniesienie danych, a także przygotowanie ludzi i formalny odbiór. Wdrożenie kończy się wtedy, gdy użytkownicy wykonują codzienne zadania w nowym systemie, a nie wtedy, gdy program się uruchomi.

Ta strona opisuje cztery etapy po stronie firmy: migrację danych i szkolenia, a następnie uruchomienie wraz z odbiorem. Analizę przed projektem opisuje osobny tekst o analizie przedwdrożeniowej, a szczegóły importu danych do systemu klasy ERP przedstawia strona o wdrożeniu systemu ERP i migracji danych.

Model instalacji a zakres prac

Oprogramowanie lokalne instaluje się na serwerach firmy, a oprogramowanie w chmurze działa u dostawcy w modelu subskrypcji. Wybór modelu zmienia listę zadań wdrożeniowca oraz podział odpowiedzialności za dane.

Programy lokalne dają większą kontrolę nad infrastrukturą, ale wymagają jednorazowej inwestycji i własnych administratorów. Rozwiązania chmurowe upraszczają start, za to wprowadzają stałą opłatę i zależność od dostępności łącza. Porównanie kosztów w konkretnym scenariuszu magazynowym przedstawia strona o licencji i modelu SaaS w oprogramowaniu magazynowym.

Licencje i legalność oprogramowania

Każdy program używany w firmie wymaga licencji zgodnej ze sposobem użycia, a nielegalne kopie narażają przedsiębiorstwo na konsekwencje prawne i finansowe. Najbezpieczniej kupować licencje od producenta albo autoryzowanego dostawcy i przechowywać dowody zakupu. Wdrożeniowiec sprawdza na początku, czy liczba licencji odpowiada liczbie użytkowników, bo audyt po uruchomieniu kosztuje więcej niż korekta przed nim.

System dedykowany a produkt gotowy

Produkt gotowy ma stały zakres funkcji, więc wdrożenie polega głównie na konfiguracji i szkoleniu. System dedykowany powstaje pod wymagania klienta, dlatego wdrożenie obejmuje także odbiór funkcji, których nie ma w żadnym standardzie. SoftwareStudio tworzy oba rodzaje rozwiązań, a różnice w podejściu do zakresu opisuje strona o wdrożeniu systemu WMS.

Środowiska i konfiguracja przed startem

Nowy system nie trafia od razu na serwer produkcyjny. Wdrożenie prowadzi się na osobnych środowiskach, z których każde ma inne zadanie i inny zestaw danych.

Środowisko szkoleniowe nie może współdzielić bazy z produkcyjnym, bo pomyłka użytkownika na ćwiczeniu zmieniłaby dane rzeczywiste. Rozdzielenie środowisk opłaca się nawet w małej firmie, gdyż koszt drugiej instancji SQL Server jest niski wobec kosztu pomyłki.

Konta serwisowe i uprawnienia

Aplikacja łączy się z bazą przez konto serwisowe, któremu nadaje się tylko potrzebne uprawnienia. Przykład poniżej pokazuje konto domenowe z prawem odczytu i zapisu w jednej bazie; nazwy są ilustracją, a nie schematem konkretnego produktu.

CREATE LOGIN [FIRMA\svc_aplikacja] FROM WINDOWS;
GO
USE BazaAplikacji;
CREATE USER [FIRMA\svc_aplikacja] FOR LOGIN [FIRMA\svc_aplikacja];
ALTER ROLE db_datareader ADD MEMBER [FIRMA\svc_aplikacja];
ALTER ROLE db_datawriter ADD MEMBER [FIRMA\svc_aplikacja];

Reguła: konto serwisowe aplikacji nie należy do roli sysadmin, bo błąd w kodzie albo wstrzyknięcie SQL uzyskałoby wtedy pełną władzę nad serwerem.

Model uprawnień w bazie opisuje dokumentacja Microsoft o uprawnieniach silnika bazy danych. Opieka nad samym serwerem po wdrożeniu należy do zakresu opisanego w katalogu usług IT dla firm.

Integracje z innymi systemami przed startem

Nowy system rzadko działa w izolacji: wymienia dane z ERP, z zewnętrznymi usługami albo z urządzeniami. Przed uruchomieniem sprawdza się każde połączenie na środowisku testowym, razem z otwartymi portami i ważnością certyfikatów oraz kluczy dostępu. Awaria integracji po starcie objawia się niepełnymi dokumentami, więc test obejmuje pełną ścieżkę dokumentu, a nie tylko dostępność usługi. Wymianę danych z systemem magazynowym opisuje strona o integracji WMS z ERP.

Migracja danych ze starego systemu

Dane z poprzedniego rozwiązania decydują o tym, czy użytkownicy zaufają nowemu systemowi. Pierwsze pytanie brzmi, co w ogóle przenosić: kartoteki i salda otwarte zwykle tak, a historię wieloletnich dokumentów często zostawia się w archiwum do odczytu.

Zakres danych do przeniesienia

Zakres ustala się razem z właścicielami procesów. Przenoszenie całej historii wydłuża okno migracji i zwiększa liczbę błędów, a rzadko przynosi korzyść operacyjną. Poczta elektroniczna też jest zasobem do zabezpieczenia: do archiwizacji korespondencji z Microsoft 365 służy między innymi MailStore Server, który pozwala odnaleźć wiadomości po wyłączeniu starych skrzynek.

Import i kontrola liczebności

Dane z plików CSV ładuje się do tabel przejściowych, a dopiero po kontroli przenosi do tabel docelowych. Poniższy fragment używa polecenia BULK INSERT w wariancie CSV, dostępnym od SQL Server 2017, i od razu zlicza wczytane wiersze.

BULK INSERT dbo.kontrahenci_import
FROM 'D:\migracja\kontrahenci.csv'
WITH (FORMAT = 'CSV', FIRSTROW = 2, FIELDTERMINATOR = ';',
      CODEPAGE = '65001', TABLOCK);

SELECT COUNT(*) AS wierszy_w_imporcie
FROM dbo.kontrahenci_import;

Liczba wierszy w imporcie musi zgadzać się z liczbą rekordów w pliku źródłowym, pomniejszoną o wiersz nagłówka. Rozbieżność wskazuje na błędnie zakodowane znaki lub uszkodzone linie, dlatego import powtarza się do skutku jeszcze przed testami użytkowników. Opis mechanizmów masowego ładowania znajduje się w dokumentacji Microsoft o imporcie i eksporcie danych.

Migracja próbna

Zanim wykona się import ostateczny, przeprowadza się co najmniej jedną migrację próbną na kopii danych. Próba pokazuje, ile trwa każdy etap, jakie rekordy odrzuca walidacja i czy okno migracji mieści się w planowanej przerwie. Wyniki próby trafiają do harmonogramu przełączenia, więc godziny w liście kontrolnej opierają się na pomiarach, a nie na szacunku.

Okno migracji i punkt bez powrotu

Ostateczny import wykonuje się w oknie, w którym stary system jest zamknięty do zapisu. Od chwili, gdy użytkownicy zaczną wprowadzać dokumenty do nowego systemu, powrót do starego oznacza ręczne przenoszenie danych w drugą stronę. Dlatego moment ten ustala się z góry i poprzedza go pełna kopia bazy.

Szkolenia użytkowników przed uruchomieniem

Szkolenie ma przygotować do pracy, a nie omówić wszystkie funkcje programu. Materiał dzieli się według roli, ponieważ inne czynności wykonują magazynier oraz księgowa, a inne administrator. Szkolenie prowadzi się na środowisku szkoleniowym, z danymi zbliżonymi do rzeczywistych, żeby ćwiczenia wyglądały jak zwykły dzień pracy.

Scenariusze ćwiczeń i instrukcje

Ćwiczenia opiera się na scenariuszach z prawdziwej pracy: przyjęcie dokumentu i jego korekta oraz wydruk i raport. Każdy uczestnik wykonuje scenariusz samodzielnie, a prowadzący notuje miejsca, w których pojawia się pytanie. Te miejsca trafiają do instrukcji stanowiskowej jako opisane przypadki. Pomoc w programie oraz asystent kontekstowy opisany na stronie o asystencie użytkownika programu uzupełniają szkolenie po jego zakończeniu.

Osoby wspierające po starcie

W każdym dziale wyznacza się jedną osobę, która przeszła szkolenie pogłębione i odpowiada na pytania współpracowników w pierwszych tygodniach. Taka osoba skraca kolejkę do zespołu wdrożeniowego, ponieważ większość pytań dotyczy podstawowych czynności. Rolę zespołu po stronie dostawcy opisuje strona o roli zespołów wdrożeniowych w projekcie.

Uruchomienie produkcyjne i plan wycofania

Uruchomieniem produkcyjnym zarządza się jak zdarzeniem zaplanowanym co do godziny. Przed nim zespół sprawdza listę kontrolną, a po nim potwierdza, że najważniejsze operacje przechodzą przez cały łańcuch. Najlepiej wybrać termin o mniejszym natężeniu pracy, na przykład koniec tygodnia, gdy ewentualne poprawki nie kolidują z obsługą klientów.

Lista kontrolna przełączenia

Lista kontrolna obejmuje cztery grupy czynności, z których każda ma przypisaną osobę i godzinę.

• Kopie - pełna kopia bazy i konfiguracji przed pierwszym zapisem w nowym systemie.
• Dane - końcowy import i porównanie liczebności z systemem źródłowym.
• Dostęp - aktywacja kont użytkowników i wyłączenie zapisu w starym systemie.
• Weryfikacja - wykonanie krótkiego scenariusza przez wyznaczonego użytkownika.

Plan wycofania

Plan wycofania opisuje, co zrobić, gdy uruchomienie się nie powiedzie. Warunkiem jest kopia wykonana tuż przed przełączeniem, którą da się odtworzyć bez pomocy autora. Kopia z opcją COPY_ONLY nie zakłóca łańcucha kopii różnicowych, więc nadaje się do zabezpieczenia punktu przed zmianą.

BACKUP DATABASE BazaAplikacji
TO DISK = N'D:\kopie\BazaAplikacji_przed_wdrozeniem.bak'
WITH COPY_ONLY, CHECKSUM, INIT;

Opcja CHECKSUM wymusza kontrolę sum stron podczas zapisu, co wykrywa uszkodzenia zanim kopia trafi do archiwum. Wycofanie ma sens tylko w określonym czasie po uruchomieniu, a po jego upływie dane nowego systemu są ważniejsze niż punkt kopii.

Pierwsza doba po przełączeniu

W pierwszej dobie zespół obserwuje dziennik błędów aplikacji, czas odpowiedzi bazy i liczbę zapisanych dokumentów. Nagły spadek liczby dokumentów wobec zwykłego dnia oznacza, że użytkownicy nie mogą wykonać jakiejś operacji, nawet gdy nikt jeszcze nie zgłosił problemu. Wyznaczony użytkownik z każdego działu potwierdza pod koniec dnia, że pracował bez zatrzymań, a wynik zapisuje się w dzienniku wdrożenia.

Odbiór i dokumentacja powykonawcza

Odbiór formalnie zamyka wdrożenie i uruchamia okres gwarancyjny. Odbywa się na podstawie kryteriów zapisanych na początku projektu, dlatego nie zależy od wrażenia zespołu w dniu spotkania. Protokół wymienia sprawdzone funkcje, wynik każdej z nich oraz listę uwag z terminami poprawek.

Testy akceptacyjne użytkowników

Testy akceptacyjne wykonują osoby, które będą pracować w systemie, a nie zespół wdrożeniowy. Scenariusze piszą wspólnie przedstawiciele firmy i dostawcy, a każdy z nich ma dane wejściowe oraz oczekiwany wynik. Wynik każdego przebiegu zapisuje się jako zaliczony lub niezaliczony, z opisem odchylenia. Po poprawkach powtarza się ten sam scenariusz, bo naprawa jednej funkcji bywa przyczyną błędu w sąsiedniej.

Klasyfikacja usterek przy odbiorze

Uwagi zgłoszone podczas odbioru dzieli się na klasy, które decydują o możliwości podpisania protokołu.

Dokumentacja powykonawcza

Dokumentacja powykonawcza opisuje system w stanie rzeczywistym po wdrożeniu, a nie w wersji z projektu. Administrator znajduje w niej konfigurację środowisk oraz procedury kopii i odtwarzania, a także listę kont serwisowych. Użytkownicy dostają instrukcje stanowiskowe. Bez tych dokumentów utrzymanie systemu zależy od pamięci osób, które mogą odejść z firmy albo z zespołu dostawcy.

Utrzymanie po wdrożeniu i aktualizacje

Opieka w pierwszych tygodniach

Pierwsze tygodnie po uruchomieniu generują najwięcej zgłoszeń, choć większość z nich dotyczy sposobu pracy, a nie błędów oprogramowania. Zespół wdrożeniowy w tym okresie zwiększa dostępność i analizuje zgłoszenia codziennie, zamiast czekać na cykl tygodniowy. Powtarzające się pytania wracają do instrukcji, a błędy trafiają do listy poprawek z terminem.

Stałe utrzymanie i aktualizacje

Po odbiorze system wchodzi w fazę utrzymania, w której rozliczane są zgłoszenia i aktualizacje. Konserwacja oprogramowania obejmuje poprawki bezpieczeństwa oraz nowe wersje, a jej regularność chroni przed znanymi lukami. Każdą aktualizację sprawdza się najpierw na środowisku testowym, a dopiero potem przenosi na produkcję w uzgodnionym oknie.

Aplikacje webowe, opisane na stronie o aplikacjach webowych, upraszczają ten etap, bo nowa wersja instaluje się raz na serwerze zamiast na każdym komputerze. Codzienną opiekę nad użytkownikami i infrastrukturą po wdrożeniu opisuje strona o usługach IT z helpdeskiem i siecią, a rolę dostawcy przy pierwszych tygodniach pracy przedstawia tekst o wsparciu wdrożenia systemu przez dostawcę.

Wdrożenia i aplikacje na zamówienie realizuje SoftwareStudio; zakres usług prezentuje portal producenta w części oprogramowania na zamówienie. Kontakt w sprawie projektu wdrożeniowego: +48 533 322 626.