PIM is short for Product Information Management. At the outset that could mean all the data about your products, but in practice you want be a bit more selective on what you include in your PIM system to ensure efficient operation.
PIM can take different roles in the overall system and sometimes even multiple distinct roles at the same time. It can be used for simply handling the descriptive data of the items, for example an e-commerce store. It can also take a larger role in handling the item lifecycles and it can used as the master of item data. When using PIM in a larger role, care needs to be used to avoid PIM taking on too many responsibilities from other systems. Each system and application, including PIM, has their strengths and weaknesses and it’s always good to take those into account. Which kind of users are going to be using PIM is also an important to consider, business-oriented users and technical users have very different requirements.
What data to include in PIM?
Marketing and selling data (product names, descriptions, attributes, etc.) are the core of what PIM is designed for. This role requires the least amount of customization to implement and makes using PIM simple for the end users. In a minimalist use case PIM will take in product identifying data and then the marketing and selling data is filled in in PIM and finally the data is sent out to downstream systems (for example to an e-commerce store).
Including pricing data in PIM often comes up when planning what data to include in PIM. However, while it might seem convenient to have the pricing data next to the other product information, in practice it might not be so smooth to implement or use. Pricing is complex and involves rules and regulations which tools specifically made for pricing already contain.
Logistical data is another example of data that probably should be handled elsewhere. While PIM does have tools to have relations between items and logistical units this can end up being difficult to manage.
Should PIM be the master system?
As PIM has a nice, user-friendly UI, powerful interface capabilities and it could also be a large investment so it might be tempting to have it as the master system. While PIM can work in this role, careful planning is needed.
First thing to think about is if there is some other system in the architecture that would take a large role, ERP systems are a common example. If there are such systems, it could lead to a “dual master” kind of design which is detrimental to the system architecture. Keeping both systems in sync could require large amounts of work and both could end up having fields and attributes that are only needed for serving the other system.
Another pitfall is using PIM as sort of “a remote control” for the other systems in the architecture where PIM duplicates functionality of some other system just so things can be done in PIM and then sent to that other system. Preferably things should be done in that other system or is that system even necessary if things can be done in PIM.
Key points for selecting the role for PIM
Defining the role of PIM is not an easy task, but care should be taken so that implementation will be straightforward, PIM will work efficiently and end users will enjoy using it.
Few key points to consider:
Take advantage of PIMs flexibility and ease of use
Consider what other systems in your environment will be used for
Carefully choose the data to be included
Avoid duplicating fields, attributes and functionalities of other systems