编辑导语：当面临复杂多变的业务场景时，产品应该如何配置才能更灵活地适应实际，帮助处理效率提升？本篇文章里，作者就结合实际案例，对上述问题做了探讨，一起来看一下吧。

在企业做软件产品有两种目的：一是用于软件出售、二是用于支持主营业务。

前者以系统产品为核心，标准化程度较高；后者以业务为核心，系统只是工具，业务需求常常是凌驾于系统之上的。业务形式复杂多变，且未来难以预测，配置化是提高了效率还是沦为业务发展的阻碍？怎样设计功能才能在变化多端的环境下达到最佳的灵活性和可扩展性？

笔者以在券商搭建活动系统的实际经历，与大家共同探讨这个话题~

一、零售活动平台搭建背景

不知道你们公司有没有这种情况：

业务种类繁多，依靠着各种活动投入进行推广，但活动的布署、奖励计算等要么靠手工计算、要么靠一次性开发。久而久之，活动数据便凌乱地分布在业务同事的excel表中以及技术人员的代码里。

一方面，要是想对活动数据进行投产效果分析、挖掘客户特征之类的话，数据质量就非常堪忧；另一方面，活动布署及奖励计算等环节也因为没有系统化的功能沉淀而拉低了运营效率。

不巧的是，我们公司就遇到了这些问题。

证券公司作为传统金融行业的三大剑客之一，即有传统线下业务的地推模式，近年来也受移动互联网的影响大力发展线上营销。随着券商业务发展趋于成熟，总部作为中后台大脑的支撑作用越来越明显，虽线下活动依赖各地营业部的营销团队地推，但整体方案都是由总部进行策划、督导、运营，为一线员工提供营销工具支撑。

而线上模式主要针对互联网大众客户，与线下模式互为补充。业务种类繁杂，活动形式多样，在野蛮发展的过程中，数据质量和运营效率的问题都愈渐凸显。

在这种背景下，随着业务已成熟发展，自然而然便有了搭建活动管理平台的想法。

从去年6月开始做内部调研，到现在系统一期即将上线，已经过了大半年时间。这中间有感到特别难推进的时候，甚至怀疑这项目到底有多大做的必要，当然也经历过豁然开朗、跟意见不一的同事达成共识的时刻。过程中也有很多感悟，在此与各位产品同行们共享~

二、基于需求的任务拆解

在明确了平台是为了提升运营效率和提高数据质量的前提下，就要着手对任务进行拆解了。

首先是数据质量。为了避免活动数据孤岛，需要将原先由excel和各业务活动系统生产的数据都集中在这个平台作为唯一的活动结果数据出口。这块就是统一接口的问题，并不难。

其次是运营效率。要减少手工计算和技术重复开发，同时显化业务管理功能，就是要让业务同事可以根据活动方案自行在系统界面中进行参数配置，从而形成后台奖励逻辑，自动进行奖励计算。这算是整个项目中最难的点。

三、系统配置化的边界思考

我们知道软件是“对现实世界建模”：是将一系列具有共性的业务流程提炼出来，体现为系统界面功能，并起到支持这一系列的业务的作用。因此，对于标准的业务流程，是最适合做系统配置化的，因为共性足够明显。

那么，非标准的呢？

开展活动的目的就是用不断推陈出新的花样来刺激员工或客户以推广业务，似乎它天然就是“非标”模式，且不说从中提炼共性并不是一件容易的事，即便花费大力气对历史已开展活动提炼出来了一套系统化功能，但这对未来也同样适用吗？

抱着这个怀疑我跟业务和技术同事讨论，因为习惯了手工核算或者每次由技术写代码开发，大家都纷纷表示很难做到配置化，做了一些市场调研后，也没找到同类产品，不禁问自己：这个项目还有开展的必要吗？

顶着领导给的压力，哦不，是打破砂锅问到底的探索研究精神，我再次思考这个问题：系统配置化的边界在哪？

系统配置化的本质是提炼共性，那么理论上，只要共性足够多，就可以做。

仔细研究了历史活动方案发现，线下活动和线上活动在“是否有足够多共性”这一点上还是有很大区别的。

线下活动规则形式挺多，但因为所有逻辑行为都是基于数仓指标进行加工计算，虽然计算方式有不同，但其基础数据都在数仓的固化指标范围内，即“万变不离其宗”；而线上活动则因为有客户的实时交互行为参与，而产生了更多不确定性。

对于个性化极强、规则变化非常快的业务来说，如果共性较少，强行为了界面可配置去搭建一套标准的逻辑规则框架，完全就是在做无用功了。这种情况下，还不如把更多的灵活性放在代码中，系统只做数据的归集和展示。

四、如何在多变的业务场景中提炼共性

通过以上分析，笔者认为线下活动虽然看似非标，但是是有足够多共性的。抱着试一试的态度，我着手开始对业务场景进行提炼。

我想到哲学中有个很重要的特点：高度抽象。因为只有高度抽象的东西才能适用更广的场景。系统配置也是一样，要能灵活运用于各类业务场景，配置功能必须是足够抽象的。

什么东西是高度抽象的？就是最基础最本质的事物。放眼于宇宙，原子的种类并不算多，但却能组合成世间万物。

先“解构”再“重组”。

第一步解构：基于业务逻辑的过程拆分

将活动奖励计算拆分成几个基本过程：

• ① 什么对象
• ② 在满足什么条件的情况下
• ③ 获得多少数额的奖励
• ④ 奖品是什么
• ⑤ 什么时候发放

任何活动在①④⑤项的可配置参数都是能穷举的，因此很好设计。关键在于②③，也就是活动规则最核心、变化度最高的部分。

研究了大量活动规则后，发现各类线下活动方案即有共通之处，也有特别之处，如果全部用固化几类规则模板的方式太死板，肯定是不适用的。需要更高维度的提炼。

第二步解构：“给你积木块，自己去搭建”

对于第②点”满足什么样的条件“，即达标对象的筛选，是整个环节中变化最多灵活度需求最大的一环。但不管活动规则再怎么变化，线下活动的奖励总是能通过业务同事们手工计算出来。那试着还原下手工过程。

业务同事从报表平台上导出需要的报表，对各类报表进行关联、筛选查询出想要的达标对象范围。

本质上，这些报表中的字段都是数仓里面的指标，那只要形成指标库，把指标展示出来以供选取，再提供逻辑加工工具（例如选取指标、选择逻辑判断符号、录入判断值，形成单个条件，再对单条件进行组合形成最后筛选范围），就能自行加工出想要的数据了不是吗。

这跟利用动态SQL的无代码自助取数平台的原理类似，在数据产品领域其实已经有技术经验了，因此技术实现层面也不是大问题。

指标在这里就是我们拆分出来的“最基础“的元素，是高度抽象的。对这些元素的组合能形成任何我们想要的数据范围，整套体系是非常灵活的。此外，活动指标库的沉淀也提升了数据的复用程度。

第三步解构：权衡灵活需求度与可操作性，并对不确定性留有余地

已经解决了获奖对象的范围后，就剩第④项多少奖励数额了。这块怎么拆？

跟第③项不一样的是，奖励数额的算法逻辑更加复杂，如果要通过非常灵活的配置自行组合生成算法，且不说能不能实现，对于使用者的操作难度来说也是非常大的。

考虑到第④项的变化程度没有那么高，基本能通过历史方案提炼出几类算法，并且算法过程中如果需要用到不同指标，前面的指标库便再次派上用场。因此采用了固定几类算法模板+选择指标的方式形成了一套配置框架。

但毕竟这些算法并不是穷举，虽然能覆盖历史所有的算法类型，可不能保证未来的活动没有新的算法出现。

于是我在配置框架里面留了一个口子，加入自定义脚本的上传，以应对未来小概率的不确定性。提高了系统扩展性的同时，还能随着后续系统投入运行业务种类丰富清晰之后，再逐渐提炼这块非标部分并完善到标准框架中。

至此，就完成了整个业务过程的配置功能设计。

五、总结

其实做这种业务支持类系统常常都会遇到这样的问题，说到底，是既想要通过实现配置化解放人力提高效率，又想要最大程度拟合业务发展中变化莫测。

这种情况下，不能简单粗暴地说“鱼与熊掌不能兼得”，而是应该具体情况具体分析，判断系统配置化的边界究竟在哪，值不值得做配置化。

其次，在觉得能做的情况下，“解构、重组”也许是在看似非标的变化业务场景中提炼出其本质共性的最好方式。当然解构到多大的颗粒度要根据对灵活度的需求来定，颗粒度越小，灵活度越高，但重组的操作难度也越大，这是需要权衡的地方。

最后，对于完全无法预测的未来业务场景，留有非配置的余地，并随着业务发展将这部分逐渐提炼到标准配置框架中，动态完善配置框架。

本文由 @离子烫电台头 原创发布于人人都是产品经理，未经作者许可，禁止转载。

题图来自Unsplash，基于CC0协议