The top terminology management priorities described in
my previous posting should be no-brainers: Terms need to support the safety and security of the company and its customers, to promote business continuity, and to recognize brands as the most visible aspect of corporate language.
Now let's start using our brains (“No, not
that … not without coffee!”) and start drawing the wavy line between term and "non-term”.
Below the branding level lurk the
terms used in our corporate language. Every organization has its own lingo, its own vocabulary, its own way of phrasing things. A shared language can add to the cachet of a company; it promotes group cohesiveness; it contributes to the feeling of belonging to something special. And good terminology not only enhances that image, it’s fundamental for clear corporate language itself.
A good chunk of these terms are only used internally - slang, jargon, and other expressions impenetrable to outsiders.The more numerous, and more visible, external expressions of our corporate language are those
terms created for and unique to SAP’s products, innovations, and services. These terms clearly distinguish our products and services from those of other organizations'.
But we must be careful. On the one hand, a good portion of our market share depends on innovations, new products, and fresh concepts. On the other hand, our products are intended to be used for long periods and require continuity and stability. Unclear definitions, awkward terms, and inconsistent use will confuse customers, detract from our innovations, and reduce our market lead.
It's thus vital to create snappy, descriptive terms and write clear, straightforward definitions that can both establish themselves quickly and are built to last, particularly for the functions and features of SAP products below the branding level such as
ABAP Debugger and
dynpro. (Look them up if you’re curious; all published for free on
www.sapterm.com – plug, plug!)
Moreover, because our company’s software reflects the processes of several dozen different business sectors, we need
terms specific to entire industries. Our customers and partner consultants use the proper terminology of their vertical industries and specialist topics as a matter of form – so must we. Terms made up by SAP would force our customers to learn “fake” terminology if they wanted to use our products. This is A Bad Thing and something to avoid at all costs.
As an example, medical terminology, such as
medical event,
diagnosis, and
patient consent, is shared across a good number of our products including SAP for Healthcare, SAP Sports One, and SAP Health for Patient Engagement. SAP Sports One, in addition, must include and use sports management terms, including
approach run and
yellow card, to make its player analysis features worthwhile. (This is in addition, of course, to making sure customers in the United States differentiate association football from the American kind during product configuration!)
Moreover, we have offices in over 180 countries and localized versions of our software for more than one hundred of those countries. All of those versions need
terms specific to localized situations. We’d get into trouble and lose sales and reputation very quickly if we didn’t use the terminology of, amongst other things, South Korean taxation (
inhabitant tax), Canadian employment regulations (
modified work day), and Swiss postal service procedures (
ISR check digit) in the way the customers and the authorities require and expect – and in their own languages as well as in English.
Still rather obvious, is it not? We have our own language and we want to share it with our customers. The reverse is also true: Customers and industries want to see their own terms while they work with our products.
Now the big grey area begins! Dissecting that has to wait for the next posting. As they say, “it’s complicated”.
