Thank you, everybody for joining, part four of our, six part, life panel series on, selling MDM to leadership. So really not much in terms of master data management technology here much more about the organizational dynamics of how you kick off a program, how you justify the program.

And in today’s session, we’re gonna be talking about how you pick the right scope.

So We last week, we covered broadly speaking organizational readiness. How do you know if you’re ready to tackle an MDM project or your organization really is ready to tackle one?

Then getting into the justification, prioritization, and, project. We talked on Thursday about, total cost of ownership. There’s some of the things that drive total cost of ownership that are important to consider when you’re looking at the the ROI. And today, we’re gonna be talking about program scope.

We’ll get into that, obviously, in just a second. Tomorrow, we’re talking about evaluation pitfalls, which I think will be, interest to anybody who’s considering, selecting a master at management program or on a piece of software to fulfill the program, you’ll hear from some people who’ve been on the other side of the evaluations and where we start to see things going right or going wrong from an evaluation perspective. And then, on Thursday this week, we will talk about, how to get beyond the first use case and the value of going beyond the first MDM use case. One of the things that I think is kind of special about prophecies approach is that, we view the first domain as only as the first step in a series, and then we find that that’s where when you go beyond the first use cases where the value really starts to, to ramp up.

So interesting conversations for this week. And today is around program scope. How to establish quick wins and, select the right initial scope in order to to build the rep program. So, instead of last week, we had, people introduce themselves, and then I introduced them today.

I’m gonna ask, random people to, introduce somebody else. So Christopher, could you introduce Bill?

Just, so I’m pleased to be joined by, Bill O’ Caine again today.

Bill has been, part of prophecy now for just over a year. Prior to that, Bill was the lead analyst for Gartner around master data management.

He was a lead author on the Magic Quadrant for quite a few of his years there. He was a gardener for eight years.

Was also pivotal to creating the magic quadrant as we know it today. If you’ve been in this market for a while, you may recall these to be two quadrants. One MBM quadra for product, a different quadrant for a customer. And Bill was in charge of, formulating the combined MDM quadrant several years back.

In his time at Gartner, get Bill engaged with, around three thousand different organizations.

And really focused on how to make them successful with an MDM program, how to evaluate vendors. We’ve got tremendous experience in this space and we’re delighted to have him part of prophecy. His, MDM experience precedes Gartner.

He was pivotal in creating some of the early MDM technology.

Back in the day, the large, life insurance organization that went on to become, Pwl and eventually IBM MDM advanced edition. So, quite a long background in this space. We’re pleased to have his expertise.

Excellent, Chris.

Point out that that was all done without notes because I didn’t tell these guys I was gonna do this. Alright.

Harbor, can you introduce Christopher?

Christopher, absolutely.

He’s our VP of customer success.

He’s, part of a startup, a sound of a startup that was at the very beginning stages of what is, master data management. He’s also worked for some of our competitors, and we’re lucky to have, Christopher here at prophecy.

He has at least twenty plus more years of experience in this space. And I’m person, like to say, I don’t think there’s anyone that has a more innovative perspective on what MDM can do for enterprises and how MDM can transform enterprises at the at the highest level. The troops subject matter expert.

Excellent.

And then for symmetry, Bill, can you introduce Harbor?

Sure. Glad to do it.

Harbert Bernard, it runs the global value consulting team here at prophecy.

You’ve heard us mention a couple of times in here, something we call the business impact road map or be a BIR or beer, that’s the, latest and greatest incarnation of a framework that we have that, helps folks about zero in on the the valuable outcomes that they can get from MDM and order to pursue them in and how to get agreement that that’s what’s, gonna deliver that kind of benefits of him. And so in that role, he’s in he’s invaluable a lot of experience around this.

He’s very much a finance geek, which is a good thing in this role.

So Those of you that have heard a reference to beer, that’s that’s Harvard’s, baby, and he does a great job driving that through with a lot of our clients and prospects.

He’s he’s done similar things at other places on a consulting, unemployment basis. I’m gonna say going back at at least eight or ten years if not longer. And he’s certainly an expert in, the finance side and, the implementation side of by MDM.

Excellent. Thank you. And, I’m your moderator, VP product marketing Martin Boyd. So, we’ll just, take it from there. Thank you guys. Now, we’re going to here talk about, the program scope.

The the important thing to recognize around, you know, when you’re thinking about, over a program scope, not all data has the same value, not all data problems have the same impact. We’re gonna talk about different ways to kind of uncover where the most value is, and, Which ones are going to have the most, quick impact.

One of the things I think we all understand when we’re dealing with enterprise, implementations is that you need to these days, you can’t wait for two years for, an implementation because the world has moved on, by the time you get done. So you need to get quick wins and you need to start building what I call the enthusiasm flywheel. You know, the first step builds some of the enthusiasm and excitement. People start to get interested.

People start to want to be involved, and, you, you kind of build the program from there. And, as I mentioned, a moment earlier, One of the things that’s, special about prophecy is that it’s very easy to move from the first to the second to the third, domain, product data domain or rather, master data domain, and to first and second to third use case, these things build on each other. And what we typically see when things are going well, is that, other people in the organization start coming to you that who’ve now becoming a center of expertise, start, you know, asking to be part of it and see, could you do that with my data, etcetera?

But it’s important then it’s even more important than that you get the right first starting You don’t attempt to boil the ocean. You don’t do something that’s too obscure that no one really cares about. You have to do something that people care about. Yet is tractable and can deliver short term success.

So that’s really what we’re going to spend some time talking about here.

And, I guess because we’re we’re saying start small, we’ve got these, cute little dogs to help us along the way. Something to look at while we’re talking Alright. So, I’m gonna, ask Christopher to to lead off and talk a little bit about the whole idea of starting small and quick wins.

What might be easier use cases versus harder use cases and just some, you know, hard one experience and rules of thumb in in that area.

Excellent. Well, hey, thank you Martin. And I’ll certainly rely on my colleagues to chime in. You know, the the first thing is we’ve talked about this. You can see it in the title.

Is program scope. Right. One of the most important things when you’re talking about data management to your organization and to leaders is to make sure you’re setting the notion correctly that data management is a program. Right? It’s not like implementing a CRM where there’s a finite start and finish.

Taking on data management is going to be a a longer term program And even if you only do data management around a certain subset of data, there will be ongoing curation, ongoing work. So The first thing to understand is that, you know, this is not a project with the start and finish. You know, perhaps implementing a technology may have a a start and then a go live. But data management is a a living, breathing program within the organization.

So part of what we’ve talked about throughout this and we’ll continue to talk this week is making sure that the organization understands there is a a program that there’s ongoing effort to to managing your data which does mean you’ve gotta be able to show value in that effort. So that’s why this initial phase or initial scope becomes so important because If you don’t actually deliver something quickly that does have tangible value, the willingness of the organization to do that ongoing investment will start to fade out and diminish over time. So in my experience, I know Bill, in our conversations and your experience, We’ve seen several MDM initiatives, effectively wither on the vine, and it’s because they didn’t get the right scope and they didn’t tie it to some kind of business outcome.

So we talk about Start Small and, I have this vision of everybody on the the call today saying, alright, captain obvious. This is this is, everybody know if you’re supposed to start small. We’ve heard this over and over. It’s all about quick wins and agile approaches versus an old school waterfall approach.

But why are we talking about that again here?

It’s because with master data management, choosing the right scope is sometimes more difficult.

You’re talking about a flexible data management platform, not a discrete business application that performs a specific function. So choosing scope with an MDM program is quite a bit harder than some other technologies.

That’s particularly true when you have an MDM platform that is multi domain, you know, with a solution like prophecy or some of the other solutions on the market, You could start with customer or you could start with contact, or you could start with material, finished good, or facility, if the list goes on and on and on. So it’s it’s not always obvious to figure out where to start small. So we’re not gonna sit here today and preach to you about why you should start small. Because I think that’s just why you know we should be Whenever you take on any kind of technology initiative, you want to start small and build incrementally. Our focus today is gonna be what are some of the nuances to choosing the right scope for starting an MBM. So that’ll that’ll be kind of the the key part of the conversation, across the the different subjects we’ve got. Lined up for you today.

The first biggest thing that is critical is the the slide that Martin brought up before it’s important that you and your organization understand and can agree that not all data has the same value. Right? I get really nervous when I engage with organizations and they say, Hey, we need to clean up our data. It’s it’s a big mess. And they say, well, what maybe do you need to clean up? And they say, all of it. It’s a mess everywhere.

Well, and again, Some data that is is messy may have impacts on the organization that are minor grievances. Other data could have a critical impact. Right? So the first thing to understand and to make sure that leadership understands is not all data, within an organization has the same value or data discrepancies data issues, data problems, may or may not have different levels of impact.

So you’ve gotta make sure that you’re thinking about where can I find scope that is doable within a reasonable time frame where there is actually some kind of tangible impact? You’re not taking on the the cleansing and stewardship of data for the sake of data. It’s gotta be for the sake of some kind of a and we probably are starting to sound like a broken wheel in that regard. And we’ll talk a little bit about how to figure that out.

One of the other notions that I’ve seen is organizations like, hey, if I go live, if we go through phase one and we get to production and we’ve got data stewards, we can say we’re successful.

That’s not necessarily the case. Right? Just be able to stand up a technology and have some users in it, as I said, those kinds of initiatives, if you can’t tie that effort and the ongoing stewardship and data curation to some kind of business outcome, Those tend to wither on the vine. And in the long run, those projects are not deemed successful.

Right. So successful is not go live. Successful is a sustained program. Or data management and the value of data is taken seriously, not just by the the technology side of the organization, but by the entire organization.

Hey, Chris.

I was just gonna ask when you talk about, quick wins, what what kind of time frame do you think that would be? Is that weeks, months, I mean, what would you really have done for that?

The you want it’s it’s a competing set of priorities. You want the shortest runway possible to something that’s real. So you can’t do something that if, you know, if you say the mandate is six weeks, but within six weeks, I can’t show any real results, you’re probably gonna have to take on more skill.

You know, what I’ve seen is many organizations are able to find something tangible If they’re clever about thinking about the the data issues and ways to slice and dice the program, many organizations can find something where they’re tangibly successful within ten to twelve weeks. You know, I think that’s the sweet spot. I’ve seen a few use cases where it’s a little bit shorter. I’ve seen some use cases where it’s longer.

I start to get seriously nervous when you start getting to twenty six weeks. Right? You start to get to two quarters or more before you’re able to show any tangible results I think there’s probably some risk there. And you should rethink, Hey, how can we slice this apart a little further and decompose the problem a little further?

To still show value by choking that time frame. Excellent. Because the because we’re talking about data management general, you know, the the process for doing that is gonna be unique to every organization. So we’ll give you some input and insights on things to consider.

But it’s gonna be unique to your organization about how can you rightsize this initial project to deliver something? Alright. Let let’s get some other folks, talking to Bill. Can you talk a little bit about what types of projects? They’re usually the ones where you where you can, find the right trade off between, quick wins and, sufficient value to to be to matter.

Sure.

I I got a couple things here. One is, I’ll just go back to something Christopher pointed out about program versus project.

You know, one of the thing one of the rules of thumbs I gave a lot of people I interacted with over the years was, because I would often get the question. How long is this gonna me? When will it be over? Not just when can I deliver value, but when can I stop? When can I send all these consultants home when when, you know, I’m trying to budget, and I finally got frustrated at at one point and said, I want and it became a rule of thumb? Every time you think about doing something, whether it’s initiating, expanding, whatever it is justifying, your data management project, want you to ask yourself if you would do the same thing to pre to your procurement department because that’s how persistent this is gonna be. The if this is successful will last as long as your procurement function lasts, which is probably as long as you last as as an organization.

So, again, take it as seriously as you take that. If you’re thinking of offshoring something, ask yourself if you would offshore that, you know, the corresponding part of your procurement function. If the culture says no, you know, think about it, because there are some pretty good analogs there.

In terms of, you know, quick wins, I would also say, and I’ll use these two things as sort of a jumping off point. It it varies, but Christopher touched on this a little bit there at the end. It it varies by culture. I worked in a lot of different industries, and I could almost tell you within an industry, you know, what’s the tolerance, for example, for overpromising and underdelivering versus underpromising, and being a little underwhelming. If you work in health care, that’s a completely different scenario than if you work in financial services.

I spent part of my time as a professional program manager, a project manager, when I would start a new engagement or a new job, the first thing I would do is find somebody who knew and say, what what’s the what’s the big sin here? Is it being late Is it spending too much money? Is it being underwhelming in terms of functionality you deliver? What is it that’s gonna make us successful here or make us a failure?

You know, there there are big banks where if you’re a week late on your project plan, it doesn’t matter that you’re, you know, fifty thousand dollars away from transforming the entire company. They’ll stop you in your tracks. So, again, quick win is also, affected by that.

And, you know, we we’re gonna talk a little bit maybe a definitions in order of the analytical versus operational. And there are some tendencies that people think are obvious, and as Christopher, has said many times very insightfully, it’s not obvious. It’s not always the thing that seems the easiest that will be the easiest. And hence our business impact roadmap, as a technique to uncover that.

And so I’m I’ll I’ll just take a second and give you the the the book definitions and then sort of the real implications, which we’ll get to a little later as well. On the technical side. Analytical MDM is exactly what it sounds like. It’s MDM solely or mostly in the service of analytics.

So you’re trying to get your data your master data cleaned up for your analytics platforms. Your data warehouses, your data marts, virtual or physical, However, however, that tends to work out structurally.

That’s what it is.

And, you know, there are ways to do that. Sometimes, it don’t involve MDM software.

If you don’t need real time processing, if you never intend to go beyond that first use case, which is a not a good thing, but it it could be deliberate. We’ll talk about that on Thursday. It might not be so important to you But, in particular, again, I’ll I’ll I’ll do prophecy sworn just a little that at our our TCO and price point, it becomes actually cost effective to use a tool like prophecy solely for analytical MDM.

Again, it used to blow up my argument about, you know, whether MDM software is worth it. At our price point. Operation MDM is is also sort of what it sounds like. It’s a little bit broader. It’s MDM in service of business operations directly. So the most blatant example of it is, you’re sitting there with your MDM hub and surrounded by an enterprise service bus, that’s having to talk to all the business applications in real time and you’re doing, check for duplicates before it creates, which we’ll get into at some point later.

But there there there are more nuanced versions of it. So for example, most people, when you say operational MDM, think real time or near real time, whether it’s Pubsub asynchronous or, synchronous request response, they think, you know, oh, I’m sitting there. I’m getting stuff back right away. Probably a record at a time.

That that may that’s most of the time. That’s true. There’s an affinity there. That’s prob you’re probably gonna be correct most of the time, but there are cases of batch oriented operational MDM. In real time oriented analytical Indian. So you should never think, you know, I’m I’m actually doing this. So I I have to change everything if I go to do this.

That that’s almost never the case. So the, you know, there there’s the usual situations which cover eighty, eighty, eighty five percent of the time. But don’t think of them as empirical because you will see exceptions, I I can guarantee it, and mixtures, hybrids of the two. So, again, you know, analytical has implications. It’s probably gonna be batch. It’s probably not gonna be the system of record as MDM. The opposite’s true for operational, but there are sort of middle grounds that people gray areas that can be covered as well.

And we’ll get to those on a technical basis in a few minutes. So Sorry. Go ahead.

I was gonna say, you know, the Christopher’s twelve week benchmark, I think, is is pretty accurate.

But again, and he and he did touch on this. You you have to know your surroundings.

You know, is it okay to I’ll go back to that kind of obvious captain obvious example. I’m two weeks away from finishing, but my plans that I’d be done today, what’s that gonna do to me in this organization?

Should I plan ahead so that doesn’t happen, or should I just spend most of my time making sure the solution will work, if and when I get get in there sometime around when I said I would. That’s that that can be a big differentiator in a lot of organizations.

I worked on a lot of farmers in health care, and they have a big tolerance for, the IT the IT framework tends to mirror the product framework. In that there’s a lot of tolerance for deviation and exploration, and things like that in finance, Again, it kind of mirrors the business culture where you better be done when you said to be done and don’t spend any more than you said you would.

Otherwise, you’re gonna be in a lot of trouble. I I was just gonna ask Harvard a a question, but it looks like he’s dropped Harvard. If you’re there, just let me know if you’re not. I’m still here. I’m I’ve lost my internet connection, thanks to the cable provider, but I still have my cell phone connection.

Okay.

So I’ll I’ll So the the question I was about to ask you then if you’re if you’re able to answer is, when, because you’re you’re often wrestling with, program scope and looking at the the ROI.

How often does the program scope that someone comes to the table with end up being the one that they they actually start with? Do they tend to pick something completely different having done the, the full analysis with you, or do they, you know, expand it or contract it having gone through that procession? What just as a, you know, normal experience, what do you Very rarely does the initial program scope, remain Once you go through the analytical process to find out, you know, where you’re gonna get through quick wins and where where you’re gonna have the the the best use cases usually the program scope changes, and we’ve even had multiple instances where someone has started with one domain, realized values, and another domain and switch the the focus and prioritization of that use case.

Also, you know, a lot of value comes with multi domains and bringing in reference data, attributes, and things like that. So, once you look at it that from that perspective, scope does change regularly. Yeah.

Okay. I think that’s not That’s probably an interesting learning for everybody then that, the the gut feel as to why you think you’re gonna get started on this May after analysis is most often isn’t, what you start with. They’re for the analysis is important.

Back to, you you need to start with the end in mind. Right? That there’s two large mistaken notions that I encounter in the market over and over and over. And the first one is, hey, I can I’ll select my program scope based upon analytical versus operational bills explaining. And typically, the what I experience organizations say, Hey, we’re gonna start analytical and we’re gonna go operational.

The misperception is that analytical always be easier.

Reality is there’s sometimes operational solutions where it’s centrally managing the process for onboarding suppliers that could have a much higher, impact in a relatively low complexity.

So you you can’t just say, Hey, the way I’m gonna figure out my scope is choose between analytical and operational and word on the street is analytic.

Don’t make that assumption. The other thing that Harvard touched on that I think is super important is the other big mistake I see is people say, well, I’ve selected a a starting domain and therefore, I define my scope. You know, and we’re gonna start with customer, you know, b to b customer. We’re gonna start with vendor. And they say that they think that, okay, I’m done. You have to find my scope. You really need to get more fine grained than that.

And decide, hey, which systems should be participating? Do I actually want to even manage all customers or a segment of customers? You know, with what are the data sources? There might be ten data sources that have customer data, but in order to deliver value, How many of them do I actually need to bring together?

Maybe it’s just two or three. So, you know, the the two big mistakes I see is people say, well, I’ve chosen analytical versus operational. Therefore, I’ve I’ve limited my scope, and that’s never enough. Or they say I’ve chosen a domain.

Therefore, I’ve right sides of my scope. And generally, that’s never enough either. So you really do need to dig in deeper, which brings us back to the business impact roadmap. In order to make those choices, you must have done some analysis to figure out, where are the data problems that deserve to be fixed first?

Yep.

Thank you. So, in the interest of time, let’s pivot to the next topic, which is actually taking some of the same construct of analytical versus operational and going down to the next level. So I’m gonna have a bill lead off on this. So, buckle up everybody. This is the Gartner analyst.

Talking about, implementation styles.

Excellent. Is that me in the hat? Yeah.

You you decide.

Okay. So, we’re gonna get a a a little bit architectural and technical here, but, this usually, is something Everybody finds pretty pretty helpful. I had two sort of, life changing conversations with a couple of prospects of prophecy last week that really, took took this to heart. I always assume people know this. It it’s a concept that Gardner has fostered.

Other people have different versions of this on say there are three. Some people say there are five.

Some people wanna count hybrid, which we can pretty much do away with as as the coexistence style.

I won’t take a ton of time on this.

You know, if anybody wants to follow-up, I’ll be more than happy to support that.

These are the four physical implementation styles. Some people call them integration patterns or integration styles, that MDM programs and solutions generally support.

First thing, then, much like Christopher, I’m gonna try to dispel a myth here, that you pick one and go for it. And that’s that’s the beginning and end of the story, and you’ve got your scope.

The other one is that, it has to be the same for every every outcome you tackle, every domain within the outcome, and it and it won’t change along that access either. That’s not true. And you’ll see that that’s that sort of blurb across the bottom. It’s okay to have in order to achieve an outcome, to have consolidated style customer data, and centralized style product data at the same time, or vice versa. And it’s okay. And it will well, I’ll spend little bit of the rest of the time talking about it is that sort of progression, between styles for, let’s say, a single outcome or a single domain or domains to support that outcome.

And again, to to really hammer on what Christopher said there, Someone saying they need to clean up their customer data to in my ears is the same as saying I need to clean up all my data, in terms of risk and and and lack of definition and things like that. And Again, what that’s what we’re we’re really looking to help with over these two weeks is better definition of the objectives.

And then, you know, right sizing for them and prioritizing them. In general, the two styles on the left have an affinity to. And, again, it’s not a it’s not a hundred percent. There’s an affinity to the analytical MDM use case.

Registry doesn’t get used that much anymore outside of health care where they still like it because what registry basically is is pointing to all your source data, but not storing copies of it. And that’s appealing to a lot of people with sensitive data because all they have to do is really point to where it’s located, and wherever that is is responsible.

For the security and and privacy of it.

Used to be very popular even outside of health care, it’s it’s lost it’s luster in the last decade, I would say, at least, for a couple of reasons, the the main one being you don’t ever really get good governance this way. It’s it’s it’s hard to for some reason, there’s there’s a difference when in the consolidated style, you say, I’m gonna start storing what I think the best email address is, and it’s not yours source system a owner. That tends to get people’s attention. You don’t have the best email address, so I’m not storing it is the best.

That’s different to them than saying, I’m just gonna point to it. In fact, I’m gonna point to all of them, and the consuming application can figure out what the best one every time it needs to use it. So you can see why, you know, this might be less popular in a more automated MDM scenario. Consolidated is sort of the the analytical scenario we described earlier, think of an ODS for a data warehouse that only stores master data, and you’re gonna be very close to is, in fact, there are many MDM hubs that function as ODSs for data warehouses, among other things. Again, usually, that sort of next use case, the full value use case tends to be on the right side where we start we trust it so much that we start letting our applications integrate with it real time, whether it’s read only or read write.

And, hence, the two on the right side tend to have an affinity with what we’ve referred to as operation MDM. They tend to be more, live wired to your to your operations, your source systems, your admin systems. They still, again, will feed generally a data warehouse, And just moving from these doesn’t mean you leave. They they tend to be cumulative in a way. They you don’t leave consolidation style use cases behind because you move to coexistence.

And, again, many for I’m gonna I’ll pick a domain. For B2C customer data, you know, the consolidated styles vary just start with. We we talked about this earlier, but not always.

And for things like product data or b to b customer or supplier that tend to have business processes supporting those functions already.

If not optimal automation, they tend to start in centralized. You know, I’m just gonna load all the data in there, get control of it. And in a way, you can think of those things centralized and consolidated sort of as polar opposites. In the consolidated style, you’re kind of admitting at least for now that you’re not gonna get control of the entry of that data.

It’s always gonna happen in those business apps. They’re not gonna have the data quality functions we need or the data integration functions we need. So we’re gonna do it in batch, and we’re not gonna write anything back to them. That’s One of the things that differentiates consolidation style is it doesn’t write back to the source system source systems. In fact, the only updating it really does it is, matching and merging internally to itself. All the other interactions tend to be downstream, and that’s why the arrows look like that.

Coexistence starts to get a little mixed where some attributes, MDM is a system of record for, and and can write back to source systems, you know, and centralizes really when it’s doing it for all the master data in the domain. But in terms of quick wins, this is this is a way to look at it.

I wrote a paper years back at Gartner on how to use these in that way as sort of a a palette, if you will, buy outcome. Boy, what what do I need? What’s the lease in basic thing I can do.

So on the consolidation side, what makes that appealing is I’m not really asking into my source systems to change.

You know, I’m sitting downstream from them. I’m very non invasive, but I’m still able to implement all my data quality and business rules. I’m able to see how the performance is going.

For batch if if nothing else, is this software what I thought it would be, all of that? Is my matching getting me to what I think is a hundred percent data quality, or do I see a way to get there? So, again, you’re not really tying yourself integrating tightly with those operational sources. So you’re not in a sense putting the business at risk. In the coexistence and centralized styles, in the coexistence style, you really are because you’re those systems are really talking bi directionally to each other, and you have to know your stuff to get there. You know, your your semantic model’s gotta be good, and we’ll get back to that.

In a bit, but, you know, so that’s how that has to work. And centralized, it actually is a little bit safer because generally what this is used for is, I always use the example of new product introduction for manufacturing. Right? You probably have a lot of systems and processes that handle building designing and building and pricing and selling new products or distributing them.

But there’s probably a lot of slack between the nodes of that process. And often, product MDM is brought in or the product domain is brought in to, just reduce that slack. Manage the handover. In a sense, it’s a BPM operation for product data.

And so, again, you can see that’s the sort of polar opposite of trying to gather B2C customer data. But those two things are often, orchestrated together at one time. So, again, you know, happy to dig into these more in in another session with it. If anybody would like, I do this with clients and prospects frequently. This is the palette you’re looking at is, you know, you’re going left to right. It’s less invasive, less invasive, getting more invasive, in terms of having the source systems, pieces of them having to be aware that MDM exists or not.

The integration from left to right tends to go from batch to real time, that’s not a hundred percent academic, concept. You’re going from being just a downstream system of reference often to being a system of record for some or all of your master data attributes. And again, there is, excuse me, an affinity between the top the the ones on the left and analytics and the ones on the right in direct operations.

Within this, I wanna make the point Christopher touched on earlier about not when we say not doing whole domains. What does that mean we should do?

I’m a big believer in, you know, it takes multiple domains to solve just about any real business outcome. That little blue drum in the middle should only contain the master data attributes you need to service the outcomes you’ve you’ve identified. You can always add more attributes later for your next internal release for your next outcome for your next business use case.

That’s one of the pitfalls is that the things to watch out for is that scope just to bigger than you need.

And again, you know, I I love I I said during a session last week, I believe in consulting, but you have to be careful.

Everybody here I bet has seen a consulting consulting statement of work that says, I wanna come in in inventory all your data.

Every single source system wanna do a profile. We’re gonna figure out where the problems are.

If you’ve been listening last week, you know that that is antithetical to everything we’ve been saying.

You’d be better off pointing them at your future state instead of your current state and say, you tell us what we should be, doing based on what our competitors do or what the potential is. So, again, that data model should be pretty narrow, especially for the first deliverable. If you’ve got something out there with, you know, two, three, four hundred attributes, it’s time to take a pause, because the idea that you’re gonna need all that to deliver value in twelve weeks to use Christopher’s guardrail.

It’s just, you know, nonsensical.

Yeah.

But there’s been a few questions coming in and thank you everybody for for doing that in a frame feel free to keep on, dropping in the questions.

Hopefully everybody is seeing that this, framework here is a good way of having a conversation about how you’re going to implement and exactly where you’re gonna implement and how it’ll impact scope because you know, a one way, sync of data as opposed to a bidirectional is is a very different thing from a scope and technology perspective. So couple of questions just to sweep up.

There is no real right or wrong, and and where to start.

But this is a good conversations for, are we gonna pick? And it is absolutely possible. In fact, it’s expected that you would evolve from one style to another as implementation, progresses, and that you could have different styles going on in different domains for different use cases. So, hopefully, that clarifies a little bit.

Question, Bill, let you pick this up. Is virtual MDM registry style? I’m not sure. Yes.

Yes. Okay.

That’ll be my shortest answer for the two weeks.

Never mind. Every time I’ve seen it use the answer every time I’ve seen it use the answer, would be. Yes. Okay.

And I just don’t really see it in in the real world. Right? Because the challenge you’ve got there is I’ve got pointers to every copy of this customer or this contact, but there’s no way to know which which of those systems has the right email with the most up to date email. We’re putting stuff in the address.

And so I just think pretty fast. I think the original vision for this as a style was I’m gonna build a set of centralized services that know that.

That actually, you know, and Are you offering it? And back to real life, every time I’ve seen that tried, that is a very noble goal, but every time I’ve seen it tried, eventually someone would come back and say, this was it was some statement like this. We’ve now decided to let the consuming applications house the business logic. What that means is we just punted. We’re not gonna try to build those services you’re all gonna and at that point, you’re doing a data integration project. It’s not even an MDM program anymore.

And I would say the one other thing I would say, not I hope this is confusing. I usually leave it out, but the other three styles besides registry all usually contain registries.

You know, so you may have consolidated customer hub, but it’s gonna contain pointers to the products or services that customer used in whatever other system of record they have. Most real implementations have cross references to other domains wherever those domains may lie, So when we say registry here, we mean pure registry with nothing else in it. In a sense, you could say, consolidated style is registry where there are tables where the decisions have been made what the best email address is, and it’s been stored. And again, just a put just a a an anecdotal thing, I don’t know why, but the minute you progress to storing best copies of attributes, people that own the source data pay more attention. In terms of governance.

I don’t know why. Yeah. I think I think of it as these first three registry consolidated coexistence.

We’re kind of building on each other. You’re adding more MBM capability to support a slightly more sophisticated solution. So registry is just bare bones, use some kind of fuzzy matching to develop pointers, consolidated as, hey, now let’s take data from the systems and decide what constitutes the best copy attribute by attribute coexistence is, hey, now let’s take that and start sharing that vast data back out to our operational system. So those kind of three, if you think of like a a slim consolidating is probably the closest thing there is to register out there in the real world, but then additional systems and attributes might get added in as the next step. And then eventually you might start sharing that data back out to system.