我们产品的名称由2部分组成，SMART+BI，前者就是聪明的、敏捷的，后者就是商业智能。这也说明自产品诞生起，我们一直以“简洁实用”的BI作为努力的目标！通过看到市场上琳琅满目的宣传广告，以及Smartbi自身的服务和研发，我们终于“不惑”！

首先，敏捷BI并不是指某个前端工具软件，而是贯穿在数据分析平台构建和运行过程中的快速实现能力。

简单来说，评价是否是敏捷BI应该从以下角度：

•  IT可以快速提供可选的分析数据；
  




• 非常简单的给现有报表增加字段；
  




•  能够快速完成新仪表盘的制作；

其次，具有敏捷BI属性的前端分析软件，不是”传统BI”的替代品！

二十几年前与BI、数据仓库同时诞生的OLAP（Online Analysis Process），正是由于为业务人员提供了灵活的分析、计算、钻取能力而风靡全球。但过去的十年，OLAP的产品却不再风光，出现这个问题的不是其需求发生了改变，而是其技术不够简单，或者说违背敏捷BI的潮流。但是，随着Apache Kylin项目的成功推广，OLAP即将在大数据时代重新焕发青春。

再举个例子，Business Objects曾经因“语义层”和“内存Cube”的专利技术，在十年前得到了广泛的认可，也最终以78亿美金出售给了SAP。当时BO的用户，就是能够在敏捷BI的方式下进行自助分析。无论是当时，还是现在，业务人员的需求没有变化，他们一直需要能够快速、便捷的分析数据，以及做出一些漂亮的图形去做汇报！

因此从软件本身，从来没有两个派别，只有不断的技术创新和发展。、

最后，敏捷BI无法替你解决需求分析、数据准备、平台管理等难题！

无论Smartbi还是别的前端分析软件，都只是将数据平台（数据库、数据仓库、大数据平台）的数据统计展现出来，都是将大数据变成可读懂的小数据的过程。

•    如果使用者不能确定数据能否覆盖潜在需要，同样不可能得到有用的分析结论；
  




• 如果数据平台的数据是脏数据，统计展现的结果一定也是不准确的（”Garbage in,gargage out”这句话依然有效!）；
  




• 如果快速制作的报表，不能在安全的前提下发布给报表消费者（一般是领导），对于大型的用户，同样都是重大风险；
  




• 如果数据源变更了内容，但不能确定受到影响的有哪些应用，谁敢轻易变更；

总之，敏捷BI是客观存在的市场需求，Smartbi和其它软件都在构成敏捷BI的前端分析工具环节不断实践和思考。比如，我们认为未来改进的方向应包括以下3个角度：

从逻辑上说，这三条是构成敏捷BI的“必要条件”，而不是“充分条件”。元数据与高性能都是缘于技术架构的，在各个软件之间差异很大，但在简易操作方面，各个厂商都有自己的设计，也才能满足不同类的用户操作需求。

3. 敏捷商业智能的本质

前文从大数据等时代背景，分析了敏捷BI需求存在的合理性，也通过解读敏捷BI的误区提出了敏捷BI软件的“金三角”，但敏捷BI有没有一个最能让我们记住的核心价值呢？答案是肯定的，那就是“快而有效”！

从汉语词典中可以查到，敏捷一词的基本释义就是“反应迅速快捷”，词性为“褒义”！那么在数据分析（BI）行业，敏捷具体体现在以下四个方面：

3.1.  快而有效的交付

交付是一个动词，那么从其主语（操作者）和宾语（需求方）来剖析，有这么四种情况：

	主语	宾语	扣个帽子
情况1：	技术操作者	业务需求方	经典的BI项目
情况2：	技术操作者	技术需求方（领导）	IT主导的BI项目
情况3：	业务操作者	技术需求方	“这是不可能的”
情况4：	业务操作者	业务需求方（领导）	敏捷BI提倡的

其中情况2、3都是小概率事件，我们不予探讨。而从情况1、4来做系统性的分析，我们可以看到共同的宾语（交付对象）都是业务需求方。那么在任何规模以上企业、政府中，业务需求方对BI一般会有哪些需求呢？

■      需求一：获取数据

其实这个需求最普遍，也最不用解释，任何软件（包括BI）都要提供Excel导出功能。这背后的原因可能是业务需求方自己有一些数据，他需要从平台补充做分析；也可能是用户习惯于使用Excel做报表、做计算。

■      需求二：制作报表

这个是用户的核心需求，大多数的业务需求方使用BI平台软件，都觉得制作一份简单的统计报表比较方便、快捷，往往通过拖拽就可以完成了。尤其在管理需求瞬息万变的情况下，企业有大量的制作报表需求，而且往往要得快、要得急。

■      需求三：探索分析

制作报表是目标非常明确的需求，但很多情况下，需求方往往只给出了模糊范围或者方向，需要操作者通过一定的思考过程来完成报表。这时就是前文所提到的OLAP匹配的场景，操作者通过拖拽、钻取等操作，首先要了解都有什么数据，然后再理解其中数据的相关性，最后完成一份图表的设计。

■      需求四：编制报告

无论是需求清晰的报表需求，还是从探索分析而确定的分析图表，30%的操作者会选择用仪表盘进行综合的展现，也会有20%将其用到企业月度、年度的分析报告（Word/PPT）当中。其中分析报告的制作过程都是操作者最为苦恼的经历（没有例外）。

■      需求五：发布

最后，无论你做的图表、仪表盘还是分析报告，50%会用于发布给需求方，比如通过PC浏览器、大屏幕或者APP。尤其越有价值的数据分析结果，越会被发布出来。

因此，快而有效的交付，就是无论谁操作软件，都能非常简单顺利的实现如上5个需求，就是对敏捷BI最重要的实现。

3.2.  快而有效的部署

规模以上企业、政府往往都已经构建了基于标准技术的数据平台，比如MPP数据仓库或者Hadoop/Spark等环境，为大数据的存储和计算提供了基础保障。敏捷BI应当能够复用这些资源，毕竟分析数据不是每个人都需要操作的，不用考虑“大并发”的应用场景（一般不会超过100人）。

与此同时，以各种形式做中间单点存储的架构（比如一些MOLAP产品）将不再必要，刨除微软相关产品，敏捷BI都应该是2台应用服务器集群就能够满足要求，并可以与用户自身的系统进行完美的集成。

3.3.  快而有效的变更

一次性的部署或者交付即便再复杂，如果没有后期的变更，那么大家也都不会关注。但事实是敏捷BI就是一个不断迭代、优化、变更的过程，因此以下几类变更都需要被考虑：

■     展现结果的变更（组合形式或图形的变化，代价最小的变更）

■     需要更多的数据（能够快速找到以前的数据从哪里来）

■     源于数据源的被动变更（上游变更传递过来后，需要评估其影响范围）

3.4.  快而有效的查询

性能，尤其是在大数据下的查询性能，是所有用户最为关心的维度。用户操作的结果能否快速返回，决定了其分析思维能否连贯的进行下去，更决定了试误操作的成本代价。

但其实性能解决方案，应当是整体技术架构的考虑，而不应该被认为是前端分析软件自身的责任。这好比买车上路，能开多少速度，一方面是车的性能，但更重要的是路况及限速要求！

敏捷BI不应依赖自身构建数据计算能力，比如内存计算或者定制Hadoop，如果这样做，首先违背了第二条本质，同时也给自己适应大数据分析埋下了地雷，因为不可能在相对合理的成本下把大数据全部复制到内存或者文件系统当中。这点已经可以从国外知名产品得到证实。

4.  如何实现敏捷商业智能

2014年，该银行部署了Smartbi，实现了自助数据分析平台，现在小A需要分析数据时，只需要登陆指定的安全桌面，在其中完成指标定位、拖拽制作、保存报表即可，如果需要得到真实数据到本地，也只需要在系统自动提交审批即可完成。

在这样的需求背景下，Smartbi以开放的技术架构、丰富的操作特性和贴心的运维管理破解了业务需求与IT服务围绕“数据”的矛盾，释放了银行数据生产力，加速了中大型银行在互联网时代的转型速度，提高了面对市场的决策效率！

4.1.  开放的技术架构

Smartbi以开放的架构融入该银行的技术平台，查询计算被分解为2个阶段，提取数据的计算交给大型的MPP数据仓库（或Hadoop）完成，类OLAP分析的前端计算由内存计算（或其它缓存方式）完成。如果用户只是提取数据，那么内存计算能力就不会被消耗。而且计算能力的分布方式可以根据客户的情况进行随时调整，Smartbi也不需要落地的存储资源，极大的体现了敏捷BI的部署便捷性。

4.2.  丰富的操作特性

Smartbi为小A这样的数百名业务人员提供了丰富的操作功能，满足其取数、制表、分析、报告、发布等五类查询需求。我们从小A使用过程的3个环节进行详细说明：

具体说明请了解“Smartbi自助分析版V6”产品白皮书

4.3.  贴心的运维管理

平台的完美运行离不开小B的贡献，他完成了从报表开发人员到数据平台管理员的转变，为各个分行的小A们提供了重要的系统保障。我们也从小B日常工作的三个环节进行说明：

具体说明请了解“Smartbi自助分析版V6”产品白皮书！

4.4.  敏捷商业智能的意义

通过小A和小B的场景化描述，可以看到作为敏捷BI的参与者，Smartbi自助分析版以其开放的技术架构和独特的功能特点，获得了银行、电信等客户的长期认可。

通过部署“自助取数与分析平台”，客户获得的真正价值包括：

■     数据产生于业务部门，现在也可以回归于业务部门进行分析利用，从而实现信息化的真正闭环，推动数据质量、数据完整性的建设；

■     IT部门更加专注于技术的创新与应用，比如引进Kylin等大数据分析平台，也可以更加投入在元数据的维护与管理上，提升分析平台的服务效率；

■     对于个人来说，业务部门的分析人员学习到了更多的工具，而技术人员也因为掌握数据知识而转型为业务分析师的机会。这样的人员内部流动对企业来说更是释放了潜在的内部生产力；

■     对企业来说，数据不再是搁置在硬盘上的1-0，而是能够驱动全面决策的数据资产，从这样的结果来说，IT部门因此能够得到更充足的资金预算；

■     对实施来说，漫长的交付周期能够缩短50%，主要精力放在数据模型、安全体系、元数据服务等基础工作上就可以了。