Z arkusza do aplikacji: jak przenieść proces bez gubienia wyjątków

Arkusz dobrze radzi sobie z zadaniem, dla którego powstał. Potem ktoś dodaje nową kolumnę, druga osoba tworzy kopię dla swojego oddziału, a trzecia wprowadza poprawki w pliku wysłanym mailem. Po kilku miesiącach firma ma sprawnie działający proces, ale coraz trudniej wskazać jego aktualną wersję. Nie zawsze potrzebna jest nowa aplikacja. Czasem wystarczy uporządkować sposób pracy. W innych sytuacjach aplikacja pomaga przypisać odpowiedzialność, kontrolować dostęp i zachować historię zmian.

Przeniesienie procesu z arkusza do aplikacji zaczyna się od zrozumienia tego, co ludzie robią dziś. Widoczne kolumny to tylko część obrazu. Istotne bywają formuły, ręczne poprawki, pliki pomocnicze i wyjątkowe sytuacje rozwiązywane przez doświadczoną osobę. Jeśli projekt pominie te elementy, nowy system może działać poprawnie, a zespół nadal będzie potrzebował starego arkusza.

Jeżeli rozważasz taką zmianę, wyślij brief z opisem procesu, liczbą zespołów i przykładową sprawą od początku do końca. Nie przesyłaj haseł ani plików zawierających dane klientów. Na początek wystarczy opis kolumn, najważniejszych decyzji i miejsc, w których obecny sposób pracy sprawia kłopot. Jeśli w proces zaangażowane są osoby z różnych krajów, przy ustalaniu zakresu warto też omówić języki i strefy czasowe zespołu.

Znajdź wszystkie wersje procesu

Wyobraźmy sobie firmę usługową, która zapisuje zlecenia w arkuszu. Koordynator wpisuje zgłoszenie, technik dodaje datę wykonania, a osoba rozliczająca uzupełnia kwotę. Oprócz pliku głównego istnieje kopia dla jednego oddziału i osobna tabela z wyjątkowymi stawkami. To przykład projektowy, nie opis rzeczywistego wdrożenia. Pomaga jednak zobaczyć, dlaczego skopiowanie pierwszej widocznej tabeli nie wystarczy.

Zacznijcie od rozmowy z osobami, które tworzą dane, zmieniają je i korzystają z wyników. Poproście o pokazanie ostatniej zwykłej sprawy oraz takiej, która wymagała obejścia. Ustalcie, które pliki są aktualne, kto ma do nich dostęp, jak powstają kopie i kiedy informacje trafiają do innych systemów. Warto zanotować nie tylko nazwy kolumn, lecz także moment, w którym ktoś uważa sprawę za gotową.

Osobno spiszcie operacje wykonywane poza plikiem. Pracownik może poprawiać dane po telefonie, szukać stawki w wiadomości albo pytać kierownika o zgodę na odstępstwo. Te działania są częścią procesu, nawet jeśli nie mają własnej kolumny. W artykule o aplikacji dla firmy usługowej pokazujemy, jak prześledzić drogę zlecenia od zgłoszenia do rozliczenia.

Nie każde przyzwyczajenie trzeba odtworzyć w nowym narzędziu. Jeżeli kolor komórki oznacza jednocześnie pilność i osobę odpowiedzialną, bardziej czytelne mogą być dwa osobne pola. Zanim jednak zastąpicie kolor nowym statusem, sprawdźcie, jak zespół go używa. To, co dla projektanta wygląda na ozdobę, dla pracownika może być jedynym ostrzeżeniem o wymaganym telefonie.

Rozczytaj formuły i ręczne poprawki

Formuła może obliczać termin, stawkę lub sumę pozycji. Przed migracją warto zapisać jej znaczenie zwykłym językiem i sprawdzić, z jakich danych korzysta. Czy stawka zależy od klienta, daty, oddziału czy rodzaju usługi? Czy wyjątek może zatwierdzić kierownik? Taka rozmowa pomaga ustalić regułę, którą będzie można później przetestować niezależnie od konkretnego pliku.

Ręczna poprawka nie zawsze oznacza błąd użytkownika. Może być świadomym odstępstwem od typowej reguły, na przykład korektą terminu po uzgodnieniu z klientem. Nowa aplikacja powinna umożliwić takie działanie właściwej osobie oraz zachować powód zmiany, jeśli jest potrzebny. Sztywne zablokowanie wszystkich odstępstw może po prostu przenieść je do notatnika obok systemu.

Zbierzcie kilka przykładów wartości obliczonych i poprawionych ręcznie. Dla każdego ustalcie dane wejściowe, oczekiwany wynik i osobę, która potrafi go potwierdzić. Tak powstanie początek zestawu testowego. W artykule o kryteriach odbioru aplikacji opisujemy, jak zamienić takie przykłady w sprawdzalne warunki zakończenia prac.

Sprawdźcie też pola używane przez inne systemy. Numer klienta może wyglądać jak zwykły tekst, ale być łącznikiem z księgowością. Zmiana jego zapisu bez uzgodnienia może utrudnić dopasowanie danych. Zanim zaprojektujecie import lub nową integrację, ustalcie, które źródło odpowiada za daną informację i co ma się stać przy rozbieżności. Pomaga w tym artykuł o źródłach danych w integracji systemów.

Uzgodnij słownik i relacje danych

W arkuszu nazwa klienta może pojawiać się w wielu wierszach i kilku wariantach. Przed przeniesieniem danych trzeba ustalić, czy podobne zapisy oznaczają tę samą firmę, dwa oddziały czy różne podmioty. Automatyczne łączenie wyłącznie po nazwie jest ryzykowne. Lepiej wskazać osobę, która rozstrzygnie niejednoznaczne przypadki, oraz zachować informację o sposobie dopasowania.

Słownik danych powinien opisywać znaczenie pola, dopuszczalne wartości, źródło oraz sposób traktowania braków. Przy statusie „w toku” warto wyjaśnić, kto może go nadać i jaka czynność następuje później. Przy dacie trzeba wiedzieć, czy oznacza zgłoszenie, planowane wykonanie czy faktyczne zakończenie. Te ustalenia przydadzą się także w raportach, których liczby będą porównywane po zmianie systemu.

Relacje między rekordami pomagają utrzymać porządek: zlecenie powinno wskazywać właściwego klienta, a pozycja rozliczenia właściwe zlecenie. Mechanizmy bazy danych mogą wspierać kontrolę takich powiązań, choć nie zastąpią uzgodnienia znaczenia danych. Dokumentacja PostgreSQL o ograniczeniach danych pokazuje między innymi sposoby wymagania wartości i kontrolowania powiązań między tabelami. Wybrana implementacja zależy od projektu.

Nie wszystkie stare informacje muszą trafić do aplikacji w tej samej postaci. Część może być potrzebna do codziennej pracy, część do raportowania, a inne dane mogą wymagać osobnej decyzji o archiwizacji. Przed usunięciem lub pominięciem danych ustalcie wymagania firmy i sposób dostępu do historii. Osoba prowadząca proces powinna potwierdzić, że w nowym miejscu znajdzie informacje potrzebne do obsługi bieżących spraw.

Przygotuj import i sprawdź wynik

Migracja zaczyna się od kopii danych i planu przypisania pól, czyli mapowania. Dla każdej kolumny źródłowej ustalcie pole docelowe, sposób przekształcenia oraz postępowanie z pustą lub niepoprawną wartością. Jeśli jedna komórka zawiera kilka informacji, może być potrzebne ich rozdzielenie i ręczna kontrola. Wynik importu powinien wskazywać, które rekordy przyjęto, a które wymagają wyjaśnienia.

Sprawdzenie nie kończy się na liczbie zaimportowanych wierszy. Porównajcie także sumy, statusy, powiązania klientów ze sprawami oraz przykłady wyjątków. Dobrze wybrać próbki razem z osobami, które używają danych, ponieważ wiedzą, gdzie najłatwiej o pomyłkę. Jeśli źródłem są różne pliki, trzeba upewnić się, że ten sam rekord nie został wczytany wielokrotnie pod różnymi nazwami.

Wynik importu może ujawnić braki, których wcześniej nie było widać. Nie każda pusta komórka wymaga zgadywania albo wpisania domyślnej wartości. Czasem należy pozostawić pole nieuzupełnione, oznaczyć sprawę do sprawdzenia lub poprosić właściciela danych o decyzję. Ukrycie niepewności za pozornie poprawnym zapisem utrudni późniejsze wyjaśnienie błędu.

Przygotujcie także plan cofnięcia lub powtórzenia próby. Przed kolejnym importem trzeba wiedzieć, które rekordy powstały podczas poprzedniego uruchomienia i czy można je bezpiecznie zastąpić. W środowisku testowym łatwiej sprawdzić błędne mapowanie i sposób odzyskania stanu. Po wdrożeniu produkcyjnym zakres cofania zależy również od zmian dokonanych przez pracowników w międzyczasie.

Przeprowadź próbę z zespołem

Przed przełączeniem całej firmy wybierzcie ograniczony fragment procesu. Może to być jeden oddział albo nowo przyjmowane sprawy określonego rodzaju. Ustalcie, kto bierze udział w próbie, gdzie zapisuje wyniki i jak zgłasza brakującą funkcję. Dobrze pokazać pracownikom scenariusze, które już znają, oraz poprosić ich o wykonanie zadania bez podpowiadania każdego kliknięcia.

Równoległa praca w arkuszu i aplikacji wymaga jasnych reguł. Jeśli te same dane są poprawiane niezależnie w obu miejscach, powstaje pytanie, która wersja jest wiążąca. Można wyznaczyć jedno źródło dla danego etapu albo określić sposób uzgadniania różnic. Ważne, aby wszyscy uczestnicy próby wiedzieli, gdzie wykonują prawdziwą zmianę i kto ją zatwierdza.

Prototyp nie musi obejmować całego starego pliku. Może pokazać przyjęcie sprawy, jedną poprawkę i przekazanie do kolejnej osoby. O tym, jak zaprosić pracowników do takiego sprawdzianu i wykorzystać ich uwagi, piszemy w artykule o testowaniu prototypu z pracownikami.

W trakcie próby zbierajcie konkretne obserwacje. Zamiast pytania „czy aplikacja się podoba?” poproście o znalezienie zlecenia, poprawienie terminu i sprawdzenie, kto je przejął. Zapiszcie, gdzie użytkownik musi pytać o pomoc, a gdzie potrzebuje informacji, której nie ma na ekranie. Następnie ustalcie, które poprawki są konieczne przed przełączeniem, a które można zaplanować później.

Zamknij stary obieg w ustalonym momencie

Data przełączenia powinna być połączona z decyzją o stanie danych. Ustalcie, kiedy kończy się wprowadzanie zmian w arkuszu, kto wykonuje końcowy import i kto potwierdza zgodność wyników. Jeśli proces wymaga przerwy, osoby obsługujące klientów powinny wiedzieć, jak przyjmować sprawy w tym czasie. Samo ogłoszenie „od poniedziałku używamy aplikacji” nie wystarczy, gdy w piątek wieczorem nadal zmieniają się stare pliki.

Po przełączeniu ustalcie, kto ma dostęp do archiwum i kiedy można ograniczyć edycję dawnego arkusza. Sprawdźcie także integracje, uprawnienia oraz raporty używane przez kierownictwo. Jeżeli nowy system liczy wskaźnik inaczej niż poprzedni plik, trzeba najpierw wyjaśnić definicję, a dopiero potem porównywać wyniki. Artykuł o definicjach wskaźników na dashboardzie pomaga uporządkować takie rozmowy.

Po pierwszych tygodniach warto wrócić do wyjątków rozpoznanych na początku projektu. Sprawdźcie, czy każda z tych sytuacji ma rzeczywiście wykonalną ścieżkę i czy zespół wie, kto podejmuje decyzję. Jeżeli wyjątkowa stawka wymaga akceptacji, przetestujcie nie tylko jej wpisanie, ale też odrzucenie i poprawienie propozycji. Dobrze prześledzić sprawę przez cały proces, aż do momentu, w którym jej wynik pojawia się w raporcie lub rozliczeniu.

Zachowajcie również dokument opisujący najważniejsze ustalenia o danych. Powinien wskazywać źródło wartości, sposób postępowania z duplikatami oraz osobę odpowiedzialną za zmianę słownika. Gdy do procesu dołączy nowy oddział, zespół będzie mógł sprawdzić obowiązujące zasady zamiast odtwarzać je z rozmów. Taki dokument nie musi być długi. Powinien dać odpowiedź na pytania, które w starej wersji procesu rozwiązywała wyłącznie pamięć najbardziej doświadczonej osoby.

Przy przekazaniu aplikacji ustalcie też, kto posiada dostęp do kodu, danych i kont usługowych oraz jak zgłasza się poprawki. Sama dostępność nowego ekranu nie zastępuje informacji potrzebnych do jego utrzymania. Kiedy zmieni się reguła obliczania stawki, ktoś musi wiedzieć, gdzie jest opisana i jak sprawdzić jej wpływ na wcześniejsze rozliczenia.

Przez uzgodniony okres po zmianie zbierajcie zgłoszenia i sprawdzajcie, czy pracownicy nie tworzą nowych kopii arkusza z powodu brakującej funkcji. Nie każda dodatkowa tabela jest problemem, ale powrót do ręcznego przepisywania może wskazywać lukę w procesie. W oprogramowaniu na zamówienie warto od początku zaplanować tę obserwację razem z osobą odpowiedzialną za dalszy rozwój narzędzia.