01

“一个哈姆雷特式的问题”

“业务系统”归根结底是支撑企业达成其某类业务目标所需要的业务过程和管理过程的功能合集，如客户管理系统、产商品管理系统、订单系统等。同时因客户需求不同，会导致同样产品具备不同的业务功能。

为了满足产品通用性和核心稳定性，我们往往采用强大但复杂的配置能力满足客户个性化定制来避免二次研发。如订单系统，通过流程和表单等配置，确实可以实现所有业务的配置，但在产品交付上线时，交付团队就需要进行大量的配置工作，难以快速交付。

因此当我们研发某类业务系统产品时，如何平衡产品功能通用灵活和齐全覆盖、侧重核心研发还是侧重产品交付成为一个难点。

本文以订单中心系统为例来说明我们在平衡产品核心研发和产品交付中的探索实践。

业界认为订单中心是面向企业业务运营支撑，对外提供一组标准化订单服务的载体。它用于管理产/商品交易的信息处理，通过协同各核心业务系统来完成商品销售的业务过程。从这个观点上看，订单中心本质上是一个协同调度枢纽，在功能规划上着重强调通用的订单能力。

从上图可以看出订单中心具有非常明显的业务无关性特征。无论是哪个行业、哪种销售模式都适用上述功能架构。

订单产品在落地实施中，不同客户对订单中心的要求各有不同：

1、有的客户要求订单产品去业务化，提供强大的流程等配置能力和灵活调度协同能力即可，产品使用者（如偏业务侧人员）通过一列配置完成业务承载，而无需 IT 侧人员频繁参与。

2、有的客户要求订单产品要具备丰富的业务承载能力，产品使用者只需通过少量配置即可完成业务快速加载，项目往往要求在较短时间内完成上线和业务承接。

那么，这里就存在一个哈姆雷特式的问题：订单中心是侧重业务无关性还是强调业务厚沉淀？

从产品研发视角和产品运维视角看，倾向于前者：因为去业务化可以确保产品研发更快捷、功能更内聚、核心无需频繁上线等好处。

从产品交付视角看，倾向后者：订单中心预置了各项业务配置，只要通过少量调整即可实现快速业务加载，响应客户需求更敏捷。

02

我们的答案——鱼和熊掌可兼得

面对这个问题，我们需要多方位进行辩证思考。

产品端到端效能竞争力的诉求：订单中心产品经过多年研发迭代，在系统功能完备和架构先进性方面已具备较强竞争力。但随着公司精细化运营的深入开展和市场竞争的日益激烈，产品研发到交付的端到端效能已成为产品核心竞争力指标之一。如何降低订单产品端到端成本、降低二次研发投入、提升现场交付效率、提升规模化批量复制推广水平，成为订单中心产品当下需要重点思考和急需解决的问题。

落地快速交付的诉求：订单产品只做核心通用能力，虽然达到了产品更灵巧、更稳定的目标，但若仅提供灵活强大的配置能力，那么在落地省份交付及日常滚动需求支撑时需要进行较大量的配置工作。从端到端来看，显然只是将工作内容从研发转移到交付，全流程并未有效提升效能。

规模化推广的诉求：对于同类业务，更存在多省间重复配置，浪费交付成本。从研发交付一体视角看，显然这不是一个好的做法。如新兴的 5G 专网业务，就存在多个存量市场省份前后要求提供支撑版本。在此场景下，为避免重复开发，如何实现快速复制就成为一项重要的产品研发指标。

仔细梳理上述诉求，我们思考：除了交付产品功能，我们还能交付什么内容来助力产品落地和复制推广？每次交付过程中，我们都积累下哪些内容可以后续加以利用？

对标业界先进产品理念，我们发现一个好的产品模式，它在我们每一次产品的交付过程中，是应该能够积累资产的。将这些沉淀资产数据有效管理并预置到产品中，便可以用于交付落地复制、借鉴，达到交付提效的目标。

因此，为契合公司经营战略、实现产品端到端降本和交付提效，我们的答案是：业务无关性和业务厚沉淀我们全都要。

• 核心通用能力层继续保持业务无关性、灵活强大配置能力、核心架构稳定性；

• 业务应用层将多年落地沉淀的业务数据资产预置到出厂版本中，实现快速落地和规模复制。

03

订单中心业务资产数据预置探索

结合几个订单项目的实践经验，订单中心业务资产数据预置探索之路分三步走：

步骤 1：订单业务资产盘点

要实现数据预置，首先要定义订单产品的业务资产。在这里我们可以把技术估值为一种资产，或者说把它等值为一种资产。我们对运营商业务订单支撑进行梳理、分析、积累、可视化、有序的管理，并有意识地构建出运营商支撑订单业务资产库，持续迭代。

订单中心本质来说是一个以流程为核心的调度系统，再辅以流程之外的独立功能（如对外提供的接口、后台执行的 JOB 任务和管理使用的功能页面）。因此我们围绕流程和独立功能对订单业务资产结构剖析如下图所示：

为实现业务间的高内聚、低耦合、快复制，订单中心采用业务分包插件化架构，将业务相似度高、集团规范约束强的业务独立成包，进行统一的业务数据预置，提高规模化复制能力和交付效率。目前业务包主要有：号卡业务包、宽带业务包、集客通用业务包、专线业务包、5G 专网业务包、云网业务包、订单查询业务包、订购实例查询业务包。

步骤 2：订单业务资产数据预置

根据上述订单业务资产结构，研发团队根据集团规范、首发省份需求进行各项业务数据预置。

1、业务流程预置

梳理各类业务场景，在 BCMC 套件中进行流程绘制、环节定义、环节事件方案配置、环节对应业务组件关联、环节规则配置，形成基于 BCMC 套件的流程相关预置数据。在省份交付时，可通过在 BCMC 组件中导出导入操作完成。

2、业务组件预置

为提升原子服务利用率，将其封装成业务组件，并在 BCMC 组件中注册和统一管理。业务组件存在多种使用场景：给流程引擎调用；封装成接口，给外部系统调用；给页面事件调用等。

3、原子服务预置

原子服务指订单中心基于高内聚、低耦合原子开发的一系列服务（如订单创建、订单拆分、订单列表查询等）。订单中心作为调度枢纽，需要与多个外部系统交互，存在大量的接口调用。因此，除了这些通用的原子服务，研发团队还将与外部系统对接接口进行封装预置成原子服务，现场交付团队可基于研发版本结合本地接口，决策直接使用还是复制后修改使用，避免从零开始研发，节约交付成本。

4、业务配置预置

除了 BCMC 组件的配置数据外，订单中心还存在很多其他业务配置，如服务转换配置、数据字典、拆单规则、派单规则、抢单规则等等。这些配置数据作为业务资产的一部分也纳入到数据预置范畴。

5、页面表单预置

基于 BCMC 配置的表单，除了提供给流程环节处理使用，还可作为单独功能页面用于菜单链接。研发团队预置了各类页面表单（如订单审批、订单详情查询等），现场交付团队可基于本地需求，在产品线版本上进行修改即可。

6、独立功能

订单中心除了流程相关能力，还存在几种形式的独立功能：接口服务（如订单创建接口）、后台 JOB（如订单同步任务）、功能页面（如订单查询页面），这些独立功能基于业务组件封装而成。研发团队同时预置了常见的接口、JOB 和页面，现场交付团队可基于本地需求，在产品线版本上进行修改即可。

步骤 3：业务资产可视化交付

在实际项目实施过程中，我们发现在完成各业务包业务数据资产预置还远远不够。IT 业务数据作为数字资产存在一个重大难题就是可视化难。产品线预置的业务数据在交付时物理形态上常常是以 war 包、jar 包和脚本的形式提供，无法清晰看到有哪些业务预置数据。如下图所示：

现场交付人员需要从 zmp 上把事务单找出来，通过查阅需求规格说明书结合测试报告才能确定这个版本更新了什么功能点。或者还是直接打产品线人员电话问吧！存在不透明、耗时多、效率低的痛点。

为提升核心版本开发透明度和现场版本交付效率，急需对订单中心业务资产进行显性化管理，让现场及交付团队清晰了解各版本更新内容；并支持快速加载版本内容，同时指导本地适配开发；与 BCMC 组件、服务转换组件打通二次研发入口，实现高效的本地化版本交付，构建端到端成本竞争力。

1、业务资产可视化交付解决方案如下图所示：

2、业务支撑可视化展示

采用两种形式可视化展示业务资产内容。

1）业务视角：按业务场景/功能视角来展示其包含的资产信息。可以清晰查阅某个业务流程或功能对应的流程信息、环节事件、使用组件和表单等资产。

2）资产视角：从资产类型视角来展示各种业务资产信息，包括汇总和清单。

3、提供资产关系拓扑图，助力研发、测试和交付人员评估关联影响，做到测试验证全覆盖。

4、打通 BCMC 组件和服务转换组件通路，实现在线流程编排、表单绘制和服务配置。

5、智能标识版本变更内容，助力测试和交付快速定位变更点。

6、提供交付指导。通过交付说明（核心模块不可改、个性化可改）和备注（业务逻辑、对接方和接口等）来指导现场交付团队进行二次研发。

7、支持根据资产数据导出实际配置数据（BCMC 组件配置、服务转换组件配置、配置表数据），现场交付团队可导入本地研发环境进行调整。

业务支撑可视化交付模块除了提升交付效率，也能为研发提速赋能：研发人员能快速定位升级改造点、新人可以快速了解系统功能和对应资产、测试人员更易评估升级影响面等。

04

实施成效收益

以 5G 专网业务支撑为例，产品线将集团规范+首发省份（山东移动）需求作为核心版本研发并提供数据预置交付，落地到山东、宁夏及黑龙江三省移动，并对 3 次集团规范版本升级进行统一迭代研发，端到端研发交付能效明显提升。主要体现在三个方面：

1、研发及交付人员投入减少

引入业务预置模式后的人员投入个数分布如下：

2、现场交付周期缩短

5G 专网业务首次交付省份（出厂版本预置+本地适配改造），周期从 2 月多缩短到 3-4 周。集团规范大版本滚动升级，省份交付周期也能从 3-4 周缩短到 1-2 周。

3、交付成本降低

全新业务由产品线统一研发并预置业务数据，成本显著降低。

05

结束语

业务预置及可视化交付是一项不断持续演进的过程，订单中心也还处于探索起步阶段，后续还有很多内容需要深入思考和实践。

业务预置后续工作将围绕研发提效、交付提效、质量提升、产品可视这四个目标展开：

为达成上述产品目标，业务预置将按以下路径进行持续演进：

1、资产盘点：进一步梳理各类资产，如呈现代码级服务资产，推动原子服务组件化；

2、资产整合优化：在支撑梳理盘点中，会发现大量重复、低效甚至有缺陷的资产，因此需要进行整合和优化，提升资产健康度和复用率；

3、资产预置：预置整合优化后的资产；

4、资产可视化：提升资产可视化能力，完善资产拓扑关系和在线预览能力，细化省份版本交付指导说明；

5、交付在线化：资产预置最终目的是为了交付提效，这是订单中心业务预置下一阶段最重要的演进工作。一方面需要进一步打通资产配置与实际生产配置的通路，支持在线配置及数据实时同步，另一方面重点思考核心版本省份发布机制，推动省份版本二次研发更清晰更快捷。

业务预置不仅仅是配置类数据的预置，更是服务、功能和能力的预置。业务预置的过程更是对产品自身全面梳理、持续迭代优化的过程。这不仅是一个高效研发交付手段，更能改变我们的研发交付思维。从“你要什么”提升到“我能给什么”，从“我完成了”演进到“我沉淀了”。

这是一项积跬步致千里的工作，需要我们在产品研发和项目实施中不断提炼共性资产、沉淀可复用资产、不断健全系统能力，最终实现强功能、快交付。