MDM software proof of concept: how to test with your own master data

An MDM software proof of concept is only worth it if it runs on your own master data, is operated by your team, and is measured against scenarios you wrote before seeing the tool. Pick a sample with real problems, protect personal data, define the expected result of each scenario, and score with weights and saved evidence. Whatever passes the POC becomes an acceptance criterion in the contract.

I have seen proofs of concept turn into rehearsed demos. The vendor arrives with its own database, every material has a flawless description, every supplier passes every check, and the workflow moves along on screen by itself. Everyone leaves the room happy.

Then the project starts. The first load with the real database gets stuck, the description rule that looked simple needs consulting hours, and the ERP integration is pushed to "phase two". The POC tested the presenter's skill, not the software against your problems.

What are MDM and a POC, exactly?

SAP defines it this way: "Master data management is the discipline of creating and maintaining a single, trusted view of an organization's most important business data across systems" (SAP, What is master data management (MDM)?). Note the word discipline. MDM software is the tool that supports that discipline every day: data entry, rules, approvals, quality and distribution to other systems.

A proof of concept (POC) is a short, controlled test in which a company checks whether a tool solves its problems, with its data, before signing. It answers one simple question: does this work here? It is not training, not implementation and not a sales presentation.

When does a POC make sense?

After the RFP and the shortlist. A POC costs effort on every side, so it comes in when you already have two or three vendors that passed on paper. If you are not there yet, start with how to prepare an RFP for MDM software and use this checklist of what to evaluate in MDM software to set your criteria.

The RFP tells you what the vendor says it has. The POC shows what it can do with your records, in front of you. They are different steps and one does not replace the other.

How do you choose the data sample for the POC?

The sample decides the outcome. If it is too clean, any tool will pass.

Step 1: measure quality before the test

Without a baseline you cannot tell whether the tool improved anything. Before sending data to anyone, measure completeness, description standards and duplicates in the slice you chose. The article on how to measure master data quality shows where to start.

Step 2: include the hard cases on purpose

• Materials with duplicates your team already knows about (the same item under different descriptions). This is where deduplication proves itself.
• Suppliers with expired documents, pending qualification or a registration status that does not match official records.
• Records with empty mandatory fields and non-standard descriptions.
• A volume that makes the bulk load actually work, not a handful of rows.

Step 3: give the same sample to every vendor

If each vendor tests a different dataset, you are not comparing anything. Same sample, same scenarios, same deadline.

How do you protect personal data in the sample?

Customer and supplier records for individuals contain personal data: national taxpayer ID, address, phone number. In Brazil, the individual taxpayer ID is the CPF (and the company ID is the CNPJ). The LGPD, Brazil's General Data Protection Law (Law No. 13,709/2018), applies to data processing in Brazil. If your operation is elsewhere, check your local law. Two LGPD concepts help decide what to send.

The necessity principle, in Article 6, item III, limits processing to the minimum necessary to achieve its purposes, covering only pertinent data. Article 5, item III, defines anonymized data as data about a data subject who cannot be identified, considering the use of reasonable technical means available. Article 12 adds that anonymized data is, as a rule, not considered personal data for the purposes of the law, unless the anonymization can be reversed (Law No. 13,709/2018, official text in Portuguese). These are free translations of the original Portuguese text.

My recommendation for the POC:

• Send only the fields each scenario needs to test.
• Mask or anonymize what is not being tested. If the scenario is about material descriptions, the vendor does not need to see anyone's taxpayer ID.
• When a scenario requires real personal data (document validation, for example), use the smallest possible slice and agree in writing with the vendor on how that data will be handled and discarded.
• Involve your company's data protection officer before sending any file.

How do you write the test scenarios?

Write the scenarios before you see the tool and put the expected result on paper. If you define success after the demo, the vendor defines it for you. Five to eight well written scenarios are enough.

Scenario	What to prepare	Expected result	Evidence to keep
New material record with workflow	Your current approval flow mapped, with steps and owners	The request goes through the right steps and each approver sees only what they need	Screen recording and record history
Change to an existing record	Sample records and the rule for who can change what	The change requires approval when the rule says so and is logged	History showing who changed it, when and the previous value
Material deduplication	The list of duplicates your team already knows	The tool finds the known duplicates and explains its criteria	Duplicate report compared with your list
Supplier validation against an official source	Suppliers whose registration status does not match	The inconsistency is flagged before approval	Screen or report with the lookup result
Bulk load	A spreadsheet with real volume and mixed errors	Valid records go in, invalid ones come back with the reason	Load report with accepted and rejected rows
ERP integration and error response	An ERP test environment or a simulated response, including one send that fails	The send is logged with status, attempt and a readable error message	Send log with the ERP identifier
Rule configured by your team	A new business rule written by the key user	Your team configures the rule with guidance, without code	Recording of the configuration and the rule test
Audit trail	A record that went through the previous scenarios	You can reconstruct everything that happened to it	History export

Who takes part and who operates the tool?

The vendor explains. Your team operates. This is the rule that most clearly separates a POC from a demo.

Who needs to be in the room

• Master data key users, who will use the tool every day. Their role is covered in what your key user needs to know about MDM software.
• IT and architecture, for integration, security and access.
• The data owner of each domain being tested (procurement for suppliers, engineering or maintenance for materials, for example).
• IT procurement or the PMO, to keep the schedule and record the scores.

What to ask the vendor

Ask for access to the environment so your team can run the scenarios. If configuration is needed, it happens in front of you. A setup "we did last night" does not prove your team will be able to maintain it later.

How do you score vendors in the POC?

Set the weights first

Each scenario gets a weight based on what matters to your business. The group agrees on and signs off the weights before the first session.

Score only with evidence

Use a simple 1 to 5 scale. A score without saved evidence does not count. "It worked at the time" is not enough. Keep a recording, log or report for each scenario.

Hypothetical example. The numbers below are fictitious, only to show the math. A company sets these weights: ERP integration 25, record creation with workflow 25, material deduplication 20, rule configured by its own team 15 and audit trail 15, for a total of 100. Vendor A scores 5 on workflow and 2 on integration. Vendor B scores 4 on both. Across these five weighted scenarios, B is already 25 points ahead on workflow and integration alone and can win without the nicest screen, because it did better on what weighs more for this company. That is what weights are for.

What warning signs show up during a POC?

• The vendor insists on using its own data "because it is faster".
• Configuration happens out of your sight and shows up ready.
• The integration scenario is "left for the project".
• Results appear, but there is no trail of who did what.
• Every new rule needs a ticket to the vendor.
• The answer to a failed scenario is a slide.

None of these signs rules out a vendor on its own. But write them down, because they tend to come back during the project.

What should go from the POC into the contract?

• The approved scenarios, with expected results, as acceptance criteria for the implementation.
• What was shown as configurable by your team, so it does not become a separately billed service later.
• The scope of the ERP integration, including how error responses are handled.
• How test environments work and who maintains them.
• What was agreed about handling and discarding the data sent during the POC.

Where to start

1. Close the shortlist based on the RFP.
2. Measure the quality of the slice that will become your sample.
3. Build the sample with the hard cases and protect personal data.
4. Write five to eight scenarios with expected results and weights.
5. Define who takes part and make sure your team will operate the tool.
6. Run the POC with the same sample for every vendor and keep evidence of everything.
7. Take the approved scenarios into the contract.

To check whether your scenarios cover what matters, go back to the MDM software evaluation criteria.

Frequently asked questions

How long should an MDM proof of concept last?

It depends on the number of scenarios, how many domains are in the test and how much time your team can dedicate. ERP integration is usually what needs the most preparation. I prefer a short, fixed timeframe, agreed in advance and the same for every vendor, because a POC without an end date becomes a project without a contract.

Should the POC be paid?

It depends on the scope and the effort you ask from the vendor. A POC with real integration and several domains is work for both sides. My view: discussing this openly in the RFP is better than finding out later. What matters is that the agreed model does not take away your right to operate the tool and keep evidence. To understand the cost of a full solution, see how much an MDM solution costs.

Can I send real customer and supplier data to the POC?

Real data is what gives the POC its value, but personal data needs care. In Brazil, the recommendation is to follow the LGPD necessity principle (Article 6, item III): send only what each scenario needs to test and mask or anonymize the rest. Talk to your company's data protection officer before sending anything.

How many vendors should take part in the POC?

It depends on how much time your team has, because each extra vendor is another full round of scenarios. In my opinion, two or three that already passed the RFP are enough. More than that tends to wear the team out before it reaches what matters.

What is the difference between a demo, a POC and a pilot?

A demo is the vendor showing the tool, with its own data and script. A POC is your team testing scenarios you defined, with your data, before signing. A pilot is real use in a small scope, usually after the contract, to adjust the process before expanding.

What if no vendor passes the scenarios?

First, review the scenarios: was the expected result realistic and clear to everyone? If it was, you just avoided a bad project. Go back to the RFP, check whether the problem lies in the requirements or in the vendors you consulted, and adjust the shortlist before a new round.

How 4MDG can help

The scenarios in this article match what the 4MDG platform offers: cloud SaaS, workflow configurable without code, declarative business rules tested against real records, bulk entry by spreadsheet, integration through a REST API and connectors to ERPs (each send records status, attempts, the ERP identifier and the response message) and a complete history for every record. The details are in how the platform works and integrates.

If you are still building your sample, you can request a 4MDG assessment on a real sample of your data. You send a spreadsheet or an extract, nothing is installed in your environment, the material is covered by a confidentiality agreement and it stays with your company whether or not you sign. If you would rather talk first, speak with a 4MDG architect.

Note: the LGPD section is general guidance, not legal advice. For your specific case, consult your data protection officer and legal team.

Sources

• SAP. What is master data management (MDM)? https://www.sap.com/resources/what-is-mdm. Accessed on October 7, 2026.
• Presidency of the Republic of Brazil (Planalto). Law No. 13,709/2018, Brazilian General Data Protection Law (LGPD), Articles 5 (III), 6 (III) and 12, official text in Portuguese. https://www.planalto.gov.br/ccivil_03/_ato2015-2018/2018/lei/l13709.htm. Accessed on October 7, 2026.