Control of equipment instruction manuals

[somashekar]

There is nothing in this thread that suggests that the OP's company creates software for others. An equipment manual is a technical document that simply forms a part of a equipment packing list content and can be the same for one or many equipments which are similar. A simple control just like any other equipment part control is necessary to use the correct manual in equipment packing or to issue against request.

 

[Wes Bucey]

At present, our control of instruction manuals is bad to non-existant. Many are out of date and this needs to be addressed. I see two possibilities:

(1) Treat them exactly the same as controlled company documents.
(2) Treat them as products in their own right and control them that way.

In both cases a mechanism would be needed to ensure the manual gets updated with the product to which it refers.

A third suggestion has come from the software developers who say that manuals could be controlled under the software versioning system they use, however management don't like this suggestion.

I would be interested to hear how others approach this.

Thanks,
John.

There is nothing in this thread that suggests that the OP's company creates software for others. An equipment manual is a technical document that simply forms a part of a equipment packing list content and can be the same for one or many equipments which are similar. A simple control just like any other equipment part control is necessary to use the correct manual in equipment packing or to issue against request.

Perhaps I misunderstood whether OP's company creates the software to go along with the product (or perhaps you were so eager to point out my error, you erred instead.)

 

[BethP]

Like somashekar, my first thought was that this belongs in the BOM. This aligns with OP's option 2. Based on the organization that I work with, the challenge may be that two different groups are involved. For example, marketing or Customer Service may be tasked with the instruction book, packaging and other collateral pieces (called OOBE - out of the box experience where I work), while the Engineering team is tasked with changes to the product. It is easy for one group to be out of synch with the other group.

Perhaps, the product change control (ECR/ECN) process may benefit from having a checklist item related to these marketing collateral pieces so that the question is at least asked when changes are being implemented. Additionally, if not already the case, an owner should be assigned for the marketing collateral, so that when a change is needed, the team making the change knows who to go to.

BTW - I think the software team's suggestion is a red herring in the post. The way I read it is that the software team has an existing system for source control and is offering it as a solution to the other teams.

 

[somashekar]

Perhaps I misunderstood whether OP's company creates the software to go along with the product (or perhaps you were so eager to point out my error, you erred instead.)

I simply meant what I said and that was about nothing in the thread suggesting that the OP's company creates software for others. The software could even be the embedded part of the equipment.
No other eagerness intended.
My thoughts were only on future posts not getting biased.
Hope the OP has got what he wished, or hope John Mann comes back with his opinions.

 

[somashekar]

Like somashekar, my first thought was that this belongs in the BOM. This aligns with OP's option 2. Based on the organization that I work with, the challenge may be that two different groups are involved. For example, marketing or Customer Service may be tasked with the instruction book, packaging and other collateral pieces (called OOBE - out of the box experience where I work), while the Engineering team is tasked with changes to the product. It is easy for one group to be out of synch with the other group.

Perhaps, the product change control (ECR/ECN) process may benefit from having a checklist item related to these marketing collateral pieces so that the question is at least asked when changes are being implemented. Additionally, if not already the case, an owner should be assigned for the marketing collateral, so that when a change is needed, the team making the change knows who to go to.

BTW - I think the software team's suggestion is a red herring in the post. The way I read it is that the software team has an existing system for source control and is offering it as a solution to the other teams.

THIS IS THE SIMPLE PROCESS INTERACTION THAT IS EXPECTED AND THE ISO9001 BEGS THIS TO BE ACTIVE AND BENEFICIAL TO THE ORGANIZATION WHEN A QMS IS ESTABLISHED IMPLEMENTED MAINTAINED AND CONTINUALLY IMPROVED ......

 

[John Mann]

Thanks to everyone who has responded for your thought-provoking points. Apologies for not responding earlier but I am in the UK and have only just got into work in the morning!

To clarify the situation, I am Quality Manager for a small company. We produce both software and hardware products for our customers and the issue here is with manuals and instructions that we supply to customers relating to the use of our hardware and software. The software has reasonably good online help but standalone documentation for hardware and software has also been produced. I was actually unaware of this until our customer surveys showed poor scores for documentation. As has been suggested by BethP, part of the problem is that no-one really "owns" these items.

The general opinion I get from this thread is that our manuals should be controlled as a product, not as part of our document control system. I like the idea of a checkbox on the ECR form as a reminder that a change to hardware/software may require updating of manuals.