一种可操作的分析方法论

[Qing]

hunter最近一系列的帖子给我们介绍了他的挖掘实战，在昨天的回复里面，在他的话题里面提到了关于做出假设的问题，后来我发现，其实这可以引申成为关于分析方法论的话题。

 

结合我们自己的项目（我们是一个数据挖掘项目），因此，这里向提出一个可以用于挖掘项目的方法论。

 

挖掘的方法论其实已经有了，有sas的semma和几个公司联合提出的crisp-dm，前者，注重挖掘建模的过程，后者将对业务问题的定义也纳入其中。本文更有点像是对后者的一种细化，所以，并没有称之为挖掘方法论，而是成为"分析方法论"，是指利用挖掘（甚至可以是不用挖掘）技术来分析业务问题的方法论。这也不一定是一个完整的方法论，而是希望能够有一个比较可以真正操作的方法论。

 

重点是提出更容易"操作"的，因为在crisp-dm里面，虽然提出要定义业务问题，但对于如何定义业务问题，并没有说。这个难题也在我们项目里面存在。

 

在我们内部，有做业务分析的，有做挖掘技术的，但他们之间如何协调工作是个难题。很惭愧，对于搞业务分析的，你很难去将客户的疑问转换成一种是明确定义的需求，而挖掘技术人员更偏向于是从数据中找到规律，而这是什么规律，并不明白。这对我们应用的效果有很大影响，经常性，我们的模型给不出任何结论，或者给出一些大家都知道的结论。但这也不完全是他们的问题，因为在业务问题定义方面，可能是一句模糊的说法，比如"需要对客户进行分类"，或者是离挖掘建模比较远，比如"要将收入提升5%"。这种目标要不就不能真的从业务指导建模或者目标不能完全由分析建模达成。

 

这是一个长久存在的问题，在我们这里，至少三年了。没解决。

 

在上次跟hunter的讨论中，无意提到了基于假设的证实和证伪过程来满足他们客户的需求。我觉得这是一个可以解决上面问题的一个模式：

 

假设 → 证实或证伪

 

要开会了，下次再说。

[raullew]

开放挖掘人员直接和需求方谈需求的权利，就解决了

On Jul 8, 2:09 pm, Qing <happys...@gmail.com> wrote:
> hunter最近一系列的帖子给我们介绍了他的挖掘实战，在昨天的回复里面，在他的话题里面提到了关于做出假设的问题，后来我发现，其实这可以引申成为关于分析-方法论的话题。
>
> 结合我们自己的项目（我们是一个数据挖掘项目），因此，这里向提出一个可以用于挖掘项目的方法论。
>
> 挖掘的方法论其实已经有了，有sas的semma和几个公司联合提出的crisp-dm，前者，注重挖掘建模的过程，后者将对业务问题的定义也纳入其中。本文更-有点像是对后者的一种细化，所以，并没有称之为挖掘方法论，而是成为"分析方法论"，是指利用挖掘（甚至可以是不用挖掘）技术来分析业务问题的方法论。这也不一-定是一个完整的方法论，而是希望能够有一个比较可以真正操作的方法论。

>
> 重点是提出更容易"操作"的，因为在crisp-dm里面，虽然提出要定义业务问题，但对于如何定义业务问题，并没有说。这个难题也在我们项目里面存在。
>

> 在我们内部，有做业务分析的，有做挖掘技术的，但他们之间如何协调工作是个难题。很惭愧，对于搞业务分析的，你很难去将客户的疑问转换成一种是明确定义的需求，-而挖掘技术人员更偏向于是从数据中找到规律，而这是什么规律，并不明白。这对我们应用的效果有很大影响，经常性，我们的模型给不出任何结论，或者给出一些大家都-知道的结论。但这也不完全是他们的问题，因为在业务问题定义方面，可能是一句模糊的说法，比如"需要对客户进行分类"，或者是离挖掘建模比较远，比如"要将收入-提升5%"。这种目标要不就不能真的从业务指导建模或者目标不能完全由分析建模达成。

>
> 这是一个长久存在的问题，在我们这里，至少三年了。没解决。
>
> 在上次跟hunter的讨论中，无意提到了基于假设的证实和证伪过程来满足他们客户的需求。我觉得这是一个可以解决上面问题的一个模式：
>

> *假设 → 证实或证伪*
>
> 要开会了，下次再说。

[Qing]

你这招在哪儿有什么成功案例吗？还是自己就这么一感觉？让技术人员直接面对需求方可能是一种解决方案，可以算得上是从激励角度来让需求更加清晰，但肯定只是有这个权利肯定不行。因为如果这样，我们这里早就解决问题了。

 

这次要说的这个分析方法论其实是想寻求一种需求方跟分析方的交互方式。其实不论谁来充当这个需求方，是客户自己，还是业务顾问角色，或者挖掘人员自己，都需要将分析的需求表达出来。这里谈的暂时还不是激励问题，如果要谈这个，那话题要广的多了：一个团队得有共同的价值观...得有足够的激励让大家朝同一目标前进...每个人的专业定位...

2008/7/8 raullew <rau...@hotmail.com>:

开放挖掘人员直接和需求方谈需求的权利，就解决了
...

[笨笨]

Qing这个问题说到点子上了，我也确实有这样的困惑，尤其是面对没有成熟解决方案的行业的时候，问题尤为凸显。
但是我个人认为，对于成熟行业，尤其金融、电信、零售等等，情况相对好些，分析主题其实都有现成的，关键还是看怎么去引导客户。就比如金融行业，由于
Basel资本协定的需求，现在可能大家都在关注信用评分这个点，成熟、现成的实现技术都是有的，用户也是需要的。实施起来，更多的可能是商务上的因素
在主导。
问题的关键，我觉得还是归结为是否有成熟的解决方案。

On 7月8日, 下午2时09分, Qing <happys...@gmail.com> wrote:
> hunter最近一系列的帖子给我们介绍了他的挖掘实战，在昨天的回复里面，在他的话题里面提到了关于做出假设的问题，后来我发现，其实这可以引申成为关于分析-方法论的话题。
>

> 结合我们自己的项目（我们是一个数据挖掘项目），因此，这里向提出一个可以用于挖掘项目的方法论。
>
> 挖掘的方法论其实已经有了，有sas的semma和几个公司联合提出的crisp-dm，前者，注重挖掘建模的过程，后者将对业务问题的定义也纳入其中。本文更-有点像是对后者的一种细化，所以，并没有称之为挖掘方法论，而是成为"分析方法论"，是指利用挖掘（甚至可以是不用挖掘）技术来分析业务问题的方法论。这也不一-定是一个完整的方法论，而是希望能够有一个比较可以真正操作的方法论。

>
> 重点是提出更容易"操作"的，因为在crisp-dm里面，虽然提出要定义业务问题，但对于如何定义业务问题，并没有说。这个难题也在我们项目里面存在。
>

> 在我们内部，有做业务分析的，有做挖掘技术的，但他们之间如何协调工作是个难题。很惭愧，对于搞业务分析的，你很难去将客户的疑问转换成一种是明确定义的需求，-而挖掘技术人员更偏向于是从数据中找到规律，而这是什么规律，并不明白。这对我们应用的效果有很大影响，经常性，我们的模型给不出任何结论，或者给出一些大家都-知道的结论。但这也不完全是他们的问题，因为在业务问题定义方面，可能是一句模糊的说法，比如"需要对客户进行分类"，或者是离挖掘建模比较远，比如"要将收入-提升5%"。这种目标要不就不能真的从业务指导建模或者目标不能完全由分析建模达成。

>
> 这是一个长久存在的问题，在我们这里，至少三年了。没解决。
>
> 在上次跟hunter的讨论中，无意提到了基于假设的证实和证伪过程来满足他们客户的需求。我觉得这是一个可以解决上面问题的一个模式：
>

> *假设 → 证实或证伪*
>
> 要开会了，下次再说。

[Steven]

Qing办了件实事，如何定义业务问题，确实还缺少一个标准和原则，大多数情况下业务人员或者业务分析人员给出的定义都是高度概括的，含糊的，不明就理的，或者都没深入下去定义需求是怎么得来的等，这时候我们需要定义一个原则或者规则，在定义业务问题的时候按这个原则办事，比如smart原则，否则让技术人员参照一句话去实现业务分析确实有难度

 

 

2008-07-09

---

Steven

---

发件人： 笨笨

发送时间： 2008-07-09  10:59:44

收件人： ttnn BI 观点

抄送：

主题： Re: 一种可操作的分析方法论

[Qing]

如果是有成熟的解决方案，那肯定是解决一个明确的业务问题。可是在具体工作里面，"问题"并不明确的。比如说定价问题可能有一个比较成熟的解决方案，但有时候现实中的问题还是难以抽象到这个问题里面。

 

因为"问题"不清楚，我们经常是提供了正确的"答案"，可惜却回答了错误的问题。这事儿很尴尬。

 

需求方是定义"问题"的，分析方是提供"答案"的。

 

看大家这么说，一开始我还有些怀疑我是不是将这个题目搞大，所谓"分析方法论"是个空洞的题目，其实想说的仅仅是如何定义分析需求的业务问题。但后来想想，其实我想说的还不止这个。待会儿再来说说，昨天被中断，吃完饭继续。

2008/7/9 笨笨 caozh...@gmail.com:

...
但是我个人认为，对于成熟行业，尤其金融、电信、零售等等，情况相对好些，分析主题其实都有现成的...问题的关键，我觉得还是归结为是否有成熟的解决方案。

...

[Qing]

昨天提出了一种可操作的方法论，用"假设"来定义问题，而用证实或证伪来提供答案。我想这是比较具体，容易操作。比仅仅是"定义业务问题"这个说法要实在一点。其实我们在做需求分析的时候，也做过很多假设，但一般"仅供参考"，挖掘、分析并非以为为目标，而是以发现有趣的东西为目标，或者仅仅是为了达到一个lift值为目标。这就是因为大家多业务问题的理解不一。

 

大家可以看到这种基于假设的定义问题的方法有个问题——看上去并不能发现新的模式。因为假设是一种限制，限制分析的思路，这似乎并不符合常见的挖掘方法（扔进很多东西，保不准能发现一些东西）。这个问题待会儿再说，先来说说这种方法的好处。

 

基于假设，其实就是从业务出发引导分析，这比我们喊"业务指导技术"的口号要实际。依据假设去分析，有个好处，不至于是得出跟业务感觉不相干的结论。对假设的证实和证伪，容易形成比较稳定的业务规则，可以累积下去，形成知识库。

 

当然，假设的提出并不能完全凭空去想象，会随着数据的不断探索会有更深入更实际的假设。假设的提出需要业务想象力，需要感觉。这能够回到刚才那个问题，假设限制了分析思路。如果我们的分析过程是迭代的，就会不断产生新的假设。可以这么说——所有的分析都是基于假设的，你扔进去什么变量，定义什么目标，这些都是假设。只是，也许我们平常并没有将它们严格定义出来，当回事儿，甚至将一个可能并不成立的前提假设当成是真的。迭代分析过程是符合人们认识世界的习惯的，人不可能一下子就能够完全认识一件事情，一开始可能模模糊糊，可以给出一种很粗浅的假设。比如对群人的判断，"这些人大部分人都是男的"，验证这点可能不难。在验证过程中，你对这群人了解更深了，可能又做出一个判断，"这群人估计有八成都是外地人。"

 

假设的提出并不只是让需求方提出，而是需要需求方跟分析方一起迭代提出。最初的提出可以是需求方（这里，我用需求方跟分析方来代替我们项目组里面的业务和挖掘的角色）。从技巧上，做假设的时候，对一些把握比较大的，或者是跟最终业务目标关系不大的，可以根本不做，可以将把握大的当真（也可以专门去证实或者证伪，如果这是一个非常普遍的假设的话）。如何选择做出什么假设，这确实不是技术问题，还是跟业务感觉有关系。但人们往往过于相信自己的判断，通常会将没有验证的假设当作真实前提，这是需要注意的。

 

有时候业务感觉虽然直白，但并不愚蠢。如果分析模型得出的结论看上去好像否定了业务感觉的规则，这时候先不要洋洋自得，因为很大可能是分析模型基于了错误的数据，或者将目标定义错误（分析了错误的问题），或者是依据的变量不能代表真正的业务含义。所以，并不能证伪这个假设。

 

用假设来表达业务问题，并且在分析过程中不断继续深入假设来完善业务问题。这是谈如何"定义问题"。

 

接着是如何"回答"，就是证实和证伪。完全地证实或者证伪不容易，但也许可以给出一个置信度。这个假设有多大把握是成立的，当存在这种情况下，其实就有继续分析下去的必要，可以继续补充这个假设，加上一些前提。比如"在xx情况下，会怎样"，或者"在yy情况下，不会怎样"。不过通常，如果有项目进度的压力的话，如果已经能够有较大把握证实或者证伪这个假设，就已经足够了。分析这种东西，追求完美是没有尽头的。

 

这个方法论我觉得比单纯谈sas的semma方法论，或者是crispdm的闭环方法论要现实一点，虽然不可避免地会牺牲一些东西。但在我们平常应用当中，分析一样东西，不能漫无目的地区寻找，必须得有个目标。

 

举个例子，那电信业传统的离网预警模型，如果不做假设，可能我们这样定义业务问题，"寻找最有可能离网的客户"，面对这个问题，然后需求里面给出一堆建议分析的维度。然后分析者确立目标，构建模型，扔了成百上千个变量，也许是一个逻辑回归模型，最后得出lift很高，模型建完了，对所有客户进行打分，得到他们可能离网的概率，高的就容易离网，低的不容易离。但为什么有的容易离有的不容易离呢？去解读这个模型吧，对不起，这种模型不能简单地解释，所以也得不出什么稳定的业务知识。换个做法，在定义需求的时候，除了那句"寻找最可能离网的客户"，进一步作出最初始的假设：
1、 假设离网用户在离网前的三个月，或六个月里面，会有规律性的行为。
2、 假设这些行为主要体现在消费降低、呼转等等方面。
3、 假设，在通信行为上，长途、漫游行为的降低尤为明显。
4、 假设对于全球通跟智能网的高端和中端是有区别的，主要区别在于下降的幅度上面；
5、 …

 

如果能够回答这些问题，这将是一个好的模型，能够让人眼前发亮，能够共享，能够累积业务知识。

 

所有的假设很难在一开始就做出，而是在数据探索过程里面，一点一点发现，也许第四条假设是在一开始做出的。这就要求我们改变以往的做法，要迭代式进行分析，而不是一次性建立模型，得出模型评估结论。那样，根本没有时间来修正，来进一步提出新的假设。可以规定一个最少迭代次数，比如两次，我想这都会比假设问题已经定义清楚，一次性建模的方法要好。

 

假设 → 证实或证伪
 ↑__________|

 

好了，我在总结一下上面所说的，主要是三点：

1、用假设来定义问题；

2、用证实或者证伪来回答问题；

3、这是一个迭代过程；

 

除此之外，还有很多没有考虑清楚。比如如何做假设，是否有一些基本的假设形式？我想"如果..那么.."的形式是最基本的，如果给出了假设的前提，那么给出假设，一般来说，每个假设都有自己的前提，忽略前提的真伪，本身这个假设就不完善。但这个问题我并没有想明白，需要实践中摸索一番，也许在逻辑学那里能够找到一些答案。而至于证实、证伪，如果做到，我想在分析领域，主要还是归纳的方法，从高概率事件归纳得出规律。在方法上，似乎还有个证伪主义，不知道会不会有用。

 

我也意识到一点，虽然我说这种方法论是可操作性的，但其实也存在一些操作性的问题。比如分析方参与业务问题的定义，这现实么？从漫无目的在数据里面寻找，到依据主观假设来寻找，观念的转变很容易么？做假设需要业务感觉，需要经验，但如果这样的人缺位，是不是同样会流于形式，只是炮制出一堆空洞的假设呢？

 

这些问题应该会存在的，不过需要实践和时间去验证。不过我很相信这种方法论要比一直以来我们自己做分析的过程要有进步。

2008/7/8 Qing happ...@gmail.com:

... 

假设 → 证实或证伪

 ...