A consistent product data model is fundamental to sales success. This is because only a comprehensive product data model provides customers with the desired filters to quickly find the desired product and the opportunity to compare different desired items.
This presents retailers with the great challenge of mapping more extensive product data models on the PIM system suitable for the company. Product data models specify how products are best described by which attributes, contain all the required value lists for consistent search filters, and facilitate the setup of comprehensive product data governance, i.e. contain the category tree. In addition, the model indexes which information suppliers should provide on products and articles. Thanks to Continuous Migration, new product data models can be tested and, if necessary, adapted quickly, practically, agilely and, above all, iteratively. How this works and why this approach is so important is explained below.
There are essentially two use cases that make it necessary to quickly check a new data model. One is when the entire existing product data model has to be rethought because previous structures are no longer sufficient, or when a new PIM system is introduced.
PIM systems have become indispensable in the modern world for several reasons: On the one hand, the PIM serves as a central database for all product-related information and, on the other hand, it facilitates the further processing of this data, for example for webshops or catalogs. In order to exploit all the possibilities of the PIM system, an appropriate product data model must be stored in the PIM. But how do you build one correctly?
The creation of a product data model takes place in two phases. In the first step, categories are refined or newly created and thus the category tree is created or revised. Then, each category or product family must be described with a uniform attribute set. Finally, the metadata (data types, value lists, units, etc.) must be defined for each attribute.
A major hurdle in the introduction of a new product data model is to check its completeness and to test whether it can be mapped well with the existing product data. In the classic approach, the plausibility of the new product data model is checked by means of a full migration, followed by one or two iterations. This is cumbersome from several points of view: Everything has to be considered on paper and far away from the actual product data and discussed theoretically with a long lead time, described and introduced as fully as possible. This is associated with large personnel expenditures and tied-up resources. In addition, the adaptation and sharpening of the product data model is time-consuming, costly and comprehensive.
Continuous Migration, or the 2.0 approach, skilfully eliminates the cumbersome nature of the classic IT migration approach: Instead of a large and cumbersome migration, many small iterations are used. Because feedback is received quickly, adjustments can be made and checked selectively. As a result, the product data model quality is significantly increased quickly, agilely and iteratively iteration by iteration. Because only those who can work quickly with the existing data and their mappings can also quickly see where improvements are necessary.
In practice, the implementation looks as follows: The new data model is created on the Onedot product data platform and desired PIM test system. The existing product data from the live system is also loaded into the product data platform. With this information, Onedot's AI-powered software can map existing product data to the new model. In the process, the product information is automatically mapped to the structures specified by the product data model in a clearly structured process.
As soon as this process has been completed and the product data has been mapped to the model accordingly, it is quickly apparent whether adjustments are still necessary in the product data model. After any adjustments, the product data is mapped again to the improved product data model structure. Of course, the product data is continuously exported from the live system. This process is repeated until the product data looks right in the new structure, i.e. is correctly displayed.
The fine-tuning of a product data model can only be done on and with the product data. The faster you can test the product data model on the existing product data, the smoother the introduction of a new PIM system or product data model. Thanks to the use of Onedot's product data platform, however, there are even more advantages.
Thanks to Onedot's AI-powered product data platform, companies need to deploy fewer human resources and do not need to bring in their own IT for the migration, as category or product managers can accompany them. In addition, once the Continuous Migration is complete, the AI is already trained on the company's own product data model. This subsequently enables a very fast ramp-up of automated supplier onboarding.
In this way, companies can guarantee the desired product data quality across a broad and deep product range. This is precisely the approach 2.0 that is needed to make adjustments to the product data model quickly, agilely and sustainably. This is the only way to introduce a consistent product data model that is also future-proof.
