296 lines
10 KiB
ReStructuredText
296 lines
10 KiB
ReStructuredText
.. _rmdc-proc:
|
|
|
|
Records and Document Management Procedure
|
|
=========================================
|
|
This procedure governs the creation, intake, maintenance, authorization,
|
|
distribution, and retention of :term:`Records <Record>` and :term:`Documents
|
|
<Document>`.
|
|
|
|
Purpose
|
|
-------
|
|
Systematic management of Records and Documents helps teams execute
|
|
large, long-term, and complex projects in a coordinated fashion.
|
|
Furthermore, management of quality-related documents is required by
|
|
regulations. This procedure implements the following requirements:
|
|
|
|
.. impl:: Define processes for lifetime records
|
|
:links: R_GDC_01_04
|
|
|
|
.. impl:: Define processes for Document Control
|
|
:links: R_APPB_45
|
|
|
|
.. impl:: Define processes for Quality Records
|
|
:links: R_APPB_79
|
|
|
|
Roles
|
|
-----
|
|
Roles involved in this procedure include:
|
|
|
|
Originator
|
|
Person who authors a new or revised document
|
|
|
|
Reviewer
|
|
Person who is assigned to review a submitted document, checking for quality
|
|
and content
|
|
|
|
Approver
|
|
Person in the releasing organization who is authorized to mark a document as
|
|
Approved, thereby enabling its use across the project.
|
|
|
|
Manager
|
|
Person in any organization who is authorized to request document reservations
|
|
|
|
RMDC Staff
|
|
Person responsible for receiving documents and administering :term:`RMDC` IT
|
|
systems such as the :term:`EDMS`
|
|
|
|
Staff
|
|
Person in any organization who is authorized to access or submit project
|
|
documents/records
|
|
|
|
Procedure
|
|
---------
|
|
|
|
.. _rmdc-access:
|
|
|
|
Accessing a document/record
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
Internal project staff shall follow these steps when seeking documents or records
|
|
to perform project work.
|
|
|
|
* **Staff** navigates to the project :term:`EDMS` as defined in :ref:`rmdc-systems`
|
|
* **Staff** searches EDMS for desired document/record by number, title, and/or other fields
|
|
* **Staff** checks ``status`` field and ensures they choose a revision that is
|
|
approved for their current work task (generally this requires an APPROVED status).
|
|
* **Staff** checks the ``usage`` field and ensures to choose a revision with a
|
|
usage marking that is appropriate for their current work task.
|
|
* **Staff** accesses the file(s) via the EDMS download or access feature
|
|
* If an expected Document/Record cannot be found, appears to have erroneous data, or
|
|
is not accessible, **Staff** contacts **RMDC Staff** for assistance
|
|
|
|
|
|
.. _rmdc-origination:
|
|
|
|
Originating a new document/record
|
|
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
|
|
New records and new or revised documents are originated as invoked by other procedures
|
|
and processes, or by third parties. The following steps shall be taken whenever a new
|
|
document or record or document reservation is requested, created, or received:
|
|
|
|
* **Staff** shall specify document data defining the new record/document in
|
|
accordance with the content rules listed in :py:class:`nrsk.models.Document`
|
|
|
|
* Required:
|
|
|
|
* Title --- a single-line description of what the record/document is
|
|
* Record/document type --- This determines template, review, and
|
|
retention rules. Should be from :ref:`rmdc-doctypes`
|
|
* Originating organization --- the organization or group assigned primary authorship.
|
|
Internally-generated records/documents shall be contained on the :ref:`org-chart`, while
|
|
others should be the name and department of external entities.
|
|
|
|
* Optional
|
|
|
|
* Keywords --- words or phrases to assist in future searches/lookups
|
|
|
|
|
|
.. impl:: Require document index to be updated upon origination
|
|
of any new document or record
|
|
:links: R_APPB_83
|
|
|
|
Updating the index at the point of creation is a robust
|
|
way to ensure compliance that each document/record will always
|
|
be discoverable and retrievable.
|
|
|
|
|
|
Intake
|
|
^^^^^^
|
|
Upon receipt of Document/Records from an external party, the following process shall occur:
|
|
|
|
* **Receiver** determines whether the Document/Record is eligible for
|
|
entry into the Document Index.
|
|
* **Receiver** inspects Document Index to ensure consistency with the Index and the
|
|
received Document
|
|
|
|
* If the received document/record is not already listed in the Document Index, then
|
|
**Receiver** takes on the role of **Originator** and follows the process in
|
|
:ref:`rmdc-origination`.
|
|
* If the data is incorrect or outdated, **Receiver** updates the data
|
|
|
|
* **Receiver** uploads the received file(s) to the EDMS.
|
|
* **Receiver** updates metadata in the Document Index, including the latest
|
|
revision number, authors, received date, and location/URL in the EDMS
|
|
* **Receiver** assigns acceptance review task to appropriate person based on
|
|
the work breakdown structure that the document was produced under.
|
|
* **Reviewer** views Document Index and downloads file(s) as listed
|
|
* **Reviewer** inspects files and performs acceptance review as appropriate, potentially
|
|
generating a Review Record
|
|
* **Reviewer** updates Document Index acceptance metadata field according to review
|
|
* If the document/records are not accepted, **Reviewer** informs originating
|
|
institution of deficiencies and requests update
|
|
|
|
Document/Record data management
|
|
-------------------------------
|
|
|
|
.. _rmdc-doctypes:
|
|
|
|
Record/Document Types
|
|
^^^^^^^^^^^^^^^^^^^^^
|
|
One of the following record/document types should be assigned to each
|
|
record/document. The types are generally associated with specific forms or
|
|
templates that include the expected content/sections, and are often created to
|
|
satisfy the needs of a lower-level procedure.
|
|
|
|
.. impl:: Define numerous Record/Document types
|
|
|
|
There is a timeless debate about having too many vs. too few doc types.
|
|
Additional types are added to support more mature procedure sets, but then
|
|
people start to struggle to know what type they should use, leading to
|
|
cleanup efforts, followed by management declarations to reduce the number of
|
|
types.
|
|
|
|
A good solution to this problem is to be very explicit in your procedural
|
|
culture. Ensure that whenever a record or document is being originated, that
|
|
each staff member has the relevant procedure open and is following it
|
|
precisely. Ensure that the procedures are rigorous and precise about which
|
|
record/document types should be generated in each scenario. When a procedure
|
|
is written, ensure that any new record/document types are added to the list
|
|
of known types.
|
|
|
|
.. warning:: Don't make one rec/doc type for each individual checklist or form
|
|
in each procedure though. Those can all be forms. Or maybe do make them
|
|
all form subtypes? Could be nice to really have specific evidence.
|
|
Need easy way to make auto-generated forms per procedure then.
|
|
|
|
.. datatemplate:yaml::
|
|
:source: /_data/doc-types.yaml
|
|
|
|
{{ make_list_table_from_mappings(
|
|
[('Type', 'name'), ('Abbrev', 'abbrev'), ('Use case(s)', 'use_cases'),
|
|
('Record', 'record'), ('Retention', 'retention')],
|
|
data,
|
|
title='Record/Document types',
|
|
) }}
|
|
|
|
|
|
Document Numbering
|
|
^^^^^^^^^^^^^^^^^^
|
|
|
|
Document numbers (or IDs) are human-usable codes that uniquely identify
|
|
the document/record for purposes of cross-referencing and discussion.
|
|
|
|
All projects may use |inst| corporate-level document numbering as appropriate
|
|
in addition to the project-specific policies. Corporate number shall
|
|
|
|
For corporate-level documents/records not associated with any specific project
|
|
or system, the document numbers shall be of the form: ``AMS-{type}-00000``,
|
|
where {type} is the document type abbreviation in all CAPS, and the number
|
|
starts at 00001 and increments from there. When 100,000 or more numbers are
|
|
needed, the number continues increasing.
|
|
|
|
For project-level documents/records not associated with any specific system,
|
|
numbers shall be of the same form, but with ``{AMS}}`` replaced with the
|
|
project abbreviation, e.g. ``TTP``.
|
|
|
|
Documents/records associated with a specific project and system shall have document
|
|
numbers of the form:
|
|
|
|
``{proj}-{sys}-{type}-00000``
|
|
|
|
where `{sys}` is the system abbreviation in all CAPS.
|
|
|
|
Active projects and their abbreviations may be found in :ref:`projects`.
|
|
|
|
|
|
.. _rmdc-doc-status:
|
|
|
|
Document Statuses
|
|
^^^^^^^^^^^^^^^^^
|
|
Document Status indicates where a document or record is in its lifecycle, and
|
|
determines if and how it may be used in design or operation. Statuses fall into
|
|
three top-level categories. These statuses are derived from
|
|
:cite:p:`cloverDocumentControlRecords2010`.
|
|
|
|
.. autoclass:: nrsk.models.Document.STATUS
|
|
:no-index:
|
|
:no-members:
|
|
|
|
* **Not Yet Approved** --- The following statuses apply to Documents that
|
|
generally shall not be used to support plant design or operations:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.RESERVED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.IN_PROGRESS
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.IN_REVIEW
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.REJECTED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.REFERENCE
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.NATIVE
|
|
:no-index:
|
|
:no-value:
|
|
|
|
* **Approved** --- The following statuses apply to active documents that allow
|
|
plant design or operations:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.APPROVED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
* **No Longer Approved** --- The following statuses apply to documents
|
|
that are no longer approved for use other than reference:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.QUARANTINED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.SUPERSEDED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.REVISED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.VOIDED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. autoattribute:: nrsk.models.Document.STATUS.CLOSED
|
|
:no-index:
|
|
:no-value:
|
|
|
|
.. note:: These statuses are validated in the data dictionary
|
|
in :py:class:`~nrsk.models.Document`
|
|
|
|
.. _rmdc-systems:
|
|
|
|
Document/Record Management Systems
|
|
----------------------------------
|
|
|
|
Documents and records are managed in the following systems.
|
|
|
|
.. datatemplate:yaml::
|
|
:source: /_data/it-systems.yaml
|
|
|
|
{{ make_list_table_from_mappings(
|
|
[('Name', 'name'), ('Use case(s)', 'use_cases'), ('Location', 'location')],
|
|
data['RMDC'],
|
|
title='RMDC Systems',
|
|
) }}
|
|
|
|
|
|
See Also
|
|
--------
|