小谈决策表
Liu Qing
决策表是一种使用表的结构，精确而简洁描述复杂逻辑的方式。就像if-then-else和switch-case语句一样，将多个条件与这些条件满足后要执行的动作相对应。
Sammy Liao
MuSheng
On 2011-03-29 11:26, Liu Qing wrote:
前几天提 到詹姆斯泰勒关于决策管理的报告。后来发现他在那天稍晚一些时候发布了更多的文章，介绍他参与会议的其他一些观点和技术。其中， 可以发现不少好东西。这次会议 是OMG组织的。OMG， 是对象管理组织，我有些奇怪它怎么跟决策扯上关系了。这个组织的典型作品是UML和Corba，前者是一种用于软件分析和设计的表达语言，后者是一种面向对象的应用 架构标准。当然，他们还有其他作品，比如跟数据仓库相关的元数据标准CWM， 跟业务流程相关的BPMN。听起来，他们就是专门建立标准的，而这些标准 大多是一种表示层面的——为了建立一种共同的语言。而建立语言的目的，是为了自动化。这次，他们的主题是决策建模的符号表示法， 可以理解为准备进军决策自动化这个方向。目前还没有这样的标准，不过他们想插手了。于是，找来若干专家来分享各自的观点。也许在 不久的未来，他们就会一个标准出台。不过不要对这个标准抱有太大期望，因为据说OMG的 标准有一个显著的特性，就是又臭又长，操作起来十分困难。采用挺难，借鉴却是十分必要。在这次会 议上。除了詹姆斯谈到的决策管理之外，还有几个主题，我先来说说关键字吧——决策表（Decision Table）、KPI决策模型、业务规则管理、复杂事 件处理（CEP）、文本挖掘。
如果可 以，我们也可以在ttnn探讨一下这些技术。虽然我们没资格参加那种标准 的制定，不过可以提前设想一下那个标准会事什么样，甚至我们还可以设计出简单易行的表达法，在实践中尝试。气死他们。今儿个先 来看看决策表。决策表，Decision Table。在网上搜了一下，发现ibm网站有一篇文章， 是介绍基于决策表进行自动化测试的（看，又是自动化）。在互动百科上，也有相关文字介绍。其中提到：决策表是一种使用表的结构，精确而简洁描述复杂逻辑的 方式。就像if-then-else和switch-case语句一样，将多个条件与这些条件满足后要执行的动作相 对应。有点抽 象，来看一个典型的决策表（摘自Wikipedia 决策表词条），是一 个诊断打印机故障的决策表。
很简单 吧，这是一个。可以看到决策表主要有几部分构成：条件、行动和规则。规则即不同条件和行动的取值。上面打印机故障诊断是一个有限 入口（limited-entry）的决策表，确实是最简单的形式。在规 则中，条件判断只是yes或no， 而行动则是执行或不执行。还有复杂点的形式，叫扩展入口（Expand-entry） 决策表和混合型。扩展入口，是指条件采用变量来表示，在规则中，该变量可以有不同的取值，比如条件变量为arpu，在规则中可以包括<20,[20,50),[50,120),…而 在行动中，也可以针对某一类行动，有不同的取值，比如充值赠送，按照不同条件可以有30，50…去年我遇 到一个问题，当时要设计一种客户接触策略，当时我不知道有决策表，现在想象，发现这非常合适，简单整理一下（示例）。
也许有人 会有疑问：这些规则不是在程序里面都已经写了嘛，这只是换了一种表示方法而已。
我想这里 的区别就是，使用决策表可以让规则处于一种“可管理”状态。可管理，就可以检验规则的覆盖程度，检验规则的有效性，并且可以从一 个高层视图来看待业务逻辑。比如这里，你可以一目了然看到针对客户接触会有那些行动，有些行动根本不必要的，或者成本太高的，就 得做出选择。这就是可管理，而平常不可管理的状态，一个行动可能仅仅是停留在纸面上，或者是决策者的脑海里面。
值得注意 的是，决策表的应用场合大多还是针对操作型决策，因为那些决策是更需要被管理，更需要自动化的。比如客服前台的决策，比如精确营 销…针对目标客户，分成了ABCD四 个群体，每个群体根据客户等级的不同，推荐不同档次的资费包…
形式简 单，功能强大…我想以后我会在实践中使用的，如果有新的心得再与大家分 享。更多关于决策表的资源，给出几个链接。
Q
决策表看起来是个好东西，不过还可能有更好的。
昨个尝试用这个表达以前的一个实例，也发现个问题。
如果枚举所有的条件，决策表将非常庞大。对与受限型决策表，还好说，条件是简单是否值。三个条件，就是二的三次方，8条规则。但如果是扩展型决策表，一个条件可能有多个取值，比如arpu，可能会有5个分档；客户类型有4种；投诉类型有6类。那么，总共规则数=5×4×6=120条。那这个决策表基本上没法看，跟hard code没太大区别。因此我想，决策表的构建应当有一些原则，这些原则能够便于决策表中决策的执行和管理。
条件过多、行动过多，必定导致规则过多。这不符合现实情况，现实情况的规则必定是非常简单，因为要符合执行者的理解力和执行力，过于负责必将不被执行。让决策表有效应用，必须要保持单个决策表的轻量级。
对于一个决策者，一个执行团队，他面对的可能的行动并不多。只不过在一个企业里面，决策者和执行团队的数量很多，才累积成为复杂剪不断理还乱的情况。
因此，可以针对每一个团队所开展的某一类事务设计一个决策表。当一类决策贯穿企业高层和执行层是，就可以形成一个决策表链。高层决策表的行动，对应到一个细化决策表。比如对于总的客户接触决策表，这是面向公司客服部门的策略制定者，他们关注是否每一种客户都覆盖住了，能保证在固定周期里面会被关注，重点客户重点关注，每种类型的接触是否都有所处理了 。但对于客服下面，有个投诉处理团队，他们并不太关注营销接触分成几类，他们更关注是否不同类型的投诉有适当的处理办法，那是他们的工作。因此，如果有必要，在客户接触决策表中，将会有一项接触行动，叫“投诉处理”，连接到一个细化的投诉接触决策表，其中对投诉分成几类，形成不同的规则和行动。
最终在一个企业里面，针对不同的事务流程，将会形成相应的决策表链。生产链、保障链、销售链…每条链中，每个决策表面向不同的角色。不过这说起来有点理想化，确实，没经过实践证明也不好说。
wind wail
On Mar 29, 5:55 pm, Q <happys...@gmail.com> wrote:
> 决策表看起来是个好东西，不过还可能有更好的。
>
> 昨个尝试用这个表达以前的一个实例，也发现个问题。
>
> 如果枚举所有的条件，决策表将非常庞大。对与受限型决策表，还好说，条件是简单是否值。三个条件，就是二的三次方，8
> 条规则。但如果是扩展型决策表，一个条件可能有多个取值，比如arpu，可能会有5个分档；客户类型有4种；投诉类型有6类。那么，总共规则数=5×4×
> 6=120条。那这个决策表基本上没法看，跟hard code没太大区别。因此我想，决策表的构建应当有一些原则，这些原则能够便于决策表中决策的执行和管理。
>
> 条件过多、行动过多，必定导致规则过多。这不符合现实情况，现实情况的规则必定是非常简单，因为要符合执行者的理解力和执行力，过于负责必将不被执行。让决策表-有效应用，必须要保持单个决策表的轻量级。
>
> 对于一个决策者，一个执行团队，他面对的可能的行动并不多。只不过在一个企业里面，决策者和执行团队的数量很多，才累积成为复杂剪不断理还乱的情况。
>
> 因此，可以针对每一个团队所开展的某一类事务设计一个决策表。当一类决策贯穿企业高层和执行层是，就可以形成一个决策表链。高层决策表的行动，对应到一个细化决-策表。比如对于总的客户接触决策表，这是面向公司客服部门的策略制定者，他们关注是否每一种客户都覆盖住了，能保证在固定周期里面会被关注，重点客户重点关注，-每种类型的接触是否都有所处理了
> 。但对于客服下面，有个投诉处理团队，他们并不太关注营销接触分成几类，他们更关注是否不同类型的投诉有适当的处理办法，那是他们的工作。因此，如果有必要，在-客户接触决策表中，将会有一项接触行动，叫"投诉处理"，连接到一个细化的投诉接触决策表，其中对投诉分成几类，形成不同的规则和行动。
>
> 最终在一个企业里面，针对不同的事务流程，将会形成相应的决策表链。生产链、保障链、销售链...每条链中，每个决策表面向不同的角色。不过这说起来有点理想化，确-实，没经过实践证明也不好说。
Q
你说的评估是什么意思？具体说说。
Q
上次提到omg决策模型表示法会议有几个关键词，其中一个是KPI决策模型。我没有细看那片介绍文章，或者说已经抱有一个固定思维，将这个所谓“KPI决策模型”理解成为——基于KPI指标驱动的决策模型。可仔细一看，不对，这里的KPI跟我们常说的KPI，关键绩效指标，一点关系没有。这里的KPI是一家咨询公司的名字，叫做Knowledge Parteners International。真是误会大了（然而我想，既然这家公司使用了这样一个容易让人误解的名词，是否在这个名称背后多少隐藏了一点跟绩效指标相关的寓意？）！
这家公司提供的正是决策模型的咨询服务。他们称决策模型，正是对业务逻辑的抽象。Business Logic，在他们这里成了一个术语，代替了Business Rules这个术语。而且他们为BL带来一个定义，并作为其理论基础——业务逻辑就是，从业务事实到业务结论的推导，事实à结论。所以，一条“业务逻辑”可以表达成“当…那么…”,或者“如果…那么…”。
KPI决策模型将基于这个定义，对企业全盘的业务流程进行抽象，采用一种形式化的表示方法来表达这些逻辑。这种方法跟决策表其实有点类似，只不过一些术语不同，更加严谨，更加系统化一点吧。在他们这个体系里面，使用不少很专业的术语，诸如Fact、Assertion、Domain、Operator…。来理解一下。
Fact，事实。是指某种上下文中的信息片段（太抽象了），比如“某人已有五年工作年限“。由此，Fact可以由Fact Type，Business Concept和Fact Type Domain构成。在这个例子里面，工作年限是Fact type，某人，就是Business Concept，Fact Type Domain是工作年限的取值范围，这里是五年。Assertion，断言，就是事实陈述，由Fact Type，Operator和Oprand构成。“某人的工作履历很差劲”，其实就是“某人的工作履历”（FT） - “是”（Operator ）-“差劲的”（Oprand）。这里，Operator可以是常见的逻辑判断，是、不是、少于、大于、早于；Oprand，可以是前面说的Fact Type Domain值，也可以是公式计算，也可以是某个其他Fact Type，比如“交款日期-晚于-账单日期”。
一条业务逻辑，进一步用这些术语就可以说是：条件断言 à 结论断言。
于是就有了原子业务逻辑（Atomic BL Statement），所谓原子，当然就是不可在分的意思。Atomic BL有如下特征：
· 由0个或多个条件组成；
· 导致只有单一Fact Type的结论；
· 每个条件是原子的逻辑表示式，只有一个原子Fact Type；
· 条件之间只是AND的关系，没有OR的关系；
参见附件图。这里值得注意的就是导出一个单一Fact Type结论。其实可以看出，这个原子业务逻辑跟决策表中纵向的规则很类似，条件对应条件，而此处的结论对应那里的行动（Action）。只不过，原子业务逻辑中特别强调只能是到处一个Fact Type，而决策表中，可以多有个行动。
针对结论中Fact Type的不同取值，将若干条原子业务逻辑组合起来，就形成了Rule Family。在RF中，使用相同条件Fact Type的（但取值不同的），称之为一条Rule Pattern。
如此，对每个结论的推导，都有一系列原子业务逻辑构成，形成一个Rule Family。而如果一个RF，其结论的Fact Type作为另一个Rule Family的条件，那么就可以将两个RF串接起来。最终构成一个完整的决策模型。并且KPI也有一套符号表示法来表达这种决策模型，有点类似UML风格的那种。
最后，他们也给出对企业业务流程构建决策模型的方法论：解、范、析、组、连。
· 解，分解，Decompose，将业务逻辑分解成原子形式，让每个业务逻辑互不干扰；
· 范，范式化，确保每个业务逻辑片段在企业里面位于唯一而恰当的地方；
· 析，分析，确保业务逻辑推导完整性和业务完整性；
· 组，组合，让业务逻辑可重用，便于理解和利于SOA架构；
· 连，连接，将业务逻辑组跟业务流程连接起来，去除传统描述型的业务逻辑；
总体看上去跟决策表类似，特别就是那个Rule Family。只不过后者是把决策表横过来放，而且规定，只有一个行动。我想他们这么做是为了更严谨，更形式化，更容易自动化。但不可否认，概念太复杂了。光上面那些概念，害得我看了好久，而要想将它们解释明白，恐怕也有一种沉重的压力感而让听众害怕。
有兴趣的童鞋可以去他们网站下载一些资料看看。
