以下内容是转载：作者分析透彻，理解深刻。受益匪浅
点击打开链接
新的一年,回顾一下近10年的BI生活，觉得可以思考一下本质的东西,在这里进行抛砖引玉(现在又叫高级分析了)。
从BI开发实施流程的角度看，是先了解需求，然后设计框架，设计模型，再是开发、上线，用户使用、反馈-》循环下一期项目。我们每个人身处一个角度、一个角色时可能只管好自己那部分，而忽略整体的价值。那么跳出这个圈往下看，我们不难看出，BI的目的是帮助用户分析出宏观的事件、出现的问题、问题的关键、去找解决问题的办法、如何避免问题、发现潜在问题、揭示潜在商机等等。那么手段呢?为啥要这样做,要做这些呢?
打个比方，传统OLTP系统就是将商业和其他社会行为用数据记录下来，而高级分析要做的就是将数据再重组，还原业务本身的场景,分析这些行为的规律、趋势、行为的错误、行为的优势，然后去解决问题、发扬优势。于是就会出现两个瓶颈，一是分析技术手段瓶颈，我们是否能用合适的手段把问题和优势找得更准、更好地为用户所用？二是管理问题，包括找到问题，用户是否去改善、促进，也包括我们用户的数据，是否包含更丰富的数据，所谓巧妇难为无米之炊。
在技术方面，现在所用方法很多，但要让用户全部接受去用，要让所用的方[已经隐藏]是用户当前需要的又推到管理问题上去了。那就说说将如何用技术将数据再度还原成业务。首先大家都知道BI的重要环节就是建模，有一点很重要，就是你理解OLTP的业务模式和基本流程不？如果不理解，可能出现如下状况：1. 直接讨论业界通用模型的时候，结果发现用户的业务数据不支持整个关联关系，要么不了了之，要么会出现经常修改模型而被动的状况。2. 跟着用户的需求一点一点地走，那是危险的烟囱型模型，危险性就不说了。3. 数据质量把握不了，OLTP业务模式和功能使用，可能直接导致某些潜在分析BUG。? ? 有了适当的数据建模型，才能更好地将业务再现，业务再现后才能说到后面的各种分析目的。
现在回想起来，Inmon与Kimball之争，无非一位注重如何打好数据基础，他希望类似化学里将一个物质如何分解到分子、原子以便有更好的应用，一位注重如何还原业务，由数据直接支撑想要的业务分析模式。
从技术上来讲，既然要将业务先通过OLTP系统和其他途径如手工数据分解成数据，然后再在BI自有的数据仓库里重构数据、再进行业务再现，那么任何再现工作都会意味着缺失、误差和过程跟踪问题，包括我们传统行业的某些产品的深加工，那人家也是丢了很多原材料的东西，然后进行质量检验、跟踪全过程保证质量嘛。所以我们不难理解我们会有数据质量技术手段、元数据管理技术手段，术语统一管理，道理和传统行业一样的。只是传统行业人家是熟练技术工人去做，而我们的高级分析BI，这些活很多时候还是在资深设计、管理人员在兼做，成本很高额（毕竟不成熟）。
在管理方面，这个方面比较难克服，但一旦克服困难，效益不是一般的大。比如你发现业务系统不支持某种分析，如果用户帮你解决这个问题，就可能会做出不一样的成果，如果你发现问题，经过用户认可，用户去更正了问题，效益就是明显提高，BI不再是面子工程。
那如果说需要数据就去搞数据呗。事情没这么简单，搞任何数据都需要成本的，比如竞争对手数据，这需要从咨询公司手里买或者自己手搜索的，要看你是否觉得投资回报合理了。再有，某些已有业务系统在设计时未考虑保留足够多信息方便分析，你如果要业务系统修改，代价是需要计算的，同样要换业务系统，代价是否值得，是否是基础信息化本身该升级了？
再说,只要把很多社会行为能部分数据化，我们就可以开始“BI”了，意味着我们平时还可以在更多地方用BI。比如项目管理，如果我们做BI项目就有一个管理模型，做一个界面或者EXCEL模板能让PL/TM轻松填写工作进度、成绩等回报，那么我们的管理人员可以很轻松跟踪大型团队、多团队的项目进度、状况、困难，也能即使解决问题。既然管理都可以将业务转换为数据，然后再为更好的管理服务.??那么未来BI深入分析的趋势之一，就是不断加深数据、数据更新、关联更多，当然数据庞大的背后是统一管理。所以深入考虑BI后感觉，底层数据会越来越多、越来越细、流程越来越自动化（手写脚本正全面退出主流ETL就是证明）、质量监控越来越严密、过程跟踪越来越细、关联性越来越多、由于业务分析的上层应用数据重构将成常态，而整个过程由“工业化流程”跟踪，根据用户不同时代的需求而定。
所以我想有牛人提出的数据工厂的概念，最多在底层数据上发展，上层分析数据不可能工厂化，否则跟不上应用（可以考虑类似“车间化”，一个车间定制一类产品的意思）。而且底层数据会越来越庞大，参考世界500强现在的信息范围仍然在增长，数据工厂任重道远。
其实有一点IT的普遍思想有偏差，那就是想用自己的那套去解决用户所有的事情，而用户仍然按照自己的方法在做。问题出在哪里？问题其实出在用户的思想没有和IT碰在一起，要么用户对BI使用太不熟悉，要么IT的人对业务太外行。
要想用户使用得好，让用户在BI的框架下自己开发报表是必要的！也就是说高级用户必须培养成为报表开发高手，我们公司有1个部门已有多名高手，开发深度自然不一样，应用价值是我们IT部门单独推广不能比的，其他部门的高级用户也在培养之中，逐步形成成果。
其次IT人必须熟悉到精通业务，否则和用户谈需求时，人家会觉得对牛弹琴，你只能成为“技术工人”，达不到1+1>=2的效果。所以目前BI的一大趋势是甲方公司普遍开始加强IT自己的力量，而非大部分依靠厂商实施，那样的甲方IT部门只是监工就毫无意义了。
有鉴于此，我昨天突发奇想写了关于BI本质的想法，从以前做了多年的乙方实施、开发到现在在甲方做。
现在很多公司使用BI有问题不完全是BI本身有问题，包括数据的准备、BI实施的整套应用管理和工作分配。 数据本身就是业务拆分成的“原子”，如果原子不全，怎么组成完好的物质呢？你想重组成为想要的分析结果，那自然是失败的。所以很多时候BI是需要推动数据源本身的不断完善。 而BI的实施管理，那是另外一个关键，看了太多花了N多钱做的BI，结果用户偶尔用一下，用户也少时，那简直是杯具，人家能不说你BI失败么？ 关键是1没了解清楚用户想什么而是硬推，硬推能解决用户的问题么？ 2是用户习惯并没改变，BI的重要作用是BI的思想，而不是用工具做报表，如果只看厂商吹的报表而不注重思想，那再漂亮的报表都是shit，所以一定要逐步改变用户的习惯和思维方法，这点必须甲方的人拼命需要完成的任务。 3是使用情况没跟踪，我们公司使用BI的效果向上面汇报时，完全用数字说话，常用的用户数、使用次数、使用时间都是关键指标。 4IT人是否了解用户的业务，要知道用户不知道你BI能做成什么，IT人刚开始也不知道用户业务怎么运行的，必须找到中间的人---通业务熟悉BI的人，要么用户中培养，要么IT人自己去努力。 其他数据仓库的支撑，是良好的BI应用下才说的，有了BI的应用，数据仓库的技术价值才能更好体现出来，也不能说数据仓库设计不重要，那是要有使用基础的。 BI要产生价值，BI不要在中国企业成为滑铁卢，需要科学的方法实施、开发和推广。在甲方公司为啥BI被人看为只看投入没看产出的东西？最重要的原因就是BI没成为大批量用户日常使用的一部分，没有深入人心，没给用户带来太多价制，自然会大失所望。
