Wdrożenie aplikacji i przeniesienie danych: jak zaplanować start?

Rozdziel ukończenie programu od rozpoczęcia pracy

Odbiór funkcji odpowiada na pytanie, czy aplikacja wykonuje uzgodnione zadania. Wdrożenie odpowiada na inne: czy firma potrafi z niej korzystać na rzeczywistych sprawach, z odpowiednimi danymi i osobami. W harmonogramie potrzebne jest miejsce na obie części.

Wyznacz po stronie firmy osobę, która podejmuje decyzje o danych i sposobie pracy. Wykonawca może przygotować import oraz wyjaśnić rozbieżności, ale nie powinien zgadywać, który z dwóch wpisów klienta jest aktualny albo czy dawne zlecenie rzeczywiście zakończono.

Ustal również, kto przeprowadzi próbę jako użytkownik. Jeżeli nowy program ma służyć biuru i osobom wykonującym zlecenia, przedstawiciel każdej z tych grup powinien sprawdzić własne zadania przed startem.

Wybierz, jakie dane naprawdę trzeba przenieść

Nie zaczynaj od polecenia „przenosimy wszystko”. Oddziel dane potrzebne do dalszej pracy od historii, do której trzeba tylko czasem zajrzeć. Otwarte zlecenia, aktualne kontakty i używane indeksy mogą mieć inny sposób przeniesienia niż dawne załączniki lub zakończone sprawy.

Przy każdym zbiorze określ źródło, właściciela i przeznaczenie. Jeśli historia pozostaje w starym narzędziu lub archiwum, uzgodnij dostęp, możliwość wyszukania i okres przechowywania właściwy dla tych danych. Nie zakładaj, że wyłączenie starej licencji pozostawi dostęp do potrzebnych informacji.

Przykład poniżej jest fikcyjnym planem migracji dla aplikacji do obsługi zleceń. Pokazuje decyzje do podjęcia, a nie uniwersalny zakres importu.

Tabelę możesz przesunąć w bok, aby przeczytać sposób przeniesienia i sprawdzenia danych.

Takie rozdzielenie pomaga wycenić pracę. Import jednego uporządkowanego arkusza różni się od łączenia danych z kilku programów i przypisywania tysięcy plików do właściwych spraw.

Uzgodnij znaczenie pól przed importem

Kolumna „termin” może oznaczać obiecaną datę wysyłki, rozpoczęcia albo zakończenia pracy. Zapis „gotowe” może oznaczać wykonane lub już wydane klientowi. Kopiowanie wartości bez ustalenia znaczenia przeniesie nieporozumienia do nowej aplikacji.

Przygotuj mapę pól: skąd pochodzi informacja, do którego pola trafi i czy wymaga przeliczenia lub decyzji. Sprawdź jednostki, zapis dat, identyfikatory, puste wartości i sposób powiązania plików. Nie dopisuj wymyślonych danych tylko po to, aby import przeszedł bez błędu.

Osobno ustal duplikaty. Dwa podobne nazwiska lub nazwy firm nie są wystarczającą podstawą do połączenia rekordów. Wątpliwe przypadki powinny mieć listę do rozstrzygnięcia przez osobę znającą dane.

Zrób próbny import i sprawdź wynik

Pierwszą migrację przeprowadź w środowisku do prób. Zakres udostępnionych danych powinien wystarczać do testu i odpowiadać ustalonym zasadom dostępu. Przed importem zapisz stan źródła, aby można było wyjaśnić różnice.

Porównanie samej liczby wierszy jest zbyt słabe. Sprawdź także powiązania klientów ze zleceniami, sumy ilości, terminy, załączniki oraz przypadki odrzucone przy imporcie. Wybierz zarówno zwykłe rekordy, jak i te z niepełnymi danymi czy nietypowym przebiegiem.

Poproś użytkowników o wykonanie pełnej czynności na przeniesionych danych: znalezienie sprawy, otwarcie dokumentu, zmianę etapu i sprawdzenie wyniku przez kolejną osobę. Dzięki temu test obejmuje użyteczność danych, a nie tylko ich obecność w bazie.

Prowadź listę nierozstrzygniętych różnic z osobą odpowiedzialną za decyzję. Każda rozbieżność wymaga poprawienia, świadomego zaakceptowania z wyjaśnieniem albo wyłączenia z uruchomienia według uzgodnionej zasady. Pominięcie odrzuconych wierszy bez odnotowania utrudnia późniejsze ustalenie, co naprawdę zawiera aplikacja.

Ustal moment przełączenia i plan powrotu

Największe zamieszanie powstaje, gdy zespół nie wie, czy wpisywać zmianę do starego programu, czy do nowego. Ustal dokładny punkt przełączenia: co przestaje być edytowane, kiedy wykonywany jest końcowy import i kto potwierdza gotowość.

Jeżeli część pracy pozostaje chwilowo w starym narzędziu, wyznacz granicę, na przykład zakończenie już rozpoczętych spraw w poprzednim programie i przyjmowanie nowych w aplikacji. Sprawdź, czy taki podział pasuje do sposobu raportowania oraz powiązań między sprawami.

Plan powrotu powinien wyjaśniać:

• kto może wstrzymać uruchomienie;
• jakie problemy wymagają powrotu, a jakie pozwalają pracować dalej;
• gdzie pracownicy zapisują nowe zdarzenia podczas przerwy;
• jak po powrocie zostaną uzgodnione zmiany wykonane w nowej aplikacji;
• jak poinformować użytkowników o decyzji.

Samo posiadanie kopii sprzed startu nie rozwiązuje kwestii zleceń dodanych później. Ten okres trzeba uwzględnić, żeby powrót nie oznaczał utraty wykonanej pracy.

Przygotuj użytkowników do ich zadań

Szkolenie powinno obejmować czynności danej osoby: przyjęcie sprawy, znalezienie dokumentu, zapisanie przeszkody lub sprawdzenie terminu. Przegląd wszystkich przycisków jest mniej użyteczny niż wspólne wykonanie kilku typowych zadań.

Przygotuj krótką instrukcję oraz jedno miejsce do zgłaszania problemów. Rozróżniaj błąd, pytanie o obsługę i pomysł na nową funkcję. W pierwszych dniach potrzebna jest osoba, która może rozstrzygnąć również wątpliwość dotyczącą zasad pracy, nie tylko kodu.

Kiedy można uznać wdrożenie za zakończone

Przed startem zapisz warunki zakończenia: uzgodnione dane są sprawdzone, użytkownicy wykonują kluczowe zadania, wiadomo gdzie zgłaszać problem i kto odpowiada za dalszą obsługę. Lista otwartych uwag powinna oddzielać błędy blokujące pracę od kolejnych usprawnień.

W ofercie sprawdź, czy migracja, szkolenie i wsparcie po uruchomieniu są ujęte w cenie, czy wymagają osobnego zakresu. Etapy współpracy z brigdev pomagają rozdzielić planowanie od budowy. Do planu uruchomienia dopisz także zasady utrzymania aplikacji, aby po odbiorze nie pozostały bez właściciela kopie, aktualizacje i zgłoszenia.