决策表实践有感

[Qing Liu]

之前我们曾经探讨过决策表这个东西，Decision Table。它可以看做是一种将条件、行动串联成规则的“规则引擎”。这种技术已经具备几十年历史，目前基本被划分在EDM（企业决策管理）的范畴，跟它相似的东西比如还有CEP（复合时间处理）。

最近，我做了一些决策表实践。对客户的某项流程设计了一系列决策表。发现——决策表的形式简单，然而要让它运转起来，却不那么容易。

开始提出这个概念，同事觉得有些陌生，你又在玩概念了？…这跟以前搞的xx矩阵不是一样的吗？…这不就是一个规则库吗？…我说，这不是我提出的概念，另外，决策表也不仅仅是概念，而是有实际的表现形式和工具…我试图用决策表来串联决策层和执行层的脱节。决策的下达上传，从战术到执行的决策，大多是模糊不确定的，战略的咱就没打算放在决策表里面。领导一个想法，下面人忙活半天。决策层无法跟踪自己的决策，甚至无法看到自己做过的决策。而决策表，则起到这样一种粘合作用，将模糊的决策都形式化表达出来。

可首先碰到的第一个问题就是——其实战术层决策也基本是模糊的。如果无法它本身就不清晰，那么决策表也只是记录了一种形式，而无法真正运行。比如决策层希望分析人员分析指标的下降原因，可以算是一种战术决策。或者，希望营销策划人员针对低端市场做一些工作。具体什么工作他不管，由营销策划者去做决策。如此，分析指标原因，发起营销活动，这两个是行动，而条件则是什么呢？用指标下降xx%来触发分析行动？以客户群的某某指标不达标来触发针对客户群的营销活动？这过于理想化了，现实不是这样的，我想就算是决策者自己也无法说出来他为什么要那样决定（也许他是觉得分析人员没事儿干，给他找点事？）。

决策表是自动化运行的，必须得去掉那些模糊性，而当现实中的决策本身就是模糊的，而你也无法将它们去除，也许那根本就不适用决策表。

但至少在执行层决策上，决策表是有用武之地的。因为越往下层的决策，其模糊性越小。

比如，不同客户群每个月最少接触多少次，最多接触多少次，这种规则定下来就需要严格执行。

其实你说这种决策是执行层还是战术层呢？似乎也没有明显界限。但对比下面两个描述：
1、当xx指标下降15%，那么发起xx指标分析任务；
2、当客户群=VIP，那么月最少接触次数=1；

很明显，规则2的可操作性要强于1，只能说规则1在规则2的上游，越靠近上游的决策，模糊性越强，越难以用决策表表达。

越下游的决策越具体，越可以用决策表来表达。然而第二个问题也来了。

决策、规则，要表达到多细的程度？来看看这几条规则：
1、当客户群=VIP，那么 月最少接触次数=1；
2、当客户出生日期=今天，那么 进行生日关怀；
3、当客户账户余额<0，那么 客户状态=欠费；

要知道，随处都可见业务规则，他们在各个系统里面都有体现，ERP、CRM、SCM…难道要将所有的业务逻辑集中在决策表管理？不可能，它承受不了，而且那数量也无法管理。那么，究竟什么样的业务规则适合用决策表管理呢？比如上面谈到的最少接触次数规则，在没有决策表的时候，他必定也会在某个系统中体现，比如有一个服务营销平台，里面有一段程序（或者也是一种可配置的规则形式）。

这个问题没有很清晰的答案。也许只能这么说，只有决策层关注的业务规则才适合决策表，他们基本都在决策链的上游，是具备很大影响力的。或者稍微具体一点，就是以前停留在公文当中，用文字描述的那些规则，适合用决策表来表达。

有些混乱。

[Allen]

Qing的叙述够细致够长啊。

这个问题在我看来分两个方面：1）决策分析的业务思想 2）技术实现。
关于业务思想，我认为主要是用户要清楚，或者至少大概清楚，乙方只是帮助整理、归纳而已。

我主要想谈下技术实现。

好的实现，可能需要三个技术：指标库、规则库、工作流
指标库用来准备各种数据指标。当然，决策规则不仅仅可以从指标库中取数，也可以从数据仓库模型中直接取数。
规则库（RuleBase）用来表示决策规则。
工作流（WorkFlow），顾名思义，用来触发某个判定结论后的行为动作。
还是上文的几条规则，形式化一下：
1、If (客户群Level=VIP) and (月接触次数=0） then workflow（VIP客户接触流程）
2、If（客户Birthday=today()） then workflow（生日关怀流程）
3、if （客户账户余额<0） then 客户状态：='欠费'
//以上是SuccezBI（我们正在研发的新一代BI，内置规则库、工作流等）内的语法 。

[Q]

原来你们也在研究决策表啊，太好了。

我在设想的时候，早先也是想用你说的这种结构，if..then..，但后来觉得这样会过于规则化。
所谓过于规则化，就是这种一条条的规则是列式的，很难看出规则之间的关系。

而决策表的提出，其实是将if语句里面的项和then里面的项都已经做了定义，

比如条件变量，总共有c1,c2...cn，行动总共有a1,a2,...am

所以，我觉得在这类EDM工具（或称决策表工具、规则引擎都可），应当有个地方管理这些变量和行动。

当为一个角色设计决策表时，可以考虑他可能会有三个动作，a1,a2,a3,这三个动作已经定义好了。

而这三个动作可能由9个条件变量触发，c1-c9。

我觉得对于这位决策者来说，一个重要的功能应当是：

将九个条件和三个行动之间的条件触发能用表格的方式明显展现出来，一目了然。

请问这点你们是怎么考虑的？

2011/10/14 Allen <zlshe...@gmail.com>

[Allen]

规则库中的很多条规则，似乎用表格方式表示并不合适，N条规则构成的树，或有向图，这个有向图还可以带回路（但不会死循环）。

对于规则库整体，目前我们只是提供了List和全文编辑两种模式，下一步正打算开发一个图形化规则流展示、编辑工具呢（有难度）；但对于单条规则，则提
供GUI编辑界面，用户可以方便查看前置或后导规则，或编辑规则条件和结论。

指标和动作（工作流），确实需要事先定义好。我们分别提供了指标管理工具和工作流管理工具，来帮助用户。

[Jerry Wu]

是否可以做一个规则数据模型来模拟多条规则和规则导向的关系？ 也可以考虑在数据库存储SQL逻辑，然后执行的时候调用SQL的时候计算出规则？

这个管理确实很重要，是未来业务智能化必须的管理技术，一大堆统计计算后，让用户看到他们业务需要的信息，帮助他们准确促发下一步业务，可以作为一个业务智能化的思路。

> --
> 订阅地址：ttnn+su...@googlegroups.com
> 退订地址：ttnn+uns...@googlegroups.com
>

[Q]

对于这个图形化规则流展示，我觉得它表现出来应当非常简单。不是说将所有的规则一下子展现出来，在现实中，展现出来的东西是要给人看的，要能让人理解，就得简单点。一个决策者必定只关注自己那摊子事情。

当然这是有点理想化的考虑。

另一个有些想不清楚的地方是：一个规则，或者说一项决策，从上层战术发起的任务，到下层执行的动作，整个过程应当是可以被评估的，看看这一系列规则是否达到预期目标。规则应该形成一个链，决策链。

2011/10/18 Allen <zlshe...@gmail.com>

[Allen]

是的，必须是一个链。

现在，用户对数据分析的要求越来越高了，已经超越分析展现，而希望系统能给出业务结论。
举个例子：
我做税务行业比较多，其中有项分析叫纳税评估。简单说来，就是为每个纳税人设定若干想评估指标，如税负率、成本费用率等。传统BI系统，一般只是分析展
现出这些评估KPI，然后根据打分规则，得出一系列风险系数。这些评估指标也好，风险系数也好，对基层的税务干部，实在太高深了一点。而且用户也不一定
会对每一个有风险的纳税人进行调查处理，如果责任心不够的话。
这个例子中，简单说来有两个问题：1）BI只能做数据的展现，而用户希望的是结论。比如某纳税人偷漏增值税的嫌疑很大，而不是看到一堆指标。 2）有了
结论后，需要有进一步的动作行为。
解决问题1，一般可以通过规则库来解决，规则形如：
IF(原材料占比环比变动率Z0404 >存货项目单项占比环比或同比参数上限X0402 (省级维护默认50%) 或 原材料占比同比变动率
Z0405>存货项目单项占比环比或同比参数上限X0402(省级维护默认50%))THEN { 结论：分析有无未及时结转成本、虚构进项或应转出未
转出进项税额问题。}
（顺便，这里面还有个难题，评估规则可能不断需要调整，所以必须独立于BI系统，业务用户自己能方便编辑维护；要是规则调整只能通过修改脚本实现，那就
太痛苦了）

解决问题2，则需要引入工作流。当某个最终结论得出后，要通过规则库去触发一个工作流，比如上门调查的工作流。有了工作流，进一步的行为动作就成为了刚
性，也就是说下级必须处理，必须反馈，上级可以以此来监督下级的工作，而且上级也可以参与工作流，进行审批或复核。调查处理后，调查结果可以回写到数据
库中，需要的话可以再次评估。
这样，通过整合分析的数据流和业务行为的行为流，就把 BI的决策整合到了实际的业务工作中了，形成真正的决策流。

有些人把 BI结合工作流、全文检索、规则库等，称作“后BI”.

[Q]

你们的产品有没有考虑EDM的想法？目前国内似乎很少专门这方面的产品，但国外这似乎已经成为单独一个领域。

有个James Tyler，就是专门研究这玩意儿的。

2011/10/19 Allen <zlshe...@gmail.com>

是的，必须是一个链。
...

[Allen]

尚不了解，没有。

[hunter]

用本体和推理机做过类似的东西。用于推理隐含规则。

[hunter]

听起来像操作BI

问题一我觉得是流程问题，有模型了，那么有没有流程来保证定期及时处理模型的结果

[hunter]

听起来像操作BI

问题一我觉得是流程问题，有模型了，那么有没有流程来保证定期及时处理模型的结果

On 10月19日, 下午12时41分, Allen <zlshen2...@gmail.com> wrote:

[Jerry Wu]

最能快速产生BI特有价值的，就是操作型BI，其他决策支持什么的，谁知道在用户心中算什么地位，用户是否觉得BI对他们有多大的帮助？

 

2011/10/22 hunter <hunte...@gmail.com>