商业智能 BI 分析平台构建重点
企业级商业智能 BI 分析平台的构建是一个系统型的工程，涉及业务分析需求的把控、各类数据资源的整合清洗、数据仓库的架构设计、可视化分析报表逻辑设计、IT 部门与业务部门的工作边界划分与配合等等居多环节。
派可数据可视化自助分析设计器
每一个环节的重要性都不容忽视，今天我们重点选择两个环节进行阐述。是业务分析需求的把控，第二是数据仓库的构建，这两个问题处理的好坏也在很大程度上决定了一个商业智能 BI 项目的成败。
业务分析需求层面
碰到的痛点与解决方式
对于很多准备或者正在规划商业智能 BI 项目的企业来说，业务分析需求的梳理是整个项目开始的步，往往也是困难的：
1. 业务部门往往提不出比较具体的分析需求。
2. IT 部门很难深入到业务，也提不出适合业务部门的分析需求。
3. BI 实施方很难在短时间内梳理清并通过一种非常直观的方式和业务用户进行有效的沟通。
4. 对于管理层、上级领导部门，特别希望可以直接看到可视化报表分析的成果。他们不会去关心技术和如何实现的问题，能不能先让看到效果。只有看到效果，才会有比较直观的认知，这个项目才有可能被认可和立项。
5. BI 项目需求分析涉及到很多部门，有的时候内部资源的沟通、协调和推动往往比外部（乙方）的推动要困难的多。
以上这些点集中起来其实就是一个问题：如何能够非常清晰的梳理好一个完整的业务分析需求，并且能够用业务部门能够理解的语言进行有效沟通？
我们的解决方式是什么呢？就如同下面的房屋装修一样，如果要我们自己从头到尾来设计和装修实际上是一件很困难的事情。
你不能一直给业务讲我们的工具有多么的好用，多么的强大，未来这个房子可以装修成什么样子，这种方式是很难行的通的。
正确的做法是提供一个或者很多个不同角度的设计图或者方案给到用户，有了设计原型参考，用户就一定会有很多潜在的想法表达出来。
有了这种原型，大家始终站在对方可以理解的角度上进行沟通，终出来的效果也一定是自己所期望的。
所以当我们的用户没有这种数据分析思维意识的情况下，让业务用户提出一些分析的想法，或者让领导提出分析的内容是非常不现实的。但是让他们参考一个比较成熟的分析体系或者方案，再来提出自己的想法这样还是比较容易的。
派可数据的做法是：结合客户需求以及派可数据在各个行业多年沉淀下来的业务经验快速的提供各类分析图表，客户可以选择适合企业自身的分析维度和指标、分析模板，或者基于派可数据的各类指标分析体系提出自己的想法，所有可视化分析内容可随时调整以完全达到客户的分析需求。
派可数据的一个独立顾问可以在很短的时间完成用户的分析需求梳理和分析页面搭建，包括各类动态效果、钻透、联动、跳转等等，并且在这个阶段我们不需要连接用户的实际数据源。
派可数据 BI 可视化图表之间的钻取、联动等效果
某客户的业务分析模型梳理
派可数据一个顾问一天半的工作成果
17 个报表页面 250 多个报表原型各种动图
100 多个分析指标，比较真实的模拟数据
VS
类似于上面的这种工作成果
换成其它的 BI 工具至少需要 7- 8 天时间
是派可数据的至少 5 倍投入
数据仓库架构与开发层面
碰到的痛点与解决方式
数据仓库的开发，可以理解为一种技术，也可以理解为一种方法论或解决方案。在商业智能 BI 中，数据仓库就是核心的那一层，起到的就是一个承上启下的作用。往下承接各类数据源中的数据，往上支撑各类分析报表。再形象一点，数据仓库就如同人身体中的腰腹一样，腰腹力量是人的核心的力量，所有的运动都离不开腰腹力量的支撑，重要性不可忽视。
但目前的现状是越来越多的企业为了追求所谓的 "敏捷" 基本上已经放弃了传统数据仓库的构建。敏捷快速开发是没有错的，但很多人错就错在没有分清楚什么时候应该敏捷，什么时候应该保留传统数据仓库的架构。关于这一点，会在以后的文章中专门讲到。
通用的数据仓库架构示例图
同时，数据仓库的构建水平将直接影响到商业智能 BI 项目的整体质量。潜在的问题也恰恰出在这里：数据仓库的架构设计对开发人员的能力要求相对较高，并且在同一个项目上，不同开发人员对数据仓库理解的不一致也可能会造成设计的缺陷。
我们在一些项目上看到的普遍问题是：
1. 完全没有数据仓库的搭建，基本上使用大宽表、临时表组成临时的数据集市，没有统一的维度设计，逻辑基本不可复用。一旦业务逻辑或者维度层次结构发生调整，整个受依赖的所有分析报表基本上全都得改一遍。碰到极端的情况，基本上开发人员宁愿重做也不愿意去改报表，因为没有办法改。这种情况在新项目上线的年没有太大问题，但是随着业务需求的增加与调整，这种问题越来越明显。
2. 有数据仓库的架构，但缺少统一的开发标准和规范。一个数据仓库的设计与维护，不同的开发人员能力各不相同，对于数据仓库的理解程度高低不一。这就造成在设计和开发数据仓库的时候没有统一的标准，大家各自开发各自的，能省事就省事，造成数据仓库系统维度冗余、事实冗余，这对后期的开发维护造成极大的困难。
造成这种问题的原因有很多，有几个点我可以在这里简单总结一下：
1. 现在很多的 BI 分析产品工具整体的设计思路就是在弱化数据仓库的作用，过度的追求前端可视化的效果，过度的追求快速敏捷开发。这类产品的定位实际上更加适用于个人或者部门级的数据分析场景，并不适合一个真正企业级的 BI 项目构建。对于真正注重企业级 BI 的项目开发，我们不应该削弱数据仓库的作用，反而更应该加强。
在这样的一种刻意营造的"行业趋势"推动下，新进入商业智能 BI 行业的开发人员至少有很大一部分很难有机会再深入数据仓库的学习和实践，大部分人的主要工作就是取数和做报表。
2. 大部分经历过传统数据仓库搭建的这批人员要么逐步退出一线开发，要么进入比较稳定的甲方企业或大型咨询机构继续大型的数据仓库设计与架构贡献自己的专业能力，因此仍然活跃在市场上且能够把控一个企业级数据仓库架构设计的乙方专家也越来越少。
目前在项目上比较常见的 BI 开发形式就是来一张报表写一组 SQL 语句，再来一张报表再写一组 SQL 语句。由于项目进度和工期，或者经验水平的缺乏，底层的数据仓库架构设计基本上是缺乏统一规划和深度考虑的。
所以企业级的 BI 项目离不开数据仓库的规划与设计，而这种规划与设计对人的依赖相对较高，当市场上这类人越来越稀缺的时候，企业想要构建一个稳定可扩展的数据仓库难度就更大。
要解决的问题是什么？ 就是如何让数据仓库的构建可以不依赖于某一个人，而是在某一个平台上直接赋予企业一个完整的企业级数据仓库开发能力，并且让所有的 BI 开发人员都自动的遵守同一种开发准则，这个问题就迎刃而解了。
基于多年的 BI 实施交付经验沉淀，派可数据将数据仓库已经完全产品化了，通过产品化的方式动态配置维度和分析指标，将整个数据仓库的开发过程标准化和规范化，极大的减少了对个人开发者的依赖。并且针对部分 ERP 业务系统，例如用友的 U8\NC 等，我们已经内置了核心的分析维度和指标，以及相关的取数计算逻辑。
派可数据仓库平台的维度和指标配置
派可数据仓库平台的ETL模板配置
查看各个分析指标的血缘关系
通过数据仓库的平台能力，企业可以极大的提高数据仓库的开发效率，并且统一标准和规范，避免因人员流动而造成的项目卡壳等问题。各类维度和指标关联清晰可见，所有分析指标可追踪可查看，给项目的长期升级和维护带来了很大的帮助。
BI 行业的两个观点
1. 三分工具，七分实施 —— 对于一个稳定的商业智能 BI 项目来说，三分靠工具，七分靠实施，真正决定项目成功与否的是如何落地实施。而落地实施的关键在于需求把控，第二在于数据仓库核心的设计。
2. 20% 的时间做报表，80% 的时间处理数据 —— 在一个完整的商业智能 BI 项目中，只有 20% 的时间是在处理开发各种可视化报表，80% 的时间基本上都花在需求梳理、数据清洗治理、ETL 过程、数据仓库的搭建上。
当然，影响一个 BI 项目成败的因素也有很多，只是业务需求分析和数据仓库这两个环节的重要性更高一些，值得我们花时间和精力投入。
