Conventional document management systems (DMS systems) are simply ineffective at modeling the complex structures found in technical companies. DMStec describes a particular type of document management system that is capable of modeling these technical structures. This lets companies implement a unified Product Data Backbone, which in turn allows them to model their digitalized processes.

5.1 Document Management

In engineering companies, the issue of document management poses a challenge that must be managed across departments and disciplines. It is directly tied to workflows and the control of related documents. Their project-driven work environments impose specific requirements on document management systems. Documents from the different disciplines and departments must be brought together and kept complete and up to date at all times.

A guideline published by the German Engineering Federation (VDMA) provides assistance in the selection, implementation, and operation of document management systems. It describes the basic features of document management systems and offers insights into how to separate and integrate a document system from and with other IT solutions such as CAD, ERP, and authoring systems.

Mechanical and plant engineering – like any other industry – has to deal with ever-increasing volumes of data and documents. Being able to control them is a critical factor in achieving cost-effectiveness. But document management is more than just tagging documents and archiving them in a common location. It is really about structures that connect these documents and about maintaining a formalized document control process that meets the specific requirements of the industry.

Document management in the file system

Many companies today rely on the Microsoft Windows file system to manage their project documents. They store their documents in folders that were manually organized into trees. This is an error-prone and time-consuming process that makes it extremely difficult to find and retrieve documents, especially when they were filed by someone else. Frequently, these documents are accidentally moved to the wrong folder and, just as frequently, the same documents can be found in multiple locations throughout the folder tree. This makes it impossible to determine if a document has been changed, resulting in change conflicts and activities that are based on obsolete documents.

Document management in conventional DMS solutions

Document management systems or digital archives use tags to accelerate the retrieval of documents. And they are also able to prevent change conflicts and data redundancy.

What these systems cannot do, however, is to mirror the structure of a machine in a way that is independent of the document. This proves to be a major disadvantage for engineering teams who are used to working and thinking in project and Product Structures. When accessing the description of an installed pump, for example, they need to know exactly how many times it has been installed and where. Document characteristics or tags are simply not able to provide this kind of information.

Document management with DMStec-type solutions

DMStec-type DMS solutions are able to reflect the structures of a product, plant, or project in a way that is independent of the documents and to then store the documents in the context of these structures. This is done by means of references. Any changes to a document are applied exclusively at the source, which means they are available everywhere.

The fundamental principle of DMStec provides the basis for the automatic creation of machinery and project files. Since these structures can also hold documents associated with the lifecycle of machines, plants, and projects, the static machine file becomes a dynamic Lifecycle File once delivery is complete.

5.2 Product Structures

By taking a DMStec approach, manufacturing companies can structure their product information in keeping with the product’s structure and control their documents in a way that reflects their typical workflows. A part’s structural information is traditionally created by a company’s development team and then used by its production and sales departments. CAD, PDM/PLM, ERP, and CRM systems, however, are seldom designed to support a consistently managed and structured storage model. Conventional folder structures with their large amounts of unstructured data are not all suited to provide a structured Product Data Backbone that lets companies take control of their versions, approval mechanisms, and collaboration efforts.

If, for example, a motor has been installed in five different locations throughout a plant, its specifications will be stored in five different locations within the folder structure. If changes are made, the specification will need to be updated in every one of these five locations. One could use tagging and keywords to show that these specifications are related, or in fact identical. It is, however, not possible to unequivocally establish their relationship based on a document’s tag alone, as this can only be achieved based on a plant’s structure, as it is not intrinsically tied to any one document. This is why technical documents belong to the corresponding assembly of a plant, just as a patient file belongs to a particular patient.

DMStec: Zusammenhänge technische Dokumente

The creation of product structures follows the technical attributes of a plant or its location and there can be multiple structures that are completely independent of one another. They establish relationships and the documents are stored within their context. Links are used to control workflows based on these relationships and ensure that the same information is made available and editable from a single location only.

This leads to product structures, plants, or infrastructure objects being managed in a way that is detached of the document itself. Product structures shift the focus away from file system-oriented folder structures and towards dynamic views over a common data backbone. Each document is stored in a single location only, assigned with specific information, and then incorporated into structures that reflect its logical relationships. This means that rather than being actually stored in a specific folder, the folder structure rather just serves as one way to (dynamically) view the document.

DMStec: Individuelle Sichten

Designers will have a different view of a part’s drawings and CAD models than the production teams, which are usually more interested in assembly and production reports. The sales force on the other hand will have more of an interest in looking at supplier bids, complaints, etc. that belong to a specific part. And since there is only a single instance of every document stored in the DMStec system, everyone will always access the latest version of the document they need.

5.3 PDM and DMS

Design and business department have traditionally relied on separate systems for their data and document storage. CAD (e.g. AutoCAD, Autodesk Inventor, Creo, Solid Edge, or Solidworks) users work with PDM/PLM systems – or very basic CAD data management capabilities – while ERP/SCM or CRM users turn to electronic document management systems (DMS systems) to store, version, and manage their documents. This isolation makes it rather difficult to establish a culture where product-related data and documents are passed on seamlessly and consistently across departments lines.

Regardless of whether a company is looking to tackle the issue of document management from a business or a design perspective, in the end, any company with a heavy focus on technology and complex products needs a unified Product Data Backbone that covers both DMS and PDM on a common data platform. PRO.FILE is a PDM/PLM and DMStec system that fully meets the demands of such a Product Data Backbone. It is perfect way for companies to start out with DMStec and move on to PDM and PLM or the other way around.

PROCAD’s ROI calculator: When is it worthwhile to implement a DMS/PDM/PLM system?

Determining the threshold for when it becomes worthwhile to implement a DMS/PDM/PLM system is a complex task. The number of variables is large: the number of designers, the sum of newly designed parts and their average cost, the number of times a part is reused and of variants/new purchased parts per year and their average cost. Other factors tipping the scale in favor or against PLM are the number of Bills of Materials that need to entered manually each week (and at what hourly rate) along with the number of changes per week and the time and effort involved in each change iteration.

For your convenience, PROCAD has therefore made available an online ROI calculator at that allows anyone interested to enter their specific data. Backed by PROCAD’s free service for assessing the cost-effectiveness for the company at hand, it is now easy to determine the extent to which PLM solutions can have a meaningful impact, to identify where there is room for process improvement, and to infer whether these effects actually make economic sense. Drawing from more than 1,000 successful projects, PROCAD has the experience it takes to realistically assess the benefits of a PLM solution.  This allows for informed decision-making right from the start.

5.4 Lifecycle File

Bids, orders, and order confirmations, for example, often serve to determine the initial project structures within the ERP system. These refer to a (standard) plant and are then transferred to the PRO.FILE DMStec system where they create an empty machine or lifecycle file. It will be populated with data provided by the mechanical design (CAD models, drawings, engineering BOMs), electrical design (circuit diagram, Bills of Materials, external data sheets), project planning (specifications, customer drawings, email correspondence, production data sheets), quality assurance (release reports) and service (service reports) teams.

By leveraging machines files that are based on a unified Product Data Backbone, companies create a foundation from which they can implement document control, which is defined as the assignment of documents to tasks and responsibilities. This must be based on structures that exist independently of the document, making document control with a DMStec and PDM/PLM system the next logical move following the introduction of a Product Data Backbone. This marks the next step in the evolution: Product Lifecycle Management (PLM).