Difference between revisions of "Documented knowledge lifecycle"
(→Related articles) |
DavidBeraha (Talk | contribs) (→Definition) |
||
| Line 1: | Line 1: | ||
==Definition== | ==Definition== | ||
| − | + | {{ {{PAGENAME}} }} | |
==Description== | ==Description== | ||
Latest revision as of 14:35, 18 December 2015
Definition
An approach to documented knowledge: from creation/capture, to review and approve, publishing, using, managing, and finally archiving and deleting. It is designed to maintain the currency and accuracy of documentation that an organization uses in its activities
Description
The DKL encompasses a cradle to grave approach to documented knowledge: from creation/capture, to review and approve, publishing, using, managing, and finally archiving and deleting. Everyone has a role to play in the process. It is designed to maintain the currency and accuracy of the documentation that an organization uses in their activities.
The process is depicted below. In the Capture/create stage there are collaboration and workflow activities happening in order to complete the document and approve it before it is published in the Publish phase. In the Publish phase documents are placed in the approved knowledge repository, with appropriate meta-data and security. The repository has the necessary taxonomy and disaster recovery processes in place so that it is findable within the system and so that the system is available in the case of an outage.
Once the document/artefact is published, it can be used for reference and information purposes by staff. In the repository, the documents are managed making sure they remain current, and remain accessible when taxonomy or meta-data change. It may be updated while it is housed in the repository. Ideally that means that the owner updates it (getting appropriate approvals, where necessary) and creates a new version rather than a whole new document, although this relies on the repository software to have versioning as one of its features. Once a document/artefact is no longer useful it should be removed from the repository and archived and/or deleted according to the records retention schedule.
In order to manage the repository/repositories, some new meta-data, reporting, and an escalation path are required. The meta-data allow the reporting and include the following tags/flags:
- Owner
- Review date
- Archive date
- Creator
- Review required (this should be a flag that Users can use to indicate that they have found problems with the document)
- Last accessed (this should be system generated)
The reports are run by Knowledge Coordinators or some similar function, although document owners should also have access to the reports so that they can monitor/maintain their own documents. Knowledge Coordinators will contact document Owners in order to have any outstanding issues with the documents resolved. The reports required are as follow:
- to review any documents that have been flagged by users as requiring review, should be run daily
- to review any documents that have not been accessed in a period of time, 6 months or a year, for example, run monthly
- to review and archive any documents that have reached their archive date, run monthly
- to review any document that have reached their review date, run monthly
- to review any documents missing required meta-data
The escalation path for enforcement purposes is through the document Owner’s manager and Department Manager. For example, if a Knowledge Coordinator has indicated to a document Owner that one of their documents has not been updated within the agreed upon time (e.g. 30 days) and it needs to be reviewed and updated; the document Owner has 5 days to update the document. If the Owner has not updated the document their manager is notified, there is then a further 3 days for the situation to be resolved. If it is not resolved at that point the Department Manager is notified.
