给我一个理由，让BI生存下去

Happy 20060916

爱因斯坦说：给我一个杠杆，我可以撬动地球。BI人说：给我一个理由，我要让BI生存下去。

接触BI越久，对BI越了解，越来越需要这么一个理由。曾经被无数次问到，曾经在心中感叹，为什么项目失败的多，成功的少？为什么自己经历的项目最后没有客户在使用？每当遇到一个新朋友，谈起他所经历的数据仓库项目时，我总是习惯的问：项目客户在用吗？

为什么会发出这样的感叹？看问题的角度不同，导致完全不同的结果。

我们习惯用IT的观点看问题，集成了多少数据源，用了哪些规则做数据清洗，采用哪些步骤和措施来保证数据的质量，分了多少个维度，用了哪些建模方法。这些都是从数据角度来看数据仓库，就像数据挖掘一样，从数据本身的特性出发，从中找到特定的规律。

还有一种角度，是从业务的角度出发。

现在看来，应该是这么一种思路或者路径：业务部门头脑风暴推出一种设想，然后选择用什么方式来实现？靠人，靠经验，还是靠现有的信息系统，或者靠数据仓库？选择是多种的，客户肯定会选最有效的，最实际的，最方便的。不管选择哪种，包括数据仓库系统在内的所有被选项对于客户来说，都只是信息的来源，是信息的提供者，而人是信息的消费者。消费应该占主导地方，是推动事物发展的源动力。那么从这点来看就可以看出人（业务）和数据仓库系统的关系，业务主导数据仓库（数据分析）。

数据和业务这两种角度的关系，可以用树木和森林的关系来比喻。

我们可以把关于数据仓库的问题用5W2H的方法来归纳，然后可以从数据和业务这两种不同的角度来回答，看看有什么不同。

?       Why：我为什么要上数据仓库？我可以不上吗？
?       What：数据仓库提供哪些内容？它最终可以为业务部门能带来什么？实施数据仓库对于日常业务有哪些改变？
?       Who：谁最关心数据仓库？谁来使用数据仓库？由谁来参与实施实施？对谁最有价值？
?       When：什么时候（环境）应该实施数据仓库？
?       Where：数据仓库应用在哪？
?       How：怎么做？怎么用？
?       How much：数据仓库项目投资多少？实施要多长时间？

其实道理很明白，从业务入手，从需求开始这个观点大家一直都在照着做，那么为什么现在在BI实施的过程中还有那么多困惑，那么多需要解决的问题呢？我觉得根源在于要改变BI的应用模式，变主动为被动，变前台为后台。也许我们下次再向客户推数据仓库概念的时候，就应该以员工考核、绩效管理、CRM、BPM等形式为突破口，强调的是基于数据仓库的应用而非数据仓库本身。Hyperion现在推行的理念是绩效管理，BO强调的是企业流程管理，这些都是从应用入手的很好的实例。

再次感谢网界和TTNN带给我们大家的一次交流的聚会，希望不久的将来聚会可以发展成BI届的盛会！

li-zhenguo 20060918

作为一个银行IT人员，我只能说你们和业务靠得还不够近。我们分行开发了自己的数据仓库，个人和对公CRM，收到的业务人员好评如潮，包括总行和很多其他分行都来参观。但细究我们用到的技术，都是简单的存储过程+JSP，在开发方法上也没有上升到方法论的层面，数据仓库也是名不符实，在很多方面只起了一个中间件的作用，更多的历史数据在各应用内部保存。

究其原因，还是我们和业务人员靠得足够近，业务人员在科技部里蹲点，一有什么新想法和新问题，双方可以及时交流。没有太多的业务知识障碍和技术知识障碍妨碍业务和科技进行交流。

Liu Yonghua 20060918

０１年，数据仓库项目是这样开发的。现在，如果还是用ｅｔｌ＋ｊｓｐ，再过两年，你就知道这种方式够用不够用了。

个人觉得，你们银行的数据仓库最多叫个小集市，只是应用处在勃发期而已。一旦业务人员有什么报表、分析的需要，你们帮着实现就是了，大家都觉得好用而已。靠科技人员和业务靠得足够近，是不够的。对银行业务以及业务系统足够了解，又懂得分析应用的需求分析人员，基本上来自于科技部，多少需要一定的积累，也只有这样，才能对业务人员的需求准确理解，并能良好引导而非误导。

hawk 20060918

在一本管理类的杂志看到，说国外现在大多数做的好的CIO，都是来自于公司所在的行业领域的专业人员，而非学计算机或者信息管理出身的。由此可以看到，并不是BI存在这样的问题，任何一个软件领域都存在着这样的问题。所以国外的许多成功的软件，都由产品经理来负责。产品经理可能并不懂技术，但他清楚的知道市场需要什么，未来的需求点在什么地方。他能够找到技术和需求之间的一个平衡点，然后实时的推出一个产品，也许这个产品技术并不是最先进的，功能并不是最强大的。但要想取得市场的成功，那么这个产品一定是别人最需要的。只要清楚的知道了市场需要什么，并理顺了实现这些需求的所有环节，然后才需要我们这些所谓的"技术"人员。不然的话，再好的技术，再高的水平，又有什么用呢？所以，我们做IT的人，的确该反思。假如客户换成我们自己，换成是我们自己的开的公司，我们会花这么多钱，开发或者投资我们现在做的东西吗？如果有一天，我们自己的公司，也愿意花这么多钱，用我们自己开发的东西，我想信，那我们离成功也就不远了。

Qing 20060918

西宁说的这个问题，关于应用模式的问题，在这次北京聚会上已经有所探及。在和朋友们的交流中，我也有所感触，虽然还是没整太明白。
 
但也许正是li-zhenguo所言的，技术和业务脱离，所以才让我们去谈论这个问题。记得这次聚会上，艳山兄弟就我对这个问题的疑问不是给出一些建议吗，他强调了一点——组织结构。确实有道理啊。在li-zhenguo的例子当中，他们的做法，技术、业务部分的人能够在一起工作，看上去亲密无间。上头不让这两种人员这么干，他们也难呆到一块去阿。
 
和朋友聊到一个问题，他们也是作电信的，也在作专题分析，作数据挖掘，团队的能力我想也是差不多的，但他们的做法和我们这边的做法不一样。他们作出来的挖掘模型，比如说一个预测模型，打完分，也就是放到olap里面作为维度去展现而已，这都是技术方面在动作，至于业务方面，并没有规定该如何用这个结果。
 
在我们这边，不同地市的分析应用也是不同的部分负责。有的是市场部负责，从设计应用流程到执行，市场部门能够说了算。但有的地市，是IT部门来跟我们对应，然后他们再去推动自己的市场部去应用。一般来说，后者的效果显然要差点。但暂时我们还没有要求对方必定是市场部门来牵头，可能是还不够底气吧，总觉得有人来牵头就已经不错。究竟谁来牵头，就看客户对这种分析应用模式的理解了。
 
我想这恐怕是比较根本的，显然不是技术能解决的。以前集成商大多是在技术层面给出解决方案，很少强调应该有怎样的组织结构来支撑这个解决方案。一方面是因为集成商的力量往往不够强势，另一方面可能这个问题似乎是隐藏起来不太明显的。
 
li-zhenguo 20060919

Qing说的是“技术实现--》业务反馈--》技术修改”这个环出了问题。

问题有三：

1，业务和技术两方，任何一方没有达到足够强势，不能推动整个环节，只能管好自己的事。

2，业务方不重视技术方提出的要求，没有充分的反馈。

3，技术方无法忍受业务方提出的无休止的业务反馈导致的技术修改，以至成本超标但在银行内部不存在这3个问题。很多业务人员是技术出身，在反馈和成本控制上，有行长室监督，不会出现相互扯皮的情况。集成商要解决这3个问题，只能是本着长期合作的精神，深入了解业务人员需求，与基层业务人员建立起密切联系，并一点一滴解决系统投产后的问题。

to:Liu Yonghua

你说的没错，以我们目前的架构，根本不能做到高度的敏捷开发。可是忽略了一个问题，就是市场。对于我们来说，分行的需求就是我们的市场，市场有多大，决定了我们需要什么样的技术，没有必要攀高。

to:hawk

我们开发部门一个副总调到了业务部门，现在她成为了技术和业务两条线的专家，如果银行也搞什么o的话，那她肯定胜任cio了。

BI4Fun 20060919

"我只能说你们和业务靠得还不够近"

我个人认为:这个话是做数据仓库或者其他什么系统主要存在的问题,报表也好,挖掘也好,OLAP也好,什么需求,什么技术,最好不要就技术本身谈技术的应用,应该结合实际的情况,将适合的技术应用到具体的要求上。

做银行的客户分析，建议多跟那些经常跟客户打交道的业务人员交流，或者直接跟他们去面对解客户的，这样你完成的系统或者应用才能比较实用，也比较受他们的欢迎，因为你有这样的经历。

分析应用不是单纯从技术上就可以解决的难题，也不是单纯从业务上可以解决的难题，一个分析开发人员应该具体多种知识，而不仅仅是DW,JSP,DB。还应该去学习行业知识，社会知识或者其他分析牵涉到的知识。包括Qing所说的“以前集成商大多是在技术层面给出解决方案，很少强调应该有怎样的组织结构来支撑这个解决方案。”这些不是一个简单的技术或者应用的问题。

Liu Annie 20060919

想必你是某家银行的分行的科技部门人员吧，你说得没错，只要满足全分行需求就可以乐。你现在的状态，我说了，跟我01年在某家还算大的银行的最大的分行，开始做数据仓库项目的状况非常相似，单从你们分行业务部门的需求角度来看，目前的技术和你们技术人员对业务的了解，够用了，请注意“够用而已”。我也说了，你们的系统数据仓库都称不上，更不要说BI了，规模不大的分析系统而已。

数据仓库系统的构建，乃至商务职能BI的运用，在银行来看，不管是对于科技部来说，还是业务部门来讲，都是发展趋势之一。当然，数据仓库的应用，更不是简单是业务部门需要一张什么样子的数据报表，或者他们想看到什么历史数据就够了的。如果行长也这样子理解数据仓库，那我们的系统都不要建了，毫无意义。

在银行业务系统大集中之后，发展地日趋完善地状况下，管理信息系统地发展，势必是未来的重中之重，同作为银行科技部门人员，我的这种说法没有错吧？尽管目前状况下，各类管理信息系统面向的业务部门，采用的技术不尽相同，长远来看，为了保证数据的一致性，应用的单一性，在同一个信息平台上进行构建也一样是大势所趋。

今天够用的系统，未来会怎么样，谁都不知道？业务部门的需求得到初步满足后，
接下来的需求，会越来越难以得到满足。给两个建议吧：

一、为了保持系统能够持续满足业务部门的需求，请在构建系统的初级阶段，稍微具有点前瞻性，不管从业务角度还是技术角度。

二、了解业务，不单知道业务部门要怎么做，还要知道为什么这么做，了解业务才能给出更好的解决方案。

wangyong 20060919

前瞻性可能就意味是十倍或者百倍的投入,并且对业务人员的水平要求上一个台阶.如果业务人员的水平上不去,那前瞻性的数据仓库也只是技术上的前瞻性,而不是整个的.就投资回报率来说,甲方也会考虑,到底值不值得去投入大量资源到这样一个系统?还是就用简单技术来满足现在需求?我偏向于后者,然后在这个基础上一步一步把其他的东西(数据挖掘,智能分析)引进来指导企业的决策.如果大家的基础都不扎实,再前瞻性的东西,可能客户也不会用.

li-zhenguo 20060920

to Liu Annie :

我所在单位是中国最大的商业银行里管理信息方向排名前三的分行。在我们的科技部，开发过号称创造了50亿美圆价值的业绩管理系统，目前的个人和对公CRM，我相信也是国内同业中利用率最高的CRM系统。我们的目标是使我们的管理信息方向成为国内同业中最强的。你说的其实大致和我们想的以及正在做的差不多，我们是应该对未来进行前瞻性的规划，但是相关的问题有：

1，目前各种技术如雨后春笋，各家也提出各自的解决方案。但是，没有任何一家的解决方案是没有漏洞的，包括IBM和Terrdata，很多的所谓产品解决方案，都是在收购了n家公司以后才实现的。即使我们有钱，也不会把钱交给他们。

2，作为一个银行的科技部门，开发人员的技术水平要比专业的IT公司差不少，要引进一个新技术，需要评判开发人员的接受能力。

3，bi4fun说得没错，业务这个最关键的因素经常被忽略。我们的个人和对公CRM在技术上毫无特色，即使总行评奖我也不知道能写些什么，它们的成功点在于业务与技术的完美结合。银行的组织结构在不断变化，各部门的实力在不断调整，在人力有限的情况下，先做什么，再做什么是关键。不能采取休克疗法，完全不考虑业务需求，先把技术实力提高了再说。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友