|
Explicitly, a process document is not a mandatory document. Implicitly, it can be—if it is in the form of a procedure that is required. For example, the audit process could be documented in the form of a SOP that would then be mandatory because an audit procedure is mandatory. This vagueness is not new to the 2000 version; it has always been there and has always been confusing to all QMS developers.
However, several requirements and definitions help to demystify the form of tier II documentation. Such inputs can serve to include the concept of a process document more clearly into the ISO terminology.
First, we must examine the definition of a procedure. With reference to ISO 9000:2000, Par. 3.4.5, a procedure is a document that tells you how to accomplish either an activity or a process. In other words, if you want to create a process document, you can call the document a procedure. The common terminology ranges from standard operating procedure, to quality systems procedure, to quality-assurance procedure. The document will then fit into the ISO terminology.
There is another bug in the ointment that is a throwback to the 1987 first release. Procedures can be documented or not. What we did in those days to resolve this issue was to interview several people running the same procedure to indicate either that it was being done differently by different people or it was not. The advent of a multitude of procedures and work instructions is indicative of what was discovered.
However, this requirement, which appears as a note under Par. 3.4.5 in the vocabulary, is a real issue that must be considered carefully. For example, many a machine shop has extremely well-qualified and experienced machinists who perform a multitude of complex tasks without written procedures. To require written procedures in this case would be a waste of resources. As long as both the inputs and outputs of the machining process are controlled and the appropriate records are kept, there is no sensible reason to document how the machinists set up their work, implement the drawings, and inspect and move the product along to the next cell. On the other hand, for example, it is ludicrous to argue that it is reasonable to perform complex test plans from memory.
The next step in our attempt to validate the process document as a viable tier II text is based upon the definition of a quality plan. With reference to ISO 9000:2000, Par. 3.7.5, a quality plan tells you that procedure(s) and resources are required by those who do work, regardless of the type of work that has to be done. Sounds like a process to me. It has inputs (procedures, resources, people), transformations (inputs applied and changed), and outputs (projects, products, processes, contracts). As a result, quality plans are really process documents. The terminology used includes quality-assurance plan, manufacturing control plan, and design control plan. Work orders and travelers are sometimes in the form of a quality plan. This is why we have placed the requirements for plans under the category tier II documents in Table 3.4.
It is also common for the various design phases in the process document to be broken down into subphases. For example, a subphase 1.1 might be the process to create the program plan and a subphase 1.2 might be the process to create the program team. It is not uncommon to nest procedural documents as subphases of the process document. They would still be labeled 1.1, 1.2, … 1.N, but would contain the necessary steps of a tier III document. The idea of nesting appears in the tier III procedure.
It is important to realize that none of the formats are final. They are simply convenient templates to use to increase information flow. That is the sole purpose of the taxonomy—to make the tasks easier to follow and understand. Feel free to innovate to suit your purposes. Tier II and tier III formats are often mixed together. If it works, use it.
The Difference in Format Between Tier II and Tier III Documents At this point in our discussion, it would be best to give an example of the differences in format between our recommended tier II process document/SOP/quality plan and a tier III procedure/work instruction. For this purpose, we will describe an overly simplified design engineering process document for Apogee E&M Inc. (see Table 6.3). The table lacks the usual logo and document control features such as approvals and dates and the revision level. It could be either a hard-copy or online document. The Standard's paragraphs will also be indicated so that you can see how the Standard can be used as an effective template in the creation of process documents. Most readers will feel that the process document is similar to an SOP or quality plan or control plan, and they are correct.
ISO Par. | Design phase | Activity | Managed by... | Inputs | Outputs | Resources/Controls | Link to Document |
---|---|---|---|---|---|---|---|
7.3.1 | 1.0 | Design planning | Engineering manager | Marketing requirements document | Program plan Team assignments | Gantt charts Team meetings | Form E-1 Form E-2 |
7.3.2 7.3.4 | 2.0 | Design inputs | Program manager | Planning documents Regulatory requirements | Specification first draft Design review (DR) Records | DRs | Form E-3 Form E-4 DR procedure |
7.3.3 | 3.0 | Design output | Project engineer | Specification first draft | Released specification DR records | DRs | Form E-5 Design review procedure |
7.3.5 | 4.0 | Design verification | Project engineer | Released specification Verification test plans | Product verification reports Engineering change notices (ECNs) DR records | DRs ECN board Calibrated test equipment | Form E-6 DR procedure ECN procedure Verification test procedure Metrology procedure |
7.3.6 | 5.0 | Design validation | Project engineer | Released specification Product verification reports ECNs Validation test plans | Product validation reports ECNs Acceptance test equipment Bill of material (BOM) Design transfer package DR records | DRs ECN board Calibrated test equipment Customer inputs Marketing and sales inputs Customer-service inputs Operations inputs | Form E-7 DR procedure ECN procedure Validation test procedure Metrology procedure |
7.3.6 | 6.0 | Transfer to operations | Program manager | BOM Design transfer package | Release to operations Pilot line testing | Acceptance test equipment and procedures | Form E-8 Transfer to operations procedure |
We will then illustrate a tier III procedure that is linked from the process document to show how self-evident the differences are between the two formats. The tier III procedure will deal with the transfer of product from engineering to operations (see Table 6.4). The location of this procedure in Table 6.3 is highlighted with underlining. Again, the usual document control features are missing for the sake of expediency.
Transfer Steps | Step Description | Step Activities | Date Planned | Link to Document |
---|---|---|---|---|
1.0 | Hold initial ECN transfer to operations review | 1.1 Transfer bill of material (BOM) and engineering transfer package to operations 1.2 Transfer acceptance test equipment to operations | 1.1 Jan. 02 1.2 Feb. 02 | Form E-8 Test equipment operators manual |
2.0 | Review manufacturing plan | 2.1 Review manufacturing engineering manufacturing plan 2.2 Schedule initial pilot run (10 units) | 2.1 Mar. 02 2.2 April 02 | Form ME-1 Form ME-2 |
3.0 | Run initial pilot line (10 units) | 3.1 Monitor and analyze data and prepare NCMRs as required 3.2 Prepare ECNs based on NCMRs as required | 3.1 May 02 3.2 May 02 | Form ME-3 Form E-6 |
4.0 | Initial manufacturing engineering review | 4.1 Review results of initial pilot run 4.2 Review ECNs and take appropriate action 4.3 Close open NCMRs 4.4 Plan for final pilot run (25 units) | 4.1 June 02 4.2 June 02 4.3 June 02 4.4 June 02 | Records of initial pilot run Records of ECNs Records of NCMRs Form ME-4 |
5.0 | Run final pilot line (25 units) | 5.1 Monitor and analyze data and prepare NCMRs as required 5.2 Prepare ECNs based on NCMRs as required | 5.1 July 02 5.2 July 02 | Form ME-3 Form E-6 |
6.0 | Final manufacturing engineering review | 6.1 Review results of final pilot run 6.2 Review ECNs and take appropriate action 6.3 Close open NCMRs 6.4 Schedule final release review | 6.1 Aug. 02 6.2 Aug. 02 6.3 Aug. 02 6.4 Aug. 02 | Records of final pilot run Records of ECNs Records of NCMRs Form E-8 |
7.0 | Hold Final ECN transfer to operations review | 7.1 Transfer final BOM and engineering design package | 7.1 Sept. 02 | Form E-8 |
Please note that the format for Table 6.3 is highly idealized to illustrate the classical approach to process documentation. Most writers use the more familiar SOP format. Either way is fine as long as the required information is included (i.e., the design phase, activity, responsible management, inputs, outputs, resources, and controls required), and linkage to pertinent lower tier documents to aid in QMS document navigation.
|