如何做决策?

我们已经介绍了一些基础内容:编写规则时不该做什么。现在我想重点谈谈该做什么。谈到这个话题,我的第一个念头,同时也是最基础的一点,那就是:做决策。

一个常见的误解是,决策服务只做一个决策。当然,会有一个最主要的决策将结果值设置为true、一个字符串或计算得到一个数值。例如:

· 批准贷款申请

· 核准保险索赔

· 将一笔支付交易标记为欺诈行为

决策服务通常会做出这个关键决策,但它往往会附带其他子决策。例如:

· 风险评估

· 最好的抵押贷款产品

· 付款金额

· 可能的欺诈类型...

做多个决策还是一个决策

在我的职业生涯中,我见过许多不同行业的项目。它们适用于完全不同类型的决策。我时不时听到一些人想要简化决策结果的想法。‘某些情况下’仅仅做出一个决策是不够的。不要假定没有决策就等同于与其相反的决策。这种过于简化的做法不是一个好的设计。决策服务需要做出多个决策。

业务规则通常会标记出负面的结果,例如一个拒绝的决策、疑似欺诈等。一个诱人的想法是决策服务只在反面的行为发生时才做出响应。如果申请人没有被拒绝或转介,那么他或她的申请就被批准了。既然这是显而易见的事实,为什么还要明确地表述呢?

在这样的设计中,决策服务将在申请人被拒绝时返回"已拒绝",而当申请人没有被拒绝时,则不会返回任何信息。

把糟糕的情况标注出来并不是什么坏事。同时我个人坚信正面的决策结果也需要肯定地表述出来。决策服务所给出的最终结果都是“申请被拒绝”,这是不够的。如果符合申请规则,它应该能反馈结果“申请已批准”。只关注否定的结果似乎会很直观,但没有返回任何结果未必就是正面的,也可能是由于缺乏信息而无法对申请人进行审查。

不要让决策服务做出的决策有任何的不确定性。


为什么要同时准备正反两面的决策?

你当然可以认为‘没有错误的决定’等同于‘正确的决定’。不过我觉得这逻辑有点站不住脚。当出现例外状况时,在这种逻辑下会得出一个肯定的结果(“申请被批准”),这会使你的业务遭受损失。如果你的决策逻辑在中间步骤失败了,不要忽视了这一信息。

不要因此臆断我不信任业务规则。显然,业务规则会忠实地重现您所创建的决策逻辑。我担心的是数据会随着时间的推移而改变,既定的决策逻辑也会同样改变,而且很频繁。

不要想当然地认为所有可能的路径都被覆盖了。当前你的规则可能会检查是否所有必需的信息都已经提供了。假设第二天你的决策服务需要一个新数据,而负责该数据相关规则的业务分析师忘记提前检查,缺少此数据时,将无法做出决策。最终你会得到许多一开始就无效却被批准了的申请。

简而言之,我强烈建议为例外事件做好准备,不要让它在不经意间发生。一定要清楚地表述你的决策。如果申请没有被“拒绝”或“转介”,则添加一条规则将状态设置为“已批准”。如果遇到这些无法做出决策的情况,只需要相应地更新你的决策逻辑。另外,这会大大增加在质量检查时发现这些问题的机会。你也不希望在决策逻辑部署到生产环境后还出现混乱。这就是关于做决策的101规则。

产品
解决方案
学习
上海杨浦区昆明路739号文通大厦9F
©2021 上海数泱信息科技有限公司 版权所有