How to create SKUs? (What’s the best way?) – ERP vs. PIM
There comes a moment in every technology rollout when the biggest decision has been made. In the context of opting to implement a PIM, or Product Information Management solution, it’s often when the commercial case for having the capability to collate, manage, and enrich product information in one central repository has been proven.
As we explore in our blog on how a PIM system helps drive digital sales, this commercial case typically rests on the way a PIM helps brands and retailers to:
- Simplify processes and streamline tasks
- Improve data quality
- Create a single source of truth for products
- Get to market faster across multiple channels
- Craft more personalized shopping experiences
These are powerful reasons for investment, but once the decision to implement a PIM has been made, another set of questions around implementation comes into focus. These are often detailed and complex, yet often revolve around the following two questions:
- How will the PIM work with an existing technology stack, for example, a company’s enterprise resource planning (ERP) system?
- How will implementing a PIM impact the way the business deals with its data on a day-to-day basis?
One way to answer these questions is to focus in on the creation of stock keeping units (SKUs)1
Should companies create SKUs within an existing ERP system or within a PIM?
This is a question that many retailers and brands ask early on when buying a PIM. It’s easy to see why. Lose track of SKUs and a task as simple as restocking a store or warehouse quickly becomes unmanageable. Businesses without a PIM typically create these SKUs within the ERP, so they want to know early if processes need to change.
The first thing to recognize here is that a PIM is typically a flexible system that can ‘talk’ with the ERP, so there’s no pressing need to change this. However, this is a task-orientated way to look at the issues. Another arguably more fruitful approach stems from asking a different question: what kinds of data will reside in the ERP and PIM?
Typically, it makes sense for the ERP to be ‘in charge’ of an item number for a product or service, price, and data surrounding stock numbers and shipping times. Why change this if it works? The question of where to create a SKU is actually secondary, good news for companies where it’s straightforward to create a SKU within an existing ERP.
But what if it’s not easy to create a SKU within the ERP?
Here’s where the flexibility of a PIM comes into play. Take the example of a retailer receiving product data from multiple companies. This data will likely be arriving in multiple formats – Excel files, CSV files, and XML files – yet ERP systems were traditionally designed to handle structured operational data, not to onboard data from a multitude of diverse sources. Rendering them less efficient for these kinds of tasks.
In this case, it may make more sense to import the information into the PIM first, especially if a supplier is offering data on its full range, including products the retailer is never going to stock. Here, it may be better to select the relevant products and create the SKUs within the PIM rather than clutter up the ERP with unwanted data. The SKUs can then be pushed to the ERP to deal with, for example, item numbering and pricing. In this scenario, there’s a back-and-forth exchange of information between the two systems.
Turning to suppliers or manufacturers, not all of the products they design will get to market. Take the example of a fashion company that has been working on a new range of t-shirts. At a trade fair, it becomes clear that only half of the designs will perform well in the market.
Rather than creating SKUs within an ERP for products that will never be offered to the public, it makes more sense to work in the PIM initially, and to only export products to the ERP when they are close to being launched and sold.
In each of these cases, the eventual decision will depend on the best workflow. The underlying point is that using PIM in conjunction with an ERP system gives the retailer or brand more flexibility to choose the most efficient way to handle their data.
Can pricing be managed within a PIM?
A way to illustrate just how flexible a PIM can be is to focus on pricing. As we have already noted, most businesses will hold price data within the ERP. It can then be exported to the PIM on a read-only basis. However, there may be instances when it is simpler to do this within the PIM.
Last year, the German government cut VAT from 19% to 16%. For many companies, this was unexpectedly difficult to deal with because it meant they needed to change the price on every individual SKU within the ERP. This led to companies instead opting to deduct 3% at the checkout.
Often, this kind of scenario is easier to manage within a PIM, where deducting the 3% can easily be automated. This approach can also be applied to discounts or to items that are being sold by weight or volume. Here the ERP might be managing the final sales price per unit, but offer no way of calculating a base price per kilogram or liter, a crucial piece of information when it comes to marketing your products.
In short, all and any of the above ways of creating SKUs are workable and can even freely be combined for a hybrid approach. The choice, in the end, is going to depend on how the PIM is integrated into a company’s existing IT landscape and what their requirements are. But there is one piece of advice that underpins everything we have said here: data needs to be able to move from one system to another and back again, and to integrate data from other systems, rather than just travel in one direction.
This may sound simple, but the creation of efficient workflows rests on this idea. Take the idea of connecting to an online shop or marketplace. It may make sense to let the PIM take care of such syndication processes, automating them as much as possible.
But what if the business needs to show different prices to different customers? What if different product data needs to be fed to different channels? One approach is to have the PIM handle the communication with third-party software, the syndication, and to trigger a command to the ERP to provide the pricing information, integrating these two distinct data streams.
Again, there’s no one ‘correct’ way to integrate a PIM into an existing technology stack. Equally, there’s no one ‘correct’ way to handle data or processes such as the creation of SKUs. The power of a PIM lies in its flexibility and in the way it can augment your existing systems and improve workflows in all of the business scenarios we’ve outlined in this blog post. And many more we haven’t mentioned.