The PIM project must be carefully thought out beforehand. First of all, the company must express the need and establish the specifications while involving the business lines such as marketing, communication, e-commerce and the IT department. This step is essential. It allows you to determine the expected requirements that the management platform you select must meet. Find out how to make a success of your PIM.
Take stock of the situation
For software solutions, it is necessary to take the time to analyze the internal procedures and data model before starting to build the new product repository. The goal is to identify time-consuming tasks, weaknesses and recurring actions in the organization from which you can define the expectations to be met in the pim project. This phase allows you to list the production deadlines, the channels to be fed, the flows and formats of data exchanges and the tools used. You must listen to the teams and you must not neglect all the remarks in order to have a broader vision of the areas of improvement and the difficulties encountered on a daily basis.
Define the project scope
You must keep in mind that the PIM is not a CRM or an ERP. Even if the PIM centralizes product information, it must not replace all the tools in the information system. A preliminary analysis of the internal organization is useful in order to precisely identify the interest of different tools and to judge if the use of these tools in the data model supply must also be questioned. Sometimes, it makes more sense to consider the communication flows between the PIM and these tools rather than wanting to enter everything directly into the PIM. Imposing a new tool on a few departments can be counterproductive when they have efficient ways of working with software at their disposal. You need to define the responsibilities of each person in the new model: what is the dependency between the different stakeholders? Who informs what? You need to establish the different workflows for data entry and validation in order to map out the overall organization of the teams in a clear and precise manner.
As for the time to be given to the project: be realistic
Rethinking the product repository of your information system does not mean abandoning existing methods and tools. It is important to take the necessary time to ensure a smooth transition between the new model and the old one. Think, for example, about designing temporary exchange flows between the existing system and the new one in order to allow you to move forward with the construction of a product repository while ensuring the daily tasks. Favour step-by-step operation to avoid the Everest syndrome. It is, in fact, more rewarding and also less stressful to move forward in stages while reaching regular goals than to wait until the end of the project to start reaping the benefits of the system redesign. To do this, apply the principles of Agile methods. You must therefore identify the relevant axes that allow you to split the repository into several iterative batches, for example, while processing product lines or while dividing a repository by the logical grouping of attributes such as technical data and marketing data. Before attacking the parts that are the most complex, start with the data that are simple to process: structuring that already exists in the IS tool, data with no short-term deadlines and little sensitivity, etc. A method that has proven itself is the implementation of the POC or proof of concept phase. The latter generally allows to test the viability of the project on a reduced scale with the pilot team with the partial data set. Thus, before extending a project to the whole perimeter, you will be able to verify the viability of the model and the new procedures. The main advantage of this mode of operation is that it gives you the opportunity to go back or revise the copy in case of difficulties.
Think about the well-being of users
You have to keep in mind that the users will have to be available to implement the project. You have to arrange the working time in order to allow them to appropriate a new tool in a progressive way and to avoid the feeling of a too brutal break with the old working methods. You need to surround yourself with key users who will act as sponsors for the internal teams and facilitate their adhesion to the project. Moreover, it is also easier to respond to the concerns and questions of others when you share the same daily routine. Finally, be aware that the PIM project certainly does not have an end. It is necessary to capitalize on the feedback from users and also your new needs in order to make your structure and your work processes evolve.