Difference between revisions of "SCC QSP Product Lifecycle Management"
m (→Part Sources)
m (→Part Source (Supply Chain) (4.1.4))
|Line 135:||Line 135:|
==== Part Source (Supply Chain) (4.1.4) ====
==== Part Source (Supply Chain) (4.1.4) ====
the source part is of . of a partmay manufacturer a custom partoften are .
is critical, the designer part and OEM part number).
==== Supporting Documents (4.1.5) ====
==== Supporting Documents (4.1.5) ====
Revision as of 14:34, 22 October 2018
Reference: ISO 9001:2008 Element 7.1 Planning of product realization
- 1 Purpose (1.)
- 2 Scope (2.)
- 3 Responsibility and Authority (3.)
- 4 Procedure (4.)
- 4.1 Part Identification (4.1)
- 4.2 Change Management (4.2)
- 4.3 Iterations and Current Data
- 4.4 Procedure
- 4.5 Design notes
- 4.6 Detailed Requirements
- 5 Related and Support Documentation (5.)
To establish a procedure for the control and management of SCC product data.
Product data is information associated with a specification for both the design and the manufacturing process of a product. Product data typically includes part numbers and part names, supplier and manufacturer specifications for commercial-off-the-shelf (COTS) items, engineering fabrication and assembly drawings, electronic circuit schematics, electronic circuit board fabrication files, component specifications, manufacturing work instructions and process descriptions, test procedures, etc. Product data does not include information associated with manufactured product, such as serial numbers, test results, material incoming quality inspection reports, inventory quantities, etc.
Product data should be captured during the design stage of a project as parts are selected and/or designed. The most common use of product data is in the manufacturing process (including purchasing). However, the data is available to all SCC departments, including sales, project and product management, technical product support, marketing, purchasing, shipping, finance. etc.
This procedure applies to all product designed and manufactured by the SCC.
|COTS||Commercial-off-the-shelf||relatively generic item which is readily available in stock from either a reseller or the manufacturer.|
|OEM||Original Equipment Manufacturer||Applies to commercial off-the-shelf items and refers to the original manufacturer of a part to distinguish them from a manufacturer who incorporates OEM parts in the products they manufacture.|
|Part||Part||A unique identifier for a part. SCC part numbers are entirely numeric, but some companies may use alpha-numeric part numbers, or even fully alphabetic part numbers.|
|PBS||Product Breakdown Structure||A diagram which provides a clear and unambiguous statement of how the product is constructed in an exhaustive, hierarchical tree structure arranged in whole-part relationship. A PBS is similiar to a work breakdown structure (WBS) diagram, but includes only the physical architecture of a product.|
|PN||Part Number||A unique identifier for a part. SCC part numbers are entirely numeric, but some companies may use alpha-numeric part numbers, or even fully alphabetic part numbers.|
|REL||Release||A part is (or must be) released when its developer or specifier shares information about the part for others to use (for example, for purchasing or manufacturing). Releasing a part implies that any subsequent changes to the part's specification follow a controlled visible process - as a minimum, maintaining the revision level for the part and for relevant supporting documents. The release process for a part may also include a formal review and peer or supervisor approval.|
Also refer to SCC QSR Terminology.
Record Retention (2.2)
Product data history must be maintained for ever.
Responsibility and Authority (3.)
The Dir., Manufacturing, has responsibility and authority for the maintenance of this procedure.
Product data generally falls into one of three categories:
- SCC Part Number and Name, Supplier & Supplier PN, OEM & OEM PN
- Supporting documents
- Supporting information
Product data should be captured throughout the design stage of a product development project (refer to SCC QSP Project Management). Development teams are encouraged to capture product data as soon as possible because the amount of work can become overwhelming if delayed until the design is complete.
Product Lifecycle Management +-- Idea Process | |-- Idea Document | \-- Idea Gate Review Meeting Minutes +-- Requirements Process | |-- Requirements Document | \-- Requirements Gate Review Meeting Minutes +-- Design Process | +-- Preliminary Design | | +-- Determine preliminary product breakdown hierarchy | | +-- Assign part numbers to well understood parts | | \-- Submit documents to Maestro PLM | +-- Detailed Design (for each subassembly) | | +-- Determine detailed product breakdown hierarchy | | +-- Assign part numbers to sub-assemblies | | +-- Design or specify sub-assemblies | | \-- Submit documents to Maestro PLM | \-- Design Gate Review Meeting Minutes +-- Test Process | |-- Test Procedure Document | |-- Test Results Document | \-- Test Gate Review Meeting Minutes +-- Pilot Process | |-- Process Documentation | \-- Pilot Gate Review Meeting Minutes \-- Termination Process \-- Termination Gate Review Meeting Minutes
Part Identification (4.1)
A part is identified by a unique part numbers and descriptive name so that it can be referred to without ambiguity. Parts can also be revised to correct defects or add functionality, so long as they revised part remains backwards compatible.
Part Number (4.1.1)
Each part managed by the SCC in some way is assigned a unique part number and a descriptive title. A part can be revised to correct defects or enhance functionality, but a revised part must remain backwards compatible - otherwise a new part (i.e. a new part number) should be created. A part also has a revision level, identifying a specific stable state in the part's lifecycle.
An SCC part number is an 8-digit numeric value. The first digit designates a category called the Part Class, and is assigned according to the following table. The remaining 7 digits are sequentially assigned on demand per class (starting at 1).
|1||Mechanical Custom||Custom mechanical part.|
|2||Electronic Custom||Custom electronic or electrical part.|
|3||Software||Software files managed as a part, e.g. a desktop application. Software files that support a physical part, such as a hex file loaded onto a PCA during manufacturing, are identified with the part number of the supported part.|
|4||Chemical||Chemical products, typically used in the manufacturing process.|
|5||Document||Documents that are managed as a part, e.g. a user's manual. Documents that support a physical part, such as a work instruction, are identified with the part number of the supported part.|
|6||Field Repair Kit||Collection of typical parts required for field maintenance.|
|8||Mechanical COTS||COTS mechanical part.|
|9||Electronic COTS||Electronic or electrical COTS part.|
Revision Level (4.1.2)
The revision level of part is as important as its part number. A part is initially released at revision level "0" (zero). If a part is revised such that it is physically different (e.g. to correct a unforeseen design defect, improve quality, or reduce cost) but remains backwards compatible (the revised part can be substituted for the earlier version), its revision level is incremented. If the change is not backwards compatible, a new part number should be created for the revised part.
Part Name (4.1.3)
An SCC part name is determined by referring to the SCC QSR Part Name.
Part Source (Supply Chain) (4.1.4)
Information on the source of a part is a critical component of product data. In the case of a COTS part, similar parts may be available from more than one manufacturer although only one may be acceptable. In the case of a custom part, although multiple fabricators may claim to be capable of producing the desired part, often only qualified suppliers are to be used.
When the source for a part is considered critical, the designer will include recommended or alternative suppliers in product data (vendor and vendor part number, and/or OEM and OEM part number).
Supporting Documents (4.1.5)
Supporting documents provide additional information relating to a part, such as fabrication and assembly drawings, test procedures, datasheets and CAD/CAM files. A supporting document may need to be approved for it to be trusted.
Document Category (188.8.131.52)
Supporting documents are categorized to simplify identification and standardize on their use according to the following table.
|APP||Application Note||Document describing application, use, and/or operation of an item.|
|ART||Artwork||Artwork file used in the fabrication of an item (E.g. chassis silkscreen artwork, display bezel artwork, etc.).|
|ASSY||Assembly Drawing||Mechanical assembly drawing used for reference in manufacturing or assembly process.|
|CAM||CAM Files||Data file or files for the Computer Aided Manufacturing (CAM) of a part. For PCB manufacturing, typically a ZIP-format archive containing Gerber-format files, a photo-aperture specification file, a drill specification file, and a text readme file, and sometimes also accompanied by a PCB master drawing and SMT manufacturing files.|
|DOC||Ad Hoc Document||Document not having an applicable specific category.|
|DS||Data Sheet||Vendor or manufacturer data sheet for a bought-out-finished item.|
|DSN||Design Archive||Native-format application design file (e.g. *.DWG, *.SCH, *.PCB) or ZIP-format archive containing multiple related design files.|
|ECO||Engineering Change Order||Description and approval document for a product data change.|
|FAB||Fabrication Drawing||Reference drawing for mechanical fabrication of a custom item.|
|MA||Master Drawing||Typically in reference to printed circuit board fabrication and specifies mechanical features of the board, including layer stackup, and also includes specifications for the manufacturing process and acceptance criteria for the finished product.|
|MSDS||Material Safety Data Sheet||Material Safety Data Sheet (or equivalent) for a a bought-out-finished item.|
|PBS||Product Breakdown Structure||Diagram illustrating how a product is constructed using a hierarchical tree structure.|
|PRJP||Project Plan||Guiding document for the execution and management of a product development project, including product requirements, schedule, business case analysis, etc. (optionally multiple documents in a ZIP-format archive file)|
|QSF||Quality System Form||A template document which when completed or annotated becomes a QSR (quality system record).|
|QSP||Quality System Procedure||A procedure referenced in the SCC QSM, but of sufficient complexity to warrant management in the DMS instead of the Knowledge Base.|
|QSR||Quality System Record||A document or data demonstrating compliance with a QSP (quality system procedure) or WI (work instruction). A QSR may be a completed QSF (quality system form), but can also be an ad hoc record as directed by the QSP or WI, or even a copy of a log book entry.|
|QUO||Quotation||Estimated price for item or process. Provides an example at the time the item was released in anticipation of possible future reference. No attempt is made to keep the quote current.|
|SCH||Schematic Drawing||Symbolic electrical connectivity drawing. The PN associated with an SCH-type part-file is the PN of the PCA (not the PCB).|
|SW||Software File||Source code or binary software application program file or hardware description file.|
|TDO||Temporary Deviation Order||Description and approval for a informal change to product document set, similar in function to an ECO but temporarily in effect and without any changes to product documentation. Most often used to accommodate temporary minor issues affecting a manufacturing process currently underway. If the change described by the TDN has significant risk, an ECO should be used instead and the change fully documented.|
|TST||Test Procedure||A manufacturing test procedure including pass/fail criteria. In very simple cases, the manufacturing test procedure may be incorporated into a Work Instruction. In complex cases, there may be multiple test procedures, and may include design verification test procedures, and automated test program files.|
|WI||Work Instruction||A process description, most often for manufacturing, assembly, test or inspection of a item. May include a simple Test Procedure and pass/fail criteria.|
Document Filenames (184.108.40.206)
The filename for a document submitted to the SCC Quality Management system is arbitrary, but the following conventions are recommended for clarity. A document's filename provides context for the part outside of the SC Quality Management System. A document's filename depends on whether it supports a custom part or a COTS part.
Custom Part Document
The filename for a document supporting a custom part is based on:
- the part number the document is associated with
- the document category
- a two-digit version (from 0 to 99)
- optional short descriptive text
The preferred filename syntax is:
with the following rules:
- A space character shall not be used in the filename to simplify management and retrieval (different applications and operating systems treat spaces within filenames differently).
- An underscore character shall only be used to separate the PartNumber from the PartFileCategory (so that the part number can be easily parsed from the filename).
- The complete filename shall be no more than 64 characters (so that it can be written without truncation to a data-format CD, should it be necessary).
|20000001_WI-01.odt||Work instruction revision 01 for part 20000001|
|20000002_QUO-00-APC-2010-02-02.pdf||Quote from APC for part 20000002 provided 2010/02/02|
|90000001_DSN-00.odt||Design file version 00 for part 90000001 in ODT format|
|90000001_DSN-00.pdf||Design file version 00 for part 90000001 in PDF format|
The filename for a document supporting a COTS part is not required to follow the same naming convention, although it is desired. As a minimum, spaces within the filename should either be removed or replaced with hyphens or underscores.
The filename for a document supporting a COTS (commercial-off-the-shelf) part is based on:
- the manufacturer of the part
- the manufacturer's part number
- short descriptive text
|Hammond-9c2pg42-43.pdf||Hammond datasheet for model 9c2, page 43-43 in catalogue|
|Keystone-M55-prod31.pdf||Keystone datasheet for product M55|
|Belden-8085.pdf||Belden datasheet for product 8085|
|Scotch-Vinyl-Electrical-Tape.pdf||Scotch-brand datasheet for vinyl electrical tape|
Part Inventory Category (4.1.6)
Inventory categories are used to group like parts for reporting, and it is convenient to include inventory category in product data.
|ELEC||Electrical and Electronic parts|
|RADIOS||Product line finished goods|
Part Stock Class (4.1.7)
Parts are members of a stock class, which is used for managing and reporting on stock on hand. Although not directly related to product data, the stock class helps to understand the impact of making a change to product data.
|FIN||Final Assembly||aka Catalog|
|HDWR||Hardware||aka Shop Supplies|
|RAW||RAW||in same condition as received|
Change Management (4.2)
The following points should be considered when modifying a part or assembly.
- The ECO process applies to all parts, and ECO approval recursively approves all unapproved child parts. However, seeking approval of a part is encouraged as soon as it is defined to reduce the amount of work (and potential for error) that can come when its approval is included as part of a large and complex parent part.
- Any part offered for sale, or associated with the sale of a service, shall be approved through the ECO process before any such sale or provision of an associated service.
- It shall be left to management's judgement when the risk associated with a part justifies the effort of taking it through the ECO approval process (consider also that once approved, any changes to the part must also be taken through the ECO approval process).
A change either affects the way the part is used or does not. This is often referred to as the fit, form, function test, but must be considered in the context that the part is used in. The action taken depends on whether the part is a bought-out-finished part (the specification is determined and/or provided by the supplier or manufacturer of the part), or whether it is a custom part (the specification is provided by the SCC).
- Parts modified such that their use is not affected:
- BOF parts - relevant part-files must be updated and the revision level associated with the part number is not changed (it is common for a BOF part to not be assigned a revision level). ECO approval is not required, although the appropriate approval authority must approve the updated part-files (which will typically be the Dir., Engineering).
- Custom parts (including assemblies) - relevant part-files are updated and the revision level associated with the part-files and the part number must be incremented. ECO approval is required.
- Parts modified such that their use is affected:
- BOF parts and custom parts (including assemblies) - a new part number shall be issued with the new part name indicating in some way the characteristic or parameter that has changed. New part-files must also be captured. ECO approval is required.
When part-files require updated, care must be taken to ensure all sources files are also updated. For example, if a work instruction source file is updated and a new PDF version published and submitted to the DMS, the updated source file must also be updated in the DMS. If the source file in the DMS is not updated, the inconsistent source and PDF versions in the DMS will lead to confusion, the updated source will not be available to others for future maintenance, and the updated source file may easily be lost.
When a part-file has been updated, it must be obvious by visual inspection which version of the part-file is being viewed. This is most easily accomplished by including the revision level in a drawing title block or document header or footer. The filename of the part-file need not be modified.
When a part-file is revised and the new version submitted to Maestro, the submitter should provide a explanation and justification for the change.
When an assembly (a custom part which is an assembly) is updated (i.e., its revision level is incremented), the Engineering Change Order (ECO) process must be followed.
TODO: CREATE "SCC QSP ECO" (Engineering Change Order Quality System Procedure)
Iterations and Current Data
Part data in Maestro (part documents, parts lists, etc.) is "controlled", meaning that changes to part data are identified, and if warranted a new baseline is created (called an Iteration). Previous iterations can be reviewed, and even reverted to should it be necessary (e.g. should a change be found to be premature or unwarranted).
"Current" data can be brought into Maestro from external systems for control. Current data can be considered "new" (parts not yet in Maestro), "modified" (modifications to a part already in Maestro), or "old" (a part already in Maestro and unchanged in the current data).
The "Revision Level" of a part is an arbitrary identifier assigned by its originator or author (e.g. version 1, 1A, 1B, 2... in the title block of a mechanical drawing).
A part is "Iterated" when some critical information about the part is modified (such as a mechanical fabrication drawing or the electronics schematic for an assembly). Maestro can automatically detect when the current data has changed, and if the changes involve critical information Maestro will create a new iteration of the part for the changed information. The sequence of iterations for a part can be reviewed, including accessing the information or files associated with each iteration.
When loading current data from an external system:
- Old data is ignored.
- New data is added.
- Modified data causes the part to iterate when one of the following occurs, otherwise modified data overwrites controlled date (the last_updated_date and last_updated_by are still updated to reflect that a change has occurred):
- the parts list for the part has changed,
- the file list for the part has changed (i.e. a document has been added or removed)
- the revision assigned by the author has changed (i.e. the pv_pn revision field)
Previous iterations are accessible, including previous Parts Lists and File Lists.
I haven't thought through all the details, but think it will involve something like:
- each "iteration" of a part will need to be a unique entry in the pv_pn table (i.e. new iteration field needed in pv_pn)
- entries in the pv_pl table will need to reference a specific iteration of a part in the pv_pn (i.e. new iteration fk needed in pv_pl)
When a document is modified in a Windows share without changing its filename, the document already in maestro will have its filename modified to include a timestamp suffix (this will be done by rsync) and the newest version will keep its filename. If a document has been associated with a part (pv_fil table), the association will continue so long as the file name is not changed. Maestro will provide a document history view which shows the previous (time-stamped) versions of a file associated with a part.
- Part number. Any combination of letters, numbers and special characters (e.g. "-", ":"). An appropriate part number can be suggested based on user criteria.
- Descriptive text fields (2): Title, Detail
- Part Type, Status, Revision, Date, Unit of Measure (Use-As), By
- User-defined fields (10).
- Reference to associated files or web address (unlimited).
- Where Used parent listing.
- A single-level parts list of an assembly can be viewed in a configurable grid, that can be searched, filtered and exported to a CSV file.
- A complete multi-level parts list of an assembly can be viewed in an assembly tree, individual levels of hierarchy can be expanded or hidden as desired.
- A vintage is a virtual parent for a group of compatible assemblies.
Sources (Vendors and Manufacturers)
- Items are related to a Vendor to control the source for purchasing.
- Items can also be optionally related to a Manufacturer to prevent substitution when a vendor provides similar product from more than one manufacturer, or when a manufacturer's product is available from more than one vendor.
- Vendor Master data includes contact information, notes, account and terms, web address...
- Manufacturer Master data includes contact information, notes, web address...
- Vendor Unit of Measure (Buy-As units).
- Lists child items required to build an assembly, child items can themselves be assemblies (i.e. kitting for multi-level assembly).
- Categorization. Documents can be associated with one or more part numbers, and categorized according to a customizable list of categories.
- Centralized Storage Concept. Documents are conceptually stored in a centralized location, simplifying finding and controlling documents.
- Controlled Access. New documents are visible by default to all users unless access is specifically restricted for reasons of confidentiality. Access may be based on the user's department or level of authority.
- Change Control. Document changes are captured in an audit trail, changes can be verified and reversed.
- Document Category. Documents can be assigned a category from a predefined list.
- Change Notification. Users are notified by e-mail when a document requires their attention (e.g., review, approval, training certification, etc.). Users can also chose to monitor a document and be notified of any activity.
- Item, Assembly, Vendor and Manufacturer master data can be searched using a variety of criteria.
- Searches can optionally be saved for personal or global use.
- PDF-type reports can be viewed and/or saved.
- Notifications (e.g. email) of product data changes (e.g. new part number, modified work instruction, etc.).
Importing and Exporting
- Export any view to a CSV delimited ASCII text file.
Reports are any regular information being reported on, and may be a live dashboard type of report or a one-off or scheduled email report in PDF format (e.g. every day, first Monday of every month...).
- Number of new part numbers created by month for current/previous year (e.g. bar graph).
|Controlled Data||-||Data in Maestro is controlled, meaning any changes are made following a formal process with logging and auditing capability.|
|COTS||Commercial-off-the-shelf||Means the item is generally available in the market as a standard product, and can be readily purchased from a reseller or direct from its manufacturer.|
|Current Data||-||Current data is uncontrolled data with no history being brought into Maestro for control. Compared to controlled data, current data is "new" (not yet in Maestro), "modified" (changes to data already controlled), or "old" (already controlled and unchanged).|
|Iteration||-||A stable product data state or baseline. A part iterates when critical product data has changed, such as when the parts on a parent part's Parts List are changed.|
|OEM||Original Equipment Manufacturer||The original manufacturer of an item. Distinguishes a vendor or value-added reseller from the manufacturer of an item|
|Part||-||An design element in the hierarchical product structure. A part may be composed of one or more child parts, or may itself be a child of a parent part.|
|PBS||Product Breakdown Structure||A diagram which provides a clear and unambiguous statement of how the product is constructed in an exhaustive, hierarchical tree structure arranged in whole-part relationship. A PBS is similar to a work breakdown structure (WBS) diagram, but includes only the physical architecture of a product.|
|PCA||Printed Circuit Assembly||An assembly consisting of a printed circuit board (aka printed wiring board) with mounted or soldered components.|
|PCB||Printed Circuit Board||A bare printed circuit board (aka printed wiring board), with no mounted or attached components.|
|PN||Part Number||A unique identifier for a part. SCC part numbers are entirely numeric, but some companies may use alpha-numeric part numbers, or even fully alphabetic part numbers|
|Rev||Revision Level||An arbitrary identifier assigned by the originator or author to a stable part or document state (e.g. Revision 0, 1, 1A, 1B, 2).|
|Release||-||A release is the act of publishing product data at an arbitrary stable point, tagged for common reference using a unique "Rev" identifier. A release can be for a single part, or a complete complete hierarchical assembly can be released, including any child parts not already released. A part should be Released when information about the part must be formally shared with others (e.g. for purchasing or manufacturing). Releasing a part may include a formal review and approval process.|