edm ods document

Enterprise Information ArchitectureEDM/ODS/EDW

ForAbc Inc

Document Information

Project Name: EDM/ODS – Data Synchronization

Project Manager: Document Version No: 0.1

FocusPM Phase: Document Version Date: 11 Sept. 04

Quality Review Method:

Prepared By: Preparation Date: 11 Sept. 04

Reviewed By: Review Date:

Distribution List

From Date Phone/Fax

16/08/2004 30385621

To Action* Due Date Phone/Fax

* Action Types: Approve, Review, Inform, File, Action Required, Attend Meeting, Other (please specify)

Version History

Ver. No. Ver. Date Revised By Description Filename

Abc Inc of 90Enterprise Information Architecture

INDEX

1. Purpose of the Document.....................................................................................42. Intended Audiences...............................................................................................53. Company...................................................................................................................5

3.1. Business...............................................................................................................53.2. Vision Statement..................................................................................................63.3. Mission Statement...............................................................................................6

4. Enterprise Information Architecture..................................................................74.1. Logical Data Hierarchy for EIA..........................................................................8

4.2. EDM......................................................................................................................114.3. EDM Scope.........................................................................................................114.4. ODS.......................................................................................................................124.5. ODS Scope..........................................................................................................144.6. EDW......................................................................................................................14

4.7. EDW Scope.......................................................................................................145. Benefits of Enterprise Information Architecture..........................................166. Out of Current Scope...........................................................................................177. Enterprise Information Architecture Vision...................................................178. Suggested Architectures....................................................................................18

8.1. Functional Architecture.....................................................................................188.2. EDM/ODS & Reporting Architecture...............................................................208.3. Data integration Architecture............................................................................26

9. Design Basis for EDM..........................................................................................2710. RIC Conceptual EDM........................................................................................2811. Business Model Views....................................................................................3513. Business Process Reengineering................................................................6414. Execution Plan...................................................................................................6415. EDM Development Plan...................................................................................6416. ODS Implementation Plan..............................................................................6417. ODS Deployment Strategy..............................................................................6417.1. Sizing................................................................................................................6417.2. ODS Population process Strategy...........................................................6418. ODS Query & Reporting..................................................................................65

18.1. Standard Query & Reporting.........................................................................6518.2. Dashboard......................................................................................................6618.3. Synchronization status report........................................................................68

18.3.1. Target Update Tracking.............................................................................6818.4. Cross footing Reports....................................................................................68

18.4.1. Source Cross Footing.................................................................................6818.4.2. Target Cross Footing.................................................................................69

19. Policy and Procedures....................................................................................6919.1. Data Current/Archive/Purge Policy...............................................................6919.2. ODS Data population Policy.........................................................................6919.3. Business Process Change Request Policy......................................................69


19.4. Outages and Recovery Policy........................................................................6919.5. ODS-Source Synchronization Policy............................................................6919.6. Error Handling Policy....................................................................................70

20. Quality Assurance & Testing.........................................................................7021. Administration Plan..........................................................................................7222. User Training......................................................................................................7223. Ongoing Improvement.....................................................................................7224. Responsibility Matrix.......................................................................................7325. Resources Required and Background........................................................7326. Assumptions......................................................................................................7327. Dependencies....................................................................................................7328. Risk Analysis.....................................................................................................7329. Metadata..............................................................................................................73

Data Dictionary Metadata..............................................................................................73CIM Metadata................................................................................................................73Business Metadata.........................................................................................................73

30. ODS Service Level Agreement......................................................................7432. Baseline Documentation.................................................................................7932.1. Customer Life Cycle.....................................................................................7932.2. Business Definition......................................................................................79

32.2.1. Customer........................................................................................................7932.2.2. Products.........................................................................................................7932.2.3. Services..........................................................................................................7932.2.4. Channel..........................................................................................................7932.2.5. Network.........................................................................................................79

32.3. Functions........................................................................................................8032.4. Current Architecture....................................................................................86

32.4.1. Operational....................................................................................................86

1. Purpose of the Document

The purpose of this document is to lay down the vision, approach, business definition, design requirements, baseline reference documentation, Design and implementation plans, suggested architectures and resource requirements. for Abc Inc Enterprise Information Architecture/EDM/ODS Synchronization and Reporting Architecture project.


The document describes the approach towards defining Synchronization and Reporting strategy for RIC with a long-term view. The guiding principle for Enterprise Information Architecture is that it should support the organization for a period of minimum five years.

In order to be a document providing a long-term solution to the synchronization problems, the future course of organization needs to be understood. The EDM, synchronization and reporting strategy described herein is defined after considering the growing Indian market for telecom services, convergence of telephony, cable, Internet and other services and Abc Inc’s mission to be India’s largest service provider with growth happening both organically and in-organically.

The document also attempts to create a single source of most basic information available at this time that will guide the EDM/ODS project. The EDM is based in part on enhancement of current Common Information Model and the individual data models in line with the HP OneView data model. The basic business requirements have been generated from business documentation available at this time.

DSS/Data Warehouse/Data Marts are not in scope of this document even though they appear as part of the architecture. RIC has currently running DSS function that manages DSS/DW/DM. They are a part of the overall Enterprise Information Strategy though not covered in this document or project

The documentation also does not consider implementation plan for Enterprise Data Warehouse.

2. Intended Audiences

Intended audiences for this document are:

Abc Inc Management Business Managers

3. Company

3.1.Business

Abc Inc is one of India’s largest Telecommunications Companies providing voice and data services.


3.2.Vision Statement

Abc Inc Vision

Abc Inc envisions a digital revolution that will bring about a New Way of Life. A Digital Way of Life.

With mobile devices, netways and broadband systems linked to powerful digital networks, Abc Inc will usher fundamental changes in the social and economic landscape of India.

Abc Inc will help men and women connect and communicate with each other. It will enable citizens to reach out to their work place, home and interests, while on the move. It will enable people to work, shop, educate and entertain themselves round the clock, both in the virtual world and in the physical world. It will make available television programs, movies and news capsules on demand. It will unfurl new simulated virtual worlds with exhilarating experiences behind the screens of computers and televisions.

Users of Abc Inc's full range of services would no longer need audiotapes and CDs to listen to music. Videotapes and DVD’s would not be necessary to see movies. Books and CD ROMs would not be needed to get educated. Newspapers and magazines would not be required to keep abreast of events. Vehicles and wallets will become unnecessary for shopping.

Abc Inc will disseminate information at a low cost. "Make a telephone call cheaper than a post card". These prophetic words of Dhirubhai Ambani will be a metaphor of profound significance for Abc Inc. Abc Inc will regularly unfold new applications. Continually adapt new digital technologies. Create new customer experiences. Constantly strive to be ahead of the world.

Abc Inc will transform thousands of villages and hundreds of towns and cities across the country.

Above all, Abc Inc will pave the way to make India a global leader in the knowledge age.

3.3.Mission Statement

Abc Inc Mission

We will create an integrated infrastructure with state-of-the-art digital technology to provide innovative, cost-effective and world-class convergent services to our customers. We will be India’s defining service provider and most preferred one. We will achieve dominant market share In India by 2005 and will rank among the world’s top ten carriers by 2007.


4. Enterprise Information Architecture

The Enterprise Information Architecture is the data or information blueprint for how data is to be organized across the entire organization.

EIA is required at RIC because:

- A company of Abc Inc size needs a comprehensive strategy to manage data.

- With the growth in the Telecom market and mergers and acquisitions in India and overseas, data explosion is inevitable.

- Data management needs to be seen as core competency of the enterprise.

The enterprise Information architecture for RIC can be seen as the combination of the following activities:

Data Acquisition

Data is acquired by the organization front-end systems:

- Acquire customer information- Network captures service usage actions of subscribers


Organizational Readiness Technical Readiness

Data Driven Decision Making

Query & Reporting Analytics

Behavioral Change Management

Business Process Change Management

ROI Analysis

Measurable Results of EIA

Vision and

Strategy

Org And

Culture

BISkills Infrastructure Data Quality

Information

Knowledge

Profit

Integration

Data

- Payments are received against Billing- Customer grievances and change requests, etc.

Data Generation

RIC generates internal data as an organization:

- Marketing launches a product or a campaign- Order management systems track orders- Billing generates invoices- HR and finance departments generate internal records, etc.

Data Management

Organization manages data actively by creating a data flow and storage in order to:

- Support business workflow- Integrate data from different sources

Reporting

Organization uses data for reporting purposes and generates information for business use.

- Standard reporting on business performance- Querying for information - Analytical reporting for Decision support

4.1.Logical Data Hierarchy for EIA

Logical Data Hierarchy in RIC will flow from the EDM.

EDM captures all the data of an organization and is at the highest level.

EDW is physical implementation of EDM. An EDW maps to EDM and can be a subset of EDM.


Not all data represented by EDM needs to be captured in EDW as it will not be necessary from business perspective and physically challenging to do so.

All the data in ODS is be subset of the EDW. ODS will have subject oriented detailed data required by business to solve specific problems.

Data Warehouse and Data marts also map to the EDW and will derive all their data from EDW. They are a strict subset of EDW.

The Operational systems will form the lowest rung in the data hierarchy and data at this level will map fully to EDM and partially to ODS and EDW.



Logical Data Hierarchy

EDW

ODS

ODS

Business Application






DM

DM

DW

EDM

4.2.EDM

An enterprise data model is a consistent definition of all the data common to the business, from a high-level business view to a generic logical data design.

The Enterprise Data Model incorporates and depicts the integrated data requirements of the organization in a single logical data model. It is the primary data model and foundation data model for strategic planning, communicating information requirements throughout the organization, implementing integrated systems and organizing data in the lower-level systems, warehouse and data mart models.

The EDM should have the following characteristics:

Comprehensiveo Caters to Enterprise Wide Data

Flexibleo Adapts to business changes

Scalableo Caters to new systems and data

Caters to current business processo Handles current business model

Caters to future business process o Does not become a bottleneck for business growth

Caters to dynamic business changeso EDM should be able to accommodate Customer hierarchy or

product definition changes without a major change in Data Model.

EDM can be built on an incremental basis by considering business areas in stages that are loosely coupled but needs to capture business model in its entirety at all times.

4.3.EDM Scope

The current scope of RIC EDM is to cover all the business areas that directly impact revenue generation and are customer centric. The EDM will cut across the product lines to cover the above-mentioned areas. The areas that will be covered are a follows:

Customer-Corporate-Individual


Customer Order Management

Product & ServicesWire line

WirelessAll others

Billing Payments Adjustment Collections

(MACDs)

Promotion/Schemes tracking Model

Customer Classification -De-duplication & House-holding

Inventory

Marketing Channels

Customer Communication -Proactive-Marketing Campaign-Passive-IVR-Reactive-CRM

Loyalty Programs

Credit Risk Rating & Fraud Tracking

Wholesale Customers/Interconnect

Network Indicators

CDR Data

4.4.ODS

ODS is a "subject oriented, integrated, volatile, current valued data store containing corporate detailed data" to support tactical decisions.

A real-time Operational Data Store is a set of detailed information collected from databases dispersed throughout an enterprise. An ODS supports the time-critical operational requirements of the business, bridging information gaps by:


Creating an environment tuned to information delivery. Containing data at detailed transaction levels. Synchronizing information across all relevant source systems. Maintaining a unified state of business operations.

ODS at RIC has the following goals:

Provides a online, integrated view of enterprise data Allows RIC to manage growing volumes of information in real time. Reduces management costs with single-system access. Enables online decisions based on available information. Reduce the reporting load of the source systems.

ODS is not the following:

The ODS is not the lowest level of detail in the data warehouse architecture.

The ODS is not a staging area for the data warehouse. The ODS is a subject oriented application and not a department-specific

application. ODS is not complete replication of OLTP database.

ODS is not a solution for the operational data exchange problems but it can track data exchange that has not been successful and systems that are not in sync.


ODS implementation will also help standardize all the data exchange mechanism. In case data exchange mechanisms are not standardized, all the processes that exchange data on spreadsheets, emails, etc. where format, content and responsibility of data is suspect will need to be standardized.

4.5.ODS Scope

The scope of ODS is limited by the scope of EDM.

EDM can be translated in to one ODS or it can be implemented as multiple ODS based on independence of data populating different ODS’s.

If one ODS is planned it will be based on the EDM and will have all the subject areas and related data covered in EDM.

In case of multiple ODS, the scope of each ODS will be defined by the business users as to what data they would need to see in the subject oriented data store.

For example, sales organization might like to see the channel and customer data in one ODS and Finance would like to see financial data related to customer, billing, payment and adjustment information, General ledger, etc. in other.

4.6.EDW

Enterprise Data Warehouse is single store of historical data of the organization. It is based on the EDM and will be implemented as one data store.

It is different from ODS as it has historical data for multiple years while ODS has current synchronized data for a limited period only.

Historical Enterprise data is preserved in EDW for analytical feeds and Data Mining purpose as it has detailed level data without summary.

In case of RIC, it is proposed to look at the option of implementing an EDW along with ODS/EDM or later. All data along with CDR’s become part of the EDW and will be available for analysis, mining and regulatory purpose for the lifetime of organization.

4.7.EDW Scope

EDW scope includes all the enterprise data although it can be selectively implemented.


Accounting

MACDBudgeting & Forecasting

Product and Services

Product and Services

Finance FinanceRevenue Assurance

Revenue Assurance

CustomerService

CustomerService

Fraud FraudSales and Marketing

Sales and Marketing

Customer Profile

Inventory

Customer Demographics

Customer Demographics

General LedgerGeneral LedgerPayments and

CollectionsPayments and

Collections

5. Benefits of Enterprise Information Architecture


Inventory DataInventory DataG/L DataG/L Data

Revenue dataRevenue data

Sales DataSales DataCustomer DataCustomer Data

Product DataProduct Data

Sales

Sales

EDW/ODS Integration

Single Synchronized View of Business

Enterprise Information Architecture in RIC gives managers a single view of business for both current data as well as historical data.

Instead of looking at individual separate stores of data for strategic and tactical decision-making, the Information architecture provides the business a single view at a single place and gives a big picture of business activities.

Better and Faster Decision Making

EIA gives business the desirable capability to make better-informed decisions faster as the data availability in terms of current as well as historical terms is enhanced to a great degree.

Meet Changing Business Demands

Once EIA is in place, it gives the organization better ability to meet changing business demands. The decision-making becomes all encompassing and impact analysis of changes to be brought about in business processes and systems becomes easy.

In case EIA does not exist, the impact of changes in one system can be disrupting on the other systems. EDM makes the changes of impact easier to analyze and implementation based on the data hierarchy.

Enable Organization Transformation

Creating integrated Information architecture leads to business transformation for better as the cohesiveness in decision making regarding the way business and information systems work together is better understood.

The creation of enterprise information architecture brings to the front information about the business and data model and how they perform in tandem. This leads to organization more tuned in to market realities.

6. Out of Current Scope


ODS/EDM/EDW currently under discussion do not cover the following subject areas:

HR Finance Purchase All others not mentioned in this document

The above subject areas can be added later to the information architecture if required.

7. Enterprise Information Architecture Vision

The Enterprise Information Architecture at Abc Inc envisages a long-term solution to business.

EDM/ODS/EDW combination is an attempt to align the data architecture to the business activities.

The data architecture needs to be robust enough to handle the dynamic business processes. Properly defined and Integrated Data Architecture in Abc Inc will help business achieve its vision, mission and goals.

Any data architecture project is not an iterative exercise. The vision of the business needs to be captured properly in enterprise data model so that all business processes are supported well.

EDM and ODS/EDW are derived from sustainable business model. Business model is reflected in the Enterprise Data Model. The Enterprise data model needs to be flexible and scalable to accommodate these changes.

EDM Vision

Abc Inc EDM vision is to create an umbrella data model for the enterprise by defining the enterprise wide data requirements to capture the business model and reporting model.

EDM will define data, required to run the enterprise, in an integrated form as one single model.

The EDM will be capable of predicting the impact of the changes to the Enterprise data architecture. It will be the model of reference and will need to be changed first before the changes reflect in any other systems in the enterprise.

EDM will be capable of accommodating new systems and Mergers and Acquisitions.


EDM will become the basis of the Enterprise Data Warehouse that will be store of data for enterprise for years to come.

EDW/ODS Synchronization and Reporting Vision

EDW/ODS Synchronization and Reporting strategy for Abc Inc envisions a data architecture and its implementation to help business run efficiently and effectively.

Data and reporting architecture defined by this strategy aims to create a solution where data acquisition, utilization, management, synchronization, reporting and retention are looked at from enterprise view point.

The aim is to integrate data, provide single view of business and fulfill reporting requirements of business.

8. Suggested Architectures

8.1.Functional Architecture

Functional architecture defines the functionality that will be catered to by the ODS. The functions that generate data are identified and the data entities are captured in the ODS.

The functional architecture is the arrangement of functions and their decomposition that define the execution to achieve the desired result. In case of ODS, the primary function is to collect data from and about the various functions being performed .The functional architecture represents the data capture from various functions.

FUNCTION LISTCustomer CreationService CreationPayment CreationLater Payment creationProvisioning MACD’sNon Provisioning MACD’sAdjustmentsPayment Rejection/CreationETC.


Add extra functions


Services &

FacilitiesAdjustments

Customer

Product

Payment

MACDCustomer Balance

Credit Profile

Collection

Billing

ODS

8.2. EDM/ODS & Reporting Architecture

ODS

ODS is a "subject oriented, integrated, volati le, current valued data store containing corporate detailed data" to support tactical decisions.

Enterprise Data Warehouse

Enterprise Data Warehouse is single store of al l historical data of the organization. It is based on the EDM and is implemented as one data store. It is based on EDM and is usually not used for querying or reporting.

Data Warehouse (DW)

Data Warehouse is a collection of integrated, multiple subject-oriented database designed to support the DSS function.

Data Mart (DM)

A Logical and Physical subject oriented subset of Enterprise Data Warehouse.

Data mining

Data Mining is defined as the non-trivial extraction of implicit, previously unknown, and potentially useful information from data.

Dashboard

Dashboard is a single screen, near real time representation of the key performance indicators needed by business to take corrective actions and make intelligent decisions.

Query and Reporting

Business needs useful information from the databases in the form of query and reporting. Query can be a one-time event to acquire and display information required by business. Reports are predefined formats for presenting information to business.



One ODS One EDW

SOURCE

SOURCE

SOURCE

SOURCE

SOURCE

ODS

Analytical Reports

Analytical Reports

EDW

OLAP Cube

DW

DM

DM

Query

Metadata

SOURCE

Tactical Reports

Adhoc Query

Dashboard

Dashboard

Data Mining

EDM/ODS & Reporting Architecture


Multiple ODS One EDW

SOURCE

SOURCE

SOURCE

SOURCE

SOURCE

ODS 1

ODS 2

Tactical Reports

Analytical Reports

Analytical Reports

Sync EDW

Data Mining

OLAP Cube

DW

DM

DM

Query

Metadata

SOURCE

Tactical Reports

Adhoc Query

Dashboard

Dashboard



One ODS No EDW

SOURCE

SOURCE

SOURCE

SOURCE

SOURCE

ODS

Analytical Reports

Analytical Reports

Data Mining

OLAP Cube

DW

DM

DM

Query

Metadata

SOURCE

Tactical Reports

Adhoc QueryArchiv

e

Dashboard

Dashboard



Multiple ODS No EDW

DM

Adhoc Query

Analytical Reports

Data Mining

ODS 2

Archive

Query

SOURCE

SOURCE

SOURCE

SOURCE

SOURCE

ODS 1

Tactical Reports

Analytical Reports

SyncOLAP Cube

DW

DM

Metadata

SOURCE

Tactical Reports

Dashboard

Dashboard


Multiple ODS architecture Pros

Easy data maintenance due to less data in single ODS. Better synchronization handling due to synchronization of only subject

oriented data Each ODS is independent and data availability is better in case of failure

of one ODS. Better reporting performance due to limited users coming to ODS and

small database size. Higher Scalability and Flexibility if data or process changes occur or new

systems are added.

Multiple ODS architecture Cons

Expensive Solution. Synchronization between multiple ODSs needs to be monitored in case of

common data. Higher maintenance resource requirement. Any Business process or Data Model changes affecting multiple ODSs

lead to higher costs. Multiple sources of information in case of combined data report required. Some Data Duplicated across ODSs.

EDW Pros

Historical store of all enterprise data. Archival or purging not required for ODS Data as it will be stored in EDW. EDW is ideal Data Mining database as it has all data at lowest level of

granularity. EDW provides progressive status of event and snapshots of various

entities like customer, products, etc. Future requirement of Data warehouse and Data Marts fulfilled faster as

EDW creates framework for DM/DW environment.

EDW Cons

Expensive solution. Higher Maintenance resource requirement Replication of data in EDW and DW/DM (though they serve different

purpose). Duplication of extract and load for DW/DM

Recommendation


We recommend the architecture with multiple ODSs for independent data with EDW to be the solution for Abc Inc.

8.3.Data integration Architecture

Data Integration architecture represents the data integration achieved in ODS for current data and eventually in EDW for historical data.

9. Design Basis for EDM

EDM Design is to be based on the following:


ODSMACD Status

Payment

OrderClarify

Clarity

Customer Acquisition

Payment

MACD

ADCBilling

Adjustments

Customer Balance

Service Status

SAP

Invoice Allocation

PG

Collection

Com-IN

Voucher Usage

Channel

Inventory

Portals

Rate Plans & Schemes

Adjustments

EDW

HP OneView Data Model

HP OneView data model is a pre-built data warehouse data model created by HP for Telecom service industry.

The HP OneView model can be customized to create a data warehouse for a telecom operation and it has most of, but not all, the data needed to create a comprehensive reporting mechanism.

It is to be used as a reference data model that will provide data and information requirements to be captured by Telecom operations.

Current Data Models from systems

The current systems in place and their data models in production at RIC will be used as the source of data for EDM.

Modeling of this data will be reviewed with the business to understand how well it serves the business model. Any changes suggested as business process change requirements will be modeled in EDM.

Business Processes

The EDM building exercise being undertaken is to serve business goals and needs to align with the policies and procedures that are defined by the business users to run a profitable enterprise.

Business Model will be the reference for building EDM.

Building RIC EDM

There can be two approaches to building EDM:

Build Abc Inc EDM from existing system Models and HP One view

Buy pre-built Telecommunication EDM and customize

The process of soliciting bids, evaluating Data Model, purchasing EDM and then customizing it might be a time consuming, expensive and possibly futile exercise.

In case of Abc Inc, systems are in place to serve nine million already existing customers,. The business model that these individual data models capture is already defined. Buying a pre-built EDM might not be the best solution as customization required and change in the current data architecture might be disruptive.


The current systems have been built over a period of time and have processes in place that should be utilized to build the EDM.

It is proposed that the current data structure, HP OneView and business process requirements be used as baseline for creating an EDM.

10.RIC Conceptual EDM

RIC Conceptual Enterprise Data Model is a high level representation of the entities to be covered in EDM.


Customer

Subscription

Order

Products & Services

CDR

Payment

Billing

Contract

Marketing Campaign

Promotion Schemes

Credit Risk Rating

Profiling

Sales Channel

Inventory

Organization

Fraud

Loyalty Rating

Segmentation

Portals & Touchpoints

Employee

HRFinance

Network ComponentsRate Plan

Interconnect

Others

Budget Cost

Forecast

Supplier

Householding Customer Status

Collection

CRM

Abc Inc Page 30 of 90Enterprise Information Architecture

RIC Conceptual EDM

Definition of Conceptual EDM Entities

EntityName DefinitionBilling This entity represents charges a customer needs to pay for the

services.Budget Budgeting for Marketing, promotion, etc. related activitiesCDR Call Detail RecordCollection This entity represents details & status of payment instrument.Contract This entity represents details of the contract between RIC & it’s

customer.Cost This entity represents cost related to various activities. For

example marketing cost, acquisition cost etc.Credit Risk Rating

Credit risk associated with a customer

CRM Customer Relationship ManagementCustomer Customer is the most important entity in any business and

customer information plays an important role. One of the aim of business is to know as much as possible about the customer. In order to serve better, a business needs to have complete and accurate information about the customer. Customer entity represents all customer attributes & demographics

Customer Status This entity represents status of the customer. For example active, inactive, suspension, termination, reconnection etc.

Employee Employee of RICFinance Business Function at RICForecast Forecast of sales/Revenue/Inventory/Churn/etc.Fraud Fraud tracking system informationHouse holding Capturing persons from same householdHR Business function at RICInterconnectInventory Physical Inventory of the network components/InstrumentsLoyalty Rating Rating customer’s loyalty towards RIC based on duration, etc.Marketing Campaign

Campaign aimed at attracting new customers/existing customers towards using RIC services

Network Components

Components that form part of network

Order Customer OrderOrganization RICPayment This entity represents details of payment done by customer.

Payments can be made in following ways.CashCredit CardDebit Card


EntityName Definition

CheckDemand Draft

Portals & Touch points

This entity represents portals through which customer can make payments or other requests.

Products & Services

This entity represents products & services offered by RIC.

Profiling Customer profile based on defined parametersPromotion Schemes

Targeted campaign that leads to higher revenue

Rate Plan Pricing plans for servicesSales Channel Channel through which sale to customer occursSegmentation Customer segmentation based on usage patterns/other

parametersSubscription Subscription to a certain serviceSupplier Supplier of Inventory parts

Entities in Current Systems & HP One View

EDM Entity Existing SystemsHP One View

Billing ADC IncludedBudget Not Included IncludedCDR Mediation IncludedContract Clarify IncludedCost Not Included IncludedCredit Risk Rating Sotas/ADC IncludedCRM Clarify Not IncludedCustomer Clarify IncludedCustomer Status Clarify IncludedEmployee SAP HR Not IncludedFinance SAP Finance Not IncludedForecast Not Included IncludedFraud Sotas Not IncludedHouse holding Not Included IncludedHR SAP HR Not IncludedInterconnect IncludedInventory SAP IncludedLoyalty Rating Not Included Not IncludedMarketing Campaign Clarify IncludedNetwork Components OSS Not IncludedOrder Clarify Included


EDM Entity Existing SystemsHP One View

Payment Clarify, Portals IncludedCollection SAP Not IncludedPortals & Touch points Portals IncludedProducts & Services Clarify, ADC,

ClarityIncluded

Profiling Not Included Not IncludedPromotion Schemes Clarify, ADC IncludedRate Plan ADC IncludedSales Channel SAP IncludedSegmentation Not Included IncludedSubscription Clarify IncludedSupplier SAP Included

The above is based on the information available at this time.

EDM covers all entities covered by the system data models and HP OneView model. New entities have been defined based on business requirements that need to be fulfilled. Business needs may add more entities as and when business captures new entities.

These entities are combination of entities and will be decomposed further as normalization process of data model is undertaken.

A fully attributed data model can be derived from the conceptual data model as detailed analysis of each entity is undertaken and new entities are added.


11.Business Model Views

Customer Hierarchy Management

Customer is the most important entity in any business and customer information plays an important role. One of the aim of business is to know as much as possible about the customer. In order to serve better, a business needs to have complete and accurate information about the customer.

As business matures tracking of customer will become important.



Group

Company 1

Company 3

Company 2

Company 4

Corp. Office

Head Office

Regional Office 1

Regional Office 2

AO 1

D 2

D1 D 2

D 1

AO 2 AO 3

D1D2D 2

Company 5

CBS

CBS

BS

CBS

CBS

CBS

D1BS

BSD1B

S

BS

BS

BS

BS

BS

BS

BS

BS

BS

BS

BS

BS

LegendC-CustomerB-Billing AccountsS-ServicesAO-Area OfficeD-Department

Customer Hierarchy

Same hierarchy can be applied to individual customers after House holding.


S1

L4

A2

L3

L1 L2

S2 S3

Company

Corp. Office

Head Office

D1 D 2

BS

BS

BS

BS

S5

A1

LegendC-Customer A-Postal AddressB-Billing Accounts L-LocationS-Services

CBS

Customer Billing & Services

S4

A2

Same hierarchy can be applied to individual customers after House holding.

The following needs to be fulfilled in a robust customer definition:

Only one entry for each identifiable customer should be allowed.

No new entry should be created in database If repeat customer.

Provision for creating a customer hierarchy in a way that:

Corporate customers can have a multiple level hierarchy to manage Group, Company, Division, Branch and individual level identities and still link them as one group.

The consolidated billing might happen at any level.

Individual customers can have hierarchy to manage household including dependent information and one bill can be generated, if needed, for all subscribers and products/services they subscribe.

One customer should be able to buy multiple products/services and, if needed, get one bill.

Contacts at different hierarchy levels should be identifiable in the system, each for services, billing, etc.

House holding provision should be available so that customers from same household are identified.


The EDM data model should have one customer – One entry in its database. The duplication of customer information leads to issues and need resolution at a later date.

CAF – One CAF one Customer

In case of one CAF – One customer, the customer that already has account with the RIC is added as another customer. This creates another instance of customer in the database.

Single customer buys multiple products/services

If a customer wants additional products/services, the customer is not able to do so as it is treated as new customer acquisition.

Service calls

In case of single customer having multiple instances of same or different products and not being treated as one customer in system will lead to multiple service related call for single issue. Where one call should have resolved the matter, customer will be bothered multiple times.

Customer Status

Any changes to the customer status cannot be determined, as same customer exists in the database as multiple customers. If it is only one customer, status of all products/services will be known at once.

Branch handling for Corporate

In case of branches of corporate not linked to the parent and treated as individual customers, impact of dealing with one branch will have a cascading effect.

No contact information at different levels

In order to resolve issues related to local SDCA level for a corporate customer with multiple locations, contact information at the local level is not available. Billing or corporate level can have one contact but might not be responsible for local level. There might be contacts for service related issues, billing issues, corporate communication, etc. at all levels.

Multiple Billing


If the customer hierarchy is not taken into consideration, billing for different products, different locations, etc. cannot be consolidated in one bill.

Initiating action including Fraud

In order to initiate any action on customer, if the customer has multiple instances in the database, it will be difficult to understand the correlation between the cause and effect.

Marketing campaign

In order to run a marketing campaign, information about a customer needs to be managed carefully so as to avoid resultant churn. If the customer hierarchy and interrelations between customer data is not known, campaigns may turn out to be unsuccessful or give unexpected results.

Incorrect information about customer base

Business will not be able to tell how many real customers they have and what products they subscribe to if the customer is not treated as a single entity.

Cross Selling

The ability to sell, to a customer, additional products can be enhanced if only one customer instance exits and one view of product/services subscribed by the customer is made available to the sales team.

Customer Profitability Analysis

A consolidated customer profitability analysis can be performed if properly defined customer hierarchy is maintained.

House holding

If a husband and wife bought phones on different CAF’s, business will not be able to identify the relation and any activity that affects one partner might have impact on two customers.

The data model for EDM should be able to take in to consideration the above factors and have a customer model that is scalable and is able to provide intelligent reports to business.

EDM is dependent on other systems that are capturing customer information. ODS will need the source systems to capture information that will enable it to


maintain hierarchy of customer and multiple products they buy and have more meaningful data available for business.

Data Model Views

Following are the data model views that try and resolve the observations above. These data model views have been created on the basis of HP One View model and information available at this time.

Business users will need to verify the data model views and modify them if business model is not completely captured in the views.

Legend

Zero or One Relationship

Zero, One Or More Relationship

Recursive Parent Child Relationship


Logical Model for Customer


CustomerCustomer Group

Billing Account

Corporate Hierarchy Level

Customer

Any entity needs to fulfill following two conditions to be considered an RIC customer:

It is a legal entity in its own right. It is responsible for the payment of bills against services and their usage.

There can be following types of customers.

Individual (Domestic Customer) Corporate (Commercial Customer) Individuals belonging to a Corporate

Customer may have hierarchy where all the members (family members incase of individuals-Family Hierarchy, companies & individuals in case of corporate- Corporate Hierarchy) could be linked. Individuals belonging to a corporate will fall in both Family and Corporate hierarchy if a family tree exists and vice versa.

Hierarchy will support any number of levels.

Individuals:

Customer must have one or more billing accounts.

They can also be identified as belonging to same household by virtue of same address and /or last name.

Corporate:

Customer must have one or more billing accounts.

Members who don’t have a billing account are not customers. They could be service contact/location or group.

Individuals belonging to a corporate:

Member must have one or more billing account.

Member will have its family hierarchy as well as it will be part of corporate hierarchy.

They can also be identified as belonging to same household.


Customer Group

Customer Group defines logical grouping of customers.

Billing Account

By default each customer has one billing account. Billing account is required to facilitate billing of multiple services together.

Corporate Hierarchy

Corporate hierarchy represents multiple offices, departments or divisions of customer organization.

When different offices or departments of an organization buy services, system should not create multiple customers.

When a corporate customer buys services only legal entity is treated as customer. If a department, Regional office or Area office buys service, system should not create a new customer but a billing account should be created.

In this case multiple billing accounts will be created and billing account will have attributes assigned to identify where it fits in the organization structure. This will help in targeting different offices or divisions of big customers.

Mergers and Acquisitions

Customer Hierarchy will be able to handle mergers, acquisitions and divestitures by RIC and among customers.

Mergers and Acquisition by RIC

This will lead to duplication of customers across two organizations. Mapping to EDM and de-duplication of customers will need to be performed before data can be uploaded to ODS and EDW.

Merger and Acquisitions of RIC Customers

Migration of acquired customer to be part of parent will need to be performed in case of merger and acquisition. In case of divestiture, customer will be broken into multiple customers.

Services, Rate plans, contacts, addresses, location, etc. will need to be captured for new entities.


Logical Model For Address, Locations & Contacts

Address Master

Contact Person Master

Contact Type

Location And Contact

Location Master

Location Type


Address & Location

Address is defined as postal address.One address can have multiple locations for services. Location consists of attributes (Utility Room No, Cabin No etc.) to identify service location for installation or maintenance on that address.

Multiple categories of address type could exist. Address type could be corporate office, Registered office, Billing, Shipping, Service, etc.

Customer & Billing Account can have multiple addresses.

Contact Person

Multiple categories of contact type could exist. Contact type could be corporate, service, service-location, billing-approval, billing-payment etc.

One contact person can be assigned role of multiple contact types. One contact person can be assigned for multiple Services, Billings and locations.

For one billing account there could be a different contact person for billing & service related calls.


Logical Model For Service

Customer


Service Details

Location Master


Contact Type

Service Master


Service

Service Master

Service Master represents all services offered to customers. One customer can subscribe multiple services.

Service Details

Service details represent status of services subscribed by customer.One service can be subscribed at multiple locations & one location can have multiple services.

There could be multiple contacts for the same service based on the category of contact.

Some services need not be assigned a location but can have different contacts for service & billing.


Logical Model For Billing

Billing Account

Customer



Order

Service Details

Service Master

Billing Node Type


Billing Account

By default each customer has one billing account. Billing account is required to facilitate billing of multiple services together.

One customer can have multiple billing accounts.

Billing accounts can have hierarchy for roll ups.

Customer can place subsequent orders against existing billing accounts.

Billing Node Type

Billing Node Type represents whether the billing account is Invoice or statement node. At least one invoice node should exist in hierarchy.


Combined Customer, Services & Billing Logical Model

Customer

Billing Account


Order

Service Details

Location Type

Address Master

Customer Group

Contact Type



Location Master

Service Master

Billing Node Type


Customer Identification Strategy

Most important function in managing customer is to identify customer- both Individual and Corporate customers including their hierarchy.

Customer identification can solve a lot of problems for the enterprise, as it will know its customers. Intelligent and accurate information about the customer can be had only if the data collected at the time of customer acquisition is correct.

The customer should be assigned a unique number in the enterprise and at all times customer should be identified by that number.

Avoiding duplicate entries of customer in the database is a prerequisite for customer management. If the customer has multiple entries in database, customer information is incorrect and is lost at the time of reporting.

There needs to be a mechanism at the time of creating customer that checks whether the customer:

- Is already a current customer?- Was a customer in past?- Was a delinquent/fraud customer? - Belongs to a group?

Identification Process

The CAF should have a field to capture the past interaction of customer with RIC.

Following cases need to be looked at:

1. Customer, when asked, voluntarily answers in affirmative.2. Customer replies in negative.

If the customer replies in affirmative, system should be able to search and activate customer or create a new instance of the old customer without creating new unique customer no.

In case customer replies in negative, system should be able to look for matches in terminated customer list/Fraud terminated customer list on the basis of information provided. If not found, a new customer can be created.

If there is a match, a pending verification status for the back office needs to be activated.

More information can be asked for and verified.


Back office then can take the decision on creating a new customer or any other appropriate action.

De-duplication

Even if the customer identification strategy is applied at the time of acquisition of customer, de-duplication process should be run regularly in the ODS. If RIC does not own a de-duplication software product, one should be procured and de-duplication process should be put in place.

De-duplication algorithms give a probability of the customer being the same based on defined parameters.

De-duplication is also not a foolproof solution and if the customer intends to hide identity, it might be difficult to track the customer. In India, nothing like a Social Security Number (SSN) exists. Even though PAN number is becoming more widespread, It is still difficult to track a customer.


No

Ask for Additional Information & Recalculate

Credit Rating

Yes for existing/New

No

Credit Rating Qualification

Credit Rating Qualification (If possible)

No

Reactivate customer & update details.

Create new Customer or New Billing Account

Authorization

Reject Customer

Yes for ReactivationYes

Yes

Customer Acquisition

Was a customer in past or is already a current customer?

Get details of Customer from existing database.

Yes

No

Delinquent or Fraud

Check duplication in customer database.

High probability of duplication

Get Details of Group or family member, who is currently a customer.

Internal Referral

Yes Yes

Customer Identification Strategy

No

12.HP OneView Comparison


No

Based on current system information following differences from HP OneView have been determined.

Subscription Profile HP OneView Model

Bill To Address

Business Attributes

Customer

Customer Contract

Customer Measures

number of productsoutstanding balance

Customer Segment

Geography

Household

Product Sales Channel

Service

Service Address

Subscription

Time


Subscription view from Partial EDM Based on System Data Models

BILLING ACCOUNTBILLING ACCOUNT NO

CUSTOMER ACCOUNT NO (FK)PRINT STACK CODE (FK)BILL_CYCLEDEPOSIT BALANCEACCOUNT BALANCE

CUSTOMER ACCOUNTCUSTOMER ACCOUNT NO

ENTITY NAMETITLEFIRST NAMEMIDDLE NAMELAST NAMECUSTOMER TYPE CODE (FK)CREDIT RISK CODE (FK)ENTITY TYPE CODE (FK)CUSTOMER STATUS CODE (FK)GROUP ACCOUNT NO (FK)HIERARCHY LEVEL CODE (FK)

ADDRESS MASTERADDRESS ID

ADD LINE1ADD LINE2PINCODE (FK)EMAIL ID

ADDRESS TYPE MASTERADDRESS TYPE CODE

SERVICE MASTERSERVICE ID

SERVICE DESC

SERVICE NODE DETAILS SERVICE NODE ID

SDCA CODE (FK)MDNRSNMINHANDSET CODE (FK)BILLING ACCOUNT NO (FK)CUSTOMER ACCOUNT NO (FK)STD CODE

SERVICE STATUS

SERVICE NODE ID (FK)SERVICE ID (FK)FACILITY STATUS

CUSTOMER STATUS MASTERCUSTOMER STATUS CODE

CUSTOMER STATUS DESC

GROUP ACCOUNTGROUP ACCOUNT NO

CORPOATE HIERARCHY LEVELHIERARCHY LEVEL CODE

PRODUCT MASTERPRODUCT TYPE CODE

PRODUCT TYPE DESC

ADDRESS LOCATION AND CONTACT

CUSTOMER ACCOUNT NO (FK)BILLING ACCOUNT NO (FK)SERVICE NODE ID (FK)ADDRESS TYPE CODE (FK)CONTACT TYPE CODE (FK)CONTACT PERSON ID (FK)ADDRESS ID (FK)LOCATION ID (FK)

CONTRACT

BILLING ACCOUNT NO (FK)SERVICE ID (FK)PRODUCT TYPE CODE (FK)TARRIF BUNDLE CODE (FK)

Gap between HP OneView and Partial EDM

Customer Segmentation not available House holding not available

Currently Not Covered in Partial EDM

Sales channel not covered in details. Only OTC code is captured. Service suspension, reactivation details to be covered from system data

models.


Billing Analysis in HP Oneview

Bill To Address

Business Attributes

Call Origin/Destination

Customer

Customer Billing Details

Customer Contract

Customer Segment

Geography

Household

Pricing Plan

Product Sales Channel

Service

Service Address

Subscription

Time

Billing Period


Billing view from Partial EDM





CONTRACT


GROUP ACCOUNTGROUP ACCOUNT NO

INVOICE DETAILSINVOICE NO

INVOICE DATEBILLING ACCOUNT NO (FK)




PINCODE MASTERPINCODE

CITY CODECITY DESCSTATE CODESTATE DESCCOUNTRY CODECOUNTRY DESC

PRODUCT MASTERPRODUCT TYPE CODE

PRODUCT TYPE DESC

SERVICE MASTERSERVICE ID

SERVICE DESC





SERVICE STATUS

SERVICE NODE ID (FK)SERVICE ID (FK)FACILITY STATUS


Call Origin/Destination not covered.


Order Analysis in HP OneView

Bill To Address

Business Attributes

Customer

Customer Contract

Customer Segment

Geography

Household

Order Measures

Sales Channel

Service Address

Subscription

Supplier

Time


Order view from Partial EDM

CONTRACT


CAF/ORDERCAF/ORDER NUMBER

CUSTOMER ACCOUNT NO (FK)CAF AGREEMENT DATEPAN NOFORM60SERVICE TAX STATUS CODE (FK)TDS TAX STATUS CODE (FK)ADD PROOF TYPE CODE (FK)ID PROOF CODE (FK)CAF_SIGN_PLACEID PROOF NUMBERREF RIM NODEPOSIT PRINCIPLEOFFICE FIXED PHONE STD CODEOFFICE FIXED PHONE NOOFFICE FAX STD CODEOFFICE FAX NUMBEROFFICE EMAIL IDPARENT SPOUSE NAMENO OF EMPLOYEESANNUAL TELCOM SPENDBILLING ACCOUNT NO (FK)OTC CODE (FK)






ORDER DETAILS

TARRIF BUNDLE CODE (FK)PRODUCT TYPE CODE (FK)SERVICE ID (FK)CAF/ORDER NUMBER (FK)







OTC MASTEROTC CODE


Supplier Details


Payment Analysis in HP OneView

Bill To Address

Business Attributes

Customer

Customer Segment

Service Address

Customer Contract

Geography

Sales Channel

Subscription

Time

Payment


Payment view from Partial EDM

CONTRACT








INVOICE DETAILSINVOICE NO

INVOICE DATEBILLING ACCOUNT NO (FK)

PAYMENT TRANSACTIONSRECEIPT NUMBER

PAYMENT DATEAMOUNT PAIDCHQDD CCDC NUMBERCHQDD CCDCEXP DATEPAYMENT TYPE CODE (FK)PAYMENT MODE CODE (FK)BANK BRANCH CODE (FK)CARD TYPE CODE (FK)CARD TX AUTH NUMBERBILLING ACCOUNT NO (FK)INVOICE NO (FK)OTC CODE (FK)SERVICE NODE ID (FK)

PAYMENT TYPEPAYMENT TYPE CODE

PAYMENT TYPE DESC

PAYMENT MODEPAYMENT MODE CODE

PAYMENT MODE DESC

OTC MASTEROTC CODE








HP OneView Payment Analysis Covered Completely


Campaign Analysis in HP OneView

Bill To Address

Business Attributes

Customer

Customer Segment

Geography

Household

Promotion

Promotion Campaign Measures

Service Address

Subscription

Time

Campaign details not covered in Partial EDM. Data availability in system data models to be identified.


13.Business Process Reengineering

Business participation in developing EDM is of utmost importance, as business model needs to map to the enterprise data model. Building an EDM for RIC might trigger Business Process Reengineering in certain areas.

Building a Data Model that supports the business in its entirety leads to following discovery:

Data that might not be captured at this time but is needed to run business effectively.

Data is captured but has not been modeled as per the business requirements and needs different treatment than is accorded to it.

Some business processes might need to be modified to capture correct data and put the collected data to most optimal use.

Data is captured and modeled properly but is not utilized by the current processes. This might lead to modification or new process design.

Current DSS operations might have more information and new ways of acquiring synchronized data once the system is in place.

14.Execution Plan

Execution Plan

15.EDM Development Plan

16.ODS Implementation Plan

17.ODS Deployment Strategy

17.1. Sizing

17.2. ODS Population process Strategy

The process design for ODS is an important step in overall design of ODS as processes will not only define the data capture points for ODS but also make sure that synchronization of data does not suffer.


ODS does not generate any data on its own. It will depend on the source systems for all the data. Robust processes are required to populate ODS and keep it in sync with the source systems.

The first step in defining the process is to determine the owner of the data. The data Steward will be the one which will need to be in sync with the ODS. The processes defined for populating the ODS and synchronization strategy will be defined by the source system characteristics, data availability and business logic.

TIBCO Processes

Operational data required for the workflow is exchanged amongst the source systems through TIBCO BPM and Integration manager application. TIBCO application is in production and the data is exchanged as XML. TIBCO BPM verifies the XML it receives from the source system and passes it on to the target system. This data can be captured by the ODS when it subscribes to the messages that are being exchanged.

ETL Processes

The data other than the operational data required for the workflow is available with the source systems only. This data is not exchanged on TIBCO bus. In order to get this data for the ODS, separate Extract, Transform and Load (ETL) processes will be required.

Synchronization Processes

One of the aims of ODS is to synchronize the data and make sure that it is synchronized with the source systems at all times so that any user having access to the data can be sure that they are seeing the current correct data. Processes need to be defined so that the data synchronization with the source systems is maintained and verified.

Outages recovery processes

The individual source systems, TIBCO bus or network can have scheduled and unscheduled downtimes that need to be considered in terms of data capture and loss of synchronization. Recovery processes need to be defined so that the changed data can be captured and synchronization achieved.

18.ODS Query & Reporting

18.1. Standard Query & Reporting

ODS will be subjected to both queries to retrieve information and standard reporting on regular defined intervals.


ODS can be queried on by the Managers and users to get information they need in their day to day operations, Clarify CSR’s can query ODS if they need customer related information to reply to their queries. They will not be able to initiate any action but will be able to satisfy customers on the basis of integrated information available to them on customer. ODS will become an alternate source to the users.

Management can define reports that they might need from the ODS on a daily basis. These reports will run at pre-defined intervals and get the information to the managers that will lead to more effective decision-making. Single view of business gives managers better understanding of the big picture.

18.2. Dashboard

Dashboards are reporting mechanisms where key performance indicators are tracked real time by the system. ODS can provide following dashboard to the users:

1. Synchronization Dashboards

Synchronization dashboards can provide users with the statistics against Tibco processes and synchronization status with other systems.

ODS will track the status delivery, to target application systems, of all the messages it subscribes and will monitor all systems it is synchronized/desynchronized. This can be presented to the users on a Dashboard as messages that have been subscribed by all and messages that are still awaiting delivery to the target systems.

2. Business Key Performance Indicators Dashboards

Business key performance indicators like number of customers created in the day, no. of provisioning and non provisioning MACD’s handled, etc. can be presented on the performance indicator dashboard that will give business users the current status of business.



0

2

4

6

8

10

12

14

16

18

20

CLFY ADC SAP ODS

Failure

WIP

Success

Customer Creation Process

0

1

2

3

CLFY ADC ODS

Failure

WIP

Success

Rate Plan Upload

CLFY

ADC

SAP

CLTY

ODS

CLFY

ADC

SAP

CLTY

ODS

Process Failure Count

CLFY

ADC

SAP

CLTY

ODS

Com-In

PG

CLFY

ADC

SAP

CLTY

ODS

Com-In

PG

Synchronization Report

RIC Data Synchronization Dashboard

Date 9/8/2004

18.3. Synchronization status report

18.3.1. Target Update Tracking

It can be tracked whether the systems are in sync with each other and with ODS by enhancing the EDM to keep track of the Tibco process workflow. The Tibco process workflow has multiple tasks and at each success, BPM gets a confirmation from the target system. In case of asynchronous process, the source system is not listening to the information but BPM knows about the status of delivery.

The source and target systems are identified with each of the process. ODS can subscribe to all the messages that enter TIBCO bus without considering whether the target has received it/Accepted it/rejected it or not. ODS will get populated with the information carried by the message. Since all the systems associated with a TIBCO process are known, ODS will be aware of systems that are involved in the workflow.

The source systems will already have the data, as it is publisher. ODS, when it receives a message, depending on the message, will start tracking the success result from target systems. As and when the target systems get updated and let TIBCO know that they have successfully used the message, ODS gets the information and updates in its system.

Any user will immediately know that the data has entered the TIBCO bus from the source as ODS will capture it and will be in SYNC with the source. In addition, the user will know that the other systems that are the targets for the message. Initially ODS will have a default ‘WIP” value for each target. As the targets get the message, ODS will update it to ‘Success’ or ‘Failure’.

This will ensure ODS is always in sync with the source of data and at all points of time has knowledge as to which other systems are in sync with it and the source.

18.4. Cross footing Reports

18.4.1. Source Cross Footing

Synchronization queries are queries that are run against the owner systems and ODS and are exactly similar so that the results can be compared and any de-synchronization can be monitored in the databases. It is a simple way of finding out if any discrepancies have occurred in the systems during the data exchange process or any changes that might have happened without the knowledge of ODS.


18.4.2. Target Cross Footing

Synchronization queries are queries that are run against the Target systems and ODS and are exactly similar so that the results can be compared and any de-synchronization can be monitored in the databases. It is a simple way of finding out if any discrepancies have occurred in the systems during the data exchange process or any changes that might have happened without the knowledge of ODS.

19.Policy and Procedures

The following Policies and Procedures will be defined once the EDM is completed and the data populating the ODS is known. The policy and procedures will be dependent on the data, source system and ODS needs.

19.1. Data Current/Archive/Purge Policy

The policy will determine the definition of ‘current data’ from ODS point of view. It will also define the archiving or purging of data based on definition of ‘current data’ and the time period data will be available in the ODS.

19.2. ODS Data population Policy

The policy will define the population of various data elements as real time or batch e.g. the invoicing data might be batch but the customer payment data might be real time. It will also define the policy about initial data load of the ODS as to what will constitute initial load at the time of rollout.

19.3. Business Process Change Request Policy

In case of business process change that affects ODS in terms of data or processes, this policy will define the methodology of handling change.

19.4. Outages and Recovery Policy

This policy will define the steps to be taken if outages occur in the source systems, TIBCO bus, ODS, etc. that are disruptive to the capture or access to data. It will also define how synchronization will be achieved as a recovery process.

19.5. ODS-Source Synchronization Policy

This policy will lay down guidelines to avoid de-synchronization of data with the source systems as well as the recovery process in case it occurs.


19.6. Error Handling Policy

The error handling policy will define the steps to be taken in case of error in data upload in the ODS.

20.Quality Assurance & Testing

EDM

Quality assurance for EDM will need to be carried out on the following basis:

- Data Modeling Standards

- Business Validation

Business needs to validate the EDM design by ensuring it meet business requirements and be able to support business activities. EDM must be capable of handling all data generated and acquired by business processes and meaningfully reproduce it at the time of reporting.

Business needs to create scenarios where EDM will be stretched to its limits to support business activities. For example, they might conduct a business transaction in a certain way and check if EDM will be able to capture data generated by the transaction and also will it keep the transaction in the database meaningfully.

ODS

The ODS data model needs to be validated against the data modeling standards as defined in this document.

Testing for ODS development can be described as testing the each of individual ODS population processes, reporting processes and synchronization processes in addition to the functioning of the integrated system.


Data Requirements Specifications

Design Specifications

Development

Test Environment Test Plan & cases

Testing

Testing will be a combination of manual and automated testing.

Testing Process

Setting up Test Environment Creating Test Plans Creating Test Cases

Unit Testing

This phase will establish the acceptability of each independent unit of software code that creates data input to or output from ODS. Unit testing will test all individual processes and/or adapters that will either populate or extract data from the ODS.

Error Fixing

The development team will debug the software based on errors detected in unit testing.

Regression Testing

During regression testing the earlier test cases will be run on the debugged code and will make sure that new errors have not been created due to debugging.

Integration Testing

Integration testing phase will test how all the components of the system work together. This stage of testing will make sure that all the individual components work together in a consistent error free manner.

The individual components would have been already tested for errors in unit testing phase.

It will also simulate different error conditions based on outages and errors in different systems and TIBCO/Network.

Performance Testing

Performance testing of ODS will be carried out for following:

- Transaction Load- Query and Reporting Load


This phase will determine if ODS works fine on performance parameters like response time for individual query/report or time taken to load data from both TIBCO and ETL processes.

Load Testing

Load testing will test the limits of ODS by subjecting it to increased transaction load and increased query and reporting load. This test will determine the performance of ODS under strenuous conditions.

Production ready testing

Production ready testing will ensure that the system is production ready. Test will be carried out in a simulated production environment and errors or performance issues noticed will be rectified.

User Acceptance Testing

User acceptance testing needs to be defined by RIC to accept the ODS system based on standards defined by the acceptance team.

Following wil l be put through the test process:

TIBCO data population processes TIBCO Adapter Functions ETL data population processes Pre-defined Reporting Dashboard population and update Synchronization Process Cross Footing Report Outage handling process

21.Administration Plan

Database AdministrationUser Administration

22.User Training

End User Training

23.Ongoing Improvement

Business Change RequestEDM Change Request


24.Responsibility Matrix

25.Resources Required and Background

26.Assumptions

27.Dependencies

28.Risk Analysis

29.Metadata

Metadata will be built keeping in view the business users and the technical users. The business users need to understand the data from business perspective and the technical users need to understand the data from the development perspective.

Data Dictionary Metadata “Technical” Perspective Based on data structures Typical elements: table lists, data elements, relationships and definition

CIM Metadata

The CIM mapping will be used as its metadata by TIBCO processes.

Business Metadata

Business Perspective Based on Business structures Difficult to create and maintain as the business definitions vary for same

data and changes with person defining it.


30.ODS Service Level Agreement

Following Service Level Agreement will be used to define the Service Level agreed by the ODS implementation team and Sponsor. The SLA is still a work in progress and will be reviewed throughout the project before finalizing it when the system goes in production.

Description of the System

ODS is the central repository of the synchronized current enterprise data received from the source systems that include Clarify, ADC, PhoneGen, SAP, Comverse IN and Clarity and others.

Main Roles Included in the SLA

The main roles that are identified within the SLA are System Owner, ODS Application Administrator, ETL process administrator, Data Base Administrator, Data Analyst, System Administrator, Source System Administrators and TIBCO Bus Administrator. As a separate attachment, the name and contact information of individuals who will fill the role will be available and updated as and when required.

Application User and Volume Metrics.

Following are the conditions for which Service Level Agreement applies.

Condition ValueExpected number of Source Systems 6Average number of incoming transactions per hour/day on TIB BUS

TBD

Peak and Off peak transaction volumes TBDAverage number and Complexity (High /Medium/Low Load) of incoming query requests per hour/day

TBD

Incoming ETL Load outside TIBCO TBDOutgoing ETL Load outside TIBCO TBD

Availability

The system will be available 24/7 other than scheduled unavailability.ODS “prime time”, or highest period of usage, will be operating hours of business during the day. The activity that would occur during that time will be all customer related activities in the source systems. Currently any exceptions (critical and non-critical) to system usage periods have not been identified. Users will be supported during the business hours by ODS Help Desk.


Scheduled Application Unavailability

The ODS will be unavailable in following conditions:

Maintenance DowntimeBatch Load/ETLBackup ODS EnhancementSynchronization Process RunData Archive/Purge Scheduled maintenance unrelated to ODS

The plan for periodic unavailability will be determined at the end of design phase.

Dependencies on Other Services

ODS is dependent on other systems for the availability of data and fulfillment of SLA’s. Following are the systems that ODS depends on for functioning in intended manner:NetworkTIBCO BusSource-Target Systems on TIBCO (In terms of availability and synchronization)ETL Server

Reliability

ODS Reliability can be defined in the following two ways: ODS will be available x% of regular scheduled hours (24 Hrs.) Reliability in terms of Synchronization with the Source System.

(Except during times of system failures, and other unexpected events)

Performance Expectations

Performance in terms of the following:ODS data availability time lag as compared to source (TIBCO and ETL).Standard Query response time Problem Reporting and Resolution

Standard Abc Inc policy will be adhered to for Problem reporting and resolution. Help desk will be set up with BSS and the problem escalation will be defined. In case any modification are required in regards to ODS Problem reporting, concerned persons will be consulted.Notification


In case of disruption in the service of ODS Following will be notified:

Role Name Mode of CommunicationODS App. Admin. TBD Phone/emailODS DBA TBD Phone/EmailODS System Admin. TBD Phone/EmailSource System Administrators

TBD Email

TIBCO Admin TBD EmailODS user Group TBD Email

Application Maintenance

Standard Abc Inc policy will be adhered to for Application Maintenance. In case of any modifications are required in regards to ODS maintenance, new process will be defined and authorized.

Expected Growth and Change

Standard Abc Inc policy will be adhered to for change management. The expected growth in the number of users, storage, volume of transactions, etc. still needs to be determined.

Backup and Recovery

Standard Abc Inc policy will be adhered to for Backup. In case of any modifications are required in regards to ODS Backup, new process will be defined and authorized.

Archival and Retention

This is a policy matter that will be defined at a later stage.

Business Recovery/Continuation

Standard Abc Inc policy will be adhered to for Business Recovery /Continuation.

Periodic Review

The SLA should be reviewed every three months for the first year and six months /one year depending on the changes that might be occurring in the business/system.


31.ODS Standards

Primary Keys To ensure non-duplication of data, primary keys will be enabled on all master tables.

Referential Integrity

To ensure there are no orphan records, referential integrity will be enabled at the database level.

"Data" based transformation

This means that transformations of data must not be "hard" coded. For example, if the source OLTP uses coding, such as, "1=Active" and "2=Inactive", the transformation of 1 to Active and 2 to Inactive must not be hard coded. Instead, a translation table should be utilized. In this manner, when the meaning of the codes changes, or when codes are added or deleted, changes to the transformation programming are not required. If OLTP systems exchange code description in place of code, in that case ODS will not populate the description as it is, but it will maintain a master list and validate the input against it. Source system for the master data will be identified & ODS will be informed about any addition or modification about that data.

Null standard

The NULL standard will be implemented. This means that spaces or "blanks" may not be inserted as legitimate values. If the value for a field is not known, the field must be NULL. The use of spaces/blanks often provides a false sense of data integrity. In addition, some tools ignore the presence of spaces and treat them as NULLs or even change them into NULLs. To prevent inconsistencies with databases, NULLs must always be used. In addition, as neither NULLs nor spaces/blanks are visible to the user, the user may errantly attempt to join a column containing NULLs to a column containing spaces/blanks. Since database does not consider these to be the same, the query will not return the result expected by the user. End users will require training regarding the querying of NULLs and their use.

Physically Normalized/de-normalized

Data in the ODS will be stored in hybrid format. Most of the data should be stored in normalized form. Some of the master data can be stored in de-normalized form.


Data verification scripts

To ensure ongoing validity of the data in the ODS, data verification scripts will be designed and written. These scripts must be designed to check that no extra data was moved, that no data was lost, and that the data moved was the correct data. In addition, these scripts must be implemented in such a manner that notification, such as EMAIL, will be sent to the appropriate application administrator as well as to the appropriate system representative(s). The systems must also be aware of the problem.

Standard benchmarking queries

In order to support the SLA, as well as to identify and define performance issues, a set of standard "benchmark" queries will be developed. These queries will be used to verify reports of performance degradation. These queries will also be run before and after software upgrades to verify the success of the software change.

Metadata

Metadata will be captured throughout the ODS design process. The capture and recording of this data during design and development is critical to providing necessary user support and database maintenance after the ODS is in production. Metadata must also be maintained after the ODS is in production.

Plan for archival of data

Historical data will not be left in the ODS forever. The accumulation of data over an extended period of time will seriously degrade the performance of the database. Part of the ODS development effort must include the development of rules and scripts to archive historical data to a data warehouse or other storage location.

Read only

The ODS must be read only. The ODS is to represent data in the current business systems. In order to guarantee that data is inserted into databases in accordance with defined business rules, data must always be entered into the system via the OLTP applications.

QA of Final Design

Before the physical build of an ODS in development, the design must go through Quality Assurance with Data Administration and business. This will help to ensure that a quality model has been designed and that all necessary documentation has been provided.


32.Baseline Documentation

32.1. Customer Life Cycle

32.2. Business Definition

32.2.1. Customer

32.2.2. ProductsWirelineWirelessPre-PaidPost-Paid

32.2.3. ServicesRworldRconnectVPNEtc.

32.2.4. Channel

32.2.5. Network


32.3. Functions

Following functions will be considered for EDM design and ODS implementation.

Market & Product (MP) Market research Demand forecastingCampaign management Marketing sales collateral management

Develop technical specifications Develop pricing specifications Develop promotions and discount schemes Create product reference information Distribute collateral for all relevant media Maintain product catalogueNumber Planning Tariff management Price services Provision of access to tariff / price info. Tariff maintenance/reviewProduct portfolio management Product lifecycle management

Portfolio mix balancing

Sales & Channels (SC)


Own stores management Store/OTC InformationDealer management

Handset commission calculation and payment

Voucher commission calculation and payment

Commission claw backSales support material Distribution of POS to own stores Distribution of POS to dealersHandset distribution management Handset assembly Handset distribution Handset returnVoucher distribution management Voucher procurement Voucher distribution Voucher returnPrepaid sales Prepaid sales at own store Prepaid sales at dealer Prepaid sales through call centerPost paid sales Post paid sales at own store Post paid sales at dealer Post paid sales through call centerCredit refilling Vouchers top upCorporate sales Provide quotation Manage prospect Sales lead tracking Commission calculation and payment

Fulfillment & Assurance (FF) Provisioning


Order Management Provisioning Plan Assignment Inventory and/or Capacity Management Design Service Layout records CPE ProvisioningActivation Prepaid Activation Credit checking Order approval Order management Order completionPerformance Management Set threshold for performance parameters

Implement performance parameter configuration

Collect and report performance for trendsUsage Management Establish usage measures Monitor usage measure Evaluate usage pattern Publish customer usage pattern

Customer service (CS) Inbound customer contact Direct channel Indirect channel


Web channel Kiosk channelOutbound customer contact Churn Management TerminationCustomer Retention Outbound customer contact Retention letter Discount for retentionCustomer Satisfaction monitoring Direct channel Indirect channel Web channel Kiosk channel Manage Customer relationshipCustomer identification/verification Inbound Sales Enquiries Pre-paid Sales Pre Paid Activation Enquiries Pre Paid Recharge EnquiriesPost-paid sales Post-paid Activation Enquiries Post-paid upgrade/switchCustomer Account Management Account registration Add new service Change security details - Lost or stolen PIN

Handle service change eg. Add paid service, suspend service

Handle customer profile change e.g. address change

Terminate ServiceFault (Trouble Ticket) Management Tier 1 Trouble Ticket Handling Generate trouble tickets for internal party Generate trouble tickets to Providers Trouble ticket administration Track progress Ticket intervention Network generated fault management Manage ticket at 3rd party interface Confirm trouble cleared Notify customer of trouble clearance


Trouble ticket escalation Ticket assignment and dispatch Trouble ticket closureTier 2 Trouble Ticket Handling Problem diagnosis Resolve trouble at 2nd line Priority service restoration1st line diagnostics & resolution Resolve trouble at 1st line Reset parameters e.g. PIN/password

Diagnose cause/identify owning party and referral

Network generated fault management Manage service problem ticket Cancel fault Manage activation problems Manage pre-paid top up problems Arrangement of solution with customer

Network Infrastructure (NI) Interconnection management Assess interconnection requirements Negotiate interconnection agreements

Share forecasting and network build out plans

Negotiate and implement network level agreements


Network capacity management Network forecasting Inventory Management Asset ManagementRe-configure service Enhance/change existing service

Revenue Assurance (RA) Pre-paid Account credit update processPost-paid Rating process Billing process Payments and collections process Create physical refund process Run exceptional bills processCustomer Service 2nd Tier Billing query process Add adjustment process Create customer account process Change customer account process Direct debit mandates process On demand pre-paid processProduct maintenance Product configuration process Tariff update processInterconnect Interconnect billing process Interconnect reconciliation processFraud Management Fraud response process

Purchasing & Logistics (PL) Supplier managementInventory managementDistribution management

Enterprise performance (EP) Business planning and budgeting


Target settingEnterprise performance measurement

KPI validation ReportingChange management Process management

32.4. Current Architecture

32.4.1. Operational

Current operational architecture consists of following systems in the New Architecture. Earlier architecture having RECON is not considered for the current design.

Following components are part of this architecture.

Selectica Clarity SAP Clarify ADC Phone Gen Comverse IN Portals TIBCO EAI SOTAS Interconnect Mediation DSS



WIRELINE APPLICATION ARCHITECTURE

edm ods document

Documents