本文作者Rick van der Lans是咨询公司R20的创始人、管理总监。是数据仓库、商务智能、数据库技术和虚拟化技术领域的专家。

自服务BI工具帮助业务用户在不需要专业IT员工帮助的情况下快速运行查询，创建报表。有了这样的工具，用户可以对新的业务发展和数据分析需求做出更快速的反应。BI工具今天已经发展的很广泛，但是，仍然缺少一个重要类别：自服务操作型BI工具。

目前，自服务BI工具都是首先考虑业务决策者的需求，而不是真正奋战在运营第一线的管理者和员工，比如生产、运输和库存管理人员。

但是，有时运营人员在面临业务突发事件时，需要快速的反应。比如：一旦产品没有及时到达，那么是什么原因导致的?是不是因为原材料送晚了?如果是，那么有没有可以临时替换的材料?这些问题都需要快速解决。

再比如产品质量问题或食品包装问题：包装材料是从哪里来的?来自生产工艺的哪个流程?要送到哪个超市?组织中每天要面临几百个这样的运营问题。

理解数据

能回答这些问题的数据往往存储在SAP或Oracle的ERP系统中，从技术上来看，完全可以把自服务BI工具和数据连接，比如SAP系统的交易型数据库。但如果这样做的话，就要求运营用户了解数据存储位置，数据结构和数据库表之间的关联。

事实是，大部分BI工具都不理解数据，它们不知道在SAP数据库中，可以在KNA1表中找到客户数据，也不知道制造运营的材料管理数据可以在MARC、MAPR、MBEW、MDKP和STXH表中实现联接，或者销售订单或其他类型的销售文档可以通过集成VBAP、VBUP、VBLB、VBKD、VBPA 和AUSP/IBIN表中数据创建起来。

而且，即便BI工具看到了“北京”和“上海”，也难以推断出这两个值代表客户所在城市名称。工具能做的只是通过比较列名或列中填充的数据判断表之间可能存在的关系。如果有很多相等的值，那么很可能存在关系，不过，工具还是不能知道列中的值代表什么。

不要忘了，SAP数据库汇中包含两万个实体表和20万个虚拟表，虽然并不是所有表都重要，但至少有两千个表示重要的。自服务BI工具要想访问SAP系统，就需要在浩如烟海的表中找到正确的路径。如果用户没有技术知识，直接访问数据库只会让他一头雾水。

自主软件的同化问题

另外，交易型数据库包含更多常用数据。通过应用逻辑于存储数据，用户可以吸收新数据，比如开放的订单列表，或产品库存概述。很多同化数据(assimilated data)都是日常运营管理不可或缺的。

计算同化数据的逻辑很简单：比如从出生日期可以推算出员工年龄，或者判断订单的哪一部分已经完成。但也不总是这么简单。比如识别“死股票”，这需要很多表联接在一起。

要识别交付订单，比如内部购买、工作订单和消费订单，比如客户订单的关系就很难。需要分析材料清单，考虑存在于未完成货物和中间产品中的应用逻辑。要判断SAP中的潜在计划和执行瓶颈以及产生的影响是很复杂的。要开发出必要的逻辑，需要很多十分了解SAP数据库的员工花上几个月的时间才能完成。

即便这样，BI工具还必须能够计算同化数据，支持运营部门用户自服务。一些BI供应商已经在它们的产品中做出了这样的尝试，但很多还没有。