Re: Enterprise TECHNICAL document management

Subject: Re: Enterprise TECHNICAL document management
From: HALL Bill <bill -dot- hall -at- tenix -dot- com>
To: "'spcarr -at- evcom -dot- net'" <spcarr -at- evcom -dot- net>
Date: Mon, 3 Jul 2000 16:23:40 +1000

Sanford Carr stated:

>I've been tasked with reviewing possibilities for enterprise-wide
>document management software in the design-build-operate environment.
>Particular emphasis on situations where vector graphics like CAD are
>primary components in the design process and their output (files or
>blueprints) will be used in production/manufacturing, supplier and
>sub-contractor interactions, and customer operation and maintenance of
>the product.
<SNIP>
>I'd really appreciate feedback from anyone using these or similar
>products in their organisations or some leads for people to talk to
>who are evaluating these solutions.
---------------

What Sanford is asking for is a proper Product Data Management (PDM)
environment. I have been trying to implement such a system in the company I
work for since 1994, when I first encountered the principles. In these,
everything is related to a 3D hierarchical breakdown of the product and
under full configuration control tied to the engineering change process.

There are some good products on the market for dealing with the CAD-type
documents: Parametric's Windchill (http://www.ptc.com), SDRC's Metaphase
(http://www.sdrc.com/), and Matrix-one
(http://www.matrixone.com/products/applications.html) are the ones I can
think of immediately. We are currently implementing Sherpa - which may
eventually go live. However, Sherpa is a dead duck after Inso gutted it, and
then sold what was left to SDRC who appear to want Sherpa's customer list
for their Metaphase product (there is a long story here that can be followed
through Inso and SDRC press releases and SEC reports). However, none of
these PDM products is very good dealing with the content of textual
documents.

For that you need an industrial strength document and content management
system (DCMS) with SGML/XML parsing and processing capabilities such as
XyEnterprise's Parlance (http://www.xyenterprise.com), Chrystal's Astoria
(http://www.chrystal.com) or RMIT's SIM (http://www.simdb.com/).
BroadVision's BladeRunner product
(http://www.interleaf.com/products/brintro.htm) includes what remains of
Texcel's IM database, which was also well qualified as an enterprise
technical document management system. However, according to industry
scuttlebutt it may be that BroadVision is no longer marketing or even
supporting BladeRunner/IM technology into the heavy engineering DCMS market.
All of these DCMS have the capability to manage heavy engineering
documentation including graphics as binary large objects (BLOBs), but have
no built-in understanding of product structure or engineering configuration
management.

As noted in an earlier posting to Techwhirl and the Framers, at our Naval
Projects and Support division in Williamstown (Melbourne), we are
implementing the SIM DCMS to manage maintenance documentation for the ANZAC
frigates we are building for the Australian and New Zealand Navies. This
implementation of SIM is structured to manage SGML content and related
graphical inputs. The graphic objects are stored in the repository as binary
large objects (BLOBs). In Williamstown, we have been electronically
delivering maintenance data into the Client's maintenance management system
for several years from our WordPerfect environment. Requirements to deliver
paper were eliminated from the Contract last year. Our SIM system will
continue to deliver electronically, with far less human intervention than
was required to make the WordPerfect-based system work.

Our Land Systems and Support division in Adelaide is also implementing SIM
to manage the full documentation suite for Army light armoured vehicles.
This SIM system will link to the configuration management and line item
management capabilities of the MTMS enterprise manufacturing resource
management system (http://www.aremissoft.com/mfg/products/), and will
include full checkin/checkout and workflow control over graphics objects
included in the documents (e.g., illustrated parts breakdown lists). The
implementation work is pending release of the Army's budget to proceed with
the vehicle upgrade project, but - based on the Williamstown experience - we
anticipate no dramas.

Both SIM implementations include commented links to all kinds of source
documents. Document metadata (paper or electronic) are entered into a source
registry, and if electronic they may also be stored physically in a BLOB
repository linked to the registry. This allows us to securely link element
level content in our deliverables with the sources used by our authors for
that content. Changes to the sources can then readily be traced to the
deliverables to determine whether a change has any impact on deliverables
derived from the source information. Assuming intelligent comments are made
about what content in the source is actually referred to in the link, in
most cases it will not even be necessary to open the deliverable to
determine that there is no impact.

Both of these implementations will have complete workflow, revision and
release control and the ability to provide a view of the data at any
arbitrary point in time.

A point I forgot to make in my previous posting about our SIM implementation
is that it involves no modifications of any kind to third party products.
Unlike the other DCMS products listed, SIM servers include no third party
products anywhere in their architectures. It even includes its own integral
object oriented scripting language (a real advantage where system
maintenance skills are concerned). The user client is the user's default Web
browser (to IE4 standard). All user and management interactions with SIM are
via HTML forms. Document metadata editing is also done via HTML forms. The
document is edited in the user's preferred SGML editor. SIM launches the
document as a .SGM mime-type and associated objects to a designated user
directory, and the author's default SGML editor (as determined by the
Windows file association) automatically opens the file for editing. We have
tested FrameMaker+SGML, Epic Editor and XMetaL on the same documents with no
hassles of any kind. With minor configuration changes to the SIM Web Server,
there is no reason why our authors could not work as well in Miami as they
do in Williamstown. The environment would work exactly the same way whether
they were sitting next to the server or using it from the opposite side of
the globe. SIM's Internet security is good enough for some fairly
unforgiving clients.

If you wish to follow this up with specific questions, I will try to oblige.

Bill Hall
Documentation Systems Specialist
Integrated Logistic Support
Naval Projects and Support
Tenix Defence Systems Pty Ltd
Williamstown, Vic. 3016 AUSTRALIA
Email: bill -dot- hall -at- tenix -dot- com <mailto:bill -dot- hall -at- tenix -dot- com>





Previous by Author: RE: Future of FrameMaker: InDesign? [Long]
Next by Author: RE: Enterprise technical document management
Previous by Thread: URL: TransHub - The Encyclopedia of Terminology
Next by Thread: RE: Enterprise technical document management


What this post helpful? Share it with friends and colleagues:

Sponsored Ads


Sponsored Ads