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 firstname.lastname@example.org.
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