OLAP工具毁了商业智能

kinghq

最初由 happysboy 发布
[B]

嘿嘿，要做这个得用个工具——脑袋，除此没想到有什么好招。

首先要做的是先确认这句话背后的意思，所谓”分析一下“，不光是ARPU角度的。要提升这群低价值客户价值，有些客户根本就是垃圾客户，你再怎么也找不到他的。因此，需要从最近是否充过值，是否通过信，主要使用语音还是增值业务等角度（当然还有其他角度，这跟后面的”活动“方式有关系）。

然后，让IT人员从DW里面查询数据，似乎没有办法用OLAP来实现这个分析。

得到数据后，用excel来作一些旋转透视表，这是业务人员可以自己做的。如果深入一些，需要挖掘人员帮忙作一些统计描述，观察一些数据的特征，诸如均值、众数等等。

最后得出若干规则——可以针对ARPU低于20块钱一下的，并且最近3个月发生过通信（纯粹发短信的不算）...这类客户，进行小额话费赠送来提升他们的价值。

不知道interstage说得工具能否办到，但我总觉得他说得是一种管理方法，不是工具。 [/B]

您说的这个ARPU例子涉及到很多问题。实际应用过程中还会碰到更多的问题。另外，针对不均匀需求更重要的是对这个需求的管理。

我现在的想法就是业务领域的事情先在业务管理方面解决。至于这个过程中涉及到的技术问题，也尽量用简化的方法解决，以为技术需要解决的问题规范接口。这样，业务-技术之间就可以很清晰了。

interstage

最初由 happysboy 发布
[B]

看来咱俩不是同一个行业，继续用你的例子来说事儿。有两个问题：
1、这个汇总表是业务部门自己建的还是IT部门建的？
2、如果从业务角度要新增从”信用卡透支额度“来分析，但这个汇总表中没有这个信息，该怎么办？ [/B]

1,汇总表就是日常的一张统计明细表,BI系统中有的.应该是SI和IT部门建的,业务部门在用的.
2, "信用卡透支额度"是度量值,不是纬度值,度量值本身做纬度值没意义,但度量值的范围可以做纬度.如果度量值汇总表没有,BI系统中是不是能找到,有就没问题.如果BI系统中没有,说明数据库里的这个度量值没在BI系统中开放,需要IT部门开放于BI系统,总不能让业务部门直接进数据库取吧.

kinghq

最初由 happysboy 发布
[B]

不好意思，前面那段话我确实没有看明白。”抛砖引玉“的成语用在这里比较奇怪。

但也有问题啊。如果是咨询商，自然是愿意，拉屎不用擦干净，咨询完了，跑了。SI埋头苦擦，结果擦了一半，被勒令重擦，是多么不爽的事情。我想没有哪个SI愿意这样，都力争上游。

除非，这个价值链条已经非常清晰，干下游的事情自然能够挣到钱，那有人干。不过这个时候还早。在目前，大家恐怕都不愿引后面的玉去，反倒更乐意抛前面的砖了。

说着有些跑题了。 [/B]

您说的这个事情我们也要面对。所谓价值链非常清晰，我觉得还在于我们的要求是否清晰，同时针对做的事情能否落实。两者缺一不可。

通过这里的讨论，我也有了一个落实的思路了，也就是刚才说的清晰业务-技术之间的接口。

这个对我来说正是需要直面的课题。

interstage

最初由 happysboy 发布
[B]

不好意思，前面那段话我确实没有看明白。”抛砖引玉“的成语用在这里比较奇怪。

但也有问题啊。如果是咨询商，自然是愿意，拉屎不用擦干净，咨询完了，跑了。SI埋头苦擦，结果擦了一半，被勒令重擦，是多么不爽的事情。我想没有哪个SI愿意这样，都力争上游。

除非，这个价值链条已经非常清晰，干下游的事情自然能够挣到钱，那有人干。不过这个时候还早。在目前，大家恐怕都不愿引后面的玉去，反倒更乐意抛前面的砖了。

说着有些跑题了。 [/B]

老大,你还是没理解我的”抛砖引玉“的BI实施方式:
1.抛砖: 咨询专家出业务模型,IT部门+SI用BI实现业务模型,这就是BI的"抛砖"项目结束了.SI拿到项目集成开发费用,专家拿到咨询费.
2,引玉:这块砖开始让业务部门去用,他们会在这块砖应用中,根据企业的本身特点想出很多玉,SI+IT部门支撑想玉过程中的数据模型工作,SI开始收服务支持费用了.

这样的模式,SI会觉得不爽吗,笑死都来不及.目前的BI模式,SI才会死掉, 永远收不到尾款,还老是免费提供一个人在里面.

后面的玉谁在引,只有业务部门,只要这个企业业务部门存在,他们自然会连续的引玉,SI和咨询专家是引不出玉,因为他们不懂业务人员的实际情况.

interstage

最初由 kinghq 发布
[B]

您说的这个事情我们也要面对。所谓价值链非常清晰，我觉得还在于我们的要求是否清晰，同时针对做的事情能否落实。两者缺一不可。

通过这里的讨论，我也有了一个落实的思路了，也就是刚才说的清晰业务-技术之间的接口。

这个对我来说正是需要直面的课题。 [/B]

业务-技术之间的接口,就是对分析角度的各自描述问题,就是NV中专利的"管理视点"技术. 我相信,你如果亲眼看到我的产品,基本能解决你直面的课题.

kinghq

业务-技术之间的接口，这个说法，我还要再琢磨一下：因为所谓接口就是前面说的简化处理的要义所在。

至于说的实施方法，一方面有了新思路，另一方面有了支持这一思路的工具，那么就可以去尝试一下了。起码POC DEMO就可以做起来了。这个，我自己也再琢磨琢磨。

interstage

最初由 kinghq 发布
[B]业务-技术之间的接口，这个说法，我还要再琢磨一下：因为所谓接口就是前面说的简化处理的要义所在。

至于说的实施方法，一方面有了新思路，另一方面有了支持这一思路的工具，那么就可以去尝试一下了。起码POC DEMO就可以做起来了。这个，我自己也再琢磨琢磨。 [/B]

呵呵,如果我的"持续改善的企业"理论你们企业老大能认可,我的"信息活用"分析方法你们的业务部门能支持,那我的"抛砖引玉"式BI实施方式,你们IT部门肯定支持.

呵呵,这些理论和方案是一环扣一环(都有文档的), 应该让你们满意.你看看,别人是靠关系买产品,我是靠整体solution卖产品,这个境界就不一样吧.

试问目前国内象我这样BI工具的销售人员,这样卖产品的不多吧.

interstage

最初由 duzhaoyi2000 发布
[B]

一点即中
这也许是很多BI项目失败的原因吧。。。
归根结底
还是因为中国人很爱面子
很多国人也不爱去刨根就地，这也是为什么信息技术核心领域我们没占什么阵地的原因
起步晚我承认，条件差我承认
但这总不能成为我们赶不上人家的借口

面子是要做好，但不能忽视核心的东西
否则只能是金玉其外，败絮其中了：） [/B]

呵呵,http://www.chinabi.net/blog/user1/105/archives/2007/1416.html

原来是你的博客,为什么转贴我的文章,不但不写转贴,而且该标题,叫什么:OLAP与报表工具契合的必要性.

做人太不厚道了吧.这种情况不是爱面子不爱面的问题.正如你所说的:面子是要做好，但不能忽视核心的东西. 核心的东西,是抄了的,对吗.

bq_wang

呵呵,欢迎大家继续讨论,不过注意一下不要有火药味啊!

bireport

炒做贴，鉴定完毕。
大家的回复都是认真的，除了interstage。
虽然炒做，私下认为对于interstage产品的知名度还是有好处的。