EDM ODS Document
-
Upload
api-3716519 -
Category
Documents
-
view
201 -
download
1
Transcript of 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 Page 2 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
Abc Inc Page 3 of 90Enterprise Information Architecture
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.
Abc Inc Page 4 of 90Enterprise Information Architecture
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.
Abc Inc Page 5 of 90Enterprise Information Architecture
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.
Abc Inc Page 6 of 90Enterprise Information Architecture
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
Abc Inc Page 7 of 90Enterprise Information Architecture
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.
Abc Inc Page 8 of 90Enterprise Information Architecture
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.
Abc Inc Page 9 of 90Enterprise Information Architecture
Abc Inc Page 10 of 90Enterprise Information Architecture
Logical Data Hierarchy
EDW
ODS
ODS
Business Application
Business Application
Business Application
Business Application
Business Application
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
Abc Inc Page 11 of 90Enterprise Information Architecture
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:
Abc Inc Page 12 of 90Enterprise Information Architecture
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.
Abc Inc Page 13 of 90Enterprise Information Architecture
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.
Abc Inc Page 14 of 90Enterprise Information Architecture
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
Abc Inc Page 15 of 90Enterprise 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
Abc Inc Page 16 of 90Enterprise Information Architecture
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.
Abc Inc Page 17 of 90Enterprise Information Architecture
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.
Abc Inc Page 18 of 90Enterprise Information Architecture
Add extra functions
Abc Inc Page 19 of 90Enterprise Information Architecture
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.
Abc Inc Page 20 of 90Enterprise Information Architecture
Abc Inc Page 21 of 90Enterprise Information Architecture
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
Abc Inc Page 22 of 90Enterprise Information 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
EDM/ODS & Reporting Architecture
Abc Inc Page 23 of 90Enterprise Information Architecture
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
EDM/ODS & Reporting Architecture
Abc Inc Page 24 of 90Enterprise Information Architecture
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
EDM/ODS & Reporting Architecture
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
Abc Inc Page 25 of 90Enterprise Information Architecture
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:
Abc Inc Page 26 of 90Enterprise Information Architecture
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.
Abc Inc Page 27 of 90Enterprise Information Architecture
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.
Abc Inc Page 28 of 90Enterprise Information Architecture
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
Abc Inc Page 32 of 90Enterprise Information Architecture
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
Abc Inc Page 33 of 90Enterprise Information Architecture
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.
Abc Inc Page 34 of 90Enterprise Information Architecture
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.
Abc Inc Page 35 of 90Enterprise Information Architecture
Abc Inc Page 36 of 90Enterprise Information Architecture
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.
Abc Inc Page 37 of 90Enterprise Information Architecture
Abc Inc Page 38 of 90Enterprise Information Architecture
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.
Abc Inc Page 39 of 90Enterprise Information Architecture
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
Abc Inc Page 40 of 90Enterprise Information Architecture
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
Abc Inc Page 41 of 90Enterprise Information Architecture
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
Abc Inc Page 42 of 90Enterprise Information Architecture
Logical Model for Customer
Abc Inc Page 43 of 90Enterprise Information Architecture
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.
Abc Inc Page 44 of 90Enterprise Information Architecture
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.
Abc Inc Page 45 of 90Enterprise Information Architecture
Logical Model For Address, Locations & Contacts
Address Master
Contact Person Master
Contact Type
Location And Contact
Location Master
Location Type
Abc Inc Page 46 of 90Enterprise Information Architecture
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.
Abc Inc Page 47 of 90Enterprise Information Architecture
Logical Model For Service
Customer
Location And Contact
Service Details
Location Master
Contact Person Master
Contact Type
Service Master
Abc Inc Page 48 of 90Enterprise Information Architecture
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.
Abc Inc Page 49 of 90Enterprise Information Architecture
Logical Model For Billing
Billing Account
Customer
Corporate Hierarchy Level
Location And Contact
Order
Service Details
Service Master
Billing Node Type
Abc Inc Page 50 of 90Enterprise Information Architecture
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.
Abc Inc Page 51 of 90Enterprise Information Architecture
Combined Customer, Services & Billing Logical Model
Customer
Billing Account
Contact Person Master
Order
Service Details
Location Type
Address Master
Customer Group
Contact Type
Location And Contact
Corporate Hierarchy Level
Location Master
Service Master
Billing Node Type
Abc Inc Page 52 of 90Enterprise Information Architecture
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.
Abc Inc Page 53 of 90Enterprise Information Architecture
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.
Abc Inc Page 54 of 90Enterprise Information Architecture
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
Abc Inc Page 55 of 90Enterprise Information Architecture
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
Abc Inc Page 56 of 90Enterprise Information Architecture
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.
Abc Inc Page 57 of 90Enterprise Information Architecture
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
Abc Inc Page 58 of 90Enterprise Information Architecture
Billing view from Partial EDM
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)
CONTRACT
BILLING ACCOUNT NO (FK)SERVICE ID (FK)PRODUCT TYPE CODE (FK)TARRIF BUNDLE CODE (FK)
GROUP ACCOUNTGROUP ACCOUNT NO
INVOICE DETAILSINVOICE NO
INVOICE DATEBILLING ACCOUNT NO (FK)
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)
ADDRESS TYPE MASTERADDRESS TYPE CODE
PINCODE MASTERPINCODE
CITY CODECITY DESCSTATE CODESTATE DESCCOUNTRY CODECOUNTRY DESC
PRODUCT MASTERPRODUCT TYPE CODE
PRODUCT TYPE DESC
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
ADDRESS MASTERADDRESS ID
ADD LINE1ADD LINE2PINCODE (FK)EMAIL ID
SERVICE STATUS
SERVICE NODE ID (FK)SERVICE ID (FK)FACILITY STATUS
Currently Not Covered in Partial EDM
Call Origin/Destination not covered.
Abc Inc Page 59 of 90Enterprise Information Architecture
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
Abc Inc Page 60 of 90Enterprise Information Architecture
Order view from Partial EDM
CONTRACT
BILLING ACCOUNT NO (FK)SERVICE ID (FK)PRODUCT TYPE CODE (FK)TARRIF BUNDLE CODE (FK)
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)
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 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)
ADDRESS TYPE MASTERADDRESS TYPE CODE
ORDER DETAILS
TARRIF BUNDLE CODE (FK)PRODUCT TYPE CODE (FK)SERVICE ID (FK)CAF/ORDER NUMBER (FK)
PINCODE MASTERPINCODE
CITY CODECITY DESCSTATE CODESTATE DESCCOUNTRY CODECOUNTRY DESC
BILLING ACCOUNTBILLING ACCOUNT NO
CUSTOMER ACCOUNT NO (FK)PRINT STACK CODE (FK)BILL_CYCLEDEPOSIT BALANCEACCOUNT BALANCE
ADDRESS MASTERADDRESS ID
ADD LINE1ADD LINE2PINCODE (FK)EMAIL ID
OTC MASTEROTC CODE
Currently Not Covered in Partial EDM
Supplier Details
Abc Inc Page 61 of 90Enterprise Information Architecture
Payment Analysis in HP OneView
Bill To Address
Business Attributes
Customer
Customer Segment
Service Address
Customer Contract
Geography
Sales Channel
Subscription
Time
Payment
Abc Inc Page 62 of 90Enterprise Information Architecture
Payment view from Partial EDM
CONTRACT
BILLING ACCOUNT NO (FK)SERVICE ID (FK)PRODUCT TYPE CODE (FK)TARRIF BUNDLE CODE (FK)
SERVICE NODE DETAILS SERVICE NODE ID
SDCA CODE (FK)MDNRSNMINHANDSET CODE (FK)BILLING ACCOUNT NO (FK)CUSTOMER ACCOUNT NO (FK)STD CODE
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)
BILLING ACCOUNTBILLING ACCOUNT NO
CUSTOMER ACCOUNT NO (FK)PRINT STACK CODE (FK)BILL_CYCLEDEPOSIT BALANCEACCOUNT BALANCE
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
ADDRESS MASTERADDRESS ID
ADD LINE1ADD LINE2PINCODE (FK)EMAIL ID
ADDRESS TYPE MASTERADDRESS TYPE CODE
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)
PINCODE MASTERPINCODE
CITY CODECITY DESCSTATE CODESTATE DESCCOUNTRY CODECOUNTRY DESC
HP OneView Payment Analysis Covered Completely
Abc Inc Page 63 of 90Enterprise Information Architecture
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.
Abc Inc Page 64 of 90Enterprise Information Architecture
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.
Abc Inc Page 65 of 90Enterprise Information Architecture
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.
Abc Inc Page 66 of 90Enterprise Information Architecture
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.
Abc Inc Page 67 of 90Enterprise Information Architecture
Abc Inc Page 68 of 90Enterprise Information Architecture
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.
Abc Inc Page 69 of 90Enterprise Information Architecture
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.
Abc Inc Page 70 of 90Enterprise Information Architecture
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.
Abc Inc Page 71 of 90Enterprise Information Architecture
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
Abc Inc Page 72 of 90Enterprise Information Architecture
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
Abc Inc Page 73 of 90Enterprise Information Architecture
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.
Abc Inc Page 74 of 90Enterprise Information Architecture
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.
Abc Inc Page 75 of 90Enterprise Information Architecture
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
Abc Inc Page 76 of 90Enterprise Information Architecture
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.
Abc Inc Page 77 of 90Enterprise Information Architecture
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.
Abc Inc Page 78 of 90Enterprise Information Architecture
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.
Abc Inc Page 79 of 90Enterprise Information Architecture
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
Abc Inc Page 80 of 90Enterprise Information Architecture
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)
Abc Inc Page 81 of 90Enterprise Information Architecture
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
Abc Inc Page 82 of 90Enterprise Information Architecture
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
Abc Inc Page 83 of 90Enterprise Information Architecture
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
Abc Inc Page 84 of 90Enterprise Information Architecture
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
Abc Inc Page 85 of 90Enterprise Information Architecture
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
Abc Inc Page 86 of 90Enterprise Information Architecture
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
Abc Inc Page 87 of 90Enterprise Information Architecture
Abc Inc Page 88 of 90Enterprise Information Architecture
WIRELINE APPLICATION ARCHITECTURE
Abc Inc Page 90 of 90Enterprise Information Architecture