最近有机会整理了一下过往的BI项目和它们的实施过程，并做了简单的总结。对于从事BI的老司机们就见笑了。对于刚入BI的新手们或许会有点帮助，因此决定在此和大家分享一下。如果有不对或者不明确的地方还请指正。
商业智能（BI）大家可能早已耳熟能详。从早期的报表自动化，到现在的复杂灵活分析，多平台支持，优秀的人机互动，多数据抽取，大数据整合，甚至和当下最火的人工智能都有结合点。可能一提到BI，大家都会自然而然地把这个话题丢给IT。但是由IT主导的BI项目最终是否能够落地那？
为什么以技术为主导的IT部门做不好BI项目？
首先我认为BI是最直接，最重要地服务于商业决策者的，尤其是管理层。BI应用是否符合用户习惯，数据是否准确及时，是BI能否活下来的关键之关键。试想一个难以操作，挤满了图表，而且错误百出的BI应用，哪个经理会有兴趣去使用它？一旦失去存在的价值（credibility），被抛弃就成了自然而然的事情。
其次国内的IT人员普遍热衷于技术而忽略业务。牛牛爸也是技术出身的，深知对于很多开发人员来说，看InfoQ的兴趣要远大于CEO年终总结里的数字。由于业务知识和经验的缺失，很多时候IT闭门造车搞出来的BI应用根本不是业务人员需要的。慢慢地双方的激情消退，抵触情绪滋长，失败是早晚的事。
另外很多IT部门现在还停留在维护传统大型项目的框架里。当今的商业瞬息万变，与之配对的决策系统也应该具备灵活变化的能力。我相信很多商业决策者经历过类似的痛苦，例如从提出某个报表的修改意见到正式上线往往要等很长时间。但这不能完全怪IT，因为他们需要审批，获取权限，收集数据，测试，写文档 ... 。 所以一个小的修改可能要在6个月后release里才能实现。转型需要时间，但作为重要的决策者，您会等吗？
站在商业和IT之间，BI主要包含了什么？
国外很多大牛都定义过BI的框架。在此，我只是根据前人的经验和一些国内项目的经历总结出自己的内容。从下往上，我的BI各元素框架（BI Component Framework)主要分为3个部分：基础部分（Foundation），实现部分（Enablement），和辅助部分：
BI框架之基础部分（Foundation）
从业务层面来讲整个框架的根基应该是商业或者管理层的“觉醒”和授权。很多公司现在还依赖于excel报表。业务部门习惯于从excel中生成图表，粘贴到PPT里，然后把周报，月报，或者年报呈现给管理层。这样做会面临几个主要的问题：首先是数据的准确性。Excel报表肯定难以避免手工错误，而且在充满大量的 vLookup 或者公式的excel里找出错误是十分痛苦和低效的。其次是资源压力。越复杂的报告所需要的数据和人力越多。期限前集体赶报告的经历很多人应该都有吧。再次是时效性。商业决策讲究的是快速灵活。有些报告，例如公司年报确实不要求实时，但是很多底层的业务决策是不能等到周末或者月末才能开始制定的。最后是安全性。数据和分析结果全都在excel或PPT里。IT部门可以限制email，封锁网盘，但是直接考取那？面对这些问题，管理层必须思考是否需要一个完备的BI系统。
BI应用的灵魂来自于数据。数据就好似血液一样支撑着整个BI系统。但很多时候公司的数据是最为敏感的，例如供应商数据或财务数据。此外一些部门会把数据当成“私有财产”而拒绝或者有限度地与其他部门分享。单纯的BI实施团队（不管是IT主导还是业务主导），在没有高层甚至顶层授权的情况下很难持续地推动BI项目。因此管理层的“觉醒”和授权是我认为完成一个BI项目最优先，最重要的基础。
接下来是了解公司业务。前面已经说过了，IT部门通常精于前沿的技术而忽略业务，但是BI作为业务部门最直接的决策工具，失去了业务的支撑就好比给一个厌食症患者做了一桌子满汉全席。业务的构成有很多，例如公司有哪些KPI，各个部门的核心业务是什么，报告流程是什么，瓶颈在哪里，业务流程都需要哪些职能，是否需要内外合作等等。对于业务的理解，IT技术人员容易习惯性地用用例图（use case）或者系统架构图（system architecture）来表达。但是问一下哪一个经理或者业务员能一下子看懂那些圆圆圈圈代表的意思？在这里我的经验是用最传统的流程图和excel列表，因为大部分非IT人员基本不需要工程培训就可以轻松的理解你要表达的意思。
了解公司的系统和数据是重点。现在只有极罕见的公司还仅使用office或者手工作业，基本上大家都多多少少有些系统，一些大的公司甚至会上马全套的ERP，sales force，CRM等。对BI团队来说，系统本身的迭代，之间的接口，承载能力，权限设置，技术特点等都是需要了解的。数据分析则需要更多的精力。从范围来说除了分析系统内已有的数据，BI团队还要了解手工生成的数据，例如excel报表。从属性来说要分析数据的历史情况，数据的完整性，数据质量，数据层级（hierarchy），数据从属，维度变化（包含缓慢变化维的情况）等等。根据目前的经验，我遇到的数据分析最大的痛点：一是数据质量，尤其是历史数据。很多业务部门，尤其是缺乏控制的部门，其数据都是五花八门的。在清洗的时候会遇到各种问题。二是数据定义。很多公司没有主数据系统，或者根本不遵循主数据。同样一个主体，这个部门或系统定义这个code，另一个部门或系统使用别的code。在数据需要联通的时候我们需要耗费大量的时间去协调和校对。
分析完公司的业务，系统和数据之后真正的难点来了：整合。之前的分析都可以是独立的，但是在这里我们必须在熟知公司业务和数据的情况下把所有信息整合在一起。例如我们要知道在每一个流程里数据进口在哪里，出口在哪里，谁生成数据，谁更新数据，谁使用数据，怎么使用的，同样的数据是否被重复定义或多次使用，主数据是什么，数据属性又是什么等。我认为这个时候BI团队还是要更多的和业务部门坐在一起，交流的方式还是以流程图为主，只不过更加复杂，例如加入数据流和不同的人物信息。描述数据情况的时候则不拘于形式，但要把现状和问题说明白，千万不可以隐藏，否则将来的BI系统一定是垃圾进，垃圾出（rubbish in，rubbish out）。
在以上元素都介绍完之后，我们终于可以和IT坐下来谈谈感情，顺便聊一下数据存储，建模以及BI工具的实施了。
数据不会像水一样从源头直接流进BI系统。通常我们需要通过一个叫做ETL（技术术语，全拼是Extraction，Transformation，Loading）的流程来把数据从源头抓取到BI的数据仓库（data warehouse）。除了业务部门的终端系统和数据之外还有各种介于“中间层”的辅助数据，例如主数据，也要通过ETL流程把它们保存到BI仓库里。不同的IT部门会使用不同的技术来实现数据仓库，例如MySQL，微软的SQL，或者云端的数据库技术等等。
BI建模和普通的数据库建模有很大区别。一般系统数据库建模更多的是考虑数据存储，而BI本身只消费数据，其模型主要是为了服务将来的报表和分析。因此负责BI建模的架构师除了能够驾驭两种数据库的思维之外，还要有很强的技术能力和业务理解力。好的模型除了能针对不同的业务需求做出快速反应之外，还要有足够的拓展性以防备未来的业务变更或者新需求。因此好的数据建模师特别值钱。
有了BI所依赖的数据仓库和模型之后，我们可以开始用BI工具来开发对业务用户有意义的信息和应用。别忘了到目前为止大多数业务部门和管理层是不知道或者看不懂BI团队在干什么的，直到我们在屏幕上把表格或者图形做出来。BI工具有很多种，例如传统的SAP，IBM，Oracle等提供的重型BI工具，也包括时下流行的新型工具，例如QlikView，Tableau，和PowerBI。当然一些大公司也可以使用自己开发的BI工具。
当数据，模型，和工具都敲定之后，我们就可以开始真正的BI实施了。Part 2会介绍模型余下的部分和两种实施策略！
