We have developed best practices and recommendations together with 6 manufacturing companies!
Across all industries, the trend towards increasingly variant-rich products is now daily business for component manufacturers. What we observe time and time again is the same challenge: the type code does not scale!
What is a type code?
“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”.
While 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.
The 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.
An 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.
Why was the type code originally developed?
The 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.
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.
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.
But most companies haven’t quite reached that stage of digitization yet – so why is that?
What are the problems with the type code?
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.
In our first meeting, we discussed the current situation, identified typical problems, and developed initial ideas for solutions.
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.
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.
High effort for preserving old data structures
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.
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 take over this task and free the user from unnecessary details.
Possible solutions and obstacles
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.
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.
The way to the right type code
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!
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.
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.
The middle way – the “semi-speaking type code” as solution
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:
- Products with rather low variance in 3 to 5 characteristics can be well mapped using a cpeaking code. These are often stockable items.
- Products with a significantly higher variance, especially with lot size 1, should not be mapped in speaking codes.
A possible solution therefore lies in the “middle ground” so often chosen: For products with a high variance, one selects the 3 to 5 most important characteristics from the customer’s point of view, codes these human-readable, and describes the remaining variance via a purely machine-readable code. The automotive industry, for example, does something similar: the “VW Passat High-Line 2.0 liter Diesel” is described, but which navigation system or which rims were selected can only be traced in a list of all details.
The solution in a practical test
In our third meeting, we finally developed exemplary semi-speaking type codes for real products. Specifically, together with the companies Bosch Rexroth AG, elobau GmbH & Co. KG, InterApp AG, Komax Holding AG, Kübler Group and Schmalz GmbH selected one series each, determined the most important features, set up a code and then discussed the advantages and disadvantages.
For all selected examples we were able to form a meaningful, semi-speaking type code. Selecting the most important features was also done quickly for all companies.
For one of the companies, type codes are generally out of the question – they don’t have any today and don’t want to introduce any in the future. Another company is satisfied with the fully speaking type code at present time. The other four companies see the semi- speaking type code as the right way forward. The company elobau had already played with this idea in advance and had a finished concept “in the drawer”. One waits still for a good time, in order to begin with the conversion. The Schmalz company is one step ahead. They have recognized the potential for a long time and are already using this type of codes. The following figure describes the semi-speaking type code used today for compact ejectors, as it is already in use. In direct comparison with the concept from the introduction, this is a considerable relief for human comprehension.
Our recommendations for optimizing your type code
Finally, we would like to give you a few practical dos and don’ts:
- Under no circumstances should you reintroduce fully speaking type codes if you are not really sure that future product variance can be mapped in a meaningful way.
- You should also only introduce fully speaking type codes if you can get all products in the company mapped with them. Sometimes it seems so obvious for simple products. But if it doesn’t work for part of the product portfolio, then you need to create and manage redundant processes, IT systems and data structures for the same task.
- If you define type codes with significantly more than 5 characteristics, then you should question whether a fully speaking code is the right and sustainable way forward.
- If you want to make a change from existing type codes to a world without, or at least with semi-speaking codes, then you should start with new products and successively change over. A generation change in the product portfolio also offers a good opportunity.
- If possible, use similar structures and abbreviations within the codes for different products. The same characteristic should be coded the same way for different products, if possible. This makes it easier for outsiders to learn the code.
- If you are an international company, it is better to avoid using German abbreviations in the code. These are not obvious to the vast majority of users.
You know the situation described in this article? You don’t know how to evaluate the current situation in your company? You are unsure what the next reasonable steps are? Ask us! We will be happy to support you.
We would like to take this opportunity to thank the companies once again for their interest, participation and active support! Above all, the good preparatory work of the third appointment contributed to the fact that we proceeded in a goal-oriented manner and were able to achieve good results.
As a global partner, Bosch Rexroth supports the worldwide machine and plant engineering industry with technological excellence and unique industry knowledge. Solutions from Bosch Rexroth help machine manufacturers and users, for example, to produce small batches economically or to save energy while increasing productivity.
elobau is a global manufacturer of non-contact sensor technology, level measurement and operating elements for mobile machinery and mechanical and plant engineering. With its headquarters in Leutkirch in the Allgäu region of Germany and over 1000 employees, the company has made it its mission to offer sustainable solutions.
When it comes to transporting and controlling liquids, gases and solids in the safest possible way, valves and control devices from InterApp play a crucial role. The manufacturing, air conditioning, and municipal sectors rely internationally on InterApp quality metal and plastic valves and accessories.
As the market leader in automation with vacuum and for ergonomic handling systems, we are a partner in demand worldwide. The basis of our success is our innovative strength: it drives all our employees. We know and understand our customers’ requirements and develop the right products from groundbreaking ideas.