The tricky thing about protocols is that you have to be willing to follow them and deal with the consequences when you step off the normal path through the flowchart.
If the protocol says "(1) Check out tools before using them. (2) Check in tools when returning them. (3) Verify all tools checked out have been checked in before marking the job complete." that's one thing. Sending employees to training on how to do this and seeing daily clipboards by the tool room with initials might make you think the protocol is in use. And if there are supervisors making sure that the clipboard is full of initials at the end of the day, that can give you a nice warm fuzzy feeling.
The problem comes when supervisors want to 'look good' by having no deviations from the protocol. If people are post-dating their check-in or pre-dating their check-out, or checking stuff in that's still in use by a coworker, the protocol is less than useless.
When humans are tasked with following those protocols, they'll make human mistakes sometimes. If there are no mistakes that's not good, that's bad - it indicates the metrics are being fudged. I think any supervisor that fails to find a deviation from the protocol or who can't list an event when the protocol required action outside the norm does not look good.
Similar stuff applies to software development: If you're doing code reviews, or testing before check-in, or signing off on releases, and can't point to a time when the protocol said "nope, go back to the drawing board" you're not actually making your development safer you're making it a hassle.
The tool crib checkout is done on computer at least. The toolbox inspections might be fudged.
It also might be downstream or upstream of the Boeing factories, like at one of the companies that manufactures major components (example: Spirit AeroSystems manufactures the 737 main fuselage and I'm told Section 41/cockpit of many aircraft) or at one of the maintenance facilities.
If the protocol says "(1) Check out tools before using them. (2) Check in tools when returning them. (3) Verify all tools checked out have been checked in before marking the job complete." that's one thing. Sending employees to training on how to do this and seeing daily clipboards by the tool room with initials might make you think the protocol is in use. And if there are supervisors making sure that the clipboard is full of initials at the end of the day, that can give you a nice warm fuzzy feeling.
The problem comes when supervisors want to 'look good' by having no deviations from the protocol. If people are post-dating their check-in or pre-dating their check-out, or checking stuff in that's still in use by a coworker, the protocol is less than useless.
When humans are tasked with following those protocols, they'll make human mistakes sometimes. If there are no mistakes that's not good, that's bad - it indicates the metrics are being fudged. I think any supervisor that fails to find a deviation from the protocol or who can't list an event when the protocol required action outside the norm does not look good.
Similar stuff applies to software development: If you're doing code reviews, or testing before check-in, or signing off on releases, and can't point to a time when the protocol said "nope, go back to the drawing board" you're not actually making your development safer you're making it a hassle.