Tolerancje bez dryfu: jak liczyć terminy przeglądów

Arkusz kalkulacyjny do pilnowania resursów prawie zawsze zawiera ten sam błąd. Nie w formule — w założeniu. Kolejny termin liczy się w nim od daty faktycznego wykonania, a nie od terminu, który był planowany. Efekt jest cichy i skumulowany: każdy przegląd wykonany „na styk” w tolerancji przesuwa cały dalszy cykl do przodu.

Skąd bierze się dryf

Weź zadanie z limitem 100 godzin i tolerancją 10 godzin.

Cykl	Termin planowany	Wykonano przy	Kolejny termin bez kotwicy	Kolejny termin z kotwicą
1	100:00	108:00	208:00	200:00
2	200:00	207:00	307:00	300:00
3	300:00	309:00	409:00	400:00

Po trzech cyklach kolumna „bez kotwicy” jest już nawet o dziewięć godzin dalej niż powinna. Nikt nie zrobił nic złego, każde wykonanie mieściło się w tolerancji — a mimo to statek lata dłużej między przeglądami, niż przewiduje program obsługi. Tolerancja miała być marginesem organizacyjnym na jeden raz, a stała się stałym dodatkiem do limitu.

Reguła, która to naprawia, jest jednozdaniowa: punktem odniesienia dla następnego terminu jest wcześniejsza z dwóch wartości — faktyczne wykonanie albo termin planowany. Wykonanie przed terminem naturalnie przesuwa cykl do przodu (bo kotwicą jest wtedy wykonanie), ale wykorzystanie tolerancji nie kupuje dodatkowego zapasu na przyszłość.

Praktyczna konsekwencja przy przepisywaniu stanu z papieru: jeżeli w importowanym pliku nie ma planowanego terminu, system musi jawnie ogłosić założenie, że kotwicą staje się data wykonania. To informacja dla mechanika, a nie szczegół implementacyjny — od niej zależy pierwszy termin po migracji.

Dwie osie w jednym zadaniu

Większość zadań programu obsługi ma więcej niż jeden limit: 100 godzin albo 12 miesięcy, cokolwiek nastąpi wcześniej. Zdarza się też reguła odwrotna — „cokolwiek nastąpi później” — i zadania mieszane, gdzie część limitów jest godzinowa, a część kalendarzowa.

Żeby due-lista miała sens, każde zadanie musi mieć wyznaczoną oś decydującą: tę, która wypada pierwsza (albo ostatnia, zależnie od reguły). To ona odpowiada na pytanie „ile jeszcze mogę latać”, ona wyznacza kolor statusu i ona trafia na wydruk. Lista, która pokazuje osobno „37 godzin” i „50 dni”, zostawia arytmetykę człowiekowi — czyli dokładnie to, co miało zniknąć.

Osobna pułapka to baza nalotu. Śmigłowiec ma zwykle licznik czasu blokowego i licznik tachometryczny, które nie chodzą w tym samym tempie. Jeżeli program obsługi mówi „100 h według tacho”, a system liczy według czasu blokowego, różnica potrafi urosnąć do kilkunastu procent. Każdy limit godzinowy musi więc wskazywać konkretny licznik, a wpis PDT musi rejestrować oba odczyty. To nie jest nadmiar danych: to jedyny sposób, żeby ta sama flota mogła mieć zadania liczone w obu bazach.

Prognoza: ostrożnie i uczciwie

„Zostało 37 godzin” to informacja dla mechanika. Dla planowania potrzebna jest data. Zamiana godzin na dni wymaga założenia o wykorzystaniu — i tu decydują dwa wybory:

• Które wykorzystanie? Średnia z ostatnich 30 dni reaguje szybko, ale wariuje po tygodniu przestoju. Średnia z 90 dni jest stabilna, lecz spóźniona. Bezpieczniejsze jest wzięcie większej z nich: prognoza wypada wcześniej, a błąd idzie w stronę wcześniejszego przeglądu, nie przekroczenia.
• Co ze statkiem, który nie lata? Wykorzystanie bliskie zeru daje prognozy w rodzaju „termin za 412 dni”. To liczba, która wygląda jak wiedza, a jest artefaktem dzielenia. Uczciwiej jest pokazać status „brak wykorzystania” i nie prognozować.

Ta sama uczciwość dotyczy statusu „brak danych”. Zadanie, którego nie da się policzyć — bo licznik nie ma stanu początkowego albo brakuje historii wykonań — nie jest zadaniem „w porządku”. Na due-liście musi wyglądać jak alarm, bo oznacza dziurę w danych, a nie zapas czasu.

Gdzie tolerancji nie ma wcale

Tolerancja jest własnością zadania, a nie przywilejem organizacji — i są zadania, przy których wynosi ona zero. Dotyczy to przede wszystkim części o ograniczonej żywotności (LLP) oraz zadań wynikających z dyrektyw zdatności. Termin wskazany w dyrektywie jest terminem, a nie sugestią; nie da się go „zmieścić w tolerancji”, bo żadnej nie ma.

Praktyczna konsekwencja dla konfiguracji systemu: tolerancja musi być polem zadania, z domyślną wartością zero i świadomym ustawieniem tam, gdzie program obsługi ją dopuszcza. Odwrotny domyślny wybór — jedna tolerancja globalna dla całej floty — prędzej czy później zostanie zastosowana do resursu LLP, i to jest błąd, którego nie widać do momentu przekroczenia.

Zadanie nadrzędne zeruje podrzędne

Programy obsługi zawierają zadania zagnieżdżone: przegląd 100-godzinny zwykle obejmuje zakres przeglądu 50-godzinnego. Jeżeli system nie zna tej zależności, po wykonaniu „setki” zadanie 50-godzinne dalej wisi jako zaległe — a mechanik zamyka je ręcznie drugim wpisem, którego nikt nie wykonał.

Poprawne rozwiązanie to jawna relacja nadrzędne → podrzędne: rejestracja wykonania zadania nadrzędnego generuje wykonania wszystkich zadań objętych jego zakresem, z tą samą datą, tym samym stanem liczników i tym samym odniesieniem do poświadczenia obsługi. Każde z nich zostaje osobnym zapisem — nadzór musi widzieć, że zakres 50-godzinny został wykonany, a nie tylko domyślać się tego z faktu wykonania setki.

Jak czytać due-listę

Cztery statusy wystarczą, jeżeli są rozłączne i zdefiniowane z góry:

• przekroczony — termin minął i nie mieści się w tolerancji zadania; statek nie lata do czasu wykonania,
• w tolerancji — termin minął, ale mieści się w dopuszczalnym marginesie; wymaga świadomej decyzji, nie milczenia,
• wkrótce — zbliża się (typowo 25 godzin nalotu albo 30 dni),
• brak danych — zadania nie da się policzyć.

Na due-liście muszą też wylądować zadania powstałe z dyrektyw zdatności i biuletynów — dokument oceniony jako „dotyczy”, ale nieprzeniesiony do programu obsługi, nie jest przez nic pilnowany.

Do tego jedna zasada procesowa: status ma wynikać z danych, a nie z ręcznego ustawienia. W momencie, w którym ktoś może „odhaczyć” zadanie bez zapisu wykonania z datą, stanem liczników i numerem CRS, due-lista przestaje być dokumentem, a staje się notatką.

Co z tego wynika dla wyboru systemu

Trzy pytania, które warto zadać przy każdej demonstracji oprogramowania CAMO:

1. Co się stanie z kolejnym terminem, jeżeli wykonam przegląd w tolerancji? (Odpowiedź „przesunie się o tyle, ile spóźnienia” oznacza dryf.)
2. Do którego licznika przypięty jest limit godzinowy i czy da się mieć zadania w dwóch bazach nalotu na jednym statku?
3. Jak wygląda zadanie, którego nie da się policzyć? (Jeżeli wygląda jak zielone — to najgorsza z możliwych odpowiedzi.)

Reszta funkcji jest wymienna. Te trzy rzeczy decydują o tym, czy due-lista jest dokumentem, na którym można oprzeć decyzję o locie.