Baza wiedzy
Tolerancje bez dryfu: jak liczyć terminy przeglądów
Dlaczego przeglądy „uciekają” do przodu, jak działa kotwiczenie terminu planowanego i co zrobić z zadaniem, które ma limit godzinowy i kalendarzowy naraz.
Aktualizacja: 4 min czytania
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.
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ć.
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:
- Co się stanie z kolejnym terminem, jeżeli wykonam przegląd w tolerancji? (Odpowiedź „przesunie się o tyle, ile spóźnienia” oznacza dryf.)
- Do którego licznika przypięty jest limit godzinowy i czy da się mieć zadania w dwóch bazach nalotu na jednym statku?
- 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.