Document Management in a Data-centric World

(1)

Document Management in a Data-centric World

Don’t be “content” with just containers

A White Paper

(2)

ABSTRACT:A White Paper discussing the productivity increase to be gained by the continued convergence and integration of “data-centric” and “document-centric” technologies.

The key words here are rapid, secure, relevant, high-integrity, and importantly, data. These key words are often used in reference to the functionality of any major IT purchase. But the actual deployment, capability, and feature set will invariably be different from system to system. This paper will discuss some of the different capabilities and feature sets provided by these different technologies, what approach they are taking to the problem, and what the benefit of an integrated approach will be. Some of the questions evaluated will include:

• What is document management in a data-oriented world? • What is data management in a document-oriented world?

• What are the different approaches, intersections, and overlaps between technologies including:

o Document management o Product data management o Product life cycle management o Plant life cycle management o Engineering data warehousing o Portals

• Which option is appropriate:

o Select one technology and extend its scope to meet diverse business and functionality needs

o Select a mix of best-of-breed technologies, exploit their best qualities, and integrate their capabilities

The paper will also illustrate the data (content)-centric approach of the Intergraph SmartPlant® Enterprise and how it complements the document (container)-centric approaches of traditional CAD and PDM/PLM technology.

(4)

2. What is data and what is a document?

2.1 Definitions

2.1.1 Data

The smallest discrete entities which describe something in the real world – such as pressures, temperatures, tags – and properties, characteristics, attributes, relationships, and objects are all “data” objects. We can also refer to data as “contents.”

Examples of data types include real numbers and text strings.

2.1.2 File

When logically collected together in an envelope or “container” of some sort, data elements are said to be contained within a file. Even a relational database could be considered as a specialized form of file(s) that exists within a file management system (e.g. Microsoft® Windows®). Many such “containers” are often mistakenly referred to as documents.

Examples of file types include;- .xls, .pdf, .asm, and .par.

2.1.3 Document

Whereas the previous two terms could be said to have a physical manifestation, a document is logical or conceptual object. What differentiates a document from a file is metadata. In other words, a document possesses characteristics (either user- or system-defined) that uniquely and unambiguously describe it. Indexes, classifications, numbering, cross-references, etc. are all mechanisms used to describe documents. It is this metadata that we use to store and

unambiguously retrieve documents. Think of “documentary evidence” as a clue – anything that can be uniquely and unambiguously classified and named could be considered a “document.” Document management systems exist to store objects, typically files, in locations that are accessed by a naming or indexing system.

(5)

2.2 Explanation

It is clear that files and documents are not data types. They are containers for data. Data = Contents

Documents = Containers

Therefore, a system that is data-centric is one that acts directly on data, and one that is document-centric acts on documents.

2.3 Vendor, industry group, and analyst confusion

This concept of what is data and what is a document is commonly misinterpreted. Some “document management” software vendors classify their software as “content management’ when clearly they are providing librarian and classification services for the documents (containers), and are not managing the actual content of the document. A leading industry body originally grew out of the image capture and processing and records management market. The Association for Information and Image Management (AIIM) (www.aiim.org) positions itself as solving business content challenges. It describes Enterprise Content Management (ECM) as the technologies, tools, and methods used to capture, manage, store, preserve, and deliver information, content, and documents related to organizational processes. ECM enables four key business drivers: continuity, collaboration, compliance, and costs.

Even industry watchers, analysts, and researchers confuse the market in this respect. For example, Daratech defines three classes of systems supporting this market:

• Data management technologies – Required to manage all of the data created in the enterprise during the design and manufacturing process. This definition includes systems such as PDMs, DMs and CMs, and touches on their interactions with the ERP systems used to manage the entire enterprise.

• Collaboration tools – Enable sharing of data and documents across the Web, and include aspects of PDM, DM and CM.

• Workflow tools – Define, control, and enforce work practices around the enterprise as they relate to the design, manufacturing, and support of engineered products.

In this definition provided by Gartner, PDM, DM, and CM systems clearly lie in all three categories. This is very confusing for the user.

(6)

3. Enterprise-class data vs. personal productivity

documents

It is clear that “enterprise-class” information systems (such as SAP®) involve many disciplines and functions working on individual tasks. While part of a larger process, they share data with an end-goal in mind – but they are essentially working on data (content).

This is in contrast to “personal productivity” computing (such as Microsoft Office and typical engineering CAD systems) where individuals work on one specific deliverable (a file or document) at a time, again, part of a bigger picture, but where the one deliverable could be isolated from the whole with minimal impact.

Personal productivity grew partly from the necessity to provide read/write access to files where multiple people could not write to the same file at the same time. But it also arose from the fact that some of the early applications required specialized workstation class hardware – as opposed to centralized mainframe-class hardware.

(7)

4. Mechanical CAD vs. process engineering

Clearly, today’s CAD/CAE systems grew from replacing the drawing board concept.

Electronic drafting of sheets of paper was slowly replaced by logical (schematic) and physical (3D) model representations. Drafting was not entirely replaced since the engineering drawing was still seen as the primary means of communication of facts, and as a record of the task – a deliverable against which decisions, tasks, and indeed contractual transactions occurred. Model views were aligned and annotated on the electronic drawing sheet. Drawing engines, such as AutoCAD from Autodesk and MicroStation from Bentley spawned specialized application environments, with tools to increase the personal productivity of the individual. But the basic architecture of the applications remained the same – tools that modified data within a file. This approach is wholly appropriate and applicable for discrete manufacturing. Each individual component could be designed within a file. Many CAD/CAE systems have different names for the file types, but they are essentially parts. An assembly model could be drawn together from multiple parts to examine fit, form, and function. Mechanical CAD vendors implemented different techniques to allow multiple users to work simultaneously on these assemblies – some via a graphics-sharing mechanism, some via file management mechanisms.

The file management technique formed the basis of product data management (PDM) systems. The data in this acronym was somewhat of a misnomer in the early days since they were essentially managing documents and not the core data. Later, PDM systems were developed around object-oriented database techniques. Each object represented a part or assembly, which invariably pointed to a file secured away in a vault. The objects maintained relationships between themselves which represented the many different structures required for mechanical engineering – assemblies, bill-of-materials, configuration trees, etc.

These objects and relationships carried data that added value to these exercises. For example, in an early PDM system, each and every bolt in an assembly would need to be identified individually. In later systems, these became true data items, expressed only as quantity values (typically on a relationship object).

However, the essence of a PDM system was still that of a file/document manager. Each PDM vendor found it difficult to work with assemblies of parts from mixed CAD system vendors, partly because for viewing purposes they would need to understand and potentially convert the file format to a neutral medium, and partly because some of the PDM application functionality required access to the content of attribution/data within the file, for example “item weight” and “center of gravity.” Another reason that PDM systems could still work effectively in a file/document (container)-centric mode was the essence of the individuality of the component parts themselves. Changing one part for another did not affect the form/fit/function of the whole. It is this very interchangeability that is key to the concepts of managing multiple configurations of the same assembly.

Process engineering CAD/CAE grew from the same base drafting technology as mechanical CAD. Deliverables were still required for the same reasons as in the discrete engineering world. Early modeling (logic and physical) applications mimicked mechanical CAD techniques, but clearly these systems did not yield the same performance increases as in the mechanical market. Why?

(8)

The reason is in the fundamental differences between the assembly market and the formulation market. For example:

• Changing a diaper fastener from Velcro to adhesive does not change the fact that the assembly is still a diaper

• Even though the bill of materials changes, the assembly remains the same

Assembly

Formulation

Action Result Action Result

Uniquely isolate parts from the assembly for modification There is no impact on the overall nature of the assembly Changes to a formula cannot be isolated from the assembly without some impact on the whole Different volumes of material or different transformations will yield a completely different end-product Alter the weight

of a component part

The product is still effectively the same, only heavier

Alter the bore of a pipe

The entire process and end-product are completely altered Substitute and alternate or optional part in the assembly It is still the same product (although with a different BoM) Substitute a different sub-process or feedstock

The end product will not be the same, unless the process characteristics are changed to suit Change the

impeller of a pump

It is still a pump Change the impeller of a pump

The process and product output is altered

Figure 1

Although mechanical engineering and process engineering can be established using some of the same object/relationship techniques, the process engineering objects have a much higher degree of inter-dependence that do mechanical objects. That is, the impact of a change to a process (in formulation) can have much wider ramifications than does the change to a product (in assembly).

Therefore, it is apparent that the file/document-based metaphors that support the mechanical CAD market do not lend themselves to the process market. It is not accurate to suggest that a mechanical bill of material is the same as a formulated recipe.

Process engineering lends itself more to the data-centric approach as found in the “enterprise class” application world, where, for example, the change in value in a sales ledger would have a ripple effect on the accounts.

(9)

5. But process engineering is document-centric too

But process engineering is document-centric too. Indeed it is. The same documentation needs to be produced as a record of the task and as a communication medium to the next task in the process. Projects are still executed and measured by the delivery of specific documents at measured milestones. Indeed, many projects include a cost and payment schedule based on the work breakdown structure of document deliverables. This is not to say that process engineering is wholly data-centric, but documents must be produced as records of the data.

This change of emphasis means that whereas in the past the effort of the project was centered around the production of documents connected to some form of model (schematic and physical), today it is centered on the production of a model, where documents are merely revision-controlled reports or views of the data. Therefore, document management and document control systems still have a part to play as the systems of record and official release and distribution mechanism. But they are clearly not content management systems in

(10)

6. SmartPlant Enterprise data-centric process engineering

The tools from Intergraph that make up the SmartPlant Enterprise are data-centric.

They allow multiple users access to the schematic (2D) and physical (3D) models that define the process and the plant engineering. The products in this suite include:

• SmartPlant 3D, SmartPlant Layout and SmartPlant Review for 3D modeling and visualization

o Multidiscipline plant layout and documentation – Piping, structural, HVAC, mechanical, electrical, instrumentation

• SupportModeler™, SmartPlant Isometrics, and Spoolgen®

for detailing o Pipe hanger structures, pipe-sketching, fabrication, and construction • SmartPlant P&ID, SmartPlant Process Safety, SmartPlant Instrumentation,

SmartPlant Electrical, SmartSketch® for 2D, logic, and schematics • SmartPlant Foundation for information management and integration • SmartPlant Materials and SmartPlant Reference Data for materials and

resource management

(11)

In this environment, each of the SmartPlant applications is data-centric and operates with its own optimized database. However, each can be connected to SmartPlant Foundation using the supplied SmartPlant Adaptors and share data with each other via publish/retrieve workflows. This sharing/exchange mechanism is provided by SmartPlant Foundation.

Since SmartPlant Foundation also provides document management, product structure management, configuration management, and workflow management capabilities, on the face of it, SmartPlant Foundation would appear to be a traditional PDM/PLM system. But that is where the similarity ends.

While SmartPlant Foundation can manage files and documents and the traditional structures between them, it is also a granular data management engine. The data from the SmartPlant Enterprise applications is normalized by the SmartPlant Adaptors against a common data model as represented by the SmartPlant Schema. This is the native data model of SmartPlant Foundation. So in addition to finding documents, models, drawings, and all manner of other files associated with objects in SmartPlant Foundation, you will also find granular data such as pressures, temperatures, setpoints – indeed, all of the complex inter-dependent data that makes up a process plant.

A datasheet for a piece of equipment is just that – data presented in a sheet. It is not a document whose changes can only be compared at revisions, but essentially is a report or complex query from the database from the SmartPlant Schema data model. Of course, documents still need to be produced which reflect the exact state of the data at a specific point in time for records and auditing purposes. These can be produced as, for example, Excel® spreadsheets or .pdf files. When annotated with metadata, these files become documents (documentary evidence) that can be stored in SmartPlant Foundation or the user’s document management system of choice, e.g. LiveLink, Documentum, etc.

(12)

7. Document vs. data analogy

Is there a way to summarize the differences between documents and data and their respective management systems in a neat analogy?

Assembly

The sum of the discrete parts

Process

One connected whole

A document/file/model is like a castle.

You can find it within your document management system, but the content

is impregnable and inaccessible unless you have the application key.

Data is like the sea.

Content is all-encompassing, connected and fluid, touching everything. Anyone in the water gets wet with data.

Figure 3

Why is this analogy so appropriate to describe the SmartPlant Enterprise, and particularly SmartPlant Foundation?

SmartPlant Foundation is a database, which also happens to manage documents.

But this management of documents was not its main design purpose. For that, you need to go back a few years.

(13)

8. Origins of SmartPlant Foundation

In the late 1990s, a number of process plant companies in Europe, both engineering, procurement, and construction (EPC) contractors and owner operators (O/Os), were looking for ways to improve the way that data was turned over from engineering execution into plant operation.

They realized that the data produced during the engineering cycle was relevant and useful to populate the operations systems, such as a computerized maintenance management system (CMMS) or digital control system (DCS), etc. But without a common data model or exchange protocol, this could not be achieved. Enter the POSC/Caesar project and the development of a holistic life cycle data model – ISO 15926, an international standard.

This is the heritage of SmartPlant Foundation, a holistic data model, management, and integration system to capture all data generated during the life of a process asset – from first concept to final decommissioning.

(14)

9. Uses of SmartPlant Foundation

The concepts of data-centric engineering can be challenging to many at first, not just in theory but also in practice, since they invariably change business practices and procedures. Most organizations start by deploying SmartPlant Foundation against traditional tried and tested practices, setting themselves a goal to evolve from document-centric to include data-centric methodologies. They use SmartPlant Foundation objects and relationships to classify the drawings and documents used within the plant.

On the face of it, this approach may look like a traditional document management system. But even though the object types and indeed in some cases the end-user experience may be the same, the architectures for SmartPlant Foundation and a traditional document management system are fundamentally different.

9.1 Differences

These differences include:

9.1.1 Granular data model

Although some object types in the SmartPlant Foundation system describe high-level objects – containers – there is little to prevent the deployment utilizing finer-grained objects at a later stage, for example, when deploying SmartPlant P&ID and extracting the engineering data (content) to be presented in other forms, such as line lists, equipment lists, datasheets, etc. However, in a document management implementation, these lists and sheets would need to remain as documents (containers), since there is no tight integration with the authoring applications and no fine-grained data model to receive this data (content). In the document world, this makes version comparison and change impact analysis of the process plant a manual and time-consuming business – since the contents of the containers cannot easily be analyzed without specialized software (see Section 7).

9.1.2 Data-driven system

SmartPlant Foundation is data-driven – changes and presentation of the data are driven by the configuration of data within the core. New object types (classes) and relationships to receive the data can be dynamically added with no code, recompiling of the system, or complex SQL scripting, resulting in a savings of between 400 and 700 percent over the equivalent definitions in competitive systems. This practice lends itself to the evolutionary and flexible deployment of a system as opposed to the traditional “define and deploy all upfront” methodology.

(15)

9.1.3 Integration-ready

Integration relies on the exchange and, in some cases, sharing of data between systems. In point-to-point environments, it makes the integration architecture fragile and costly to maintain, since in this mode you support nn-1 interfaces. Additionally, the scope of data being exchanged and mappings needs to be crafted on a case by case basis.

With a common core data model, the number of interfaces equals the number of systems, and the mapping is to a core common data model as opposed to a variety of data models. In this environment, SmartPlant Foundation could be considered a data warehouse or integration hub. It not only integrates the data into a single correlated source, but also provides the application integration hooks to procedurally move the data.

9.2 Uses

SmartPlant Foundation has not only been deployed (initially) as a document management system or a document control system, but it can also be used as a:

• Data warehouse

• Workflow execution system • Product data management system • Integration framework

• Configuration management system • Commissioning and completions system • Construction sequencing system

(16)

10. Data-centric engineering in practice

The tools within SmartPlant Enterprise have been designed to share data through SmartPlant Foundation’s common data model, though this does not mean that the process has to be synchronous. Engineering is not a real-time activity. It is a milestone-based activity, where many disciplines and functions collaborate on often different schedules and even time zones. Additionally, many engineering projects today are global in nature, which further requires the data transport to be asynchronous.

A traditional document-centric approach to this harmonization would typically involve the exchange of files between systems – in some model cases, large file sizes even when zipped. This could have pretty significant consequences on bandwidth and communication costs. To have engineering “follow the sun” would require significant transmission, let alone alignment of work schedules or segregation of work areas.

With a data-centric approach, only the differences between the databases need to be

transmitted. As such, the bandwidth requirements are much reduced and the transmission can: • Occur asynchronously

• Use existing database replication/synchronization expertise • Not consume duplicate file and ftp server storage

At Intergraph, we call this process worksharing. It means that global execution is a practical reality where multiple partners can share and execute a project concurrently, dramatically reducing time-to-market schedules. This process can also be extended to cover security and preventing intellectual property from being exposed to non-trusted parties.

(17)

11. Remote engineering management and review

The data-centric engineering case discussed in Section 10 may be ideal for a global EPC executing a project. But this approach may not be suitable for an O/O, particularly if the O/O does not have in-house detail engineering functions.

What approaches can be used in these cases?

• What if the O/O does not deploy the same engineering tools as the EPC?

• What if there are multiple EPCs executing the project in a joint venture for the O/O and these EPCs do not share the same tools?

• What if the EPC, the plant site, and the O/O are not co-located?

Since SmartPlant Foundation is data-centric at its core, it can be used to capture, normalize, and transform model data for access by users that do not have the source applications at the desktop. As an approach, the remote EPC would deposit models, drawings, and data into SmartPlant Foundation and use SmartPlant Foundation as a document management and document control engine in a traditional manner. As part of the capture (check-in) process, SmartPlant Foundation would convert these native forms into a form accessible and distributable over the Web.

For example, SmartPlant Foundation uses a high-performance graphics streaming technology to provide remote users with access to 3D models for query, navigation, and review:

• Without the native application being installed on the remote desktop

o Resulting in lower cost of ownership from lower IT and training overheads • Without the whole model being duplicated and transmitted across the network ahead of

the review session

(18)

Figure 4

Figure 4 illustrates the ability for a remote user to collaborate with the project team, browsing and reviewing the integrated engineering data including viewing drawings and 3D models, without needing the source application at the desktop.

However, in a review environment, it is usually not enough to view the data and document-ation being made available. The reviewer needs to make comments on documents and drawings, and leave annotations on the data to be examined and possibly rectified.

SmartPlant Foundation provides an integrated, non-destructive remote view and markup tool in SmartPlant Markup for this purpose. It is capable of opening hundreds of file types without the native application needing to be available. Additionally, it allows users to leave comments as overlays to the original. The difference in the SmartPlant Foundation environment is that these overlay files are also controlled and managed objects, against which rules for workflow, completion, and audit trails can be associated. Figure 5 illustrates the object/relationships that are established against a document during a typical review cycle.

(19)

Figure 5

In Figure 5, note how the document is tracked through intermediate versions between formal revisions. Note also how there may be multiple viewing renditions associated with a document. All of these objects and relationships (along with any change notes) are tracked and maintained to ensure close-out and completion of changes.

In this example, a document object is being revised. But again, remember that SmartPlant Foundation can be used as a granular data warehouse and an object as fine as a pressure or temperature setting could be revision-controlled if necessary.

(20)

12. Continuous handover

So far we have seen that an O/O can collaborate with a remote engineering company or with the remote site using SmartPlant Foundation as a communication hub. But as the project progresses, the EPC will be gearing up the project for handover to the O/O. The traditional handover involved boxes of paper.

More recently, handover at least involved electronic files, typically on CDs and in databases of mixed formats. However, if this data handover was not classified and indexed in some form, it was highly unlikely that the O/O would be able to yield any benefit from the electronic files because the volume of un-indexed information was too overwhelming.

However, as the documents and data are being indexed into SmartPlant Foundation for review and engineering change purposes as indicated earlier, it follows that SmartPlant Foundation becomes the information handover mechanism also. Intergraph has seen this usage model many times on projects where the turnover of the project involved the change of ownership of the data objects.

(21)

Figure 6 shows how a continuous handover process may work. At the left side of the diagram, the O/O awards the design and engineering contract to an EPC. At this stage, the SmartPlant Foundation system is established, in this case indicated as an engineering data warehouse (EDW). Note how the system is not embedded in the core but alongside the EPCM processes. In this way, the EPCM is not forced to change its working practices and procedures, which would invariably impact the project with time, cost, and delay to do so. As the project progresses, data is captured from the design process in SmartPlant Foundation, which continuously consolidates and aggregates the data. During this process, SmartPlant Foundation can also be used to validate the quality and integrity of the data from the

multiple disciplines and vendors/suppliers to ensure consistency and accuracy. A SmartPlant Foundation client is where the O/O would gain access to the data as it is being captured for remote reviews and change management processes. Note how the documentation is shown being captured concurrently. Also, this may be in the EPCM’s own document management system, which could also be SmartPlant Foundation depending on the desired end-state for the plant.

Finally, the SmartPlant Foundation EDW is handed over into operations, potentially with other tools from the SmartPlant Enterprise (such as SmartPlant Instrumentation and SmartPlant P&ID) already integrated into the dataset. This ensures that the intelligent engineering documents and data is kept evergreen and not allowed to degrade, which would then be costly to repair prior to the next engineering rework project. Since SmartPlant Foundation has all of the engineering data captured during the design, engineering, construction, and commissioning phases of the project, it can also be used to pre-populate the on-plant management and operations tools, such as SAP for maintenance and procurement. This alone has yielded dramatic time and cost savings for many O/Os.

(22)

13. SmartPlant Foundation as an eEngineering

integration hub

From its outset, SmartPlant Foundation has been designed for integration. This integration can be manifest in any one of specific ways:

• Presentation integration – Typically using in conjunction with a collaboration portal • Data integration – Typically integrating data together from multiple sources to

provide a consistent view of a plant object – such as in the handover example earlier • Application integration – Moving data from application to application to ensure that

the data is entered once, but used many times – to reduce the risk of end user errors and to ensure consistency of the project

• Business process integration – Routing data as part of a business process, often overarching many line-of-business applications, such as in an engineering change management workflow

• Composite application integration – Developing new “lightweight” applets that share data from the high integrity data source SmartPlant Foundation instead of duplicating it in a standalone application

Figure 7

But, since the SmartPlant Foundation engine is so flexible at its core, it can be used to support any or all of these levels of integration, evolving from one tier to another without needing to purchase and deploy additional technologies/products to support another tier.

(23)

14. Conclusion

In summary, SmartPlant Foundation has been developed to support both document-centric and data-centric approaches in complete harmony. Both approaches can and often are deployed at the same time.

Since SmartPlant Foundation also supports a very fine-grained data model, it can be used as a true data-management engine, not simply managing files that contain the data, where the documents are (erroneously) referred to as “data-types.”

And, since it supports electronic workflow and role-based access, it can be used as an application hosting platform in its own right.

(24)

Headquarters

Intergraph Corporation

170 Graphics Drive Madison, AL 35758

For more information about Intergraph, visit our Web site at www.intergraph.com.

Intergraph, the Intergraph logo, SmartPlant, Spoolgen, and SmartSketch are registered trademarks and SupportModeler is a trademark of Intergraph Corporation. Microsoft, Windows, and Excel are registered trademarks of Microsoft Corporation. SAP is a registered trademark of SAP AG. Other brands and product names are trade-marks of their respective owners. Intergraph believes that the information in this publication is accurate as of its publication date. Such information is subject to change without notice. Intergraph is not responsible for inadvertent errors. ©2008 Intergraph Corporation, Huntsville, AL 35824-0001. All Rights Reserved. 11/08 PPM158A0

Document Management in a Data-centric World