-re “over maintaining”
While engineers generally don’t carry out maintenance for the sake of it, I think I know what rafloo’s referring to.
The example I cited (RAF down to 6 cabs) was caused entirely by poor (non-existent) training leading to engineers removing a complete 13-LRU system every time the observers thought there was a fault. The instructors hadn’t been trained on the system so they were passing on duff gen to the observers. What the observers thought was a fault was a design feature of the system. The engineers weren’t trained to recognise / diagnose this so simply pulled the whole system (the over maintaining bit, if you like). Result? 99.5% No Fault Found Rate at 3rd line workshops. That is, almost 100% serviceability, but low availability. And as any engineer will tell you, thinking an LRU is serviceable is different from verifying it to QA standards, so there was a huge bottleneck at 3rd line while literally hundreds of serviceable LRUs (in fact, over 1000 on the day in question) had to be fully tested, which took months and diverted staff from other tasks.
In the end, a 5 minute teach-in with the Obs Instructor and a Chief Tech saved a fortune by reducing unnecessary maintenance, the NFF rate and 3rd line costs / overtime; and increased availability and operational effectiveness.
We also found out that the RAF didn’t routinely employ people to troubleshoot cases like this (and nowadays neither do IPTs) but they knew the RN had a specialist team doing just that. (Disbanded when the RAF took over RN support). Sounds like we need a return to a similar system. If such a level of efficiency savings could be achieved (again) without impinging on OE, it would throw into doubt the calculations underpinning the cost-effectiveness of SKIOS (which is the original subject of the thread).