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
|
||||
--------
|
||||
|
|
@ -0,0 +1,9 @@
|
|||
*********************************
|
||||
Information Management Procedures
|
||||
*********************************
|
||||
|
||||
.. toctree::
|
||||
|
||||
information_management_plan
|
||||
document_management
|
||||
|
||||
|
|
@ -0,0 +1,126 @@
|
|||
Information Management Plan
|
||||
===========================
|
||||
|
||||
Purpose
|
||||
-------
|
||||
This plan is the highest-level description of how information is
|
||||
managed at |inst|. It defines the information management requirements
|
||||
and explains the chosen processes and tools that meet the requirements.
|
||||
|
||||
Scope
|
||||
-----
|
||||
This plan applies to creation, storage, exchange, and retirement of project
|
||||
information related to |project|. This includes plant configuration management
|
||||
data as defined in :cite:p:`barrieroInformationManagementProcess2010`. The plan
|
||||
is not limited to information affecting quality, it also includes business
|
||||
information.
|
||||
|
||||
|
||||
Background
|
||||
----------
|
||||
The potential benefits of the digital transformation are well known across all
|
||||
business sectors. Numerous commercial nuclear information management studies
|
||||
have further suggested that properly implemented information management can improve
|
||||
efficiency and quality while reducing costs
|
||||
:cite:p:`halpinInformationManagementNuclear1978d,agencyInformationTechnologyNuclear2010,barrieroInformationManagementProcess2010,renuartAdvancedNuclearTechnology2014`
|
||||
In addition, management of information related to product quality is subject
|
||||
to nuclear quality regulations in all jurisdictions.
|
||||
|
||||
Requirements
|
||||
------------
|
||||
|
||||
.. req:: Quality-related information shall be managed in accordance with 10 CFR 50 Appendix B
|
||||
:id: R_INFO_APPB
|
||||
:links: R_10CFR50_APPB
|
||||
:tags: quality
|
||||
:basis: Compliance with Appendix B is necessary for licensing
|
||||
|
||||
Note that non-quality related information is not necessarily subject
|
||||
to this requirement.
|
||||
|
||||
.. req:: A data dictionary shall be maintained defining controlled data
|
||||
:id: R_DATA_DICT
|
||||
:basis: It will provide a central reference for all project members to
|
||||
find specific, precise, and up-to-date data definitions to enable
|
||||
unambiguous communications and collaboration.
|
||||
|
||||
The dictionary shall define data types, data fields, constraints on the
|
||||
fields, relationships between the data, source, sensitivity, usage,
|
||||
owner/steward, sample values, and transformation logic, as applicable. It
|
||||
shall be revision controlled such that changes can be clearly seen and
|
||||
remembered.
|
||||
|
||||
.. req:: Data shall be managed such that data exchanges and transformations between
|
||||
parties and systems can be readily automated
|
||||
:id: R_DATA_EXCHANGE
|
||||
:basis: Over the project life, numerous parties and systems will ramp up
|
||||
and down due to changing relationships and technologies. Automated data
|
||||
exchanges are expected to improve the ease, cost, speed, and quality of
|
||||
the inevitable exchanges and transformations.
|
||||
|
||||
This effectively requires rich data import and export capabilities
|
||||
in each tool used to manage data.
|
||||
|
||||
.. req:: Data shall be subject to role-based access controls (RBAC) or stronger
|
||||
:id: R_DATA_ACCESS
|
||||
:basis: Role-based access control (RBAC) is a strong standard
|
||||
covering the needs of commercial nuclear information
|
||||
from export control and business sensitivity perspectives.
|
||||
|
||||
More sensitive data, such as Security Related Information,
|
||||
may use stronger access controls such as ABAC or MAC.
|
||||
|
||||
Implementation
|
||||
--------------
|
||||
This section defines the specific implementation of the requirements.
|
||||
|
||||
General principles
|
||||
^^^^^^^^^^^^^^^^^^
|
||||
A hub data architecture has been chosen for this project, based on
|
||||
arguments and experiences in :cite:p:`agencyInformationTechnologyNuclear2010`.
|
||||
|
||||
.. figure:: /_static/data-hub.png
|
||||
|
||||
Hub architecture, from :cite:p:`agencyInformationTechnologyNuclear2010`
|
||||
|
||||
This is designed to enable rapid integration of a wide variety of partner
|
||||
organizations, specialized information management tools, and engineering/design
|
||||
tools while striving to future-proof the multi-decade project.
|
||||
|
||||
The underlying data layer consists of:
|
||||
|
||||
* Structured text (e.g. YAML, XML, JSON) controlled in version-controlled repositories
|
||||
* Databases (e.g. Postgres)
|
||||
* Documents/drawings (PDFs, native files, HTML) stored on corporate drives and managed
|
||||
by the Records Management/Document Control system
|
||||
* Technical data (3D models, simulation input/output, laser scans, schedule dumps) stored
|
||||
on corporate drives, managed by the Technical Data Management system
|
||||
|
||||
Above the data layer sits the data authoring and manipulation layer, which includes:
|
||||
|
||||
* Office tools: word processors, spreadsheets, text editors, IDEs, etc., including
|
||||
online collaboration tools
|
||||
* PM tools: Primavera P6, HR tools
|
||||
* Engineering tools: SolidWorks, ANSYS, CASMO, MCNP, Intergraph, Revit
|
||||
* Construction tools
|
||||
* Maintenance tools
|
||||
|
||||
One-way or bidirectional data exchanges between tools and institutions occur
|
||||
through the API, which reads the data layer and presents data representations to
|
||||
authorized users or services in clearly-defined formats over the network.
|
||||
|
||||
.. _info-mgmt-data-dict:
|
||||
|
||||
Data Dictionary
|
||||
^^^^^^^^^^^^^^^
|
||||
The data dictionary is defined and maintained as described in
|
||||
:need:`I_DATA_DICT`.
|
||||
|
||||
The data dictionary itself is located at :ref:`data-dict`.
|
||||
|
||||
|
||||
.. insert render of the data dictionary table here.
|
||||
|
||||
Technology stack
|
||||
^^^^^^^^^^^^^^^^
|
||||
.. insert render of the IT systems table here.
|
||||
Loading…
Add table
Add a link
Reference in a new issue