DSM produces chemicals; it also produces lots and lots of documents. Such documentation better be right, too. Under the EU’s new liability laws, DSM has to prove, for example, that the technical specifications for a new plant are in order.
    Based in Heerlen, the Netherlands, DSM, one of the world’s largest chemicals concerns, employs 19,000 people worldwide and manufactures a vast range of chemicals and materials for the energy, electronics, automotive, packaging, pharmaceutic, aI, agricultural, and construction industries. But in addition to exporting chemicals and materials, it also exports what DSM’s director of corporate systems management, Ranier Maarschalkerweerd, calls “knowledge products,” licenses to DSM technology, which, of course, are largely com’ prised of text,based information.
    According to Maarschalkerweerd, a number of trends are influencing the way DSM does business and hence its documentation process. He notes the ongoing thrust of internationalization and localization, the outsourcing of non’ core activities, and concurrent engineering with third parties all of which call for clear standards. “The chemicals industry is becoming more and more depend, ent on computers and software,” says Maarschalkerweerd, “and that means a growing exchange of information.” One of DSM’s most critical documentation problems is centered around that of stamcarbon engineering, and it is here DSM and PolyDoc set up a joint undertaking within the Eureka project. Each year, the company produces five thousand technical specifications detailing the design, construction, and maintenance of installations. These are written by a variety of engineers and technicians, some of whom are third,party suppliers and subcontractors. Maarschalkerweerd notes that DSM is by no means limited to English; it may have to produce a specifaction in one of up to eighty languages, depending on the nature of the contract and the relationship with the other party.
    PolyDoc analyzed the specifications DSM had been producing and developed a writer’s work, bench based on various Windows applications for producing these documents. At the core of the DSM workbench is an intricate set of templates representing the semantic components of a specifi, cation. PolyDoc also elicited a vocabulary list from a corpus of DSM texts. “This particular domain is very narrow, specific to DSM,” points out PolyDoc’s Rutten. “It covers the discipline of stamcarbon engineering and the building of installations. You can’t buy such a thing anywhere — you have to develop it yourself.,” With verification, language support (spellcheckers, on-line dictionaries, etc), and keyword metafields, DSM’s users can produce specifications much more quickly and — most important — more accurately. Moreover, thanks to the keywords and Folio, View’s query tools, documents can be faultlessly retrieved. “It was an enormous improvement over the previous situation,” maintains Rutten.
    Maarschalkerweerd says there was some initial resistance to the new system; people had to be gentl y lured away from the familiar confines of their trusted wordprocessors. But now, he notes, I they are extremely happy with it and DSM has; signed up PolyDoc for a follow-up project. “User acceptance is a critical success factor here,” maintains Maarschalkerweerd. “Some of DSM’s normalization experts are very old,” adds Rutten. ”Over the years, they’ve made the arduous transition from WordStar to WordPerfect 4.1 and then WordPerfect 6.0. They are adamantly opposed to an ything new. But when they saw what we were developing,” recalls Rutten with obvious pleasure, “they said: ‘…And when will it be ready?’ They wanted it!”

(See  article  that this sidebar accompanied)