The 5 Data Differences – Supplier Information Management (SIM) or a Wanabee?
What is Supplier Information Management (SIM)?
Supplier Information Management is the evolution of Supplier Master Data Management (MDM) which takes the arcane approach to MDM and brings it into real life by embedding it within real business processes which connect stakeholders across all these functions together. In the same way as Product Master Data Management evolved into Product Information Management (PIM).
Below are the five data differences which you should use as a litmus test for your next SIM module or solution.
- Data Model
- Data Consolidation
- Data Flow
- Data Governance
- Data Staging
If it doesn’t pass any of these tests it’s not SIM it’s a wanabee and you will have problems down the road once you have spent $100Ks or $1Ms.
Data Model
The data model of a Supplier Information Management software solution must be very flexible in order to provide an efficient way for internal users and suppliers to work with. Most data models in ERP and P2P solutions are very rigid or limited.
For example, SAP has a flat view, essentially a supplier actually in SAP is just an address and you can inter-link these address with partner functions to tell SAP where to order from, pay an invoice or who the manufacturer is.
In Oracle and PeopleSoft, you have two levels to link addresses together to a single tax ID – however in our experience no one uses it correctly and records tend to be created at will.
These different variations can sometimes be very complicated. In our experience, we see the need for three levels, but every customer is different therefore they can choose if they want one or two or three levels deep.
The key thing is that your SIM solution lets you flexibly define your data model and how things interlink.
It needs to be able to support consolidation from multiple disparate systems, into a single view and flexibly accommodate 100% of all the attributes from all those systems for 100% of your suppliers.
What this means in practice is if you have five different ERP systems there should be one supplier in your SIM solution with five relationships (these relationships could break down further into company codes, purchasing organizations or operating units – depending on your ERP) holding all of the data attributes.
This element is very often under played by non-SIM solutions who don’t provide true master data management functionality and have no tooling available to help you bring your data together using match and merge workflows.
Data consolidation is one of the main risks and key success factors of any project which tries to centralize data or information management from multiple sources into a single source. Don’t be fooled if anyone tells you this is simple, it’s not.
Numerous P2P implementations get delayed or cancelled because when it comes to loading the data it quickly becomes a mess.
Data Flow
Creation and maintenance of supplier [data] needs to start in the SIM solution. This will ensure that you don’t duplicate efforts and you will drive good data quality. This will then be fed into transactional systems normally in sequence ERP and into P2P (buying system) so users can create shopping carts and workflow to generate purchase orders.
There is a reason for the data flow and why you see P2P or supplier network solutions normally receive data from the ERP first. It’s because they need a transactional supplier record so it can reconcile purchase orders and invoices back to the ERP. If they didn’t to do this then interfaces for purchase orders and invoices would start to fail.
This approach is unsuitable for centralized supplier information or master data management because you only want to be working on a single record and the system should be taking care of keeping the other records and information in sync. You don’t want three records in your centralized solution.
If you read the fine print of most P2P suites they will mention that even though you could create and update suppliers in the P2P system first, this is normally disabled by customer choice. The truth is that it’s not by customer choice but because of system limitations.
At the end of this piece we have an example which will make this point very clear.
Data Governance
Every single change to data should be governed. This means that there is a workflow process so when a change happens it will go through various automated and manual approvals.
Also, there needs to be clear differentiation between global (common) data and local data. A good example of this is the tax ID and name are global data, so they should be common for everyone, but payment terms is considered local data because different organizations may have different terms with the same supplier.
Data governance has to be fine-grained in order to be efficient therefore you can have a different type of data change request for a manufacturing location, remit-to location, ordering location, bank account, legal entity, etc.
These examples all have key differences between them and normally go to different stakeholder groups.
Also, you need to answer key questions like if a supplier changes their Tax ID is this still the same supplier? There are special circumstances and actions to take in such situations.
You should be able to easily add your own data governance workflows in the system and extend any out of the box functionality because data governance is very specific to how an organization is structured and its particular industry.
Data Staging
In order to not garbage up your data you need to have your solution ‘stage’ it. What this means is that if a supplier or internal user makes a change it shouldn’t be applied immediately. Changes will only be visible to users and sent to downstream and upstream systems only once they have been validated through the appropriate data governance channels.
This also helps avoid duplicates by ensuring that records are only created after the right checks have been done to verify that in fact this new record doesn’t exist somewhere else within the organization.
Confused? An Example will help.
So finally, a practical example to explain how this works in the real world and a litmus test to see if you have a true SIM solution or a wanabee.
Picture this scenario:
You have three different ERP systems (this example works with a single instance as well but easier to explain with multiple ERP instances) – one for Division A, Division B and Division C. All of the divisions are using ACME Tools Ltd. so you have 3 records, one in each ERP system.
You have loaded these records into your P2P tool and you have 3 records of the same supplier in your P2P tool.
Problem, problems, problems:
A user in Division A decides to change the data of ACME Tools Ltd
- Will it only change it for their record in their ERP? Will this data no longer match with the other two records?
- Will it change it for all three records? If the answer is yes then who will approve this change? Is it all three Divisions just the one Division? What if the other Divisions don’t want their data to change?
The above example illustrates the need for all the five Data’s Differentiators of SIM in order to successfully centralize supplier data and information management:
- You need to have the right data model to provide a single view across multiple locations and addresses
- You need to always maintain data in a single central place and then feed transactional systems – it’s the most efficient and cheapest form of data and system maintenance.
- You need to have data governance – both central and local so when you are working a central environment it’s clear who can do what. This is the essence of Data Stewardship.
- You need to stage the data, to not create confusion when a change is initiated and ensure the correct approvals are in place.
Does your SIM solution cover the five data differentiators?
