Dos and Don’ts of BI Usage

To maximize profit, companies need to monitor countless interdependent activities spread across all their business processes, analyze the results, and use this information to make sure that the whole interplay – including customers, partners, suppliers – fits together.
Manufacturing companies for example have complex supply chain networks. These companies are facing more and more demanding customers and increasing numbers of stock keeping units, as well as compliance reporting issues in an environment forcing them to decide faster. The core of any manufacturing company is its supply chain, the process of transferring goods from the shop floor to the end consumers. This process must be accompanied by financial systems or human resources solutions, for example.
Speed is what counts in the manufacturing industry: Speed in product development, speed in assembly, and speed in delivery and service to dealers and customers. Traditional business models are transforming into transparent, customer-driven value chains. The integration of OEMs, suppliers, dealers, and customers is essential for success.

Different industries, different processes, different KPIs

List of some KPIs
List of some KPIs

Products like SAP NetWeaver Business Intelligence combine planning and simulation capabilities with data warehousing functionality to provide a coherent, comprehensive analytical solution tailored for multiple user roles in different industries. Its pre-configured business content offers data extractors, report templates, and metrics (KPIs).
The list of relevant KPIs will vary from company to company, depending on the various internal and external factors including the type of business. “Enabling” the KPIs for the business intelligence solution depends on the information being collected in the transactional system, the original source of all data. For manufacturers, for example, material costs have a big impact on the margins. On the other hand industries should have an eye on the customer service satisfaction level, which will pay off in market share sooner or later.

Business intelligence architecture

KPIs and their transactional processes
KPIs and their transactional processes

Each BI analysis is in general less granular than its source information in the transactional system (OLTP). As a matter of fact a high granularity of the transactional system will be detrimental for BI analytics from a performance perspective. In addition the basic processes for which data should be collected in the transactional system to transform them into KPIs vary from organization to organization depending upon how KPIs are defined and interpreted. Nevertheless it seems reasonable that the market share for example is extracted from sales order and sales offer data, from delivery item and scheduled line item data, or from billing documents, for example.
A business intelligence architecture like SAP NetWeaver Business Intelligence helps to extract this sort of data from other SAP solutions, non-SAP systems, or flat files in a seamless manner by using SAP NetWeaver Exchange Infrastructure. The architecture is based on consecutive layers like primary ODS, info cubes, or multi-providers.
The primary ODS typically contains granular data which is mostly quite similar to that from the source system. The data transformation from the source data to the data residing in the ODS is defined by the transfer rules. These rules can be defined by directly mapping the source system fields, by writing ABAP routines, or by using the predefined functions available in the transformation library. One simple example of a transfer rule: An ABAP routine can be written to weed out special characters like “!” or “@” in character strings being extracted from the source system.
The next layer, the info cube level, enables the users to step from transactional reporting to analytical reporting. The first benefit of this level is that it provides the user with aggregated information. Second: Since the data is represented in a multidimensional model, the layer provides the slicing and dicing of data. Third: The level allows data to be consolidated from multiple ODSs to provide an integrated view on information. Business rules serve to transform the data from the underlying ODS to the target info cube. For example Sales Order ODS, Delivery ODS, and Billing ODS can be merged to provide an integrated view of the sales cycle.
Multi-providers are created to meet specific analytical requirements such as cross-functional reporting. They are useful if a number of different key figures such as the purchase order value, goods receipt value, and invoice value are required for the same set of characteristics – material, plant, and calendar year period, for example. These key figures may exist in different info cubes.
On top of this all is the presentation layer. SAP NetWeaver Business Intelligence enables analytics through different front end tools like BEx Analyzer, SAP Enterprise Portal, other Web applications or Visual Composer, just to mention a few. Each of these tools is used according to the individual business needs of a company.

Analyzing and interpreting data

Within such an architecture SAP NetWeaver Business Intelligence helps to analyze and interpret data to create business information. Tools such as query, reporting, and multi-dimensional analysis support collaborative decision making. Users access data on summary or detail level and analyze and share business information using a web browser. They may create their own reporting environments, represent data graphically, and visualize relationship between information.
Data can be explored within a multilevel process, with advanced analytical methods being applied in order to gain new insights from this data. The analytical results are persisted within SAP Business Information Warehouse. For example, if a user wants to get information about sales revenues of his or her company, he or she may start at the country level, and then drill down, getting information at a country and a state level, then at the country, state, and sales territory level and so on.
Last but not least business planning and simulation capabilities are fully integrated into the SAP solution. This allows users to develop planning applications or activate existing functions for financial budgeting or production planning, for example. The simulation capability allows what-if analyses.

Don’t underestimate the influence of performance for success

Independent of architecture or solution, users should follow some golden rules when using a BI solution:
Dos of BI Usage

  • The BI tool should be used as an analytical tool to proactively show patterns and exceptions. It should aid in the decision-making process.
  • The BI strategy of an organization should be reviewed at least once a year to see if it fits with the overall goals and objectives. A strong BI platform will aid in achieving the goals and objectives of an organization.
  • More users should be trained and empowered to use BI. A well executed BI solution will aid in achieving the goals and objectives of an organization.
  • The BI solution should pave the way to data integration across the organization.

Don’ts of BI Usage

  • Don’t start to think about an authorization concept at the end of the project. The authorization concept might have impact on the data model and also on the performance. If users have for example 20, 30, or 40 authorization relevant objects in a query, this will impact the performance – and may in the end result in a time-consuming re-design of the authorization concept and/or the data model.
  • Don’t underestimate the influence of performance for the project success. From the end user perspective, the most important thing is to have the right data in the required layout with a high performance. This will be essential for the acceptance of the BI solution. So this aspect needs to be considered during the data modeling phase.
  • Don’t use ODS objects for the sake of using them. ODS objects should for example serve to create a data warehouse layer, fulfill special loading purposes like the derivation of deltas or overwriting functionality, or fulfill special reporting purposes
  • Don’t create your own currency translation routines in the update rules. SAP provides a currency translation feature in standard business content.
  • Don’t create generic extractors if such extractors are available within the business content. Generic extractors may have their own problems, like no automatic delta recognition.
  • Don’t show too much data with the initial report appearance. Initially a query should not deliver too much information. The user needs aggregated information on a summarized level. Depending on his or her needs, he or she should then have the opportunity to drill down to granular level of data in the ODS, and should be able to enter the source system to see transactional level details.

Vikash Agrawal

Bala Ramakrishna