OLAP工具毁了商业智能

jameszhuangmin

最初由 esestt 发布
[B]


如果这个维度只是用户自己临时需要，而且是由其他维度组合而成，那么让用户自己在用户端加上就好。
如果是长期需要，由IT人员在cube里由其他维度生成这个维度就可以了。
如果企业内有多个BI小组，比如集团内的分布式BI项目，其他小组也可能会用到这个维度，那么在DW里做一个维度表，再在Cube里加入这个维度。 [/B]

OK！太棒了！
不管是不是临时的、长期的；私有的还是公用的，只要都能像第一个答案：用户自己在用户端加上就好。这就是站在用户角度看问题了。

用户会不会加是能力问题；想不想加、愿不愿意加是工作主动性的问题；用户端工具能不能够加上是产品或者技术问题。

好的BI系统设计要站在用户角度看问题，好的用户端工具也要站在用户角度看问题。

interstage

最初由 esestt 发布
[B]


你不要岔开话题啊
你不是说现在的OLAP工具不行吗
你说说你碰到的问题，我告诉你我是怎么解决的 [/B]

     呵呵,我碰到的问题就是目前很多用户对BI项目实施后抱怨越来越多, 很多用户告诉我没有达到预期效果.
    当然用户也在发展,他们对这些抱怨有一些自己的解决方式,但都感觉不是解决问题的根本,我认为目前问题的根本就是:现在的OLAP工具在解决OLAP概念中2个核心(多维角度和CUBE运算)是牺牲了业务人员的分析能力为提前来实现的,存在逻辑上偏移. 所以才有这样的讨论.
   你认为不是这个因素,那你认为是什么因素,还是因为这些用户没有遇到你就匆匆上BI了,或者没有请你做BI项目总设计师,所以没有得到解决. 因为你都能告诉他们是怎么解决的.

esestt

最初由 jameszhuangmin 发布
[B]
用户端工具能不能够加上是产品或者技术问题。
[/B]

这个是需要的，因为大部分时候用户或分析人员无法事先知道该从甚麽角度观察。他需要自己组合或定义维度，只有从某个角度观察数据发现问题或者规律时，他才能确定需要从这个角度分析问题。

esestt

最初由 interstage 发布
[B]

     呵呵,我碰到的问题就是目前很多用户对BI项目实施后抱怨越来越多, 很多用户告诉我没有达到预期效果.
    当然用户也在发展,他们对这些抱怨有一些自己的解决方式,但都感觉不是解决问题的根本,我认为目前问题的根本就是:现在的OLAP工具在解决OLAP概念中2个核心(多维角度和CUBE运算)是牺牲了业务人员的分析能力为提前来实现的,存在逻辑上偏移. 所以才有这样的讨论.
   你认为不是这个因素,那你认为是什么因素,还是因为这些用户没有遇到你就匆匆上BI了,或者没有请你做BI项目总设计师,所以没有得到解决. 因为你都能告诉他们是怎么解决的. [/B]

甚麽抱怨？具体说。

jameszhuangmin

最初由 esestt 发布
[B]

这个是需要的，因为大部分时候用户或分析人员无法事先知道该从甚麽角度观察。他需要自己组合或定义维度，只有从某个角度观察数据发现问题或者规律时，他才能确定需要从这个角度分析问题。 [/B]

太好了，我们达成了初步的共识：好的BI工具应该让用户或分析人员可以自己组合或定义维度。先握个手

接下来的问题是要做到上述的功能，容易不容易？是否会让用户或分析人员感到太难，而不得不又去找IT人员帮助做？

我看到的大多数BI前端会让用户或分析人员感到很难，不知道esestt你看到的工具如何呢？是否用户也感觉很难呢？

interstage

最初由 esestt 发布
[B]

这个是需要的，因为大部分时候用户或分析人员无法事先知道该从甚麽角度观察。他需要自己组合或定义维度，只有从某个角度观察数据发现问题或者规律时，他才能确定需要从这个角度分析问题。 [/B]

呵呵,你终于说对了,是的连用户或分析人员都无法事先知道该从甚麽角度观察,他们需要自己组合或定义维度，只有从某个角度观察数据发现问题或者规律时，他才能确定需要从这个角度分析问题。这种组合或定义的过程本来就是证实和证伪的过程,他们也知道是不成熟的验证过程,这种不成熟的验证过程应该是私有的东西,应该不希望IT技术人员参与吧. 把只能靠OLAP前端工具.但OLAP工具在设计为了解决"'多维角度"和"CUBE运算"的矛盾,就是牺牲用户或分析人员为前提的,看来用户或分析人员靠OLAP前端工具是不行的.

他们只能对着BI系统说,为什么这个系统不是esestt设计的,不然我们就没疑惑了!

kinghq

上次说了我的一个思路。通过这几天的思考以及大家的讨论，我又有了另一个思路。

如果说DW给了我们统一的数据视图的话，那么OLAP工具应该给我们统一的维度视图。

其实作为IT来说，最害怕的莫过于不可预测的变化。如果我们能将我们的分析维度进行一下统一，那么IT将面对的压力就会小很多，起码知道了什么是可以不变的，只要针对变得部分进行组合就可以了。当然，这也会涉及到优化的问题；不过，这个问题可以放到一个更长的生命周期的其他管理流程上去解决。

这个观点，那谁已经跟我沟通过关于时间维度的观点。我的这个思路就是把这个观点放开了去：不同的是，他要做行业；而我，只是想做好我们自己的就行了。可惜的是，我没见到他们的实现。如果已经有实现的话，那么结合 interstage 提到的5W1H分解、优化、组合后就可以实现我的这一思路。

interstage

最初由 kinghq 发布
[B]上次说了我的一个思路。通过这几天的思考以及大家的讨论，我又有了另一个思路。

如果说DW给了我们统一的数据视图的话，那么OLAP工具应该给我们统一的维度视图。

其实作为IT来说，最害怕的莫过于不可预测的变化。如果我们能将我们的分析维度进行一下统一，那么IT将面对的压力就会小很多，起码知道了什么是可以不变的，只要针对变得部分进行组合就可以了。当然，这也会涉及到优化的问题；不过，这个问题可以放到一个更长的生命周期的其他管理流程上去解决。

这个观点，那谁已经跟我沟通过关于时间维度的观点。我的这个思路就是把这个观点放开了去：不同的是，他要做行业；而我，只是想做好我们自己的就行了。可惜的是，我没见到他们的实现。如果已经有实现的话，那么结合 interstage 提到的5W1H分解、优化、组合后就可以实现我的这一思路。 [/B]

OK,你说的非常正确,我们今天就把讨论时间这个在BI中最大的纬度困惑讨论一下.

技术人员的解决思路: 设计一张时间维表,放20年时间,20*365=近7300条数据,表中字段定义了本年第几天,本月第几天,本半年第几天,本季度第几天,本周第几天,是否节日等等来解决的.

这是目前最流行的解决方式,是不是这样.

如果,你同意我描述目前这种流行的技术解决方式,我就继续描述这种解决方式太技术性了,也是严格限制了业务人员的分析思路, 其实时间是最大的分析纬度,也是不应该由IT技术人员来做的.

interstage

其实,你说的对,DW解决数据视图,OLAP要解决纬度视图.所以时间这个纬度也是分为2块:时间本身和时间描述. 时间本来在数据库的事实表中,以datetime型(或者date,time型)存放着. 因此,这个在事实表中存在的时间本身.在业务人员认为的时间描述型是不一样的, 他们描述时间往往是"本月","本周","本季度","前3天","昨天","前天","上月本日","上周本日","去年本月","从年初到现在的累计","从本季度出到现在的累计".等等. 这些时间描述性与具体时间本身都需要计算,因此,我发现intestage NV把这个业务员口中的时间描述型单独定义为"时间模版"的管理视点,NV总结了93个时间描述型,业务自己也可以定义不同的时间描述.然后这个时间描述和数据库表的某时间本身字段做匹配,就可以解决这个问题了. 而不需要技术人员通过函数从时间维表算出"上月本日","去年本月"的具体时间,再和数据库事实表的时间本身做join.
  这种解决方式有2点:
1,IT部门不需要计算烦琐的时间角度
2,业务部门自定义时间角度

以上回答,符合5W1H的分析理论.5W1H是70年代提出来的分析理论,非常经典.

我为什么认为目前OLAP工具毁掉了BI,就是因为OLAP工具从技术实现出发,限制了业务人员的思维为代价,把分析角度的压力加给了IT部门或者SI公司,让技术人员认为项目控制成功或者优秀架构能解放业务人员的分析思维.却从来没有怀疑过产品设计思路.

我们只有勇敢承认OLAP工具最大的缺陷,才能是这些工具实现持续改善.

innovate511

我还是那个观点, 无论你是什么工具, 管的事情不要太多. 工具客户可能会换掉, 也许会有新的工具做新的应用, 只有数据模型不会换. 试想, 你的工具提供93个时间描述型, 能包含所有时间信息么? 肯定不能, 客户倒是使用了你的产品, 有新的需求, 他们如何去扩展呢?

再退一步说, 你的时间描述型能满足客户现有的需求, 但如果客户需要搞数据挖掘, 你的工具能支持么? 但如果这些事情处理在数据模型的维表里, 情况就不同了, 不但可以灵活变化, 而且任你什么工具, 什么BI应用, 都可以做支持, 而且可以成为客户的积累. 如果厂商把这个事情做了, 那只是厂商的积累, 而别人什么都不是, 有问题出现后, 就只有干着急的份.