by Jen O Neill
Outsourcing manufacturing is big business. Many companies today use the services of other companies to make, even design, some of their products as it can provide them with needed components or products without owning and operating a factory to do this work themselves. The benefits are cost savings, improving time to market, and access to a wider range of products than they could develop themselves in-house. Both hardware and software are outsourced.
What’s an OEM?
Companies to whom manufacturing is outsourced are called Original Equipment Manufacturers (OEMs). An OEM is a company that “manufactures goods that are sold to other businesses that might rebrand them and sell them at retail”. Source of OEM definition.)
An Original Design Manufacturer (ODM) is a company that “designs and manufactures a product which is specified and eventually branded by another firm for sale”. (Source of ODM definition.)
OEM and ODM products are used in many industries, but particularly so in electronics. These companies are located around the world but many are based in Asia. In this article “OEM” has been used to cover both OEM and ODM companies.
The OEM source files
If you are rebranding or rewriting OEM documentation, be aware that in the world of OEMs, Microsoft Word rules. As cost control is a big issue with many OEMs, few have technical writers in-house but instead get their engineers to write the documentation. They use Word.
And often they’re not writing in their mother tongue – most OEMs aren’t located in English-speaking countries. The documentation consequently can often be poorly written and riddled with an “English” contaminated by another language.
Rewriting OEM manuals can be challenging, particularly if you’re working to a tight deadline and the English is poor. If your company works with many OEM products, a further challenge is trying to keep the rewritten manual consistent with the content of the other manuals in your company. Reuse of content is particularly important to help control translation costs. Yet writing for reuse can at times feel a challenge when you’re struggling with reading to comprehend, particularly if you don’t have access to the OEM engineers to ask what they meant in the text they wrote.
Some companies just simply rebrand an OEM manual and leave the content as is. There are unfortunately many examples of such manuals on the internet. Lots of companies don’t have the services of technical writers. And don’t consider the business benefits of having them either.
Keeping terminology correct and consistent
Working with OEM software and documentation increases the need for terminology control as there’s a greater chance of unapproved, inconsistent, and incorrect terms being present than when content is developed in-house. Even when correct, terms may also not always be the same between companies.
Build a glossary of terms related to your OEM documentation and software that includes both the correct and incorrect terms. Include context of use, the definition of the term. So next time a writer in your group is working on an OEM manual and they come across “appearance time”, for example, they can quickly look it up in the glossary and see that this must be changed to “display time”. As with all glossaries, this is a living document and must be regularly maintained.
Fluency in other languages is certainly a help when working with OEM documentation as it can make it easier to spot problems with terminology. One example we had of “flavoured” English was in the software of a French ODM we used to develop a program for us. They used the term “equipments” throughout the English source software. We changed this franglais (English with French influence) term to “devices”. The word “equipment” exists in both languages but the context of use can differ. In French this is called a “faux amis” or “false cognate” in English. Be continually on the lookout for such faux amis when checking software and documents written by OEMs.
Where possible, give the OEM your company’s glossary of approved terms to use when customizing products for your company. But continually check that your company’s approved terms are indeed being used, particularly when the product is updated. A different engineering team perhaps might be put in charge of the product update and for whatever reason they could ignore or overlook your glossary. Stay alert.
Reuse as is or rewrite the OEM documentation? This question will be answered in the contractual agreement drawn up between the OEM and the company using their services. It will specify whether the product documentation will be handed over by the OEM to be customized. So if you have any specific documentation needs, such as you want to the source files in XML, FrameMaker, or HTML, for example, you should ensure that this is agreed upon before any contractual agreement is signed. But as stated earlier, most OEMS work in Word.
In my experience, many OEM manuals have incomplete or no regulatory information included, where required. If you are rebranding/rewriting OEM manuals, check that all required legal information is indeed included for your market. Although legally the manufacturer is responsible for placing the CE mark on the product, for example, once you rebrand it, you then become legally responsible. See an earlier blog on sharing source files with third party companies.
In my experience, few OEM companies consider the impact of localization on their software and documentation even if they are selling their products worldwide. And that includes OEMs with in-house technical writers.
If you will be translating the documentation you’ve inherited from an OEM, you should review it for potential localization issues such as embedded text in graphics (do you have the source graphic files or just the jpeg files?), terminology (mentioned earlier), and possible cultural issues in the content. One OEM my company worked with had in-house native English-language technical writers who targeted their documentation to the America market although the OEM sold its products in many other countries. They had, for example, used the term “Thanksgiving” in a section of a user manual on programming schedules instead of the generic “public holiday”. We had to carefully go through their manuals to ensure that the content was culturally neutral for our market in Europe, Middle East, and Africa.
- From the contractual agreement and your product managers, find out what has been agreed with the OEM with regards to the documentation.
- Develop a glossary specific for this OEM (or expand your group’s glossary) that includes correct and incorrect terms.
- Check that the legal information in your rebranded/rewritten documentation is correct and complete.
- If you translate, check for potential localization issues.