The document management needs of the Engineering EnterpriseTM are substantially more complex than in other types of organizations. The purpose of this white paper is to provide a basic understanding of the nature of these diverse needs and the risks associated with picking the wrong solution for the job. In general, solutions for Engineering are referred to as Engineering Document Management (EDM) or Product Data Management (PDM) solutions, while solutions for the Office side are typically referred to as Enterprise Content Management (ECM) solutions. For the sake of simplicity we will refer to these as “Engineering” and “Office” solutions.
This paper assumes you are already familiar with the many advantages offered by a proper document management solution and have begun evaluating your requirements. If you are not yet convinced of the opportunity to reduce risk and costs provided by a proper document management solution in your organization, we suggest you evaluate the sources listed at the end of this paper to learn more.
Let us begin by specifically defining what we mean by the “Engineering Enterprise.” We define it as follows:
“Engineering Enterprises are those organizations with a significant Engineering group(s) fundamental to the organization’s operations. While most of these will be product designers and manufacturers, the term includes any organization with a substantial Engineering department(s) such as utilities, municipalities/counties/states, defense contractors, and others.”
From a document management viewpoint, an Engineering Enterprise has two distinct sides: the Engineering side and the Office side. The Office side would be all other departments outside of Engineering. These include Engineering’s internal customers, such as quality assurance, manufacturing, purchasing, finance, etc. We will use the term “Office” to refer to all the organization’s departments other than Engineering.
The complexity of document management in an Engineering Enterprise arises from the very different document requirements of Engineering verses the Office. Once these differences are properly understood it raises a serious problem for an organization considering any enterprise-wide document management solution. As this white paper will discuss, neither current Engineering nor Office-oriented document management solutions can meet the needs of the entire enterprise.
Every organization will have its own peculiarities between Engineering and Office documentation. Our approach in this white paper is to explain the most common differences between Engineering and Office requirements. There are no hard and fast rules, but we believe you will find what follows will be correct 90-95% of the time.
There are two core fundamental differences between Engineering and Office document management solutions, the structure and organization of the data and the methodology for storing the data, which determines how that data can be searched and accessed.
Structure and Organization
Office documents are primarily more individualistic in their nature. There may be documents related in their purpose, for example a stored resume, an employee’s annual review, and a job description all keep information about an employee, but the individual documents themselves start as templates with usually only one current version of each maintained. In Office document management the only version that is typically relevant is the most current version. The primary exception to this is where regulation requires older versions of documents to be retained. This is not required for the majority of documents on the Office side.
Engineering documents, in contrast, are almost always a part of a package of specifically related documents, typically called a product release or release package. A single release of a complex product can include hundreds of individual drawings and thousands of references to other related documentation, all of which are required to support the product lifecycle. It is typical for products to be built from assemblies, which are built from sub-assemblies, which are built from parts that come out of part libraries that are shared across the organization. Each “piece” is a versioned document that must be managed both individually and as part of the release packages they are contained within.
To begin to get a sense of how complicated Engineering Document Management can become, consider the following example: you have a part drawing of an individual bolt which is included in the part library. The company changes vendors and the part is replaced with a comparable bolt. The new drawing for the bolt is entered into the part library. It is at this point that a decision must be made to determine the effects of a bolt change on every assembly that used the old bolt. Some assemblies will need to be updated while others may not. Those assemblies that need to be updated for the new bolt must be done automatically to reflect the change; otherwise a simple change can results in hundreds of hours of manual updating.
In Engineering Document Management individual documents have a HIGH degree of inter-relationship. An individual document is not meaningful in of itself, unless it is missing or is an incorrect version, in which case it can affect the entire product release. The individual drawing plays a role much like the individual parts, assemblies and sub-assemblies in the actual product produced. If one small bolt is incorrect and fails, the entire product may fail.
Even more problematic, products are often enhancements of previous product designs and different versions of the individual pieces must be maintained as they relate to a specific product release. When a product is updated the release package for Product 1 and Product 1A can be very similar and yet different. Some documents, such as a sub-assembly drawing, could be at the exact same revision level in the two different release packages while other sub-assemblies are at different revision levels in each release package. Engineering documentation must be done at multiple levels. Not only must multiple versions of the assembly, sub-assembly, and parts be maintained, but they must also have the proper relationship established to specific product releases. Unlike Office documents it is not the most current version of a document that is important but the “proper version” that was current at the time of the product release.