OLAP工具毁了商业智能

happysboy

最初由 interstage 发布
[B]

我们看看BI的应用对企业的实际用途,
企业对BI的期望:决策分析支持系统,分析是关键.

1,REPORT: 日常统计报表,是企业以前的分析思维在里面,但没有太多的创造性分析在里面
2,DW(ETL): IT部门数据规范了,应用没看到效果
3,EIS+仪表盘:老大们看到业务的汇总变化了,但不知道细节是如何产生的.
4,目前OLAP:固定纬度的分析模式,一旦分析角度变化,要靠IT部门来变化,分析的思维被IT部门禁锢了,不如用EXCEL自己搞.
5,数据挖掘:靠复杂算法,以课题制的方式,出来的结果要么地球人都知道 ,要么都不知道,分析的价值没体现.

看到了吗,这就是目前实施后的BI,离用户期望的提供决策分析BI有这么大的差别.

问题在哪里,就是BI项目没互动起来,没有让业务部门参与进来,没有作出操作性BI.只是分析性BI,现在的BI工具就是这个现状.

人民,只有人民的力量是无穷的.BI,发挥他们能动性吧. [/B]

我对操作型BI和分析型BI的理解跟你的理解不同，操作型BI不是指业务人员可以直接操作BI吧，那反倒是分析型BI的功能。

我理解的操作型BI是指隐藏在后台的BI，却融入日常业务操作中。比如客服人员，在一个客户打入电话时候，立马在客服界面弹出一个可以向该客户推荐什么业务的信息。客服人员只需要照着作就行了，不需要他们去分析。

原来所谓的分析型BI，本身就是面向于具备分析能力的业务人员的。但因为很多企业缺乏这样的人，所以才由IT人充当，却也不能说这些BI就是面向IT人的。

不知这个理解能否达成共识？

interstage

最初由 happysboy 发布
[B]

我对操作型BI和分析型BI的理解跟你的理解不同，操作型BI不是指业务人员可以直接操作BI吧，那反倒是分析型BI的功能。

我理解的操作型BI是指隐藏在后台的BI，却融入日常业务操作中。比如客服人员，在一个客户打入电话时候，立马在客服界面弹出一个可以向该客户推荐什么业务的信息。客服人员只需要照着作就行了，不需要他们去分析。

原来所谓的分析型BI，本身就是面向于具备分析能力的业务人员的。但因为很多企业缺乏这样的人，所以才由IT人充当，却也不能说这些BI就是面向IT人的。

不知这个理解能否达成共识？ [/B]

OK,同意你这个观点.
操作型BI原义就是希望隐藏在业务系统中,可提高报表、分析、与信息发布的速度，从而做出更快的操作型决策并采取行动。对操作型事务或需求做出业务响应的时间通常被称为“行动期”。行动期可以是几秒钟，几分钟或者几个小时，这依赖于业务需求。

这种操作型BI其实是闭环的BI,去协同ERP系统, 快速反应的一种方式.

但现在就是操作性BI入口点找不出来,如何形成闭环,需要先做分析性BI,而分析性BI目前最大的问题是业务人员不介入分析,这样就无法实现操作型决策并采取行动(你想想,业务人员都被目前的分析性BI思维禁锢着,只会操作不会思考),所以要找到这个操作性BI入口点需要先让业务人员学会分析.

你可以把我这里所说业务人员可以直接操作BI定义为操作性BI前期,分析性BI后期.

在ITPUB很多技术人员把操作性BI定义为ERP的一个功能,而且说到已经实现了,这是误解,其实他们看到的只是ERP的统计报表功能.

kinghq

最初由 happysboy 发布
[B]

我理解的操作型BI是指隐藏在后台的BI，却融入日常业务操作中。比如客服人员，在一个客户打入电话时候，立马在客服界面弹出一个可以向该客户推荐什么业务的信息。客服人员只需要照着作就行了，不需要他们去分析。

原来所谓的分析型BI，本身就是面向于具备分析能力的业务人员的。但因为很多企业缺乏这样的人，所以才由IT人充当，却也不能说这些BI就是面向IT人的。
B]

您所说的操作型BI还是做到应用系统里去比较好，尤其是靠流程等管理上的东西先行规范。其实在制造行业，早就有了产品配置这么一说。您举的那个例子，我更愿意理解成为服务配置。

至于让IT人来做，其实有个问题需要解决：业务人员怎么就相信IT人员做出来的是完全按照自己的想法去实现的呢？毕竟这不是某一个逻辑功能，可以“一次验证，到处使用”；而涉及到的数据情况不一定就一成不变。

interstage

最初由 kinghq 发布
[B]

您所说的操作型BI还是做到应用系统里去比较好，尤其是靠流程等管理上的东西先行规范。其实在制造行业，早就有了产品配置这么一说。您举的那个例子，我更愿意理解成为服务配置。

至于让IT人来做，其实有个问题需要解决：业务人员怎么就相信IT人员做出来的是完全按照自己的想法去实现的呢？毕竟这不是某一个逻辑功能，可以“一次验证，到处使用”；而涉及到的数据情况不一定就一成不变。 [/B]

今天下午去了一个客户现场交流,我先讲思路的时候,IT技术人员个个觉得不可能或者其他工具也有.

于是,我演示做一个场景,一个BI项目完成,有一个标准商品类别的CUBE运算(纬度有:商品大类,商品中类,商品小类,若干时间角度,度量值有:销售额,毛利等等), IT部门+咨询专家做了更多公司分析层面的报表.(从商品类别角度)
但现在业务部门有20个人,他们不关心这些报表,因为和他们的实际工作有差别,他们只关心他们管理的商品,这些商品在任何的商品类别中都有. 如果传统BI系统中,需要再求助IT部门,让IT部门把业务人员1管理的这些商品定义成1维,把业务人员2管理的这些商品定义成2维,以此类推. 几天后IT部门把这些纬度建完了,可以出每个业务人员自己关注的报表.第2天业务人员2跳槽了,他管理的商品分散到另外19个业务人员了,OK,IT部门又要把20个维改成19个了,好辛苦.

然后,我直接演示了我的管理视点技术,业务人员这个自己关注的商品本来就应该自己做,马上出来了.

这个模拟场景是否让大家满意,至少我在那个公司交流的现场,他们技术人员满意了.

happysboy

最初由 interstage 发布
[B]

。。
你可以把我这里所说业务人员可以直接操作BI定义为操作性BI前期,分析性BI后期.
。。[/B]

你说的让业务人员介入到BI里面我非常赞同，但不认为用工具解决这个问题。

你是站在工具销售的角度来说这件事情，我理解，我想你肯定也知道真正的症结并非在工具，而是在缺乏一种固定的分析流程，或者说分析方法论。

业务人员在大脑中不明白该如何分析一件事情，如何决策一件事情。首先要做到就是就是将自己目标表达清楚，这点都是太难做到。有时候他自己以为要分析的是收入变化，却分析到业务量的变化上去了。用任何牛逼工具都是一样结果。

interstage也许不应该在这里宣传产品，因为这一套对这里的人来说是吃不开的，大家都是圈子里面的人，知根知底。跟客户说，这就非常高明。

有时候看看自己给客户写的材料，虚伪得都想吐，但还得那么写。那些文字要是拿到论坛上跟大家讨论，不给大家骂死才怪。

interstage

最初由 kinghq 发布
[B]

您所说的操作型BI还是做到应用系统里去比较好，尤其是靠流程等管理上的东西先行规范。其实在制造行业，早就有了产品配置这么一说。您举的那个例子，我更愿意理解成为服务配置。

至于让IT人来做，其实有个问题需要解决：业务人员怎么就相信IT人员做出来的是完全按照自己的想法去实现的呢？毕竟这不是某一个逻辑功能，可以“一次验证，到处使用”；而涉及到的数据情况不一定就一成不变。 [/B]

你讲到点子上了,IT部门和业务部门在交流"分析角度"的时候存在失真. 把分析角度定下来了,业务人员开始讲统计要求了,IT部门把这个统计方法变成算法,用复杂的SQL语句或者OLAP工具的计算函数,从数据从几亿上通过计算成一张只有不到1000条数据,IT部门这么辛苦出来报表了.居然业务人员对刚才的"分析角度"要求变化了,这IT部门不是要疯了.

但业务人员也奇怪,既然是分析,就应该让我变化着分析,怎么可能不变.或者在你固定纬度的范围内变化. 也太痛苦!!

久而久之,BI系统变成领导的把设和面子工程了.

这就是你的疑惑,

interstage

最初由 happysboy 发布
[B]

你说的让业务人员介入到BI里面我非常赞同，但不认为用工具解决这个问题。

你是站在工具销售的角度来说这件事情，我理解，我想你肯定也知道真正的症结并非在工具，而是在缺乏一种固定的分析流程，或者说分析方法论。

业务人员在大脑中不明白该如何分析一件事情，如何决策一件事情。首先要做到就是就是将自己目标表达清楚，这点都是太难做到。有时候他自己以为要分析的是收入变化，却分析到业务量的变化上去了。用任何牛逼工具都是一样结果。

interstage也许不应该在这里宣传产品，因为这一套对这里的人来说是吃不开的，大家都是圈子里面的人，知根知底。跟客户说，这就非常高明。

有时候看看自己给客户写的材料，虚伪得都想吐，但还得那么写。那些文字要是拿到论坛上跟大家讨论，不给大家骂死才怪。 [/B]

呵呵,为什么要和技术人员讨论BI,就是要告诉技术人员,当技术,工具,实施都解决不了目前的问题的时候,怎么办, 对,是方法. 但这些方法的实施可以被固化的时候,是什么,是工具. 这是工具发展和变化的动力,也是技术发展和变化的动力.

技术人员很聪明,很理性,但很顽固. 因为需要我们时刻去否定我们辛苦学到的技术,这就让我们非常痛苦.

kinghq

只要能帮我们突破症结，打开工作局面，找到一条大家认可的持续有效的路子，那么任何沟通都是欢迎的。至于商业机会，本来就是“供需匹配”的结果；离真正达成合作还有很多事情要做。因此，就我个人而言，商业沟通本来就是很正常的。

另外，通过这么长时间的讨论，有一个共识应该是有的：DWBI项目越来越不是纯技术项目了。正因为这样，更多的不是对事情本身的考虑，而是事情之外的考虑。而且，这种考虑也更容易跟客户进行沟通。

谈到这里，我觉得我们自己的项目思路其实是关键。毕竟合作伙伴也好、工具也好都是可以选择的；但唯独自己没法选择。所以，我们更看重的是这个。而为了得到这个东西，我们最需要的是跟不同的人沟通，慢慢就形成了既有合作伙伴支持，又能自己把握的项目思路了。大家都是身经百战的人，应该知道什么样的项目做起来最不爽。呵呵，我是希望合作起来是爽的感觉，尽管我也知道这样的合作可遇不可求。

interstage

最初由 kinghq 发布
[B]只要能帮我们突破症结，打开工作局面，找到一条大家认可的持续有效的路子，那么任何沟通都是欢迎的。至于商业机会，本来就是“供需匹配”的结果；离真正达成合作还有很多事情要做。因此，就我个人而言，商业沟通本来就是很正常的。

另外，通过这么长时间的讨论，有一个共识应该是有的：DWBI项目越来越不是纯技术项目了。正因为这样，更多的不是对事情本身的考虑，而是事情之外的考虑。而且，这种考虑也更容易跟客户进行沟通。

谈到这里，我觉得我们自己的项目思路其实是关键。毕竟合作伙伴也好、工具也好都是可以选择的；但唯独自己没法选择。所以，我们更看重的是这个。而为了得到这个东西，我们最需要的是跟不同的人沟通，慢慢就形成了既有合作伙伴支持，又能自己把握的项目思路了。大家都是身经百战的人，应该知道什么样的项目做起来最不爽。呵呵，我是希望合作起来是爽的感觉，尽管我也知道这样的合作可遇不可求。 [/B]

是的,你说:毕竟合作伙伴也好、工具也好都是可以选择的；但唯独自己没法选择.

所以,合作伙伴也好、工具也好给你的只是砖,只有你自己能产生玉,不是在合作伙伴,厂商,咨询顾问那里.
你自己包括你们的IT部门和业务部门.

这就是,我说的"抛砖引玉"的BI实施方式. 因为BI不再是技术能解决了,不再是几个聪明人在一起就能解决了.

interstage

innovate511总是一付DW高手的样子,动不动世界500强用EDW,中国移动经营EDW多么高深. 如何充分按照实践大师Kimball思路来做,以前还谈inmon,现在不谈了. 因为innovate511所说的DW一直是在讲CIF的DW,从来不讲MD的DW,甚至他不把MD的DW认为是DW.这在以前的交流中,他提到过.

OK,为什么会造成这种情况,我个人估计innovate511就是从DW 2.0开始学习和实践,所以他的操作性很强(至少从他的自信中感觉到,希望事实如此)

但奇怪是,为什么innovate511这次只提Kimball,不提Inmon.而把Kimball定义为实践大师,让这里的BIers 感觉Inmon是架构定义者,Kimball是实践者.

其实,据我所知.Kimball也是DW架构的定义者!!

Inmon首先提出了数据仓库的定义,但Inmon最早定义数据仓库架构，Kimball先定义出DW架构,Inmon对Kimball的DW架构并不满意,但Inmon费劲力气也没能驳倒Kimball。这样Inmon没办法了,就提出DW2.0后立刻就注册了商标. 他注册了商标!!!! 这是很幽默的事情,这样Kimball所说的DW,就不是DW了.只有DW2.0中提到的才是DW.如果innovate511这里所说的DW就是Inmon所注册商标的DW 2.0, 那我无法可讲了,因为并定义住了.

但业内并没有被Inmon这个幽默的举动固定住,还是认为DW架构比较成熟并已经形成理论的主要有两个，一个是Corporate Information Factory，简称CIF，代表人物是Bill Inmon。另一个是Mutildimensional Architecture，简称MD，代表人物是Ralph Kimball。 业内并把Bill Inmon注册的那个DW2.0改为CIF 2.0.


CIF 2.0主要包括集成转换层（Integrated and Transformation Layer）、操作数据存储（Operational Data Store）、数据仓库（Enterprise Data Warehouse）、数据集市（Data Mart）、探索仓库（Exploration Warehouse）等部件。
MD分为后台（Back Room）和前台（Front Room）两部分。后台主要负责数据准备工作，称为数据准备区（Staging Area），前台主要负责数据展示工作，称为数据集市（Data Mart）。而数据仓库是一个虚拟的部件，它指的是全部数据集市的集合。

innovate511看来是Bill Inmon的信教徒,就是这样混淆大众的是非,把Kimball说成实践大师,这样就把DWBI分开了,DW是 Bill Inmon的领域,BI是DW的实践,实践大师是Kimball.

呵呵,所以,当我提到BI的时候,一旦基于MD的DW就被他以EDW嘲之. CIF和MD都是DW.这是你改变不了的.