|
|
|
Don Bridges |
|
Data Conversion Laboratory |
|
|
|
|
|
Who is DCL? |
|
What to convert? |
|
The business side of the equation |
|
How long will it take? |
|
What about Automated tools? |
|
How much will this cost? |
|
Data conversion process |
|
What should I look out for? |
|
Case Studies |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Option 1: Convert nothing |
|
No conversion costs |
|
Delayed ROI |
|
Option 2: Convert everything |
|
High conversion costs |
|
Reduced ROI |
|
Option 3: Convert ‘frequently used’ documents |
|
Some conversion costs |
|
Maximized ROI |
|
|
|
|
|
Convert documents that are most used |
|
They will have the most re-usability |
|
ROI will be demonstrated faster |
|
Convert documents that are customer favorites |
|
They will enable customer satisfaction |
|
Don’t forget: Customers are internal and
external |
|
Convert documents with longest product life |
|
You’ll reap the investment longer |
|
When in doubt start in the present and go back |
|
|
|
|
|
|
|
|
|
|
|
Increasing Revenue |
|
Increase Customer Satisfaction |
|
Decrease Time to Market |
|
Expansion into New Markets |
|
Decreasing Expenses |
|
Increasing Authoring Productivity |
|
Reducing Publishing Costs |
|
Increasing Information Reuse |
|
Reducing Translation Costs |
|
Future-Proofing Data |
|
|
|
|
|
Hardware |
|
Software |
|
Labor |
|
System Configuration |
|
Training |
|
Data Conversion |
|
|
|
|
|
The Business Case for XML |
|
by DCL |
|
www.dclab.com/businessxml.asp |
|
Building the Business Case for XML |
|
by Arbortext |
|
www.arbortext.com/html/webinars/webinar11_files/frame.htm |
|
XML Cost Savings Toolkit |
|
by Arbortext |
|
www.arbortext.com/html/cost_savings.html |
|
XML Business Case Calculator |
|
by SPX Valley Forge TIS |
|
www.vftis.com/presentations/SPX_Valley_Forge_bus_case_calc.xls |
|
|
|
|
|
|
|
|
Schedule depends on complexity of the project
and resources available |
|
Is there a paradigm change? |
|
How good are your conversion tools? |
|
Set-up requirements |
|
How much post-conversion clean-up |
|
As a rule of thumb, plan on 3 - 5 minutes per
page to clean-up and correct if the paradigm is consistent |
|
|
|
|
|
Programming languages |
|
Flexible & powerful, but not always
straightforward |
|
examples are XSLT, Omnimark, PERL, AWK |
|
Integrated packages |
|
most authoring packages have basic import tools
(such as Interchange in Arbortext’s EPIC) |
|
typically not “industrial strength” tools |
|
Stand-alone tools |
|
most are format specific such as Filtrix
(Blueberry), WebWorks (Quadralay), WorX (Hypervision) |
|
|
|
|
|
|
So how good are they? Yield will depend on three main factors: |
|
Consistency of input data |
|
How much of a paradigm change |
|
Flexibility of tool to your situation |
|
does your data have the ‘hard stuff’ (such as
effectivity tagging, tables, cross references, headers, footers, equations,
figures, etc..) and can the tool handle your data |
|
|
|
|
|
Time to Market |
|
Can the world wait a year for you to be ready? |
|
Quality |
|
When you show it to the world, will you be
proud? |
|
Cost |
|
Do you really know what it will cost? Are you sure? |
|
Scalability |
|
Can you do thousands or millions of them the
way you did your demo? |
|
|
|
|
|
|
|
|
|
|
Data is so sensitive that it must stay internal |
|
Paradigm is consistent |
|
Your schedule is flexible |
|
Materials are not complex |
|
Clean-up requirements may vary widely |
|
Budget is tight & in-house resources
available |
|
Tools are relatively cheap |
|
Project is small |
|
|
|
|
|
|
|
|
Paradigm is changing |
|
Meeting schedule is critical |
|
Materials are complex |
|
Demonstrate expected results while there is
still time to make modifications |
|
Budget is well defined |
|
Understanding the project costs and the
trade-offs |
|
Project is large |
|
Process scales as big as needed |
|
|
|
|
|
|
|
Project Engineering (Set-Up) |
|
Document Analysis |
|
Conversion Specification |
|
Pilot (Proof of Concept) |
|
QA Plan |
|
Production Planning |
|
Production |
|
Conversion |
|
Post Processing QA |
|
|
|
|
|
|
|
|
|
Example:
Automated Links |
|
See figure 15.5 |
|
See fig. 15.5 |
|
Refer to figure below |
|
As illustrated on previous page |
|
… drawing 15.5 years at hard labor. |
|
See figure 15.1 in volume II of … |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
GE Power Systems (Schnectady, NY) |
|
Manufacturer of gas turbine motors |
|
Migration from Interleaf to XML |
|
Very large volume of data and very demanding
schedule did not allow for time to become data conversion experts |
|
|
|
|
|
|
Mercury Marine (Fond du Loc, WI) |
|
Manufacturer of small boat motors |
|
Migration from Interleaf to XML |
|
Multiple languages, a very demanding schedule,
and decomposing the data into elements complicated the issue. |
|
Change of paradigm |
|
|
|
|
|
|
|
|
Schlumberger (Houston, TX) |
|
Oil field services company |
|
Migration from many formats (Word, Frame, Paper,
etc..) to XML |
|
All technical and training documentation across
multiple divisions migrated to a single DTD. Consistency critical. |
|
Change of paradigm |
|
|
|
|
|
|
|
|
BEA Systems (San Jose, CA) |
|
Application infrastructure software company |
|
40 writers and 400k pages of extremely
consistent FrameMaker documents |
|
Requirement to provide daily update of data in
HTML and PDF |
|
Utilize WebWorks for automated conversion that
delivers converted content during nightly builds |
|
No change in their paradigm |
|
|
|
|
|
|
Large electronics manufacturer |
|
Desktop Printer Division |
|
Migration of 250 pages from Frame to XML |
|
Utilized manual conversion as a method for tech
writers to gain familiarity with XML. This approach was enabled by low
volume and manpower availability. |
|
|
|
|
|
|
|
|
|
Notes
