A Content-Management Case Study at Kohler


June 2003

A Content-Management Case Study at Kohler

CIDMIconNewsletter Tina Hedlund, Senior Consultant, Comtech Services, Inc. with Mark Peterson, Technical Publications Manager, Kohler Co.

The Situation

The plumbing division of Kohler Co. is no stranger to managing their content. They had been using BroadVision’s document-management system, Relation Document Manager (RDM), for three years and authoring in Interleaf since 1989. But when BroadVision stopped supporting RDM, Mark Peterson, the technical publications manager at Kohler, was desperate to find a replacement. BroadVision offered BladeRunner, but that tool didn’t sufficiently support the heavy and stringent print requirements of Mark’s department. Plumbers don’t always have adequate or readily available access to the Internet.

The Vision

Mark knew what he didn’t like about RDM. He wasn’t able to reuse content, automate production of content into print, or translate modules of changed information.

Content reuse
Because many plumbing products, such as faucets or toilets, look different on the outside but work the same on the inside, 85 percent of the content in Kohler documentation is reusable.

Therefore, a change in part of the internal workings of a faucet, for instance, might mean updating hundreds of documents. Interchangeable and modular content, based on the internal mechanisms in the products, would allow Kohler to update content modules once and populate all the manuals that used those modules.

Kohler produces many small documents that go into the box with the product, such as installation guides, owner’s guides, and specifications. These documents are translated into three languages: English, French, and Spanish. Mark wanted to streamline the manufacturing process and produce documents that included all three languages within.

Mark needed a robust production system that would automate the formatting for information products that are still delivered mostly in paper. The most important of the many production requirements was the ability to format the translated and English content so that all the languages fit into a single manual.

Canadian law requires that content in French be given the same importance (including font size) as English content. As a result, Kohler needed a way to print in multiples of four, but if the content ended up in multiples of three, they wanted to be able to apply conditional formatting to reduce the font of the English and the French content to the same size and still print the Spanish content using a smaller font size because there are no similar requirements for Spanish.

With RDM, Kohler had to submit whole documents for translation even when only a small portion of the content changed. Mark wanted the ability to submit only the changed content for translation and reduce their overall translation costs.

Document Management to Content Management

The transition from document management to content management was a natural next step for the department. They already knew what they didn’t like about RDM, and they knew what functionality they could expect in a content-management system.

Kohler sent a requirements document to a number of vendors. Five responded. Kohler chose XyEnterprise’s Content@ for management of the content, XPP for production, and Arbortext’s Epic Editor for document development.

Interleaf to XML
To get the kind of modularization and labeling necessary to reuse content and reduce translation costs, Mark decided that “XML was our only good choice” and the “only way to solve the problem.” With XML, they could create highly structured documents with metadata (or XML attributes) that could be broken into modules based on their structure. Particular information modules could be left in or stripped out based on the metadata that applied to the content.

“We didn’t go in as XML zealots,” Mark explains, and the transition from Interleaf as their authoring environment wasn’t always easy. The WYSIWYG environment that the technical writers had been comfortable with disappeared. Although on-screen formatting existed in the XML editor, what writers saw on the screen did not look the same as the printed manuals would look.

Writers could no longer determine their own structure; they had to adhere to a Document Type Definition (DTD), which works like a template. Instead of enforcing style, a DTD enforces structure and the application of metadata. The DTD ensured, for example, that every procedure element contained a title and step-by-step instructions and that every procedure contained metadata indicating which model of product it referred to.

Writers had to be careful about applying metadata to the XML tags. If a writer strayed from the proper structure for an element or forgot to enter the proper metadata, the editing software would display an error message, informing the writer that the document was not valid according to the DTD.

DocBook DTD
At the outset of the project, Kohler decided to use the DocBook DTD, which has existed in one form or another for ten years. DocBook was originally marked up in t-roff for the interchange of UNIX documentation, was eventually converted into SGML, and, since the late nineties, has been available in XML. The result of so many years of trying to be the end-all, be-all to technical documentation is a bloated DTD that consists of hundreds of element tags and metadata attributes that must be customized to be useful.

Kohler found that the DTD issue was more complicated than they initially believed and that they needed more than just the vanilla DocBook DTD.

It All Came Out in the Wash

Despite “being naïve” about the work to be accomplished, Mark claims that they “would do it all again.” In January 2002, Kohler completed the initial installation of Content@, XPP, and Epic; they conducted tests until June; and went into full-scale production of their installation and owner’s guides in January 2003.

Although setting up XPP to conditionally format their documents added a year to their implementation schedule, conditional formatting is producing Kohler’s best return on investment. By conditionally formatting documents and reusing content, Kohler has been able to streamline manufacturing costs. Mark estimates that the system will pay for itself in a year and a half based only on these cost savings.

Additionally, the technical publications department has experienced increased efficiency of about 30 percent. Because Kohler is always growing due to international acquisitions, this efficiency is the key to keeping costs down while the workload increases.

Kohler is at about 35 percent of where they want to be for translation. They haven’t automated the process yet, but that’s the next step. Because some translation vendors are more competent in XML than others, they’ve also had some difficulty finding vendors that can efficiently translate XML as well as accommodate SVG graphics. (SVG is an XML-based standard for representing vector graphics.)

The cost savings and efficiencies have been significant, and although Kohler has seen its share of growing pains, they are better positioned to meet the challenges and increased workloads in the coming years. CIDMIconNewsletter

About the Author

June BP15