CSPs have lots of OSS and BSS tools. All these tools come with some kind of reporting solution. Some reports are embedded in the product, some OEM Business Objects, Cognos like tools on the top of their databases.
The problem with these reports is two fold. One is, they are just built to show operational data to operational people that are in charge of that specific OSS/BSS domain. These reports often include lots of technical data that are meaningful only to the technical people. Business people, or even the technical people from other domains usually need for some kind of “translation” in the provided data. If the tool allows, the domain owners would create (or ask IT to create) new reports that are meaningful to other parties.
While translating the “language” of the reports, the look-and-feel is also taken into account as business and executive reports should look fancy and include charts, graphs and some kind of analytics on the top. This report beautifying process, also adds another burden to the operations’ day-to-day activities.
Second problem arises in the nature of data. The data that can be extracted for the reports is for the tool’s domain. This prevents cross-domain analysis report creation which is crucial for the business people. The organizational functions that operate on the service management layer (such as SOC) also need these kind of reports to run historical analysis on the operational performance.
As mentioned before, most of the products do include a separate reporting solution by either OEM’ing or utilizing CSP’s reporting platform licenses. These also bring additional license costs and maintenance effort to the customer, resulting an increase in both OPEX and CAPEX.
Common Reporting platforms aim to solve these problems. In such kind of a platform, all the organizational groups connect to a single platform for all their reporting needs. There’s much less maintenance cost of such kind of a solution. Usually 1 or 2 admins with reporting and DB skills would be enough to run such kind of a platform.
Removing the need for reporting from the OSS/BSS tools will reduce the license costs of the solutions. Also, some machines that are procured with these solutions just for reporting purposes would return to the free inventory.
Implementing a common reporting platform, starts with investing in a BI reporting solution. Cognos, Business Objects like products will be good fit for such kind of a platform.
There are several implementation strategies for these platforms.
First one is to take the data directly, on the fly, from the operational data sources and combine under a common logical data model that will be used for reporting. This is a low-cost implementation as it requires only the reporting platform licenses and hardware. The drawback of this solution is it may degrade the operational data sources, thus the OSS/BSS platforms’ performance. A detailed analysis is required to see the effects of the reporting load on the platforms. (It is a common act to over-size the hardware at the presales phases)
The second approach is to include a staging database in between and use this database for reporting purposes. An ETL process will also be required to take the data from underlying operational data sources to this staging DB. This brings additional performance both in reports and the operational databases. The drawback is obviously the need for a separate database and an ETL tool which will bring extra costs.
The second approach could also be used for a phased strategy to move to a network datawarehouse. Common reporting platforms could easily migrate to network datawarehouse
platforms. This way, It will be more easy for the operational teams to justify the next NW datawarehouse investment to the business.