Inaba Chapter 9 - Becky and Jaya
Guidelines for Developing Instructions
Becky and Jaya
The last chapter of this book pertains to the special considerations for maintenance. The authors discuss the inherent structure is based on the fact that maintenance is made up of a common set of functions (checkout, align, adjust, etc.) and each function is made up of similar tasks. Because of this, the total set of maintenance tasks required can be defined for most systems by a matrix functions applied against the equipment at different levels of detail.
The maintenance functions defined in this chapter are: adjust, assemble, calibrate, checkout, disassemble, inspect, install, remove, replace, repair (in place), service and test. The authors talk about the use of these various terms such as remove and install are usually treated together and is sometimes identified as replace.
An example of a matrix system is given. The left column details the systems and equipment units included in each system. The other columns are the maintenance functions. The entries in this matrix identify the maintenance tasks required for each system. The authors discuss the hierarchal structure of the equipment and how to read the matrix.
Special troubleshooting analysis, Failure Mode and Effects Analysis, is discussed as a well-known analysis approach which is normally reserved for systems with potentially hazardous consequences for malfunctions. It is not used often due to being labor-intensive requiring extensive participation of engineers which adds considerable costs. There was an adaptation to this process in which the labor effort required can be adjusted by selecting the level of analysis used for the selected portions. This adaptation was called the Failure Mode and Indications Analysis. This project was considered a major factor in the development of a maintenance system that contributed to extending the operational life of a system. The process consisted of:
- Develop a list of components
- Develop a list of indicators (of system failures)
- Identify the modes of failure (of each component)
- Trace the effects of failures to indicators.
- Summarize the modes of failures by indicators
- Develop diagnostic procedures
posted by Becky | 1:46 PM
10 Comments:
The approach to develop a maintence strategy seems to be such a good idea. However, from what I've seen, more attention seems to be paid to getting a project active or published than it does to maintaining it after it's been released. People seem to lose interest and move on to the next project. As far as troubleshooting, we've been working with our IS department to get them to document their processes. They can fix it, but if someone else has the same problem, it's back to the drawing board again. A matrix system would be a good solution.
I think it is much more interesting to create something than it is to maintain it. I agree with Anne. Give me something new and I'll assign maintenance to a junior-level tech writer.
I can understand how maintenance isn’t a glamorous job. Going back to an established—notice how I didn’t say old?—document can be seen as a dreary job, but I think that most jobs can be seen as that. Yes, the new document gets all the attention, but if the established one is still in use it’s important to keep it maintained. When it comes right down to it, if it still makes money or adds to the organization, it should still be given some thought. But I suppose if maintenance slacks, then the document becomes outdated and a new one is needed. So you’d get that “new” document after all.
I can see maintainence documentation as being much more complex and frustrating for the writer. When you write instructions to assemble something, all you have to do is tell the reader what to do and they do it; they just follow the directions. Assembling something only requires an understanding of the instructions and the materials. Maintainence, on the other hand, requires the user to understand theory; how the widget works. A maintainence manual user will be asked to think critically about a widget and make decisions based on what they find out while performing maintainance. Good authors can easily describe how to put something together, but it takes a truely great author to tell users how to think.
For example, think about the serpentine belt in my car. The maintainence manual tells me to change the belt when it appears frayed or worn, but if I took it to 5 different car repair shops they would all tell me 5 different opinions about the condition of my belt. Professional opinion is an extra consideration that writers must consider when writing maintainance materials.
It's good that Inaba points out maintenance of a document, since that can often be overlooked. Personally, when I finish a project, I don't even like to LOOK at it again! Even when I write papers for class, when I'm done, I'm done. And so it is in the workplace, many writers and designers work more at making a finished product rather than worrying about upkeep.
I agree with Anne. Although I don't have much experience in maintenance strategy field I'm going to say that there are a lot more people concerned about getting a product released then there are with actually maintaining it. I think a lot of it has to do with the ever changing industry in which you can't afford to focus on what you've done but rather what you're going to do next.
I have dabbled in computer programming in the past and I think there is an analogy to be drawn from that experience. There are few worse jobs than having to go back into someone else's program to try and figure out what they were trying to do and how they were trying to do it. The same is probably somewhat true for documentation; going back into someone else's document to make revisions is probably quite frustrating.
The reality of this--or any other job--is that "sombody has to do it." You will probably be paid the same whether you are working on "old" documents or "new" ones. Depending on who you work for and what the documentation is concerned with, it might be very important that those documents be kept accurate and up-to-date.
I agree with Carl, making things is more interesting. Maintaining them is for newbees.
I agree completely with this chapter when it mentions the considerable body of experience the military has on conducting maintenance analysis. I still remember the endless amounts of material data on maintenance documentation. It was the best I have ever see and used. I only wish I could get my hands on some of the documents now that I have an increased knowledge of what it takes as a whole to produce such documents.
Maintenance is important and from what I have personally witnessed, not always done. I think this chapter gave a good formula for performing maintenance though.
Post a Comment
<< Home