Let’s discuss an issue which is of major importance to all of us in the consumer products industry – Your product catalog. SAP is providing an excellent tool to help manage master data in general and product catalogs in particular, and this tool is naturally the SAP MDM. However, using this tool is not enough, and we, as business process experts, should pay attention to a few major points from as early on as the blueprinting phase of the project, to make sure our product catalog management initiative turns out to be a success. The first thing I want to mention is the ever changing nature of the data model. Some examples: o A new marketing-related attribute is required to support a new marketing concept – For example, your company just started publishing its catalog through the web, and a new type of image for a web icon (low resolution image) is required. o A new logistic-related attribute is required to better support logistic processes – For example, standardization of package sizes leads to a new attribute, “Package Size Category”, which is syndicated to logistic systems and logistics service providers. SAP MDM, like most other comparable tools, manages only one data model, being the attributes and relationships describing the product catalog. That means that whenever you do the change, it is automatically imposed on all products in your MDM repository. It may be the case that this is the required behavior, meaning, if we use the web marketing example, that indeed all products need to have this new “Icon Image” attribute as they are all going to be published on the web. However, in some cases, a new concept shouldn’t be applied to all the products you manage. For example, some of the products in the repository are no longer for sale, and are maintained only for support purposes. The last thing you want to do is go through a long and tedious data migration process for products which are no longer sold (and there’s probably no business case for that either). In the latter case, the ideal thing would be to somehow keep the data model of some products the same as before while changing the data model for other products. Well…easier said than done! The problem with all “repository tools” (including SAP MDM) is that they manage only one active data model and cannot apply different data models to different records in the same repository. But there’s a trick! Consider the question – Do you really need to change the data stored in the “old” data model? Let’s take the former example, that of web-marketing. Those products which are only maintained in the repository for support purposes, probably will never be changed, or at least, their marketing content will never be changed. In that case, what you might consider doing is maintaining a second repository, let’s call it “complete catalog repository”, where the last version of any product is stored as a single file (XML would be a wise choice but we’re not in the BPX business to discuss formats). The active repository will actually not have any explicit knowledge of the data model of the file, but will have a data model “version” associated with each file. That way you would be able to know hoe to “interpret” the file whenever you do need to access the data in it. In parallel to this repository, you will keep on maintaining your “old” complex repository which manages all the attributes and relationships. Let’s call this repository as the “active products repository”. Any data model change would only happen in this repository which will only contain those products whose data you expect to change and therefore want to keep them up to date with the data model. The way the process should work is whenever a product is changed or created, you perform this activity in the “active repository”. Once this creation or change activity is completed, the “active repository” will export the product data as a single file which will be uploaded into the “complete catalog repository”. 
With this dual-repository architecture you are able to support multiple data models concurrently (though only one is active) and facilitate the ever changing nature of business. Great, isn’t it? In my next blog I will discuss another usage for the dual-repository architecture, this time from a publishing perspective.
With this dual-repository architecture you are able to support multiple data models concurrently (though only one is active) and facilitate the ever changing nature of business. Great, isn’t it? In my next blog I will discuss another usage for the dual-repository architecture, this time from a publishing perspective.
2 Comments
