{"id":8114,"date":"2021-09-16T09:17:00","date_gmt":"2021-09-16T07:17:00","guid":{"rendered":"https:\/\/e.keyrank.de\/the-type-code-a-blessing-or-a-curse\/"},"modified":"2024-11-28T13:45:50","modified_gmt":"2024-11-28T12:45:50","slug":"the-type-code-a-blessing-or-a-curse","status":"publish","type":"post","link":"https:\/\/www.encoway.de\/en\/blog\/the-type-code-a-blessing-or-a-curse\/","title":{"rendered":"The type code \u2013 a blessing or a curse?"},"content":{"rendered":"\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t\t
\n\t\t\t
\n\t\t\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\tAcross all industries, the trend towards increasingly variant-rich products is now daily business for component manufacturers. What we observe again and again is the same challenge: the type code does not scale!<\/em> Together with 6 companies from the manufacturing industry, we have developed best practices and recommendations!\n

What is a type code?<\/h2>\n“Type codes”, often also called “product keys” or “order codes”, are character strings that uniquely identify a variant of a configurable product. Analogously, they also describe (stock) components from which products can be individually assembled; typically called “part numbers” there. They look like this or similar: “ABCD-12-3E-F-45-G6”.\n\nWhile component manufacturers often use the “type code” to communicate with customers, machine and plant builders use the “part number” for internal communication. What both have in common is the fact that they encode the subset of characteristics relevant for identification. This article focuses on the “type code” – i.e. the external representation of the product variance towards the market. We call it a “speaking type code” when it is a human-readable encoding.\n\nThe illustration of type codes to the customer is almost natural for most component manufacturers. Often the structure is even explained graphically in a data sheet. What we often observe is that the type code reaches a length and also complexity where the attribute “human readable” can be questioned. And this is exactly where this established tradition collides with the current requirements of individualization: the type code scales only up to a finite set of product variants.\n\nAn example: a compact ejector from the Schmalz company, including the selection of optional attributes, has about 20 sales-relevant features that uniquely identify a variant. Assuming we code these features with two characters each, the entire key, including separators, would have a length of just under 60 characters. Later in this article we show that this variance can be mapped more cleverly by the illustration of the code used by Schmalz. Before we delve deeper into this challenge, let’s venture a little review.\n

Why was the type code originally developed?<\/h2>\nThe type code was developed to transport large amounts of information with little space available. Especially when the number of variants can no longer be listed in a meaningful way, passing on this information in form of a modular system is a valid form. We must remember that at the time when the type code was invented, information transfer and order entry in paper form were the normal way.\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t\"\"\t\t\t\t\t\t\t\t\t\t\t\t\t\t\t<\/div>\n\t\t\t\t<\/div>\n\t\t\t\t
\n\t\t\t\t
\n\t\t\t\t\t\t\t\t\t

The aim of the coding is to provide an unambiguous description of the characteristic values available for selection. For example, the code “B” can stand for the color “blue” and then describes a clearly defined hue. In the form of free text, there would be no limit to the descriptions – and this would not be unambiguously interpretable. It quickly becomes clear that the type code represents a kind of “foreign language” that has to be learned. Those who regularly buy from the same manufacturer quickly get used to this language. Those who buy occasionally, and from several manufacturers, usually have difficulties. This makes the customer’s shopping experience more difficult.<\/p>\n

Today’s digitized world offers completely different ways of processing information. One of the most important innovations here is to use different views of a data model. Parts of the existing information can be hidden and other parts can be translated at the same time. In this way, each user sees exactly the part of the available information that is relevant for the current task – and can focus on precisely this task.<\/p>\n

But most companies haven’t quite reached that stage of digitization yet – so why is that?<\/p>\n

What are the problems with the type code?<\/h3>\n

Our customers and befriended companies from our network repeatedly report that the actual product variance is not adequately represented in their type codes. We have taken this as an opportunity to approach the causes and also possible solutions together with these companies in an open exchange. We organized and conducted an online exchange of experiences consisting of three meeting. In the following, we describe the core findings.<\/p>\n

In our first meeting, we discussed the current situation, identified typical problems, and developed initial ideas for solutions.<\/p>\n

In addition to the cognitive ability of humans, IT systems also have limitations. For example, the lengths of data fields in ERP systems are often limited. At elobau, for example, the ERP system has a limit of 16 digits for the type code. This limit is quickly reached when product families are made. At Bosch Rexroth, this limit is 40 digits. The exemplary calculation for the length of a type code of the company Schmalz as it is calculated above, however, would not fit into a data field with 40 characters. If such a limit is reached posterior to the concept by increasing variance, then a reaction to the situation is particularly difficult.<\/p>\n

The underlying data model is static, while products evolve. New features need(ed) to be included in the data model. This in turn leads to a changing language – and thus confusion on the customer side. In general, changes to the type code are difficult to communicate. As a result, historical legacies are rarely eliminated and an initially coherent specification of options becomes fuzzy and, above all, confusing over time.<\/p>\n

High effort for preserving old data structures<\/h3>\n

So a lot of effort is put into building and managing outdated data structures. In general, data structures are important in the age of digitization – but there is often a lack of purposeful design.<\/p>\n

Indeed, one of the most serious aspects is that not all digits in the type code can be freely combined. For example, not every pumping speed and every basic valve position are available for every line of the Schmalz compact ejector. With increasing product variance, the possible combinations can no longer be meaningfully read from a schematic representation for untrained users. Digital systems such as product configurators<\/a> take over this task and free the user from unnecessary details.<\/p>\n

Possible solutions and obstacles<\/h3>\n

In our second meeting, we therefore asked ourselves how a world without the speaking type code could look like – and above all: which obstacles stand in the way of a change.<\/p>\n

It is well known that the biggest obstacle to any change is the sentence: “we have always done it this way”. In a similar way, it is often argued that customers know the code and like to use it. However, this argument only counts for existing products. With new products, one definitely has the possibility to go new ways. Part of this path can also be a software-supported communication of the product variety. In this case, the customer does not even have to learn a new language.<\/p>\n

The way to the right type code<\/h3>\n

The actual biggest obstacles lie within the manufacturing company itself. Because type codes have been used for many years, they are firmly anchored in the processes and IT systems. A discontinuation of speaking type codes directly represents a large change project!<\/p>\n

A complete overthrow of existing data models and systems is therefore inconceivable for most companies. If one wants to go this way, then the only way is a successive replacement of the product areas – that is: by a temporally limited parallel operation of the old and the new world. This investment is more profitable for companies that would otherwise not be able to map their product variance. Other companies will generally live with the current pain until it becomes too great.<\/p>\n

In the long run, there should be exactly one type of product identification in the company. Because: IT systems are used most efficiently when there is exactly one system for one task – i.e. mapped in the same way across all products. Any system variance besides that means redundancy – and thus additional process costs.<\/p>\n

The middle way – the \u201csemi-speaking type code\u201d as solution<\/h3>\n

A core insight is: we make this kind of mapping for us humans. Computers can interpret the same amount of information in a much more compressed space. So extending field lengths in IT systems is not a real solution. The human cognitive limit is typically seven “information chunks” that we can take in and process simultaneously. Seven elements, each encoded with two characters, and separated by a separator, reach a total length of 20 digits. Nothing beyond that should be considered as a “speaking” code. So we can state as a reasonable limit for the application of type codes:<\/p>\n