
决策型产品是经过理解业务需求,创建业务模型,提供数据展现与分析,进而实现自动决策的产品。本文将结合咱们在严选供应链的实践,分析在设计一个决策型产品时,最应该关注什么,产品设计成功的关键点是什么等问题。web
大数据技术的成熟及其在企业决策流程中的普遍应用,让基于数据的各种业务产品在企业产品矩阵中的地位愈来愈重要。此类业务产品按照对于业务决策支持能力的强弱,能够分为三个发展阶段:算法
第一阶段:报表型产品,为业务人员提供各种数据报表,帮助他们了解业务的运行情况,业务人员能够借助报表展现的数据进行分析和决策;微信
第二阶段,分析型产品,分析型产品更进一步,除了数据展现外,将成熟的业务分析思路嵌入产品,提供不一样程度的数据分析能力,加强了辅助业务决策的能力;架构
第三阶段,决策型产品,利用数据、规则、算法进行自动化决策,极大提升业务的自动化程度和决策水平;app
咱们认为,决策型产品是经过理解业务需求,创建业务模型,提供数据展现与分析,进而实现自动决策的产品。本文将结合咱们在严选供应链的实践,分析在设计一个决策型产品时,最应该关注什么?产品成功的关键点是什么?等等问题。框架

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 围绕模拟的反馈闭环
须要说明,咱们所说的“决策”,其实是决策产品在面对某个业务场景时,所执行的一套规则或一组算法,而不管是规则或算法,都是由一系列的参数来控制的。所以本质上,咱们说的复盘,除了对于规则或算法自己的更新修正以外,更多的是来复盘面对某个业务场景是,对应的各项参数配置是不是“最优的”(注意:咱们讨论规则是否“最优”,必定要和业务场景相结合,不难理解,库存管理系统针对大促时期和平销时期的最优参数配置必定是不一样的)。
-
仿真模拟系统能够根据历史数据和将来指望数据,在决策前即对可能的业务结果进行仿真模拟,明确决策对于业务各项指标的影响,达到决策有预期,避免错误决策;
-
在决策后,仿真模拟系统能够持续对影响决策的参数进行模拟,尝试寻找更优的参数配置。一旦找到了更优的参数,就能够对线上的决策参数进行替换了。
固然,在产品设计时,当发现更好的参数配置,有两种作法:一种是将更好的参数及其模拟结果告知业务方,由业务人员确认,另外一种是直接由系统替换配置,再告知业务人员配置变动的缘由。选择哪一种方式,取决于系统的成熟度,一般都是从第一种方式向第二种方式逐渐过渡;
-
即便在多轮模拟后、甚至第一轮配置时就找到了决策对应的最优参数配置,可是因为决策面临的外部场景会发生变化,决策依赖的参数配置也须要随之改变。经过仿真模拟,咱们能够以更短的周期(例如天天)结合最新的业务变化状况与为将来的预测状况进行模拟,从而找到与将来状况更匹配的决策参数;
结尾
随着企业各种业务线上化、自动化和智能化的推动,会出现愈来愈多的决策型产品,帮助业务人员作好各种业务决策。咱们相信,在推动决策型产品落地的过程当中,若是围绕咱们提出的核心要素进行设计和实践,可以帮助你们少走弯路,一次把事情作对。
做者简介
麦格,网易严选供应链策略系统产品经理,负责严选供应链策略系统建设,专一于供应链订单调度、库存平衡、仿真模拟等方向。
斯内普,网易严选供应链技术架构师,负责严选供应链策略系统建设,目前专一于供应链系统建设、仿真模拟系统实践。
本文由做者受权严选技术产品团队发布

