B端零售业：订单轨迹日志功能设计思考|轨迹|运维

编辑导读：B端产品设计千头万绪，在对业务场景非常熟悉的基础上，还要求对技术实现、资源管理有一定的认知。本文作者从B端零售业中订单轨迹这一小功能的设计出发，来分享一下自己对B端设计的思考，希望对你有帮助。

笔者目前在负责一个O2O订单中台产品，产品的主要功能为：聚合分发订单以实现订单的履约，所谓聚合，是获取了美团外卖，饿百，有赞等公域和私域的O2O订单，进行了订单数据的一致化标准化。所谓分发，是将数据一致化后的订单分发至门店作业系统，聚合物流系统，ERP系统，统一进行标准化拣货作业，标准化配送，标准化记账与库存管理。

接下来我们了解一下订单轨迹日志是什么：

对于B端产品来说，可用性是产品的基础，可用性一般指两个方面：

解决方案能够解决企业问题；
系统可持续稳定的运行；在产品运营过程中，客户反馈产品不可用，可能并不是业务解决方案有问题。

而监控是降低运维成本，保证系统稳定运行的有效手段，在B端产品中，监控一般分为两个方面:

业务监控：如订单轨迹日志，凭证生成监控等，这些功能本质是对服务层的关键节点的转义描述-问题定义与预警
系统监控：如数据库资源监控，redis监控等，这些功能本质是对存储层的运行情况的描述与预警；

那么我们可以看出，订单日志轨迹是B端产品中的一个业务监控功能。那么订单轨迹日志作为一个监控功能是怎么帮助我们降低运维成本，保证系统稳定运行的呢，就像我们刚刚在业务监控功能本质上描述的一样，主要体现在两个方面：

关键节点的转义描述：以发生时间正序可视化展示订单状态的变更，节省运维过程中查询数据库的时间，降低理解数据库中编码的含义的难度。同时在运维过程中可以清晰的判断订单的业务进行是否正常；
问题定义与预警：如订单未正常同步状态，或者退单长时间没有被审核，可能会造成财务凭证的生成的延迟，造成对账与扣减库存等一系列问题。故需要定义出什么情况下需要识别为问题，并自动进行提醒相关人员，减少运维过程中面对大量订单无法进行便捷的识别问题的现象。

总结以下，订单轨迹日志就是以发生时间正序展示订单状态变更及其变更原因，并提供异常预警的功能。

但是在设计过程中，也遇到了两个问题。

一、系统的复杂性 1.1 复杂系统中，目标用户的定义

该需求的来源方是组内的系统支持工程师，那目标用户就是他吗？通过用户访谈并查阅了工单系统中类似问题的反映数量及在各个项目的分布，我们发现，对于用户侧的运营人员，订单轨迹日志功能也是他们普遍的诉求。由此可见，需求的来源方可能并不是唯一的目标用户。这就要求我们在B端设计过程中，对现实世界进行抽象。

用户一般具有过多与当前业务无关的属性，如认知水平，个人喜好（B端产品主要依靠优化业务流程的各个节点来最终实现提高效率的诉求，实际操作系统的用户作为系统的一个节点，往往由于产品策略选择，必须被要求具备相适应的认知水平和操作方式等，如财务系统操作人员必须具备基础的财务知识，故在抽象B端产品的目标用户时，一般不对具体对象认知水平，个人操作喜好等做重点的考量），需要进行剥离，抽象出普遍的用户画像，我们称之为角色。抽离出角色后，我们接下来就可以很方便的针对运维支持的角色进行设计。

1.2 复杂系统中，关键节点如何转义描述

在订单中台系统中，由于涉及到很多系统的数据，实际我们在做关键节点的转义描述过程，就是对数据进行一致化标准化的过程，一般可以按照以下思路进行：

数据收集→数据整理→数据展示

1.2.1 数据的收集

我们可以从具体业务场景和抽象的系统设计两个层面进行了分析：

从业务场景分析：订单轨迹日志作为业务监控的一项功能，在实际使用场景中，需要提供两个方面的信息：

订单的状态变更：运维支持人员可以通过订单状态的描述，判断业务流转是否正常，状态是对某一对象一个时间段内业务进展的概括性描述；
造成订单状态变更的动作：当运维支持人员发现订单状态变更异常时，可以通过判断造成订单状态变更的动作来判断问题原因；

从系统设计层面分析：面向对象方法将时间看错一个个相互独立的个体，相互之间没有因果关系，他们之间平时保持独立，在某个外力的驱动下，对象之间才会依据某种规律相互传递信息，这些交互构成一个业务场景。在订单这个业务场景中，我们可以将外卖平台，订单中台，ERP系统都视为一个对象。此时，当我们针对外卖平台这个对象设计功能时，我们需要考虑以下三个方面：

对象描述：描述对象本身的属性
输入信息：其他对象传递给订单中台的信息，即造成订单中台本身属性发生变化的外力
输出信息：订单中台传递给其他对象的信息，即造成其他对象属性发生变化的外力

得到以下初步的结果：

在B端行业，现有业务的技术实现方式会深刻影响到功能的设计，故通常在功能设计阶段就需要和开发进行充分的互动，以确认我们单纯从业务场景和系统设计两个层面梳理的展示数据是否正确能够描述订单的轨迹，一方面是资源有限，要充分理解现有功能实现逻辑，避免对系统改造较大的设计，以控制开发成本；另一个方面，订单轨迹日志功能作为业务监控的一环，本身就是对服务层关键节点的描述，服务层的逻辑当然是开发同学更为熟悉。

通过和开发确认，我们发现了需要增删的地方：

门店前台系统中的数据是其自行调用订单中台接口进行的查询，且不对订单状态造成影响，不应展示；
ERP系统不会给订单中台系统主动推送数据，需要订单中台系统主动查询，且不对订单状态造成影响，不应展示；
订单系统会根据配置，自动实现状态的变更，需要进行展示；

经过整理细化，展示的数据为（数据已脱敏）：

1.2.2 数据整理

当我们确认好要展示的数据后，我们需要按照一定的规则对数据进行整理，形成一致的标准化的文案，方便用户阅读。我们一般将【时间+描述+操作人】定义为一个元件，元件按照发生时间正序排列，形成完整的订单轨迹日志，如：

2020-11-11 13:46 推送【新订单】消息至订单中台美团外卖

2020-11-11 13:47 自动同步订单到订单中台订单中台

2020-11-11 13:47 订单总状态变为【门店作业中】订单中台

2020-11-11 13:46 门店操作【拣货完成】门店前台作业系统

2020-11-11 13:47 呼叫【美团配送】成功，运单号：100111 订单中台系统

2020-11-11 13:48 推送【骑手取货】消息至鼎力云系统,骑手姓名：张聚合物流系统

数据整理的原则是：

颗粒度适中：通过合并同类动作，去除重复动作，使得订单轨迹日志不至于过于啰嗦，如同步订单状态时，订单中台既会接收外卖平台的消息推送，也会在接收到消息推送后主动调用外卖平台接口查询订单状态确认状态是否为最新状态，以保证在订单状态高频变动的阶段获取正确的数据，这时就不需要展示如此的详细，既展示消息推送，也展示拉取的动作，只展示消息推送的数据即可。
明确视角：应明确说明信息的发送者，接收者或者状态变更的操作人是谁，以明确视角，不至于混乱
统一规则：同一类操作的文案需要保持一致，如【时间+推送【XXX】消息至订单中台+操作人】描述其他系统向订单中台推送的数据
通俗易懂：不要使用技术语言，如回调，JOB等，而是使用通俗易懂的语言进行描述；

1.2.3 数据展示

确定信息优先级：从数据整理的结果来看，一笔订单的订单轨迹日志数据过多，需要判断信息的优先级，优先展示重要的信息。从使用场景来看，正常情况下只需要关注订单状态，异常的情况下才需要查看造成订单状态变更的原因。故优先展示状态信息；
区分视角，贴切场景：由于存在订单中台接收的数据和推送给其他系统的数据,故决定采用将输入和输出的数据分开展示；

最终经过方案细化，展示效果示意图如下：

1.3 复杂系统中，如何进行问题的定义与预警功能的设计

如图所示，订单的创建是一个异步的动作，会出现接收到新订单消息，鼎力云中却没有创建订单的问题，同样的，也会出现状态不同步的问题，针对此类情况，就必须先将问题定义出来，然后设置预警功能，从而保证业务的正常进行。此块内容较多，下篇文章再详细介绍。

二、资源的有限性

产品功能随着边界的蔓延，边际收益也在递减，所以产品的功能是有边界的。在【中台产品经理宝典】一书中，作者提出：ROI(投资回报率)是衡量B端产品功能的标杆，产品经理必须考考虑一个功能的投入和收益

由上图可知，为提高ROI，则必须在产品设计时减少投入，因为对于B端来说，收益不是特别好量化，那么可行的方向就是：重点降低功能推广成本，后期运维成本的同时压缩开发成本，这就要求我们在产品设计时必须做以下工作：

确认哪些功能特性必须满足，必须做的功能特性中，哪些优先做，以压缩开发成本。

我们可以使用简化版的KANO模型来进行分析：