业务背景
货拉拉企业版是专为企业客户打造的货运平台，在业务上，货拉拉企业版提供同城货运、定制城配、API技术支持等差异化服务；在功能上，企业版提供货物保障、管理功能、月结账户等服务，专为企业货运难题提供解决方案。服务领域包括商超零售、生鲜餐饮、家具家电、电商平台等领域，成立至今服务超过150万+企业客户。
大客户介绍
面向企业客户的货运业务中，大客户通常能带来显著且长期的收益回报，但大客户的接入过程也伴随着高昂的成本。下面从成本、收益以及大客户诉求带来的挑战三个方面对企业大客户做简要的介绍。
1. 高成本
- 流程长，通常在1~2个月，过程涉及众多不同角色人员，存在很大的沟通成本。
- 诉求多，众多大客户诉求需要花费大量产研成本，23年H1 大客户需求占企业货运总体需求的32%。
客户接入流程
23年H1需求分布
2. 高收益
- 二八原则，小部分大客户提供大部分的营收，具有强B端属性的客户，客均贡献非常高。
客户特征
3. 大客户诉求带来的挑战
- 维护成本高，大客户因业务、行业等差异在不同方面都提出定制诉求，有着巨大的长期维护成本。
- 迭代效率低，存在核心逻辑代码与差异化代码相互影响，改动成本高。
- 稳定性挑战，牵一发而动全身，差异化实现分布在系统的不同位置改动风险高。
大客户诉求
方案探索
1.行业解决方案
面对企业客户诉求所带来的挑战，我们调研了一些公司的解决方案，总结得出以下方案: “建设标准的能力与产品，在标准之上完成差异化诉求的定制”。结合业务现状，我们认为这是个值得我们进行探索的方向。
-
什么是标准
百科定义: 标准是对重复性事物和概念所做的统一规定，它以科学技术和实践经验的结合成果为基础，经有关方面协商一致，由主管机构批准，以特定形式发布作为共同遵守的准则和依据。
-
为什么要标准
从业务角度看，标准能更好满足大部分的客户诉求，从系统的角度看，标准意味着通用性强，更易于复用。
-
关注怎样的标准
标准在不同维度、阶段所研究的对象有所差异，如业务分析阶段我们更关注的流程，系统设计阶段我们更关注模型与能力。
2.技术调研
建设标准是为了更好适配大部分需求以及为客户定制打下可复用的基础。我们调研了市面上一些常见的技术措施与分析方法论。最终我们认为 "建设标准能力+通用流程+业务扩展点"的方案能满足未来很长一段时间内的业务发展与系统迭代的要求。
常见技术措施
上述措施都在围绕"不变与变化"进行系统建设，选择怎样的技术组合，关键还在于识别出自身业务不变的是什么，变化的是什么，进而构建稳定的标准能力。
- 分析方法
关于不变与变化的分析、构建可复用能力，MEAF（现代企业架构框架）提供了一些可执行的分析方法论。MEAF是一个关于企业架构设计的可落地的执行框架，下面简单介绍下MEAF的识别与构建能力的过程。
识别与构建能力（出自MEAF）
流程建模（出自MEAF）
- 识别与构建能力在MEAF中分为为业务梳理与模式设计两个阶段，业务梳理是对业务不同层次的拆解梳理，比如阶段可以是售前/售中/售后，活动可以是下单、支付等，分析所得到的结果则作为模式设计的输入。
- 流程建模，模式设计中关键第一步，会进行共性分析与可变性分析，分析得到的通用流程、实体、关系会作为后续设计的输入，最终完成不同粒度的能力模型设计。
3.企业版解决方案
3.1 系统背景
- 可复用能力建设不足及关键流程抽象较低，导致面对大客户定制诉求时实现过重，后续的维护成本较高。
- 众多的特性与策略缺少统一管理，导致了较高的策略管理成本，同时也影响客户的接入效率。
- 定制诉求的实现代码缺乏规范，存在于核心逻辑耦合的情况，不利于长期迭代。
3.2 系统目标
结合业务规划、系统背景、调研结果三个方面，我们明确建设标准能力与通用流程是解决企业客户诉求的系统基础，而面对大客户的差异化诉求，我们选择了在标准之上对特性策略的统一管理以及轻量级定制的方式来解决。
战术策略
- 建标准，建设标准能力与通用流程，提高复用能力，降低维护成本。
- 配置化，建设特性管理中心，将所有特性、策略、决策进行统一管理，降低特性管理成本。
- 轻定制，明确定制的可用措施，规范化相关定制逻辑，基于标准能力与流程做少量的定制逻辑。
3.3 设计要点
3.3.1 建标准
建标准，建设标准能力与通用流程，提高复用能力，降低维护成本。
（1）标准能力建设
系统架构
业产研围绕定价、订单、管控等模块持续进行标准能力的建设，不断沉淀夯实可复用能力。在标准能力的基础上，完善以大客户群体为中心的客户定制模块，满足大客户差异化诉求。
（2）通用流程建设——以下单为例
抽象通用流程
- 流程抽象，改造前APP/开放平台/定制客户的下单链路完全隔离，改造后各端及定制客户都基于通用流程进行实现。
- 链路整洁，基于通用流程实现，在链路上更强调动作的执行，将逻辑的复杂性收口在下单模型中，简化核心链路的调用。
建设通用下单模型
下单模型
下单模型-能力视角
下单模型-数据视角
- 建设下单通用模型，将下单的复杂性收口模型构建过程，通过模型向上兼容多端差异，向下对接多方依赖。
- 业务动作 之间解耦，统一依赖于下单模型，顶层流程按需编排动作。
关键类图
- 下单模型，以领域、流程作为依据划分匹配表达、履约表达等模块，收口250+字段，大大降低了认知成本。
- 模型构建者，将下单的逻辑复杂性封装在模型构建过程中，所有动作依赖下单模型，动作之间解耦。
- 编排服务，对流程中的业务动作进行编排，只有简单的调用动作，无复杂逻辑的实现。
- 下单上下文，贯穿下单过程，负责数据传递与共享。
3.3.2 配置化
建设特性管理中心，将所有特性、策略、决策进行统一配置，降低特性管理成本。
架构
特性管理-项目架构
特性管理-技术架构
- 规则缓存，通过本地缓存对特性、策略、条件等决策要素进行保存，减少库表访问提高决策效率。
- 决策结果缓存，对特性策略决策结果进行缓存，重复的决策查询若决策要素不变则直接返回。
- 引擎内核，结合事实（决策过程所依赖判断值组合）与规则进行策略决策计算。
关键点
3.3.3 轻定制
明确定制的可用措施，规范化相关定制逻辑，基于标准能力与流程做少量的定制逻辑。
措施
- 将扩展点设定在模型构建与动作执行中，完成差异化实现
- 对于一些深度定制，扩展点不合适的场景则基于标准能力通过扩展新的流程进行实现
扩展点实现
使用COLA扩展点组件，支持到“业务身份”，“用例”，“场景”的三级扩展。比如图中表达的是tmall业务——下单用例——88VIP场景——的用户身份校验进行扩展。
引用
-
《ThoughtWorks现代企业架构框架白皮书》
-
TO B 的本质是“定制化”不变，“定制化”实现方式求变 xie.infoq.cn/article/2eb…
-
对话张星亮，洞察本质，SaaS首先是一种商业模式 zhuanlan.zhihu.com/p/554786438
-
避免掉进“重造轮子”的坑: 从审核系统说起 www.infoq.cn/article/mvm…
-
行程平台中台化建设 segmentfault.com/a/119000004…
-
数字化转型底层方法论-读现代企业架构白皮书zhuanlan.zhihu.com/p/372333842
