Chapter 2: Why MDM Is Needed -- Master Data Silos Issues
Each business application has a different data model, different data attributes and is maintained by a different team using different processes. In this section, learn how to overcome the challenges of SAP NetWeaver master data management by coordinating your SAP NetWeaver MDM program with a master data management strategy.
Effective Master Data Management with SAP NetWeaver MDM, Ch. 2
Table of contents:
Using SAP NetWeaver MDM with CRM, SCM and NetWeaver BI
Designing your SAP NetWeaver master data management strategy
The importance of master data management following mergers and acquisitions
Enterprise MDM: SAP MDM for reducing data silos and duplicate records
2.2 Maintaining Master Data Across the Silos
Earlier we described MDM as a business application sitting between the record of origin and your consuming systems. Linking the record of reference to the record of origin is relatively straightforward. There is a 1:1 relationship with the D&B D-U-N-S Number as the unique key.
Your SAP NetWeaver MDM program will need to persuade each of the consuming systems owners and business users to both change their current processes and cleanse the existing data. They each must be willing to share the common key -- the D&B D-U-N-S Number -- and to follow the new data standards to incorporate SAP NetWeaver MDM into the operational business procedures.
2.2.1 Business Data Varies by Application
The business application, its data model, and its functionality drive the stored customer and vendor data. For example, the Financial Accounting application stores financial data and the important attributes such as bank details and payment terms. The names and address details are typically for legal entities and payer addresses.
A best practice for companies is to establish standard processes and controls both for supplier and customer registration. For vendors, information such as company search by name, identifier, location, company identification and contact information, demographics information, financial information and references, supplier diversity information, insurance, federal tax, and certification information are all relevant.
Following are the key questions that you need to address for your SAP NetWeaver MDM program (we'll consider these design considerations further in Chapter 6):
- Which of these attributes are your global attributes to be shared across all of your business applications?
- Which attributes are best maintained locally in the business applications?
- Will your customer and vendor master data be captured in one request form and then subsequently be keyed or uploaded into the relevant business applications?
2.2.2 Different Teams and Organizations
In Case Study 1, we defined a situation in Company CO1 where the marketing team, the supply chain management team, the customer facing team, and the financial accounting team each acted independently, and company-wide data standards were not established. The quality of data entry was variable and based on the business unit's operational procedures, the individuals involved, and their line management.
Let's not forget that the data conversion team who created the original master data records, the IT division who created applications interfaces, and the mergers and acquisition teams who uploaded a batch of records have all impacted the quality of your master data. These batch processes and interfaces need to be subjected to the same rigor and data standards as your day-to-day operational procedures.
Over time, the people and teams who maintain your master data will change. Individuals move on to new roles and pass on their accountabilities to new team members. In Case Study 1, the handover of the customer and vendor maintenance processes is likely to be a brief one because there is little formal documentation and few operational procedures. There will be a handover process and some limited training, but it is unlikely that the new business users will exactly follow the same processes as their predecessors. Attributes such as search terms may be treated differently, and attributes that are non-mandatory may be omitted. Duplicate records will be created if the new business users do not understand the previous search processes and the historical maintenance procedures. The new users also may not understand the value of the customer and vendor record to the company because the training didn't cover this.
Also, organizational units will change over time. Companies reorganize, and the customer and vendor record maintenance teams may centralize and then decentralize over time. Each time there is an organizational change and new users take over, this can again introduce new business processes for maintaining your master data.
2.2.3 Impacts of Outsourcing
Potentially each of these maintenance processes can be outsourced to an external third-party service provider, which adds yet one more team and one more company into the process. In Case Study 1, the Financial Accounting processes have been outsourced.
There is an old adage that you should "never outsource a problem," and currently there is a problem with the maintenance of master data in Company CO1. The lack of data standards and unclear operational procedures resulted in many duplicate and out-of-date records in the FI1 application before it was handed over to the outsource company to maintain.
Outsourcing a data entry process to an offshore company introduces complexity because the new users won't necessarily know local name and address standards. This issue is particularly relevant for global companies with global systems. Over time, a changing workforce may not fully understand the previous processes and the historical usage of business partner master data attributes. Inconsistent application of customer and vendor record entry over time causes confusion and data quality issues.
The service levels you agree on with your outsourced partner may not include the data quality of your master data records as a key metric. The Service Level Agreement may actually discourage accurate master data with other metrics such as all invoice payments to be made within x days acting as a disincentive. For example, if a customer or vendor request form is inaccurate or incomplete and needs to be returned and queried with the requestor, this will slow down the payment process and jeopardize the SLA. In these cases, incomplete master records may be created so that invoice payments can be made. Future searches of the incomplete data will not match accurately, and the data won't be maintained appropriately and duplicates will be created.
Carrying out rigorous searches of existing data to see if the business partner is already set up takes time and effort. After your business partner master data quality is compromised with incomplete or inaccurate names and address details, the duplicate record setup increases, and searching for existing companies is less likely to be carried out.
These basic search and maintenance issues need to be resolved, which involves people from the outsourced team cleansing and removing duplicate master records. You need to establish change management procedures to mandate the new SAP NetWeaver MDM processes as part of the customer and vendor record creation processes.
Eventually the SAP NetWeaver MDM program's operational processes will become a good candidate for outsourcing. The D&B Entity Matching processes, the SAP NetWeaver MDM Company Search processes, and the maintenance processes are core services that can be externally sourced with appropriate Service Level Agreements.
However, you should leave outsourcing until your SAP NetWeaver MDM solution has scaled and you are close to the end of the SAP NetWeaver MDM Phase 2. A lot of "value add" project work and data discovery with consuming systems needs to be done before you consider "commoditizing" SAP NetWeaver MDM and outsourcing the SAP NetWeaver MDM services as your organization's way forward.
2.2.4 Features of Unlinked Systems
Multiple business applications linked in the way we described in Case Study 1 have the following properties. Vendors and customers are set up several times in various pockets with different parts of your organization performing their business processes in isolation. The business applications data models and business rules vary and are not integrated. Invoices can be paid by creating supplier records in the Financial Accounting system.
Even when companies use an integrated solution such as SAP provides, they sometimes choose to implement only parts of the solution such as the Financial Accounting functions, while preferring to use specialist supply chain applications and CRM applications alongside them. This is the situation described in Case Study 1.
Your purchasing organization is unable to leverage its spend with business partners and cannot scale its transactions to benefit from volume discounts because each organizational unit generates its transactions in unconnected systems. A vendor may understand its sales to a large organization better than the organization itself if its systems are connected and its master data processes are established. This additional knowledge can help the vendor to negotiate a better deal.
Credit management is problematic because the sales organizations do not understand their overall exposure positions. In the case of a failure of a very large business partner, it could take some time to understand the full implications to a company. This is one of the reasons for the Sarbanes-Oxley legislation and the real-time disclosure clause.
Accounting and business intelligence reconciliation takes most of the business analysis effort rather than analyzing the corporate spend and leveraging global positions. Group financial and procurement organizations then trying to make sense of the master data run into difficulties. Instead of focusing on the overall business transactions carried out with a business partner company, considerable internal effort is spent in trying to reconcile inaccurate, incomplete, or out-of date customer and vendor information. This adds little business benefit and provides results that are inconsistent and need to be repeated frequently. We strongly advocate trying to fix the root cause of the problems once using SAP NetWeaver MDM, as opposed to repeatedly providing "quick fix" reconciliation reports. The root cause is to change the underlying business processes for the search, create, update, and deletion of your customer and vendor records in each of your business applications.
Lack of Standards -- Mandating Legal Entities
New rules and standards are often unpopular with those who are impacted. A good example is the "No smoking in a public place" legislation, which has been introduced in an increasing number of countries and cities in recent years. For many years, it was accepted that going out to a restaurant or bar would also include and returning home with smoke fumes on their clothes. Within a few weeks of the legislation taking effect, people became used to the new rule. Now, after getting used to the smoke-free environment, most people find it very noticeable, if not difficult, to acclimate to cities and counties who allow smoking in public places.
The good thing about the "no smoking in a public place" rule is that it's a clear rule to everyone, and the majority can see the benefits. There has been some debate about what constitutes a "public place," but these definitions have been clarified over time. Under this legislation, smoking is prohibited in many public places, including workplaces, commercial premises, educational institutions, and sports venues.
Adopting a new company data standard mandating that "All customers and vendors must be authenticated with a D&B D-U-N-S Number and be maintained with MDM" may initially be unpopular as your organizational units will resist the change management process. However, the majority will soon see the benefits, and after it becomes part of your culture, it will become a standard process to follow. The new standard will remove the "smoke screen" of your current master data silos, and in the future, you will ask the following questions:
- How could you set up a new business partner without a D&B D-U-N-S Number?
- How would you authenticate that a company is who it says it is?
- How could you verify a company's credit status and risk?
- How could you search to see if the customer or vendor is already used in your company without it?
Eventually, the rule will become as obvious as the "no smoking in a public place" rule. The data standard is clear, concise, measurable, and enforceable. You have either tagged a customer or vendor record with a D&B D-U-N-S Number or you haven't — it's true or false. Similarly, your SAP NetWeaver MDM repository either holds the key mapping to the business application record or it doesn't.
Data standards are extremely important to your SAP NetWeaver MDM program. If you can convince your business leaders to adopt this kind of rule early on, then you can dramatically speed up the SAP NetWeaver MDM adoption process. By mandating the new standard, people who were used to behaving in one way now must act differently.
Instead of trying to persuade each individual organizational unit, you will be in a position to mandate compliance with the SAP NetWeaver MDM initiative and put the onus on them. SAP NetWeaver MDM is fundamentally a "people and process" issue -- if you can convince the people, you can drive through the process changes to achieve success more easily.
2.2.5 Maintaining Data Silos — Business Process Issues
Let's now consider the current search, create, update, and delete issues faced when business users in Company CO1 attempt to maintain business partner data across the five systems and see how the new data standard can help the situation.
1. Company Search Processes
Matching business partner names and addresses without a unique key is difficult. You can't easily determine if a business partner record already exists in a system. Company names and addresses are inexact, and comparisons of name and address fields require special algorithms and methods.
Company names may be partially keyed, and business names and trading names can cause confusion. Phonetic matching can help the process, but that requires good algorithms and human checking. Name fields in a business application may have insufficient characters to store a full legal entity name. Company addresses may be incomplete with the street, city, ZIP code, or country missing, invalid, or inaccurate.
Company relationships further complicate the company search process. For vendors, the data entered into the SCM1 application may be for an ordering party, but in the FI1 application, for a payment name and address. For customers, there are several relevant business records to be stored in the CRM1, SD1, and FI1 applications, including sold-to, ship-to, bill-to, and payer names and addresses.
In some applications, related addresses may be stored but not clearly differentiated. The business user requesting or entering the master data details may not know the underlying company structure of the business partner.
However, if the rule "All customers and vendors must be authenticated with a D&B D-U-N-S Number and be maintained with MDM" was mandated by your company, your company search processes would become much more accurate. For example, you will be able to search by Global Ultimate Parents, as well as by individual companies. If a D&B request returns a D-U-N-S Number that you already have in SAP NetWeaver MDM, you can distribute the existing record. The unique D-U-N-S Number means you can avoid creating a duplicate record in your SAP NetWeaver MDM repository and therefore through to your consuming systems.
2. Company Create Processes
As we've already discussed, business partner data created in multiple systems have different business rules for each application, are maintained by different teams, and are captured using several forms. Each team collects the business partner master data using different forms and with varying standards and rules. Capturing business partner master data accurately and consistently at the source is a key requirement for a successful SAP NetWeaver MDM business partner management system.
- With this new rule mandated for Company CO1, SAP EE NetWeaver MDM will play an important role during the business process of converting a prospect into a customer. At the point where your sales team decides they want to do business with a new customer, they will go through a set of new operational business procedures. With a live SAP NetWeaver MDM operational environment in place, the create customer process in the CRM1 application will now include the following new information checks: Have you authenticated who the customer is? Have you matched the customer to the relevant D&B D-U-N-S Number?
- Have you checked where else the customer is being used across the organization? Have you reviewed the D&B Corporate Linkage and the total spend and sales across your organization?
- Is the customer new to your organization? Is it a record that is already set up somewhere else in your organization or even in the CRM1 system already? Have you checked the D&B D-U-N-S Number key mapping in SAP NetWeaver MDM?
- Have you validated that the customer is a company you should be doing business with?
- Have you checked the credit rating of both the customer and its Global Ultimate Company? Have you assessed your current credit exposure across the entire D&B Corporate Linkage?
Similarly, the new create vendor processes in the SCM1 application will now include the following information checks:
- Have you authenticated who the vendor is? Have you matched the vendor to the relevant D&B D-U-N-S Number?
- Have you checked where the vendor is being used across your organization? Have you reviewed the D&B Corporate Linkage and the total spend across your organization?
- Is the vendor new to your organization? Is it a record that is already set up somewhere else in your organization or even in the SCM1 application? Have you checked the D&B D-U-N-S Number key mapping in SAP NetWeaver MDM?
- Have you validated that the vendor is a company you should be doing business with? Does it fit in with your procurement strategy?
- Have you checked the credit worthiness of both the vendor and its Global Ultimate company? Is there a risk of bankruptcy?
3. Lifecycle Management Processes
Lifecycle Management processes need to be invoked when your business partners change and your master data records need to be maintained. Companies are dynamic in regards to changes to names, addresses, and mergers and acquisitions that must be managed. Unless each application — SCM1, FI1, CRM1, SD1, and BI1 — is maintained in a consistent manner, comparisons and reconciliations across the applications will be inaccurate.
Adopting the new rule in Company CO1 will be a significant help in keeping your records up to date. You will establish processes to periodically refresh your customer and vendor records with the very latest D&B Worldbase details, using the D&B services to provide the Lifecycle Management. SAP NetWeaver MDM will then distribute the relevant changes to your consuming systems so that each application is maintained consistently.
4. Deletion Processes
Deletion of old vendor records takes administrative effort with little apparent benefit to the organization. However, this is important, and we should consider why all of the business effort is spent in creating new customers and vendors as opposed to revisiting old records that have been created some years ago but have not been updated.
As we've discussed, your business partners are dynamic organizations. Over time, some previously legitimate companies may become "undesirable" companies that you no longer want to deal with such as if they now become bankrupt. Leaving old inaccurate business partner records in your company's business applications is a risk.
By carrying out a census, you can validate periodically that your master data record details are accurate with your business partners. After you have entity-matched them with D&B, you can then consider emailing them and asking them to validate their details.
You can then store each response on the appropriate record in the SAP NetWeaver MDM repository to confirm that the record has been authenticated both by D&B and your business partner. This will help to resolve any long-term records that were created several years ago and need to be updated.
This could become an ongoing business process that is similar to a government census. If your SAP NetWeaver MDM business case is so compelling and your customers and vendors are so important to your organization, why not ask them every two or three years to verify their master data details?
This is a good audit and compliance process that also provides a good measure of the data quality of your business partner master details. It is a straightforward and low-cost technical process that involves sending emails, repeating the messages in the case of no replies, and storing the responses.
Earlier, we compared your customer and vendor data with your physical fitness. Every couple of years, you may go to your doctor for a health check. Are your customer and vendor records also worthy of such a check periodically?
Another approach to consider is to conduct a "How fit is your customer and vendor master data?" review. You could extract your master data from a consuming system and review when each active record was created, when it was last updated, and when it was last involved in a business transaction.
- How many records were originally loaded as part of the data conversion exercise?
- How many records were interfaced from another business application or were created as part of a mergers and acquisition process?
- How many records have not been updated in the past three years or have not had any invoices in that period?
This is a useful exercise particularly ahead of trying to measure your business performance with customers and vendors. Analyzing only the record counts of vendors and customers can provide you with misleading information, and it's good to understand the underlying state of your company's master data before producing management reports. This information also helps with service level agreement negotiation and to better understand revenue and expenditure reporting.
Let's now consider the types of analysis you as a business leader for Company CO1 want to carry out. For now, continue to assume that the SAP NetWeaver MDM and D&B solution is not yet introduced to Company CO1 and that the data silo issues remain.
2.2.6 Measuring Performance with Business Partners
Your senior business leaders (CEOs and CIOs) want to understand Company CO1's profitability and spend relationships with its leading business partners. They will ask the following questions regarding your customers and vendors:
- Who are my most profitable customers?
- How do I increase my revenue from my existing customers?
- How do I improve my operational efficiency when dealing with a customer?
- What is my credit risk with a customer?
- What is my total spending with a vendor?
- Am I leveraging the scale of our company by understanding the global overview of my dealings with a vendor?
- What is my financial and trading risk information of a vendor?
- Am I trading with a "legitimate" vendor that I have authenticated?
- Do I understand who I am dealing with and their financial health?
- What are my potential strengths (and weaknesses) within the supply chain?
- Do I understand joint ventures?
- Have I implemented purchasing controls?
- Can I track issues such as health and safety status and diversity and inclusion?
To answer each of these questions, you'll need accurate and accessible customer and vendor management information. However, for Company CO1, you know that this data is currently difficult to obtain.
You'll initially need to answer some more basic questions:
- How do I uniquely identify my customers and vendors?
- Is the customer and vendor data accurate, complete, and up-to-date?
- How many vendors and customers does my company have?
- What is the legal entity structure of the customers and vendors I am working with?
Let's now consider how many records are in each system while recognizing that this can provide you with misleading information depending on the underlying state of the business application's data.
Table 2.2 provides the vendor and customer record counts by business application for Company CO1.
|Application||CO1 Applications Name||Vendor Active Records||Transactions in the Past Two Years||Customer Active Records||Transactions in the Past Two Years|
|CRM1||Customer Relationship Management||3000||1200|
|SCM1||Supply Chain Management||4500||1000|
|SD1||Sales and Distribution||2000||1100|
Unfortunately, based on the data available, these basic questions are surprisingly difficult to answer. Each system is updated independently with varying names, addresses, and attributes. Duplicate records and inactive records are stored in each system. The unfortunate truthful answer is "Don't Know" without a lot of research and reconciliation and until duplicates and inactive records have been removed. Potential answers could include the following.