Evaluate Weigh the pros and cons of technologies, products and projects you are considering.

Self-service software missing from operational BI picture

Consultant Rick van der Lans says most self-service business intelligence tools fall short at the operational level, leaving some key business users locked out of the self-service BI process.

Self-service business intelligence tools enable business users to run queries and create reports without help from IT and BI staffers. With the aid of such tools, users can react more quickly to new business developments and urgent data-analysis demands. But although self-service software comes in a variety of shapes and colors, one crucial category is largely missing: self-service operational BI tools.

The self-service BI tools available now are primarily designed for users who work on strategic and tactical business planning. That leaves out the managers and workers who are responsible for an organization's day-to-day operations -- for example, production, transportation and inventory managers.

The information needs of operational users are characterized by spontaneity and commonly result from unexpected business situations that require an immediate response. Here's an example of a need for information at the operational level: If we aren't able to deliver our products on time, is that because some of our suppliers are late in delivering the raw materials? And if so, are there alternative suppliers that we can work with temporarily to resolve the problems?

Another example involves quality problems on some food products because of damaged packaging. Where did the packaging material come from? Which production runs was it used in? To which supermarkets were the flawed products shipped? Literally hundreds of operational questions like those are asked daily in an organization.

Held back by a lack of understanding

The data needed to answer most of the questions resides in ERP systems such as SAP and Oracle. Technically, it's possible to connect a self-service BI tool to, say, an SAP system's transaction database. But if we do, the operational users must understand where data is stored, the structure of the data and how the relevant database tables are linked together.

The reason is simple: Most BI tools don't understand the data themselves. They don't know that in an SAP database, customer data can be found in the table called KNA1; they don't know that materials management data for manufacturing operations can be combined from the MARC, MAPR, MBEW, MDKP and STXH tables; nor do they know that a sales order or other types of sales documents can be constructed by merging data from the VBAP, VBUP, VBLB, VBKD, VBPA and AUSP/IBIN tables.

And even if BI tools see values such as New York and Boston in a column, they typically won't be able to deduce that those values represent the names of cities where customers are based. What some tools can do is determine that likely relationships exist between tables by comparing column names or the data that populates different columns. If there are many equal values, a relationship probably exists. Still, the tools typically won't know what the values in the columns mean.

Don't forget that an SAP database contains more than 20,000 real tables and 200,000 virtual ones. Not all of them are important, but at least 2,000 are. If we allow operational users to access the database in an SAP system with self-service BI software, they must be able to find their way in the labyrinth of tables. That's a major undertaking -- and without technical knowledge on the user side, accessing a database directly will likely be troublesome.

Assimilation problems in self-service software

In addition, transaction databases contain more usable data than is physically stored in them. By applying logic to the stored data, users can "assimilate" new data, such as a list of open orders or an overview of unallocated product stock. Much of this assimilated data is indispensable to day-to-day operational management.

The logic required to calculate assimilated data can be simple -- for example, it's relatively straightforward to derive an employee's age from his or her birth date, or determine which parts of an order have already been shipped. But it's not always that simple. Identifying dead stock -- outdated inventory that can't be sold -- can be a highly complex process because many tables must be joined together.

The process of assessing bottlenecks in a supply chain also provides a good example of the application logic requirements. It isn't easy to detect dependencies between "delivering orders," such as internal purchase and work orders, and "consuming orders," such as customer orders. The steps that have been defined in bills of materials need to be analyzed, and the application logic must take into account existing stocks of finished goods and intermediate products requiring further work. To determine in SAP what the potential planning and execution bottlenecks are, and what impact they're likely to have, is incredibly complex. Developing the necessary logic can take many man-months and requires in-depth knowledge of the SAP database structure and all its peculiarities.

And even then, BI tools must be able to calculate assimilated data to support user self-service in operations departments. Some BI vendors have taken that step with their tools, but many haven't. As a result, most self-service software isn't ready to handle self-service operational BI.

About the author:
Rick van der Lans is an independent consultant, speaker and author, specializing in data warehousing, business intelligence, database technology and data virtualization. He is managing director and founder of R20/Consultancy; email him at rick@r20.nl.

Email us at editor@searchbusinessanalytics.com, and follow us on Twitter: @BizAnalyticsTT.

Next Steps

More from Rick van der Lans: Why the term logical data warehouse no longer makes sense

Get his take on why executive awareness of what big data systems can do has become vital

Read a Q&A with consultant Wayne Eckerson on managing self-service BI projects

Dig Deeper on Operational business intelligence

Join the conversation

1 comment

Send me notifications when other members comment.

Please create a username to comment.

Isn't this a question of terminology? "Tactical business planning" and handling "unexpected business situations" sound fairly similar in terms of the big three of People, Process and Technology.

Margaret Rouse stated, "Operational business intelligence, sometimes called real-time business intelligence, is an approach to data analysis that enables decisions based on the real-time data companies generate and use on a day-to-day basis." That definition was posted on TechTarget at https://searchbusinessanalytics.techtarget.com/definition/operational-business-intelligence.

As you have pointed out some vendors have taken the step to understand the information housed in the data. I can think of several vendors marketing tools that meet the need for tactical decisions using operational data. ERP vendors themselves are getting into the game. In other cases operational dashboards built by the BI team does some of the mapping to the data to allow exploration during exception processing.

In the People, Process and Technology view, the limitation may be People skills to use operational data in the operational business Process. The problem may not be that the Technology "isn't ready to handle self-service operational BI." Addressing the People skills to do self-service BI is a huge effort. Fixing the business Process is also key. Technology is only a small part of the problem.