另一种解决未来问题的设想

丁西宁 20061207

innovate511老兄说的问题的起源是前段时间在向一个合作伙伴推销essbase产品时提出的。我们在税务行业一直与他们合作，开发一个面向税务行业的数据分析利用产品，所以经常在业务需求、技术架构上进行交流。

在交流中提出是否有现成的产品可以支持动态建模。动态建模就是指当业务需求或者分析角度发生变化时，业务人员可以自己通过一个可视化的界面修改模型（逻辑模型），然后后台的工具自动根据模型的变化来组织、抽取数据到物理的模型中，如果使用了essbase产品的话，后台工具还应该自动更新或者生成新的多维数据库。这时候前端的业务分析人员就可以通过数据展现工具来分析数据。 这个设想来源于对BI项目的理解。因为现在很多BI项目，项目需求的好坏决定了BI项目最后的结果，因为虽然需求的确定同时也把人的思维固化下来了，固化在将要实现的软件中。为什么人们总是把项目失败的原因归咎于需求不明？为什么需求阶段组织了那么多业务人员面壁了那么长时间的需求经不起时间的考验？哪怕一年。为什么我们总是说客户自己没有想法，需要实施方去忽悠去引导客户？

很多BI项目在交付使用后，很快就无人光顾。如果你开一饭馆，开张不久就没人来吃饭，总得分析一下原因吧。是菜不好吃，太贵，服务员不漂亮，还是外面有个臭水沟？来这吃饭总得图一样吧。浏览BI系统就像逛超市，总是不卖我想要的商品，总是不做促销做宣传，有谁还去逛！
 
不说没用的了。BI项目中变化的因素主要有两种：
1 需求。就像庆兄说的，预知总有个限度，除非神。既然只有神才知道，我们就不用操心了。
2 思维。具体就是指考虑问题的方法、角度、深度、广度、灵活度。为了解决用户思维的多样性，BO有个概念叫语义层，提供即席查询的能力，让用户可以自己来选择看问题的角度、深度。但是它不能提供灵活度，你所能选择维度和数据范围是固定的，是在设计时就固定下来的，所以其实只是一个有限制的灵活。

由于这两个原因，我们无法满足用户的要求，就像我们无法满足人民对生活水平日益增长的要求一样。

我们想一下需求变化的流程：
1需求变化->2业务模型变化->3数据准备->4生成新的可以操作的物理模型->5用户操作

我们不管需求了，只考虑后面的步骤。
2业务模型变化：通过统一的元数据管理、借助可视化的建模工具，可以让用户自己根据需求来建模。
3数据准备：还是通过统一的元数据管理、自动化的ETL程序，可以让系统自动为新模型准备数据。
4生成新的可以操作的物理模型：可以是关系型的，也可以是OLAP的。essbase工具自己就提供导入程序来自动更新数据到cube中。
5用户操作：这时用户就可以通过数据展现工具来看了。

从步骤需求开始变化到数据展现，用户自己是唯一的参与者。所以解决的根本方法，还是靠用户自己！
  
icbc2005 20061207

想到了程序中常提供的一种功能叫"模版定制"，在一致性维度，一致性事实下我觉得也不是没有可能，用户可以用维度和事实来创建自己的业务模型，然后用这个模型去产生数据（比如生成新的度量），最后展现！
  
Kevin(C) 20061208

这样对用户的要求会不会太高了。
越灵活的东西操作好像会越复杂，
越复杂的东西推广度就。。
  
Qing 20061208

同意！

用于研究问题的工具，复杂一点是应该的，因为要不断尝试新的方法。
而用于生产的工具，一定要简洁，不要让操作者太动脑子。

前者如OLAP、挖掘工具，后者如KPI、一套管理流程。
  
丁西宁 20061208

两者应该是相互矛盾的，不管偏袒某一方，都要面对客户是否满意的问题。

数据分析利用是一个很广泛的话题，它应该渗透到客户业务中的方方面面。数据分析利用可以适应到不同类型的业务当中去：
比如：KPI，根据KPI的思想可以实现诸如业务流程监控、绩效考核等业务，这类业务属于流程类，通过监控各种指标来掌握业务行为的质量，从而最终达到优化流程的目的。在这类业务中，变化的是考核指标；流程类的特点是用户按照流程来办事，不用动太多脑筋。

再比如：税务行业中的纳税评估，银行系统的反欺诈，以及电信行业的客户流失分析，这类业务属于模型类，通过定义不同的模型（模型代表不同的分析方法，一般来说比较复杂）来找出被分析对象的异常行为，从而最终达到规范客户行为的目的。在这类业务中，变化的分析问题的方法，是模型；流程类的特点是用户需要不停的修改模型，需要更多人脑参与。

这两类不同的业务在实现中应该区别对待，把用在流程类的方法用在模型类，就会导致客户体验问题。

兰德里尼  20061220

丁兄说的问题其实也是一直在困惑着我的问题，所以较有感触。
不过我觉得BI项目目前看到的最终展示似乎离不开报表，做得好点有可能用户可以自由设计报表，类似BENQ的Analyzer2005。
但是始终有一点难以解决的就是所谓的自由设计后台实际上是处理好的不自由的CUBE。
如果数据源也开放了，就如BO所谓的语义层把数据库直接向用户开放，得到的似乎更多的是用户的茫然。
所以我觉得作为自由与固定主要考虑的是一个度的问题，究竟应该开放哪些，在多大程度上开放，业界似乎没有定论，大多项目也是按照固有的模式进行。
讲到这里我想把SPSS纳入进来，作一个对比，SPSS是一个纯统计分析的软件，非常专业，但一般不会用到BI项目，
同样很多专业的数据挖掘软件也很难直接用到ＢＩ项目里，问题出在哪里？
因为分析没有定式，很难有一套放之四海皆准分析思路可以被固化，可以被反复应用到不同项目中去，
这也许是BI的魅力所在，也是我们这群人存在的一个理由。
说到这里似乎进入了死胡同,但是我产生了一个委屈求全的方法:
也就是在自由与固定之间寻求平衡点.通俗的说就是可以建立一个个的规则模型,
定义好标准的I/O接口,每个规则应该被高度抽象,可以在一定程度上应对一些环境的改变,
然后要做的就是用这些规则模快去搭建不同的业务流.随需而变是由业务流来适应的,
不同的业务流使用不同的环境需求,不变的是规则.我们要做的就是抽象规则,设计规则,
给规则不同的选项.这样做的原理就是我把业务分解成相当细的一些原子,
然后给与用户搭建组合的权限,这就是我所说的度.
如果可行的话,BI项目的工作模式也许会有一个新的突破,呵呵.
我正在尝试,所以可能还有很多没有想明白的地方,希望各位能够多提宝贵意见
  
Qing  20061221

有即是无
一切皆有可能变成了一切都没可能

为什么报表这种形式的分析结果流传更广泛？因为简单。而对于OLAP、语义层、挖掘工具，确实他们能够千变万化，可也正合了"有即是无"的道理。

阿兰兄提出要对现有的分析思路进行高度抽象，是非常不错的想法。其实，这也是ttnn中讨论一直在进行的，要抽象，必须得现有具象的存在。所以，这里通常有对某项分析工作的思路总结，希望能够在某个时候，能够抽象出一些东东，大家共同努力吧。

以前提出过"分析流"的概念，倒是跟"业务流"有个对比。后者是操作的流程，前者是决策的流程，我想BI应该还是集中在前者的抽象上。明确需要解决的问题域，分别可以用什么方法实现。如果能够将这些问题搞清楚，功莫大焉。不过你说要展开进一步讨论，我不是非常明白要讨论什么问题。倒不如抛出一个实际的案例，介绍自己的分析思路，这样大家才有话要说嘛。

兰德里尼  20061221

庆兄（呵呵，大家似乎都要先客气一下）说的分析流我在以前您的贴子里有所了解，感觉分析流是比业务流更加抽象的东西，就比如一些算法，分类聚类，异常值探测之类的，这些东西我觉得源自于项目或者实践，但是最终收获于学院派，他们最终把这些东东理论化，升华了，最后被一些工具类公司所产品化.所以感觉分析流似乎更难一些。

至于业务流，我觉得可以这样来解释，就比如说：我要选择有问题的客户，那么不同的部门会有不同的筛选原则，但是其中也会有相同的原则，我们如果针对每个部门甚至每个人都取来制定一张报表（甚至是一个界面，连带业务的进一步动作）那么可能会很麻烦，其实仔细想想大家选择的方法（也就是我所谓的原则）实际上就那么几种，只不过是不同的组合而已，或者是改变某些参数而已。那么我们为什么不做一个类似搭积木的界面呢？也就是提供给他们自己组建属于自己特点的业务流呢？

从这一点来看分析流应该说是属于更底层的东东，我觉得搞BI的似乎没有太多必要去搞这些算法之类的东西。我说的业务流有其局限性，适用于某一业务领域，但是这也正是它优势的地方，如果做得好，就可以可复制，具备了产品化的一个重要特征了，呵呵。

我觉得我所说的业务流这种理念可能没有什么技术含量，但是它与以往的BI设计理念毕竟发生了些许变化。

呵呵，请庆兄及其他大大们指正。

Qing  20061222

怎么是酱紫讲呢？不认同阿兰对"分析流"的感觉。

其实开始提到分析流的想法，是为了说明如何将"分析思路"固化的问题。那些算法，都是分析方法层面的，确实是学院派在研究的课题。分析思路还是一种对这些方法的组装，面对一个业务问题，首先弄明白这是它是什么类型，然后可以指导分析者，从哪几个方面入手来观察这个分析对象，当观察到一些有意思的、奇怪的现象之后，能够针对这些现象的不同，自动分析得到一些分析结论。这就需要一些分析方法，比如挖掘的支持了，但显然，它们还是隐藏在后头。

因此，所谓分析流，不是算法。算法是科学的、严谨的，而分析流是对人们思维的抽象，人们分析问题的思维受经验、文化、行业不同所影响。但这种思维必定还是有一些相同的模式。如果上面这段觉得太过含糊，请不要介意，因为我也不知道这个叫做"分析流"的东西，到底是啥样，只是知道，它不是数据挖掘，不是算法。

而此处提到的"业务流"，从阿兰的叙述中，我找到一种比较相似的东西。在我们项目里面，有一块叫做营销管理平台，其中一块功能就是客户细分，然后自助地选择客户名单，进行相应的外呼活动。可以参见
http://groups.google.com/group/ttnn/browse_thread/thread/b5c031de3859a8fc/8263a7a7894370a8

实现这个功能的主要基础还是客户细分，从价值、客户身份、业务构成等若干方面进行分类，比如价值可以划分高、中、低，也可以根据话费分成10个档次。当进行一项"xx业务推荐"的外呼活动时，可以只是在界面上打打勾，就可以选择出中高端客户、尚未办理xx业务的、手机支持xx功能的客户群。

不过，这个系统目前看起来已经有成为生产系统的趋势，因为要融入平常的业务当中，每天都要做。因此，我都怀疑，这个操作型系统是否还属于BI的范畴。虽然后台的数据整合，客户细分还算作此范畴。

微信扫一扫实时了解行业动态

微信扫一扫分享本文给好友