从早期的多维分析（OLAP）到近年来的敏捷BI，BI产品厂商一直在强调自助能力，宣称可以由业务人员自己分析数据，而用户方也常常有强烈的此类需求，双方一拍即合，很容易形成购买行为。但是，BI产品的自助功能真地能让业务用户自己随心所欲地分析数据吗？
“分析”这个词并没有一个业界公认的严格定义，所以不能说这些BI产品是否过份宣传了。不过，就大多数缺乏BI应用经验的用户所期望的工作内容而言，自助分析的目标就可以说远远达不到！从经验上看，最好情况也就能解决30%左右的问题而已，而大多数BI产品连这个数也达不到，只能处理10%左右的需求。
我们分为三个层面讨论这个问题。
多维分析
多维分析是指针对某个事先建好的数据集（称为立方体）做交互操作。这是大多数BI产品目前能够提供出来的分析能力，尽管新一代产品在界面美观度和操作方便度上有了不小的进步，但能完成的运算功能并没有本质变化。
多维分析的主要问题是有个建模过程，也就是事先准备数据集。如果要分析的数据都可以限定在某个数据集中，且动作只限于产品提供的那些（旋转、钻取、切片之类），那么没有问题。但这是个小概率事件，实际应用中会经常超出这个范围。增加一个以前没想到的数据项，和另一个数据集做一个关联运算，都会导致再建模。而建模需要求助于技术人员，这样业务人员的自助就无从谈起了。
做到多维分析这一步，只能解决10%左右的自助需求，这是BI产品最常见的自助能力。
关联查询
为解决多维分析的局限性，有些BI产品开始提供关联查询能力。一般是在多维分析前面增加一步，能够基于多个数据集关联计算出新的数据集再来做多维分析，或者在多维分析过程中支持多个立方体间的某些关联运算。这相当于允许业务用户一定程度可以自己建模。
不过，实现关联查询并不容易，其根源是关系数据库对关联运算（JOIN）的定义过于简单造成的，导致数据集之间的关联关系看起来过于繁琐，超出许多业务人员的理解能力。这个困境在BI产品的界面协助下能有一些改善，好的BI产品能够让业务人员正确处理没有形成环的关联关系。但是，要从根本上解决问题，就要改变数据库层的数据组织模型。而几乎所有的BI产品都不会重新定义数据库的数据模型，其关联查询能力就会受限。这些较深入的技术问题我们将在后续文章中逐步谈及。
一个可用于检验BI产品关联能力的通俗例子：查询女经理的男员工。这个很简单的查询需求中涉及到同一数据集的多次关联，大多数BI产品都处理不了（除非事先建模）。
有了关联查询能力后，BI产品能解决的自助需求占比能提高到20%-30%，具体程度要看产品提供的关联能力的强弱。
过程计算
剩下70%左右或更多的需求，都会涉及到多步骤有过程的计算。而过程计算完全超出BI产品的设计目标，甚至可以不被认为是数据分析，但却是用户特别希望解决的问题，也就是让业务人员能够随心所欲地（在其权限范围内）获取数据。
一个简单办法是使用BI产品导出基本数据，由业务人员自己用Excel等桌面工具去做。但是，Excel并不擅长处理多层次数据的关联运算（我们后续会讨论到），而且数据量大了也撑不住，在许多应用场景无法胜任。
在没有更好的交互计算技术出现之前，这些问题还是需要技术人员才能解决。在这个前提下，BI产品能做的事就不是让业务人员自己实现过程计算，而是要想法提高业务人员获取技术资源的效率，以及技术人员实现需求的开发效率。
具体来讲有两个方面：一是建立历史问题库，某些以前曾经做过的问题，可以直接由业务人员直接调出算法改变参数执行；即使是新需求，也可以找到类似问题以协助技术人员准确理解，技术人员和业务人员的理解不一致是造成事务延期的主要因素之一；二是提供高效且可管理的开发技术，让技术人员能快速编写和修改计算代码，并可将这些代码存入历史算法库中保管和再次执行。目前业界并没有多少适合的技术，SQL可管理性较好，但编写繁琐而难以处理有过程计算；存储过程需要再编译而不方便再次执行；Java代码也要再编译而基本上不可管理；其它脚本语言的集成性又较差也难以入库管理和再次执行。
针对于用户最普遍的自助数据需求，当前BI产品的能力实际上是相当弱的。经常的情况是：BI厂商说的是多维分析，而用户想的是那些需要过程计算才能解决的问题，这个错位就会导致期望高而失望大的局面。用户要清楚自己的自助需求：是否做到多维分析就够了？有多少关联查询需求？业务人员是否会提出大量需要过程计算的问题？这样才能设定合理的期望值，知道BI产品对自己的作用在哪里，不被产品的花哨界面和流畅操作迷惑，避免事后的遗憾。
