![]()
决策型产品是通过理解业务需求，建立业务模型，提供数据展示与分析，进而实现自动决策的产品。本文将结合我们在严选供应链的实践，分析在设计一个决策型产品时，最应该关注什么，产品设计成功的关键点是什么等问题。
大数据技术的成熟及其在企业决策流程中的广泛应用，让基于数据的各类业务产品在企业产品矩阵中的地位越来越重要。此类业务产品按照对于业务决策支持能力的强弱，可以分为三个发展阶段：
第一阶段：报表型产品，为业务人员提供各类数据报表，帮助他们了解业务的运行状况，业务人员可以借助报表展示的数据进行分析和决策；
第二阶段，分析型产品，分析型产品更进一步，除了数据展示外，将成熟的业务分析思路嵌入产品，提供不同程度的数据分析能力，增强了辅助业务决策的能力；
第三阶段，决策型产品，利用数据、规则、算法进行自动化决策，极大提高业务的自动化程度和决策水平；
我们认为，决策型产品是通过理解业务需求，建立业务模型，提供数据展示与分析，进而实现自动决策的产品。本文将结合我们在严选供应链的实践，分析在设计一个决策型产品时，最应该关注什么？产品成功的关键点是什么？等等问题。
![]()
2. 决策型产品的设计路线
我们认为，决策型产品的核心要素有三个：模型+数据+策略。与此相对应的，为了能够让一个决策型产品成功落地，主要需要做好三件事：- 构建领域模型，即要充分抓住决策型产品所解决的真实的业务问题，构建精准且可扩展的领域模型；
- 挖掘数据价值，即要从业务、流程、系统等各个层面挖掘数据价值，以数据驱动业务决策；
- 打造决策闭环，即要让决策系统是一个可以持续优化的闭环，以不断满足快速变化的业务需求；
![]()
3. 构建领域模型
决策型产品围绕一个或一组业务场景进行设计，专注解决特定的业务问题，因此，深挖业务规则、理解业务流程、明确业务指标是构建业务模型的突破口。可以说，一套精准又强大的业务模型，是一个决策型产品的灵魂。我们所理解的构建业务模型通常是产品技术人员的工作。虽然这件事情很重要，但由于团队责任划分，通常负责需求的业务人员不会参与业务模型的构建，而是将需求通过层层传递的方式告知给产品技术人员，这可能造成关键信息丢失，进而导致构建的业务模型的精准性和扩展性不足。这种模型构建方式的直接后果是：业务人员脑子里的模型、产品人员脑子里的模型与开发真正实现在代码里的模型都不一样，最终造成不同角色间沟通困难，代码持续腐化，新需求开发周期变长等问题。![]()
3.1 达成广泛共识
决策型产品设计之初，就应该要求参与产品的各方，都能够对于业务模型、业务流程和业务指标达成共识。该实践的重点是，构建业务模型的工作不能仅仅是由产品技术人员来完成，而是应该由整个团队（包含业务人员、产品、技术、数据等角色）共同完成，让每个角色都能够对业务模型所包含的模块，模块之间的关系等有深刻的、一致的认知。在领域驱动设计（DDD）的实践中提出了一种称为“事件风暴”的方法：业务专家向团队所有成员描述详细的业务流程，整个团队积极参与讨论，并在过程中找到核心域、非核心域，明确实体、聚合、事件等关键元素，最终完成业务模型构建。在具体的实践中，能否高质量地进行事件风暴，除了很考验每一位参与者的专注度与执行力之外，还特别需要一名业务专家的积极投入。因此必须要让业务专家意识到，一方面他的专业知识对于业务模型的构建至关重要，另一方面一套清晰、精准、强大的业务模型也能大大帮助他完成业务目标。即在这个过程中，要让业务专家由提需求的人，变成协助/甚至主导构建业务模型的人。除了对业务模型的构建达成共识外，还需要各方对于整个业务未来的发展取得基本共识，例如未来业务会重点朝哪个方向努力，哪个业务域的可挖掘价值最高等等。这么做的目的是能够让产品技术团队进行一定的提前布局：例如是否需要拆分微服务、是否可以将非核心的模块外包、是否应该在某个模块开发时投入主要精力等。3.2 统一沟通语言
达成广泛共识的最终状态应该是：在未来需求迭代、系统演进的过程中，各个相关方能够使用同一套话语体系（Ubiquitous Language）进行沟通。这不仅避免了各方在沟通过程中的信息失真，更重要的是可以让大家都能够在同一个思维框架内去认知和讨论。当各方对于领域模型达成广泛共识，并能够用同一套语言进行沟通时，就可以大大提高业务需求从提出到落地的效率。除此之外，还有其他诸多好处：- 当面临一个业务需求时，有两种思考方式，一种是根据系统现状，直接实现业务需求；另一种更好的方式是，对照领域模型，对业务需求进行结构化分析：
- 为了支持业务需求，核心域是否需要进行能力扩充（即对核心业务模型进行扩展）
- 为了支持业务需求，支撑域是否需要新增处理逻辑（即对支撑业务逻辑进行调整）
- 当提出需求的人和实现需求的人对于领域模型有共同的认知时，那他们也能更好地就需求的投入产出比达成共识（而与此相对应的是，提需求的人对于需求实现的难度没有概念，造成开发资源的浪费）；
3.3 挖掘核心业务指标
我们首先需要明白一个道理：“若无法衡量，则无法优化”。对于一个决策型产品而言，我们必须找到一系列指标，来衡量产品做出的各类决策的质量优劣，进而能够围绕这些指标，来持续进行决策功能的优化。同时，对于一个团队来说，共同挖掘业务指标的过程，也是一次发现价值的过程。大家需要回答这些问题：
- 业务指标应该是分层的，哪些是核心指标，哪些是非核心指标，一个核心指标下面关联哪些非核心指标。分清核心指标和非核心指标，对于产品的设计也有很大的影响，例如在我们的一些供应链产品中，主页面只需要展示最核心的库转和缺货等核心指标即可；
- 业务指标彼此可能存在冲突，例如成本和用户体验，通常为了优化一个，就必须在一定程度上牺牲另一个。我们应该结合业务发展现状，来选择当前业务更加关心的指标，找到影响这些指标的关键因素来进行优化；
- 业务指标的评价口径不是一成不变的，而是应该随着业务的发展而发展，定义业务指标的目的是为了更好地理解业务的运行状态，挖掘系统下一步的优化目标，因此当指标的统计口径不能很好地指导业务发展时，就应该改变指标的统计口径；
对于互联网这样的数字化业务，业务流程中的方方面面都需要利用数据。一个经得起市场检验的决策，是基于尽可能广泛的数据收集和尽可能严谨的逻辑分析基础上得来的。因此，决策型产品的第二个关键要素是对业务数据的分层抽象与使用，深度挖掘数据价值。我们可以将数据的加工与使用分为三层：- 第一层，数据只是一串通过观察而记录下的符号，所含内容十分有限，无法回答特定的问题。
- 第二层，通过加工解释、分析数据间的关系获得了信息，信息是具有逻辑关系的数据，但此时信息中可能包含大量的冗余内容，还不足以指导用户决策。
- 第三层，进一步对庞大无序的信息进行管理和分类，知识是从相关信息中过滤、提炼及加工而得到的有用资料。具备知识的决策产品能够直接推动用户的决策和行为，加速行为过程。
举个例子来说明。例如，某个商品在A仓库有10件，在B仓库有20件，C仓库有15件，一个用户订单需要购买5件。这是数据，只是单纯的记录，无法帮助业务决策应该从哪个仓库给用户发货是最优的。继续分析发现，用户地址离A仓库最近，配送时效更快，但是A仓库的库内操作费和配送费都比B、C仓库更高，同时，B仓库存在产能不足的问题、C仓库的商品即将过期……可以看到，信息开始变多变杂，我们开始面临新的问题：如何确定这些信息的价值或者说优先级，从而制定最佳决策呢？此时，我们可以进一步分析信息之间的关系，并确定业务最关心的指标。例如，将影响调度结果的信息归类为成本、时效、产能、效期等因素，明确信息之间的协同或互斥关系。当业务目标是确定以用户体验最优为导向时，我们便可以根据业务模型快速构建决策链路，最终得到决策建议，从最近最快的A仓库为这位用户发货。设计决策型产品的一大核心在于，需要围绕业务目标对数据进行“数据-信息-知识”的逐步提炼，最终系统可以在一个完善的知识体系下实现“因地制宜”的决策效果。在这个过程中，我们认为，主要应该关注数据在三个方面的价值表现。4.1 业务价值
作为面向企业内部的产品，决策型产品的一大重点在于为业务指标服务。满足业务需求、解决业务痛点是决策型产品需要具备的核心能力，而数据则是这项能力的关键载体。在规划决策型产品时，不仅要清楚数据在整个业务流程中的运转规律，更需要厘清原始数据在每一次使用和运算后产生的新信息的含义，再结合业务规则和逻辑对新信息进行加工。用一个例子来说明。在库存平衡的业务场景中，调拨人员每天都要创建仓库与仓库之间的调拨单据，当系统只记录和提供各种商品在每个仓库的数量时，在调拨场景中是没有业务价值的，我们不仅需要提供库存的实时数据，更重要的是满足调拨核心需求——该从哪个仓调拨哪些商品调拨多少数量到哪个仓，才可以帮助库存平衡，从而达成业务指标。我们同样可以通过以下几步来解决问题：- 第一步，挖掘仓库、商品、库存、时间、路线等多维度数据之间的关联关系，获得更多信息；
- 第二步，基于以上信息，构建合理、模块化的业务模型，规范统一输入参数，也就是搭建知识体系；
- 第三步，综合以上所有条件并集合算法计算出符合核心目标的最佳组合；
- 最后，复盘每次调拨决策中存在的异常和问题，作为下一次对模型或参数优化的输入。
决策型产品要让数据为目标所用，冗余的数据会让用户困惑，每一个展示给用户的数据在特定场景下都应该有它的业务价值所在。随着系统的自动化程度变高，我们向业务人员提供的数据重心也会逐步从信息展示类转向风险预警类和异常分析类，一方面提高系统辅助业务决策的前瞻性，另一方面也为下一步的自动化决策做准备。4.2 流程价值
在系统还未发展成熟的阶段，业务人员往往会通过各种各样的方式达成业务目的。即使在同一个业务场景下，不同的业务人员操作流程也很有可能是不一样的。千人千面的用户习惯对于整体业务流程来说其实是一种资源损耗，业务人员可能花费大量精力在数据的获取和清洗上，甚至是仅根据少量数据拍脑袋做决策，可能导致一些意想不到的异常情况和后续很难解释的补丁流程。企业内部产品实现提效的根本在于作业流程标准化，因此，找出不同业务行为背后的根本问题，通过构建合理的数据模型重组业务流程，促进流程标准化，是决策型产品应该从数据中挖掘到的第二重价值。我们还是以调拨为例。在人工处理时期，业务需要根据采购计划、销售活动、库存水位、仓库路线、调拨成本等信息综合判断，人工筛选、计算每条路线需要调拨的商品数量，计算结果受个人影响大且难以监控。可以看到，在整个过程中，使用到了销售、商品、采购、库存、配送等多个维度的数据，而业务如何使用这些数据其实是不明朗的。决策型产品需要非常清晰地定义数据使用分几个阶段、每个阶段使用哪些数据、使用的顺序是什么、不同数据的权重如何等问题，我们要明确将哪些流程封装到系统进行自动化，哪些流程仍然需要业务人工处理，而这个设计也非常依赖于数据的可靠性、完整性和准确性。通过对数据的定义与抽象分析，业务流程中的共性与特点也将脱颖而出，成为我们标准化流程的关键。此外，在我们设计产品的过程中还需要保持独立的产品视角，明确产品的阶段与发展形态，在承接业务需求时，尽量与产品的发展路线相匹配，而不是一味地进行功能点的堆砌。对业务需求和规则做必要的抽象，沉淀为系统的通用能力，从而可以满足未来更多的业务场景。
4.3 系统价值
打造数据流转闭环、反哺系统建设是决策型产品发展历程中的高级形态。当前我们使用的多数内部决策型产品基本还处于辅助决策的状态，这里的“辅助”不仅仅指系统对于业务来说，是一种数据分析与计算的工具，不具有完全决策能力，也表示对于产品本身而言，还缺乏一种自我迭代机制，用户的行为数据还未实现反向输入或分析，产品的更新与进步仍然需要依赖于用户主动的自我意识，导致产品品质与使用者的专业素质关系绑定很深。反向分析用户行为数据的过程其实是一种对用户已有经验知识的逆向解析，目前大多数情况下，我们通过人为尽可能地广泛收集用户工作方法与经验，将用户通过经验形成的知识解构为信息和数据，再嵌入到产品中供系统识别和使用。这样做的缺点在于往往受个人偏好的影响较大。智能决策型产品则需要具备自我学习能力，可以基于更多角度的、更深度的、更实时的信息和知识进行解析和复盘，获得新的知识与技能，持续优化决策。此时，决策型产品便完成了正向“数据分拣-信息聚类-知识架构”和逆向“知识解构-信息转化-数据捕捉”的完整数据闭环。这也是决策型产品设计的第三大核心“打造决策闭环”的前提。决策型产品的最终目标，是能够实现自动化决策，取代业务人员日常决策的工作。实际上，实现自动化决策本身其实并不难，难的是如何实现一套可持续迭代优化的自动化决策系统。我们把这项工作称为打造决策闭环，即实现“决策→复盘→优化→再决策”的闭环。不难理解，只有完成了决策闭环的构建，才算真正意义上实现了自动化决策。进一步，通过一轮轮决策闭环的迭代优化，完善策略，强化算法，才能发挥决策型产品的价值，将业务人员从日常的决策工作中解放出来。5.1 构建评价体系
一套完备的、标准化的评价体系至关重要。上文我们已经讨论过需要挖掘关键的业务指标，而评价体系里除了业务指标外，还包含两类指标：- 面向业务的中间指标 —— 例如供应链的核心业务指标为默认仓满足率，而我们可以根据系统优化的需要，定义诸如最优仓满足率等指标，帮助我们对系统进行更准确的评价；
- 面向系统的技术指标 —— 例如系统的订单处理能力、算法执行速度等指标；
- 构建的评价体系是需要多层次的、完备的，能够对系统的方方面面进行评价。举例严选的仓配决策系统，我们有针对订单层级的指标，如拆单率等，也包含运单层级的指标，如次日达率等；
- 在评价体系里实现的业务指标，一定要和业务方认可的核心指标对齐（即需要被业务方认可），最好是能够直接接入真实的业务核心指标计算逻辑里。这么做的好处是，评价体系容易被业务方认可，同时一旦业务指标的计算逻辑有更新，也能够马上反应到评价体系里；
5.2 复盘与模拟
为了能够让决策型产品做出的决策质量更高，必须持续对每一次决策进行复盘，而复盘的关键，就是要看每一次决策对于评价体系的各项指标产生什么影响。更进一步，能够分析出指标变化的原因，从而在下一次的决策过程中调整参数，以期望得到更好的决策结果。上面所说的这个“决策→复盘→优化→再决策”的过程，在实际执行的过程中会比较复杂，主要原因是：- 实际中的业务指标，经常受到很多因素的共同影响，所以很难简单的归因于某一个具体的决策导致了业务指标的变化。例如对于用户订单的拆单率，可能受到用户订单数量、库存分布情况、仓库产能等数十个因素的影响，如果我们想要找到拆单率变化与某个决策之间的关系，其实是很困难的；
- 实际中的业务指标，可能需要很长时间才能够真正体现出影响来，这导致了从复盘、优化到再决策的周期很长，系统优化的效率低下。例如商品的采购策略，可能会影响未来几周甚至几个月的销售情况、库存成本等，我们不可能真的等到这批库存卖完，才能对采购的下一次决策进行优化；
为了解决这个问题，系统在设计的时候，可以考虑引入仿真模拟系统。简单来说，仿真模拟系统是基于业务模型构建的一套虚拟运行环境，通过控制整个系统变量的数量，来对系统决策如何影响指标变化进行量化。仿真模拟系统能够大大加速复盘周期，例如快速将用户过去半年的订单以事件流的方式进行重放，让“决策→复盘→优化→再决策”的闭环能够真正落地。因此，我们应该考虑围绕仿真模拟系统去打造决策反馈闭环。5.3 围绕模拟的反馈闭环
需要说明，我们所说的“决策”，实际上是决策产品在面对某个业务场景时，所执行的一套规则或一组算法，而不论是规则或算法，都是由一系列的参数来控制的。因此本质上，我们说的复盘，除了对于规则或算法本身的更新修正之外，更多的是来复盘面对某个业务场景是，对应的各项参数配置是否是“最优的”（注意：我们讨论规则是否“最优”，一定要和业务场景相结合，不难理解，库存管理系统针对大促时期和平销时期的最优参数配置一定是不同的）。- 仿真模拟系统可以根据历史数据和未来期望数据，在决策前即对可能的业务结果进行仿真模拟，明确决策对于业务各项指标的影响，达到决策有预期，避免错误决策；
- 在决策后，仿真模拟系统可以持续对影响决策的参数进行模拟，尝试寻找更优的参数配置。一旦找到了更优的参数，就可以对线上的决策参数进行替换了。
当然，在产品设计时，当发现更好的参数配置，有两种做法：一种是将更好的参数及其模拟结果告知业务方，由业务人员确认，另一种是直接由系统替换配置，再告知业务人员配置变更的原因。选择哪种方式，取决于系统的成熟度，通常都是从第一种方式向第二种方式逐渐过渡； - 即使在多轮模拟后、甚至第一轮配置时就找到了决策对应的最优参数配置，但是由于决策面临的外部场景会发生变化，决策依赖的参数配置也需要随之改变。通过仿真模拟，我们可以以更短的周期（例如每天）结合最新的业务变化情况与为未来的预测情况进行模拟，从而找到与未来情况更匹配的决策参数；
结尾
随着企业各类业务线上化、自动化和智能化的推进，会出现越来越多的决策型产品，帮助业务人员做好各类业务决策。我们相信，在推进决策型产品落地的过程中，如果围绕我们提出的核心要素进行设计和实践，能够帮助大家少走弯路，一次把事情做对。
作者简介
麦格，网易严选供应链策略系统产品经理，负责严选供应链策略系统建设，专注于供应链订单调度、库存平衡、仿真模拟等方向。
斯内普，网易严选供应链技术架构师，负责严选供应链策略系统建设，目前专注于供应链系统建设、仿真模拟系统实践。
本文由作者授权严选技术产品团队发布
![]()
![]()