破解商业智能 BI 的谎言从“你能不能说起”

说的小谎.

包治百病、药到病除的“商业智能 BI”

我们经常会碰到有伙伴、企业客户向我们提出这样的问题：

“某某厂商说他们的 BI 工具交项目交付很快，基本上用他们的产品几天或者一周就可以把项目做完，敏捷开发，零风险，你们能不能？”

“他们直接连业务数据库，不懂 IT 技术也没有关系，业务人员自己就可以做分析报表，你们能不能？”

“他们的自主分析很强大，什么业务问题只要拖拉拽就可以做分析，能一眼看出企业存在的经营管理问题，什么业务数据实时预警决策都不在话下，你们能不能？”

.....

类似于这样的问题很多，总体感觉就是只要你买了我们的药，不用望闻问切，就可药到病除，包治百病。并且通常一副药一个疗程就够了，快捷高效。

听上去，很美好，但实际上有点过于夸大，也是经不起推敲的。

商业智能 BI 的开发生命周期

商业智能 BI 是有开发生命周期的，一个完整的商业智能 BI 项目一定是经历过业务需求分析、分析指标体系梳理、源数据和数据质量调研、ETL 数据的抽取、清洗转换和加载、业务计算逻辑到数据计算逻辑的实现、数据仓库建模（ Inmon 或 Kimball ）过程、可视化分析报表实现等几个阶段。 即使现在也有一些 BI 方法论宣称是反对数据仓库建模方式的，但也仍然无法回避其它前期的工作部分。

商业智能 BI 的基本定义

以上的每一个阶段都存在很大的变数：业务架构自底往上的调整、分析需求的变化、业务数据计算逻辑的变更等。 在不了解客户实际资源能力、项目支持力度，一味拔高用户对商业智能 BI 的期待， 而选择性的弱化商业智能 BI 项目后期的风险、用户的实际投入、长远规划...实际上是一种不负责任的表现。

对于商业智能 BI，我们不谈具体的技术和具体的工具产品，只来客观中立的说说它的几个特点以及相关的认知。

三分产品，七分实施

在商业智能 BI 项目中，大多数情况下产品的因素只能占到三成，七成来自于专业的技术开发、落地实施服务。

有很多 BI 工具本身都非常的优秀，在不同的使用场景下，特点鲜明，但是最终很多项目也是以失败而告终（ 客户没有用、没有二期 ）。究其原因在于前期承诺的太满，一味的只告知客户产品功能多么的强大，但是却很少告知针对企业目前的现状可能会存在的风险。 比如：

1. 告诉我们的客户在数据库的数据直连打通后，直接拖拽建立表与表之间的关系就可以了，但是却不会告诉业务系统的数据可能要经过复杂的清洗和转换。

2. 告诉我们的客户你们是可以做到自准备数据的，但是却不会告诉客户自准备的数据一定是格式良好的，复杂的数据处理是一定需要专业的 ETL 工具开发的，业务人员是绝对做不到自己搞定一切数据准备工作的。

3. 告诉我们的客户 BI 项目是不需要构建数据仓库模型的，数据仓库是落伍的、过时的方式，但是他们却在自己的每一位实施顾问招聘职位中一定要求应聘者有两年的数据仓库开发经验。

诸如此类的问题还有很多，并且通过对不同的用户进行调研，发现他们可能潜在的风险还不完全相同，所以实际上也很难有一款商业智能 BI 工具能够完美的解决用户的所有问题。那么这些无法解决的，实际上就需要经验非常丰富的专业 BI 开发、架构、业务分析人员来进行把控并进行个性化的开发、服务和引导工作，并且也需要客户能够达到一定的成熟度。

产品的作用在于提高工作效率，更高效的将各种复杂技术问题简单化。但尽管如此，产品工具的对于商业智能 BI 成与败的影响因素只能占到三成，剩下的七成实施服务才是最重要的。

派可数据针对不同的项目运用不同的 BI 实施方法论

比如基于不同行业的数据分析指标体系梳理的能力、取数与ETL 数据处理能力、数据抽取策略设计能力、数据仓库建模能力、数据仓库实施方法论落地能力、具有很强逻辑性的数据可视化图表设计和开发能力等。

但对于很多优秀的 BI 工程师，不同的 BI 工具在其手上都可以最大程度上无差别的把商业智能 BI 的实施服务做到最好。

所以，通过以上了解基本上也可以看出实际上即使是一个小型的商业智能 BI 项目也是无法做到几天时间或者一两周时间就可以完整落地的，并且是零风险的，这违背了一个商业智能 BI 项目的正常开发周期。

当然，如果愿意牺牲底层数据构架，仅仅以最终的可视化分析图表内容来吸引用户也是可以做到的。就如同在很短的时间将一个房屋粉饰一新，短时间内没有问题，但是时间长了当出现问题要修补，把房屋墙面底层扒开一看可能看到的就是任意的走线、混乱的水电、以土为沙的墙面。后期需求的扩展如何保证 ？是否意味着真正的零风险 ？二期维修的成本是否还高于新建的成本，这些问题都应该认真考虑。

最后，我们并不否认不同 BI 工具之间一定存在产品能力的差异，但不应该过分强调一款 BI 工具在违背了 BI 开发生命周期的前提下还能够完美的解决用户的一切问题。

在一个完整的商业智能 BI 项目中，刨除需求分析等基本工作，20%的时间耗在前端可视化报表设计开发阶段，80% 的时间都耗费在底层的数据开发包括 ETL 、建模、需求变更引起的底层数据调整等。

举个很简单的实际案例，这是我们在客户业务系统中看到的一张表，要做的事情是什么呢？就是计算部分操作节点（ 0034、0035、0036、0048 等 ）之间的时间周期，最后做 KPI 统计，实际的场景比这个示例数据要更加的复杂。

这里面包括了一系列的数据处理、节点回溯与去重计算等等，这些很难由业务人员自行处理，所谓由业务人员自准备数据、直接拖拉拽基本上是不可能完成的事情。

数据清洗处理中的业务计算规则

更详细的数据统计分析需求规则

不同的用户时间节点的组合规则各不相同

有的数据排列组合简单，有的复杂

类似于这样的数据处理、业务逻辑计算在实际的商业智能 BI 项目中非常的多，BI 项目中 80% 的大部分时间就耗在这些地方，除此之外例如数据的增量抽取策略、维度和事实选择、分析建模等都是不如可视化报表那么直观可体现的工作。

所以，我们不能简单的认为商业智能 BI 就等同于可视化分析报表的开发，在一个可视化报表出来之前，实际上我们做了大量的基础数据准备工作。

有了上面的理解和认识，再来说下我们在很多客户反馈中听到的 ”敏捷 BI“ ，”你们能不能“的话题。简单来说，所谓的 ”敏捷 BI“ 只能敏捷在上面提到的 20% 报表部分，在底层的核心数据处理、数据架构设计是敏捷不起来的。当然，现在也有很多非常优秀的数据集成 ETL 产品可以加速底层各系统数据的拉通，但是在核心架构设计、BI 方法论的实现上该投入的时间还是一定要投入的。

“敏捷 BI”的大多数现场演示都是基于提前准备好的数据，做可视化分析报表，拖拖拽拽看起来确实很快很方便产品很强悍。但是，实际上如果在现场给几个业务系统，做几个超出演示方案之外的分析，就会发现结果并不是像宣讲的那样顺利。因为即使是一个最简单的分析指标也可能需要从几个不同的系统取数并进行业务规则的计算，这部分时间是谁也省不掉的。当然，碰到 1+1 等于几的问题除外。

之所以出现这种概念，并且在 BI 行业中形成了我们都是 ”敏捷 BI“ 这样的结果，实际上是从市场宣传的角度来考虑的。但只要深入了解就会发现，其实中间存在着很多偷换概念的地方。

在最初的 BI 行业话题中，至少在 2013 年以前，是不存在“传统 BI”或者“敏捷 BI”这样的一个说法的。后来随着 BI 市场在国内的兴起，部分 BI 厂商为了赢得市场而创意性的创造了这种对立。这种概念的提出在当时是一种很好的市场宣传手段，很吸引眼球，也为商业智能 BI 在国内的普及做出的很大的贡献，这是值得肯定的一部分。但是随着这些宣传深入，其它很多 BI 厂商的跟风，整个方向其实是越走越偏的。这种可怕的结论就是：“敏捷 BI”就是牛，“传统 BI”就不行了，这是包括作者在内在当时的真实感受，但其实到后来发现这样的认知是很片面的。

这种认知的局限来自于我们这批比较早期的 BI 开发人员都是从 ”传统 BI“ 中走出来的，苦 BI 久矣。早期的“传统 BI”的特点是什么，底层有良好的数据架构和数据仓库模型，虽然重数仓重模型，但是架构稳定。最根本的问题在于：即使简单关联几张表都需要写 SQL 查询，前端也缺乏一个可以完全靠拖拉拽就可以自由实现可视化图表分析的展现方式。

早期的报表即使做一个很简单的

从 Overall 到 United States 页签切换钻取

都需要写代码

同时设置两个图表之间的显示和隐藏

在早期的商业智能 BI 产品中，例如 IBM Cognos、Oracle BIEE、SAP BO、Microsoft SSRS 等，整个的 BI 的开发，包括可视化报表开发确实是需要 IT BI 开发人员不断的迭代维护的，包括报表的钻取、联动、跳转、动态维度的筛选等等这些基本功能。

这些基本功能放在今天很简单，但是在以前即使一个很小的调整也的确是需要 BI 开发人员手工调整的甚至要写很多的代码，并且对报表的要求就是只要图能出来能展现就可以了，美观不美观，不关我的事。

派可数据可视化分析效果

所以当我们这批比较 ”传统 BI“ 的开发人员看到这种非常敏捷的、自助拖拉拽式、零编程的可视化分析工具出现的时候，的的确确有让人眼前一亮的感觉，并迅速的成为这些产品的粉丝和摇旗呐喊者。但我们可能都忽略了一个细节，这种认可的前提是我们在 “传统 BI”的架构中大多已经有完整的底层数据仓库，基于这些已经处理好的、标准的、数据格式良好的基础数据，我们的 “敏捷 BI” 的的确确充分的发挥了它的能力并对 ”传统 BI“ 形成了”碾压“。

其实现在来看，这种”碾压“ 只是体现在了可视化分析报表的敏捷部分，但却忽略了”传统 BI“在底层数据架构、数据仓库建模、ETL 数据处理规范等一切的努力。

在这样的一种错误认知和市场宣传角度下，似乎“敏捷 BI”的确是取代“传统 BI”的最佳方案。结果就导致大家都开始做敏捷方案了，朝着一个反数据仓库的方向发展，很多企业不再在业务的复杂程度、底层数据架构的合理性和稳定性上做资源投入。

这种一味追求敏捷开发，其恶果通常会在“敏捷 BI”上线之后的一到两年内逐步浮现 —— 业务调整引起的底层数据架构变动，由于缺乏合理的分层和维度一致性，导致很多依赖的报表无从修改和调整；核心逻辑代码没有复用性；指标定义重复等。我们已经在很多客户的项目中看到了这种情况，而我们派可数据现在要做的事情就是帮助客户重构分析指标体系以及底层数据仓库的设计等工作。

看似花哨的动作恰恰是篮下的终结者

强大的腰腹核心力量支撑与滞空能力

前端灵活多变“花哨”的可视化分析展现

何尝也不需要一个强大的 “腰腹核心”

合理的底层数据架构就如同一个人的腰腹核心，缺乏核心力量的支撑，一个人上肢再怎么健壮都是不协调的。

所谓的敏捷，它的使用前提是建立在良好的数据规范和格式基础之上的，缺乏格式良好的底层数据结构，是无法敏捷起来。所以，对于“敏捷 BI”的定义，把它归于敏捷可视化报表一类要更加合理一些。或者更进一步说，”敏捷 BI“ 更适用于部门级和个人级的数据使用场景，基于系统导出的相对规范的数据来快速进行数据可视化分析，或者基于一个比较完整的、高度可扩展的底层数据架构，这样才是”敏捷 BI“能充分发挥价值的地方。

在此，我们并不是要彻底否定“敏捷 BI”，而是需要明确指出它最适合的使用前提和最佳实践场景，而绝非是一提到 BI 就是“敏捷 BI”比“传统 BI”强的错误认知。

后台 — 良好的数据架构、分类

前台 — 良好的分析

我们需要再次强调：在底层数据架构设计上省时间，就意味着后续会面对很多不可控的因素。 只有对数据进行良好的设计和分类，才能真正做到“敏捷”，数据才能“拿”的快。

在最后需要说的是，经过这么几年的发展，所谓的”传统 BI“在前端可视化方面现在与”敏捷 BI“也没有太大的差异，从产品和技术角度都已经追赶上来，所以关于”敏捷 BI“和”传统 BI“的争论也可以休矣！

总之，“敏捷 BI”并不总是敏捷，“传统 BI”也并不总是传统！

商业智能 BI 的市场是一个阵地战

商业智能 BI 无论从专业性上、技术复杂程度上、实现方法论、项目周期上都是需要贴合项目实际情况并充分考虑的，所以它并不是产品因素可以唯一决定的。同时，商业智能 BI 仍然是一个集产品、开发技术、BI 建设方法论为一体的专业领域，它不像传统的报表市场，只要开发人员懂基本的 SQL 语句就可以快速上手做几张分析报表。Report 报表不等于 BI，但 Report 报表可以是 BI 前端的一部分或者一种展现形式。但我们现在看到也有很多企业，SQL + Report 报表就等同于 BI，实际上理解很片面。

Dashboard -> 局部比较 -> 个体洞察 -> Report 报表明细

至少从目前来看，商业智能 BI 在国内的发展还无法做到大规模产品化的高速曲线成长。

一方面 IT 信息化走了这么多年，还有很多企业数据基础薄弱，数据缺失、数据不规范的情况比较普遍。在 BI 项目开始前的底层数据采集和治理方面需要投入的时间和精力很多，并且很难完整的标准化，这些前期由业务系统建设的问题而带来的困难是 BI 工具无法解决的。

另外一方面，想完全的推进“业务驱动”代替“IT 驱动”对企业的底层数据规范、数据架构支撑、用户的业务和数据意识等要求都非常的高。所以想完全放手让业务人员自己承担起从源数据到最终可视化分析难度其实很大，因此比较完美的可持续性成长的架构仍然是 IT 主导底层数据架构 + 数据集市分析主题 + 业务用户自助分析的方式。但仍然有一个很重要的前置条件：精通业务 + 良好的数据思维意识 + 合理的数据架构，这三点缺一不可。

因此，目前商业智能 BI 在国内的现状就是：它打的仍然是一个项目制为主的，靠着开发顾问的技术经验、业务经验、劳动付出的一种产品+实施的阵地战。

当然，能看出这个问题的本身就说明这一切也都是相对的。

（全文完）

本文由派可数据原创，如需转载请必须注明来自派可数据 www.packingdata.com，否则按侵权处理。