Interview: Ben Martin, J.D. Edwards
We recently asked Center member Ben Martin, Director of Worldwide Publications at J.D. Edwards & Company about his experiences with single sourcing.
You started single sourcing very early on. Can you describe how you became interested in it and how you convinced senior management to invest in the tool development? In 1992, our CEO and founder, Ed McVaney, declared the “word” the number one enemy to J.D. Edwards’ success. To illustrate his point, he hauled in all the reference guides for our 55 sets of products, all the tutorials the technical writing team was hatching, all the training manuals the course development team was authoring separately, all the third level brochures the marketing writers were re-word smithing, and the printouts of the online help being authored by the programmers. The room was spilling over with the demise of several huge trees.
He not only invited the violators (the marketing writing management, the training management, and the documentation management), he hauled in the senior executives of all the corporate functions at that time. At that moment, he mandated that we figure out how to write it once and repurpose many times, translate it once and replicate it across foreign deliverables.
This watershed event was the culmination of several frustrated attempts to jump start our entry into foreign markets and translate our products and their associated product information deliverables. Our translation center in Paris could not staff or organize to meet the independently derived deliverables that were enhanced, rewritten, and often, redesigned every 9 to 12 months.
The documentation was maintained in Ventura, the training materials were scattered across a woefully primitive text management editor for the System/38, Word, WordPerfect, and PageMaker. The marketing material ended up in Quark but never seemed to originate in any one standard word processing product. The online help was a proprietary help facility that had no links to the documentation set of information.
It was a dark day for those of us with our specialized degrees in Instructional Design, Technical Communication, and Marketing Communication. We knew our audiences and we did not want to lose control over the requisite flavor needed to meet their needs. Despite separate organization structures, we were thrown on the same floor together and eventually found ourselves reporting into the same management structure. Our translation center was yanked out of Paris and planted right in our midst, serving as a daily reminder of the mandate-solve single-sourcing. We had no trouble convincing senior management; we just had trouble convincing ourselves. We had two choices: quit or single source. Many of us remain to this day who made the latter decision.
Describe how the change to a single source environment affected the organization of your department.
Once we decided (or it was decided for us), and we were restructured into the same leadership, we were given (like the Apollo 13 ground crew) a budget, a few primitive tools, an RFP process, and a lot of disgruntled check-ins (why is it taking you so long?) to “solve” single sourcing. First, we did the product/tool search scanning the SGML products of the day as well as the high-end publishing tools. We went with a total Interleaf solution-meaning desktop publishing, document management and CD-ROM publishing applications. We then customized the heck out of it and databased every paragraph we wrote.
Our first step was corralling all the tributaries of information, merging them into one virtual information vat and then converting them into the Interleaf format (No small feat). We did this through exhaustive task analysis with cross functional teams analyzing the existing information and then retasking it in a way we all agreed upon. Our instructional, tasked based approach was the key information design strategy to our success. We then chunked up (or up-chunked as some of the writers called it) our information into bite-sized (WinHelp panel sized) tasks that could be assembled into chapters that were assembled into sections that were assembled into book sized sets of information that served as the training manuals and the user guide and the online help for a single application. One set of files contained all the markup for WinHelp, for our proprietary Help system, our user guides including indexing and conditional assembly, our training guides, and our CD-ROM deliverable which eventually turned into.PDF files. And our translation team needed to translate only one set of files for say Accounts Payable and at the completion of their translation effort, JDE had a translated training guide, translated online help both field level and program level, a translated user guide and a translated.pdf Web deliverable. The ROI was spectacular and the efficiencies monumental but the effort was painful.
The technical writers went from 90 percent of their time authoring content to about 35 percent of their time on content authoring. The remaining time was divided up into architecting (assigning metatagging, WinHelp coding, hyperlinking, indexing, chunking), task analysis, and reconciling cross-functional edits. Suddenly, the writers were the information junction and the only gateway for Response Line and Training to get information into the target seven languages of French, German, Spanish, Italian, Chinese, Japanese, and Portuguese. Instead of being a back office function that was producing a necessary evil (documentation), the technical writers were servicing the information needs of all the product support functions of the company and providing critical just-in-time information for all aspects of JDE business.
How long was it before the tool and process were up and running smoothly? Did you lose any work time during the change?
We have always had aggressive, unachievable timeframes and never secured a reprieve from delivering deliverables at the same time we were reinventing them. It was likened to changing the tires on a moving truck or drinking from a fire hose. After a six month search we settled on Interleaf in March 1993. We then took almost a year and a half converting our data from their various and sundry sources into Interleaf. At the same time, we were producing documentation for the release of the day.
Once we corralled the information, we tackled our field level help (over 30,000 fields required definition), we designed a database approach to authoring them once and then pulling them into our guides where appropriate and uploading them to JDE applications so they could be displayed when the user pressed F1 or right mouse clicked on “What’s this?” This was not a trivial task.
We then took on WinHelp. We were moving from an AS/400 (IBM mini-computer) centric application group to a client-server application set of software. We built into our architecture ways for the writer to enter the WinHelp jumps, resolve them and then port them to.rtf where they were complied. True to single sourcing, all hyperlinking remained in Interleaf and no repair or additions were allowed outside our Interleaf repository. This allowed us to maintain consistency across all languages and allowed us to focus our translation resources on content only and not on replicating WinHelp structures.
Once we solved the databasing of our field level help and the WinHelp link assignment, we were ready to tackle the automation of our translation process. We added to our publication tool kit a translation memory tool (IBM’s Translation Manager) and started databasing every English sentence and its translated counterpart. This gave us a net change approach that allowed our in-house translation teams to focus only on what they had never translated before and reduced the redundancy of effort of recurring phrases.
We celebrated the completion of the publishing system in the Spring of 1997. Of course, the day we declared it bug free and operating without a glitch was the day I launched us into developing a more Web-centric, publish-on-the-fly, translate-it-on-the-fly, content management solution that we are currently developing today.
How has single sourcing affected your translation processes?
Delivering release-current documentation is necessary in a global market. The single-sourcing approach is the only way we can achieve our goal and achieve it with our online help, our training materials, and our user guides. The single-sourcing method puts the pressure on the English writer who must define the information once for all languages and then it is preserved throughout the translation process.
From the indexing strategy, the page layout, the hyper-linking, the WinHelp design, and so on, the writer does all the information architecting. The translators need to focus only on the content and then final review the deliverables without getting embroiled in screen captures, pagination, page layout, and WinHelp debugging. We end up using a third to a fifth of the translation resources of companies who must translate comparable volumes.
If you had to advise someone on making this change, what mistake or oversight from your own experience would you warn them about?
Our single-sourcing design focused first on print and then we solved online. If we could have worked it differently, we should have designed our information for online and then derived our print design from that. We are in the midst of redesigning our information base -we have a little further to go to get it to a Web-centric, intranet based product as a result of our print-based publishing system.
We should have started with a clearer design before we ever ventured into translations. We stubbed off a lot of custom code because we tried to solve our translation issues before we settled on a translation memory tool.
Finally, since you’ve already tackled what most consider to be leading technology in technical publications, where do you see your group going from here?
I have heard it said that in 1988 it was MRP (Material Resource Planning); in 1994 ERP (Enterprise Resource Planning) and 1999 it’s E-business. I believe in 2003 it will be e-content. I believe we are pioneering what that world will be like. The tools we are developing for our internal needs are premised on a Web-based, xml data base. Just within our own enterprise of 5000 employees world-wide, we have a lot of enterprise-wide opportunities to develop and manage content in new ways and extend self-service power to our users who need access to information faster and who need methods for customizing it in multiple languages.
Our expertise in pioneering single sourcing in eight languages easily transfers to some of the tough problems of orchestrating information across today’s companies who are prone to acquire or be acquired, partner, and change on a dime. Industry analysts say that content management will be a 5 billion dollar market and grow 40 percent over the next five years. We believe we are there with the tools, the content stores, and the expertise not only to support the JDE ERP application software, but also to offer our clients and even non-ERP clients a robust content management solution.
I have been in the industry long enough to see us go from a back office, necessary evil function to suddenly being a market differentiator and now possibly redefining the market in an information economy fueled by e-business and knowledge management.