Sometime in the 1990s, electronic archiving and document management systems (DMS software) started to gain momentum in commercial departments. The latter’s advantage over simple archiving solutions lies in its additional check-in/check-out features and versioning capabilities, which means that they also ensure the appropriate handling of current documents. Next to DMS, the term enterprise content management (ECM) is also frequently used today. Despite the differences in their theoretical definitions, most vendors of these types of systems use the two terms synonymously. Generally speaking, ECM/DMS today is understood as the whole set of technologies and methods used to capture, manage/process, deliver, store and archive information to support business processes across the enterprise.

4.1 Document Management System (DMStec)Using DMS software to base collaboration on a common information foundation

In product-centric industries, the issue of document management poses a challenge that must be managed across departments and disciplines. Today, technical products and services need to be developed against ever tighter deadlines. In many cases, this results in development, production and sales departments working on the same product without basing their efforts on the same information. Document management 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.

The highly complex environments found in product-centric companies regularly push conventional document management systems to their limits. In these companies, technical product structures come up against a myriad of technical documents such as drawings, product documentations, and specifications. The information they contain is tightly embedded into a structural context that cannot be represented by the simple storage of individual documents. The information they convey, for example change requests, is tied to technical parts and with them to other information contained in other documents such as product documentations that cannot be managed in conventional document management systems (DMS).

For this field of application that manages documents while also putting them into context with technical product structures, a very specific discipline of DMS coined “DMStec” has made a name for itself. DMStec systems allow companies to model technical structures. In combination with PLM systems, they form a Product Data Backbone, which in turn serves as the basis for modelling digital workflows.

Why tagging alone is not enough

Many of today’s DMS/ECM rely on keyword searching. Users don’t have to concern themselves with complex hierarchical management structures, but rather use simple, Google-style search forms to research all the information they need through a single field. This, however, requires that the documents to be searched were tagged (indexed) beforehand, meaning that specific keywords were added to a document in order to capture its contents for any subsequent searches.

This approach is not universally suitable, particularly when it comes to sophisticated technical product ecosystems. The products, devices, plant, and projects found in mechanical and plant engineering, the utilities sector or the automotive industries, for example, are usually highly complex in their structures. The accompanying documents need to be linked within the context of these structures. Conventional Windows Explorer folder structures are simply not suited for this.

Relationships between product-specific pieces of information

A DMStec (document management system) collects these documents in a central location, structures them, and represents them based on the underlying technical structures such as the structure of a plant and the assemblies and parts installed throughout it. This enables companies to establish relationships between the product specific pieces of information that reflect these structures. This dependency knowledge pulled from the relevant documents in turn serves as the foundation from which information based workflows can be set up to drive the digital transformation.

What this means: Adding search keywords to documents alone is not enough when you are dealing with complex technical ecosystems, because even though this will allow users to find all documents that contain the term they are looking for, this approach makes it impossible to model the technical structures of projects and products and to manage and control the corresponding documents accordingly. The key here is to be able to look at documents in the context of the product/project structure within the company and to deliver different views of one and the same document depending on which department or role owners is accessing it.

The suffix makes all the difference: from DMS to DMStec

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 product structures can also hold documents associated with the lifecycle of machines, plants, and projects, the static machine file becomes a dynamic machine Lifecycle File once delivery is complete.

4.2 Product StructuresProduct structures create context

By taking a DMStec approach, manufacturing companies can organize their product information in keeping with the product’s structure and control and manage 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, ERP, PLM 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 pump has been installed in five different locations throughout a plant, its specifications will also be stored in five different locations within the folder structure. If changes are made, the specifications will need to be updated in every one of these five locations. One could use tagging and keywords to show that these specifications are identical, it is, however, not possible to unequivocally establish their relationship based on a document’s tag alone. It’s only by looking at the plant’s structure, which is not intrinsically tied to any one document, that we can discern that it is one and the same document This is why technical documents belong to the corresponding assembly of a plant, just as a patient file belongs to a particular patient.

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.

4.3 Differentiated Views of DocumentsDifferent Views by Department or by Role

It is not always productive or effective to make all information available to everyone. Individual departments and role owners need whatever information is relevant to their job. Information needs can differ widely depending on whether you work in development, order processing, technical purchasing, service, or management. With DMStec, it becomes possible to give each role in the company their own specific view of relevant information and documents, while making sure that each file is managed only once inside the Product Data Backbone provided by the document management system.

Different views: development, design, manufacturing, and assembly

Design departments put together their view of native drawings, CAD models, wiring plans or PCB layouts of a component. They spend most of their time working with CAD and CAE tools. The documents that are part of their daily routines, however, differ widely from those that are used on the production floor or in the assembly process. Here, they focus on documents such as drawings as exploded views in PDF format or as simplified models in JT format, routings, or assembly and production reports. Design and development teams require a completely different view than their colleagues in manufacturing and assembly.

The project management view

The project managers overseeing the timely delivery of a customer’s systems certainly also need access to some of the documents created by the development departments, but they don’t need to go into every technical detail. They also create their own documents, such a meeting minutes, resource plans, and calculations and store the customer correspondence in archives that provide complete audit trails. Project managers need a bird’s eye view and put together their view of development documents accordingly.

The sales and procurement view

Sales teams need to be able to access all contracts, correspondence, and complaints related to a product. They will also require access to more technical documents such as photos of a piece of machinery or 3D models to share with other customers as references. On top of that, sales representatives will also want to look at their company’s order processing documents from time to time. All of this defines their own specific view.

The accounting and finance view

Commercial departments also work with very specific documents. One example is make-to-order production: Here, the accounting department is the central location where all bids, orders, order confirmations, and invoices pertaining to, for example, a sold piece of equipment along with any documents detailing project design services and purchased parts installed in the plant or machine come together. Every single one of these documents is related to the individual components found in the product’s structure. Purchasers don’t need to know every single detail about a machine, but they need to have a quick grasp of any spare parts that may need to be ordered to remedy a defect and they must be able to do so choosing the best quality part at a reasonable cost and with the shortest lead time. Consequently, they also require access to technical documents. On top of that, commercial departments need to have an archiving system in place that allows them to maintain complete audit trails.

The service and maintenance view

The lifecycle of a piece of equipment starts once its installed and put into operation at the customer’s site. The key to optimum operation and customer satisfaction, however, lies in preventive maintenance and timely repairs in case something does go wrong. Field technicians need to be provided with a digital representation – also known as the digital information twin – of the machinery they are working on. If, for example, they are performing maintenance work and are tasked with repairing or replacing a pump, they can’t do so without knowing which particular pump they are dealing with. How much did it cost? Who was the contact person on the supplier side? Is it still under warranty? Where can I find the installation manual? Are there any video tutorials I could use? Some of this information is contained in the invoice stored in the ERP or SCM systems and some of it is stored in completely different locations. With a DMStec solution, it just takes one click to provide maintenance engineers with consistent and complete information without any redundancies.

Custom views by department

The overall review remains

This shows that modern DMStec systems allow for different views to meet the demands and requirements of a company’s various departments. But none of this would be technically feasible without the Product Data Backbone. Consequently, one can’t exist without the other. The Product Data Backbone is the only way to establish the diverse relationships between product structures, product related documents, and the information they contain. The following example will illustrate why this overall view in the context of individual views is so important: Performing onsite service calls is usually not part of the product engineering process. If, however, an inherent defect in the product is discovered during a service call, this information must be reported back into the development, design and manufacturing view. The Product Data Backbone, through its connections to the field service management system, informs the relevant process owners that a part or component requires modifications.

4.4 Machine and Lifecycle FileThe basis for document management and document control

Complete documentation and therefore document management is a part of every technical product. Manufacturers are legally obligated to provide insight into every last detail about how their product is built and how the individual components are structurally interconnected. A thorough documentation simply cannot be created after the fact but must be generated alongside the development and manufacturing process.

In product-centric companies, bids, orders, and order confirmations, for example, often serve to determine the initial project structures within the ERP system. These often reference a standardized system that then needs to be adapted to the customer’s project specific requirements. Ideally, this structure is transferred to the DMStec solution where it creates an empty file to serve the machine/lifecycle file for the plant. Over the course of the product’s creation, it will be populated with data provided by the mechanical design (CAD models, drawings, engineering BOMs), electrical design (circuit diagram, PCB layouts, external data sheets), project planning (specifications, contracts, customer drawings, production data sheets, email correspondence), quality assurance (release reports) and service (service reports) teams. Afterwards, documents are automatically available for product management purposes such as manufacturing, maintenance, service and repair, and customer service. This is how an information twin of a machine or plant is created whose entire lifecycle can be seamlessly tracked across all disciplines, departments, and locations.

Image: Digital document management and control from product engineering to ongoing service

Deep integration with authoring systems increases the data quality of a DMStec solution

The quality of a well-tuned DMStec solution is also determined by its suitability for integration with important authoring systems. If, for example, the DMStec system is capable of recognizing emails as “correspondence”, it will automatically read out important metadata such as subject line, recipient, and sender. It will immediately identify duplicates, which means that even if an email has been sent to ten different recipients it will only store it once in the system.

Bi-directional integrations with authoring systems also ensure the automated transfer of project and item information into relevant documents. As a result, an engineering change request is not just linked to the item in question and visible to everyone involved, the system will also automatically read out the corresponding item number, project number, author, etc., regardless of the system where this information is originally maintained. By putting this information into context across system lines companies can create a truly seamless product engineering process. The automation cuts time and effort and reduces the error rate.