OLAP工具毁了商业智能

thrips

我觉得，业务模型应该是按照实际的业务流程分析得来的，和业务人员如何来观测这个模型并没有必然的联系。业务流程的变化其实是缓慢的，因为业务人员没有特定的理由，并不会轻易改变自己的工作方式。大多数的业务种类，其生命周期都远必计算机技术长，其变化也必计算机技术缓慢得多。这应该也是为什么都喜欢往业务模型上靠的原因之一吧。经常变化的应该是业务人员对业务模型中的数据的观测角度，这个是随着管理上的需要而不断的在变的。观测角度的变化由前端工具来支持，这个我十分赞成，因为这和数据本身没有关系。如果需求的的变化并不是这么简单，那就应该商榷了。比如在interstage的例子中，如果数据仓库中没有人员这个维度，现在业务上有这个需求，我们应该怎么解决呢？难道在展示工具自己会产生数据吗？还是展示工具自己到数据源中去取呢？那和BO的语意层的概念应该是一样的。但是我并不赞成这种做法。当我们发现一个业务模型的缺陷，我们因该做的是去完善这个业务模型以及相关的数据模型、ETL程序等等，而不是在前端打个补丁。这样在业务人员看来似乎是没有差别，但是实际上，你前端工具所展示的业务模型，和数据库里存储的实际的业务模型是不一致的。如果这样打了很多补丁之后，那么，我相信，这个数据仓库项目其实失败了。因为你这个数据仓库项目的核心是前端展示工具，因为在他那里包含了很多只有它知道的东西，他变成不可替代的。我觉得，数据仓库项目实施完，最有价值的就是这个业务模型，选择那个厂商的产品，只是一个技术可行性和成本的决策，不是关键。人都有惰性，过于强大的前端工具，会使人倾向于使用前端来解决问题，而最终忽视了后端数据的建设，这样是舍本逐末，最终自己咽下苦果。

kinghq

按我理解，这个讨论还缺了两类人：做应用的和做管理的。这个在我的症结初探里讲过了。其实也很好理解：做应用的有数据，做管理的有模型；而提高数据处理效率可以交给DW来解决，提高整体决策效率可以交给BI；至于这两者之间的差距经过这么一环节也就小多了，小到既可以用BI工具来解决，也可以用DW来解决的程度——这样不好么？！当然，如果差距还是很大，那么仍然要交给做应用和做管理的去解决。为什么？因为他们的结论还没法落地。所以，我在提到的解决办法里也就是选择两条腿走路。至于怎么个走法，是先左先右，还是蹦跳着过去，那完全是看客户自己的把控能力。

通过这几天的密集沟通，我觉得自己的思路还算是清晰而完整的了。

duzhaoyi2000

从这个帖子学到不少东西，呵呵
再拜一下几位大侠：）

interstage

希望不要再在这个贴子上继续讨论'BI和DW'之争了,继续讨论"OLAP工具毁了BI",前提是建立持续改善的企业. 欢迎继续讨论

innovate511

我前面一个帖子说过，争论的关键不是业务模型、数据模型的关系，而是你过于看重BI工具去直接实现，而忽略了数据模型的作用，或者说你还不太懂如何利用数据模型支撑业务模型，于是就下结论吹嘘新型的OLAP工具如何如何。

至于你对这个论题一再回避，去关注你认为抓住我“小辫子”的问题，我已经解释过很多次了，做过实施的，特别是项目管理的，都应该非常清楚，不会问这么业余的问题。

所以你以后其他与争论核心问题无关的话题，我不再参与，直到你把核心争论问题说清楚再说，其他人有兴趣的可以继续。谢谢！

如果你说这个标题的命题是OLAP工具毁了商业智能，但是后来讨论中却说某某工具如何如何，那么我就提出了尖锐的问题，结果圈子绕了一大圈，核心争论还是没有得到解决。不管我说得多有道理，如果争论的另一方始终不面对，那么这个问题永远也解决不了了。

interstage

最初由 innovate511 发布
[B]我前面一个帖子说过，争论的关键不是业务模型、数据模型的关系，而是你过于看重BI工具去直接实现，而忽略了数据模型的作用，或者说你还不太懂如何利用数据模型支撑业务模型，于是就下结论吹嘘新型的OLAP工具如何如何。

至于你对这个论题一再回避，去关注你认为抓住我“小辫子”的问题，我已经解释过很多次了，做过实施的，特别是项目管理的，都应该非常清楚，不会问这么业余的问题。

所以你以后其他与争论核心问题无关的话题，我不再参与，直到你把核心争论问题说清楚再说，其他人有兴趣的可以继续。谢谢！

如果你说这个标题的命题是OLAP工具毁了商业智能，但是后来讨论中却说某某工具如何如何，那么我就提出了尖锐的问题，结果圈子绕了一大圈，核心争论还是没有得到解决。不管我说得多有道理，如果争论的另一方始终不面对，那么这个问题永远也解决不了了。 [/B]

核心问题在另外的贴子上"业务驱动BI",已经明确说明了,就是你所说的"数据模型尽量满足客户个性化需求"而先化重点做"数据模型",你把这个"数据模型"包装成产品,然后以IT服务方式卖给其他客户,这种产品化的方式是可以的. 但绝对不能在项目化中.

这里还是讨论OLAP工具吧. 你的核心问题在那个贴讨论吧.可以吗?

innovate511

最初由 interstage 发布
[B]

核心问题在另外的贴子上"业务驱动BI",已经明确说明了,就是你所说的"数据模型尽量满足客户个性化需求"而先化重点做"数据模型",你把这个"数据模型"包装成产品,然后以IT服务方式卖给其他客户,这种产品化的方式是可以的. 但绝对不能在项目化中.

这里还是讨论OLAP工具吧. 你的核心问题在那个贴讨论吧.可以吗? [/B]

请不要回避我的最主要的问题。数据模型是可以包装，但我从没说过可以直接拿来上项目，就好比BI工具，你不根据业务模型做开发，如何满足客户的需求呢？难道你买一个产品就想直接用了？

我再次申明，我的问题核心是，既然你提到OLAP工具能有很多维度型生成功能，让客户直接个性化分析，阁下也说过这是争论的起源。那请问面对你自己举的例子、我提到的问题，该如何解释呢？如何让OLAP工具去处理那么多现实问题呢？如果再讨论分支问题，连核心争论都没搞明白，其他问题争论起来也没用！！！！！！

我自己提出的一个典型问题如下：
“比如有的时候我们需要把事实表加上通过维表型（维的某个描述）结合度量产生复合度量放到事实表作为一个字段，因为考虑效率原因，毕竟目前各大行业哪怕是部门级BI项目也是海量数据了。这种情况在一般的项目中是采用汇总后再去生成，而BI的分析会考虑到不同粒度的分析，所以不能只在汇总表里做，而要在数据集市需要的最低粒度做起。那么这个时候我们的事实表就必须和维表紧密结合，产生不同于传统的事实表。所以OLAP角度去里考虑计算维属性，那是非常狭隘的方案，很多具体项目情况都没考虑到，那只能少数的项目才能完全适合他们产品宣传的功能了。”

老兄自己的问题是：
“你讲到点子上了,IT部门和业务部门在交流"分析角度"的时候存在失真. 把分析角度定下来了,业务人员开始讲统计要求了,IT部门把这个统计方法变成算法,用复杂的SQL语句或者OLAP工具的计算函数,从数据从几亿上通过计算成一张只有不到1000条数据,IT部门这么辛苦出来报表了.居然业务人员对刚才的"分析角度"要求变化了,这IT部门不是要疯了.”我说这个不是问题，好的数据模型可以轻松处理，老兄却一直没个说法，真是遗憾。

interstage

最初由 innovate511 发布
[B]
请不要回避我的最主要的问题。数据模型是可以包装，但我从没说过可以直接拿来上项目，就好比BI工具，你不根据业务模型做开发，如何满足客户的需求呢？难道你买一个产品就想直接用了？

我再次申明，我的问题核心是，既然你提到OLAP工具能有很多维度型生成功能，让客户直接个性化分析，阁下也说过这是争论的起源。那请问面对你自己举的例子、我提到的问题，该如何解释呢？如何让OLAP工具去处理那么多现实问题呢？如果再讨论分支问题，连核心争论都没搞明白，其他问题争论起来也没用！！！！！！

我自己提出的一个典型问题如下：
“比如有的时候我们需要把事实表加上通过维表型（维的某个描述）结合度量产生复合度量放到事实表作为一个字段，因为考虑效率原因，毕竟目前各大行业哪怕是部门级BI项目也是海量数据了。这种情况在一般的项目中是采用汇总后再去生成，而BI的分析会考虑到不同粒度的分析，所以不能只在汇总表里做，而要在数据集市需要的最低粒度做起。那么这个时候我们的事实表就必须和维表紧密结合，产生不同于传统的事实表。所以OLAP角度去里考虑计算维属性，那是非常狭隘的方案，很多具体项目情况都没考虑到，那只能少数的项目才能完全适合他们产品宣传的功能了。”

老兄自己的问题是：
“你讲到点子上了,IT部门和业务部门在交流"分析角度"的时候存在失真. 把分析角度定下来了,业务人员开始讲统计要求了,IT部门把这个统计方法变成算法,用复杂的SQL语句或者OLAP工具的计算函数,从数据从几亿上通过计算成一张只有不到1000条数据,IT部门这么辛苦出来报表了.居然业务人员对刚才的"分析角度"要求变化了,这IT部门不是要疯了.”我说这个不是问题，好的数据模型可以轻松处理，老兄却一直没个说法，真是遗憾。 [/B]

看来你真的没理解我的话,好的数据模型的确可以轻松处理,但需要IT部门去做去改变, 我的这话的描述是业务部门可以直接做,不需要麻烦IT部门了. 还有我的话的前提是这些"分析角度"一开始没有在数据模型中定义好,如果业务部门提出来了,是过分依靠IT部门,还是选择自己来,我相信更多的业务部门喜欢自己来.

innovate511

最初由 interstage 发布
[B]

看来你真的没理解我的话,好的数据模型的确可以轻松处理,但需要IT部门去做去改变, 我的这话的描述是业务部门可以直接做,不需要麻烦IT部门了. 还有我的话的前提是这些"分析角度"一开始没有在数据模型中定义好,如果业务部门提出来了,是过分依靠IT部门,还是选择自己来,我相信更多的业务部门喜欢自己来. [/B]

首先很佩服贵公司在OLAP的研究, 也想为客户得到更多的东西, 提高客户满意度.

不过我的问题, 不是说你OLAP工具不能实现这个这点, 而是不能满足客户的真正的需求. 首先从技术角度看, OLAP工具要实现无限多的业务模型转换, 除了自带的函数外, 必须要提供接口, 让使用者自己去写语句实现. 不知道OLAP工具是否有更高明的手段.

其次从数据量来看, 为啥很多事情公认地要选择在数据仓库去做, 因为数据仓库的核心是存储, 而BI工具等都不能有这个特点. 这样, 我自己举的例子中, 就能帮助客户提高效率. 不知道老兄认真看过没有.

而你举的例子里, 说的是很多逻辑放在聚合表里, 然后当业务需求更换时就会无法适应其变化. 我在前面说过, 这是不合理的数据模型, 作为例子来说, 是十分不恰当的, 如果这样说你的产品能替代数据模型的部分功能, 显然不合适.

最后, 不知道楼主体会过没有数据仓库的存储帮助直接实现BI的痛苦没有? 这个例子虽然是放大了问题, 不过是一个缩影. 在某大型客户上数据仓库之前, 客户的报表需求都是通过某著名BI工具去做, 客户最常见的问题有两个: 1. 效率太低, 很多报表需要半小时以上, 但限于客户流程限制, 也只能如此. 2. 客户有的复杂报表不能实现, 比如部分财务年报. 我们只能解释, 在上数据仓库后, 这些问题都可以得到解决.

所以如果良好的BI解决方案没有考虑到整体解决方案, 不考虑客户的所有实际问题, 只关注到客户某一方面需求, 那离真正的创新还差很远.

interstage

同意你这个观点, 从"效率太低"和"复杂报表"的问题上,的确BI工具不如放入DW来的合适.
但我讲BI工具不是说这个问题, 是讲都是OLAP工具能做的(不涉及与DW这些问题)基础上,现在BI工具做多维角度需要需IT部门来配置的,但我讲的OLAP工具是在这个基础上,来说不能让IT部门来配置,应该让业务部门来配置这个多维角度.

你仔细看看我的原文章和举的例子都是基于这个基础的. 本来是多维角度这个业务模型在BI工具配置的基础上谁来做的问题. 你却说这些多维角度的业务模型应该在DW的数据先建好,导致了我的"先业务后数据"和你的"业务与数据平等"的讨论.