ods project plan v0

ODS-Data Synchronization Project Plan & Resource Requirement

ODS-Data Synchronization Project Plan & Resource Requirement: Phase I

RELIANCE INFOCOMM

Document Information

Project Name: ODS – Data Synchronization

Project Manager: Document Version No: 0.3

FocusPM Phase: Document Version Date: 26 Oct. 04

Quality Review Method:

Prepared By: Preparation Date: 04 Oct. 04

Reviewed By: Review Date:

Distribution List

From Date Phone/Fax

26/10/04 30385621

To Action* Due Date Phone/Fax

Review

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

Version History

Ver. No. Ver. Date Revised By Description File name

0.1 4/10/04 Changed Plan, Assumptions / Constraints, Resource List

0.2 13/10/04 Changed Deployment Infrastructure

0.3 26/10/04 Changed Execution and Project plan, Added HP related details in Project Plan

Project Plan – ODS of 48

INDEX

1. Purpose of the Document............................................................................42. Purpose of the ODS.....................................................................................43. Users of ODS................................................................................................44. Assumptions and Constraints (RIC ODS Specific)...................................75. ODS Program Model....................................................................................86. Execution Plan...........................................................................................107. ODS Approach............................................................................................11

7.1. Data Model for ODS..............................................................................117.2. Synchronization.....................................................................................127.3. Initial Load.............................................................................................127.4. ODS Development and Implementation................................................14

8. Test Strategy..............................................................................................159. Information in ODS.....................................................................................1510. Source Systems for ODS.......................................................................1611. ODS Project Plan....................................................................................1812. Resource Requirements........................................................................1913. Software & Hardware Requirements.....................................................2014. Risk Mitigation (Project Management Specific)...................................2115. Constraints (Project Management Specific).........................................22


1. Purpose of the Document

Purpose of the document is to finalize project plan and resource requirements for the ODS project.

2. Purpose of the ODS

The purpose of the ODS is to integrate data for Wireless & Wireline customers and provide single view of customer. This data needs to be synchronized with the owner sources. ODS will become the reference point for synchronization and synchronizing systems with each other will be done on the basis of de-synchronization reports generated by ODS.

The business purpose of the ODS is to:

Integrate data and provide a single view of customer

Synchronize actions to block all leakage points that makes service failure or revenue leakage

To assure that there are no leakages due to back end operations that are modifying parameters that affect revenue or service

Synchronize all service and revenue affecting parameters

Continue to improve visibility and lead-time (detection, propagation and reaction) of synchronization.

ODS will provide:

Real time data integration to the extent possible on TIBCO Synchronize data with source systems Generate actionable Synchronization Status Get Synchronized Single View of Customer Query, Real time Dashboards, Rules Engine triggers & Reporting

3. Users of ODS

The users of the ODS are:

Operations Managers Revenue Assurance Back Office Operations


Revenue assurance will be the primary user of the ODS. ODS will be used by RA to detect causes of revenue leakages and service failures. Some of the causes that can be reported on are:

Order and Fulfillment Service Status de-synchronization Back-end processes Initial period of customer acquisition issues

Other operations will be the secondary users of ODS as they will be able to use the intelligence generated by RA and act on causes of revenue loss.

Recovery of revenue losing de-synchronization can be affected by the information generated by RA.

Views

The RA users of ODS will get following views:

CAF – Logged in but not fulfilledCAF – Not OTAFedAmount paid and Payable not equal report at the time of customer acquisitionAddress Verification (AV) Status and its agingMonitor ILD/NLD activationReport Name changesTrack Address change and new AV statusAdjustments tracking based on:

o First 30 days of customero Based on Valueo Based on User ID

Trouble Tickets generated with 30 days of fulfillmentFirst bill generation and trackingUser ID based action tracking for adjustmentsVoucher reconciliation status

The data cleansing during the initial loading of the ODS, to ensure that ODS has only synchronized records, will lead to the RA getting the information on any mismatches existing in the systems. Any mismatch will lead to ODS rejecting the data for the want of correct integrated information.

For example, if multiple instances of CAF Nos exist in different systems, ODS will provide a report on the multiplicity of CAF’s which will need to be corrected


before the data can be loaded in t ODS. Also, for a customer, if the data is different in different systems, it will be reported and synchronization regain will be done before the data can be loaded in the ODS.

Dashboards

Real time dashboards will be available for RA to be able to track the information in real time, if available from source systems. In case the real time information is not available, views will have the latency of one day.

These dashboards can be drilled down to check the information to the lowest detail.

For example, the Payment amount for the day can be tracked against the target for the day and the dashboard can be drilled down to get the payment status of Circles and OTC’s.

Reporting

Standard Reporting will be done based on the requirement of users of ODS.

Actionable business rules engine may be developed later to alert the users of certain actions so that corrective steps might be initiated. For example, if the business rule defines that any name change activity should be brought to notice of RA team, email notifications can be sent to the responsible person on a customer name change (MACD) on a real time basis.

Benefits

Ability to get single view of customer

Actionable status on revenue leakage and service failure to RA

Actionable status on de-synchronization of customer related attributes

Reporting load borne by ODS

Ability to report and respond to triggering events


4. Assumptions and Constraints (RIC ODS Specific)

1. The extent of de-synchronization in RIC systems is not known. This will have impact on the initial load as de-sync data will need to be synchronized before loading in ODS.

2. The backend processes currently used in RIC for changing customer data are not standardized. The non-standard processes will cause de-synchronization to occur in the system. This would put additional load on all the systems to synchronize again.

3. ODS is primarily dependent on the TIB data exchange mechanism. It is assumed that the certified messages are not lost and hence the exchange data loss due to outages is not present.

4. The synchronization process cannot be achieved in isolation by ODS. All the operational systems in RIC will be aware of the ODS and will change data from backend processes only after ODS has been informed. This will ensure that the ODS team is able to manage synchronization with the source and other systems.

5. It is assumed that the NWA architecture will be in production at the time of ODS going live.

6. ODS architecture is based on the NWA and will not support pre-NWA architecture. The data will be received from Clarify and not from RECON.

7. It is assumed that data in the source systems would have been migrated to NWA data models before ODS goes into production. It will not be possible to populate data that is in different formats in to single ODS data model. For example, it is assumed that enterprise wireless customers will have migrated to the new data model with GAN, CAN and BAN.

8. It is assumed that TIBCO architecture will be able to support the real time data requirements of ODS. In case real time data requirements are not fulfilled by TIBCO architecture, ETL process will be employed. The latency of this data will be dependent on extract window with source. Usually it will be once a day feed. ETL process will need system availability to extract data.

9. It is assumed that current data models and data dictionary for source systems will be available to design team during the design phase. The non-availability will affect the schedule negatively.


10. It is assumed that the required business rules have been implemented at the source systems and ODS will be applying only data integrity rules on the data being received from source systems.

11. DSS data model, reporting requirements, etc. are not known at this time and are not being considered.

12. Sales Channel definition will be defined in ODS data model but will not be implemented in this phase of ODS.

13. The source systems to be synchronized will be required to give full nightly feed of required data to determine de-synchronization in the initial phases of deployment.

14. EAI will be able to provide the message status to ODS to keep track of synchronization in target systems.

15. It is assumed that the de-synchronization status reported by ODS will lead to the removal of cause of de-synchronization in source systems. If the resynchronization strategy is not in place the de-synchronization report will have little meaning. The process of re-synchronization will be defined by all systems together.

5. ODS Program Model

The ODS program model represents the overall program management activity for building ODS.


Project Plan – ODS Phase 1 of 48

Fig.1 ODS Program Model

ReleaseManagement

PrioritizationProject Planning and TrackingPost Activity Review

Database Design

Create Logical Data Model (ERD)

Synchronization Tracking Data Model

Physical Data Modeling

CIM MappingTechnical Metadata

Business AnalysisProject

Management

Review Current Data being exchanged

Data & Process Flow Diagrams

Identify Data not being exchanged but required in ODS.

Define Business Meta Data

Define Owner of Data, Window & Access of Owner Systems

Project planning and coordination

S/W Program Design

TIBCO ProcessTIBCO Adapter/IM

Application (For ODS)

ETLSynchronization

DesignError HandlingOutages Recovery Reports & Dashboard

Design

ODS Development

& Testing

ETL and TIBCO Process Development and modification

Adapter Modification and Development

Sync Process Development

TestingDeploymentInitial Data LoadProduction

Infrastructure/Production

Support

Infrastructure hardware and software

DatabaseImplementation

supportApplication supportReporting & Query

Management

Program Management

Program Planning and ManagementProgram Documentation and ControlBudget Monitoring

6. Execution Plan

ODS plan is to integrate the current Wireless & Wireline data at one place to get one view of customer.

The proposed Execution Plan is:

Functional & Integration Architecture

Scope 1Wireless (Corporate & Consumers)

Scope 2Enterprise Wireline

Scope 3Business Rules, Triggers, Re-Inserts (De-Duplication, Householding, etc.)

Deployment Architecture

Final plan to be provided by HP

HP Proposed plan is as follows.

1. Project kickoff2. Gather and document Technical Requirements3. Gather and document Exception Processing Requirements4. Gather and document info (interfaces, protocols used, message formats) on pre-identified contributing applications5. Development system procured and configured6. Solution High Level Design 7. NonStop ZLE Data Store – Logical Design 8. NonStop ZLE Data Store – Physical Design9. RTID Customization (metadata definitions, subscription service development) 10. Rules Definition and RE Implementation11. Interface Simulator Development 12. Test Library Development 13. TIBCO JMS Configuration14. NonStop ZLEDS Load complete for test Environments15. Unit and Integration testing using simulators and test data 16. Development 17. Integration Test Environment setup at Abc Inc18. Integration Testing using test Abc Inc systems and data 19. Test Environment setup for Technical and Functional Acceptance


20. Technical and Functional Acceptance using customer data and test systems 21. TOI to Technical Groups22. Go Live Decision23. Controlled Production Environment Preparation including loading customer data24. 30-day Controlled Production Run25. Controlled Production Run Assessment26. Production Deployment Final

7. ODS Approach

The ODS project consists of following activities:

7.1.Data Model for ODS

Data Model for ODS will include modeling data defined in this document.

Data Dictionary and Metadata will be part of data model design process.

The following functions and entities will form part of ODS.

Services Product/Pricing Plan Customer F&F CUG Customer Acquisition/Order Order Management/Fulfillment MACD/Provisioning/Non Provisioning Billing Payment Collection Adjustments Trouble Tickets Fraud Rating CDR Count Channel Sales Org Inventory Management Promotions Discounts Schemes


7.2.Synchronization

ODS needs to be in Sync with the owner source systems and also will need to be check for de-synchronization amongst the various systems.

The synchronization strategy will consist of following:

1. Tracking the TIBCO message success for the data received by ODS but not other target systems.

2. Running synchronization scripts periodically to report synchronization of ODS with systems. Once reported, regain lost synchronization in ODS.

3. Running Synchronization scripts in case of Outages as a part of recovery process.

7.3. Initial Load

Initial Load refers to loading data in the ODS for existing customers and their services from source systems.

Initial load in ODS focuses on synchronization of data as missing or unmatched data from the owner sources can not be loaded due to referential integrity constraint in the ODS Data Model.

Only data that is synchronized across systems will be initially loaded into ODS. Data that is rejected will be stored in error log. It will be loaded into ODS once synchronization has been achieved in the source systems.

ODS will be put in production ready stage before first load occurs as once data is loaded in to ODS, changes occurring due to MACD will need to be captured by the ODS. During the initial loading, ODS will not raise error messages for MACD’s on TIBCO bus even if ODS does not have corresponding customer.

Initial load in ODS will be in following sequence:

1. All Master Data Tables

Master data tables for RIC will be loaded first in the ODS. These tables are independent of all other tables in ODS Data Model.

Once loaded, they will create a constraint by the way of Foreign Key in other tables. These tables will not allow loading of data in linked tables that does not match with the data contained in Master Tables. This will ensure that referential integrity is maintained through out the ODS Data Model.


Example: If a customer record comes to the ODS that has Pin code value not available in PINCODE master, the record will be rejected, sent to error log table, corrected and re-pushed to the CUSTOMER table.

2. Picking Customer Data from Clarify for CUSTOMER Table and verifying with other systems for synchronization

Customer Data from ClariFy will be picked and checked record by record for any missing or unmatched data in the following systems:

For Post Paid Customers PG – MDN-MIN-RSN-CAF combination, Service Status ADC – Pin code, Services Status Clarity – Service Status Clarify – Customer Contract

For Pre paid Customers

PG – MDN-RSN-CAF combination, Service Status Comverse – Customer Details Clarity – Service Status Clarify – Customer Contract

If data is not synchronized across these systems, customer record will not be created in ODS customer table. It will be moved to error log for synchronization action for source systems.

If the data is synchronized across systems, customer data will be inserted in CUSTOMER table constrained by the master tables.

All data for that customer from other sources will also be loaded in ODS at the same time. This will ensure that synchronized data pertaining to that customer only is loaded in the system.

The initial load will be done using Initial Load ETL and Initial Load TIBCO process that will do the following:

1. ETL Load process will load the Master Data2. Hold all the MACD messages while the initial load is completed so as not

to loose the changing status of information.

The cleansing of data might take longer than anticipated, as the extent of de-synchronization is not known. All system owners will be involved in the data cleansing effort on a record-by-record basis. It is expected that the cleansing will take four weeks time based on resolution from system owners.


7.4.ODS Development and Implementation

ODS is the data store that will have data defined in this document from EDM/Source Systems required for synchronized single view and tactical reporting.

ODS will have integrated data from different owner systems to get single view at one place.

ODS data model will capture details only to the extent it is required for query and reporting purposes.

8. Test Strategy


Clarify PG/Clarity ADC SAP

ODS

Customer Service Bill Collection

Fig. 2. Symbolic Representation of Data Integration in ODS


Planning

• Test Strategy

• Testing / Staging

Infrastructure

• Test Cycle Plan

• Integration Test

• UAT Plan

• Governance and

Approval Process

• Test Cases

• Application Code

• Documentation

• Unit Test Cases &

Results

• RIC systems

(Internal) and

Module Integration

Test Cases and

Results

• Link Test Plan and

Results

• Security Test Plan

and Results

• Regression Testing

• Functional/Business

Process Test Cases

& Results

• Test Database

Data Quality Tests

• Traceability

Document

• Batch Process

Testing

• Regression Testing

• Performance

Benchmarks and

test cases and

results

• Backup and

Recovery test cases

and Results

• System Monitor

/Alert Checks

• Replicated Staging

Environment Setup

• End User

Experience (Usage)

Feedback

• Navigation/Usability

Test Results

• Administrator /

Operational Tests

Transfer &

Configuration

• Configuration

Scripts

• Install Guides

System Monitors

• Fully Functional

Testing and Staging

Environment

• Test Case

Documentation

Including Results

Unit / Module TestingSystem /

Integration

Testing

Functional and

Data Integrity

Testing

Performance &

Fail over

Testing

End User

Acceptance

Testing

Testing

Fig. 3. Test Plan for ODS

9. Information in ODS

ODS will have the following information for customers:

Services Product/Tariff Plan/Rate Plan Channel/OTC Inventory (Handset Provisioned & Non Provisioned) Schemes Discount Promotion Customer Details (CAF, Handset Details) Payment (Initial, Later & Deposits) Bill Information Collection Customer Account Balance Unbilled Usage Inventory (Including Stock In-Transit) Master Database Fraud CRM (TT)

10.Source Systems for ODS

SAP

Inventory Data Channel Data Collection Data

Clarity

Service activation Status Data

Clarify

Customer Acquisition Form (CAF) Data MACD Data Payment Data

Portals


Payment Data MACD Data

PhoneGen

MACD Status Service activation Status Data

ADC

Bill Data (Without CDR’s) Bill Status (Open/Closed) Data Customer Account Balance Data Unbilled Usage Data

Master Data

SDCA MASTER LDCA MASTER CIRCLE MASTER BUSINESS CLUSTER MASTER PINCODE MASTER TOWN MASTER WAREHOUSE MASTER MATERIAL MASTER ZONE MASTER AREA MASTER PHONE MASTER MIN MASTER VANITY MASTER HANDSET MASTER AAA SDCA MASTER PRODUCT MASTER PROVISION MASTER ADJACENT SDCA MASTER BANK MASTER COLLECTION CENTRE MASTER COUNTRY CODE MASTER STATE MASTER STD MASTER VMS SDCA MASTER FRANCHISE PIN TOWN STATE MAS SAP STATE MAS COLLECTION CENTER OVER THE COUNTER (OTC) MASTER MAS SDCA MASTER CHANNEL PARTNER MASTER


11.ODS Project Plan


Sr.No. Description Start End

1 Functional (Wireless) 4-Oct-04 16-Jan-05

1.1 Functional Requirement Analysis 4-Oct-04 14-Oct-041.3 Reports & Dashboard 25-Oct-04 7-Nov-041.4 Synchronization Reports 29-Dec-04 5-Dec-041.5 Analyze Business Rules, Triggers & Actions 3-Jan-05 16-Jan-051.6 Analyze Re-Inserts (De-Duplication,

Householding, etc.)3-Jan-05 16-Jan-05

2 Integration (Wireless) 4-Oct-04 16-Jan-05

2.1 Logical Data Model 4-Oct-04 14-Oct-042.2 Synchronization Design 15-Nov-04 28-Nov-042.2.1 Synchronization Check Program Design 15-Nov-04 28-Nov-042.2.2 Subscribe regain Design 15-Nov-04 28-Nov-042.2.3 Standardize Backend Processes (Run &

Notification)15-Nov-04 28-Nov-04

2.2.4 Standardize Data Exchange Processes (email, Excel)

15-Nov-04 28-Nov-04


2.3 Data Integration Design 29-Nov-04 5-Dec-042.4 Initial Load Design 22-Nov-04 28-Nov-042.5 Design Business Rules, Triggers & Actions 3-Jan-05 16-Jan-052.6 Design Re-Inserts (De-Duplication, Householding,

etc.)3-Jan-05 16-Jan-05

3 Functional (Wireline) 6-Dec-04 2-Jan-05

3.1 Functional Requirement Analysis 6-Dec-04 19-Dec-043.3 Reports & Dashboard 13-Dec-04 19-Dec-043.4 Synchronization Reports 27-Dec-04 2-Jan-053.5 Analyze Business Rules, Triggers & Actions 3-Jan-05 16-Jan-053.6 Analyze Re-Inserts (De-Duplication,

Householding, etc.)3-Jan-05 16-Jan-05

4 Integration (Wireline) 6-Dec-04 2-Jan-05

4.1 Logical Data Model (Wireless DM Extension) 6-Dec-04 19-Dec-044.2 Synchronization Design 20-Dec-04 26-Dec-044.2.1 Synchronization Check Program Design 20-Dec-04 26-Dec-044.2.2 Subscribe regain Design 20-Dec-04 26-Dec-044.2.3 Standardize Backend Processes (Run &

Notification)20-Dec-04 26-Dec-04

4.2.4 Standardize Data Exchange Processes (email, Excel)

20-Dec-04 26-Dec-04

4.3 Data Integration Design 27-Dec-04 2-Jan-054.4 Initial Load Design 20-Dec-04 26-Dec-044.5 Design Business Rules, Triggers & Actions 3-Jan-05 16-Jan-054.6 Design Re-Inserts (De-Duplication, Householding,

etc.)3-Jan-05 16-Jan-05

5 Design & Development using HP Nonstop Suite of Products(Actual Dates to be provided by HP)

2-Jan-05 30-Apr-05

5.1 EAI, ETL & Reports Design (Tool Specific)5.2 EAI, ETL & Reports Development6 Testing (Actual Dates to be provided by HP) 2-Jan-05 30-Apr-05

6.1 Unit, Integration & Load Testing7 Deployment (Actual Dates to be provided by

HP)7.1 Operations Manual7.2 Administration Manual7.3 Production Ready

12.Resource Requirements


Functional & Integration Design

- Business Analyst/Project Manager- Data Modeler- Data/System Analyst

Deployment

This is a tentative resource profile list from HP that will be finalized once the proposal is accepted.

- Project Manager (HP and Abc Inc)


- Solution Architect (HP and Abc Inc)- System Analysts (HP and Abc Inc)- Technical Focal Points (Abc Inc specially for HLR, Customer- Care, IN, Provisioning, and Billing systems)- Logical Database Designer (HP)- Physical Database Designer (HP)- Data Loader designer and developer (HP)- ETL script developer (HP)- RTID Developer (HP)- Common infrastructure developer (Events, Error Messages etc.) (HP)- Subscription Service Developer (HP)- Test Library Developers (Test Plan for Unit, Integration, System, and- Acceptance; Test Framework, Test Case Design, Test code and script development)

(HP)- Software Configuration Management Technician (HP)- System Integrator (HP and Abc Inc)- Database Administrator (Abc Inc)- Network Administrator (Abc Inc)- Systems Manager (Abc Inc)- Production Planner (HP, Abc Inc)

13.Software & Hardware Requirements

HP Non Stop suite of products will be deployed as a complete hardware and software solution. HP has proposed following:

- NonStop hardware S8x and standard systems software (G06.23 or later)- NonStop WLS 8.1 SP2- HP NonStop Server Toolkit for Web Logic Server- NonStop DTE (optional, only if data transformation requirements are identified)- NonStop Server for Java 3.1 or later- NonStop SQL/MX 2.0 or later- JDBC/MX Driver 2.1 or later- NonStop ODBC/MX server 2.0 or later- NonStop RTID jar files and scripts- Trillium for de-duping and cleansing of customer data prior to loading into the

NonStop ZLEDS (optional, only if cleansing is an identified requirement)- Interface to ETL Tools (since Abc Inc is already using Ascential Datastage, we

recommend use of Genus HSDCI)- NonStop Data Loader to do the initial load of state and event info into the NonStop

ZLEDS- Fair Isaac Blaze Rules Engine- Subscription Services- Customized JMS Adapters to TIBCO- In order to do Unit and Stress testing of the initial system as it is built,

It will be necessary to build test drivers and interface simulators.


14.Risk Mitigation (Project Management Specific)

TABLE 1: Risk Factors and Mitigation

Risk Business or Technical

Impact(H, M, L)

Probability

Project Cancellation due to unexpected budget or resource withdrawals

Business High Low

Project Delays due to inaccurate estimations, scope, infrastructure or standards changes.

Business High Medium

Skill Set Gap(s) – due to changes in development language(s), platform, infrastructure support, standards, staff or function-driven technology requirements.

Technical High Medium

Missed Deadlines – due to Project Delays and affecting interdependent tasks and/or resource schedules

Technical Medium Medium

Excessive Costs – due to unanticipated changes in charge-backs, vendor charges for hardware and/or software, resource requirements, scope or specifications

Business Medium Medium

Low Deliverable(s) Quality – due to functionality below specification, turnaround or quality of data, navigation and the like.

Technical High Low

Use of New or Immature Technology – due to unanticipated requirements of the functionality, development or interaction with an

Technical High Low


interdependent application. Fails to meet Business Needs – due to changed requirements, inadequate specifications, or ineffective testing.

Business and Technical

High Low

Disruption of Processing or Data Loss – due to changed requirements, inadequate specifications, or ineffective testing.

Technical High Low

Business Changes – due to new or altered regulatory requirements, internal or external client needs, or changes to the core business, functions, or methods of Abc Inc.

Business Medium Medium

15.Constraints (Project Management Specific)

Table 2. Constraints

Constraints Priority

Project Funding HighStaffing HighPriorities MediumBusiness Involvement

High

Support Team Involvement

High


ods project plan v0

Documents