转自:http://www.cognoschina.net/club/viewthread.php?tid=7697&extra=page%3D1%26amp%3Bfilter%3Ddigest
现在有种说法将BI归为“高级分析”,那我也跟着时髦说“高级分析”吧。整整做了近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强现在的信息范围仍然在增长,数据工厂任重道远。 |