RE: Enterprise technical document management

Subject: RE: Enterprise technical document management
From: HALL Bill <bill -dot- hall -at- tenix -dot- com>
To: "'Jeroen Dekker'" <jeroen -at- square1 -dot- nl>
Date: Tue, 4 Jul 2000 08:41:31 +1000

Jeroen Dekker proposes to develop/market a graphics conversion product able
to work with a variety of documentation tools, and asks the following

>-is this a concept that companies could base their technical document
>management on (or at least the graphics part of it)
>- could this exist as a solution by itself (considering that our software
>only does the conversions and doesn't have a lot of 'Management' functions)
>- if not, what kind of things would need to be developed around our
>to manage workflows, processes etc.
>- would some of the vendors you named in your posting benefit if they could
>integrate our technology into their solutions.

Making a success of with such a tool will depend on clearly understanding
the difference between illustrations (static graphic objects as they are
actually used in a textual document) and the engineering process followed to
develop the source materials from which the final illustration is prepared.
Managing changes to technical documents requires a close coordination
between the engineering process (the source of most changes) and the
documentation process. Particular illustrations need to be managed as
components of particular documents. Because most illustrations are used to
illustrate logical relations or physical aspects related to engineered
products, changes to them are normally sourced from within the engineering
change process and are normally first implemented in source materials from
which the illustrations were originally distilled (i.e., 3D CAD drawings,
etc.). After a change, these sources are then redistilled to make new static
illustrations or new photographs of the changed product.

CAD drawings actually involve logical connections between the different
elements of the drawing (i.e., the "drawing" is a complex assemblage of
logically related graphic objects). The illustration is generally a two
dimensional simplification of the drawing, which totally removes the
underlying logic. From a management point of view, it is dangerous to try to
change the end product without reworking the source materials. Product data
management systems are designed to integrate into the engineering design
process, so they control all components of the drawings (which may be held
in the CAD system as many separate files).

The type of product Jeroen proposes might be useful as a stand-alone product
to illustrators at the end stage, who often are trying to represent in a
flat picture graphic inputs from a variety of different sources. However,
because the process Jeroen proposes (processing the postscript image) works
with an absolutely flat file format, any logical connections between drawing
components is completely lost, so it would only be useful at the end stage
of the drawing process, where graphic concepts are turned into static
illustrations. I do not see that it would have significant value at earlier
stages in the engineering development or change management workflow.

Other Techwhirlers who are actually more closely involved than I am with the
illustration process may wish to add to this.

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: Enterprise TECHNICAL document management
Next by Author: Re: SGML/XML Justification - was replacement of Frame
Previous by Thread: RE: Enterprise technical document management
Next by Thread: RE: Enterprise technical document management

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

Sponsored Ads

Sponsored Ads