Redefining Customer 360: Building a Better Master Data Management Initiative

While the concept of the “360-degree view of the customer” has been around for years now, it still tends to be ill-defined in most enterprises, even for those actively pursuing and investing in these types of solutions. It is clear that this lack of definition and the inability to provide use-case-specific business benefits are hindrances to digitally transforming an organization’s operations and analytics. There are even more insidious effects of the Customer 360 approach on an organization’s master data management (MDM) programs and technology implementations—and in turn, its data governance.

The challenges to MDM efforts, caused by the typically narrow, yet diffuse, corporate view of Customer 360, result from approaching each master data domain separately and sequentially. Although this paradigm can have a devastating impact at the foundational level of the majority of MDM programs, it is still the default approach most enterprises take to implementing MDM in support of Customer 360, until they receive the guidance needed to avoid this doomed-to-fail approach.

An aggravating factor in this scenario is the fact that many, if not most, MDM software vendors still license their solutions separately for each master data domain deployed, even if the solution is physically a multidomain platform. This leaves organizations forced to find subsequent funding and staffing to align to the sequential implementation of domains.

When enterprises plan for an MDM implementation enabling Customer 360, it is extremely common for their initial thinking to sound something like “we need to master all of our customer data,” by which they usually mean customer master data (whether they know it or not). They then go out to the market looking for an MDM solution that is either built out of the box for the customer master data domain, or a multidomain MDM platform that will allow them to construct a data model for the customer domain as they see fit. Even in the latter case, this usually results in a data model that encompasses every master data entity and attribute that the IT organization can identify as directly pertaining to its customers. Moreover, as mentioned previously, many MDM vendors still sell base software licenses for each domain, making this approach seem quite sensible on the surface.

As a former Gartner analyst, I’ve spoken with many MDM implementers over the years who were taking the above path with every good intention. But nearly all would literally be stopped in their tracks when I asked what broad business value, or even actual business use cases, would be achieved when the customer domain was delivered stand-alone. Even without performing any analysis, they knew anecdotally that there would be other data domains, most likely product data, that would need to be mastered in order for the newly trusted customer master data to be effectively leveraged.

There are admittedly some exceptional cases where trusted customer master data on its own can provide some level of value. However, interacting with literally thousands of implementers over the past decade, as well as managing several successful MDM and data governance implementations myself, has shown me that these scenarios are few and far between. In cases where the acquired software is licensed solely for the customer domain, this inability to provide early business value is aggravated even further and can result in the program struggling at the foundational level, or even failing outright.

Multidomain MDM Needs a More Flexible Approach

The good news is that the solution to these scenarios is fairly straightforward, though it does require a shift in organizational, and even architectural, thinking around the optimal interpretation of the concept of multidomain MDM, both in program approach and technology implementation. Even better, it results in less work during the analysis, design, and implementation phases than the “default” approach described above.

Instead of thinking of multidomain MDM as the serial, or even concurrent, implementation of two or more master data domains, starting with the customer domain in the case of Customer 360, multidomain should be taken to mean the freedom and flexibility to model only those master data entities and attributes that contribute to the agreed-upon business outcomes—regardless of the data domains to which they belong. For example, the default approach would be to identify all 100 data attributes that can be considered customer master data in an organization and then licensing a solution to master only those attributes, only to realize that to deliver value, the program would also need to master 25 of the 200 product master data attributes required for a 360-degree view of the enterprise’s customers.

If a software solution only deals with the customer domain, or it is a multidomain platform that requires a separate license for each data domain in scope, it will not only delay the implementation but will result in a significant increase in license costs. It is also plausible that the default approach will rear its head again with the product data, leading to a total program scope of 300 master data attributes. Better to redefine the multidomain approach down to building and ratifying a nearer term road map for Customer 360 that only requires 20 of the customer master attributes and 25 product master attributes to deliver value. As a result, organizations only need to model and integrate those 45 attributes, which saves time, effort, and funding, and delivers the kind of transformational processes and analytics that only a best-practice MDM program can promise.

Of course, this best-practice approach really only makes sense if the acquired MDM solution is a data-model-agnostic platform, and that the vendor does not license each domain separately. Confusing the issue is the fact that some solutions market themselves as platforms (such as a customer data platform, or CDP) when they are in reality business applications dedicated to a small subset of use cases, and therefore are incapable of providing a true enterprise-level MDM solution. Care must be taken to evaluate and prove out the system’s capabilities via a proof of concept or targeted demonstration to ensure that the data modeling, data quality, data integration, and data stewardship capabilities can deliver on the expected goals.

This approach, coupled with a robust and ratified business case and/or road map that the MDM vendor should help create, can virtually eliminate the risk of program failure while confining the overall scope to deliver value as early as possible. Only then can the program be increased incrementally as business needs are identified, without worrying about the simple crossing of data domain boundary lines causing an increase in software costs going forward.

Bill O’Kane is vice president and MDM strategist at Profisee, a pioneer in master data management (MDM) solutions. To learn more, visit www.profisee.com or follow the company on Twitter @Profisee.