OLAP工具毁了商业智能

innovate511

个人认为，并非“信息孤岛情况已经影响到了管理人员的决策时才有可能上数据仓库、BI这样的项目”。现在很多厂商推出的产品，都朝分析型产品发展，而这个分析，其实就是BI，只是已经产品化了，因为他们是针对特点业务产品的BI。应该说中小公司也可以享受BI解决方案，但前提是局部解决方案，不一定需要整体BI解决方案。

1122cally

最初由 interstage 发布
[B]2楼的说法是逃避BI失败的责任,你应该在BI项目选型的时候,告诉你的用户,其实BI是可以让你的企业变成"持续改善的企业",但上BI项目需要企业来配合,让业务部门来做分析角度和报表的思路,才是实现"持续改善的企业"的BI项目的关键,只有这样的BI,企业才能真正享受BI给企业带来的改善:
改善之一:业务部门不再只看统计结果,而是提高自身分析的能力
改善之二:IT部门只关心基础数据质量和OLAP模型,只关注ETL和DW,不关注前端

只有这样的互动,才是真正的BI.不然永远是做一个'BI'项目,让用户失望一次.

我根据这个思路,近半年连续给企业高层聊这个思路,告诉他们如果他们不这样做,我就不接这样的BI项目,连续成功了5个,我觉得,我们不能由于目前存在的弊端,而不把正确的道路指出来.如果连我们自己都不坚持,在中国,BI也是没希望的. [/B]

请问"IT部门不关注前端"如何成功地去做ETL和DW,架构和模型~

interstage

23楼, 如果"IT部门不关注前端"能够成功地去做ETL和DW,架构和模型,这样的现象和案例是存在的话(我已经成功实现了),你是不是觉得这样的BI项目更容易成功,对吗?

至于如何做到, 需要找了CASE,我们可以一起来体验,呵呵

esestt

最初由 innovate511 发布
[B]应该说中小公司也可以享受BI解决方案，但前提是局部解决方案，不一定需要整体BI解决方案。 [/B]

Oracle就是将DW和BI分开的，DW用于解决信息孤岛问题，BI着重于分析和可视化，所以目前的战术性BI不是架构在DW基础上的，用于解决部门或某一业务模块的问题，对于小型企业来说这种方法成本低，更灵活。

interstage

其实,任何事物要理解清楚,一定是三个问题组成:
1,是什么?
2,从哪里来?---解释为什么会发生
3,到哪里去?---结实最终的目的是什么

21楼一直通过技术和应用系统来描述BI(BI是什么),其实一直在用他技术人员的眼光来描述"BI是什么",如果不从第2个问题和第3个问题来描述清楚,21楼其实永远看不清楚第1个问题 "BI是什么"

企业的发展需要企业的管理来支撑,这些管理上的决策需要"分析"来支撑,全世界的分析方法就2种, 演绎法和归纳法.如何在BI实现真正"决策支持",其实最核心的是BI如何来实现演绎法和归纳法.所以E.F.Codd博士定义出OLAP概念来支撑BI中的演绎法,而更多的数学家定义出数学算法来支撑BI中的归纳法. 这是BI的来源.
BI的最终目的是什么,就是BI如何将演绎法和归纳法让企业合适人在使用. 演绎法最合适的使用者是企业的业务人员,归纳法最合适的使用者企业的市场部门或者分析部门, 其实IT部门的BI工作就是如何快速的让以上2个部门使用这2个方法,而不是自己来用,其实IT部门自己也不会用.

只有,解释了"BI的来源"和"BI的目的",21楼才能理解你所说的"可视化、数据挖掘、DashBoard、绩效管理、监控、计划等"这些应用是什么.
其实,22楼已经指出了21楼的BI误解

innovate511

最初由 interstage 发布
[B]23楼, 如果"IT部门不关注前端"能够成功地去做ETL和DW,架构和模型,这样的现象和案例是存在的话(我已经成功实现了),你是不是觉得这样的BI项目更容易成功,对吗?

至于如何做到, 需要找了CASE,我们可以一起来体验,呵呵 [/B]

呵呵，这还需要找CASE啊，世界500强企业，有几个不是这种方式呢？做过500强EDW级项目的人都知道，DW和BI分开建是必然的，否则没法建EDW。

esestt

最初由 interstage 发布
[B]其实,任何事物要理解清楚,一定是三个问题组成:
1,是什么?
2,从哪里来?---解释为什么会发生
3,到哪里去?---结实最终的目的是什么

21楼一直通过技术和应用系统来描述BI(BI是什么),其实一直在用他技术人员的眼光来描述"BI是什么",如果不从第2个问题和第3个问题来描述清楚,21楼其实永远看不清楚第1个问题 "BI是什么"

企业的发展需要企业的管理来支撑,这些管理上的决策需要"分析"来支撑,全世界的分析方法就2种, 演绎法和归纳法.如何在BI实现真正"决策支持",其实最核心的是BI如何来实现演绎法和归纳法.所以E.F.Codd博士定义出OLAP概念来支撑BI中的演绎法,而更多的数学家定义出数学算法来支撑BI中的归纳法. 这是BI的来源.
BI的最终目的是什么,就是BI如何将演绎法和归纳法让企业合适人在使用. 演绎法最合适的使用者是企业的业务人员,归纳法最合适的使用者企业的市场部门或者分析部门, 其实IT部门的BI工作就是如何快速的让以上2个部门使用这2个方法,而不是自己来用,其实IT部门自己也不会用.

只有,解释了"BI的来源"和"BI的目的",21楼才能理解你所说的"可视化、数据挖掘、DashBoard、绩效管理、监控、计划等"这些应用是什么.
其实,22楼已经指出了21楼的BI误解 [/B]

你最初说的是OLAP模型使得业务人员难以理解，效率不高等缺点。
之后居然说到了企业管理的进化模式。
现在又说到了“BI是甚麽"、"演绎法和归纳法"，开始说哲学了麽，分析方法也不只演绎法和归纳法两种吧，以前大学时马克思主义哲学就学过。
老兄你到底是想讨论甚麽？你是在跟我捣糨糊吗？

innovate511

最初由 esestt 发布
[B]


Oracle就是将DW和BI分开的，DW用于解决信息孤岛问题，BI着重于分析和可视化，所以目前的战术性BI不是架构在DW基础上的，用于解决部门或某一业务模块的问题，对于小型企业来说这种方法成本低，更灵活。 [/B]

你说的是Oracle公司自身的DW项目，还是Oracle数据仓库解决方案？

对于你说的这种“战术性BI”，其实就是企业对于局部的有限性分析。它的生命力之所以很强，其实有两大原因：
1. 市场大。目前就连500强企业中相当多还没完成EDW的建设，何况广泛的中小公司了。那么在完成EDW之前，或者有的公司没钱构建EDW，各部门、分公司以及总部都需要BI，那么怎么办？于是一般就选择了建设Data Mart来弥补这种不足。而DM这种东西和DW本质的区别之一，就是DM是因为前端需要而建设的，而DW则不是。这样一来，这种需求当然大大超过了正在慢慢建设EDW的需求了，你可能往往会发现一些大公司EDW和局部DM（不是来自EDW的DM）并存的局面，因为他们正在系统过渡呢。

2. 厂商推动。厂商在实施、咨询方面，只对大项目有兴趣，其他利润还得来自产品。既然有那么大市场，厂商怎能放过，于是大家纷纷推出分析型产品，在自己产品基础上有BI，一是卖点，二是BI产品化对于厂商来说一点不费力，三是客户得到了部分想要的分析。

不过对于做实施、咨询的人来说，当然最感兴趣的是做EDW了，五脏俱全，而且难度极大，有挑战。更何况大项目利润高，你的价值可以和一些产品平分秋色。如果小项目，嘿嘿，那主要功劳就是推出产品的厂商了。

interstage

那你告诉我,这个世界上,除了演绎法和归纳法以外的分析方法还有什么,如果你能说出来,世界上所有的大奖都是你的了,哈哈!!!!!

interstage

esestt ,和你交流BI,总感觉很累,为什么? 你的学习方法就是演绎法学习方法,说明你只能说出你看到的和实施过的东西,归纳法学习的能力一点都没有,你能告诉我数据挖掘是演绎法还是归纳法?
学问有余,知识不够. 任何事务描述不都是这三个问题找答案,你从这三个问题去理解BI的话,你对BI的理解一下子深刻多了.

还有我最早的描述和现在的描述,一直阐述一个观念,OLAP分析模型(演绎法分析)应该交给业务部门来提供,而目前的OLAP工具在这点上考虑太少,这样把压力给了IT部门.

我是对目前的OLAP工具有疑问,并不反对OLAP概念,我真不知道我的描述,你是不是看完整了和看明白了?