Supplier management is the most complex solution to prepare for from a deployment standpoint. It’s also the most crucial because your suppliers are quite literally the backbone of your SAP Ariba solution. Even more so than with contracts, which we discussed in last week’s article, there are a lot of moving parts when it comes to getting ready to deploy your supplier management solution. It’s critical to make sure the information you’re going to hand to your deployment partner is both current and accurate, or it can cause months-long delays in the deployment process.
Supplier management is the most complex solution to prepare for from a deployment standpoint.
It’s also the most crucial because your suppliers are quite literally the backbone of your SAP Ariba solution.
Even more so than with contracts, which we discussed in the previous article in this series, there are a lot of moving parts when it comes to getting ready to deploy your supplier management solution. It’s critical to make sure the information you’re going to hand to your deployment partner is both current and accurate, or it can cause months-long delays in the deployment process.
This is SAP Ariba’s latest and greatest version of supplier management software. If you have recently purchased SAP Ariba Strategic Sourcing Suite, this is likely the version of supplier management you will be deploying.
You may also be deploying SLP as part of a migration from one of the older versions of SAP Ariba Supplier Information and Performance Management (SIPM). SLP offers your company a unified, up-to-date supplier 360° record, allows suppliers to maintain their own information, and lets you manage suppliers based upon various defined parameters to give you visibility and control over your supplier onboarding process.
The qualification and preferred supplier capabilities also interface with Sourcing and Guided Buying solutions to help drive spend to your desired suppliers and is managed through SLP.
As we’ve already noted, a lot of work is required to collect your suppliers’ pertinent data to properly put them into the system. Therefore, it’s important to do a deep dive into your current list of suppliers to weed out duplicate suppliers and suppliers you have not done business with for a long time.
A company may have 50 or 100 thousand suppliers, but most companies aren’t doing business with all of them. When you’re moving to Ariba Supplier Management you should start by targeting the main suppliers you are planning to do business with in the future.
Any supplier you decide to move into the SLP system will need to be contacted for some basic, yet vital, information. For example, the system requires the supplier’s current email address so they can manage their own supplier data in the system. This is tedious work. It’s a waste of time to contact suppliers you have not used in a long time, do not plan on using any longer, or that require you to duplicate your efforts because one major supplier is in the system many times. Additionally, suppliers you have not done business with recently may not meet your current supplier requirements.
A better, more efficient approach is to target the suppliers you do most of your spend with, whether that’s the top 80 percent, or some other reasonable cut off. If you have 75,000 suppliers but your top 80 percent of spend is with 25,000, it will take a lot less time and effort to migrate those 25,000 suppliers during the project. The rest can be added as needed to conform with your new supplier onboarding process through SLP.
SLP offers the option to integrate with SAP ECC, SAP S/4HANA, or other non-SAP ERP systems. If you decide to pursue integration between SLP and an ERP system, there are additional requirements to keep in mind. The more complex integration structure of the SAP ERP’s is with SAP ECC, which is why this is the focus of this article.
When you are integrating with SAP ECC, there is an absolute requirement for some version of Master Data Governance, or MDG. MDG enables the integration connection between SAP Ariba and SAP ECC.
There are two types of MDG; MDG-Foundation, which is free, and MDG-S, which is paid. If you are deploying an integration with a single SAP ECC system, you have the option to use MDG-Foundation; however, if you are deploying to more than one SAP ECC system you are required to use MDG-S.
MDG-Foundation is essentially a stack on top of ECC. It’s a very simple tool that requires almost no effort to implement. When you turn it on, it enables the integration tools via Cloud Integration Gateway (CIG). MDG-Foundation does not offer any capabilities for workflow management or any type of validations and is essentially only pass-through for information.
MDG-S is a much more robust tool that can help with data cleansing, validations and identifying duplicate suppliers. It’s a middleware tool, but it also acts, in a lot of ways, as its own ERP system. The level of effort to implement can be very simple, like MDG-Foundation, if you choose not to use workflow, external validations, or integrations, or it can be as complex as you want to make it.
If you have very complex requirements around your suppliers and require robust validations, duplicate checks, or integrations with external systems such as tax software, these can be accomplished with the MDG-S tool but are not supported with SLP. Additionally, partner functions, such as extensions, blocks, payment blocks, company code blocks, etc., are not currently supported with SLP, but may be accomplished within the MDG-S framework.
However, MDG-S can be costly, and the cost is based upon how many data records you have managed. Again, this goes to the benefits of supplier cleanup and data cleansing: 25,000 valid suppliers will cost a lot less than 75,000 suppliers, some of whom may not be currently transacting with your organization.
One of the other incredibly important things to keep in mind is if you’re currently using SAP ECC you must migrate all your vendors to business partners. It’s a tedious, almost clerical process, but it must be done prior to deployment.
If your consulting team shows up to your deployment on day one and realizes that there are thousands upon thousands of data records that must be migrated to the business partner model from the old ‘vendor’ data model, this can immediately set back your deployment by months before you even start evaluating your other system requirements.
With SLP, unlike with other solutions, there isn’t a standard, out-of-the-box practice around supplier information – the templates are essentially blank slates.
This means you’ll need to be flexible in migrating your data because SLP cloud solutions have limitations on what they can and cannot do – you can’t just retrofit your current system into SLP.
It’s also important to determine the specific data you want to collect from your suppliers and collect only the data that you absolutely require. You may have a system in place that’s evolved over the years where you’re capturing a ton of supplier information, and in some cases, you may not even know why you’re doing so.
These days, with new GDPR regulations and various data privacy and information regulations, it’s particularly important to understand why you collect the data you do. You want every piece of data you collect to have a valid business reason.
Here are some questions we suggest you ask when setting your data requirements:
If a piece of data does not meet these requirements, you shouldn’t be capturing it in your system unless you have a very compelling requirement for collection (such as potential reporting requirements). These guidelines not only help to save time, but they also are intended protect you and you clients in the case of a situation such as a data breach, as well as making your entire process more standardized and consistent.
Following these criteria also helps align clients with what data is truly necessary because a function of SLP is driving suppliers to maintain their own information. If you have a questionnaire with 200 questions on it, suppliers aren’t going to fill it out, or they might just put in junk data because they’re tired of answering questions.
Last, but not least, SLP has the option of leveraging qualified and preferred suppliers and there are separate templates for this. However, there are no standard qualification questions, nor is there a true ‘best practice’ around creating qualified or preferred suppliers. If you’re going to leverage the qualified and preferred suppliers, you need to start thinking about what your criteria are for these qualifications and for the ability to mark a supplier as preferred.
The reason it’s best to do this pre-deployment is because your consultants have some limitations on the decision as to what makes a supplier preferred for your organization. It’s possible that they can come in during the discovery phase of the project to provide support and to help you navigate what works best for you, but the ultimate decision rests on your knowledge of your specific needs.
The length of this post is a testament to how important the pre-work is in preparing to deploy your supplier management solution. But trust us because we know from years of experience that following the steps we outline here will keep you from experiencing frustrating and potentially costly delays in your deployment process.
Did you find this article helpful? If so, check out the rest of the articles in our Pre-Deployment readiness series. If you’ve already deployed, but are struggling to make your Ariba Solution work as you thought it would, our series on Post-Deployment Success has some tips that will help.