Reorg some procedures.
This commit is contained in:
Nick Touran
parent
e69b80b52c
commit
410ccd662c
7 changed files with 327 additions and 114 deletions
|
|
@ -0,0 +1,296 @@
|
|||
.. _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
|
||||
--------
|
||||
Loading…
Add table
Add a link
Reference in a new issue