In my previous blog post, I teased the concept of a new model for organizing gap analysis efforts called BEANS. Today, I’ll pick up where I left off in Part 1 and introduce the first element in our BEANS framework: business intelligence.

Business Intelligence: Reimagined

Although BI is certainly nothing new in the SAP space, we emphasize it here because we think that there’s a big misconception about what BI tools can and should be used for in the modern enterprise. In many circles, it seems that conventional wisdom dictates that BI tools should be reserved for specialized use cases only. This is to say that BI tools are primarily meant to be used by data scientists and/or BI specialists responsible for the creation of interactive dashboards and other types of advanced analytics. For anything else — especially the creation of more basic operational reports — the use of BI tools is considered to be overkill.

In our way of thinking, BI tools are actually the first place we should look to address reporting requirements. Although none of these rules are hard and fast, we generally favor a BI tool-centric approach over the kinds of partial solutions you get with traditional ABAP-based reporting tools such as:

• ALV and list reports — especially those that only exist as a tool for dumping SAP data into Excel for offline analysis
• Custom Fiori apps that utilize charts and other controls to visualize data
• Generic query tools like the Query Browser and other embedded analytics tools provided with SAP S/4 HANA
• Older report creation tools like the Quick Viewer (Transaction SQVI)

Although these kinds of ABAP-centric reporting tools still have their place, our experience has been that customers quickly outgrow these kinds of solutions. One of the more difficult aspects of report development is that the business doesn’t always know precisely what it wants. This month, a user might need a reconciliation report to help her track down some missing payments. Next month, it could be something completely different. From a development perspective, frustration levels can be pretty high since there’s seemingly no end to the types of reporting requests that may come up.

The ideal solution in our eyes is to construct a flexible and secure data model using dimensional modeling techniques and then provide the business with a user-friendly BI tool (SAP-based or otherwise) that they can use to perform self-service analytics tasks on demand. This concept is illustrated by the graphic shown below. As you can see, this approach allows both parties to play to their respective strengths:

• The IT/development team can focus on curating the data in a safe, secure, and efficient way
• The business can bring their expert knowledge to bear on slicing and dicing the data according to their specific requirements

Instead of constantly trying to guess at what the business/users may want, the IT team can just focus on building a logical data model that makes it easy for users to search for data across multiple dimensions. Besides providing a better user experience, this approach to reporting should also be more cost effective if we execute correctly. Since modern BI tools can consume OData services, there are opportunities to cut out the traditional ETL middleman and go directly to the source data. Here, we can take advantage of Core Data Services (CDS) and Data Control Language (DCL) technology in the ABAP layer to leverage SAP’s standard role-based authorization concept and avoid reinventing the wheel with regards to row and field-level security.

Using low-code BI tools like Microsoft’s Power BI or SAP Analytics Cloud (SAC), developers and analysts alike can quickly develop interactive reports like the one shown below. Over time, these reports are generally much easier to scale since industrial strength BI tools already have built-in support for smooth pagination, in-memory performance optimizations, advanced visualization controls, and so forth. At the end of the day, if we play our cards right, everybody wins — most notably the business.

Closing Thoughts

I wanted to highlight an important theme that crosscuts the entire BEANS framework: code reduction. Wherever possible, our objective is to deliver as much functionality as we can in as little code as possible. This not only reduces complexity, but also accelerates innovation and flexibility over time. With BI/reporting, this is largely about not re-inventing the wheel, but similar concepts apply in other areas of development.

In my next blog post, we’ll turn around attention to the “E” in BEANS: extension apps. Looking forward to continued dialog!