Tagged: OEM

Working with OEM documentation

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.

Legal issues

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.

Localisation issues

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.

In summary

  • 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.

Sharing our source files with other companies

by Jen O Neill

Earlier this year, Tom Johnson in his blog “I’d Rather Be Writing” discussed the issue of documentation ownership. He had recently handed over the source files of several manuals he had done to an internal client and felt that the manuals had been “stolen” from him. He acknowledged that it was the loss of “ownership” that unsettled him. He no longer controlled the quality of his documentation.

Ownership does matter

The topic caught my attention as I regularly exchange source files with customers, developers and our sales offices. Where I differ from Tom is that I am often exchanging source files with those from outside of my company. “Ownership” takes on a legal context in such situations. Whatever I may think about a document being “mine”, it really does matter to my company what happens to it after we hand it over and who becomes responsible for the content.

Sharing files in a collaborative age

In my product group at work we regularly share source files with third party companies. Several of our products are manufactured by original equipment manufacturers (OEMs). We receive their source files of the accompanying manuals to customize for our market needs as well as to rebrand.

Occasionally a large customer may request that we customize one of our product to suit their market requirements, which will mean the documentation too. Usually we would customize the documentation in-house but not always.

Not everybody wants English. Many of our customers don’t operate in English. As we operate globally, we translate into many languages and they may want their language to be customised. A large Danish customer, for example, wanted our Danish translations customised. As we couldn’t do such work ourselves, it was agreed that we’d hand over the Danish source files to them for them do rework and rebrand. They also wanted to customise our Swedish translations themselves.

And everyone wants the source files in Word. Microsoft Word is the common tool between us all.

Signing a contractual agreement

Sharing source files with third party companies — whether receiving source files from OEMs or handing over source files to external customers for example — means that as writers we should be aware of the legal implications. Obviously we shouldn’t blindly hand over source files whenever an external customer requests it.

There must be a contractual agreement drawn up between two companies and one of the items covered will be document customization. This agreement will state whether your company will do the customization in-house or if the source files are to be handed over to customers for them to modify the documents under their responsibility.

Handing over source files to customers

Before handing over source files to a customer, you need to ensure that:

  • Your company branding has been removed—Your company branding must be removed such as company logos, propriety fonts, and any company branding colours. Proprietary fonts, or example, could be changed to a general font such as Arial.
  • The copyright statement has been removed—Unmodified manuals used by customers remain the property of your company. However, if any changes to the contents of the manual are made—including simply replacing your company’s logo with that of the customer—you need to remove your company’s copyright statement from the manual and replace it with the customer’s copyright statement as they are now responsible for the content. The customer then also determines the legal front matter text to be used.
  • The customer has signed the legal agreement—Before handing over source files to a customer, the customer must sign a license and indemnity agreement drawn up by your legal department. Normally it’s the product manager iwho’s responsible for ensuring that the customer signs the agreement and for keeping the signed copy.

Customising third party documentation

The contractual agreement drawn up with the supplier, such as an OEM, will specify who is responsible for customizing the technical documentation and its maintenance. By customising the contents of the supplier’s documentation to meet your company’s requirements, your company then becomes responsible for the content and its maintenance.

You also need to consider regulatory requirements and how they impact the supplier documentation that you are customising. Products branded as your company’s products, or products imported by your company into a regional market such as the EU, must comply with the applicable regulatory requirements (such as European Union directives).

Under new ownership

There are going to be times when we have say goodbye to our work and wish it well under new ownership. Although as technical writers we can often be loath to handing over our source files to customers for fear of the impact on quality, exchanging information is part of doing business. Our work is part of business. We need to know what’s involved when handing over source files to third parties so that we and our companies don’t get any nasty surprises later on.