Customer 360 SaaS

Introduction

A Customer 360 journey provides a trusted, complete, and actionable view of individual and organizational customer data 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 complete, actionable view of all customer data. With a 360-degree view of business-critical customer data, businesses can engage with their customers, prospects, employees, and business partners in more meaningful ways.

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. It is important to document in a central location 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 entity to manage both Personal and Organizational data. Various child attributes, such as Address, Email, Product, Banking, Contacts, and others one-to-many characteristics of the parent Party. Lookup tables are pre-built, and many are prepopulated with industry standard reference data. C360 SaaS uses R360 to store and manage reference tables. The data model can be extended with project specific customer data. C360 documentation provides guidelines on extending the OOB data model. None of the OOB tables and columns should be modified or deleted. C360 SaaS data model is based on a document style database, child attributes are stored as sub-documents and can be extended. 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.

C360 SaaS leverages workflow processes included in the IDMC platform. There are several out of the box workflows included as well as the opportunity to build triggering events based on Business Events.

The MDM Architect takes requirements from the business to design the dashboard and various components in the UI such as hierarchies, networks, 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 make it easy for the business to see and provide direct feedback on required changes.

Data Ingestion and Data quality

When building a C360 SaaS project, Data Profiling, Cloud Data Quality (CDQ), Cloud Data Integration (CDI), Cloud Application Integration (CAI) and Reference 360 are all included with the C360 SaaS license for master data ingestion and hygiene. 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 provide vital information about source applications data to assess and evaluate the various DQ operations to be performed on that data.

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 or BusinessID in MDM SaaS uniquely identifies each customer entity. The MDM architect discusses the ROWID_OBJECT/ BusinessID and the data format with business. During the match and merge scenarios the ROWID_OBEJCT/ BusinessID 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 to persist the MDM ID permanently for the customer entity.

Match and Merge

Match and Merge rules development is a recursive process of testing, reviewing, and revising 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. MDM SaaS customers can leverage Cloud Data Integration as part of the IDMC platform. 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 IDMC or IDQ to publish data in real-time and batches.

MDM Data Governance

TThe 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 csv files through the UI. The User Interface and approval workflow is customized based on user requirements to govern and manage the customer master data.

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 the MDM solution 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.