The Business Case We Built From the Demo (original)

What the traditional model got right, where Profisee leads and where operators say it lags, and why a better number still isn't a decision.

Elias, who writes the general master-data thread here, spent Monday on the long argument — how master data management stopped being a back-office cleanup chore and became a discipline leadership has to fund on purpose [1]. He makes it at the level of the idea. I want it one layer down: inside an implementation, on a Tuesday, when the stewards log in and the platform either earns its keep or doesn't.

So: how we've built the business case for a modern MDM platform, which of those numbers held up, and where the model was quietly, structurally wrong. Profisee is the worked example, because it's the platform I know from the inside — which is a reason to be careful with me. Disclosure, up front: the practice behind this publication is a Profisee implementation partner. Weight my criticisms above my praise accordingly. The piece ends in a better number, because every business case does; it does not end in a decision, and that gap is where the expensive mistakes live.

How we used to make the case

For a long time the MDM business case was built out of fear, and the fear was justified; the discipline has a published body of knowledge behind it [1]. The opening move was almost always a big, ugly number: bad data costs the U.S. economy roughly $3 trillion a year, a figure Thomas Redman put in the Harvard Business Review in 2016 that still quiets a room [2]. Then you'd narrow it to the house you were standing in — duplicate customers, a product under four part numbers, a compliance report three analysts reconcile by hand. Look at the mess. Now imagine one clean version.

Underneath the headline sat a durable idea. The 1:10:100 rule — Labovitz, Chang and Rosansky, Making Quality Work, 1992 — says it costs about a dollar to prevent a bad record at the source, ten to fix it later, and a hundred to do nothing and eat the downstream failure [3]. Be straight about its provenance: the ratio is theirs, the per-record dollar gloss is the field's, and the whole thing is a rule of thumb, not a finding. It's still the economic argument for master data in one line.

From there the case stacked predictably: hard-dollar ROI (reconciliation hours reclaimed, duplicate suppliers collapsed into negotiated pricing), risk and compliance (the audit you can't survive when "customer" means six things in six systems), and the strategic story — single source of truth, 360-degree view — aspirational and a little overpromised. It isn't a sales invention: Microsoft's own published architecture names the same condition, duplicate records accumulating across applications and the manual effort of answering who your top customers are [10], and Gartner puts poor data quality at $12.9 million a year per organization [4].

Two notes on those figures, since this piece will demand provenance from you later. The trillion is IBM's estimate, which Redman was reporting rather than producing [2]; Gartner's $12.9 million is self-dated to 2020 [4]. Neither arrives with its sample. I'm still not telling you to drop them — there is always a number, and a case without one isn't a case. Just be clear what the big number does: it buys the meeting. I have never watched it decide anything.

All of it was right as far as it went. But the model had a structural blind spot with nothing to do with arithmetic, and I've watched it sink more implementations than any bad estimate did.

The case was built out of the demo — and the demo was honest

Here's the part I'd want a funding committee to sit with: almost every business case I've seen assembled — mine included — was reverse-engineered from a demo. That isn't a criticism of demos. A demo is a happy-path, basic-functionality demonstration: nothing more, but nothing less either. It shows the product's capability, honestly. What it cannot show is the fit between that capability and your business, because that fit doesn't exist yet — building it is the job. The traditional case priced the capability as though it were the fit.

The practice has been productised, too. Profisee offers a free Business Impact Assessment promising stakeholder buy-in and a business case that "quantifies a projected return on investment"; nothing in it runs the product against your data [14]. Reltio's business-case page carries an ROI calculator that asks your annual revenue and B2B-or-B2C sector, then returns an economic-impact estimate [15]. That's the category's standard motion, not one vendor's sin. But see what it is: a number built from your revenue and the vendor's benchmarks, before one of your records has been through the product. Treat it as the opening of the fit conversation, never the close.

The gap bites first at ingestion. Demos start from well-formulated, structured data; real life never is. In Profisee that means Connect — a codeless integration layer on open standards and pre-built connectors [7] — which in the demo looks like it will carry your ETL end to end. Now read the vendor's own FAQ carefully, because it's a lesson in how little a document settles. One entry says the capability "is not intended to replace commercial ETL tools for bulk transformations or migrations." Two questions later, asked whether it handles complex transformations and mappings, the answer is "Yes" — advanced capabilities, custom business logic, rules and algorithms [7]. Both are live on that page, and a vendor document that says both settles nothing.

So the claim is mine, and weigh it as mine: on real source data the transformation and filter surface runs out well before my requirements do, and a case that assumed demo-grade ingestion has lost weeks by month two. A reasonable advocate reads the same page and says my pre-processing is preference, not ceiling. I can't settle that with a citation, and you shouldn't let me.

Either way you build around it, and that's the part worth writing down. My standard move is external tables in SQL Server with the shaping done in views on top: the heavy work happens where the tooling is mature, Connect receives a clean load, and the transformation logic lives somewhere a data engineer can read a year later without opening the MDM tool. Naming a limitation and its workaround in the same breath isn't a disclosure problem and isn't disloyalty — designing around a tool's gaps is a basic, fundamental part of architecture, arguably the main part, and more or less what the money is for. A business case that assumes no gaps exist isn't optimistic; it's unpriced.

Where Profisee leads, where it keeps up, and where it lags

Any platform still on the market can match records, model hierarchies and hold a golden record. Those are table stakes, and a case built on them is one any competitor neutralizes in a single slide. The useful question isn't what a platform can do — it's what you'd notice the absence of, six months in. For Profisee the honest list is shorter than the datasheet. What each component is gets sourced; the judgements carry no citation, because they came from operating it:

• The web and UI layer, and low-code screen building through FastApps. Curated, task-specific experiences that business users configure into role- and task-based views themselves [11]. This is where I think Profisee leads — and where I must be most careful: that phrase is the vendor's, and my experience covers half of it. A purpose-built screen for one steward task, no front-end project attached, changes what you can ask people to do. The workflow behind the screen is a different animal: an operator reviewing the platform this May reports that building task workflows and notifications "requires an understanding of Visual Studio coding, which can be a barrier for non-technical users" [13]. Budget the screens as configuration; budget the workflow as development.
• Direct integration with Fabric and Purview. Profisee runs as a native MDM workload embedded in the Fabric interface, alongside first-party items like Data Factory and Power BI [9]; with Purview, Microsoft publishes a bidirectional architecture in which the model is pushed into Purview's catalog and Purview's definitions come back in front of the stewards in real time [10]. For a Microsoft shop that's integration work you never have to fund — and price the other side, because a competitor will: "we never have to build this" and "we could never cheaply leave" are one sentence read two ways.
• Connect, understood correctly. A strong codeless layer if you'd rather pay for built-in connectors than build them [7], with a framework that really is extendable: Profisee publishes webhook templates in .NET, Azure Functions and Node.js for integrators writing their own [8]. That's why the SQL pre-processing pattern is a design decision rather than a defeat.
• Aisey, which fills the same role inside Profisee that Copilot fills across the rest of the Microsoft stack. The vendor's scope for it is broad — every section of the platform, tasks from entity modeling to data quality rules, agent templates that parse unstructured text [12] — and I could have read all of that off the datasheet, so weigh it accordingly. Here's what I can only say from using it: the value has been concentrated in two places, building out Connect connectors and interrogating an unfamiliar dataset, and neither is where the marketing points.

Hold your usual standard there. Aisey carries the limitations all AI carries: excellent when what you want is close to what it does out of the box, and in need of massaging when you're matching an exact business requirement — most of the time, since "exact business requirement" is the whole reason you're buying an MDM platform. Accelerated development is worth money and I'd write it in. What I wouldn't write in is a percentage: "the copilot will cut integration effort by a third" reads beautifully in the deck and gets audited in month eight.

And where it lags

A piece that assessed a platform for three thousand words and produced no finding of the form "a competitor is better at this" would be a favourable review with an honest tone, not an assessment — and mine nearly was. So here is the third box, and it isn't mine: the public corpus of independent operator reviews on G2, forty-two of them, read rather than sampled [13]. Three reviewers between late 2025 and mid-2026 name performance at volume: "some challenges with system performance at larger scales, but this is allegedly addressed to some degree in more current versions," "performance limitations when processing large data sets," "it struggles with performance, especially when handling large volumes of data." Keep that first reviewer's second clause attached to his first — it is his, he is a five-star reviewer, and dropping it would have turned a qualified observation into a verdict. It also tells you what to ask: which version, and was it fixed. The same corpus names weak real-time SAP connectors, no multi-language web portal for a company with significant APAC and EMEA presence, difficulty promoting workflow between environments, and one case of anomalous behaviour that survived diagnostic queries against logs, history tables and metadata and stayed unexplained [13]. Globally stewarded, heavy on real-time SAP, very large: make each a bake-off requirement and prove it out on your volumes.

One more from that corpus, and it is the one I would have least liked to find, because it lands on the sentence this section opens with. A director-level operator writes that data quality is heavily reliant on Melissa; it would be great if this were built into the Profisee platform, and then: The rules are also not customizable—if customization could be added for merge, match, and survivorship, that would be a big improvement. [13] I called matching and survivorship table stakes four paragraphs ago. An operator running it says the table-stakes function is the one that won't bend to him, and that a piece of it is a third party's product. I can't adjudicate that from here — my own implementations never pushed on those rules hard enough to find the wall, which is worth saying plainly rather than reading my silence as disagreement. But "can the platform do it" and "can I change how it does it" are different questions, and I only asked the first one. If your matching logic is unusual, ask the second in the bake-off and get the answer in writing.

And here is the finding I owe you, because I set the bar two paragraphs ago and had not cleared it: on that specific question a competitor is ahead. Informatica's Multidomain MDM documents match rules as a configuration surface the customer builds — match column rules against columns you nominate, and rule types you choose between, including a fuzzy type whose behaviour is explicitly population-dependent: Robert, Rob, and Bob in English speaking populations, for the match purpose of Name, may have the same match token value [16]. That is the knob our reviewer says he wanted and could not reach. I am not telling you Informatica is the better platform — it carries costs and a weight of its own that this piece has not priced, and the comparison that matters is against your requirement rather than against a documentation page. I am telling you that if deeply configurable matching is your requirement, you should not take my list of leads as the whole market, and you now have somewhere specific to look.

Weigh that corpus for what it is — forty-two self-selected reviews is not a survey, and every platform in this category has a list like it. I cite it because it's the cheapest independent instrument a buyer has, and because I have an interest in the answer, which is exactly when to go get your own.

The line items TCO models leave out

Total cost of ownership is where the traditional case did its most serious work, and Forrester's Total Economic Impact is useful precisely because it forces benefits, costs, flexibility and risk into one model instead of three arguments [5]. Across every one of these spreadsheets I've built or inherited, two costs never appear. Here they are, then a third I missed and an operator didn't.

The first is emergency support. Every model has a line for product support, priced correctly — for business hours. What none price is the weekend. A bulk load fails on Saturday, and by Sunday evening somebody is writing emergency code so the business can open on Monday. The trigger is almost never the platform: it's a system upstream that altered its data profile and announced it through no channel you were watching. Your model assumed a support contract; what you needed was a human with commit rights and a working knowledge of your transformation layer, awake, alert and working at 11pm on a Sunday.

The second is scope creep and requirement drift — the strange one, because it's caused by the project succeeding. As the business gets fluent, the questions get harder and the requests more varied. That's adoption seen from the inside, and it generates change orders the TCO calculation never carried.

The third is the one I'd missed, and the most useful of the three in a negotiation. Notice the convenient shape of my own two: the weekend is triggered upstream, the change orders are caused by your success. Neither costs a vendor anything in a bake-off, and I should have caught that before a stranger did. The line I'd left out is licensing. An operator reviewing the platform this July writes that data modeling decisions can have a significant impact on record volumes and, therefore, licensing costs, and that their implementation generated substantially more records than they had anticipated [13]. Be fair to him: he blames himself, calling it more a result of our design choices and limited experience with MDM modeling than a shortcoming of the software itself, and he is probably right. That is exactly why it belongs in a cost model rather than a complaint — a risk that materialises through your own inexperience is still a risk, and it is the kind no vendor is obliged to warn you about. Read it again for when it happens: record counts follow from how you model, and you model after you sign. Ask in writing, before signature, what the licensed unit is and what the invoice looks like at two and three times your estimate.

I won't hand you a multiplier for the first two; I'd be making it up. The third you can size yourself. Put all three in as named unknowns your CFO has to look at, rather than zeroes she'll never see. A named unknown gets revisited; a zero never does.

The line the old case never counted at all

The traditional case counted licenses and seats. It didn't count usage, and usage determines whether any of the rest of it happens. When I asked Jeff — my co-author on this piece, and the one of us who has actually stood these programmes up — what gets stewards into the tool, he didn't hedge:

The only thing that will guarantee stewards open the tool is making it an essential part of their daily activities.

Not training. Not a launch communication. Not an executive sponsor's enthusiasm, which has a half-life of about a quarter. Move their performance and reporting metrics so they run through the tool, and adoption spikes — an accurate reading of what anyone does with a system outside the work they're measured on. But you can mandate that a tool gets opened and still lose. Data stewards mostly have responsibilities beyond stewardship; they need to duck into the tool, respond to what the data needs, and get back out.

Email-driven workflow and FastApps fit that shape almost exactly, which is why the UI layer sits at the top of my list. Profisee supports the mechanics directly: stewardship can be shared, edited and collaborated on inside Outlook and Teams without leaving them [11]. The case I care about is a decision landing in a business owner's inbox — Approve, Reject, Pick, back to work. Two minutes, not a context switch into a system they use once a week and re-learn every time. Metrics that make the tool unavoidable, plus workflows short enough that being unavoidable isn't a punishment: that's the adoption plank, and the traditional model had no line for it.

A better number is still not a decision

Everything above improves a number, and for years I assumed a better number bought the decision. It doesn't. When I put the corrected-number version of this argument to Jeff, he wouldn't have it:

While there's always a number, I'll fight about the number ever being the only factor. It's always one of a bunch of factors, even if it's the 'leading' one.

He's right, and the correction is worth more than the arithmetic it corrects. There is always a number — I'm not making the opposite mistake and telling you money doesn't matter, which is equally wrong and more irritating to a CFO. The number is real, it's often the leading factor, and getting it wrong will sink you. It is still one input among several. Here are the others.

• Can this organisation staff and sustain the stewardship? Not "will it buy the licences" — will there be named people, with time protected by their managers, still adjudicating merges in year three. If not, a perfect TCO argues persuasively for a purchase that fails slowly.
• Does the sponsor survive? A reorganisation eats master data programmes early, because their benefits are diffuse and their costs are not. Ask who defends this line when the champion has a different job. If nobody, the number is decoration.
• What does the work displace? Money is one constraint; the same six people are another, and they'd otherwise be doing the ERP migration. A programme can be worth doing and still be the wrong thing this year — and no ROI model surfaces that.
• Does the money exist at all? The spreadsheets model the return and assume the capital. Plenty of organisations that would benefit don't have that budget that year, and a threshold you've been told is a hurdle rate is often a polite way of saying so. Thresholds encode capacity, mandate, risk appetite and what the money is already promised to; the dollar sign is the smallest thing about them.

Which is the honest reading of rejections that look irrational from the vendor's side of the table. A proposal needing a number an organisation could never write gets refused — but not because the digits were too big. It's refused because that organisation was never going to be the one to do that thing, at that size, in that year. The infeasibility is the reason; the number is only how it became visible. So do the arithmetic properly, then hand the committee the four questions it can't answer. A case that presents the money as the decision is doing what the demo did: showing a capability and calling it a fit.

The newest plank, and the honest version of it

There's an argument being added to every MDM business case right now, and for once the hype has a skeleton under it: governed master data is the foundation trustworthy AI needs. Gartner projects that through 2026 roughly 60% of AI projects will be abandoned if they aren't supported by AI-ready data [6]. Point a model at a customer base where the same customer exists five times under four spellings and it will answer confidently and wrong. Reconciling them is precisely the job master data does.

Since I've spent this piece demanding samples: that page states its own survey two ways, 248 data management leaders in the meta description and 1,203 in the rendered body [6]. The prediction is quoted exactly, the analyst and date right. The sample is a mess — and it's the number I'd most expect a room to swallow whole, which is why I checked.

The plank is real and I'd put it in the case. What I'd keep out is the leap from "AI needs governed data" to "the platform's AI will do the governing." Everything I said about Aisey applies to every embedded copilot here: it accelerates people who already know what right looks like. That's a productivity argument, not an autonomy one, and the two get conflated in every deck I have been handed this year.

Building the case now

Handing a colleague the beta rather than the theory:

• Run the demo against your data, not theirs, read the independent reviews including the bad ones, and show the provenance of every figure you quote. Those are the inputs nobody selling to you controls. David, who covers data quality here, would tell you to trust nothing you haven't measured yourself, and I'd hand him the microphone.
• Price the operation, not the purchase — emergency support and requirement drift as named unknowns, the licensing metric as a question answered in writing before signature.
• Make adoption a line item. Name the metric change that routes steward work through the tool. If nobody will sign up to move a metric, you have a capability purchase, not a program.
• Bring the four unpriced questions with the priced one. Who stewards this in year three, who defends it when the sponsor moves, what it displaces, and whether the money exists.

The move you can reach

The history of the MDM business case is the history of learning to price the right things. We started with the mess and the purchase, which got a lot of platforms bought and a fair number quietly abandoned. We're still learning to price the operation, the adoption and the Sunday night — and then to admit that pricing them correctly still doesn't decide anything. A modern platform can earn its keep, and on the three things I named it earns a good deal of mine — which is a claim about my implementations and my requirements, not a rating. Yours will land somewhere else, and the reviewers above will tell you where it might not land at all. What no platform will do is decide who owns "customer" or keep that agreement honest after go-live. That part is yours.

In climbing, the strongest move is the one you can reach — not the elegant sequence you admire on video and can't pull off on the wall. Nobody refuses that sequence because it's beautiful; they refuse it because their arms are the length they are, on that day, on that route. Business cases get refused the same way, and the number is how it shows up rather than why. So build the case your organisation can stand up, adopt and run — and put the number in it, honestly, as one of the several things the answer depends on.