Skip to Content

Intro:

The need and agility of reporting systems to cater to the business users demands timely decisions based on logical and comprehensive information when needed along with crisp alerting mechanisms within Org. A’s rapidly changing business environment. Org. A is happens to be one of the largest gas distribution company in Europe. It transports and stores gas for its customers through a transportation network across the country. It is responsible for ensuring that gas is delivered to millions of consumers around the country safely and efficiently. Many shippers (Gas Suppliers) supply gas to the end consumers through Org. A’s network. The SAP BI initiative is focused on for two divisions at Org. A – Metering & Asset Management (MAM)and Support Services. The key objective is to develop a decision support system based on BI that is capable of analyzing Key Performance Indicators in the areas of Asset Portfolio (Managing the Meter Portfolio), Inquiries & Complaints (Managing the call centers), Finance (Managing Billing, Invoicing, Payments, etc.). Also, the distribution of data across many different source systems, multiple instances of R/3 and IS Utilities and Legacy Systems, this makes it very difficult for the management to get the required information on time and from the right source systems.

The Solution drivers:

The move was primarily to validate the key functionality of the BW system in context to the reporting requirements at Org. A . Having been dealing with a host of ETL tools, the objective was to assess the key capabilities of BI as a Data Warehouse product (a productized approach to the implementation) along with the development of dashboards that would capture and report the chinks in the supply chain through proactive alerting. The objective includes the assessment of key issues where the application would render non-performance that could lead to the definition of the direction of this initiative which included the tactical details of the assessment of hardware that would be needed to support such a reporting system and the landscape needed to support the DSS.

The Solution Architecture drive was driven to identify the needs of the key stakeholders in the program for timely, accurate, consistent and appropriate information in a cost effective manner. Org. A plans to provide its end users with a flexible and integrated proactive reporting solution with a single source of reporting information to replace the existing data marts. The need for a unified UI specific to user groups to reduce training costs led to the objective of having screen based reporting and to discourage paper based reporting as a paperless Decision support system. These key business drivers were supported by one common objective – providing a paperless DSS that is more proactive than reactive, that provides a similar UI, is the single source of truth that encourages ease of use and paperless reporting.

.

A. Integration of BI Reporting with EP

One way Org.A views a step towards salvation is with BI Report iViews being created using the BEx Web Application Designer. By using the web templates designed with the BEx Web Application Designer, the ease of creating BEx query strings using the BEx Query Designer containing the information about the Infocube used with EP as the front-end application simply by creating a system object for the BW system and creating a Report iView by setting the properties to the BI System created and the BEx Web Application Query String is what Org. A finds as a speedy solution to build.

image

B. Unification & Drag & Relate – Enabling of BI Web Application:

Another option being considered as part of the Solution Architecture is the Drag & Relate approach whein the BW content displayed on EP by relating the InfoObject’s within the BI system and dragging an InfoObject of a BW Web Application iView onto another BW Web Application iView displaying the related content of the dragged InfoObject seems like a relatively speedy and effective way to move ahead by creating a system Entry for a BW System in EP and Importing the InfoObjects of the BW System into the same using the Business Object Importer in EP. Once there are two BW Web Application iViews (Source and Target) created and setting the parameters for the BEx Web Application Query String and BW System, all that remains is the definition of the relation between the Source InfoObject and Target InfoObject. Having tested out the dragging of the Source InfoObject on to the Target InfoObject where the drag opens up the Target iView Report showing the content based on the relation defined between source and target InfoObjects, the results seem very promising in the landscape of Org.A, where this feature finds a definite usage.

image

C. Integration using XI:

Since the use of the data from the DSS being designed with BI is meant for use across many applications in the landscape over the next few years, the data from the proposed system will have to be fed in other legacy applications as well that will continue to exist for some more time thereby warranting the solution with XI being integrated with the BI solution. The only difference in this approach being the retrieval of data by EP being from XI instead of getting directly from the BI solution.

Adapters/ Proxies (based on the web application server) will need to be configured on the SAP XI for receiver and sender systems where XI will pull the data from the BI solution as needed and then push the data onto EP. Since the nature of the information that would require this kind of a Solution approach would be restricted to certain alerting mechanisms, the use of this solution is being kept to a minimum within Org.A, on the same token, it is being favored owing to the reduction in the peer-to-peer communications.

image

Outro:

Having the core DSS tilt towards building a BI based solution, Org.A is keenly looking forward to using the Visual Composer to build BI queries which can be then used to configure and build queries which can be viewed as iView on EP. BI Query Wizard which gets installed by default with Visual composer, which is used to build and configure BI queries. The iViews created on Visual Composer then are deployed on to WAS and viewed on EP. The need for BI broadcasting, BI alerting and the usage of the same in the day-to-day running of the business for Org.A’s business users is to be looked upon consecutively, not subsequently.

The drivers for this initiative within Org.A was primarily to do away with multiple source systems that rendered the business community reactive with inflexible reporting systems dealing with multiple systems that are OLTP driven. The lack of existing standard business content meant longer times of development starting from scratch and more built to translate the existing inefficiencies paperless, rather than building in best practices. The Solution Architect’s approach called for needed to address both the business and technical drivers to make the “BW Project” as the starting point for the move towards an ESA architecture leveraging the SAP NetWeaver platform. All in all, the Solution Architect’s approach warrants the doing away of esoteric and technologically brilliant solution that find no practical relevance to any customer.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply