Customer 360

Introduction

A Customer 360 journey provides a trusted, complete, and actionable view of individual and organizational customer data (master data and insights) which is used for analytics and operations to deliver highly personalized experiences across marketing, sales and support.

With new business models disrupting the status quo, along with heightened competition and customer expectations, the ability for an organization to provide a great customer experience and build customer loyalty, while being operationally efficient, is more important than ever. Trusted, relevant, governed, and contextual data is the foundation for a customer experience (CX) strategy. Informatica Customer 360 (C360) provides solutions  for those on the journey to create a trusted, complete, actionable view of all customer data. With a 360-degree view of business-critical customer data and insights, businesses can engage with their customers, prospects, employees, and business partners in more meaningful ways.

Customer 360 is based on Multidomain MDM. Business users connect to master customer data through a business-friendly user interface. The user interface displays an enterprise-level dashboard as well as 360-degree customer views that are customized for different business users.

Getting Started

A C360 journey begins with the concept of developing a centralized platform to manage all customer golden data from all business units in the organization. An Informatica MDM platform built with a C360 solution provides an integrated platform on which to build and manage customer master data.

Identify C360 Customers

Introducing a new C360 platform and its benefits to all enterprise-wide applications owners and stakeholders can require multiple discussions and demo sessions. Because application owners are often resistant to ideas of introducing new changes in applications and processes it is important to identify the first few business cases where C360 data provides immediate value to the business. Discussions with the architects of the consuming application will help to ensure that the C360 solution is architected to integrate optimally with those consuming applications.

Identify Source Applications

Identifying source applications will depend upon the various businesses an organization is involved in as customer data may be stored in many platforms and business applications. C360 project leaders and architects will lead discussions with business leaders and applications owners to explain C360 project initiatives and the potential value to the business and to get their buy-in. These discussions will include the necessary data sharing requirement with the C360 platform. C360 architects will engage with source application architects to evaluate the underlying application technologies, data extraction methods, and existing customer data and volume. Spreadsheets may be utilized to identify source systems and applications, their business sources, data attributes, volume, and underlying technology platform.

Data Model

The C360 solution includes a data model built from standard business domain information about the customer. The data model uses a core Party table to manage both Person and Organization data. Various child tables like Address, Email, Product, Banking, Contacts, and others contain repeating attributes for the parent Party. Lookup tables are pre-built and many are prepopulated with industry standard reference data. Data model can be extended with project specific customer tables and attributes. C360 documentation provides guidelines on extending the OOB data model. None of the OOB tables and columns should be modified or deleted. Data Model development should be reviewed and approved with all participating application owners.

User Interface Framework

The C360 solution comes with a pre-built UI with various capabilities like Entity view, search/retrieval of entities, hierarchy visualization, cross-references view, and match and merge views. The MDM architect reviews the UI capabilities with the business and determines the custom requirements for the UI based on business needs and data model extensions.

An organization may also request changes to out-of-the-box (OOB) approval workflows. An MDM architect carefully reviews custom requirements and approves for development those within the boundaries of E360 framework extension development. It is the architect’s responsibility to manage the expectations from multiple businesses and approve custom development within the product extension framework.

The MDM Architect takes requirements from the business to design the dashboard and various components in the UI such as hierarchies, network, Address Entities, and Product entities. UI design and development go through an iterative process. As the business starts seeing demos of the UI they provide feedback and new requirements. Frequent demos of UI development makes it easy for the business to see and provide direct feedback on required changes.

Data Ingestion and Data quality

MDM projects use Informatica Data Quality or any other ETL tools to load data into the MDM database. Architects conduct multiple discussions with business and applications owners about the quality of customer data and they list the various data quality operations that need to be performed on the incoming data. Data profiling results provides vital information about source applications data to assess and evaluate the various DQ operations to be performed on that data.

A data rejection strategy should be developed to handle any rejected data and send it back to business analysts for a data check. Data load jobs from source applications to the MDM landing or staging tables can be orchestrated via third-party scheduling tools or batch/shell scripts.

MDM ID Strategy

The MDM architect understands the requirement to develop an MDM ID for customer entities in the MDM platform. The MDM ID uniquely represents a system of record in the MDM platform for any consuming applications. The MDM default ROWID_OBJECT uniquely identifies each customer entity. The MDM architect discusses the ROWID_OBJECT and the data format with business. During the match and merge scenarios the ROWID_OBEJCT may change for customer entities. MDM architects evaluate every scenario and architect the MDM ID to meet the business requirements. A customized persistent MDM ID can be developed in order to persist the MDM ID permanently for the customer entity.

Match and Merge

Match and Merge rules development is a recursive process of test, review, and revise until the match and merge rules meet the business requirements. With a complete knowledge of the data coming from various sources, the MDM architect initializes and evaluates the under/over matching conditions and then iteratively fine tunes the match and merge rules until an acceptable data consolidation is achieved. Different match rule sets can be developed for the Initial data load (IDL) and the ongoing delta load data.

Merging customer entities and attributes from different source systems into a single customer entity requires source owner agreement on which source values to be saved in the master customer entity. This exercise needs a thorough study of the reliability of data coming from the sources. Source A may have high accuracy on Customer name and DOB. Source B may have high accuracy on Customer address. Ideally the master customer entity should have the name and DOB from source A and address data from Source B. Merge trust scores are configured based on this logic.

MDM Data Outbound

Informatica MDM provides various capabilities to publish data to consuming applications. Extracting the MDM golden data from MDM DB to a stage DB on daily basis using ETL tools is widely adopted. MDM also provides a web services-based framework to publish customized APIs for the consumers to call using SOAP and REST protocols. These APIs can be developed and published using MDM Provisioning tools without writing any JAVA code. Real-Time data publishing can be enabled using JMS messaging standards. Depending on each consumer application requirement to sync with MDM data, the MDM solution can be architected with middle-tier platforms like Informatica IICS or IDQ to publish data in real-time and batches.

MDM Data Governance

The MDM architect collects requirements around implementing MDM data governance. Various data governing users and roles are created to define the approval workflow for changes in the master customer entities. Different workflows can be provisioned by entity type and action (e.g., create, update) for data changes. In addition, a workflow exists so that data stewards can decide if questionable match pairs should be merged. Approval workflows can be provisioned for bulk imports of customer entities from the csv file through the UI. The User Interface and approval workflow is customized based on user requirements to govern and manage the customer master data.

Code Promotion

MDM environments are setup as Dev/QA/Prod or Dev/QA/Pre-Prod/Prod. The MDM hub console allows for the export/import of MDM code as XML files. MDM code can be exported and imported in whole or only for selected objects. XML files should be backed up to a code safe or shared drive as they serve as a backup of the MDM code.

Project Expansion

As the business realizes the value and benefits of using MDM data in their operations, the next MDM release can be planned with more source inputs and new business divisions joining the MDM journey. Situations like match and merge fine-tuning is a common follow-on requirement. The next release of MDM should account for any new business source data ingestion and match/merge with new data. Data quality measures should be consistent across all business data.