高级分析（BI）本质的思考

innovate511

现在有种说法将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强现在的信息范围仍然在增长，数据工厂任重道远。

_OldGun

非常好的文章

crazypeter2005

支持楼主。