归根结底，业务系统是支持企业实现某一业务目标所需要的，如客户管理系统、产品管理系统、订单系统等。同时，由于客户需求不同，同一产品具有不同的业务功能。
为了满足产品的通用性和核心稳定性，我们经常使用强大但复杂的配置能力来满足客户的个性化定制，以避免二次研发。例如，订单系统确实可以通过流程和表单配置实现所有业务的配置，但当产品交付在线时，交付团队需要进行大量的配置工作，难以快速交付。
因此，当我们开发某种业务系统产品时，很难平衡产品功能的通用性、灵活性和完整性，专注于核心研发或产品交付。
业内人士认为，订单中心是为企业业务运营提供一套标准化订单服务的载体。它用于管理生产/商品交易的信息处理，并通过协调各核心业务系统完成商品销售的业务流程。从这个角度来看，订单中心本质上是一个协同调度枢纽，在功能规划强调一般订单能力。
从上图可以看出订单中心具有非常明显的业务无关性特征。无论是哪个行业、哪种销售模式都适用上述功能架构。
在实施订单产品时，不同的客户对订单中心有不同的要求：
1、部分客户要求订单产品业务化，提供强大的流程配置能力和灵活的调度协调能力，产品用户（如部分业务侧人员）通过一列配置完成业务承载，无需IT侧面人员经常参与。
2、部分客户要求订单产品具有丰富的业务承载能力，产品用户只能通过少量配置快速加载业务，项目往往需要在短时间内完成在线和业务承担。
那么，这里有一个哈姆雷特式的问题：订单中心是专注于业务无关还是强调业务沉淀？
从产品研发和产品运营维护的角度来看，前者往往是前者，因为去业务化可以保证产品研发更快、功能更内聚、核心不需要频繁上线。
从产品交付的角度来看，后者倾向于：订单中心预置各种业务配置，通过少量调整可以实现快速业务加载，更快地响应客户需求。
面对这个问题，我们需要多方面的辩证思考。
产品端到端效能竞争力的诉求：订单中心产品经过多年研发迭代，在系统功能完备和架构先进性方面已具备较强竞争力。然而，随着公司精细经营的深入发展和市场竞争的日益激烈，端到端效率已成为产品的核心竞争力指标之一。如何降低订单产品端到端成本、降低二次研发投入、提升现场交付效率、提升规模化批量复制推广水平，成为订单中心产品当下需要重点思考和急需解决的问题。
着陆快速交付的需求：订单产品只是核心通用能力。虽然达到了产品更灵活、更稳定的目标，但如果只提供灵活、强大的配置能力，则需要大量的配置工作来支持着陆省份的交付和日常滚动需求。从端到端，显然只是将工作内容从研发转移到交付，整个过程并没有有效地提高效率。
大规模推广需求：对于类似业务，多省重复配置，浪费交付成本。从研发和交付的角度来看，这显然不是一个好的做法。例如，新兴的5G在特殊网络业务中，有许多股票市场省份需要提供支持版本。在这种情况下，如何快速复制成为避免重复开发的重要产品研发指标。
仔细梳理上述需求，我们思考：除了交付产品功能外，我们还可以交付哪些内容来帮助产品的实施和复制和推广？在每次交付过程中，我们可以积累哪些内容供以后使用？
根据行业先进产品的概念，我们发现了一个良好的产品模式，它应该能够在每个产品的交付过程中积累资产。有效管理和预置沉淀资产数据，可用于复制和参考交付，达到提高交付效率的目的。
因此，为了适应公司的经营战略，实现产品端到端的降本和交付效率，我们的答案是：我们都需要业务无关性和业务沉淀。
-
核心通用能力层继续保持业务无关、配置能力灵活、核心结构稳定；
-
业务应用层将多年沉淀的业务数据资产预置到出厂版本，实现快速着陆和规模复制。
订单中心业务资产数据预置探索结合几个订单项目的实践经验，分为三个步骤：
要实现数据预置，首先要定义订单产品的业务资产。在这里，我们可以将技术估值为一种资产，或者将其等值为一种资产。梳理、分析、积累、可视化、有序管理运营商的业务订单支持，有意识地构建运营商支持订单业务资产迭代。
本质上，订单中心是一个以流程为核心的调度系统，辅以流程以外的独立功能（如外部界面和后台执行）JOB使用任务和管理的功能页面)。因此，对订单业务资产结构的分析如下图所示：
为实现业务间高内聚、低耦合、快速复制，订单中心采用业务分包插件架构，独立包装业务相似性高、集团规范约束强的业务，统一预置业务数据，提高规模复制能力和交付效率。目前业务包主要包括:号卡业务包、宽带业务包、集客通用业务包、专线业务包G专网业务包、云网业务包、订单查询业务包、订单实例查询业务包。
步骤2：订单业务资产预置数据
根据上述订单业务资产结构，R&D团队根据集团规范和首发省份的需要预置各种业务数据。
1.业务流程预置
梳理各种业务场景，BCMC基于流程绘制、环节定义、环节事件方案配置、环节对应业务组件关联、环节规则配置BCMC与套件流程相关的预置数据。省交付时，可通过BCMC完成组件中导出导入操作。
2.业务组件预置
为了提高原子服务的利用率，将其包装成业务组件BCMC组件中的注册和统一管理。业务组件有多种使用场景：呼叫流程引擎、包装接口、呼叫外部系统、呼叫页面事件等。
三、原子服务预置
原子服务是指订单中心基于高内聚、低耦合原子开发的一系列服务（如订单创建、订单拆分、订单列表查询等）。作为调度枢纽，订单中心需要与多个外部系统交互，并且有大量的接口调用。因此，除了这些通用的原子服务外，研发团队还将与外部系统对接接口进行包装和预置。现场交付团队可以根据研发版本和当地接口，决定直接使用或复制，避免从零开始研发，节省交付成本。
4.业务配置预置
除了BCMC除了组件配置数据外，订单中心还有许多其他业务配置，如服务转换配置、数据字典、订单拆卸规则、订单发送规则、订单抢劫规则等。这些配置数据作为业务资产的一部分也包括在数据预置中。
5.页面表单预置
基于BCMC配置的表单，除了提供给流程环节处理使用，还可作为单独功能页面用于菜单链接。研发团队预置了各类页面表单（如订单审批、订单详情查询等），现场交付团队可基于本地需求，在产品线版本上进行修改即可。
6、独立功能
除了与流程相关的能力外，订单中心还接口服务（如订单创建接口）、背景等多种独立功能JOB(如订单同步任务)、功能页面(如订单查询页面)，这些独立功能是基于业务组件的包装。研发团队还预设了常见的接口JOB和页面，现场交付团队可以根据当地需要修改产品线版本。
第三步：营业资产可视化交付
在实际项目实施过程中，我们发现完成各业务包业务数据资产预置远远不够。IT作为一种数字资产，业务数据的一个主要问题是可视化的困难。交付时，产品线预置的业务数据通常以物理形式进行war包、jar以包和脚本的形式提供，无法清楚地看到业务预置数据。如下图所示：
现场交付人员需要从zmp找出事务单，通过查阅需求规格说明书和测试报告，确定该版本更新了哪些功能点。或者直接打电话给产品线人员！存在不透明、耗时、效率低的痛点。
为了提高核心版本的开发透明度和现场版本的交付效率，迫切需要对订单中心的业务资产进行明确的管理，使现场和交付团队能够清楚地了解每个版本的更新内容；支持版本内容的快速加载，指导当地适应开发；和BCMC组件和服务转换组件通过二次研发入口，实现高效的本地化版本交付，建立端到端成本竞争力。
1.业务资产可视化交付解决方案如下图所示:
2.业务支持可视化显示
采用两种形式可视化展示业务资产内容。
1)业务视角:根据业务场景/功能视角显示资产信息。晰查阅某个业务流程或功能对应的流程信息、环节事件、使用组件和表单等资产。
2）资产视角：从资产类型视角来展示各种业务资产信息，包括汇总和清单。
3、提供资产关系拓扑图，助力研发、测试和交付人员评估关联影响，做到测试验证全覆盖。
4、打通BCMC组件和服务转换组件通路，实现在线流程编排、表单绘制和服务配置。
5、智能标识版本变更内容，助力测试和交付快速定位变更点。
6、提供交付指导。通过交付说明（核心模块不可改、个性化可改）和备注（业务逻辑、对接方和接口等）来指导现场交付团队进行二次研发。
7、支持根据资产数据导出实际配置数据（BCMC组件配置、服务转换组件配置、配置表数据），现场交付团队可导入本地研发环境进行调整。
业务支撑可视化交付模块除了提升交付效率，也能为研发提速赋能：研发人员能快速定位升级改造点、新人可以快速了解系统功能和对应资产、测试人员更易评估升级影响面等。
以5G专网业务支撑为例，产品线将集团规范+首发省份（山东移动）需求作为核心版本研发并提供数据预置交付，落地到山东、宁夏及黑龙江三省移动，并对3次集团规范版本升级进行统一迭代研发，端到端研发交付能效明显提升。主要体现在三个方面：
1、研发及交付人员投入减少
引入业务预置模式后的人员投入个数分布如下：
2、现场交付周期缩短
5G专网业务首次交付省份（出厂版本预置+本地适配改造），周期从2月多缩短到3-4周。集团规范大版本滚动升级，省份交付周期也能从3-4周缩短到1-2周。
3、交付成本降低
全新业务由产品线统一研发并预置业务数据，成本显著降低。
业务预置及可视化交付是一项不断持续演进的过程，订单中心也还处于探索起步阶段，后续还有很多内容需要深入思考和实践。
业务预置后续工作将围绕研发提效、交付提效、质量提升、产品可视这四个目标展开：
为达成上述产品目标，业务预置将按以下路径进行持续演进：
1、资产盘点：进一步梳理各类资产，如呈现代码级服务资产，推动原子服务组件化；
2、资产整合优化：在支撑梳理盘点中，会发现大量重复、低效甚至有缺陷的资产，因此需要进行整合和优化，提升资产健康度和复用率；
3、资产预置：预置整合优化后的资产；
4、资产可视化：提升资产可视化能力，完善资产拓扑关系和在线预览能力，细化省份版本交付指导说明；
5、交付在线化：资产预置最终目的是为了交付提效，这是订单中心业务预置下一阶段最重要的演进工作。一方面需要进一步打通资产配置与实际生产配置的通路，支持在线配置及数据实时同步，另一方面重点思考核心版本省份发布机制，推动省份版本二次研发更清晰更快捷。
业务预置不仅仅是配置类数据的预置，更是服务、功能和能力的预置。业务预置的过程更是对产品自身全面梳理、持续迭代优化的过程。这不仅是一个高效研发交付手段，更能改变我们的研发交付思维。从“你要什么”提升到“我能给什么”，从“我完成了”演进到“我沉淀了”。
这是一项积跬步致千里的工作，需要我们在产品研发和项目实施中不断提炼共性资产、沉淀可复用资产、不断健全系统能力，最终实现强功能、快交付。