Your QMS can be illustrated in a number of ways. One way to think of it is as a standard fishbone. You have quote review to customer receives product. Along the way there are various inputs. In the extreme, as in starting an entirely new and unrelated product, there will be basics of design including determining processes, inspections and tests, etc. Once established you still review these basics - typically during contract review or RFQ review. Are current inspections and tests sufficient, etc. Your design change process should handle a lot of the documentation (assuming it's not a 'catalogue' item). Ie: Special length, special hydraulic fittings, special attachments at each end, etc.
If you look at your business as a set of processes and inter-relate them this is not all that hard. The important part is ensuring you are clear about inputs and outputs and intra / inter-system communications.
-> 5.5.3 Internal Communication
->
-> Top management shall ensure that appropriate
-> communication processes are established within the
-> company and that communication takes place regarding the
-> effectiveness of the quality management system.
->
-> Communications channels are represented in procedures.
-> Management reviews, for example, is a communication
-> conduit. Staff meetings are conduits. Shift meetings are
-> conduits. This should be only an issue of being ready to
-> discuss the issue and to be ready with specific examples.
If you take a look through the slides starting at about
http://Elsmar.com/Imp/sld028.htm - you might get an idea of what I'm talking about. In addition, you may want to look through process mapping.
Your QMS is a sub-set of all processes, but if you can illustrate your company processes they will be there. Most of your processes will be QMS related with the exception of some finance and such.
If you're making specialty items on a low volume level your 'process documentation' will be a lot different than in a high volume operation. Other factors are important as well, such as how much training your company does or does not do. My point here is only to say each company is different in how their systems are designed - which is a big reason I warn against canned documentation solutions.
You can do this from the product view, but my recommendation is you do it from a process view. There was a discussion thread here recently about the definitions of PROCESS vs SYSTEM as I remember. The slides address this issue.