包治百病、药到病除的商业智能 BI
我们经常会碰到我们的伙伴、企业客户向我们提出这样的问题：“某某厂商说他们的 BI 工具交项目交付很快，基本上用他们的产品几天或者一周就可以把项目做完，敏捷开发，零风险，你们能不能？”，“某某 BI 厂商说他们的工具可以直接连我们的数据库，连完数据库就可以做报表，不懂 IT 技术也没有关系，业务人员自己就可以做分析报表，你们能不能？”，“某某 BI 厂商说他们的自主分析很强大，什么业务问题只要拖拉拽就可以做分析，能一眼看出企业存在的经营管理问题，什么业务数据实时预警决策都不在话下，你们能不能？”...
我们的回答是：不能，因为我们的确做不到。并且我们也始终不能理解像这样的一款 BI 产品如此强悍的能够搞定上面的这些场景，究竟是如何做到的。我们在网络上搜索了一下这些宣传文案，看了之后的感觉就是只要你买了我们的药，不用望闻问切，就可药到病除，包治百病。
一个完整的商业智能 BI 项目一定是经历过业务需求分析、分析指标体系梳理、源数据和数据质量调研、ETL 数据的抽取、清洗转换和加载、业务计算逻辑到数据计算逻辑的实现、数据仓库建模（ Inmon 或 Kimball ）过程，可视化分析报表实现等几个阶段的。即使是现在的很多 BI 厂商宣称他们是不需要构建数据仓库的，不需要预先建模的，其它的这些过程也仍然是必不可少的。
以上的每一个阶段都存在很大的变数：业务架构自底往上的调整、分析需求的变化、业务数据计算逻辑的变更等等，这以上的哪一条可以让我们的 BI 项目是可以几天或者一周交付完成的，以上的哪一条是可以敏捷的，以上的哪一条是可以零风险落地的？
并且不问客户实际资源能力、项目支持力度，一味拔高用户对商业智能 BI 的期待，这些不客观的认知造成的后果就是：BI 太烂，某某公司上了几年 BI ，做的稀烂。类似于这样的评价和行业口碑，受影响的是整个 BI 未来的市场。
对于商业智能 BI，我们不谈具体的技术和具体的工具产品，只来客观中立的说说它的几个特点以及相关的认知。
三分产品，七分实施
在目前国内的商业智能发展现状下，大部分 BI 工具其实已经越来越同质化，甚至连一些非 BI 领域的厂商例如一些 OA、CRM、ERP 服务商都开始进入 BI 市场。尽管如此，在企业中的商业智能 BI 项目中，起到真正决定性因素的是人，这些人包括：懂业务的需求分析师、懂分析的 BI 开发工程师、懂 BI 的架构师以及相关数据开发人员。
国内外的很多 BI 工具实际上都非常的优秀，在不同的使用场景下，特点鲜明，但是我们也看到很多上了这些产品的项目最终都是以失败告终。 究其原因，很多 BI 厂商承诺太满，一味的只给予产品功能多么的强大，但是却很少告知针对企业目前的现状可能会存在的风险。比如，厂商会告诉我们的客户数据是可以直连打通的，是直接可以写 SQL 的，但是却不会告诉业务系统的数据可能要经过复杂的清洗和转换；厂商会告诉我们的客户你们是可以做到自准备数据的，但是却不会告诉客户自准备的数据一定是格式良好的，复杂的数据处理是一定需要专业的 ETL 工具的；厂商会告诉我们的客户我们的产品是不需要构建数据仓库模型的，但是他们却在自己的招聘职位中一定要求应聘者必须懂数据仓库。
产品的因素在于提高工作效率，更高效的将各种复杂技术问题简单化，但尽管如此，产品工具的因素只能占到三成，剩下的七成实施服务才决定了商业智能 BI 项目的成与败。
二八定律
在一个完整的商业智能 BI 项目中，只有 20%的时间在做可视化报表，80% 的时间都耗费在底层的数据开发包括 ETL 、建模、需求变更引起的底层数据调整等。
举个很简单的实际案例，这是我们在客户业务系统中看到的一张表，要做的事情是什么呢？就是计算各个操作节点之间的时间周期，最后做 KPI 统计，实际的场景比这个示例数据要更加的复杂。这里面包括了一系列的数据处理、节点回溯与去重计算等等，这些很难由业务人员自行处理，所谓由业务人员自准备数据、直接拖拉拽基本上是不可能完成的事情。
类似于这样的数据处理、业务逻辑计算在实际的商业智能 BI 项目中非常的多，BI 项目中 80% 的大部分时间就耗在这些地方，除此之外例如数据的增量抽取策略、维度和事实选择、分析建模等都是不如可视化报表那么直观可体现的工作。
如何客观认识敏捷 BI 和传统 BI
在最初的 BI 行业话题中，是不存在传统 BI 或者敏捷 BI 这样的一个说法的，只是部分 BI 厂商为了赢得市场而创意性的创造了这种对立。这样的一种概念的提出是一种很好的市场宣传手段，可能放在五年前，这样的话题炒作是没有问题的，但是放到现在显然是不符合实际的。
在最初的商业智能 BI 产品中，例如 IBM Cognos、Oracle BIEE、SAP BO、Microsoft SSRS 等，整个的可视化报表开发确实是需要 IT BI 开发人员不断的迭代维护的，包括报表的钻取、联动、跳转、动态维度的筛选等等这些基本功能放在今天很简单，但是在以前很小的调整也的确是需要 BI 开发人员手工调整的。
所以当我们看到那种非常敏捷的、自助拖拉拽式、零编程的可视化分析工具出现的时候的的确确有让人眼前一亮的感觉。但是我们可能都忽略了一个细节，这种认可的前提是我们在 “传统 BI”的架构中大多已经有完整的底层数据仓库，基于这些已经处理好的、标准的、数据格式良好的基础数据，我们的 “敏捷 BI” 的的确确充分的发挥了它的能力。
在这样的市场宣传角度下，似乎敏捷 BI 的确是取代传统 BI 的最佳方案，结果就导致大家都开始做敏捷方案了，朝着一个反数据仓库的方向发展，很多企业不再在业务的复杂程度、底层数据架构的合理性和稳定性上做资源投入，一味追求敏捷开发，其恶果通常会在敏捷 BI 上线之后的一到两年内逐步浮现。
合理的底层数据架构就如同一个人的腰腹核心，缺乏核心力量的支撑，一个人上肢再怎么健壮都是不协调的。所谓的敏捷，它的使用前提是建立在良好的数据规范和格式基础之上的，缺乏格式良好的底层数据结构，再怎么敏捷也无法敏捷起来。所以，对于敏捷 BI 的定义，把它归于敏捷可视化报表一类要更加合理一些，敏捷在于前端的可视化，但它并不能代替 BI 的全部。
后台 —— 良好的数据架构、分类 前台 —— 良好的分析
在底层数据架构设计上省时间，就意味着后续会面对很多不可控的因素。 只有对数据进行良好的设计和分类，才能真正做到“敏捷”，数据才能“拿”的快。
所谓的传统 BI 在前端可视化方面现在与敏捷 BI 也没有太大的差异，所谓的敏捷 BI 实施服务也必须要求实施人员懂数据仓库。因此，敏捷 BI 这个概念可以扔到历史的垃圾桶了，关于敏捷 BI 和传统 BI 的争论也可以休矣！
总之，敏捷 BI 并不敏捷，传统 BI 并不传统！
商业智能 BI 的市场是一个阵地战
商业智能 BI 仍然是一个集产品、开发技术、BI 建设方法论为一体的行业，它不像传统的报表市场，只要开发人员懂基本的 SQL 语句就可以快速上手做几张分析报表。报表不等于 BI，但报表可以是 BI 前端的一种展现形式。
商业智能 BI 无论从专业性上、技术复杂程度上、实现方法论、项目周期上都是需要贴合项目实际情况并充分考虑的，它并不是产品因素唯一决定的。
因此，商业智能 BI 在国内的发展目前还无法做到大规模产品化，它仍然是一个项目制为主的，靠着开发人员的技术经验、劳动付出的一种产品+实施的阵地战。
当然，能看出这个问题的本身就说明这一切也是相对的。
（全文完）
派可数据联合创始人 吕品，前天善智能联合创始人&运营总监，十余年商业智能 BI 行业经验，2015-2019 微软 MVP
閱讀更多 派可數據可視化分析 的文章
