On the Funding List, Off the Post-Mortem: What a Master Data Program Can Be Held To

Weaving Intelligence (House AI Style), with Jeff Shabel’s Experiential Commentary

In 2011 Lidl began planning to replace the merchandise management system it had built for itself over decades. Its statement of what was wrong with that system is the most ordinary list in enterprise software: "process breaks, redundant master data storage, integration gaps and functional restrictions" [1]. Seven years, roughly a thousand staff and hundreds of consultants later [2], the program was stopped [1] [2] and the company planned to return to the system it already had [2]. Redundant master data storage would still be on the list, because the old system was coming back. The decision at the centre of the conflict, how the company values its stock, had never been on the list at all [2] [3].

I start there because that case holds the whole problem in two documents. The first is the funding list, the page of a business case that names the defects the money will fix. Master data belongs on it and is usually there, in words a finance director can sign: duplicate records, redundant storage, figures that will not reconcile from one system to the next. The second is the post-mortem, and a post-mortem lists decisions, not defects. Master data rarely appears on it by name, because the decisions that sink a transformation are taken in rooms where nobody says "master data" and nobody believes they are taking a data decision. They believe they are settling a price, a policy or a way of counting. The master data program answers for those decisions anyway.

Sometimes the only way I have seen master data funded at all is as a line inside somebody else's modernization, so staying out of the combined program is not a real option. What a master data lead can do is decide, before the money is signed, what the program will agree to be held to, and refuse the rest in writing. That is a narrower thing than the alignment playbooks this subject usually attracts, and I think it is the only part of alignment that is actually in a data team's gift.

An enabler inside a program that usually misses

The premise has to be fixed first, because everything after it depends on it. Asked whether master data should lead a transformation, follow it or run beside it, I began with what the discipline is:

There's nothing 'transformative' about MDM. Properly understood, MDM is an enabler, not a transformer. If it does what it says on the tin, MDM will provide clean, uniform, de-duplicated data that can be trusted to downstream systems. It won't, by itself, do anything with that data, though.

That is a claim about the shape of the discipline, not a modest one. A master data program delivers records that are clean, consistent and free of duplicates, and hands them to the systems downstream. Then it stops. It does not price the goods, route the truck or answer the customer. Something else does the transforming. The corollary is the one nobody budgets for: a discipline that cannot produce a transformation's win can certainly produce its loss. Merge two customers who were never the same customer and the downstream system will act on the merge with complete confidence.

The economics literature puts the same shape in more careful words. Reviewing the case-study and firm-level evidence on what computers were actually worth to the firms that bought them, Brynjolfsson and Hitt concluded that organizational investments "have a large influence on the value of IT investments," and that the benefits of IT investment "are often intangible and disproportionately difficult to measure" [8]. Their subject was information technology in general, not master data, but the structure transfers directly. If the value of an enabling investment arrives only through the complementary changes made around it, then two things follow. It cannot be measured on its own, because its contribution is tangled up in the thing it enables. And if the complement fails, the enabler's measured value goes with it, however well it was built. A multiplier applied to nothing returns nothing.

Now set that against what the complements usually deliver. The most-cited survey on the subject, McKinsey's 2018 study of 1,793 respondents, opens by stating that the success rate for transformations "is consistently low: less than 30 percent succeed," and then reports that for digital transformations "Only 16 percent of respondents say their organizations' digital transformations have successfully improved performance and also equipped them to sustain changes in the long term" [7]. That is self-report, not a failure rate, but it establishes a base rate that should worry anyone about to tie their program's grade to the whole: on the evidence most often quoted, the thing being joined usually does not report meeting its own goals.

So a master data program inside a transformation is an enabler, whose value is hard to isolate even when everything works, attached to an effort that more often than not reports falling short. Graded as part of the whole, it inherits the whole's base rate and none of the credit when the whole succeeds. That asymmetry is the reason for everything that follows.

A list of defects and a list of decisions

The Lidl record is secondary: trade and business press and one independent case study, with no published business case and no headline cost that either company has confirmed [2].

The chronology is not in dispute. Planning started in 2011 [2]. Internally the program was "positioned as the largest transformation in the company's history" [3]. It went live in the Austrian stores in May 2015, with ten thousand stores and more than a hundred and forty logistics hubs still ahead of it [1]. In April 2017 the software vendor gave Lidl an award as one of its best customers, and in May 2017 Lidl's head of IT left [2]. In July 2018 the program was halted, and the letter to staff said "The strategic goals as originally defined were not possible at an acceptable expense" [2].

What happened in between is the part that matters here. Lidl valued its inventory at purchase prices. The standard retail software works from retail prices. Consultancy.uk's account of the collision is worth quoting whole: "fearing the group could lose a competitive edge by compromising, Lidl declined to change, so the software was instead adapted. As this and several other accommodations had to be made, performance fell and costs rose" [2]. An independent case study by Henrico Dolfing, summarising reporting in Handelsblatt and Heise, reports the valuation mismatch as "a central point of conflict," and then, in his own analysis, refuses to let it carry the whole weight: the failure "is often explained as a mismatch between Lidl and SAP, but that explanation is incomplete" [3]. His deeper reading is a structural conflict between standard software's built-in assumptions and an operating model whose advantage lies in not being standard.

That warning cuts against the easy use of this case, including mine. The valuation basis did not end the program by itself. What the record does support is narrower, and Dolfing supplies it. Lidl adapted the system rather than the business "not out of technical stubbornness, but out of strategic caution," and "The problem was not that this choice was made, but that its implications were not fully recognized at the time" [3]. That is his judgement, not a documented finding, and if it is right, the attribute that decided the economics, how stock is valued, was settled inside delivery, as an accommodation made by people with a go-live date, instead of ahead of it by the few people entitled to say what the company is.

Now put the two documents side by side. The funding list named redundant master data storage as a defect. The post-mortem, as far as the public record reconstructs one, turns on a definition: what a unit of stock is worth, and whose idea of it the software would follow. Nobody would have filed the second under master data. It is master data all the same: a shared, governed attribute of a core business entity, which every downstream process depends on and nobody downstream is entitled to change. The program was funded to fix the first and was destroyed, in part, by the second.

There is a respectable objection to all of this, and it comes from the software side. Jean-Claude Flury, head of DSAG, the SAP user group, put it in one line when the program collapsed: "If a company wants to use the standard software, it has to adapt its own processes" [2]. He may well be right that Lidl should have moved. But whether a business moves to fit the software or moves the software to fit it is still a decision about a definition, and my point survives either answer. The decision has to be taken knowingly, by someone entitled to take it, before the program is committed to one side of it.

What the matching engine can honestly promise

A disclosure belongs here, before I assess anyone's product. The practice behind this publication is a Profisee partner and holds a referral agreement with Profisee. Clients pay us for deployment work, and a licence sale we refer earns us a referral fee from the vendor. Beyond both, our services revenue depends on this category of software being bought at all, so what I say about the promises made for master data software is said by people with a stake in the category. The documentation I examine below belongs to a different vendor and was chosen because it is public and specific. Weigh my criticisms above any praise.

Two promises get attached to master data work when it is sold into a transformation under the banner of a single customer view: that the platform is comprehensive out of the box, and that matching will be automated. The first is a definitional trap with no product answer, and I will come back to it. The second can be checked against documentation, which is more useful than arguing about it.

The oldest decision rule in the discipline is still the clearest statement of what matching is. In the record-linkage model attributed to Fellegi and Sunter in 1969, as a Census Bureau overview by William Winkler sets it out, every candidate pair gets a matching weight R and is sorted three ways: "If R > Tμ, then designate pair as a match. If Tλ ≤ R ≤ Tμ, then designate pair as a possible match and hold for clerical review. If R < Tλ, then designate pair as a nonmatch" [4]. The two cutoffs are not free parameters. They are "determined by a priori error bounds on false matches and false nonmatches" [4]. Winkler calls the middle band the clerical review region.

That middle band is what this decade calls a human in the loop, and it is not the symptom of an immature program. It is the shape of the decision. Automation moves its boundaries; it does not remove them. Winkler's own numbers show both halves of that. In a very large 1990 census application, computerized procedures cut the clerical and field follow-up from "an estimated 3000 individuals over 3 months to 200 individuals over 6 weeks" [4]. Not to nobody. And in the other direction, he reports Newcombe and Smith's 1975 finding that "purely computerized duplicate detection in high quality person lists can often identify duplicates at greater level of accuracy than duplicate detection that involves a combination of computerized procedures and review by highly trained clerks" [4]. Those are national statistical operations on person lists, not customer masters: the structure of the decision transfers, and the numbers do not.

A current commercial product says the same thing in a vendor's vocabulary. Microsoft's documentation for the matching step of its customer-data platform lists what ships in the box: normalization that "Converts over 500 common name variations and titles," and that "Removes around 50 company name 'noise words' such as 'co,' 'corp,' 'corporation,' and 'ltd.'" [5]. Past that, the customer supplies lists: pairs that should always match, strings that should never match, values to bypass. Precision is a dial, set at "Low (30%), Medium (60%), High (80%), and Exact (100%)" or at a custom percentage [5]. And the page does not pretend the rules finish the job. It documents exceptions "To address rare cases of false positives and false negatives," gives twins as its worked example, and instructs: "If records are discovered that need special matching treatment, update the appropriate data source. The update will be used during the next unification process" [5].

That is the clerical review region's work with no region drawn for it: someone has to find those records and maintain those lists. One product's documentation is not a survey of the category, but what it shows is that the box holds a starting set and a set of dials, and that the distance between a starting set and "comprehensive" is the program. Nothing on the page says how much of that work there will be, because that depends on where the dial is set. And the dial will be set by whoever is answering for the automation figure that month.

The opposite of the late-arriving review queue is not a better dial; it is catching the duplicate before it exists. Mainstream customer software ships exactly that. Salesforce's own training material describes matching rules that find potential duplicates and duplicate rules that decide what happens when a user is about to create one, and says of the second: "As the admin, you choose whether to block your sales teams from creating duplicate records" [9]. Prevention at the point of entry is a standard, configurable feature. Whether it gets switched on depends on who owns the screen, which is a question about the transformation, not about the data program.

Who argues the other way

Two positions run against the one I am building, and both deserve better than a sentence.

The first is about sequence. Richard Churchill, writing for a consulting audience this year, names as a predictable failure the pattern in which "Digital platforms, analytics or operating model redesign often begin while core processes, data or governance remain fragile" [6]. His positive example is a financial services firm that built foundational data structures and strengthened its relationships with frontline sales teams before introducing new applications, with the result, as he reports it, of faster delivery, higher adoption and tools shaped by the people who used them [6]. That is data work going first and being credited for the outcome, which is the opposite of the instruction I give below. The case is anonymised and unquantified, reported by the consultant who advised it, but it is a real case, and my instruction has to give ground to it.

The second is about measurement, and it comes from closer to home than I would like: the vendor whose product our practice deploys and refers. In a 2025 post on measuring the value of master data management, Profisee's Martin Boyd describes customers who "target a specific initiative like increasing cross-sell revenue from existing customers by 1%," while others count the hours or full-time staff saved from manual data preparation [10]. That is a business-outcome target carried by a master data program, which is exactly what I am about to tell a program lead to refuse. It is vendor marketing, a position rather than evidence, and the same post concedes much of my ground: its first section is headed "KPIs for MDM Make Sense in Some Cases, But Not Always," and it says that where data starts out duplicated and inconsistent "it's difficult to get a sense of the data's potential to drive business results" [10]. The disagreement between us is narrower than the headline suggests, but it is real, and I come back to it at the end.

The operating record: what I have watched happen

The argument stops here, and the warrant changes with it: what follows is my own operating experience, drawn out in interview and quoted in my own words where the words matter, offered as patterns rather than laws and with no method I can hand you for falsifying them.

The door the money comes through

The recurring trouble that comes with attaching master data to a big transformation, trouble a standalone program never has, came out of me first as a single word, and the rest of the answer took it apart:

Interdependence. Cross-domain or responsibility dependency can cause all kinds of issues. Spill-over of poor performance, inability to meet deadlines or lack of solid deliverables can all serve to paint the MDM program with tar they didn't earn themselves. Whenever MDM, or any other program, is part of a large, combined initiative, the entire initiative is treated as one, cohesive unit. Therefore, it either all succeeds or all fails. It's a risk either way, but it is also sometimes the only way to get MDM funded as part of a larger 'modernization' or migration initiative.

The first half of that answer is the risk, and the second half is the reason people take it anyway. I would not trade either half for the other. A modernization has a budget. Master data on its own has a business case and a place in a queue, and in my experience that queue sometimes never reaches it. So the question was never whether to attach. It was what the attachment says about how the program will be graded, and the answer, by default, is that it says nothing, which means the program will be graded as part of the single object and will share its mark.

That default is fixable, and the fix is cheaper at month zero than at any point after. The combined initiative will be judged whole; the master data program can still have its own line on the scorecard if somebody writes it there before the money is signed. It is rarely done, I suspect, because at signing everyone is optimistic, and a separate line for one workstream reads like a hedge against colleagues. It is a hedge. It is also the only way the program's own delivery is visible when a workstream two doors down misses a date.

One more thing about the door. A sponsor's enthusiasm buys a program its budget priority and does not buy the departments' willingness to change how they work; I have watched an executive's excitement fail to travel to the groups who would have had to rework their processes. Inside a transformation that gap matters more than usual, because the transformation's sponsor is excited about the transformation, not about the definitions underneath it. The departments that have to agree what a customer is, or what a unit of stock is worth, have been handed a go-live date, not a reason.

The promises made in the program's name

What gets promised about a customer 360 that the master data underneath cannot yet support? My list was short:

Out of the box comprehensiveness and automation. Those are both moving targets, the first because nothing can be comprehensive out of the box when 'comprehensive' hasn't yet been defined. The second because MDM can never be 'fully automated.'

The first moving target is the one the Lidl record makes concrete. "Comprehensive" is an acceptance criterion with no fixed referent, so it moves every time somebody remembers another source system or another attribute. The deeper trouble is that comprehensiveness is usually undefined because the business has not agreed its definitions, and no program can agree them on the business's behalf. My position is that a program reveals who owns the data rather than settling it, and I lean hard on "reveals". A system can carry as much intelligence as you like; if the business has to route around it to keep operating, it will. Master data work surfaces the undefined things. It cannot define them, and a promise of comprehensiveness quietly signs the program up to do exactly that.

The second target is the one Winkler's decision rule makes concrete [4]. There will always be a review region; the only question is how wide, and who staffs it. So when a program is sold full automation, it meets on go-live day a queue it was told would not exist. The customer 360 answer went on to the two ways a program cheats its way out of that queue: force every record into a shape it does not have, or set the auto-approve threshold so low that nearly every pair clears unaided. Of the second, I said those were

thresholds guaranteed to require more work by the Data Stewards remapping false matches upon which business has already made decisions and issued reports.

The order of events is the whole of it. The merge happens. The merged record goes downstream. Somebody runs a report off it, and somebody senior makes a call on the report. Only then does a steward find that the two records were never the same customer, and the unpicking has to reach every place the merge went, including decisions already taken. In Fellegi and Sunter's terms, lowering the upper cutoff is choosing a higher tolerance for false matches without writing the choice down [4]. The work does not go away when the bar comes down. It moves to a desk that does not report to whoever lowered it, and it arrives later and dearer. That is why the shortcut keeps looking attractive on the plan: the saving is on one line and the cost is on another, and the automation figure that justified it is the only number that looked better.

The one win a business audience can watch

There is one place where a master data program can produce something a business audience sees happen, and it is not the steward queue. The question put to me was how a master data deliverable connects to a customer-experience outcome that somebody else owns. My answer skipped the theory and named the move:

Lookup-before-create and in-flight data cleansing. Most 'modern' UI interfaces utilize 'type-ahead' functionality and tying the MDM system into that interface using SOA pipelines with JSON interfaces tie MDM directly into the UX. This provides immediate, visible value to the Enterprise and, in the case of UX projects, the User.

Read that closely and it is a claim about dependency as much as value. The move needs three things that are not the master data program's to supply: a screen that already offers type-ahead, a service fast enough to answer while someone is still typing, and a user-experience project already under way to attach to. None of the three appears on a master data plan. All three appear on the transformation's. The prevention itself is not exotic; mainstream customer software ships it as a switch an administrator turns on [9]. What decides whether it happens is whether the people redesigning the screens think of the data service as part of their design or as a system to be integrated after go-live.

When it works it is worth more than any amount of resolution afterwards, because a duplicate that is never created never goes downstream, never reaches a report and never needs a steward. It is also the one version of the work a business audience can watch, and the applause will go to the experience project. It should. The number the master data program can claim is its own: how many creations were caught as existing records at the point of entry, and how fast the lookup answered. That is a program metric, and it is enough.

When the umbrella changes its name

Transformations are long, and the thing funding the data work does not always keep its sponsor or its strategy for the whole of it. When I was once told that a new director, a cloud migration or a regulatory change was an external event rather than scope creep, I corrected the premise:

Zero-days, a new director, a cloud migration and regulatory change ARE scope creep, and here is why: every time one of those occurs it has downstream effects on all in-flight projects. New directors or C-level executives need to come in and put their stamp on everything, so they will change in-flight projects as a matter of course — usually clothed in "status reviews" and "progress assessments," but always resulting in changes. Cloud migrations are inherently scope changes, because they have a fundamental effect on a partially implemented architecture. Regulatory changes are axiomatically scope changes, since they always add new requirements.

For a master data program inside a transformation, that correction has a specific consequence. The transformation's own scope changes are the data program's scope changes, whether or not anyone files them that way, because every one of them lands on a partially built architecture that the data program is part of. A new executive's status review of the transformation is a status review of the master data program, conducted by someone who has never heard its case.

The trouble in my experience is not a change of sponsor or of middle management, which programs survive routinely when there is a clear handover and the strategy holds. The trouble is a strategic change above the project. When that happens my advice is blunt: finish before the review of the new strategy concludes, or be ready to fight for the funding. A master data program whose deliverables are separately defined and separately visible can do the first. One graded only as part of the whole cannot even show what it would be finishing.

What I would sign, and what I would refuse

The rest of that first answer, on whether master data should lead, follow or run beside a transformation, was the instruction:

So I would strongly advise against 'leading' a transformation with MDM. It should be stood up beside other initiatives and used as a deliverable multiplier.

Churchill's case tests that, and the instruction does not hold in its absolute form [6]. A firm built its data foundations before its new applications and credits the sequence with faster delivery and higher adoption. So the instruction moves once. The decision has to lead; the program must not. Those are two different objects, and they belong in two different rooms. The definition is a statement of what the company means by a customer, a product, a price and a unit of stock. It belongs at the top, before money is committed, with the few people entitled to answer it. That is the step Lidl's record suggests was taken inside delivery instead [3]. The program is a delivery capability. It belongs beside the initiative, making the other deliverables worth more than they are without it. Notice that the gains Churchill reports, speed of delivery, adoption and tools that fit their users, are ones a data program can own. His case fits the narrower rule rather than breaking it.

The narrower rule still rules something out, and it is the thing that matters. It rules out the master data program taking the transformation's headline outcome as its own pass-or-fail criterion. I draw the line the way I have drawn it between engineering and the advisory disciplines: one builds things that change what the line departments do, and the other suggests ways to tune those things. Master data sits closer to the second, and the outcomes it produces in a business are adjustments to course rather than changes of direction. A program in that position cannot be held to basket size, churn or the modernization's business case, because it does not price the goods and does not touch the customer. Accepting those numbers as its success criteria is agreeing to be graded on somebody else's work.

That is where Boyd's post and I part company, and also where we meet [10]. I do not tell a program lead to hide from the business number. Where I can show my work and trace a program's direct effect on a number the business already tracks, I always do it; the danger has never been the large number, only the one with nothing underneath it. The distinction is between showing a contribution and accepting a target. A program can show that the cross-sell list exists only because several records of the same customer became one. It should not sign up to deliver the one percent, because whether the sales team uses the list is not its to decide.

So here is what I would sign, as an argument for the program lead rather than a record of any scorecard. The program can be held to:

• A match rate, stated with the error bound it was set against, so that the dial cannot move without the bound moving with it.
• The size and age of the review queue, which makes the staffing of the clerical region a visible cost instead of a hidden one.
• The share of creations caught as existing records at the point of entry, where that door has been opened for it.
• Survivorship that behaves the same way on Tuesday as on Monday.
• How long a steward waits for a decision.
• A register of definitions, each with a named owner and the date it was agreed: the kind of page the public record of Lidl never shows.

Everything else it should refuse, in writing, at month zero: basket size, churn and the modernization's business case among them.

The coupling to the transformation is not the mistake. The coupling is how the money arrives. The mistake is leaving unwritten which numbers belong to whom. What has kept data teams alive through lean years, in everything I have seen, is being woven into the enterprise's data strategy with sponsorship several layers deep rather than hanging from one initiative's line item. A program that has agreed its own numbers can survive its transformation. One that agreed to the transformation's numbers shares its fate, and on the base rate above that is usually not a good fate.

Two lists, signed before the clock starts

Every program of this kind starts with a funding list. Master data will be on it, named as a defect in words a finance director signs, and that is fine. What is missing at the start is the other list: the definitions the company has never agreed, the ones where two departments give different answers today and neither thinks it is disagreeing. At Lidl that list, if anyone had written it, would have held one line about how stock is valued. It was a line that mattered.

Pressed on what a program like this is actually selling, if ownership can only ever be revealed and never settled, I put it this way:

We are selling joints. We are selling flexibility in the process — the ability to expand and contract and adapt to the challenges above and below the project. We are building the tools and the frameworks and the architectures that can flex with the needs of the business and work to close the gaps we identify along the way. We are not selling perfect, because no one can deliver that. We are selling good enough, and configurable enough to change to address the future.

A master data program attached to a transformation is a joint in that sense: the place where the transformation's changes of direction are transmitted into every system that holds a customer or a product, and the place that takes the strain when they are. I mean the joint the way anatomy means it, not carpentry, which builds joints to stop two pieces moving; a body's joint lets them move within a range and carries load as it does. It can only do that if its range of motion is written down. A joint that moves in every direction is not flexible. It is dislocated.

So the playbook, such as it is, comes down to two pages written before the money is signed. One lists the definitions the transformation depends on, with an owner beside each. The other lists the numbers the master data program will be held to, and says in plain words which numbers it will not. Neither page is difficult to write. Neither is on the funding list, and the program that will answer for what was not written on them is rarely the one asked to write them.

An earlier version of this piece — written before this publication rebuilt how its voices are generated — is published unedited at Master Data Doesn't Transform Anything: A Playbook for Serving Somebody Else's Transformation (original), so the two can be read side by side. The account of why is at The Voice Problem.

References

[1] Cliff Saran, "Lidl dumps €500m SAP project," Computer Weekly, 16 August 2018. Read 2026-09-26 through a rendering fetch; not stored locally (egress refused). Cited for Lidl's own statement of the faults of the system being replaced, "process breaks, redundant master data storage, integration gaps and functional restrictions"; for the go-live in the Austrian stores in May 2015 with 10,000 stores and more than 140 logistics hubs planned; and for the halt ("Lidl has now decided to drop the €500m project"), with the memo to staff reported in paraphrase. It does not report a return to the old system, which is cited to [2]. A trade outlet reporting German press coverage; it contains nothing on inventory valuation, which reaches this article through [2] and [3] only. https://www.computerweekly.com/news/252446965/Lidl-dumps-500m-SAP-project

[2] "Lidl cancels SAP introduction having sunk €500 million into it," Consultancy.uk, 13 August 2018. Read 2026-09-26 through a rendering fetch; not stored locally. Cited for: planning since 2011 and roughly 1,000 staff and hundreds of consultants; the purchase-price versus retail-price valuation mismatch and the passage quoted in the body ("fearing the group could lose a competitive edge by compromising, Lidl declined to change, so the software was instead adapted. As this and several other accommodations had to be made, performance fell and costs rose"); the April 2017 award and the May 2017 departure of the head of IT; the letter to staff ("The strategic goals as originally defined were not possible at an acceptable expense"); and Jean-Claude Flury of DSAG ("If a company wants to use the standard software, it has to adapt its own processes"). Also cited for the return to the old system: "Lidl intends to revert to its old inventory system" (the body keeps the tense of a plan). The article states that neither Lidl nor SAP had confirmed the headline figure, which is why the body does not use it. Its "starting from scratch" line is quoted by the outlet from Handelsblatt, which is paywalled and was not opened; the body does not use it. https://www.consultancy.uk/news/18243/lidl-cancels-sap-introduction-having-sunk-500-million-into-it

[3] Henrico Dolfing, "Case Study 12: Lidl's €500 Million SAP Debacle," published 5 May 2020, updated 14 May 2026. Read 2026-09-26 through a rendering fetch; not stored locally. An independent advisor's case study synthesised from press primaries (two Handelsblatt reports, Heise, Manager Magazin, Reuters, IT-Markt), none of which was opened: Handelsblatt is paywalled and the Heise page returned an empty document when last tried on 2026-09-06. Used for two things, kept apart. REPORTED BY DOLFING FROM THE GERMAN PRESS, which was not opened: "Reporting from Handelsblatt and Heise identifies this mismatch as a central point of conflict". HIS OWN ANALYSIS: the program "positioned as the largest transformation in the company's history"; the usual explanation as "incomplete"; and the judgement that Lidl adapted the system "not out of technical stubbornness, but out of strategic caution," the problem being "that its implications were not fully recognized at the time." That last judgement carries the article's narrow reading of the case, and it is one careful reader's view, not a documented finding. https://www.henricodolfing.ch/en/case-study-12-lidls-e500-million-sap-debacle/

[4] William E. Winkler, Overview of Record Linkage and Current Research Directions, U.S. Census Bureau, Research Report Series (Statistics #2006-2), 8 February 2006. Sections 1 through 3.3 recorded as read in full 2026-09-06; the passages used re-checked verbatim 2026-09-26 through a rendering fetch; not stored locally. Cited for the Fellegi-Sunter decision rule as quoted in the body, the statement that the cutoffs are "determined by a priori error bounds on false matches and false nonmatches," the clerical review region, the 1990 census reduction "from an estimated 3000 individuals over 3 months to 200 individuals over 6 weeks," and Newcombe and Smith (1975) on purely computerized duplicate detection in high-quality person lists. The 1969 Fellegi-Sunter paper and the 1975 Newcombe-Smith paper were not opened; both attributions are Winkler's. Population: national statistical operations, not commercial customer masters. https://www.census.gov/content/dam/Census/library/working-papers/2006/adrm/rrs2006-02.pdf

[5] Microsoft, "Define matching rules for data unification," Microsoft Learn, Dynamics 365 Customer Insights - Data, last updated 12 December 2024. Read 2026-09-26 through a rendering fetch; not stored locally. Vendor documentation, cited for what the feature is and not for whether any product is good: the name and organization normalizations ("Converts over 500 common name variations and titles"; "Removes around 50 company name 'noise words'"), the customer-supplied always-match, never-match and bypass lists, the precision levels ("Low (30%), Medium (60%), High (80%), and Exact (100%)") and custom threshold, rule exceptions "To address rare cases of false positives and false negatives" with the twins example, and the instruction "If records are discovered that need special matching treatment, update the appropriate data source." One product's documentation is not a survey of the category. https://learn.microsoft.com/en-us/dynamics365/customer-insights/data/data-unification-match-tables

[6] Richard Churchill (Principal Consultant, Leading Resolutions), "Sequencing transformation: Building capability without overloading the organisation," Consultancy.uk, 5 May 2026. Recorded as read in full 2026-09-06; passages re-checked 2026-09-26 through a rendering fetch; not stored locally. Cited as the sharpest published opposition to the instruction the article narrows: the quoted sentence on initiatives beginning "while core processes, data or governance remain fragile," and the financial services example, paraphrased in the body, in which foundational data structures were built before new applications with reported faster delivery, higher adoption and better-fitting tools. Anonymised client; unquantified result reported by the advising consultant. https://www.consultancy.uk/news/43988/sequencing-transformation-building-capability-without-overloading-the-organisation

[7] Hortense de la Boutetière, Alberto Montagner and Angelika Reich, "Unlocking success in digital transformations," McKinsey & Company, 29 October 2018. Read 2026-09-26 through a rendering fetch; not stored locally. Cited for two sentences: that the transformation success rate "is consistently low: less than 30 percent succeed," and that "Only 16 percent of respondents say their organizations' digital transformations have successfully improved performance and also equipped them to sustain changes in the long term." An online survey of 1,793 participants, 16-26 January 2018; self-reported success against the respondents' own criteria. Used as a base rate, not as a failure rate. https://www.mckinsey.com/capabilities/people-and-organizational-performance/our-insights/unlocking-success-in-digital-transformations

[8] Erik Brynjolfsson and Lorin M. Hitt, "Beyond Computation: Information Technology, Organizational Transformation and Business Performance," Journal of Economic Perspectives 14(4), Fall 2000, pp. 23-48, doi:10.1257/jep.14.4.23. Read at the abstract only, 2026-09-26, through a rendering fetch of the publisher's landing page; the full text was not opened. Cited for the abstract's two findings as quoted: that organizational investments "have a large influence on the value of IT investments," and that the benefits of IT investment "are often intangible and disproportionately difficult to measure." The article's extension of that structure to master data programs is this publication's, not the authors'. https://www.aeaweb.org/articles?id=10.1257/jep.14.4.23

[9] Salesforce, "Resolve and Prevent Duplicate Data in Salesforce," Trailhead, module Duplicate Management, unit 2. Read 2026-09-26 through a rendering fetch; not stored locally; the page carries no visible date. Vendor training material, cited only for what the feature is: matching rules identify potential duplicates, a duplicate rule decides what happens when a user is about to create one, and "As the admin, you choose whether to block your sales teams from creating duplicate records." https://trailhead.salesforce.com/content/learn/modules/sales_admin_duplicate_management/sales_admin_duplicate_management_unit_2

[10] Martin Boyd, "How Do You Measure the Business Value of MDM?," Profisee blog, 3 March 2025. Read 2026-09-26 through a rendering fetch; not stored locally. The partner's own vendor marketing, cited as a competing position and not as evidence that anything works. Cited for customers who "target a specific initiative like increasing cross-sell revenue from existing customers by 1%," for the section heading "KPIs for MDM Make Sense in Some Cases, But Not Always," and for the concession that where data is duplicated and inconsistent "it's difficult to get a sense of the data's potential to drive business results." The post names customers; the body does not. https://profisee.com/blog/how-to-measure-business-value-of-mdm/