Z papieru na system elektroniczny bez utraty historii

Największą obawą przy odejściu od papieru nie jest technologia, tylko historia. Statek ma za sobą kilka tysięcy godzin, kilkanaście segregatorów i program obsługi, który zmieniał się trzy razy. Pytanie brzmi: ile z tego trzeba przepisać, żeby system elektroniczny mówił prawdę?

Odpowiedź jest mniej straszna, niż się wydaje — pod warunkiem, że rozróżni się dwie rzeczy: zapisy historyczne i stan bieżący.

Czego nie trzeba przepisywać

Historia lotów statku od nowości nie musi trafiać do systemu lot po locie. Dziennik papierowy pozostaje archiwum — jest zapisem, który powstał zgodnie z przepisem, ma podpisy i nie przestaje być ważny dlatego, że powstał na papierze. Przechowuje się go dalej i przekazuje razem ze statkiem przy zmianie właściciela.

Co musi być w systemie, żeby liczył poprawnie:

• stan każdego licznika na dzień uruchomienia,
• program obsługi w aktualnej rewizji, ze wszystkimi zadaniami i ich limitami,
• ostatnie wykonanie każdego zadania — z datą, stanem liczników w chwili wykonania i odniesieniem do poświadczenia obsługi,
• komponenty z resursem, z ich stanem i datą zabudowy,
• status dyrektyw i biuletynów,
• dokumenty statku z terminami ważności.

To jest cały zakres. Nie „wszystko”, tylko punkt startowy, z którego da się poprawnie policzyć każdy termin. Zapisy dawniejsze niż ten punkt zostają tam, gdzie są — z zachowaniem okresów przechowywania wymaganych przez ML.A.305(h).

Jedno zastrzeżenie: jeżeli sięgnięcie do papieru bywa potrzebne w codziennej pracy (na przykład historia zabudowy silnika, który krążył między statkami), warto przepisać także ją. Nie dlatego, że przepis wymaga, tylko dlatego, że inaczej nowy system będzie kompletny w 90 % — a to jest dokładnie ta wartość, przy której ludzie wracają do segregatora.

Bilans otwarcia: trzy pliki w jednej kolejności

Wprowadzenie stanu startowego nazywa się bilansem otwarcia i ma wymuszoną kolejność, bo każdy kolejny krok korzysta z poprzedniego:

1. Liczniki. Stan początkowy każdego licznika. Bez niego nie da się policzyć niczego.
2. Zadania. Program obsługi: kody zadań, limity godzinowe, cyklowe i kalendarzowe, tolerancje, reguła „co nastąpi wcześniej / później”.
3. Wykonania. Ostatnie wykonanie każdego zadania, z punktem odniesienia dla następnego terminu.

Cztery zasady, które oszczędzają najwięcej czasu:

• Nie twórz plików od zera. Wzór powinien generować się z systemu, z prawdziwymi kodami liczników i zadań konkretnego statku. Plik napisany ręcznie kończy się rundą poprawek nazw, a nie danych.
• Zawsze najpierw próbny przebieg. Dobrze zrobiony dry-run pokazuje pozycja po pozycji, co się stanie, i niczego nie zapisuje. To jest moment na czytanie, a nie na klikanie „dalej”.
• Założenia mają być ogłoszone. Jeżeli w pliku nie ma planowanego terminu ostatniego wykonania, system musi jawnie napisać, że przyjmuje datę wykonania jako punkt odniesienia. To założenie decyduje o pierwszym terminie po migracji — nie może być ukryte w kodzie.
• Nic nie ma znikać po cichu. Każda nierozpoznana kolumna i każdy pominięty wiersz muszą trafić do raportu. Import, który „przeszedł bez błędów”, ale zignorował trzy pozycje, jest gorszy od importu, który się nie udał.

Podpis pod stanem startowym

Bilans liczników to nie jest operacja techniczna — to oświadczenie o stanie floty. Powinien wymagać podpisu (u nas: ponownego podania hasła) oraz podania źródła danych w formie, którą da się zweryfikować:

PDT papierowy nr 3, strona 41, stan na 2026-07-18

Ta jedna linijka jest tym, co pozwala po dwóch latach odpowiedzieć na pytanie „skąd wzięła się ta liczba”. Bez niej stan początkowy jest wartością bez pochodzenia, a cała późniejsza arytmetyka opiera się na niczym.

Czego bilans otwarcia nie zrobi

Trzy ograniczenia, które lepiej znać wcześniej:

• Bilans wchodzi tylko na licznik bez historii. Licznik, który już się porusza, poprawia się korektą z uzasadnieniem, nigdy importem. Inaczej powstałby mechanizm nadpisywania stanu — czyli dokładnie to, przed czym broni się cała konstrukcja systemu zapisów.
• Ten sam plik wgrany dwa razy nie zapisze nic. Idempotencja to nie wygoda, tylko zabezpieczenie: przy migracji ktoś na pewno kliknie dwa razy.
• Import nie ocenia stosowalności dokumentów. Status dyrektyw i biuletynów przepisuje się razem z decyzjami organizacji, a nie samymi numerami.

Dual-run: po co i jak długo

Równoległe prowadzenie dziennika papierowego i elektronicznego przez uzgodniony okres to nie brak zaufania do systemu. To sposób na trzy rzeczy naraz: nauczenie się nowego obiegu bez ryzyka, zebranie materiału dowodowego dla nadzoru i wykrycie różnic wcześniej niż przy przeglądzie zdatności.

Zasady, które trzeba ustalić na piśmie przed startem:

• Który rejestr rozstrzyga w razie rozbieżności (na czas dual-runu zwykle papierowy).
• Jak długo — mierzone w lotach albo miesiącach, z konkretną datą zakończenia, a nie „do odwołania”.
• Kto i jak często porównuje oba rejestry oraz gdzie zapisuje wynik porównania.
• Co jest sygnałem do zatrzymania wdrożenia i powrotu do papieru.

Sam dual-run wykrywa zwykle jedną rzecz, której nie widać w testach: kto naprawdę wypełnia dziennik. Jeżeli w praktyce robi to wieczorem jedna osoba za trzech pilotów, system elektroniczny z podpisem imiennym natychmiast to ujawni — i to jest wartość sama w sobie, choć bywa niewygodna.

Co uzgodnić z nadzorem

Lista jest krótka i lepiej mieć ją przygotowaną, zanim padnie pierwsze pytanie:

1. Opis systemu: skąd biorą się dane, kto je zatwierdza, jak wykazywana jest integralność zapisów, jak wygląda procedura na czas niedostępności systemu.
2. Wykładnia okresów przechowywania przyjęta przez organizację (ML.A.305(h)) — z podziałem na zapisy szczegółowe i zbiorcze.
3. Zgodność wzoru wydruku wpisu z formularzem oczekiwanym przez nadzór.
4. Uznanie podpisu elektronicznego za równoważny podpisowi w dzienniku papierowym — z opisem, co dokładnie obejmuje podpis.
5. Zakres i data zakończenia dual-runu.

Czego oczekiwać: rozmowa rzadko dotyczy tego, czy elektroniczny dziennik jest dopuszczalny — przepis mówi o systemie zapisów, nie o papierze. Dotyczy tego, czy ten konkretny system spełnia warunki i czy organizacja umie to wykazać. To dwie różne rozmowy i tylko do drugiej da się przygotować.

Harmonogram, który się sprawdza

Realne osiem tygodni dla floty kilku statków:

Tydzień	Co się dzieje
1	Inwentaryzacja: co jest w papierze, czego brakuje, kto ma dostęp
2	Konfiguracja statków i liczników; opis systemu dla nadzoru
3–4	Bilans otwarcia: liczniki → zadania → wykonania, z próbnymi przebiegami
4	Zgłoszenie do nadzoru i przekazanie opisu systemu
5–8	Dual-run, cotygodniowe porównanie rejestrów, poprawki konfiguracji
8	Podsumowanie, wniosek o zakończenie dual-runu

Tydzień pierwszy jest najczęściej lekceważony i najczęściej okazuje się najważniejszy. Inwentaryzacja regularnie ujawnia braki, które istniały od dawna — zadania bez zapisanego ostatniego wykonania, komponenty bez historii zabudowy, dyrektywy ocenione, ale bez śladu decyzji. Migracja ich nie tworzy; ona je pokazuje. Warto z góry przyjąć, że część czasu wdrożenia to nie praca z systemem, tylko domykanie zaległości — i że to jest dobrze wydany czas, bo tych samych rzeczy szukałaby osoba wykonująca przegląd zdatności.

Trzy błędy, które kosztują najwięcej

1. Migracja bez punktu odniesienia dla terminów. Przepisanie samych dat ostatnich wykonań, bez stanu liczników w chwili wykonania, daje due-listę, która wygląda poprawnie i jest błędna. Naprawa wymaga powtórzenia importu.
2. Start bez ustalenia, kto rozstrzyga. Dual-run bez tej zasady kończy się dwoma rejestrami o równym statusie i sporem przy pierwszej rozbieżności.
3. Wdrożenie „przy okazji” przeglądu zdatności. Kumulacja terminu ARC z migracją danych oznacza, że każdy problem migracyjny staje się problemem terminowym. Najlepszy moment na start to okres zaraz po przeglądzie zdatności — masz wtedy jedenaście miesięcy na spokojne domknięcie wszystkiego.