Transcript:
Chris Detzel (00:00):
For those that don't know me, my name is Chris Detzel and I'm the Director of Customer Community and Engagement. And we have part two in the series of How to Build an MDM Practice from Ground Up with Chris Ilof. So today, a lot of this will be, hopefully, more of a discussion than a presentation. And the reason I say that is because we're going to have a lot of master data management practitioners on the phone. So the goal really is to have you kind of speak up as Chris presents some stuff, but we do definitely want this to be more of a discussion rather than just presentation. So we're looking forward to that.
So the rules of the show, and it's just general, is please keep yourself on mute. You can ask questions or pipe up by taking yourself off mute and/or pushing it out into the chat. This show is being recorded and will be posted, like all the shows, to the community. We do have some really good shows coming up in addition to this one. We have some deep dives into the Reltio UI configurations self-service. On the 19th, we're going to have, it's more of a, I guess I can call it thought leadership or a little bit different. We might be focused on Reltio, but it is a topic around natural language processing, text representations in master data management. And on the 22nd, we'll have a Q&A between our leader in product launch and then also another leader within our product teams. His name is, and you guys have seen him before, is [Ion 00:01:49] on moving data in and out of the Reltio.
Chris Ilof (02:39):
Yeah. So as Mr Detzel said, this is intended to be a series and it's a series that is more of a conversation than it is a lecture. So your participation is very, very welcome and appreciated. So Alex, I see we got a question from you on a link. So just to address that real quick. While this is part two, some of you were in attendance during the first one and we did get interrupted by an unfortunate life situation that I had happen at the time. So we'll get through and we'll kind of just breeze through a bit of the first part of this, but Alex, you'll get the deck here. You'll be able to see it and work through it and we're happy to have any conversations you want on any of the details and share experiences that you might have and answer questions you might have about some of the detail that we'll gloss over in the beginning here.
As Mr. Detzel mentioned these topics, this isn't going to be holistic. We're going to hover pretty high level here and we'll just talk through some of the experiences we have as we build an MDM practice where some of the challenges are and get some of your feedback and understand your experiences and challenges. So it'll be a great conversation if you're open to sharing that, we appreciate it. And you'll see more in this series kind of pop up where we'll talk about technology aspects of it as well as build on some of the practice of MDM and what it means to do that in a little more detail as we go along here in this series.
So welcome to the new folks. Thank you for the folks that are rejoining from a couple weeks ago and apologies for that. For those that joined a couple weeks ago, yep, my wife is absolutely fine. Just a little bit of an accident, couple stitches, short trip to the ER, and we're all good. So just be careful when you're doing Pilates. With that, when we discussed last time we talked about really the phases of the MDM practice life cycle and these are obviously pretty high level, right? For those of us in the room that have been in parts of this life cycle maybe from the inception to the implementation and through the continuous evolution. We've had a lot of experiences here, haven't we? I know I have. So we started the conversation there and where we left off was really more around the continuous evolution.
And as we're starting to get there, we had some great conversation around implementation, how important it is to really the key for that to be a focus on building a practice and not another IT system, right. And one are the challenges there, one of the keys to success, a big and strong focus on what gets referred to as business readiness still in a lot of cases as we execute projects and things like that, that we all know far to often can get deprioritized, I guess, would be a polite way to put it. But in the case of working through your implementation or even future implementations as you progress to evolve your MDM practice, how important it is to obtain and manage and curate relationships, relationships with your key data stakeholders.
So data providers, data consumers, folks in your data governance areas, data stewards, folks in IT across the data management spectrum that are supporting the overall data life cycle or the data supply chain, if you will, and how important that is. So we touched on that pretty heavily. Prior to that we talked about the inception about how these things come through and for most of us, we talked about how weren't really necessarily involved in the strategy that defined MDM as a necessity to support other outcomes and objectives that oftentimes we're on the receiving end of we're going to kick off this thing. We're going to build this awesome practice called MDM. And that's where we get involved and get started. A very important aspect of it that we were starting to spend some more time on here and really got some great alignment on towards the end of that is how what we perceive here is really there's this lag that is mostly around the perception of value and how important that is in really driving your ability to constantly evolve.
So to reach that next phase. And we see that as we implement, we can see here inception through implementation, there's a broader understanding because the teams tend to be smaller and there's a focus here from a smaller set of stakeholders, if you will, that truly understand kind of how what MDM is going to do and how it is connected to the broader outcomes. But as we move along through the project implementation and when we focus purely on kind of building an app or creating a technology solution and when we have that more myopic focus, we lose that. The teams expand that need to be involved in the project, we have large cross-functional teams, and the alignment to that overall business value, the outcome that you're going to deliver for your organization, starts to get a little watered down and lost.
And as we lose that perspective, it becomes much more difficult at the point in time of implementation to really get ramped up and get that what is key really, investment. And this is where you've got initial investment. The understanding of what MDM really is doing for the organization kind of falls off, gets a little washed out. And then we have here that it's a few key people mostly in the data management centers and in your teams and the MDM teams and such that really, truly understand and continue to understand the value, but it's really difficult to actually bridge that gap of what's something that is essentially I think that the metaphor that I like to use is plumbing or electricity, right?
And as with plumbing and electricity, it's under the walls, it's in the floors, it's in the ceilings, and you don't see it, but our customers are internal customers. When they flip the light switch, they expect the light to come on. Right. And we can talk all day about how the electricity works and it's kind of jargon to them and mumble to them. Connecting that to how the light switch works is not a very easy thing, right. But is a root cause to a lot of the frustration we feel as we try to grow our MDM practices, as we try to evolve them. And this is what this graph kind of represents is what we see and we've seen it here at Reltio in working with our customers, many of you and many others. I've seen it in my own experiences. And we talked last time about some of the experiences folks had here that are very similar coming out of implementation and struggling for a little bit to build that broader understanding, build those partnerships across the key stakeholders, and that's what's kind of taking place here at this timeframe. Right?
And that when we think about a more practice focus, building a practice, not a technology, we focus on maintaining those relationships and a consistent understanding of not just what MDM is doing in this project really, but what the plans are, what the roadmap is and how it can continue to evolve to add value across the organization. And when you have that alignment across those stakeholders, you don't really get these lulls here and these challenges of trying to get back up to where you can evolve and do all the wonderful things you want to do with new sources and additional consumers, different integrations, all of that kind of great work that we want to do. That actually costs money and we need funding to do.
So I know we've got some new folks, but this is really a great place for us to start. We've got some time today to get through the discussion. So for those that are whichever place you are kind of in this life cycle from inception, implementation, continuous evolution, based on the experiences I've just shared with you, some that I know that I've talked to our customers again about and some that I've had even myself in building an MDM practice at Blue Cross Blue Shield of Michigan. Anyone care to share some of their stories and their feelings on how they've lived this and they've seen this progress?
No. Quiet group. All right. Well let's talk about then the evolution and that cross-functional alignment that I just spoke to. So more along those lines. The evolution that we're talking about really are if you think about it, whether you have it documented, you have kind of your own roadmap or you're just excited about the master data management space and you want to make sure that your organization is taking full advantage of it and doing all the wonderful things that it can do and provide value to your organization. You're doing all that at the same time that you're maintaining and supporting it. Keeping the lights on, there's kind of a DevOps perspective to it. There's active stewardship, whether that is you or your team.
People are actually working the data. You're working the potential matches. You're working through issues and source systems at times to get that back and that can all be very complicated if you've not built kind of the practice and the expectation upfront of what that looks like. But the keys here that I've seen in cases that really get to be kind of frustrating and can draw that evolution out and make it complex and more difficult than it should be, the expanding and enriching. Right. So adding new data sources. Yeah. And that could be sometimes adding new data sources to your existing domain. I've got additional domains listed here too because the objective is that we all want to do more than we're doing right now with MDM and we know there's these other data domains that can be really valuable to our organizations.
Right. And we do that through adding either new domains, but then we expand and we enrich existing domains, right. So you're bringing in other data from systems one, just to expand your understanding, to gain that kind of registry understanding and lineage between source systems and then your master profile. You're enriching that with data sources that are purchased. Maybe you're doing Dun & Bradstreet or you've got Axiom data or other pieces of data that are purchased that are known as industry sources of truth and you're pulling data from that to gain new insights. So you're extending kind of the number of attributes that you're attaching to that master profile. And then you're extending integration, right? The key here is you're building all this great data, right? You're building this clean source of truth for the organization and you want to share it with as many business partners within your organization as you can.
And all of these things are pretty complex when you have to create those new relationships as you're going. It's kind of a reiteration of everything you should be going through at each one of these points within the life cycle. Everything that you went through or should have gone through in the implementation, it's taking those lessons learned, applying some of these keys to success, right. So before we get into the keys to success, anybody have any of the pitfalls or any successes they want to share around how you've been able and what it took for you to expand and enrich or extend what your MDM practice is doing within your organization?
Don't shy.
Chris Detzel (15:24):
Chris, do you think that when connecting new data, so let's say you do the implementation and over time you want to connect other data sources and things like that. When you think of the owners of those data sources, what kind of relationship do you have to build with them and how do they kind of manage those things together? I would assume that you don't just, "Hey, look. Let me connect this data," and then all the sudden we get a 360 view of the customer or whatever, right?
Chris Ilof (15:57):
Yeah.
Chris Detzel (15:58):
I don't know if that makes sense.
Chris Ilof (15:59):
Exactly. The keys here that, and we'll talk to it from that data stakeholder alignment and that's really what's meant there, Chris, so great question. So you've got a new provider or consumer of data that we want to start working with and it's the next release of MDM or it's another project that's kicking off that's working with it is how that often works. And a lot of times what we see here is that it's really the IT teams, right? The teams that are in charge of moving data from one point to the other that are considered kind of the stakeholders and owners of the work that's going on there. And far too often the business application owner or the person on the side that is kind of the Smee of the business data side of it, isn't all that included because it's really just considered a, "Well we're going to move the data through MDM and we're going to extend the profile of member, customer, partner, vendor," whichever thing you're mastering.
And far too often those people on the business side aren't included in that conversation. They have no idea what master data management is and further along down the line, how we see that impactful a lot of times is inactive stewardship. It's if and when data inconsistencies or data quality issues at the source of truth in the business app space or whichever data source tier in that case is when they're creating data that is impactful to other parts of the organization or other consumers, it's a real challenge to work through data quality resolution, right? And that's where having those stakeholders involved up front gives you one, an opportunity to develop those clear roles and responsibilities around DQ resolution, but it gives you the opportunity to really give your business focused pitch.
We should see data stakeholder alignment as an opportunity for you to create more champions within your organization for MDM. And it's incredibly important that you have that and that you curate and you manage those relationships because as many of you have experienced, if you haven't done MDM before, it's not an easy thing to understand. It's not something you just kind of read about and come to and you get it. So you think about before you ever knew anything about MDM and these key data stakeholders, that's the position they're in. And it's extremely advantageous, especially in the business side, that you take advantage of all those opportunities to build champions. To build an understanding of what MDM is doing for the organization more broadly that business focused pitch that we'll talk about in a little more detail here in a moment with those individual stakeholders and they can evangelize master data management, really make expansion of your MDM practice because they are part of your MDM practice, right? And we'll get to that in a future session as well.
But bringing them in, building that MDM practice includes the stakeholder alignment, includes relationships that are with those stakeholders so that they can be your coaches and to the business and champions for MDM going forward.
Chris Detzel (19:27):
One of the things that I've heard in the past a chief data officer said, "The key to pitching master data management is not to talk about master data management to the business specifically," and it's more about talking about the business outcomes that master data management can solve. These are the things that we can kind of solve. Here's your problem, A, B, C, and D. And that's what we can kind of go do. I'd be interested to hear from others about their pitch and how they might pitch it to stakeholders if it's not specifically IT or they know about master data management. Does anybody want to kind of share their pitch? Seems like kind of a hard thing to kind of do, right?
Chris Ilof (20:20):
Yeah. It definitely is. So this is kind of that perspective of like when I say pitch it and put it here, it's like the elevator pitch.
Chris Detzel (20:26):
Yeah.
Chris Ilof (20:27):
So you get on the elevator with the director in marketing or VP in the marketing team and you've known this person, you've known her for a while now. You're definitely friendly. And she asked what you're doing now over in IT and you're, "We built this master data management thing." And she says, "Well, tell me more about that. I'm not familiar. What is master data management?" Anybody have that kind of experience and how did you answer that question, what is master data management? Anybody want to share that.
Chris Detzel (21:02):
It's a quiet group today.
Chris Ilof (21:07):
Yeah. Holiday, post holiday.
Chris Detzel (21:13):
Yeah. Exactly. [crosstalk 00:21:13]
Chris Ilof (21:13):
Yeah. I know in my own experience, it was something that took me a while to learn myself and had to learn the hard way. And because I couldn't have those conversations with those type of leaders, it was really, really hard for me to create those champions and those support networks in the business so that they fully understand the value of MDM. And it's because I grew up in my career through being a developer and I'm a technical guy up to that point. And to me, I was speaking to MDMs as an application, piece of technology, a technical tool. And I would go immediately and do, "Oh, well, we aggregate disparate sources of information and perform some complex algorithms to unify the data and create a master profile of our members." And the minute I said disparate data, people lose you right then.
Chris Detzel (22:16):
You lost them. You're like-
Chris Ilof (22:16):
Yeah.
Chris Detzel (22:16):
Then you're like, "Plays over."
Chris Ilof (22:19):
Yeah. Isolates over and you do, you lose them because what they don't understand from that is what it's it doing for them? So in your business focus pitch, you're going to probably have several of these. It's important to explain only from the business perspective, what is it doing? What are the outcomes that you're creating? And spend more attention on the outcomes that you're generating for the business and less attention on how the thing works. Right?
Chris Detzel (22:48):
Yeah. The last thing I'll say kind of about this is there's an interesting post that I posted back in March of this year about what is master data management. And I posted that here in the chat. So I would love to kind of get the group's input, thoughts around kind of this post. So we had three or four other of our community folks kind of post what they think it is too. So feel free to reply to that or even speak up today.
Chris Ilof (23:19):
Yeah. Absolutely. And if you're not comfortable with speaking up over the mic, feel free to hit the chat on what your pitch is today around master data management and what it is. It's probably going to be a session we can do in the future too, Chris to hone in on that, right? And-
Chris Detzel (23:39):
And putting people on the spot is probably not ... the pitch is tough, man. I mean-
Chris Ilof (23:44):
It's tough. It's tough. It's very, very tough. So these are some of the keys to success, but let's get into the pitfalls here because this is, to me, this cross-functional alignment, again, how does it represent itself? Well, we come back to here. It's really about driving continued investment. You can't do what you want to do to evolve your MDM practice, to do all the wonderful technology things you want to do to get the data in and mastered all the domains you want to master. To build the relationships across the entities that you're unifying, right. Build those connections. You can't do all these things, someone doesn't fund the work, right. And people don't fund the work if they don't see the value in the work that is going to be done. Period. You will struggle continuously just to kind of be tagged onto perhaps by very aware architecture teams and things like that into onesie, twosie projects here and there that may add new sources or may add new integration points for consumption of the data that you're creating.
But that's a hard road to get to where you really want to go to make your MDM program the success that you know in your heart that it can be. So some of the pitfalls we see here really are things that happen if you're not building this cross-functional alignment, if you're not staying on the practice focus and you're on a technology focus. It's around assume complete ownership. Well, again, the practice is larger than just the technical team that is doing the maintenance and support of it, right? Maintenance and support is of the application side of it or the platform side of, it's the technology tool and how you manage that. But it's bigger than that. So when you focus on the practice, don't assume complete ownership. Don't assume complete ownership of the data. There's a lot of that in organizations as well. That's probably a broader discussion around data governance and some of the pitfalls we see there.
All right. Dave, thanks for the feedback. The idea of communicating, so from Dave Weaver. "I think that the idea of communicating the importance or prioritization of process to stakeholders and then having buy-in is essential. When MDM is seen as only IT obligation rather than a business opportunity, it loses its perspective as a driver of enterprise value." I couldn't agree more Dave. Couldn't agree more. Great feedback there and that's what we're talking about, right? From having the business understand the business opportunity there and prioritizing how you communicate that outwardly. Being inclusive of these data stakeholders, including them in the overall practice of MDM provides a broader ownership and governance perspective of the data. You see this impacting kind of the last bullet there around MDM caused the DQ issue. There's often a perspective of that when you don't have this broader team and you don't have the business understanding how it drives enterprise value. You get to points that I mentioned before around where a DQ issue is realized.
And I say realized, meaning it has visibility now, right? It's more transparent because MDM is more involved in this enterprise view of the data. And so there's a perspective that happens when you don't have this practice built out in these business perspectives that MDM created that data quality issue and that can be really hard to get out of that loop once you're in there. Right? So again, the key to that and to prevent that is, as David said, right, building those and making sure that the perspectives around MDM are understand by the constituents involved on the business side.
We talk about another pitfall to avoid are these long and costly projects. When we look back at this view, one of the key factors or variables in here that can impact this is that projects tend to take a long time, whether it's your initial implementation or if you're just cycling through adding a new source because there's a different release coming up or there's a new point of integration that you're a part of. When these things take three, six, nine months, it's really difficult to keep people's attention to what the value of that work is and balancing the value of that work versus the cost and the timeliness of that work.
So ways you can do that are to follow more of an iterative approach is highly recommended. We talked to that in some of our content around migrating from legacy to modern MDM solutions. But it's just a really good way to make sure that you're providing a picture of iterative value. Even if you can't do a project in like an agile type of sprint methodology, you can still try to look at what you're doing along those key milestones of those projects and try to flag and understand much like the business focused pitch here, what does that do from a business perspective? What did you just unlock? What did you just turn on? What did you just do that enables the business? And remember that enablement is oftentimes ignored because it's really difficult to attach a quantifiable dollar value to it, but it's still really valuable.
So don't ignore enablement as a point of value. Make sure that as projects, again, whether it's an initial implementation or just follow ons, that there's an understanding that you're communicating to the broader practice, to the broader stakeholder space about the iterative value that you're providing. Right. And keep their attention, keep the focus on the value that you're providing. And that's how you can avoid this perception that, "Oh, it's IT and IT costs too much and IT takes forever and I'm not getting value out of MDM," and those kind of things. How many folks have experienced that perspective from your business constituents around really seeing the value in the work that you're doing in and around MDM related to it taking too long and being too costly to execute projects? Has anybody experienced that?
Chris Detzel (30:44):
Positive people have.
Chris Ilof (30:49):
Sorry. Should have had a coffee slide to start. Obviously one that we see here on the pitfalls to avoid that is key. Now we see data sprawl happen. And what I mean by data sprawl is you will see consumers of data taking the data and still kind of putting it into their own personal space or their own database and rejiggering the data to do what they want to do. When this happens, it's really hard to, again, traverse what MDM is producing as a product and where that's adding value to the organization. But how we avoid that is, again, it's through clarity and a lot of it's through the KPIs and metrics and reporting. When you're able to show what MDM is doing, just from a metrics perspective, how many profiles do you have mastered? How much source data do you have coming in?
A real good one is percentage of confidence in your matching capability based on how many false negatives and how many false positives do you see, how many potential matches? All of these things are usually focused on by MDM and stewardship teams that are managing the data and they don't get outward view or outward availability to the broader organization. Providing that really helps others understand and ask important questions about what those stats, what those metrics, what that reporting really means. And again, it's an opportunity for you to advertise what MDM is doing for your organization. Right? So a key there is sharing that. [inaudible 00:32:51] cost benefit analysis. Great. Exactly. Right. Beforehand with a roadmap alignment. Yep. That would absolutely help, especially for long and costly projects. So we talk about the value aligned roadmap and we're going to hit that on the next slide.
I think that's a really good transition here and we can open up for some conversation, more general questions, anything that you got, but the value aligned roadmap is integral. It's absolutely key. Now the hard thing is, again, talking to business value from a platform or a technology space in a solution that you've helped build and are managing is really hard, when it's the plumbing, when it's the electricity. As with plumbing and electricity, oftentimes people don't really see value. They see problems. When the light switch doesn't turn the light on, when the toilet doesn't flush or it overflows unfortunately. That's when people understand plumbing or electricity. When everything works just fine, nobody even knows it's there. Right? Well that's MDM. How do you traverse that? How do you traverse that distance? And it's, what is that value aligned roadmap? That value aligned roadmap is very similar to this business focused pitch, right?
How do you speak in language that says, "This is what MDM is doing for you in our business." Mr. Weaver again. "It's essential to have those engaged in integrating MDM with new projects to have a deep and clear understanding of what MDM does. This is important to safeguard its integrity as a source of truth for master data. Too often solutions that attempt to integrate MDM on master master data when integrating that source of truth. This is significant cause of data sprawl in my opinion. The insistence that master data is insufficiently mastered to meet the business need."
So that's a lot there, David. I think we could definitely continue to unpack. We talked about the data sprawl. The way that data is consumed often persist data or changes it from its mastered intent and use. That definitely impacts the trust in the data. Right. And trust in data, people don't trust it, then they're not going to want to plug in, consume MDM data. Right. So absolutely. And then if they don't trust it, the big thing about trust is really what you said last there, Dave, the business need. The number one reason people say they're not getting value out of MDM is they don't understand if it is or isn't meeting their business need. Right. And their perspective is that it is not. And quite often I think in my experience, customers experience I've seen, it's not necessarily the case that it's not providing what the business needs. It's more the lack of understanding of what MDM is doing to meet that need. Right. So it's more of an alignment of expectations.
Is that what you see as well, Dave? That's right. I know you got stuff going on in the background. All right. So when we talk about the value aligned roadmap, let's dive into that a little bit. Right? So it's literally this, right. It's letting the value or the perspective of value fuel that journey. Too often what this roadmap really looks like is just a series of happenstance projects that the IT owners of MDM get involved in to either add new sources or new consumers. We see a lot of that on the roadmap, but again, there's no perspective of the value, right? There's just, this is part of a project. It's a requirement and we have to run data through MDM. So that's what we do. Right? MDM becomes part of the data life cycle or the data supply chain, if you will.
And that gets viewed as, "Oh, that's an IT thing. We have to do that because IT says we have to do that with our data now." And we ignore the perspective of the business value. So one of our focus is, one of our practices here at Reltio and it's one that even is if you're not a Reltio customer, if you are a Reltio customer, I encourage you to talk to your CS team about success plans. But success planning is something that you can do and it should be something that you want and you need to own and manage as owners and operators of master data management. And again, all the keys that we talked about before are really making sure that this is the understanding that your overall data stakeholders have the diamond tier representing value, right.
That we're adding a new source. Well, what source is that? Right? Where does that data come from? What's the business process behind that data? What's the business function that it supports? What is a company or the organization getting out of bringing that new data in? And not just from a, "Oh, now I can have eye color added to the profile." Okay. But what does that enable? So getting the value is often difficult because it's hard conversation to have. It's kind of an annoying conversation to have at times where you feel like you're bugging people and you're just saying, "And then what? And then what? And then what?" And then what, it's going to be your best friend. It's how you get to what's in the diamond here. And again, what's in the diamond maybe a fiscal dollar value that somebody knows, it could just be something more qualitative that, "Well, it lets me do something I couldn't do before. This thing I couldn't do before. It lets marketing build a segment based on a high collar and they couldn't do that before."
Okay. And then what? Right. So this is how we attach value to a roadmap. Reltio has a perspective on how we do this through success planning. Right. But it really is more about if you think of laying out a project plan and your project plan always has these very technical milestones, if you take a look at your key technical milestones in those plans and you ask yourself the, and then what or to do what so that you can, this is how you yourself start to be able to attach to the value that you're providing. Maybe you understand the business really well so you can answer those questions yourself, but most likely you need to work with a business partner, a business constituent, perhaps it's the business application owner, the people using the data, the data stewards of that data and working with them to understand the business process side of it.
What are you unlocking? What are you enabling? What are you making better? Value comes from a perspective of really just three things that you can boil it down to. You're creating revenue opportunities, right? So making money. You're preventing or saving money through preventing costs or reducing costs. And you're reducing or mitigating risk. That's it? Any business function within your organization, when it floats to the top to the executive stack, those are the words that they're looking for. Am I avoiding or mitigating risk? Am I saving money or am I making money? Those are the three key points to value.
Thanks Chris. So when you look at a roadmap like this, obviously it's just a picture or depiction, how have you folks on the line, has anyone been able to build a roadmap like this based on value in the past and seen how successful they could be with it? Or from the flip side of that, would anybody like to share any of their experiences and challenges on how they've been able to execute some of a journey of your MDM development and your MDM practice, in any of these cases? Mastering new entities, adding new data, things like that. Anybody want to share some of their experiences and maybe pitfalls, keys to success that they've had on these post implementation integrations?
Vivian (42:15):
Hey Chris. This is Vivian. Can you hear me?
Chris Ilof (42:19):
Sure can.
Vivian (42:20):
Yeah. Yeah. So I would say I'm in a life science industry. I think it's a necessity to implement MDM because of the compliance requirements. We don't have this fancy chart, but it's a necessity. I would say it's, both the carrots and the sticks, right? The sticks is compliance requirement that you need to have a one view of truth across enterprise. You need to do that and to report to the federal and state government. That's a stick, right?
Chris Ilof (42:59):
Yeah.
Vivian (43:00):
The carrots would be, as you just mentioned, it's about the plumbing work. It's nothing fancy, nothing glamorous, but somebody has to do it. In the past, as the data moved through each function, everybody has some augmentation of the data, but augmentation will be lost in other function or as time go on, it would be lost.
So have a centralized function to do all this hard work for everybody. I can't see why nobody doesn't want it, right. And so I think I would say just the carrot and stick and of course, when we implement Reltio, we already have a legacy MDM, not truly MDM. It's very clunky. It didn't meet the business need anymore. So it was an easy sell. I mean, like I think the business actually need the efforts because we understand the business needs for a good MDM. So that would be just my two cents
Chris Ilof (44:15):
Understanding the business need is essential. Right.
Vivian (44:18):
Right.
Chris Ilof (44:19):
And again, that business need is where you get to the value. Right. So what is that need? What does it do for you now that you couldn't do before? What problem am I helping you solve? What business problem am I helping you solve? Not necessarily what technology problem we're solving. So absolutely Vivian. That's 100% key. How do you feel you've been able to and what do you think your learning curve was like post implementation, even though you had an MDM before, and then you replaced with Reltio. How have you been able to traverse kind of your roadmap and your journey to do additional things and what are some of the challenges and keys to success that you've seen?
Vivian (45:02):
So I think the key is, I think to me, I'm on the business side. So visualization of data is critical. So we can discover things that we never seen before because in the past, everything was in database and table format. You don't see the connection of the data. So now it's right in front of us. You can connect the dots and you find things that you didn't know before. We can relate the attributes and suddenly you have some insights that you didn't have before. And I would say the speed in a cloud form, it's fantastic. And I think those are the, in search, it's easy. So this will be the, I would think, the driving factors for us to go into the cloud platform.
Chris Ilof (46:12):
Awesome. Cool. Good stuff. Thank you.
Chris Detzel (46:14):
So Chris, there is a question there. [crosstalk 00:46:17] Yeah.
Chris Ilof (46:18):
I hope I pronounce that right or I hope I didn't crush it and kill it too bad. So I apologize if I mispronounced it. "Data sprawl could occur with legacy data where people do not understand it or data is old or not used and instead of retiring it, they keep it and add their new data and it keeps growing over time. Is MDM able to help with this type of problems?" So I mean, there's yes is the short answer. And actually having that, what is a point of sometimes referred to as data lineage is key to much advantage of MDM I would say in general. Now, the overall scalability, really that's more of a technical application and what technology have you applied and the constraints they're in around the volume of data that you can allow and be processed.
How much of that is truly just historical and more of a reference type of perspective for reporting in that perspective. So understanding the, again, more the business use case around that data, what are they using the historical data for? What's the real need? And wrapping around what that legacy data or that old data allows or permits business process to do is a key to that. Yes. Modern day MDMs can scale infinitely because we have the power of the cloud behind us. Legacy on-prem solutions, it's an investment, it's an incredible investment to be able to do that. So there are advantages and it's important to understand those implications as you choose your technology and you create your solution sets, but there is a lot of value too in being able to understand the connectedness between your new data and your old data.
And a lot of times, especially with, depending on the business areas, some business areas are tightly held onto their legacy data and they have kind of a deep relationship there, a long time relationship with that data. And knowing that and understanding that and kind of being empathetic to that is important, but positioning it into how MDM helps them transition into kind of the new data space is important as well. Providing that view of how old data and new data work together and the picture that it helps develop, the more robust picture that it helps develop, is absolutely key in transitioning teams to the new data space or the new data environment or through digital transformation projects like that.
Vivian (49:02):
I would say I think it's all about the usage of data. I think that it's really the use case and then your philosophy, right. For us, I can only talk about us. The usage is that your data is going to be used across the enterprise. So for me, it's the most accurate data at the time of publishing the data. So that would be our usage, but I also appreciate some other usage, right. We see our vendors database has all the history, 10 years history. So you can see how data changes and you can go back. When you get an old data, you kind of know, "Okay. So this is how this person moved from place to place." But that's not our goal, right? But it's good for us to reference that data, but for our MDM, we need to publish the most accurate data at the time. So I think depending on the philosophy and then you will in the governance to your MDM.
Chris Ilof (50:09):
Absolutely. Great points, Vivian. There's ways and there's methods that how MDM can help with that is you can choose to include how older legacy data participates within MDM. How does it contribute to a master profile? How does it contribute to mastering? Right. So all of that is configurable and understanding the value or what that data with those attributes and that legacy data need to do and need not to do in those spaces is helpful too. Oftentimes, it's just really helpful to have that lineage and that, as Vivian said before, the view, seeing the data helps and that you can see if and how legacy data contributes or if it's not. That's really what allows those data retirement scenarios to actually take place. Right? And without that visibility into how is that legacy data actually contributing to value into the organization, you're not going to get a lot of alignment on retiring that data and you can extend some of the cost and also risk implications of legacy data.
All right. We've got a few minutes left. So again, for those, I know our CS organization here in Reltio. So for those that are our existing customers, they're working through kind of revamping the success plan strategy and execution framework there. So please ask your CSM about success planning. And I encourage you to take that as an action to build your own roadmap like this. Your roadmap is your roadmap. Right? We've got lots of folks within Reltio that can help with some initial value statements because we work with several different customers. We know what folks have done and we have broad perspectives on the value that this can bring your organization. So you don't have to struggle through that conversation and figure it out all on your own. Work with your CSM to help figure that out, build out your roadmap for your practice.
And it'll give you a great guide. I'd encourage, be flexible with it, right? You're going to get that level of inclusion and flexibility. Again, this is, as Vivian stated, this is a point of visibility that's not just about raw data visibility, but visibility into how this thing is adding value, but also how it can add more value, right? When you paint a roadmap like this and it's value based, there's an opportunity cost perspective automatically to that, right? Why aren't we doing these things that can add so much value to the organization? This is how you can get some of that future investment. This is how you can bridge oftentimes that gap and increase the velocity of your ability to expand what you know your MDM practice can do for your organization. So please, have some conversations with your CSMs if you're a Reltio customer and you're live. Even if you're not live, have them about building your journey and your roadmap through success planning. Strongly encourage that.
Just a couple minutes left here. I think before we'll hand it back over to Mr. Detzel and wrap up. We'll share some links with you, right? So there's nice ebook here from some analysts that have written up on MDM from what it can and can't do for you, right? Especially from a modern MDM perspective. There's a tech brief, just an overview real quick, tech brief on Reltio perspective. And then accelerating data value is really, while it's focused around how we get migrating to a modern type of MDM platform, there's a lot of good meat and good stuff in there that can be applied to, even if you're just doing the next new data source or the next consumer and things like that. So we'll make sure that you get those links as well, but let's open it up real quick if there's any other questions or conversation points people want to have, I'm happy to take the time with you right now.
Chris Detzel (54:32):
I'm going to go ahead and close and if there are other questions, let us know, but thanks everyone for coming. Vivian, thanks so much for some of your insights and others. So thank you so much, David Weaver, for also participating a little bit and Chris, thank you so much for bringing some insights here about how to build an MDM practice from ground up. We hope that you liked it. Please put it in the comments if you liked it and/or some other future sessions that we should have that we're not currently covering. Would love to kind of hear your insights there. We do have lots of shows coming up. I put the link into the chat. So feel free to RSVP for future events that are coming up. Everyone, have a great holiday. Hopefully you had some time off and enjoyed it. So we thank you all for coming and that concludes our session today. Chris, thanks so much, man. Really appreciate it.
Chris Ilof (55:31):
Yeah. No problem. Thanks Chris. Thanks everyone. I will talk [crosstalk 00:55:35].
Chris Detzel (55:36):
Take care.