You are on page 1of 16

SAP Mass BILLING SOLUTION FOR TELECOMMUNICATIONS

we know they know

or Event Detail Records (EDRs) and in handling the complex convergent invoicing. flexibility and a willingness to collaborate with other contributors in the value chain are critical – both for creating new revenue opportunities as well as reducing risk and operating expense – if providers are to maintain their industry leadership. Transactions generated from multiple sources (such as phones. in the telecommunications scenario. These are the findings of a recent survey of today’s telecommunications industry leaders. used to support these new flexible business processes. New business models will be needed to keep abreast of this volatile industry. business models which will allow providers to combine strategic assets and customer relationships with market innovations. shops and public transport pass cards) can include payment requirements to multiple providers. A business model for the future The emergence of new ecosystems of Internet-based communication service providers. road toll and parking garages. Theater. Greater speed. leads to an explosion in billing transaction volumes. A solutions architecture meets exceptional demand The incremental charging model. Sponsoring M-commerce Game SaaS Merchants Music SW Vendor Video Info Providers Merchants Loyalty Prog Stocks Advertisment Ticket Services Smartphones SUPPLY Service Provider Personal Home / SoHo SMEs Enterprise Public Sector Mobile Phones PULL Desktops Laptops Content Connectivity Community Figure 1 2 . pre-/post-pay.Evolution brings new challenges IBM and SAP investigate the new challenges brought on by business process evolution in the telecommunications industry and demonstrate the viability of a new cross-industry high-volume Consume-to-Cash architecture and solution for meeting these challenges. along with new technology and regulatory drivers are providing a catalyst for unprecedented change in the traditional telecommunications industry. wholesalers and interconnect partners. 1) ANY CONTENT Application Developers Content Providers Merchants ANYWHERE ANY DEVICE Airlines.. The transition to IP-based networks and convergence in its different forms (fixed-mobile. This solution allows for bundling of services and devices which are becoming key to the telecom industry evolution –thus increasing revenue and customer retention by offering new services and products (see Fig. For example.. to name only a few examples) creates an increasing need for flexibility and performance in the systems handling the associated incremental charging events. This can also result in a omplex payment scenario composed of numerous steps. the Internet. SAP Convergent Invoicing is designed to meet the requirements of these new business processes. the revenue collected may generate payments to various parties such as content owners. Merchants Bonus Points Micro-payments Small Payments Cinema.

music downloads. This is a significant IT challenge – and IBM and SAP provide the solution. 2). public transport. One common denominator found in these industries is the sheer volume of billing transactions which result from the business model: small incremental charging events generated by a huge customer base (see Fig. the supporting infrastructure used to master the most demanding scenarios being faced by the industry today and present results of a recent solution scalability and performance proof of concept. Architecture of the SAP solution SAP’s solution for mass billing addresses industry implementations as diverse as voice telephony.000 Customers EDR Contract Account Debit Credit Road Tolls GL Account Debit Credit Smart Cards Figure 2 Handling these mass volumes requires the creation of a highly scalable billing and invoicing solution. and postal services. road and congestion charging. 3 BW Update CO Update GL Update Music Downloads EDR Vendor Invoicing Vendors and 3rd party . Technical Systems Contract Accounts Receivable and Payable Customer Invoicing Customer Payments Mobile Millions of EDRs per day EDR 10.000. efficiently integrated into a highperformance infrastructure.A cross-industry mass billing solution In this document we take a look at the solution design.

EDRs) are transferred to the SAP ERP platform using an API (application programming interface) provided by SAP. etc. delivering a real value-add. from various billing systems. Designed for now – architected for the future The system provides a powerful backbone that helps to keep the business compliant with present regulatory requirements. they are stored. 4 . and from sources outside the Telco operator. The contract account is the level at which invoicing and A/R treatment (payment. aggregated with the next bill cycle. SAP ERP Consume-to-Cash Billing Account EDR EDR 1 Contract Account FI-CA Document Inbound EDR 2 Invoice PreProcessing 3 Invoice Creation 4 Print Out EDR Billing Document Invoicing Document Figure 3 The incremental charging events (Event Detail Records. and then invoiced. we look at the example of a mobile service provider.) as the widely adopted SAP RM-CA solution for contracts accounts receivable and payable handling of SAP ERP 6. It allows for an easy addition of new services and their related EDR types. while providing a solution that is able to scale up rapidly and costeffectively. etc. and the contract account is linked to the individual or company that owns the mobile device. The solution is able to perform consolidated invoicing for any number of services from different providers and send a single invoice to each account holder. Each subscription contract and its associated SIM card are assigned to one billing account. One or multiple billing accounts can be assigned to a contract account. dunning. and is able to adjust to the specific implementation requirements. To better understand some of the design features enabling both business flexibility and system performance. Several systems can feed into a single convergent invoicing system – for example.Handling massive volumes SAP Convergent Invoicing uses the same platform and technical concepts (eg. orders from sales and distribution systems.0. and can be easily adapted to accommodate the future requirements. This architecture offers great adaptability and flexibility. the Event Detail Records (records pertaining to the incremental charging event – for example a mobile call) pass through the Event Detail Handling engine for inbound processing and aggregation This engine must be able to store.) takes place As part of the Invoice Pre-Processing component of the solution. It offers integration with SAP CRM (Customer Relationship Management) and Business Intelligence. Here. The solution allows interoperability with other service partners. is absolutely independent of the external technology used to collect the EDR. This can greatly simplify process management and reduce costs. 3). handle and process the millions of records received by the upstream rating and charging systems on a daily basis (see Fig. parallelization. and can be easily extended.

or verify a first-of-a-kind high-end implementation using scalable IBM infrastructure. which can help first customers in dealing with their sizing and implementation challenges. the total solution has to scale. verifying their validity. but refers to the overall solution harmony. 5 . or specific and unique customer requirements. These proof points reduce risk for customer implementations by ensuring the stability. SAP and IBM conducted a proof of concept (PoC) to test the performance and scalability of SAP Convergent Invoicing to ensure that the volumes being targeted could indeed be managed. At the request of the SAP Service Industries sector.IBM and SAP collaborate to meet new industry requirements Integrated solution – the architecture Contract Account EDR EDR EDR Debit Credit Customer Invoicing Customer Payments Network Mediation Rating Invoice PreProcessing Invoice Creation Accounts Receivable Figure 4 To meet the volumes of data predicted for this business model. The PoC was a collaborative project. Proving the solution fits the real-life requirements The PoC targets are taken from the combined “real-world requirements” coming from multiple active engagements. completed within the scope of the IBM and SAP Alliance Co-Innovation Initiative for Industry Solutions. Scalability is the sum of the application designs and the infrastructure’s ability to meet the applications’ needs. Such projects can pave the way for a new SAP product rollout. This is not limited to the raw processing power of a single CPU. These PoCs implement current best practices and recommendations for the application and infrastructure. application to infrastructure. and providing “end to end best practice” recommendations for the overall solution implementation. These PoCs follow a step-wise scalability design to understand the effects and requirements of increasing load. scalability and performance of the application design. rather than simulated load. creating reusable collateral around a new SAP product or “first-of-a-kind” design. This approach enables a single PoC to provide realistic baseline input for many different customer situations.

SAP CRM SAP CRM Sales & Customer Care Multi-Channel Sales Financial Customer Care & Dispute Management Order & Contract Management SAP ERP SAP ERP Consume-to-Cash Aggregated EDRs Billing / Contract Accounts Invoice EDRPreProcessing Invoice Creation Subledger Postings A/R & Collections SAP ERP Enterprise Services GL Postings General Ledger Activation SAP NetWeaver SAP BPM (Business Process Mgmt. and the size of the customer base (billing and contract accounts).Architecture – SAP Convergent Invoicing The insights gained by the PoC regarding achievements and resource requirements of SAP Convergent Invoicing apply to the volume of incremental charging events (EDRs) to be handled. and not to a specific industry use case.) Business Agreement Portal Business Warehouse Rated EDRs Network Provisioning Network Data Collection Usage Mediation Mediation Unrated EDRs Rating Engine EDR Rating Figure 5 6 . 5). It is therefore possible to apply the PoC results to various industry use cases according to volume and data model requirements (see Fig.

6). and which needed to provide same-day billing. prepare files to be sent to banks Dunning proposal Creation of list with customers that didn’t pay in time Dunning activity Creation of dunning letters Correspondence printing Print letters to the customer for installment plans and returns. The maximum window for processing was set at between eight and ten hours (see Fig. to revenue accounts (after service delivery) Return processing Upload of failed payments from house bank Payment lot processing Upload of incoming payments from house bank Bank Figure 6: ‘Service to cash’ within the billing system . the EDRs created by the transfer process were aggregated to the appropriate billing accounts in the Invoice PreProcessing step. 7 .the ten processing steps of the PoC To ensure high-end throughput. Inbound interface Upload of incoming EDR records EDR billing Billing of EDR records Convergent Invoicing Invoicing of billed EDR records Payment run Balancing open items. security deposit request Deferred Revenue Posting from deferred rev. In the PoC. each of which had 50 incremental charging records (EDRs) per day. creation of files to be transferred to house bank for direct debit customers Bank file creation Payment medium program. and billing documents were created.PoC reference model – defining challenges and targets The reference model depicted a “service to cash” business process with one million business accounts. the PoC focused on the new business processes that handle the mass volumes for billing and convergent invoicing. The Invoice Creation step merged all billing documents from multiple sources into invoice documents for each contract account. The data-flow into the system needed to be able to handle extremely high volumes of raw input coming from the collection points as rated Event Detail Records.

5 hours. Reference Run 1. The peak volume was run using between 120 -140 parallel processes to demonstrate the capabilities of the application design to scale out over the available infrastructure.886.373.5 Hrs .5 hours. Using parallelization. we could demonstrated that the system was able to deliver end-to-end processing of one million billing accounts and 50 million EDRs in 1. a variety of use cases can be derived and their performance. 50 million EDRs The chart shows the physical resources used per step to process the billing volume in 1.Physical CPU-Load per Business Step 120000 100000 74601 70141 82506 83360 50936 80000 SAPs 60000 40000 20000 14448 0 45219 39357 24983 24983 11401 14974 5111 5715 3071 24198 17583 17647 11635 11603 yR un ed le ct t Pr o d oc er n rin Pr yM at rrP bo nn nA rd Fi Bi In APPS DB-CI In vC Business Step Figure 8: Reference model: 1 million accounts.219 4.582.8).418 9.626 Object type Event Detail Records Billing Accounts Billing Accounts Contract Accounts Contract Accounts Figure 7: Critical path steps and volume achievement Proving application scalability was one major target for the PoC. we reduced the 8 hour window to 1.413 2. 8 Co vP Ba Du Du n Pa In Pa De f llO re re nk Re un io v . then the solution is limited in capacity and no amount of additional hardware can effectively remedy this. if there are inherent bottlenecks.5 hours by spreading the load over more CPU resources (see Fig. This is depicted in SAPS (SAP Application Performance Standard) broken down over the two major components: database and application servers. scaling options and system resource requirements assessed. If the application design does not scale.292. The ability of the application to run in massive parallel mode reduces the runtime by delivering an extremely high combined processing volume over a short time. The same volume delivered in a full 8 hour processing window would require far less parallelization and fewer resources.417. The intent behind the compressed runtime is to prove the potential in scalability. of objects processed per hour 197. Using the reference model. From the results of the baseline proof of concept. we investigate the different options for the telecommunications model. With the PoC reference model for the “service to cash” business process.Results from the proof of concept reference model Process step Transfer of Event Detail Records Billing Orders Invoice Pre-processing Invoice Creation Correspondence Print No.857 19.

we look at three different size requirements and two different processing approaches. 10). Billing Account to Contract Accounts ratio is 1:1. ie. subscribers may have more than one service contract 2. Subscribers to Billing Accounts ratio is 1:1. and a total of 16 million event data records per day (see Fig. Prepaid accounts do not require payment or dunning processing (See Fig.Derived industry use cases: the telecommunications model For telecommunications.prepaid and postpaid 9 . 9). 6. In the model there is a ratio of 50:50 for prepaid and post-paid accounts.3. Subscriber Subscription: Billing Account (1:n) Billing Account: Contract Account (1:1) Figure 9 The model is based on the following assumptions: 1. 3 million subscribers – Tier 2 / Tier 3 model The requirements defined for a small (Tier 2/3) telecommunications model expect 3 million subscribers using a mix of services. 4. Each account will receive a printed invoice (to be processed in correspondence printing). The “T-shirt sizes” used for the models are taken from actual telco providers. Billing / Invoicing is handled in 4 Billing Cycles per month. Inbound interface EDR billing Convergent Invoicing Payment run Bank file creation Dunning proposal Dunning activity Correspondence printing Deferred Revenue Postpaid Prepaid Figure 10: End to end for telecommunications model . 5. Each service contract / subscription receives a separate invoice (convergence of invoices further improves performance) 3.

Sequential EDR Upload (6 Hrs) 120000 100000 80000 60000 40000 20000 0 15769 13952 3841 3872 3886 7885 15641 15572 In vC Co De re re fR ev d n 120 100 Runtime (Min) 80 60 40 20 0 SAPS 6245 un ed o t t ou n re Pr at io yR yM Du n Du n rrP In b Pa Pa In vP SAPS RunTime Figure 12 10 In vC Co De f re Re v d oc n Ac rin Pr Runtime (Min) SAPS 80000 . and can manage the distributed volume using 19k SAPS. 11 & 12) depict the two ends of the spectrum for runtime vs. In the first graph. allowing the end to end processing to complete in just over 1 hr. the mode is massive parallel.The following two graphs (see Figs. This model consumes 100k SAPS.Sequential EDR Upload (52 Min) 120000 117739 109742 109742 88134 79492 25 20 15 45560 41641 100000 83934 60000 40000 20000 0 38086 10 5 0 un ed ro ct t oc un nP nA rin io Pr yR yM at Du rrP bo Pa In Pa Du vP In SAPS RunTime Figure 11 Telco 3M Subscribers . Telco 3M Subscribers . The 2nd graph extends the runtime over the full 6 hour processing window. resource consumption for 3M subscribers.

000 4.000 12.35 3.000 4.72 8.000 39.950.000 Large 30.000 1. medium.000 3.000 50:50 4 9.76 Figure 14 4 Billing Cycles 8 Billing Cycles By increasing the number of billing cycles from 4 to 8.55 285.900.000.000.000 13.000.000 Figure 13 Relative runtimes Based on the throughput of the reference model.14).72 0.327.000 2.000 3.750.900.40 8. we can determine the runtimes for all three models.87 Medium telco Objects per day 64.500 2.437.000.000 3.875.210.000 1.900. we can bring the volume through within the 6 hr window by reducing the number of accounts we need to process within each billing cycle.000 Total (minutes) Total (hours) Runtime (minutes) 48.500 4.8584 Objects EDR records Billing accounts Contract accounts Contract accounts Contract accounts Contract accounts Contract accounts Contract accounts Contract accounts Small telco Objects per day 16.60 203.76 20.000 4.750.205.000 126. Reference volumes Step Inbound InvPreProc InvCreation PayRun PayMed DunPro DunAct CorrPrint DefRev Objects per minute 3.000 3.77 18.437.73 Large telco Objects per day 160.66 60.000 975.000 975.000 487.81 6.437.437.022 149.875.000.282.000.000 4.000 3.000 4.950.500 975.5263 751. or increase the number of billing cycles (see Fig.48 7.81 17.923.865.7342 654.000 15.000 1.875.400.84 209.500 2.53 12.000 50.08 32.000 4.000 1.706.000 3.08 1.750.54 37.74 1.49 Large telco Objects per day 160.45 17.80 101.545.000.4545 276.875.32 6. allowing us to handle the largest telco scenario on the available hardware.000 Total (minutes) Total (hours) Runtime (minutes) 48.500 2. There are two approaches – add more capacity.750.000 9.08 65.10 523.950.556 160.000 15.875.54 8.500 487.000 3.000 5.000 13.2312 80.000 16.58 3.04 81.875.875.000 50:50 4 975.13 48.000 50:50 4 3.000 975.600.950.400.898. large This table depicts the variation in key parameters for the three T-shirt models.Scaling the model: small.000 Total (minutes) Total (hours) Runtime (minutes) 19.98 7.23 26.222 64.24 3.787.500 487.71 52.900.41 3.000 1.3 per subscriber) Contract Accounts (subscriber accounts) Prepaid elements per day (SMS + CDR) Postpaid elements per day (calculated SMS + CDR) High-volume EDU (SMS + CDR peak incoming) / hour Total elements (EDRs) per day Ratio prepaid:postpaid Billing cycles Contract / Billing Accounts per billing cycle Small 3.000. based on the assumptions defined above and using 4 billing cycles (see Fig.52174 284.900.000 9.000.000. 13).000 4. 11 .000 9.000 34.750.000 Medium 12.59 2.900.000.903. Telco Model Components Subscribers Billing Accounts (average 1. We can see from this table that the large telco volume cannot be handled in the 6 hr window using the available architecture.41 14.600.875.33 120.65 0.600.831.000 9.15 6.86 2.000 Total (minutes) Total (hours) Runtime (minutes) 4.0769 47.246.600.500 487.900.000.000.22581 262.81 4.000.35 0.000 39.

EDR Peak 10:00 . The SAPS for the processing steps and the concurrent EDR upload are stacked for total resource requirement. This removes a large processing step in the critical path.Concurrent Loading (6 Hrs) 40000 "EDR-upload" Steps 30000 SAPS 20000 Pe 2252 In vC Co r 2252 2252 2252 10000 6245 15768 13951 2252 3841 2252 3871 2252 3886 7885 15641 0 0 ed ro ct t k E Inbo DR un Lo d / ad un rP rin ro tio nP nA re P re a yR Pa y Du Pa Du vP In Figure 17: Concurrent processing with smallest infrastructure 12 Pe a In vC Co r De fR M ev c n De 2252 15572 fR ev ct t . An alternative model may have a constant stream of EDRs arriving and being processed concurrent with the Convergent Invoicing steps. 16 & 17).Concurrent Loading (<1Hr) 120000 100000 80000 2253 2253 2253 2253 2253 "EDR-upload" Steps SAPS 60000 40000 20000 6245 0 0 79492 117739 109742 109742 82173 2253 2253 2253 45561 38086 30378 n n c ed ro ak Inb ED ou R nd Lo / ad rP rin Pr o tio Ru nP nA re a Pa y yM vP re Du Pa Du In Figure 16: Concurrent processing in shortest possible time 3 Million Subscribers .10:00 10:00 11:00 12:00 13:00 14:00 15:00 16:00 17:00 18:00 19:00 20:00 21:00 22:00 23:00 24:00 01:00 02:00 03:00 04:00 05:00 06:00 07:00 08:00 09:00 Figure 15 The two graphs below depict the small telco model running with concurrent EDR data. The Inbound step shows the requirements of the peak EDR upload phase which runs outside of the processing window (see Figs. 3 Million Subscribers .3 million EDRs per hour (see Fig.05:00 Continuous EDR Upload 14:00 . 15). The requirements for the small telco module assume that during the peak usage. and also has an effect on the resource requirements.14:00 Processing Window 23:00 . the system must manage a volume of 1.Continuous EDR upload with a 4-hour peak The processing modes up to now have assumed that the EDRs will be buffered and processed as a step in a sequential step chain.

The POC used two active partitions – one for the database and SAP central instance (CI).00 20. A third LPAR in the configuration (clone) was used for testing modifications to the infrastructure prior to use in “production” – simulating the SAP Test and Assurance system methodology. 50 million EDRs 13 Co Bi Ba Du Du In De fR at rrP bo llO re nk nn ev n . Using resource realignment in the shared processor pool. the system automatically and immediately realigns itself to changes in the load profile and load distribution over the partitions in the system.00 60. this peak load was achieved with 52 physical CPUs. around 60 CPUs would be required to support the peak workload of the application servers (which occurs during the printing of correspondence) and of the database servers (which occurs during Invoice Creation).00 8 14 22 10 9 14 14 6 3 3 2 7 10 7 un d er oc io n t Fi le ro Ac t ed yR u rd rin vP re Pr nn P Pa yM Pa In In vC APPS DB-CI Business Step Figure 19: Reference model: 1 million accounts.3GHz LPAR1 (is03d1) Database + CI Shared 24 48 Uncapped Weight=128 98GB LPAR2 (is03d2) Application Servers Processing mode Entitlement Virtual processors Sharing mode Memory Shared 24 48 Uncapped Weight=128 64GB LPAR3 (Test Clone) Processing mode Processing units Virtual processors Sharing mode Memory Shared 14 32 Uncapped Weight=128 80GB Figure 18 Resource utilization and distribution Looking at the CPU utilization in the graph below (see Fig.The contributions and benefits of the infrastructure Design and benefits of the Power Systems server The PoC was executed using an IBM POWER5 processor-based IBM Power Systems server and IBM PowerVM hardware virtualization. we can see how the CPU requirements (and the distribution of these requirements across the database and application) servers vary between the multiple steps of the processing chain. IBM System p5 595 server Installed memory Physical processors Processing mode Entitlement Virtual processors Sharing mode Memory 262144MB 64 x 2. 18). PowerVM provides the functionality for processor sharing by means of a shared processor pool. The partitions communicated with each other over the Virtual Ethernet functionality of PowerVM. 19).00 0. with dedicated resources.00 42 29 26 40 47 47 PhysicalCPU 40.00 30. and one for the production application servers. Physical CPU-Load per Business Step 70.00 10. This provides the flexibility of a 3-tier design without the network latency (see Fig. This is driven by the level of parallelization the application can achieve in the various processing steps.00 50. which supports inter-machine memory to memory communication. In a three-tier architecture. With processor sharing.

Using virtualization. the size prediction for production implementations is in the terabytes. those which will consume the most time in the processing window. The table holding the EDRs for this PoC reached nearly 500GB. as represented by this processing chain. and reducing I/O overhead. in this case the removal of masses of expired EDR data. and then dropped after a set period. 20) show the runtime for each step in relation to the number of parallel jobs and the resulting CPU utilization.5Hr) 60 50 40 30 20 10 00 d ed ile Pr o r vP re Pr oc Co rrP rin Or de un Ru tio Ac t kF bo vC re a Pa y Pa y nn nn Bi ll Ba n Du Du De fR M ev n n t % Total Runtime 30% 25% 20% 15% 10% 5% 0% Parallel Jobs %Runtime 80 60 40 20 00 20% 15% 10% 5% 0% vP re Pr oc r tio n yR un llO rd e rrP rin nk Fi bo yM nP nA In vC re a Du n Du n Pa De f Re v d ed le ro un ct t Pa In Bi Co Ba In In In %Runtime Parallel %Runtime PhyCpu Figure 20: Reference model: 1 million accounts. This is very beneficial for a fluctuating volume or highly deviant processing requirements.5 Hr) 40% 35% 160 140 120 40% 35% 30% CPU & Runtime per Step (1. 14 In PhyCPU 100 25% . The influx of mass billing data (EDRs) into the system results in the creation of several extremely large database tables. It is these two steps which define the resource requirements. depending on legal requirements. Step Runtime & Parallelism (1. Savings of 75-85% for most of the key largest tables have been realized which would translate into an overall savings of 30 to 40% of the total database size. In order to facilitate this periodic dropping of data. MDC provides not only improved query performance but also fast data roll-in and roll-out operations which eases the data management overhead. The DB2 Deep Compression feature was used in this proof of concept to compress these very large tables. in fact the two steps which use the highest CPU capacity only run for 60% of the total runtime. Benefits of DB2 database technology The EDR-based Convergent Invoicing scenario has several characteristics which directly relate to database technology. can scale out and be run in massive parallel mode as demonstrated by these charts for the 1. there is idle capacity in some of the steps. some type of table partitioning is recommended to allow this to occur with as little disruption as possible. saving disk and memory space. Thereby the resource distribution remains predictable. the CPU capacity does not need be dedicated. IBM DB2 offers two solutions which fulfill the table data management requirements: range partitioning and Multi Dimensional Clustering (MDC). MDC is the preferred approach for SAP solutions and is unique to DB2. Resource distribution can be easily controlled using a simple priority scheme. Of the two. 50 million EDRs Even during the critical path processing. these resources can also be shared with other workloads residing in other partitions on the same POWER5 processor-based server. and yet this flexibility via dynamic realignment provides a higher total processing capacity. The entries in this table will need to be maintained for a given period of time (for example 180 days online). and typical in multi-step processing. We see that the critical path steps.5 hour runtime window (high-end scalability).Parallelization and application scalability These two graphs (see Fig.

even with relatively modest IT resources. robust and highly economical solution that makes the most of hardware resources by leveraging IBM virtualization technologies and the highly optimized DB2 database platform. is met by the scalability of the application and the high performance Power Systems server infrastructure. The scalability demanded by the business process models and the expected future growth in volume. it is possible to process enormous EDR volumes. The continuous data capture.Conclusions of the solution’s proof of concept Meeting today’s IT challenge The PoC has shown that by running SAP Convergent Invoicing on Power Systems hardware and DB2. 15 . the implication of the PoC is clear: IBM and SAP can provide a rapid. and run a same-day billing system. inherent to such solutions is supported by unique functionality in the DB2 database in regard to performance and non-disruptive administration of the mass data. and this dynamically responsive infrastructure. The combination of SAP Convergent Invoicing and IBM computing infrastructure fulfills both requirements. The adaptability and flexibility demanded by the new business processes are reflected in this highly adaptable application design. For businesses facing the challenge of running a complex. This requires an easy-to-adapt data model as well as a system architecture that can grow with the business making good use of initial hardware investments. The PoC set out to answer one critical question: can the solution handle the enormous volumes of data that such applications will generate? We know now that it can. Flexibility for future business challenges As the service portfolio of telecommunications providers evolves and as subscriber numbers grow – organically in the case of up-and-coming players or through acquisition and market consolidation – adaptability and flexibility are essential. high-volume billing environment.

com/legal/copytrade. visit ibm. Many factors have contributed to the results and benefits described. product or service names may be trademarks. Photographs may show design models.com For more information about SAP products and services. registered in many jurisdictions worldwide. other countries.ibm.sap.com For more information on this specific solution. contact an IBM representative or visit ibm.com For more information about IBM products and services. or service marks of others. visit ibm-sap. and the Windows logo are trademarks of Microsoft Corporation in the United States. IBM does not guarantee comparable results. contact an SAP representative or visit sap.nsf/WebIndex/WP101231 Contacts: SAP www. This publication is for general guidance only.com/solutions/sap IBM. This case study illustrates how one IBM customer uses IBM and/or IBM Business Partner technologies/ services.com/support/techdocs/atsmastr. available at http://www. Microsoft.nsf/WebIndex/WP101231 To learn more about the solutions from IBM and SAP. or both.com are trademarks of International Business Machines Corporation. SPL03002-DEEN-01 (May 2009) . the IBM logo and ibm. 2009. © Copyright IBM Corp. IBM does not attest to its accuracy. © Copyright 2009 SAP AG SAP AG Dietmar-Hopp-Allee 16 D-69190 Walldorf SAP. Intel Xeon and the Intel Xeon logo are trademarks or registered trademarks of Intel Corporation or its subsidiaries in the United States and other countries. Other company. Windows NT. SAP and all other SAP products and services mentioned herein are trademarks or registered trademarks of SAP AG in Germany and several other countries. other countries.shtml. All information contained herein was provided by the featured customer and/or IBM Business Partner.com/contactsap for enquiries/requests www. UNIX is a registered trademark of The Open Group in the United States and other countries.sap. All customer examples cited represent how some customers have used IBM products and the results they may have achieved. Intel.ibm. A current list of other IBM trademarks is available on the Web at “Copyright and trademark information” at http://www. All rights reserved. Actual environmental costs and performance characteristics will vary depending on individual customer configurations and conditions.ibm. or both. the Intel logo. Linux is a trademark of Linus Torvalds in the United States.com/telecommunications for further info IBM For further questions please contact the IBM SAP International Competency Center via isicc@de. the SAP logo. Windows.com/support/techdocs/atsmastr.This paper is based on a more comprehensive technical document.com IBM Deutschland GmbH D-70548 Stuttgart ibm.