Wednesday, May 12, 2010

Maintenance Good. Maintenance Less Good. (part 1 of 4)

Everybody enjoys brief stories, especially hypothetical stories with impossible scenarios.

The characters in these stories work in equipment maintenance, but with minor changes, the stories could apply to any system support group, e.g. desktop support, data warehouse team, Formula One pit crew, custodial engineers, etc.

Bonus point questions for managers: Who should be praised & rewarded for fixing a problem? What if it's a really tough problem? What if it’s not?

- Technician notices a bracket has worked loose. If it wobbles too much, the tool arm might get bent. Technician tightens the bolt. Nice work! Maximum benefit; minimum cost; zero recognition.
- Same situation, but technician later mentions it to a senior tech. They add a dab of Loctite ( as a long-term fix. Nice work! Maximum benefit extended; minimum cost; zero recognition. Maybe they mention it to their manager, but maybe not. This is just routine, smart repair work.
- Same situation continues when the senior tech later mentions it to the support engineer. They jointly worry about a similar problem on the other machines. The engineer initiates a design change request, but the wait will be lengthy. Senior tech inspects all similar machines and adds the Loctite fix. Engineer modifies the on-line PM process to include a bracket inspection (until the new design is installed). Wow! Maximum benefit double-extended; minimal downtime; some recognition for project work.
- Alternate reality: For just a moment, consider the possibility of a truly excellent designer preventing these scenarios by anticipating & preventing the bracket problem. Unparalleled perfection! Permanent benefit; zero cost for user; zero recognition. As an associated concern, future perfect designs might be late and cost too much because the truly excellent designer left (no recognition, bonus, or promotion).

How does the feedback system inform the designer of discovered problems? Does the original designer own it, learning from errors? Or, do fixes for design failures drift to a different engineer?

More Scenarios
- What happens if the technician doesn't notice the loose bracket? (Inspection wasn't required by the process.) The bracket wobbles too much, and the tool arm gets bent. That’s bad! Spare part is available, and downtime is limited to half a shift. Minimum cost; good recognition for prompt repair.
- Same situation, and the bolt soon loosens up again. Tool arm gets bent, and the new spare is still "on order". Senior tech works with Purchasing to expedite shipment. Good job! Another spare part is immediately ordered, and downtime was limited to one day. Support group is recognized for excellent responsiveness and efficaciousness (something to mention during salary discussions). Quietly, the Purchasing Department celebrates promptly resolving a serious crisis.
- Same situation continues when tool arm gets bent on a second machine. Expedited delivery of the second spare part limits downtime to two days. The Support & Purchasing Departments receive applause for minimizing the effects; but after three failures, the name of the equipment company has become a new punch line to several old jokes. When contacted about this apparent design flaw, the company recommends performing monthly inspections of the tool arm until the root cause of the failure can be determined.

Bad things happen. Even to good people.

No comments:

Post a Comment