Printable versionSend by emailPDF version
January 17, 2013

While there are many challenges faced when creating the enterprise view of a customer, the pervasive use of relational database technology has been one of the key enablers assisting organizations with the development of a flexible data model. Although creating this model is by no means a mission impossible — it is possible, portable and reusable, once all business components and rules are logically defined.

The goal of this article is to provide an appreciation of moving toward the creation of an enterprise view and the value that can be exploited from achieving such a goal.

For more than 20 years, both businesses and information technology sought after the perceived benefits of the enterprise view and quickly realized the challenges set upon them. Those challenges varied across a wide spectrum — from political aversion, mainly driven by a silo effect (see diagram below) and the need by certain industries to keep customer information proprietary across specified lines of business. The other constraint was due to high estimated costs relative to the development, maintenance and lack of technology and expertise — compounded by the ability to think through a flexible database design to handle changes such as mergers and acquisitions to integrate a newly procured business into existing data frameworks. Instead, most industries decided to allow for multiple customer databases driven by the specific businesses that owned the customer. Keep in mind that many organizations can still have multiple ancillary customer databases within each silo, fragmenting the view even more.

Siloed Customer View By Business

During the late 1980s and 1990s Information Engineering was touted as the most innovative methodology to shepherd in such a concept, since its focus was on exploiting the use of relational database design through the use of CASE Technology and active (or passive) data dictionaries. That approach focused on developing conceptual designs through the use of data and process diagrams with a key ingredient: building a strong partnership with the business user community for requirements, approval and ongoing development to meet evolving needs over time. The overall goal was to have the business drive the technology solutions, not the other way around.

By the late 1990s, Customer Relationship Management (CRM) questioned the need to put such a model in place to accommodate marketing needs, using a one-size fits all approach. By late 2001, with the expansion of compliance requirements, such as the USA PATRIOT Act, the need for an enterprise view was being echoed again at conferences, by regulators, business users and technologists.

In 2013, the business need is still alive and well, with few positive results. It is still perceived to be a daunting task that has now found a stewardship in the Financial Services’ Compliance Department and Risk Management — an interesting place that does not have customer ownership, but has a reliance on various data elements to meet their “know your customer” regulatory obligations combined with the products and services used. Regardles of their responsibility for risk rating and monitoring transactions against a comprehensive view of the customer, they do not create the customer, but maintain attributes within the profile for review. Based on the compliance business mandate and regulatory obligations, it is critical that a comprehensive customer profile, through an Enterprise View, is maintained and reviewed so that accurate (or close to accurate) information is maintained and accessible by both owners and specified business areas.

Developing a Model

So how does an organization achieve its goal in implementing the enterprise view of the customer? The first step is to develop a conceptual customer data model representing relationships to core entities, defining business rules (also referred to as relationships) and capturing the salient attributes; the combination represents high-level requirements easily understood by both users and technologists. Once completed, the model must be reviewed by the business owners to ensure accuracy of the rules and attribute definitions, while providing the foundation for database design.

Once a consensus is reached by the business owners, two key steps must take place: (1) creation of a normalized logical data model and (2) inventory and assessment of the current customer data. The creation of a normalized (3rd Normal Form or 3NF) data model assists in defining all attributes, dependencies and to ensure that a comprehensive list of business rules are in place before creating the physical database design. By taking an inventory and assessment of the current customer data, determinations will be made as to the extent of the cleansing effort. Some examples of common customer cleansing techniques used are street address standardization against the U.S. Post Office database and the standardization of common name prefixes, suffixes, and honorifics (i.e., Esq., Col.). Data cleansing and transformation will require extensive efforts, but can be expedited by using third-party software and engaging individuals that have spent years fine-tuning the process, coupled with the use of an Extraction, Transformation and Load (ETL) application for mapping, edits and validation. Data augmentation may require an organization to use external data sources (e.g., Dun & Bradstreet) to provide additional data like organizational structures and names of senior management. A&M recommends using an ETL tool, instead of building your own load process. These tools are proven while providing the integration effort with a consistent, reusable and auditable process.

The Next Step

The next step is the creation of the physical data structures (tables, columns and rows). The normalized model does not typically result in a one-to-one match to the physical data structures. There is a series of calculations and reviews executed based on data load approaches and complexities associated to various access methods (e.g., views). Typically, this work is performed by the Data Administrator (representing the business) and the Database Administrator. Also keep in mind that the Data Administrator role is a rare, but badly needed, position in many organizations. Therefore, it is important that all customer-centric areas participate and communicate their access and specific requirements to the Data Administrator, since most of their information needs will be met through various levels of reporting and access paths to the customer information. Moreover, a thorough review of ancillary processes supporting a specific department’s policies and procedures requires scrutiny to ensure that the data captured in the customer profile reflects the stated information needs.

As an example, a bank’s Legal or Compliance department, specifically BSA / AML, uses tools to assist in meeting regulatory obligations, such as transaction monitoring and interdiction applications for watch-list reviews. Because there are various levels of reviews needed to truly know the customer, the department will require update and read access. By granting this access, it allows the Compliance Department to update specific attributes, such as risk ranking (or ratings), based on the customers’ behavior over time. This information can occur in one of two ways: manually, as mentioned where the Compliance Department updates the customer risk rating through the user interface, or from an automated feedback that provides an updated score on a monthly basis, using the information gathered from alert generation when transaction activity exceeds (or undervalues) the anticipated (or assigned) score. In some cases, Compliance may require override capabilities, timestamping the rating differences, while maintaining an audit trail of the updates. If overriding existing risk ratings from an automated feed is not desired, providing reporting capabilities with potential changes, with a subsequent manual review, could be used as an alternative. The overall goal is to provide an aquifer of meaningful information to enhance Compliance’s review process, along with other customer-centric departments in terms of knowing their customers, while minimizing risk.

Reaping the Benefits

It should be clear to see how the benefits provided by the enterprise view of a customer can easily outweigh the costs over time. The summarized list below shows the positive results that A&M has seen organizations capitalize on over the years, while both minimizing risks internally and increasing customer satisfaction across the brand.

The diagram that follows is a simplified illustration depicting the Enterprise View at the center of all customer related functions (directly and indirectly) within a global banking organization and could apply to any industry sector.

Enterprise View By Business and Function Areas

Here are some inherent benefits from implementing an Enterprise View of your Customer:

  • Consolidates all products and services at the customer / party level, while contributing to the elimination of data duplication
  • Provides better customer intelligence across the board to manage risk, profitability and product development (e.g., cross-selling)
  • Defines other meaningful relationships, directly and indirectly (e.g., householding)
  • Timely and frequent updates to critical business attributes (i.e., risk ranking / scoring, credit scores, demographics) to better understand the clients’ customers
  • Provides the capabilities to meet regulatory obligations for financial institutions, as well as obligations for other industries (FATCA, FCPA, AML)
  • Better controls over managing customer and business expectations

Mission impossible? Moving to an Enterprise View is not a business option for the 21st century, but a long overdue strategy that every business needs to have put in place, providing the competitive advantage on all fronts.