What is a document Management System?
A document management system is a system designed to store and organise documents of varying kinds whilst adding some control over how documents are added, updated, removed, and retrieved from the system. The documents held within a document management system are considered the single source of truth within an organisation.
There are 3 major components within any document management system:-
- Document storage.
- Document control.
- Document standards and metadata.
Document Storage
The document storage component of the system is the repository for the documentation, often centralised, sometimes distributed.
The documents held within the document management system may be digital files or hard copy paper documents, or even a mixture of both, and so the storage requirements will vary based on the type of documentation held within the system. Digital documentation storage will be on electronic devices such as a hard drive or network storage, or on an online cloud storage solution.
Hard copy documentation, whether the medium is paper or something else, the storage could be one or more filing cabinets in one or more offices, or even atmospheric controlled environments where such measures are required to preserve integrity and or legibility.
A document management system is often abbreviated to DMS, or an EDMS (electronic document management system) when the underlying documents are digital and the system itself is built in software.
Document Controls
Document controls are the rules and protocols, processes, and procedures, that ensure a document is available for use, when and where it’s required. They help ensure that documents held in the system are used in the appropriate way, by the appropriate people, and that the content is fit for and relevant to its intended purpose.
To ensure the content of a document is fit for purpose, a change control procedure is often created and used to manage the introduction, deletion, and update of documents in the system. This includes a formal approval path, where the document contents are reviewed by all interested parties, before the action on the document is accepted into the system (whether it’s adding a new document, an update to existing documentation, or deletion of documentation from the system).
This approval process will consider the information within the document as well as any standards the organisation has defined for documentation.
Ensuring documentation is fit for purpose may also involve regular reviews of that documentation, so another control often implemented is managing the regular periodic review of documentation in the system. There may also be other controls that apply when documentation is removed from the system, for example retaining older version of documents in a secure place or destroying documentation on expiry.
Control over access is also common, ensuring that documentation is protected from unauthorised or unintended use, whilst ensuring it’s available as needed to those it applies to.
Having effective controls in place helps enforce the integrity of the system and means users of the documentation can have confidence that the information they are using is current, correct, and relevant. The controls in place will vary based on the needs of the organisation, the type of documentation in use, and the requirements of any quality standards or other regulatory frameworks an organisation operates within.
By way of an example, consider that one of the controls we want to apply states that “all documentation should be regularly reviewed.”
In order to review documentation regularly, we must understand how long that document has existed in the document management system, and how often the document should be reviewed. This means there are two pieces of data we need to associate with that document, a date, and a review period. If we have both pieces of data, we can work out whether a document is due for review.
Since we know we have at least two pieces of mandatory data to associate with the document, we would define how this is done in document standards.
If our document standards state that all documentation must have an issue date and a review period in months, then before the document is added to the system, we must ensure an issue date and review period is present on (or associated in some way with) the document in some way.
From this associated data we can easily derive the length of time the document has been held in the system, as well as determining whether a review is due imminently or even overdue.
Defining standards for the recording of these two pieces of data, and how that data is associated with the document, allows the system to satisfy the control that all documentation should be regularly reviewed, so we can see that the controls we want to apply, in part, help define our document standards.
Documentation Standards
Document standards comprise the formal definitions of the types of documents held in the management system, along with properties an individual type of document must have. They also offer explanation about how some aspects of the version control system works, for example if you have an issue number or revision number, or both on your documentation, what does this mean and when does it change? This is something we should define in document standards.
Sometimes an organisation will also define the type and structure of information that must be contained within a specific type of document, for example specifying that all procedures must carry an introduction section and describing what should be included in that section.
To organise anything, documentation in this case, you will need to classify, and to classify you need to embed, attach, encapsulate or otherwise associate data and properties with the document you want to organise into part of the greater system. For example, “this document is a procedure relating to human resources”, “this document is a notice related to engineering”, “this document is a form related to finance” and so on; by establishing and documenting conventions this can be made self-explanatory from a document’s identifier or location within the system.
Any document standards required by the document management system are created by the implementing organisation and typically held as part of the system itself. This serves in part as a description of the organisation of the system and a reference that can be consulted when undertaking any kind of change or review to check the standards are satisfied, which in turn aids maintaining the integrity of the system. Some of the properties defined within document standards support the evaluation of document controls and document control procedures and processes. Others are organisational/presentational, and others are present to improve usability of the system by making it easier for end users to access documentation they need quickly.
A concrete example of a document standard would be the requirement to have an issue date and issue number present on all documentation within the system, the standard would specify where that information is located within a document, and when and how it is updated. Another example might specify a given format for a document identifier for a certain type of document.
If the organisation wants to comply with the requirements of a quality standard, such as ISO 9001:2015, then that quality standard will have certain requirements around the control of documented information – these requirements can help define some document standards you might want in your system.
You will find examples of document standards at the bottom of this article along with why they are defined.
Document management systems, quality standards and regulation.
Often, when you look for the definition of a document management system you will find the requirements of specific quality standards or individual regulation being used to define exactly what a document management system (DMS) is. You’ll frequently also find a very specific representation of an electronic document management system (EDMS) used as a definition. Both definitions are very focused on one interpretation, which is a little misleading in our opinion.
Whilst standards and regulations can point to some essential features a document management system needs, they aren’t a specification. It’s important to note, you needn’t be operating within any frameworks or be governed by any regulation or quality standard to use a document management system. A document management system could be considered one of many best practices for any organisation that uses documented information of any kind.
Conversely, if you are operating to any quality standard or regulation, then you’ll find a document management system to be an essential tool to help meet some of the requirements. Numerous quality standards and regulatory requirements suggest or even mandate how documented information should be managed, and in some cases what specific documentation is required. For example, they might specify that some minimum criteria be met when creating and updating documentation (for example a date being present on the document) and that controls be in place for access, integrity, and so on.
They rarely specify exactly how this should be achieved, just that there should be a demonstrable way of doing so.
In other words they are requirements, rather than definite specifications. How those requirements are satisfied is down to the implementing organisation, or in the case of software solution, the interpretation of the system developers.
As an example, where a quality standard says something like “the organisation shall ensure appropriate identification and description for all documentation” – it doesn’t say specifically how this should be achieved, just that it should be done to meet the standard. What appropriate identification and description means is left to you and your organisation to decide, if you think about this it makes perfect sense, all organisations differ so they will all have differing ways of approaching this.
In the same way there isn’t any mandate to use a computerised solution or otherwise, a system isn’t necessarily dedicated document management software, you can use something simple with paper documents, simple registers, and appropriate filing provided you can demonstrate how it meets the requirements of any quality standard or regulation, and that it is used consistently.
In the case of data to support any document controls, these can be embedded in the document itself, held in related documentation or registers, or computerised. All are valid ways to achieve the same goal. It’s quite possible to have a document management system that has paper documents, with a document control database built in something like Microsoft Access or Excel to manage the controlling data.
By way of contrast to quality standards, some regulation will define specific documentation standards for an organisation working in a particular sector, right down to nomenclature and titles and expected subject matter of individual documents, how any changes within should be annotated and so on – in which case an organisation would take those as a baseline and add on any of their own requirements when deciding what they need from their document management system.
What is important to understand here is that in the case of regulation and quality standards (as well as in lots of cases common sense and organisation of information), defining standards that all documents in your document management system must adhere to along with the expected metadata to support them are essential in any document management system.
People are part of the system.
As with any system, the people that interact with it could also be considered as part of the system, which makes sense, as irrespective of the underlying implementation of the system, people will need to understand how to interact with the documentation.
There are two aspects to this, the first being the people who will manage document control, (sometimes known as document controllers) i.e. perform the processes that add to, update, or remove documentation from the system, whilst ensuring document standards are met and controls are satisfied. Note the document controller role will rarely be responsible for content approval, that will be typically subject matter experts.
The second is the typically far greater number of people that will seek the information held within the document management system.
In both cases this means a system that is simple to administer and simple for end users to quickly locate the documentation they need is essential.
Document creation tools vs document management systems
Documents are created using tools, pen and paper, files on computer edited in a word processor or a structured document authoring tool. These are not part of the document management system but are authoring/editing and in many cases collaboration tools.
When considering document management software, there is an ever-narrowing distinction between document management systems and content management systems, with the lines blurring more and more over time.A content management system usually has an embedded editor and doesn’t produce independent standalone documents that are easily ported to another system. However it’s often the case that both a content management system and a document management system need external tools to produce documents or content.
Typically, content management systems render content in HTML (Hypertext Markup Language) which is presented directly in a browser, exactly the same as the web page you are currently viewing. For purposes of this article, we refer to a document management system as something that can be used to manage files of many kinds (whatever your organisation would regard as documented information) produced in a variety of independent authoring tools, and not something that manages everything in one format with an embedded editor.
Examples of document standards you might define in your document management system
A document containing the expected standards and defining any conventions a document should meet before being accepted into the system can be created, this is how we define document standards for the organisation. The standards will vary according to the requirements of the organisation implementing the document management system.
If an organisation operates under some regulation, a number of these might be predefined as part of the regulation. The standards defined facilitate the controls and organisation of the documentation within the system as well as aiding end users.
There are a few broad categories of standard we can define.
Document Identification
Documents in a document management system need to be uniquely identifiable. That will normally require some combination of identification information (an identifier, title, or both), and version information. In that way you can refer to document Identifier at Version, Dated dd/mm/yy for example.
Document Title – A clear concise title that conveys the purpose of the document for example, “Change Control Procedure” or “Compassionate Leave Policy” – it should be such that a user can immediately get an approximation of what the content relates to.
Document Identifier – A short identifier that can be referenced to avoid having to refer to documents by title, for example HR-001 might be the identifier for the “Compassionate Leave Policy”, 02-02-01 might be an identifier for the “Change Control Procedure”. These can be referenced by other documents in the system, may be used to denote some form of meaning or structure, HR above relating to human resources.
In printed or hardcopy systems it can be common to see identifiers like HR-POL-001-UK, from which a user might infer it’s a human resources document (HR), it’s a policy (POL), and it’s the first policy published (001), applicable to the UK (UK). This is an example, the specific will depend on the system you want to put in place, and what each part of an identifier means will be defined elsewhere within the document standards, typically defined as conventions.
As well as defining the what, the standards should also define the where, where the information is expected to be in the document, the header, the footer, on a cover page, for example.
Document version control
Frequently we see terms like Issue Date, Revision Date, Publication Date. These are dates relating to the lifecycle of the document, there are no hard rules about what is correct, all of this is for an individual organisation to decide for itself what works best. What is important is the meaning of each is defined and that the meaning is recorded and described in the document standards definition.
For example:
You may decide to implement something like the following.
Issue Date – The date the document was issued (a first write, or major rewrite)
Revision Date – The date the document was revised (minor changes)
Issue Number – A number that increases by 1 each major revision
Revision Number – A number that increases by 1 each minor revision.
It’s important to also include some detail about the relationship between the two, for example:-
Issue date will change when the issue number is incremented which will occur for a major rewrite only. All other changes will increase the revision number. At time of incrementing the issue number the revision number will reset to zero.
As with identification information, we should also specify where the version control properties are located within a document should appear. For example, you might define the following as part of your document standards:
The identifier followed by a hyphen followed by the title should be present on the first page of the document before any other content. The identifier, issue and revision number should be present on each and every page of the document.
Document Change Control Approval / Query resolution
In many document management systems, document standards are defined that facilitate change control approvals .or workflows. These typically include the following or similar:-
Document Author – The name of the individual responsible for the creation and maintenance of the document, this is an actual name, like John Smith. This is present so that responsibility for the document’s content is established, and to indicate where any queries about the content might be directed.
Contact Details – In large organisations, or organisations that distribute documents they author to other organisations, it can be helpful to have contact details of the author or someone who can deal with any queries on the document.
Document Owner(s) – Similar to author, but frequently associated to a role within the organisation, for example “HR Manager” – The purpose is much the same as document author but removes the need for an update should the position holder change. This can also serve as identifying the approval chain for any proposed changes to the documentation.
Document Integrity
Page numbering – For any documents that span multiple pages you should define the page numbering convention, for example:
All documents will contain page numbers in the footer, this will state the current page and the total number of pages for example “page 4 of 7”
This ensures that a document is considered as a whole, minimising the chances of information being missed by the end user.
Document Structure & Content – You might decide that every document should have some standard content or formal structure.
A good example of this might be insisting that every procedure has a section stating the purpose of the procedure, this allows an end user to immediately understand if they have the relevant document without first skim reading.
Using a typical change control procedure procedure as an example, we can see how this might look:-
Purpose:
This procedure provides a Change Control System for the introduction and amendment of Company Procedures, Policies and Forms to be adopted and used by the Company. This procedure will be used to implement all changes to documents and forms held within the Company document management system.
The following documents are subject to this procedure:
• Procedures
• Policies
• Forms
• Job Descriptions
• Risk AssessmentsA change is defined as ‘The introduction, amendment, re -issue or deletion’ of any documents classified under the above headings.
If every document, or every document of a given type, has some defined structure or content, it becomes easier to create templates for the creation of those documents, and aids end users in their use of the documents, aids authors in creating new documentation, and helps ensure consistency.
Lifetime – If the document has a limited lifespan, then you might have a requirement, particularly in a paper based system to state that lifetime on the document, which could be an expiry date, a lifetime in months, again it’s important to state that the lifetime extends from some date, perhaps the issue date.
Presentation and branding – Used to define requirements on logos and typeface (fonts) including sizes and so on. This can be enforced in conventions by providing appropriate templates for specific types of documentation, defined in a conventions section (see below).
Audience – You may define an audience section be present on some, or all of your documentation, this is especially useful in large organisations, or where a distinction needs to be made about relevance of the information within some document based on geographic location or similar.
Example:
Audience
All EU based staff
Applicability – For documentation of a technical nature, it might be useful to have some applicability information. For example, if there’s a procedure to follow in the event of a failure of some component, but the component is fitted to several models of something you might have statements like on the documentation, this helps quickly identify the appropriate information for the end user to refer to. For example.
Applicability: – Model A, Model B
Format – You may also define the format information is expected to be in, if you take advantage of some of the capabilities of some file formats (for example, you want to annotate pdf documents at the time they are viewed or retrieved from the system) you may require that some types of documentation be presented in PDF format.
References – All documents in a document management system exist for a reason, and they rarely exist in isolation. It’s extremely common to include a references section on documentation that indicates related documentation and quality standard or regulatory requirements.
For example, if we consider our change control procedure once more, we might have
References: –
GEN-F-001 – Change control form
ISO 9001:2015 7.5.3.2
This serves multiple purposes, it aids integrity if the procedure changes, it may also result in a form change; having this reference in place identifies the form that may also need change. It points the user at the correct form to use when following the procedure, it aids the quality assurance department, together with any quality auditors, when checking compliance and gives a clear indication what part of a quality standard this document is intended to aid compliance with.
Document Review Threshold (months)
If there is a requirement to regularly review documentation, then we can define a property for a document that allows this to be implemented and monitored.
We might call this a document review threshold and define it as a period from the issue date before which the document must be reviewed and assessed as valid for continued use, or changed/removed in accordance with any change control process.
Conventions
Document standard conventions can be used to define some of the expected patterns that are to be used when adding to the document management system.
For example
| Document Type | Identifier Prefix | Template Document | Review Period |
|---|---|---|---|
| Human Resources Policy | HR-POL-*** | TPL-HR-POL | 24 Months |
| Information Technology Policies | IT-POL-*** | TPL-IT-POL | 24 Months |
| Health & Safety Risk Assessments | RA-*** | TPL-RA | 12 Months |
| Quality Notices | QA-*** | TPL-QA | 24 Months |
| Departmental Instructions | DI_DEPT-*** | TPL-DI | 12 Months |
There are no hard and fast rules here so it’s for you to define as suitable for your document management system. This aids consistency at time of document creation, update, and review. It also aids organisation by clearly grouping related or similar documents together by identifier in a way that makes sense to users of the system.