Re: Enterprise software - reorganizing the help

[Richard Lewis <tech44writer -at- yahoo -dot- com>]

Typically, I create data flow diagrams as a series of parent-child hyperlinked pages of diagrams within a single Visio file.   These can then be automatically converted into a web site consisting of hyperlinked web pages or into PDFs.
   
  The individual function boxes within a data flow diagram can hyperlink to text-based documentation.
   
  Generic Richard

Patrick and Jenny <pat_jen -at- hotmail -dot- com> wrote:
          Hi Richard
   
  Good point. We do use flow charts to document business procedures, and find that keeping them to a single 8.5 x 11 inch size is best. These are most helpful for training new users.
   
  How do you deliver your data flow diagrams - pdf, some sort of online help, printed documents?
   
  Jenny.
   
    ----- Original Message ----- 
  From: Richard Lewis 
  To: Patrick and Jenny ; techwr-l -at- lists -dot- techwr-l -dot- com 
  Sent: Monday, October 15, 2007 9:06 AM
  Subject: Re: Enterprise software - reorganizing the help
  

  Hi:
   
  I lead larger-scale enterprise integration efforts at a large company by documenting As-Is (and some To-Be) situations.   Ninty-eight percent (98%) of what I do is come up with a comprehensive, integrated understanding of essential functionality and, especially, a understanding of the interrelationships between these functions.   
   
  I use data flow diagrams because:
   
  *  Only DFD's focus on the interrelationships between functions.
   
  *  Only with DFD's can one document a whole bunch of software in parent-child relationship diagrams of about 8 1/2 by 11 in size.  This is key to maintainability.  If you have larger diagrams, trying to update them in rapidly changing environments becomes too hard. 
  

Patrick and Jenny <pat_jen -at- hotmail -dot- com> wrote:
  Hi

I'm interested in talking with people who document large enterprise software 
systems.

We want to reorganize our help system so that it is easier to find info and 
simpler to update. Currently we have three types of documentation: End-user 
procedures (available from the Help menu in the app), Setup Guide (a 
standalone chm), and Release Notes (a standalone chm). We also have printed 
reference guides with technical information on advanced procedures and 
setup, and details of all the screens including background calculations.

We have three different audiences - end-users, their support staff, and our 
own high-level support group.

So, I'm wondering where to go from here. There are frequent updates to the 
software (every 2 or 3 weeks), so whatever we decide to do, needs to be easy 
to update.

Any suggestions? Anyone in a similar situation? How should we organize all 
this information?

Thanks, Jenny.
    
---------------------------------
  Looking for a deal? Find great prices on flights and hotels with Yahoo! FareChase.

       
---------------------------------
Be a better Globetrotter. Get better travel answers from someone who knows.
Yahoo! Answers - Check it out.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

Create HTML or Microsoft Word content and convert to Help file formats or 
printed documentation. Features include support for Windows Vista & 2007 
Microsoft Office, team authoring, plus more.
http://www.DocToHelp.com/TechwrlList

True single source, conditional content, PDF export, modular help.
Help & Manual is the most powerful authoring tool for technical
documentation. Boost your productivity! http://www.helpandmanual.com

---
You are currently subscribed to TECHWR-L as archive -at- web -dot- techwr-l -dot- com -dot- 

To unsubscribe send a blank email to 
techwr-l-unsubscribe -at- lists -dot- techwr-l -dot- com
or visit http://lists.techwr-l.com/mailman/options/techwr-l/archive%40web.techwr-l.com


To subscribe, send a blank email to techwr-l-join -at- lists -dot- techwr-l -dot- com

Send administrative questions to admin -at- techwr-l -dot- com -dot-  Visit
http://www.techwr-l.com/ for more resources and info.