Potential Customer Data Model Solution   Telco
Upcoming SlideShare
Loading in...5
×
 

Like this? Share it with your network

Share

Potential Customer Data Model Solution Telco

on

  • 4,476 views

 

Statistics

Views

Total Views
4,476
Views on SlideShare
4,475
Embed Views
1

Actions

Likes
4
Downloads
156
Comments
0

1 Embed 1

http://www.linkedin.com 1

Accessibility

Categories

Upload Details

Uploaded via as OpenOffice

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

Potential Customer Data Model Solution Telco Document Transcript

  • 1. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Account structure approach Author: Roman Agaev Date: Monday, May 14, 2007 -1-
  • 2. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Contents 1 Abstract.......................................................................................................................3 2 Potential solutions.......................................................................................................4 2.1 Service & Billing Accounts represent the customer........................................4 2.1.1 Advantages............................................................................................4 2.1.2 Disadvantages........................................................................................4 2.2 Customer Account represents the customer.....................................................5 2.2.1 Advantages............................................................................................5 2.2.2 Disadvantages........................................................................................6 3 Criterions.....................................................................................................................6 3.1 Solution complexity.........................................................................................6 3.1.1 Computation complexity.......................................................................7 3.1.2 Time complexity...................................................................................7 3.2 Reliability.........................................................................................................7 3.3 Scalability.........................................................................................................7 3.4 Time to market.................................................................................................7 3.5 Simplicity.........................................................................................................7 3.6 Contiguity to OOB...........................................................................................7 4 Solution Matrix...........................................................................................................7 5 Conclusion...................................................................................................................8 5.1 Discussion........................................................................................................8 6 Appendixes..................................................................................................................8 -2-
  • 3. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Figures Figure 1-1: ERD of involved entities.............................................................................4 Figure 2-2: Schematic diagram of account hierarchy disposition (Billing & Service account)..........................................................................................................................5 Figure 2-3: Schematic diagram of account hierarchy disposition (Customer account). 6 1Abstract The main aim oh this document is formulating and providing an approach for account structure. The common approach declares that we have several different types of account: Service Service Aggregator Board Central Committee Billing Billing Aggregator Customer Decentralized Intermediary Insurance Company Planner Above types don't bound possible complexity of account hierarchy, but provide an ability of effective restriction for different entity instances to be used in undesired and unnecessary way (For example creation a billing profile for service account). Considering complexity of our case the following type are necessary for an implementation and will be used: Service – represents an account who really uses an asset Billing – represents an account who pays for an asset Customer – represents an account who uses and pays an asset simultaneously The following solutions for the account hierarchy are coming to cover any possible process within an implemented system. -3-
  • 4. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Figure 1-1: ERD of involved entities 2Potential solutions 2.1Service & Billing Accounts represent the customer The solution states that there is a necessity of having two account entries of different types tied together in order to represent one customer. The main reason for that is concept which is declaring, that billing account pays for an assets that belong to its service account. The approach assumes that every potential service account has at least one similar billing account, when the last one is holding the information regarding billing, financial, exemption, and payments profiles all together. 2.1.1Advantages The support of data model and oob1 functionality The existence of several functional point that are supports existing of defined profiles in oob applications 2.1.2Disadvantages The approach leads to undesired growth of account hierarchy The approach leads to computational and as consequence time complexity 1 Out of the box -4-
  • 5. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. Figure 2-2: Schematic diagram of account hierarchy disposition (Billing & Service account) 2.2Customer Account represents the customer The solution assumes that there is no actual necessity of having two different account entries in order to support concept of separation billing and service properties of the same customer and states that customer account can be used in order to achieve any required functionality. The data model provided at the beginning of this document states that there is a supported many to many relationship between two given account entries and the relationship supports an ability of multiple billing account per each account entry. 2.2.1Advantages Dramatically decreases complexity of account hierarchy Prevents undesired growth of account hierarchy The approach supported by data model and oob functionality -5-
  • 6. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. The existence of several functional point that are supports existing of defined profiles in oob applications 2.2.2Disadvantages In some circumstances simplifies to much an existed reality Figure 2-3: Schematic diagram of account hierarchy disposition (Customer account) 3Criterions 3.1Solution complexity The following section of document is coming to analyze two different approaches and prove the statement of analysis. -6-
  • 7. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. 3.1.1Computation complexity From this point of two approaches quite different due to relationship overhead in first one. That relationship in some circumstances may lead to undesired and heavy sql statements during the gui2 development. 3.1.2Time complexity As consequence of computational complexity the predicted time complexity of first solution much heavy than the parallel one of the second solution 3.2Reliability Two approaches have very similar ability to be reliable, but the second one in several circumstances can by less reliable because the solution covers less possible implications. 3.3Scalability Two approaches have the same ability of scalability. 3.4Time to market Two approaches have the same ability to be provided to a market as soon as possible. 3.5Simplicity The second approach wins within this criterion, because it simplifies the concept. 3.6Contiguity to OOB Two approaches own the same contiguity to oob. 4Solution Matrix Table 4-1: Solution/Criterions matrix Solution Comput Time Reliab Scalab Time to Simpli Contiguity Total Criterion ational Complex ility ility market city to OOB Comple ity xity B&S 0 0 1 1 1 0 1 4 C 1 1 0 1 1 1 1 6 2 Graphic user inerface -7-
  • 8. Roman Agaev, M.Sc, PMP Owner, Supra Information Technology ltd. 5Conclusion The conclusion of the analysis states that the combination of two different approaches can be used in order to achieve an appropriate complexity and possible functionality, when the private customer will be represented by account of customer type, and corporate customer will be represented by service and billing account entries that in fact will represent different division within the customer. 5.1Discussion The state of conclusion paragraph is not mono meaningful, because none of proposed solutions wins in every defined criterions. The combined solution assemblies the approaches and gives an opportunity to every one of it to come to its meaning within the boundaries of the combination In any case the solution can be sophisticated or very simple, but must provide simplification in terms of its utilization/usage. Otherwise there is a possibility of getting not linear growth of computational complexity and all its consequences during the development stage of project. 6Appendixes Siebel bookshelf -8-