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 Page 2 of 49

INDEX
1.Purpose of the Document.................................................................................4

2.Purpose of the ODS...........................................................................................4
3.Users of ODS......................................................................................................4
4.Assumptions and Constraints (RIC ODS Specific)........................................7
5.ODS Program Model..........................................................................................8
6.Execution Plan.................................................................................................10
7.ODS Approach..................................................................................................11
7.1.Data Model for ODS....................................................................................11
7.2.Synchronization ..........................................................................................12
7.3.Initial Load ..................................................................................................13
7.4.ODS Development and Implementation.....................................................14
8.Test Strategy.....................................................................................................15
10.Information in ODS........................................................................................18
11.Source Systems for ODS..............................................................................18
14.ODS Project Plan...........................................................................................28
15.Resource Requirements...............................................................................32
16.Software & Hardware Requirements...........................................................33
17.Risk Mitigation (Project Management Specific).........................................34
18.Constraints (Project Management Specific)...............................................35

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 fulfilled

CAF – Not OTAFed
Amount paid and Payable not equal report at the time of customer
acquisition
Address Verification (AV) Status and its aging
Monitor ILD/NLD activation
Report Name changes
Track Address change and new AV status
Adjustments tracking based on:
o First 30 days of customer
o Based on Value
o Based on User ID
Trouble Tickets generated with 30 days of fulfillment
First bill generation and tracking
User ID based action tracking for adjustments
Voucher 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.

Fig.1 ODS Program Model
Program Planning and Management

Program Program Documentation and Control
Management Budget Monitoring
Business ODS Infrastructure/

Analysis Database S/W Program Development Production
Project Design Design & Testing Support
Management
Review Current Data ETL and TIBCO Infrastructure

being TIBCO Process Process hardware and
exchanged Create Logical Data TIBCO Adapter/IM Development and software
Data & Process Model (ERD) Application (For modification Database
Flow Diagrams Synchronization ODS) Adapter Modification Implementation
Identify Data not Tracking Data Model ETL and Development support
being Physical Data Synchronization Sync Process Application support
exchanged Modeling Development Reporting & Query
Design
but required in CIM Mapping Error Handling Testing Management
ODS. Technical Metadata Deployment
Outages Recovery
Define Business Meta Reports & Dashboard Initial Data Load
Data Design Production
Define Owner of
Data, Window
& Access of
Owner
Systems
Project planning
Prioritization
Release Project Planning and Tracking
Management Post Activity Review
Project Plan – ODS Phase 1 Page 9 of 49

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 1
Wireless (Corporate & Consumers)
Scope 2
Enterprise Wireline
Scope 3
Business 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 kickoff
2. Gather and document Technical Requirements
3. Gather and document Exception Processing Requirements
4. Gather and document info (interfaces, protocols used, message
formats) on pre-identified contributing applications
5. Development system procured and configured
6. Solution High Level Design
7. NonStop ZLE Data Store – Logical Design
8. NonStop ZLE Data Store – Physical Design
9. RTID Customization (metadata definitions, subscription service
development)
10. Rules Definition and RE Implementation
11. Interface Simulator Development
12. Test Library Development
13. TIBCO JMS Configuration
14. NonStop ZLEDS Load complete for test Environments
15. Unit and Integration testing using simulators and test data
16. Development
17. Integration Test Environment setup at Abc Inc
18. 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 Groups
22. Go Live Decision
23. Controlled Production Environment Preparation including loading
customer data
24. 30-day Controlled Production Run
25. Controlled Production Run Assessment
26. 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.
1.
Fig. 2. Symbolic Representation of Data Integration in ODS
Clarify PG/Clarity ADC SAP
Customer Service Bill Collection
ODS

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 Data

2. 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.
Fig. 2. Symbolic Representation of Data Integration in ODS
Clarify PG/Clarity ADC SAP
Customer Service Bill Collection
ODS
8. Test Strategy
Testing
System / Functional and Performance & End User Transfer &

Planning Unit / Module Testing
Integration Data Integrity Fail over Configuration
Testing Testing Testing Testing
• Test Strategy • Application Code • RIC systems • Functional/Business • Performance • Replicated Staging • Configuration
• Testing / Staging • Documentation (Internal) and Process Test Cases Benchmarks and Environment Setup Scripts
Infrastructure • Unit Test Cases & Module Integration & Results test cases and • End User • Install Guides
• Test Cycle Plan Results Test Cases and • Test Database results Experience (Usage) System Monitors
• Integration Test Results Data Quality Tests • Backup and Feedback • Fully Functional
• Link Test Plan and • Traceability Recovery test cases • Navigation/Usability Testing and Staging
• UAT Plan Results Document and Results Test Results Environment
• Governance and • Security Test Plan • Batch Process • System Monitor • Administrator / • Test Case
Approval Process and Results Testing /Alert Checks Operational Tests Documentation
• Test Cases • Regression Testing • Regression Testing Including Results
Fig. 3. Test Plan for ODS

9.

10. 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)
11. 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
12.

13.

14. 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-04
1.3 Reports & Dashboard 25-Oct-04 7-Nov-04
1.4 Synchronization Reports 29-Dec-04 5-Dec-04
1.5 Analyze Business Rules, Triggers & Actions 3-Jan-05 16-Jan-05

1.6 Analyze Re-Inserts (De-Duplication, 3-Jan-05 16-Jan-05
Householding, etc.)
2 Integration (Wireless) 4-Oct-04 16-Jan-05
2.1 Logical Data Model 4-Oct-04 14-Oct-04
2.2 Synchronization Design 15-Nov-04 28-Nov-04
2.2.1 Synchronization Check Program Design 15-Nov-04 28-Nov-04
2.2.2 Subscribe regain Design 15-Nov-04 28-Nov-04
2.2.3 Standardize Backend Processes (Run & 15-Nov-04 28-Nov-04
Notification)
2.2.4 Standardize Data Exchange Processes (email, 15-Nov-04 28-Nov-04
Excel)
2.3 Data Integration Design 29-Nov-04 5-Dec-04
2.4 Initial Load Design 22-Nov-04 28-Nov-04
2.5 Design Business Rules, Triggers & Actions 3-Jan-05 16-Jan-05
2.6 Design Re-Inserts (De-Duplication, Householding, 3-Jan-05 16-Jan-05
etc.)
3 Functional (Wireline) 6-Dec-04 2-Jan-05
3.1 Functional Requirement Analysis 6-Dec-04 19-Dec-04
3.3 Reports & Dashboard 13-Dec-04 19-Dec-04
3.4 Synchronization Reports 27-Dec-04 2-Jan-05
3.5 Analyze Business Rules, Triggers & Actions 3-Jan-05 16-Jan-05
3.6 Analyze Re-Inserts (De-Duplication, 3-Jan-05 16-Jan-05
Householding, etc.)
4 Integration (Wireline) 6-Dec-04 2-Jan-05
4.1 Logical Data Model (Wireless DM Extension) 6-Dec-04 19-Dec-04
4.2 Synchronization Design 20-Dec-04 26-Dec-04
4.2.1 Synchronization Check Program Design 20-Dec-04 26-Dec-04
4.2.2 Subscribe regain Design 20-Dec-04 26-Dec-04
4.2.3 Standardize Backend Processes (Run & 20-Dec-04 26-Dec-04
Notification)
4.2.4 Standardize Data Exchange Processes (email, 20-Dec-04 26-Dec-04
Excel)
4.3 Data Integration Design 27-Dec-04 2-Jan-05
4.4 Initial Load Design 20-Dec-04 26-Dec-04
4.5 Design Business Rules, Triggers & Actions 3-Jan-05 16-Jan-05
4.6 Design Re-Inserts (De-Duplication, Householding, 3-Jan-05 16-Jan-05
etc.)
5 Design & Development using HP Nonstop 2-Jan-05 30-Apr-05
Suite of Products
(Actual Dates to be provided by HP)
5.1 EAI, ETL & Reports Design (Tool Specific)
5.2 EAI, ETL & Reports Development
6 Testing (Actual Dates to be provided by HP) 2-Jan-05 30-Apr-05
6.1 Unit, Integration & Load Testing
7 Deployment (Actual Dates to be provided by
HP)

7.1 Operations Manual
7.2 Administration Manual
7.3 Production Ready
15. 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)
16. 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.
17. Risk Mitigation (Project Management Specific)
TABLE 1: Risk Factors and Mitigation
Business or Impact
Risk Probability
Technical (H, M, L)
Project Cancellation due to Business High Low

unexpected budget or resource
withdrawals
Project Delays due to inaccurate Business High Medium
estimations, scope, infrastructure or
standards changes.
Skill Set Gap(s) – due to changes Technical High Medium
in development language(s),
platform, infrastructure support,
standards, staff or function-driven
technology requirements.
Missed Deadlines – due to Project Technical Medium Medium
Delays and affecting

interdependent tasks and/or
resource schedules
Excessive Costs – due to Business Medium Medium
unanticipated changes in charge-
backs, vendor charges for
hardware and/or software, resource
requirements, scope or
specifications
Low Deliverable(s) Quality – due Technical High Low
to functionality below specification,
turnaround or quality of data,
navigation and the like.
Use of New or Immature Technical High Low
Technology – due to unanticipated
requirements of the functionality,
development or interaction with an
interdependent application.
Fails to meet Business Needs – Business and High Low
due to changed requirements, Technical
inadequate specifications, or
ineffective testing.
Disruption of Processing or Data Technical High Low
Loss – due to changed
requirements, inadequate
specifications, or ineffective testing.
Business Changes – due to new Business Medium Medium
or altered regulatory requirements,
internal or external client needs, or
changes to the core business,
functions, or methods of Abc Inc.
18. Constraints (Project Management Specific)
Table 2. Constraints
Constraints Priority
Project Funding High

Staffing High
Priorities Medium
Business High
Involvement
Support Team High
Involvement


ODS Project Plan V0

Enviado por

Dados do documento

Descrição original:

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ODS Project Plan V0

Enviado por

Direitos autorais:

Formatos disponíveis

ODS-Data Synchronization Project Plan & Resource Requirement

ODS-Data Synchronization Project Plan &

To Action* Due Date Phone/Fax

Project Plan – ODS Page 2 of 49

1.Purpose of the Document.................................................................................4

Project Plan – ODS Page 3 of 49

2. Purpose of the ODS

The business purpose of the ODS is to:

 Integrate data and provide a single view of customer

 Synchronize all service and revenue affecting parameters

 Continue to improve visibility and lead-time (detection, propagation and

ODS will provide:

 Real time data integration to the extent possible on TIBCO

The users of the ODS are:

Project Plan – ODS Page 4 of 49

 Order and Fulfillment

 Recovery of revenue losing de-synchronization can be affected by the

The RA users of ODS will get following views:

CAF – Logged in but not fulfilled

Project Plan – ODS Page 5 of 49

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

 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

Project Plan – ODS Page 6 of 49

1. The extent of de-synchronization in RIC systems is not known. This will

3. ODS is primarily dependent on the TIB data exchange mechanism. It is

4. The synchronization process cannot be achieved in isolation by ODS. All

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

Project Plan – ODS Page 7 of 49

15. It is assumed that the de-synchronization status reported by ODS will

5. ODS Program Model

Project Plan – ODS Page 8 of 49

Program Planning and Management

Business ODS Infrastructure/

Review Current Data ETL and TIBCO Infrastructure

Project Plan – ODS Phase 1 Page 9 of 49

The proposed Execution Plan is:

Functional & Integration Architecture

Final plan to be provided by HP

HP Proposed plan is as follows.

Project Plan – ODS Phase 1 Page 10 of 49

The ODS project consists of following activities:

7.1. Data Model for ODS

Fig. 2. Symbolic Representation of Data Integration in ODS

Clarify PG/Clarity ADC SAP

Customer Service Bill Collection

Project Plan – ODS Phase 1 Page 11 of 49

The synchronization strategy will consist of following:

Project Plan – ODS Phase 1 Page 12 of 49

Initial load in ODS focuses on synchronization of data as missing or unmatched

Initial load in ODS will be in following sequence:

1. All Master Data Tables

2. Picking Customer Data from Clarify for CUSTOMER Table and

For Post Paid Customers

Project Plan – ODS Phase 1 Page 13 of 49

For Pre paid Customers

− PG – MDN-RSN-CAF combination, Service Status

If the data is synchronized across systems, customer data will be inserted in

1. ETL Load process will load the Master Data

7.4. ODS Development and Implementation