TechWhirl (TECHWR-L) is a resource for technical writing and technical communications professionals of all experience levels and in all industries to share their experiences and acquire information.
For two decades, technical communicators have turned to TechWhirl to ask and answer questions about the always-changing world of technical communications, such as tools, skills, career paths, methodologies, and emerging industries. The TechWhirl Archives and magazine, created for, by and about technical writers, offer a wealth of knowledge to everyone with an interest in any aspect of technical communications.
>My company has (some form of) writers duplicating efforts in Bookmaster,
>Preference (On-line help), Phoenix(CBT), and Wordperfect. What a waste.
Join the club -- you are not alone.
>We are considering a new system. This system would become our new word
>processor (but not really) in which we would input our written info. and then
>process it with something like SGML or an EDM system like Virtual Document
>Manager. The end result: the information is formatted for Bookmaster and the
>rest (listed above), thus eliminating duplication of efforts.
>Anyone ever tried this? Do you have any suggestions?
Emphatically yes. I'm writing a case study on an aircraft manufacturer where
the problems were very similar. They swapped a labor-intensive editorial
operation with highly redundant documents for an SGML database approach. Some
of the results of their efforts:
** Saved millions of dollars on the cost of technical documentation for each
helicopter contract they delivered
** Shaved weeks off the final production process; writers can update manuals
until the day they go to the printer
** Eliminated problems they had with inaccurate, inconsistent and missing
information
** Made fewer people enormously more productive; less than half the previous
number of writers are producing 60% more manuals
** They produce Interactive Electronic Technical Manuals (IETMs), CBTs, expert
diagnotic systems etc. practically for free. For example, CBTs that used to
cost $50,000 to produce now cost less than $5,000.
Some suggestions:
1. It won't come for free. SGML systems are not cheap. However, when you look
at the real costs of continuing to do things with format-oriented systems, you
find that the cost difference is a wash.
2. Don't try to write in a word processor, then convert to SGML. You won't get
nearly the same payback because somebody will always be busy fixing the
problems caused by inconsistent formatting during writing and editing. And
everytime the word processor is upgraded, you'll have to go back and redo all
your macros and style sheets, etc.
3. Expect to put in automated composition and/or electronic publishing tools
into the system for the writers. One of the problems writers have when first
adapting to SGML is that the satisfaction of a WYSIWYG on-screen format is
taken away. To give the writers the feedback they need to feel that they are
on-target, you'll need to provide other means of composition.
4. Expect to spend time analyzing and developing the system. Putting up an SGML
system is a lot like putting up a corporate database application. You need to
bring end-users (writers, graphic artists, production people, etc.) into the
process from the start and have them actively involved in the design, tool
selection and implementation phases of the project. SGML is not
shrink-wrapped.
If you focus on analyzing the process problems you face and then developing a
new process, you can achieve impressive paybacks, improvements and give
yourself tremendous flexibility to take advantage of new technologies and
systems cost effectively. The up front effort takes a lot of hard (and fun and
exciting) work, but the payoffs are worth it.
