The first strength of EDMS is its structured approach to data management. It encapsulates data in the form of a document which includes meta-data about the document (such as the title and author) in addition to the data files themselves (for example, PDF files). EDMS allows documents to be created and classified into different document types such as specifications, technical drawings, schematics, reports, non-conformity, safety inspections and meeting minutes, just to name a few. These documents may include additional properties such as a reference number, a more detailed description of the document and additional keywords associated with the document amongst others.
EDMS offers three main types of objects: the document which has previously been explained, in addition to projects and items. Documents are typically stored within project structures where each document may be linked to more than one project. This approach gives the advantage of great flexibility in the way data can be organised within the system whilst removing the danger of data duplication. EDMS also supports item entities; these are used to store data about the equipment to be manufactured, thus serving as a technical template. Item entities may also have technical documentation linked to them.
Lifecycles are the implementation of formal processes and procedures followed by the engineers, and provide a framework for performing quality assurance. Any document must have a lifecycle associated to it at creation time. Within the lifecycle, a document may pass through several statuses; these mark the various stages of the work which reflect the evolution of the document at a given time. For example, ‘In Work’ would indicate that it is possible to edit the document, insert and delete files in it. On the other hand, the ‘Engineering Check’ status would indicate that the document is frozen until a formal engineering check is done, after which it is then either ‘Released’ or put back to ‘In Work’. For a document status to be changed, a user must have sufficient user privileges to do so.
Through the use of document statuses it is easy to understand whether a given design is already finished, approved and may go to tender, or if the work is still in progress. For example a lifecycle called “Approval with Engineering Check” offers statuses in which the comments are collected and formal approval is conducted. The final status of a document (such as ‘Released’) indicates that it is the official version with up to date information.
The diagrams below showcase two of the most commonly used release procedures within EDMS: the first being Owner Approval (DOC-OWNER) and the second being Eng. Check & Reviewing process (DOC-AL).
There are many different types of release procedures each of which may require different levels of approval. The three main types of document approval include approval from the document owner, approval from someone in the correct role such as a Project Engineer and lastly, the responsible person such as an Approval Leader. For example, a document starts ‘In Work’, it is then frozen for an ‘Engineering Check’ where the Project Engineer must approve it, and then after approval is given, the document is ‘Released’.
The most commonly used release procedures can be viewed here.
EDMS offers the advantage of document version control which allows traceability of document versions. Once a document reaches a final status such as ‘Released’ or ‘Obsolete’ it can no longer be modified. Therefore, a change in the document requires creation of a new version of that document, which will keep previous version’s metadata and associated files if the user wishes so. This new document version will of course have to follow the predefined lifecycle. The common configuration used is the one which assures that there is only one Released version of a document. When releasing a version, the previous one will be automatically put in an obsolete state.
Documentation versioning is another means of structured approach to data management. It provides traceability of changes by keeping the history of the versions, the time stamp of each modification and the data about the user who performed them.
In High Energy Physics collaboration, the work is never performed at one single location but rather, a number of different locations. Therefore, EDMS takes great care in ensuring the accessibility of data by any involved party, irrespective of their physical location, but always in respect to the type of the data and the authorization of the interested party.
The documentation stored in the system can be marked as public, internal to CERN, restricted or sensitive. These visibility options are in line with CERN’s Data Protection Policy (as recommended by the CERN IT department in 2013). In addition, any documentation may change its visibility level as it becomes official – various configuration options exist today in EDMS to ease the access management. For example one can configure a project to enforce all related documents to become public when they reach a certain status. The collaborative work is also eased by promoting the organization of documentation in a hierarchy of project nodes – the EDMS tree can then be used to easily navigate and filter large structures.
When collaborating on a document, EDMS allows the possibility of sharing documents between users. The share functionality is used for granting Read access to a person/group to a document or for distributing the given document. Furthermore, EDMS allows its users to post comments on documents, which are marked for review.
Access control in EDMS is based on user authentication and authorization. The former is integrated with the CERN Single Sign On service whilst the latter is achieved via the internal setup of EDMS contexts, which provide a very flexible access model.
A context defines the rules which should be applied for various elements of the document such as which group of users has access to it, as well as the possible document types and approval procedures/lifecycles. This means that, for example, an ATLAS user will create documents following ATLAS rules and a user from the BE Department will create documents according to his/her departmental rules.
It is important to note that each project has an owner and belongs to a group. The users in the group might have read, write or delete access whilst these access rights can apply separately to documents and structures. Such granularity is useful when write access must be restricted to a small number of users. Depending on the project needs, the contexts may implement complex rules, such as enforcing the sensitivity of documentation following a certain lifecycle and ensuring that it remains hidden for non-authorized users. Besides the context and group access mechanisms, each document can be individually shared with any user of the system.
Sensitive Restricted CERN-Internal Public
EDMS offers a search functionality which enables users to find EDMS documents and their associated files as well as other types of objects managed by EDMS (such as Projects and Items) and by the CERN Maintenance Management System, Infor EAM (such as Assets, Functional Positions, Systems and Locations). Both objects metadata and files’ content are searchable. In addition, the advanced options allow to specify the fields on which the search should be carried out, such as author, EDMS ID, title, description and keywords. EDMS uses the CERN Search engine, therefore the data is also searchable via the CERN Search portal
It is possible to point directly to an EDMS-styled search result via URL – which can be shared or incorporated in another webpage, as well as make use of an EDMS search feed, which serves the search result in an XML format.
For more information, consult our FAQ.
As EDMS is used widely at CERN, the system is configurable in order to adhere to the needs of the different user communities. The document lifecycle functionality can be adjusted to fit the needs of a given community, thus the everyday document management workflow used by a section or group can be transferred to EDMS. EDMS Projects are another configurable element, users work in EDMS structures that represent their domain and functions and are unique to their community. Last but not least, Contexts in EDMS allow administrators to pre-configure document behaviour (numbering, types, lifecycles, access rights) within the domains they are responsible for. Combining those three elements enables EDMS to provide a common CERN look and feel, yet be uniquely configured for a particular user community.
EDMS is equipped with a number of features which aim to improve the user experience. The system gives each user a list of their recently accessed documents, projects and items for quick access and also offers the possibility of bookmarking each of these objects for even quicker access. EDMS also provides an “Inbox” area where users can view documents which require action from them such as giving comments in addition to documents already commented on and processes started by the same user.
Furthermore, the “Caddie” in EDMS allows users to gather a number of documents so as to be able to perform bulk operations on this collection of documents such as sharing them with a particular user or changing their status.