OLAP工具毁了商业智能

kinghq

两位的观点好像是一致的。：）

对我来说，架构和模型确实是领导看不到的，但这是区分优秀乙方的关键所在。因为，在我看来，架构平衡了性能与功能、当前需求和未来应变之间的矛盾；而模型是在标准化、规范化以及推广的便利上提供了很好的基础。

至于架构和模型是怎么来的，我不去深究。我只希望有更好的架构和模型能够形成。

对于我来说，就在于判断什么时候需要改架构和模型。至于这个修改，一般是原厂商来做升级，要么就是由那个拥有更好的架构和模型的乙方来做替换。

innovate511

更换架构是甲方一大忌，其高昂的成本，只有经历过的甲方心里清楚。至于当初为啥DW架构没有考虑好，为啥不找合适的乙方设计，那是自己的教训。当然有钱的主不在乎这点钱也无所谓，他也可以向上级说DW生命周期一般就1、2年，那也没问题，这是题外话了。

kinghq

我当然希望一开始的时候就选好了。这样，起码费力不讨好的事情可以少一些。虽然这是题外话，但与做好项目密切相关。因为项目是甲乙方一起做出来的。乙方实际上也要把握一下这个：毕竟这跟自己赚钱有关系。

其实最重要的是：IT部门干什么，业务部门干什么，这个话到底谁来说。

interstage

对了,楼上的说法已经认同了我的观念,IT部门和SI在BI项目的工作是什么?就是设计合理的DW架构. 什么是合理的DW架构?就是适合业务部门不断要求发展的"分析角度".因此,真正的BI工具,就是应该做到IT部门的"DW架构"和业务部门的"分析角度"实时互动和相互表述,IT部门依靠业务部门设计出来的"分析角度"来不断完善DW架构,业务部门依靠IT部门的DW架构来思考出新的"分析角度",相互促进,不断改善.

这就是我心中的BI工具,而不是象现在这样的BI工具,追求界面漂亮和数据函数，想搞得尽善尽美,这样的追求,再追求下去,你能超过EXCEL工具!!!!

kinghq

其实不管是否有大领导出来说话，到了最后一定是这样的：业务部门负责“决策”，IT部门负责“支持”——决策支持不就是这样的么。

至于楼上说的BI工具，我已经有了一个选择-mindmanager，但还没验证过。至于“实时互动和相互表述”，我觉得没有必要要求那么严格，能有联系就可以了。至于各自的工作，我觉得应该用不同的方法来解决各自的矛盾：业务部门要解决“决策”中的矛盾；IT部门要解决“支持”中的矛盾——ETL架构和DW模型就是解开这个矛盾的两把钥匙。这也符合管理上组织结构的原则；老把几个部门搞在一起，总不是什么好事。

interstage

对了.业务部门负责“决策”，IT部门负责“支持”——决策支持不就是这样的么.就是这句话.  
我自去年就是按照这个思路去做BI项目,连续做了几个,结果几方都很满意,为什么满意:
1,IT部门满意:IT部门不用做报表,就不需要理解业务部门为什么要做这样的报表,报表里为什么用这种统计方法,不用做"分析角度"了,就不需要理解报表中看信息的切入口为什么是这些,而不是那些.IT部门制作的 DW和ETL的架构是基于业务部门的"分析角度"来实施的,不是来自于SI公司或者咨询专家.
2,业务部门满意:业务部门自己设计"分析角度",根据"分析角度"做代表自己想要的报表,不需要告诉IT部门这张报表代表什么意思,为什么要这样做统计,为什么要这样来看信息等等
3,SI公司满意:BI项目开始就可以结束了,不是传统的"需求分析---模型设计---报表开发"的模式,只要抛砖引玉,以后就按人头算钱,项目费用马上收回.
4,领导满意:业务部门原来只看报表结果,老是和IT部门搞来搞去,现在会自己分析报表,公司的层次提高了.

所以,我目前还是这个观念"目前的OLAP工具毁了BI",需要我们去更正,找到适合成功的方向,不断改善.

kinghq

可惜我的领导没认识到。所以我希望我的领导以及领导的领导们能多出去转转。不管怎么样，让他们看看成功的项目是怎么做的，更重要的是人家为什么成功，为什么满意，我们跟人家的差异到底在哪里。

esestt

没仔细看完作者的帖，但我觉得interstage的观念还停留在几年前。早期BI工具的数据交付方式就是通过OLAP生成透视表，就是作者所说的OLAP报表产品。但是报表是报表，OLAP是OLAP。报表工具的数据源不一定用OLAP多维数据源，使用数据仓库中的关系型数据库，在报表设计时同样也可以制作透视表，同样可以定义OLAP中的层次和分组概念。但这样每一个报表都要同样定义这样的层次关系。
作者所说OLAP“最根本的难点在于业务部门知道报表代表的真正含义，却不知道报表的数据统计模型模型；而IT部门通过理解业务部门的描述，在数据库端进行设置数据统计模型，却对报表本身所代表的价值很难理解。”这不是OLAP的问题，整个BI/DW的生命周期中都会碰到这样的问题，只不过作者是用OLAP作为报表数据源，所以说IT人员在OLAP中定义的各种模型、运算和业务人员看到的报表会发生理解上偏差。解决问题的办法当然是做好元数据的管理，最重要的多和业务人员沟通，有时一个细节要打几十个电话给业务部门，做BI是要脸皮厚的。
而且目前很多BI工具提供解决这类问题的方法。
比如Microsoft SQL Server 2005在OLAP方面就提出了一种UDM概念，并且提供了OLAP视图、翻译的功能，在数据交付方式上提供了报表模型，由IT人员提供业务人员能够理解的数据，而且还有SharePoint Server实现与Reporting Services和Office整合。Office Excel 2007中对OLAP和KPI的支持也大大增强，并且提供Data Mining和PerformancePoint扩展。目前我们单位的那些人就最喜欢用Excel连接OLAP服务，觉得比让我们这些做IT的设计报表方便多了，而且还可以在SharePoint中实现部门级文档共享和管理。
SAS有一个模块叫Information Map也是类似的功能。
Oracle也有类似的概念，将BI工具分成战略型和战术性，比如在其企业管理软件(People Soft,Siebel)中提供了类似数据仓库的分析数据，通过绕过传统数据仓库的开发，配合Oracle E-Business Suite Analytic Applications、PeopleSoft Enterprise Analytic Applications等工具提供不需IT人员参与的数据分析方法，并且还有业务人员使用的Ad-hoc工具。

OLAP最大的优点是通过多维聚合实现数据切片、钻取、旋转、运算等功能。所以对OLAP多维立方体只是一种方便用于分析的数据存储和模型而已。
至于作者说的效率和存储空间大问题，不知道你用甚麽工具，有没有设计OLAP数据分区。效率和储存空间是不能共存的，对过时的OLAP数据分区使用ROLAP解决储存空间问题，对常使用的OLAP数据分区使用MOLAP解决效率问题。

维度是用户对数据的观测角度，维度当然也会随着用户需求而变化，以前用SQL Server 2000时是会碰到这样的麻烦，作者可以试试SQL Server 2005，它对Cube的管理方式已大大变革，可以满足你的需要。

wzcyc

元数据的定义一定是经过协商的，离开了最终用户的认可和理解，数据又有什么意义呢？
大家好像一直在谈论业务部门和IT部门分工的问题。其实这里面还有不同的实践。
有些公司都会找一些商务分析人士，然后分布在业务部门和IT部门，职责有所不同，但是目的是一样的把需求总结起来，传递下去。这样就不会有这么多的 gap 了。

interstage

呵呵,18楼没仔细看完就评论了很长,而且完全从数据库产品的功能角度很描述,我在98年就在这些数据库原厂商做技术支持了,这些功能我也清楚,不必要细节描述,我的原意是什么?是BI项目实现中目前存在的思想上误差,这个误差导致目前BI失败的多,成功的少,而成功往往是短暂的成功.

为什么这么说,BI项目其实是为了企业提升管理，而企业提升管理主要有两种方式，其一：当企业的发展远远超过管理水平的提升，管理成为制约企业发展的主要原因，此时企业才有意识地通过引进管理人才或借助外脑的形式提升管理能力，这种方式是被动的；而另一种方式是企业通过建立和导入持续改善管理的机制，使管理能力稳健提升，甚至，企业的管理提升的速度超过企业自身规模的成长，反过来成为企业发展的源动力之一，而这种管理改进是主动的。
  而目前传统的BI项目是第一种方式,第一种方式符合"精英"管理企业的方式,而我认为BI项目不仅仅要有第一种方式,更要有第2种方式,即"持续改善"的管理思路,"持续改善的管理理念",它是指运用常识性的、低成本的方法来管理工作场所--产生附加值的地方."改善"的精神,就是不论你在做什么,都能做得更好 . 这种"主动式"的方式可能会引领BI走出目前的困境,这也是我认为新一代OLAP工具设计的关键所在.