On-Demand Webinar: Successfully Integrating PIM/MDM Systems - From Pre-Project to Go-live with diva-e

Annabella Pscherer: Welcome to today's diva-e webinar, Successfully integrating PIM/MDM systems from pre-project to go-live with diva-e. Today, experts give us an insight into the structured introduction of product information management and show success factors and the project execution. My name is Annabella Pscherer, and I am part of the diva-e-marketing team and your moderator for today's webinar. I would also like to take this opportunity to welcome our speakers, Markus Kettler and Matthias Schnick from diva-e. It's great to have you with us today and provide us with exciting input. I would now like to hand it over to you, our experts, and wish you all much fun and exciting insights during the webinar. So, Markus, I will give you the broadcast rights now.

Markus Kettler: Super. So, right. Yes, also from my side, again, a warm hello to our webinar today, successfully integrating PIM or MDM systems. Today we want to give you an insight into how, yes, projects run with diva-e, how the individual steps can be subdivided and what you might have to pay attention to. So, let's have a quick look at the agenda: We now have about one hour left. We'll start with a bit of round of introductions, tell you who Matthias and I are, and also repeat a bit of diva-e. Then we'll quickly go into what PIM is, what MDM is, just to get everyone up to speed. But then we'll also jump right in and see the following three points here: Pre-project, proof of concept, and leading project. This is really about how PIM integration and evaluation work. And after that, we should still have time for the questions. So, I would now like to start the round of introductions and hand over the floor to you, Matthias.

Matthias Schnick: Yes, thank you very much, Markus. And then also from me again hello to the round. My name is Matthias Schnick. I am a Senior Consultant at diva-e; I started with e-commerce more than 20 years ago with a more extensive software manufacturer. I also worked there as a consultant, and then I came to shop management at some point. I did that for many years. And there, I again noticed what problems shop operators have with product data. So primarily when you deal with online shops and other channels, it depends on the fact that you have targeted group-oriented product information. And there were always significant gaps with the individual shop operators, which ultimately led me to deal with product information management a bit more. Now I do it with outstanding commitment and believe it will be inevitable for every shop. That's it from me. Markus, if you want to say something about yourself now.

Markus Kettler: With pleasure. But gladly, exactly, that's me here. Exactly, I've been with diva-e since, yes, October as, yes, a dedicated PIM consultant with about ten years of experience in e-commerce. That also means, yes, running online shops, of course, and then just with, yes, about a bit over three years of experience with PIM integration, especially dealing with technology manufacturers and retailers. That is, primarily where many articles and a lot of product information must be handled, many channels must be played. That's where I gained my first experience, exactly, and now I'm also working at diva-e as a PIM consultant.

So, the focus is clearly on the optimization of product data flows. That is, where the data comes from, where it has to go, and what happens in the preparation. And even if the topic of PIM and MDM is exciting, you should always keep in mind that the PIM itself is not an end in itself. Still, we must always look at the goal, where is -, yes, where are the hurdles in our company, where is there something to improve, and how can the PIM help. Exactly, that is the approach I would take. So, now we are missing a third member, diva-e itself. As diva-e, we are not a pure focus on only PIM, we have MDM, but as you can see here, we are very broadly positioned with about eight hundred employees. At eight locations in Germany, we are active in everything that concerns digital transformation and the support of companies in digital transformation. So we help with strategic consulting, you can also see here in Planning and Innovation at the top left. On the top right, we have the Platform and Experiences part, where Matthias and I are more or less at home implementing PIM systems for companies, where the shop systems are also integrated and so on. We have a high, yes, upscale SEO specialization, data intelligence, as you can see here. We have so the complete picture of digitization or the wide range of tasks of digitization that we map here, yes, so that you get such a view of the diva-.e again. Now we come to the topic.

Just quickly to get everyone back on the same page, we have a customer lifecycle that has changed a lot over the last few years. You see a traditional customer life cycle or customer cycle from the left side here. You get interested in a product. Your search for it, you find it in one place, you buy it, and then you usually go into a, yeah, a routine. In other words, I've purchased from a retailer and been reasonably satisfied. I bought from them again and again. And on the other hand, you see the digital customer cycle, as it is nowadays, where the customer is simply on the move on many more channels, many more touchpoints to play with. Customers no longer just buy at one location, not just in a store, but get information online, maybe read some reviews on sales platforms, watch YouTube videos if they are very interested customers and then form their picture and then also look for the, yes, simply the best place to buy the products. That means that the demand for product information increases when you have to provide all these games, all these channels with specially tailored information. So, and for that, that's where the topic of PIM comes into play. Yes, you can see that quite well here, especially if you look at the arrow here, the grey one. On the left side, there is everything where you get the data, the product information from the ERP system, from upstream suppliers. We have media and product information in the most diverse formats, which all have to be collected everywhere. Then they come here in this, in the blue circle, where the data is enriched, the PIM system. That means that here the products go through approval processes with, yes, with quality assurance, channel-specific requirements play a role there, that we just, yes, also enter translations here and, yes, classify the data, if necessary, and then derive it for the individual channels accordingly. You can see that on the right-hand side. That means we have different content, very optimized for e-commerce, mobile apps. Of course, print still plays a role, but the product information can have a completely different character. And all of that is then placed as well. That's what we see here. We have other sales channels, so the point of sales, where we have some kind of display, a print or digital display, where we play, yes, digital marketplaces. Social shopping is a topic, and newsletters also, for example, with the data supply. This shows again what a wide range a PIM system has to offer and where it can help. So, we have broken down the advantages a bit more here. I don't want to read out all the points now. Still, it's simply a matter of exploiting more potential by keeping the data in appropriate quality and supplying more channels and more customers with the data they need more quickly. On the one hand, we get a higher revenue potential, and on the other hand, we also get an opportunity to reduce costs. That is, yes, somewhere, yes, to reduce duplicate product data processing, incorrectly distributed product information sometimes or also lead to returns, which we can reduce with that. If we have correct information on our products, the buyer also buys what he expects and does not return the product. Exactly, we've put together a little bit, here again, so increase in success, higher reach, less cost and effort and just through the greater abundance of information that we can play into every channel, just optimal product presentation. So, with that, we just wanted to get everyone back on the same page on the topic of PIM. And now I would like to continue with the agenda, now we come to the actual big issue today, which are the following three points.

Of course, when you talk about a PIM integration, you see, on the one hand, of course, the actual implementation of your system in the company, the introduction, but there is much more that plays a significant role beforehand. So we have to know the requirements before we can make a selection. We have to get to know the customer, which usually happens in the preliminary project. Yes, and that's where I would start now, and Matthias will then provide the insight later in the main project. So, exactly, let's move on to the preliminary project.

So, when you, yes, deal with the topic of PIM as a company, then, first of all, an Internet search is started. We look to see what providers there are on the market. Are there perhaps already any indications as to which one should choose. You can see here very well that you are quickly spoilt for choice with many providers and other systems on the market. Here are just a few. The three dots on the right side appear twice to show again that there are many more players who, yes, are trying to get in on the action. And of course, it plays a significant role to know what you need and where you can find the right partner from the beginning. Then maybe you will go here. Perhaps many have already seen that, so Magic has various evaluation criteria, where the systems are also tried to be sorted. Sometimes they contradict each other, and there is not a detailed picture. So you always have to weigh up many things, which doesn't help that quickly. So that's where the, yes, our preliminary project on the subject of PIM comes into play. That is, we have simply sketched out the process. We merely start on the left side with the needs analysis. We look at where the goals and requirements are, create a long list, a long list of systems to choose from, come to a shortlist, and make a well-founded system selection. I would like to try and look at this in detail, so what is essential and the contents of the individual steps. Namely, in the needs analysis, what does it consist of? So it's about, yeah, trying to get to know the customer as best as possible. What are the yeah, general goals of this company launch? Yeah, so what is the strategic purpose behind dealing with the company launch? What are the technical goals or requirements, are you allowed to introduce cloud systems here.

Yes, there are unique systems that have to be connected in the company, i.e. PLM systems, specific ERP systems, which may also lead to hurdles and are there, yes, clear business goals. Business goals can be described as follows: the business user is the user who will work with the system later on. What functions does he need, that is, what parts does he need in the program interface, but what functions does the system have to provide under the hood so that these employees can do their work well. This also includes interfaces, how can I place my data on marketplaces. Are there interfaces, yes, for example to Amazon, any, yes, also market-specific purchasing platforms, sales platforms, Mercateo, for instance? So what to look for there, where are the, yes, where is the core of the requirement. That also means, and we also look at where the most significant potential for optimization lies, yes, so what do the processes of data collection, refinement and then distribution look like at the moment. And are there already bottlenecks that we can identify, where we can directly say through the introduction of a PIM system that we can relieve the employees, that same work is reduced and that we simply do not have to supply the channels twice with data—the processes and panels where data is needed play a role in working with the system, yes. So, employees play a role and have to be involved from the beginning and give their input to make the right choice. And then, last but not least, I have noted here, we are now jumping a lot on the subject of PIM, so the preparation of product information, but there you should also, yes, go in a bit carefully or look with an, yes, with an extra eye on it, whether there are other areas besides the product information that play a role here. Yes, for example, we have contacts that are maintained here, i.e. company contacts, customer contacts, supplier information that can be stored or, yes, locations. That means, if I store information about my shops, yes, something like shop size, shelf size, that is, which products do I have, can I place at all in my shop, perhaps, how many of which products, which selection is to be made there and which assortment can I accommodate.

In this area, we come to what we also see in the last point, which is the topic of MDM. This means that we move from product information management to master data management, where we take a broader look at data handling, which also plays a role in selecting systems. Some systems are robust in the PIM area, focusing on the need for high data quality and the workflows that play a role in data preparation. And some systems cover the other areas as well. So we have now created a requirements profile, a first one. I'm going back a step here. As a rule, we work with different tools. Here you can see an Excel table as a questionnaire, where we usually divide it into three parts. We have, yes, the general requirements, general aspects for a PIM selection, technology and infrastructure and just the business features, which I have just mentioned. And this is worked out with the customer, the corresponding questions are formulated, requirements for systems are formulated, and then we go into a long list, yes. So we make or recommend a pre-selection. As a rule, we have about six to eight systems that we can simply sort out from the outside and our experience, yes, in this direction. And then, we go to this long list of systems and question them based on an investigative questionnaire, for example, where we provide these fundamental requirements and then go through this questionnaire with the company. Or we receive the answers and then go back, yes, into the queries, further discussions with the providers, to clarify any questions, so that we then really have a, yes, a constant comparison. An initial basis on which we can then, of course, present this result once, and then-, and then make a suitable shortlist recommendation, yes. That means that from these three systems, from these six systems, I have already revealed it, if necessary, three systems, yes. So that means we then have a shortlist. We have an average of between two and four systems, which are then looked at in detail based on their answers to the questionnaire. Then it's a matter of providing the system with, yes, elementary test data sets. We then develop use cases with the customer, usually two to four. So usually, three use cases are then discussed. Employees want to play data in and out of the channels, supply marketplaces, and, if necessary, simply want to merge and optimize a lot of supplier information or information from different suppliers quickly in the system. So then the use cases are defined, which can then really be given to the shortlisted candidate. A live demonstration is then agreed upon. We can see how the system behaves in practice and adheres to what was promised in the survey. So, based on this, we can then apply a scorecard that has, of course, been agreed with the customer. That means, which use case is here, where can one perhaps make cutbacks, where should he in no case go back then also somehow a step and which system offers then just directly from the beginning quasi also the best-added value and which has then also a greatest expansion potential. With this recommendation, we come back to our procedure here. We first checked the requirements, creating a longlist, then came to this shortlist, and are now really in a position to make a system selection. As a rule, we come out with one system. It can also be that we then proceed with two systems, and here again, you can also see here with the next steps, do not start directly into the main project, but perhaps first make a proof of concept, yes. In this case, especially with large projects requiring much integration and many connected systems, we have many workflows and many employees who also handle the data. Then it is advisable to introduce this intermediate step, yes, where we then really look at this whole, yes, a theory that we have now worked out and what we have also, yes, exemplarily seen in practice, in the live demonstration, is it all correct, yes. That means we are working again based on selected use cases, and workflows are built up with the system. Still, everything in one, not yet in the framework of the main project, but in a somewhat, yes, more compact framework, where you concentrate on the essentials and it but also with real information and the real employees can go through it once. That means that we have a comprehensive evaluation at the end by, that is here below in the quotation marks, by such, yes, such a real-life insight actually and just the direct feedback of the employees who can simply say again, yes, I can imagine that for after the integration. Or we might just have to take another step back and look at one of the other candidates. Exactly. And once that's done, and we've decided on a system, we move on to the main project. And at this point, I would like to hand it over to my colleague. Matthias, are you ready?

Matthias Schnick: Yes, thank you, Markus, and now you also needed the time. But I think that also shows how important this preliminary project is to move forward in the main project a bit, yes, in a more targeted way. And the main project, that is, we, yes, now assume that the preliminary project has been completed. We have ideally still done a proof of concept, and now we can start doing the real work for the customer in the system. And on the next slide, Markus, if you would be so kind, exactly, we have more or less listed three phases that this main project includes. On the one hand, there is the scoping. In individual workshops, we determine exactly which requirements are necessary. Then we come to integration. This is where everything that we have evaluated, worked out and recorded is finally integrated into the system. And then we go live. And then we don't leave the customer alone after that, but there is a hyper care phase where we accompany the project for a while and are available at any time as a contact partner for questions or perhaps for one or two adjustments. In the scoping phase, thank you very much. That's where it goes, so we usually do all that in workshops and then we also find out one or the other contact person, who we then maybe ask again separately. But first, we clearly define the scope of the project. What are the goals, what are the requirements, what are the tasks, what are the people, who are the stakeholders and what should be the final result? Based on our experience, we then create a timeline with milestones that we define together. So we say that we want to have this part finished in three months and that part at the end. And it can sometimes change a little bit so that maybe one or the other milestone is postponed in the course of the project because additional work is not yet available or because priorities have perhaps shifted again. But we do have a timeline that we stick to, that is transparent, that everyone knows. And with that, the system is more or less set to go live. In the next workshop, we'll take another close look at the existing data. We will go into more detail than we did in the preliminary project. We'll take another look at what requirements are placed on the data and how it is structured, i.e. where the product data is structured. And when it comes to MDM, we also look at the data requirements that are not product-specific. We then develop a data model and develop attributes, variants, and references, i.e., links between products and images. We also take another look at which categorizations or perhaps even classifications are necessary, what role the inheritance of attributes plays within the product structure. Then, in the end, we have a model with which we can map all data in the system. And the next point, which is defined here with rights and roles, is also critical. And this is really about who ultimately works in the PIM system. And it turned out that it makes much sense to conduct individual interviews with people who work directly with the product data and who will also work with it, later on, to find out the needs of the individual people. These can also be very different. And we then collect this information in these interviews, transcribe it, put it in writing and develop a management system for the rights and roles. And that's not directly mentioned here, all these workflows that are necessary from creating a product in, I'm talking about a product or a data set, in a system, to then transfer it to another system. All of that relates to this workshop that deals with rights and roles. And in the end, and it's still such an important point, we take another close look at where the data actually comes from, which interfaces do we need, do we still need development support in any way, and where should the data ultimately be go. So which channels, as Markus showed so well at the beginning, that there are an incredible number of channels into which product data or other data can be played out. And of course, these often need a different interface or also need different processing of the data. We take all of this into account in the data model so that there is exactly the right data set for each output channel. Well, we have now completed scoping and are moving on to integration. All we have worked out in the workshops, we are now implementing in the PIM system. in the MDM system. We build a structure for this data model, which has been very abstract, is now being implemented in the system. Variants are always a big issue, how they can be mapped and which attributes can be inherited from which level in the context, that the effort of product maintenance can be minimized, that we simply always take over certain things. So classic examples are really in sizes and colours, but something like materials, they can always be taken over from the main, from the main level. You then only maintain the colour and the size of the respective product. Then the interfaces are also implemented, so the inbound and outbound management is looked at, and we implement everything we need for that. And then, there is the first import of inventory data to test whether everything works as it should. The data then comes in, and we see whether we can process it, whether it all works. And, of course, it all works. And then it's a matter of implementing the rights and roles that we've worked out, so to speak, really giving individual employees certain rights. This also goes far beyond read and write rights. It is also about the fact that products have to be released, that they have to be translated, that external agencies have to be connected. These can not only be translation agencies. They are also often photographers or copywriters. And then everything that we have worked out should be ready. And now it's really about testing everything. So we'll test the imports, we'll let the users test the things, and then we'll get feedback, make some minor adjustments if necessary and then if everything is okay, we'll do some user training, not just with users but with everyone who deals with the system. And then the system can go live. And in the hyper care phase that follows, after the system goes live, we will continue to support the use of the system. Sometimes you have to catch some users a little bit and maybe get them enthusiastic about the system because sometimes a process has crept in that works well for everyone but is not very effective. And now it's a change that looks a little less attractive at first glance, but in the end, it does make things a lot easier for the individual employees. And sometimes you still have to do a little convincing, but it always works, without exception. We then also ask what, yes, what else you would like to see. Where can we do something more and possibly develop a new project from that, or new ideas have often arisen within a PIM project about how things can continue. And then, we look at all that in this Hyper care phase. So, Markus, I have now made this short.

Markus Kettler: Well, we have attached here an example of, yes, project planning so that you can get a little insight into it. That is, we try right from the start to simply define things in the plan as, yes, as well as possible, so that we, you can see here quite well that here also then during the creation of catalogue structures, here so in the yellow area you can see that this bold print alternates a bit with the non-bold photo. That means that we also have an interactive procedure. We go into the individual workshops, we always have consultations with the customer, with the relevant departments, with the relevant employees responsible for certain things. We also have, for example, if it is now, at some point, a matter of playing with the data in our shop, then we always go into conversation with the shop team and then also check whether we have all, all attributes, all characteristics that are necessary for the shop. And then it's just such an interactive structure that we gradually enrich the system with the information by working through everything in the form of milestones and then slow going live, but also approaching it and where it can then just go. Exactly. We have brought again as an example of such a project timeline. That means, of course, it always depends on the scope of each project, and the schedule will be adjusted accordingly. But we have broken down here again partly from the PIM project, which we then just here to give again a picture that we have then learned after the actual scoping and the concept phase, how the company, yes, how the company works. Which things have to be adapted, and then it goes into the design and then accordingly into the implementation. Here in this purple area, you can see that this sprint icon, which is supposed to represent again that these steps are repeated, again and again, so to speak, yes. We design processes and implement the design again attributes for other areas, which is then implemented little by little.

Matthias Schnick: Exactly, so we also work in PIM projects in agile, in sprints, as most diva-e projects do. And it's, yes, it's, as Markus said, just an example of that, because it, well, at least as far as a duration or a schedule is concerned, that always has a lot to do with what this needs analysis ultimately shows.

Markus Kettler: Exactly, yes. And when we have implemented the individual points for the previously, yes, determined outcome, that is, we have our, yes, PIM product, which is then ready for going live, then, of course, it goes into the testing, QA phase, around the documentation, what we have also just seen informatively on the extensive timeline and then it can just really go to the launch and the rollout, exactly. That was it to show the schedule again a little bit, yes, how that can be so exemplary. So, we'll go straight into the Q&A session from this slide. So thank you very much, and I'm looking forward to your questions.

Matthias Schnick: Yes, we are pleased.