OLAP工具毁了商业智能

esestt

最初由 interstage 发布
[B]所以,我一直认为可以把"多维角度"和"数据钻取"交给业务部门, [/B]

你的意思是把维度的选择，数据泛化、钻取，切片，旋转等这些OLAP操作交给业务人员去做？

interstage

这些OLAP操作,可以让业务部门来做,但要把IT术语变成业务部门可以理解的术语,比如"OLAP"称为信息活用,"纬度选择"称为"分析角度",数据泛化、钻取，切片，旋转等可以用掷色子的方式来描述,总之一句化,简单而易懂!! 报表工具的功能部分不要用OLAP带的那些展现部分,就用EXCEL,
IT部门就负责EDW的数据设计,其实BI从IT的狭义角度来讲,不包括EDW,但从广义的角度却包括.

这样的BI项目,就是企业"全员工"参与的BI项目,而不是有些"精英"参与的BI项目,是值得推广的.

esestt

最初由 interstage 发布
[B]我在这个ITPUB的论坛上看到了2篇文章,"绩效主义毁了SONY"和"丰田战胜通用的背后", 这2篇文章其实讲到了BI项目中经常提到很高的应用境界,就是"绩效管理"和"战略管理",但作为500强企业的SONY和通用早在10年前就成功实施的"绩效管理"和"战略管理"BI项目,却不如"执行力"很强的丰田,这个是不是值得我们深刻思考.
  所以,我认为我们现在太受美国文化的影响了,就是崇尚"精英人士"管理企业,因此借助咨询专家,为公司领导提供"绩效仪表盘"等等,其实美国模式是最不复制的,所以,越学习它,就越赶不上它,越不可能成功. 唯有采用老毛时代提到的"人民的智慧",就是让企业的员工一起参与进来,变成"员工团队"的BI项目,才可能突破"精英人士"的BI项目,取得成功.
  BI项目的应用有5类,日常统计,即席查询和OLAP分析,数据挖掘,专题应用和战略管理.  由于数据挖掘更多的是算法,不适合业务人员,只适合专业的人员,而其他的应用均涉及到"多维角度",因此,OLAP变的关键了,所以我一直认为OLAP工具可以从目前的为"专业人士"使用和配置,完全可以让用户自己来,只是把数据部分归于IT部门,"多维角度"归于业务部门而已.

这就是我最早的想法,当我按照这个想法去实施BI的时候,我突然发现业务部门,企业领导,用户的IT部门,SI公司都变的可以接受,BI原来就没那么简单,只不过,我们把它复杂化了. [/B]

BI只是为决策提供支持，但做决策的是人，而且很多决策不是BI提供的数据就能做判断的。像我们做外贸，低价抢占市场，从BI提供的报表上看，销售额一路飙升，但利润很低，有些产品还亏损；BI工具只是把这种情况告诉决策者而已，但这种发展模式是否健康是需要人去做权衡。信息系统永远只是辅助性的工具，代替不了人。不能说某个公司用了BI就应该比没有用BI的公司管理更好。



让业务人员参与到BI的设计中还不太现实，至少在我们公司，业务人员能看到的就是自己手头上的工作，不像决策者需要从一个高度上考虑问题。
做BI的被夹在管理人员和业务人员中间，所以做DW最重要的工作不是开发，而是与业务人员和管理人员进行沟通。
像我之前帮做的一个报告，管理者需要看产品的缺货量，就是将客户订单中产品数量跟仓库中的存货量比较一下。因为我们内销产品供应比较紧张，客户从最初订货计划到仓库发运要经过一级级审核，客户经理进行信用审批，会计进行收款审批，到了仓库库存不足可能是退回也可能单据暂挂，工厂还要据产能对订单数量调整等等，库存量还要主库位、虚拟库位的概念，产品还有一层BOM结构，同规格之间还有替代品……
在做报表时要获取正确数据，统计的口径很重要。管理者当然不会了解到每一个业务流程的详细情况，他不会告诉你被暂挂或者在某一个环节被取消单据中订购产品数量要不要统计。而每个业务人员只能告诉你他知道的情况，而跟业务人员谈什么缺货量，他也搞不清楚是什么东西。
我做这个报表的时候，因为刚加入BI项目，对业务系统不是很熟悉，我们ERP用的是Oracle JDE，功能很强大，模块很多，但也很复杂，同部门的系统实施人员只能告诉我某个模块提供了什么样的功能，但每个业务部门怎么操作的得跟业务人员谈。我找了十几个业务人员调研，有些时候只能是我问什么他们答什么，我没问的他们也不会主动说，有些情况我在系统里看到的他们也不知道，而且有些时候根本不知道该找什么人问。
正因为信息的不对称，管理人员不知道每个业务部门工作，业务部门不知道管理者想知道些什么，所以DW才有存在的价值。

esestt

最初由 interstage 发布
[B]这些OLAP操作,可以让业务部门来做,但要把IT术语变成业务部门可以理解的术语,比如"OLAP"称为信息活用,"纬度选择"称为"分析角度",数据泛化、钻取，切片，旋转等可以用掷色子的方式来描述,总之一句化,简单而易懂!! 报表工具的功能部分不要用OLAP带的那些展现部分,就用EXCEL,
IT部门就负责EDW的数据设计,其实BI从IT的狭义角度来讲,不包括EDW,但从广义的角度却包括.

这样的BI项目,就是企业"全员工"参与的BI项目,而不是有些"精英"参与的BI项目,是值得推广的. [/B]

难道你们不是由BI用户(包括业务人员和管理者)来操作的？

interstage

BI是应用,应用的操作当然是业务人员来操作,但你还没理解我的意思,我的意思是目前的BI应用,是IT部门设计好"纬度",开发好统计方法的基础上,在I这些已有"纬度"和"统计方法"的范围内,业务人员来选择和操作. 这种方式方法我个人感觉不适合,这样抑制了业务人员的创造性思维,他们只变得只会统计,不会分析;只会业务操作,不会业务思考了.作为决策分析的BI,思考很重要,让业务人员去思考更重要.
所以,我的意思就是"纬度"和"统计方法"应该是业务人员自己定义,再告之IT部门,不是反过来.

我这个描述,你是不是清楚我的意思了?

esestt

最初由 interstage 发布
[B]我的意思就是"纬度"和"统计方法"应该是业务人员自己定义,再告之IT部门,不是反过来.
[/B]

我不太理解你的意思。
但我做维度是这样做的：
比如产品维度，业务系统里有产品的各种属性，有些是工厂定义的，有些是销售定义的，有些是仓库定义的。
在OLAP设计维度时，我把这些属性全都包括在维度中，然后根据部门做OLAP视图(我用的是SQL Server 2005，OLAP有透视的功能)，比如把工厂要的产品维度中属性选在工厂的OLAP视图中，销售要的属性选在销售的视图中……
维度中的层次我一般不定义，由BI用户需要时自己组织。

BI客户端是报表工具，SQL Server 2005的报表设计工具有两种，一种是IT人员开发的专用工具，设计好后直接发布给用户。另一种是用户使用的简便开发工具，通过鼠标拖拽设计报表。

不过现在用得最多的是Excel，我在SharePoint Server上发布Olap数据库的数据源，用户直接点击就可以打开Excel连接上OLAP数据库。
至于透视表，图像什么的由用户自己做，维度的层次也是这时由用户自己组织，用维度的什么属性分页、查看由用户选。

interstage

你的描述很详细,基本上就是目前传统实施BI的方法.IT部门根据业务部门的需求设计好OLAP视图(产品纬度\地区纬度\组织架构纬度\时间纬度,常见的4大纬度),业务部门自己选择这些OLAP视图和层次来做报表分析,这就是目前BI项目实现后的情况,对吗?
我说的是在这个基础上,如果在实际应用BI项目后,业务部门认为IT部门OLAP视图的设计不完全覆盖他们的要求,怎么办?不是要和IT部门商量了,要他们再设计一个OLAP视图了,这样的要求其实很常见,特别是业务部门开始学会思考后,要求会越来越多,BI不是ERP,ERP因为流程相对固定所以整体变化不大,而BI报表的变化是巨大的,可能以前经常采用的分析角度,由于业务部门学会思考后,放弃了原来采用的分析角度,变成另外一种表达方式了,IT部门相对业务部门来讲,人员较少,不可能1对1的对应,而报表分析的变化往往要求及时,怎么办,这就出来了业务部门抱怨IT部门"对应慢"的问题而IT部门抱怨业务部门"变化多"的问题.
还有一个关键的问题,思考一开始往往是不成熟的,所以需要证实或者证伪,业务部门需要用新的分析角度(纬度)来证实或者证伪,如果让IT部门参与业务部门这些证实或者证伪的新的分析角度,新的分析角度可能都是昙花一现的,只是证实或者证伪过程中出现的,这样就不适合IT部门参与.

esestt

[B]
业务部门认为IT部门OLAP视图的设计不完全覆盖他们的要求,怎么办?不是要和IT部门商量了,要他们再设计一个OLAP视图了
[/B]

我是在原来的cube中加入他们需要的，不再重新设计一个新的olap视图

[B]
而BI报表的变化是巨大的,可能以前经常采用的分析角度,由于业务部门学会思考后,放弃了原来采用的分析角度,变成另外一种表达方式了
[/B]

我一般不做报表，报表的格式比较固定，不能满足用户的需要，特别是财务那边，经常对要对报告修修改改，所以我让他们用Excel连接到OLAP数据源，让他们自己做报表。
OLAP只是数据源。要选折什么分析角度由用户自己定。

[B]
业务部门需要用新的分析角度(纬度)来证实或者证伪,
[/B]

新维度的情况我只碰到过两种，一种是在ERP中定义的，比如销售在觉得在产品中还需要新加入一种分类，或者加入一类新的账目，那么他们首先联系的是ERP开发人员，在ERP中加入，然后再轮到DW开发人员改写ETL过程，这是没有办法的事情。
另一起情况是在BI分析中生成的，比如以前帮销售用数据挖掘工具对客户聚类，他们觉得这样对客户分类非常不错，然后给没有类别的客户起一个名称，希望能在报表中加入客户的这种分类属性。这种分析方法做过一次就够了，数据挖掘模型定期更新，OLAP中的客户分类属性也定期更新，不需要IT人员特别关注。

interstage

OLAP是固定后,业务部门可以这样做.如果建的OLAP不适合业务部门需要怎么办.,直接从EDW取吗? 你说来说去,就是你建的OLAP这个数据源完全符合业务部门的需求(不管是现在还是将来),这就是IT人员在建设BI中最浪漫的想法.

esestt

最初由 interstage 发布
[B]OLAP是固定后,业务部门可以这样做.如果建的OLAP不适合业务部门需要怎么办.,直接从EDW取吗? 你说来说去,就是你建的OLAP这个数据源完全符合业务部门的需求(不管是现在还是将来),这就是IT人员在建设BI中最浪漫的想法. [/B]

你的意思是OLAP中不包括用户想要的数据是伐