管理驾驶舱大屏 - 派可数据BI可视化分析平台
但凡有任何BI的销售或者售前告诉用户，你们企业的 BI 项目不需要构建数据仓库，直接通过 BI 分析工具拖拉拽就可以搞定企业里面所有的分析，不需要IT人员支撑，业务人员完全可以自己搞定... 类似于敢这样承诺的，要么是对BI不懂，要么就是真忽悠。
在企业级的BI项目建设中，真正能做到完全靠业务人员简单拖拉拽一些就能随便实现数据可视化分析，至少在我个人从业的十几年工作经验中，95%以上的企业都做不到。我服务过的重点企业包括：SHP（ Security Health Plan )、微软（中国）、微软（美国）、VWFC（ 大众金融 ）等。
VWFC 做的算是非常不错的，少有的业务人员自己动手做很多报表，线上跑了几千张报表。为什么？ 因为底层数据仓库就搭建了很多年，底层数据架构相对比较规范。Business Driven 业务驱动，它的前提是什么？
1） 底层数据质量很规范，数据仓库架构很完整，不让业务人员碰底层数据，ETL、取数、指标计算等等统统都是 IT 部门来维护。
2） 业务人员通过培训要熟练掌握BI前端报表工具的使用，要很懂放出来的数据分析模型接口。
3） 业务人员要非常熟悉业务和数据。
第 2）和第 3）条很多企业没有问题，第 1）条直接弄个前端 BI 工具让业务人员解决，能解决掉吗？ 很显然业务人员是不具备这种能力的。
这就是一到培训的时候，BI工具使用起来很简单，但是一旦到实际的企业 BI 项目开发就发现寸步难行。因为培训的时候，给出的数据表都是经过选择的，永远都是质量很高的、规范的只需要简单左表连右表例如销售订单表、订单明细表，自然很容易把可视化报表给实现出来。
数据可视化 - 派可数据BI可视化分析平台
但是在实际企业 BI 项目分析中，分析指标的计算规则绝非简单几张表关联就可以解决的，不信的话可以挑战一下一个实际的指标计算逻辑：挑战一个 ETL 数据清洗的小案例 在数据库中就一张数据表，数据理解起来也很简单，但很多 BI 开发人员做起来也需要废很大的精力，就更别谈业务人员自助 BI 分析了。
讲这么多不是为了一味否定自助式 BI 它的作用和能力，自助式 BI 有它的使用场景，也确实帮助我们简化了很多的BI工作，但从专业角度出发，特别反感是部分BI 厂商以一种不负责任的方式反复向市场强化类似于这样的概念：BI 就是可视化报表、BI 不需要数据仓库建模、传统数据仓库建模很落后、BI 就是自助分析、BI 自助分析很简单、业务用户简单几天培训就可以学会并且想怎么分析就怎么分析...
从市场宣传和销售的角度来说，简化产品的复杂度和上手难度的宣传是没有问题的，有问题的是以一种错误的讲解、不专业的讲解最终误导企业接受了这些不正确的概念，并以这些不正确的概念来评估与规划 BI 项目的建设，没有充分预计到 BI 项目建设过程中可能会遇到的挑战与风险，最后导致项目的不成功与失败、反复建设。
我们在北京就有一个客户之前花了一百多万上了一套所谓的 BI 项目，项目上线了一年左右，到最后完全推不动，失败了。后续找到派可数据，我们给他们上了派可数据BI分析平台，这个项目我们连续做了好几期，客户还写了感谢信。之前为什么推不动、项目会失败：不重视数据仓库的规划。因为他们的业务是连续的、变动的，每年的需求都是需要动态调整的，数据持续增加，分析的深度和广度都是在不断变化，没有一个好的底层数据架构来支撑，光靠 SQL 取数、建数据集出报表的形式是不可能支撑一家企业未来 3-5 年甚至更长远的业务分析需求变化的。
除了这个案例之外，在我的手机上有很多之前上过 BI 最终失败、没有做好，找过来聊天吐槽的记录，是真的产品不好吗？我也客观的帮助他们分析过：这些产品本身有的是 Gartner 魔力现象 Leader 象限的产品，你说产品行不行？ 有的产品是国内BI领域很多年的老品牌，你说产品行不行？ 客观来讲，这些产品从我个人角度来说，这些产品其实都很优秀，产品本身是没有太大问题的。
问题在于，这么多从零到一需要上 BI 的企业不知道一个 BI 项目中原来还有那么多坑，很多 BI 厂商会不会去把这些点给企业客户讲清楚，一个 BI 项目到底怎么干、中间有什么样的风险、以后还会遇到什么样的问题、应该怎么解决这些问题、有什么样的方法论和手段... 如果只是为了卖一套 BI 产品或者工具，你觉得这些 BI 销售会跟客户讲这些东西吗？ 不会的，至少不会讲的太深太全，因为这么一讲把 BI 难度讲太复杂了，一旦没有讲好，反而降低了客户的信任。
有的时候不讲，是因为怕讲复杂了，让企业客户决策周期拉的太长了。有的时候不讲，是因为不懂。你不讲，客户不知道，客户也没有经验，后续BI项目建设就会出问题。
在一次大会上，某BI厂商一位高级售前技术专家在跟客户交流时说过的一句话：BI直连不香吗？直接连接数据源不就可以做分析，不需要数据仓库。无知者无畏，实在听不下去，就打断直接沟通了一下。通过沟通，可以判断这个所谓的技术专家基本上没有做过完整的 BI 项目经验，从零到一搭建一个 BI 项目的能力等于零。以这样的一种能力跟客户来引导一个 BI 项目，这种 BI 项目的质量能有保证吗，很难的。
这也就是我们派可数据、我个人做视频号《吕品聊数据》的原因，客观的讲讲 BI、客观的讲讲数据，普及一下我们认为正确的 BI 知识和概念。告诉我们广大的 BI 用户，BI 到底应该怎么理解、怎么认知，BI 到底有什么样的坑需要我们的企业注意。
我们不能说我们派可数据在 BI 领域讲的知识和概念就一定是放之四海而皆准的，但是我们欢迎任何 BI 厂商或者任何BI个人爱好者就 BI 的一些知识和概念来向我们挑战，来看看派可数据所普及的一些 BI 知识概念到底对不对。如果普及的对，说明这些问题大家确实都碰到了，这些知识和概念对于企业而言就是难得的经验。如果普及的不对，不对又是在什么地方，指出来大家一起看看，一起探讨一下，我们还可以为企业做些什么。
八、报表工具是怎么来的？
这十几年我一直在技术领域、信息化领域、BI 行业，一直没有出这个圈。做过 JAVA ( AWT、SWING、JSP、Hibernate、Spring、ibatis )、.NET ( ASP、http://ASP.NET、C#.NET )、Object-C 、JS 等等技术开发，业务软件系统平台开发。
早期前端技术很弱，AJAX 的实现也都需要手写，要实现一个表单内数据的点击编辑和修改需要自己用 JS DOM 操作。做报表基本上就是 JSP、ASP 脚本语言在前端嵌套 HTML 做循环输出，报表样式很原生很丑陋，稍微复杂一点的表格报表样式都需要用 JS 来调整。
那个时候用过的报表像 Crystal Report 水晶报表、润乾报表等等，在前端脚本语言中有标签直接可以引用，报表生成代替了大量的手写代码。早期的前后端技术是不分家的，http://ASP.NET 还稍微好一些，前端逐步有一些集成控件可以直接使用，JAVA 是真没有。上面说到的这个阶段大概在什么时候呢，2005年前后，2007年我觉得已经使用的很广泛了，老的 CSDN 上应该还能找到很多原始的报表标签帖子。
像老一批报表还有像金峰报表 Jreport、思达报表 StyleReport 等等在国内也有一定的市场。早在 2010 年之前，有些报表厂商的收入规模就已经突破了一个亿，说明基础报表这个市场还是非常不错的。
那个时候的报表定位是什么，就是纯粹的 Report 报表，通过程序从后台数据库中查询返回的数据聚合 List 再到前端脚本页面上绑定一下就生成了各种报表，实际上就是用在各个业务软件系统之中的报表展示，还远远没有到 BI分析这个层面。
并且还有大量的软件开发厂商实际上已经具备了很强的报表能力，不过这些报表能力并没有单独拿出来作为报表产品在市面上运营而已。
逐步的，随着前端技术、前端框架的完善，从传统表格技术开始到了各类柱状图、条形图、饼状图的可视化展示，到了这个阶段，报表和BI的边界越来越模糊。为什么？BI的报表展现能力也就和传统报表效果大致相当，还没有出现那种自助分析、自助拖拉拽就可以实现快速多维分析的能力。
讲这么多主要想说的是我们所看到的很多BI项目都是拿报表思维去实现的，就是 SQL 到数据集到前端展现。而真正的BI思维应该是什么呢？ 多维思维、模型思维，这一点决定了一个 BI 项目的最终走向，后面会具体讲到这些点。
九、BI的本质 - 企业业务管理思维的落地
BI到底是什么？技术？产品？还是其它？我们把对于BI的理解再提升一个层次：BI是一家企业业务和管理思维的落地。
BI的本质 - 派可数据BI可视化分析平台
这个怎么来理解呢？简单来说，就是在可视化报表上呈现的内容就是一家企业真正关注的内容，这里面有管理高层重点关注的企业经营性的分析指标，也有某具体部门的。
十、BI 和数据仓库 Data Warehouse 有什么区别和联系？
经常会碰到有人问BI和数据仓库有什么区别，实际上这个问题的背后能反映出来一些朋友对BI的理解还是有些不准确和偏差，这个问题实际上从概念上把BI和数据仓库人为的割裂了。这种情况其实也比较正常，因为大家对BI的第一印象就是各种炫酷的可视化图表、报表，再加上市面上有很多轻量的前端可视化BI分析工具，就造成大家对BI的认知就停留在可视化这部分了。
准确的来说，BI不仅仅包含前端可视化分析、报表展现的能力，更包含了底层数据仓库的建设过程。Gartner 在上世纪九十年代就已经提到了商业智能 Business Intelligence，它更多的认为：BI是一种数据类的技术解决方案，将许多来自不同企业业务系统的数据提取有分析价值的数据进行清洗、转换和加载，就是抽取Extraction、转换 Transformation、加载Loading 的ETL过程，最终合并到一个数据仓库中，按照一定的建模方式例如Inmon 的3NF 建模、Kimball 的维度建模或者两者都有的混合式架构模型，最终在这个基础上再利用合适的分析展现工具来形成各种可视化的分析报表为企业的管理决策层提供数据决策支撑。
BI - 派可数据BI可视化分析平台
所以，可以从这里能够看到数据仓库Data Warehouse 的位置是介于可视化报表和底层业务系统数据源之间的这一层，在整个BI项目解决方案中起到的是一个承上启下的作用。如果把BI比作是一个人的话，上半身特别是脸这个部分就是颜值，下半身脚踏实地吸取大地的精华，中间这部分的腰腹核心、核心力量就是数据仓库。
那大家也会问到，市面上不是有很多直接链接数据源就可以拖拉拽分析的BI工具产品吗，不也一样可以做BI分析报表吗？这种独立的、单独的面向前端的BI分析工具，他们更多的定位是部门级和个人级的BI 分析工具，对于深层次的需要复杂数据处理、集成、建模等很多场景是无法解决的。最好的方式就是底层构建一套完整的数据仓库，把很多分析模型标准化，再利用这些前端BI分析工具结合起来，这样才能真正的把前端BI分析能力给释放出来。
很多企业认为只要买一个前端BI分析工具就可以解决企业级的BI所有问题，这个看法实际上也不可行的。可能在最开始分析场景相对简单，对接数据的复杂度不是很高的情况下这类BI分析工具没有问题。但是在企业的BI项目建设有一个特点，是一个螺旋式上升的建设过程。因为对接的业务系统可能会越来越多，分析的深度和广度会越来越多，数据的复杂度也会越来越有挑战性，这个时候没有一个很好的数据仓库架构支撑，光靠前端BI分析工具基本上是无法搞定的。
