Lessons Learned: Avoiding The Debate: “Who Is The Customer?”
By Andy Field
There has been ongoing debate exacerbated by the emergence of Database Marketing and its evolution into what is now called Customer Relationship Management (CRM) around the necessity to define who the customer is. Many organizations have had great difficulty answering this question. But as an EIM professional does it matter? – unless EIM is responsible for determining business policies then probably not. What EIM needs to deliver to the business is the capability to define a customer however they like, and to change the definition as often as they please. Or even better, to provide a solution to the business that allows them to define a customer in many different ways for different purposes. Unfortunately many organizations, in an attempt to implement EIM, get embroiled in this debate believing its resolution to be a prerequisite to moving forward. In one recent engagement I encountered a manager who was insistent that they had to define the customer prior to moving forward with a customer Master Data Management solution and cited it as the reason for previous failures. In this article I will explain why this probably needn’t be the case.
Initially the definition for customer may have been created by the sales department to facilitate the calculation of commission compensation. Even within the sales function this definition can be the subject of heated debates when it is perceived to negatively impact fair compensation. Of course we realize that “fair compensation” is a subjective matter and will vary based on each individual’s perspective which is one example why these conversations can be very emotional. An individual’s performance review may also be impacted when it is based on revenue recognition which is dependent on how customers may be defined. Within large organizations with complex structures, which may have many lines of business sales and marketing functions, the debate is endless. Sometimes before the definition issue can be resolved reorganization takes place and the debate begins anew. For this reason it is highly desirable to seek a path to move forward with your EIM activities and not let this inhibit progress.
To add even more complexity we can think about organizations that enter into contracts with their customers that stipulate things like rebates based on sales volume within a certain time frame. The organization may have introduced a rebate program to its customers for specific product lines, market segments or geography to stimulate sales based on specific targeted economic factors. Sometimes customers may leverage their global presence to take advantage of these rebates in certain geographical areas and use the product or services in other locations that the rebate program was not targeted to stimulate. Situations like this can lead to conflict within the company regarding who recognizes the revenue and how the rebates get internally allocated. This is just one example of what makes resolving customer definition very difficult and may lead to organization political conflict. One of the most challenging aspects of implementing Enterprise Information Management is that the program frequently finds itself in the middle of these corporate political, and sometimes cultural, conflicts and may be perceived as causing the problems instead of just revealing underlying issues inherent within the organization. This is why great care must be taken by EIM to not become responsible for resolving this debate.
At this point you may be thinking that data definitions, governance and stewardship are all part of EIM so isn’t defining the customer an essential part of what we should be doing? Agreed that defining data is an essential component of the EIM function but there is a difference between defining data and interpreting data. If EIM endeavors to define all the data required for an organization to operate (the data needed to support all business processes), and the relationships between this data, and makes that available to the business then the definition of customer may be derived from the data available in the context of the business processes that require it. Let’s explore this a little. One of the fundamental principles behind the discipline of information management is that we need to think about all of the things and events (data entities) that the business needs to keep track of in order to function. We need to identify what is required to describe these things and events (attributes) so that we can recognize them and uniquely identify occurrences of them (primary keys). In the article published last month in the EIM Institute titled “Real World Data Modeling” the idea presented was that if we define the data as it exists outside of the organization perspective, as much as possible, then we do not subject the data to the volatility that may occur within our own organizations. If we do this the data definitions will likely survive many transformation processes, such as redefining market segments and sales territories, that impact the organization.
When we think about what a customer is in the world outside of our organizational (or other parties’) view, we realize that no such thing exists. A customer is a subjective term that is used to categorize a relationship between either a person or an organization and their relationship to other people or organizations. Therefore if we define our organization’s data model to include parties (organizations or people) and their relationship with other things or events (i.e. contracts, orders, market segment, campaign, location, other parties etc.), which include all the criteria that may be used to discern who a customer is (business rules) then we needn’t explicitly have an entity called “Customer”. If we follow this general approach we can proceed with EIM without getting embroiled in the contentious debates about what the business rules that define a customer happen to be at that moment in time.
Here is an example of how this works. Let’s use the business rule that “a customer is anybody that has ordered from us in the past six months”. In this case all we need to do is examine order history and create a list of all the parties who have ordered from us in the last six months. We would need to ensure this list has no duplicates, but if we have truly implemented EIM (data quality, master data management etc.), then the parties should already be unique based on their primary key. In this example the list may reveal some problems to the business, such as corporate structure issues, when it contains multiple entries for the same company but in different locations. This may result in the business refining their criteria to define the customer to be unique based on their tax identifier. In this case we would roll up the parties based on this attribute (SSN for individuals and Tax ID for businesses). So we can see that the process may take some time before the business settles on what they mean by customer but if we have modeled the data correctly we should be able to handle any definition they come up with without having a “Customer” entity predefined.
I am not suggesting that we may not want to have a customer entity or attribute in our data warehouse or operational data stores, to facilitate ease of use or improve performance. What I am saying is that it should be recognized that this is derived information and may change over time. The base information used to derive who the customer is should be implemented such that it does not change over time. When we enter into discussions to define customer it should be in the context of producing reports (or queries) or creating a logical database design as a “local view” for a specific business audience. It is not required to create your logical data model or to drive Master Data Management. Master Data Management and Data Stewardship (and Governance) should be driven from your enterprise data model.
If this approach is followed many controversial issues can be avoided and EIM is lifted from the center of corporate politics as it relates to defining “Who is the Customer.”
About the Author
Andy Field has been involved in information management activities for over thirty years in both the private and public sectors internationally and domestically. He has held senior leadership positions accountable for establishing Enterprise Information Management practices in several organizations, including a Fortune 100 company. Andy has also consulted with clients from many industries and government sectors over the years and established and ran as president a consulting firm specializing in strategic information systems planning. He has broad experience in both operational and data warehouse projects from both a hands on and leadership perspective. Andy is currently a Principal Consultant with EWSolutions, Inc. Andy can be reached at AField@ewsolutions.com