- 郑州立刷：组件装配支付产品工厂
- 发布时间：2024/8/8 11:33:44次
- 为了有效管理日益增长的产品线和复杂的客户协议，企业需要一种灵活而高效的产品管理方法。产品工厂的概念应运而生，它借鉴了制造业的流水线管理方式，将产品视为可组装的零部件，实现快速生产和发布，以适应市场的变化和业务创新的需求。
产品多了、客户签的协议也会增多、配置费率也是五花八门，使得管理难度越来越大。
面对这种问题我们会想各种办法来做个配置，搞个流程来解决这些杂乱无序的产品、费率和协议签约。
今天我们就介绍一个终极大招，产品工厂，他可以把软件产品像零部件一样来进行装配和发布，并且也能对产品进行全生命周期管理。
一、什么是产品工厂
产品工厂就是把产品从零部件开始进行生产、加工和组装，然后对外销售。并且能够维护产品的完整生命周期。
1.1、产品工厂起源
产品工厂是设计思想来源于银行、保险行业的金融产品管理；这两个行业的金融产品非常复杂，产品需要受过专业培训的人员来推广和运营。
金融行业在长期的快速发展中积累了众多冗余系统，这些系统功能重叠，数据与参数分散于各个平台。产品升级与改造因此面临漫长的研发周期。为了提高效率，业界引入了 " 产品工厂 " 的概念，它借鉴流水线管理方式，将产品组件标准化，实现快速生产、组装与推广，以迅速响应业务创新和市场发展的需求。
1.2、产品工厂能做什么
1）产品生命周期管理
随着产品运营周期的延长，新旧产品可能会相互交织，这不仅会消耗宝贵的 IT 资源，还可能将那些应该淘汰的产品错误地推荐给用户。因此，必须对产品进行全生命周期的系统管理，这包括从概念设计、市场发布、日常运营、持续更新到最终的退役阶段，确保每个环节都得到妥善处理。
2）模块化的产品组装
面对市场上的创新理念和热点机遇，IT 部门往往需要长时间评估和开发。为了提高响应速度，产品应被设计成模块化的 " 积木 " 组件，允许通过标准化流程快速组装和发布。这种方法不仅支持新功能的增量式开发，确保了对市场变化的迅速反应，而且通过积累丰富的产品组件库，实现了产品的即插即用，从而大幅提升了产品开发的灵活性和市场适应能力。
3）产品的规范化管理
当产品数量增多而缺乏统一规范时，每个产品可能会发展出自己独特的实现和配置方法，这会增加用户的学习难度，并在产品配置和运营上带来高昂的人力和时间成本。为了解决这一问题，我们需要对产品组件和配置参数实施标准化，确保设计、开发和配置过程能够遵循一致的方法进行。这样，不仅可以降低用户的学习曲线，还能提高产品管理的效率和一致性。
1.3、企业级的产品工厂
既然称之为产品工厂自然是一套企业级的解决方案，他需要把企业所有对外销售的产品进行全生命周期管理，所有的 IT 系统也要进行组件化、参数化的改造以适应产品的快速组装和发布，以及沉淀大量的产品数据和指标来进行运营和效果评估，以及智能化的用户推荐。
图 1：产品工厂组装线与全生命周期管理
二、产品中心架构
支付作为一个卖接口和各种终端设备的生意，他天然就是一个组件化、插件化的产品，因此他是非常适合做成产品工厂。当然作为一个企业级的架构，产品工厂对于普通支付机构来说又过于庞大了，因此需要裁剪。我们只需要销售产品的组装、发布、签约配置即可，因此又称为 " 产品中心 "。
2.1、架构位置
图 2：产品中心的架构位置
从架构位置上我们可以看到产品中心位于前端的位置，给上游业务系统提供各种销售产品。他上游承接网关支付请求，下游负责把请求转发到内部的各个业务子系统去。
2.2、业务架构
图 3：产品中心业务架构
产品中心主要分为 " 产品服务、产品中心、产品组件仓库 " 三部分。
1）产品服务：对外提供可供客户使用的销售产品和配置参数，上游业务系统通过产品服务来查询、使用和管理产品。
2）产品中心：负责产品模块化的装配和发布，通过产品分发对产品进行上架、推荐、按渠道分发产品给指定客户群体。
3）产品组件库：存放产品的最基础单元和参数的仓库，只要积累了大量的零部件就能快速的组装出新的产品来提供给市场和消费者。
2.3、系统边界
图 4：产品中心系统边界
早期的支付系统都是通过支付网关直接来调用底层系统为用户提供服务的，这就使得网关既要承载技术能力，也要处理复杂的业务逻辑，所以使用起来非常的稀碎和杂乱。
2.3.1、上游边界
产品中心为上游的网关系统、商户平台、运营支撑平台提供产品查询、交易路由、商户签约 / 解约等服务能力；
2.3.2、下游边界
下游系统分为配置同步和交易转发两类。
1）配置同步：产品装配、客户签约产品、费率配置、交易限额与分账比例等都需要与对应的系统进行同步，在交易过程中也需要校验；
2）交易转发：产品中心是支付系统的一个应用前置，由它为上游系统提供新发布的销售产品，并且把支付请求转发给下游子系统。
三、产品中心设计
3.1、产品目录结构
产品中心要实现组件化的装配和全生命周期的流程管理，首先就是要对使用中的产品组件和参数进行分类和全面的分析，从而形成包含产品主要特征的产品目录。
图 5：产品目录结构
1）产品目录：所有销售产品和主要特性都在产品目录中来呈现和管理
2）产品层级关系：产品为了更加结构化的划分可以分成 " 业务板块、产品线、产品组 " 来进行多级分类，产品能以套件化的方式进行对外销售。
3）销售产品：就是提供给用户可使用的商品或者服务，他可以是单一的基础产品的组装（蓝色部分），也可以是多个产品的组合（橘色行业产品）。
4）基础产品：基础产品是产品的零部件，它分为网关接口、业务产品、支付产品和默认账户。
5）基础属性：产品的属性和枚举取值，他是让产品能够灵活的运转起来的参数。
图 6：产品目录样例
产品目录呈现了一个从粗粒度的业务视角，到细粒度实现参数的结构化拆解，这样的映射关系能够为产品所有参与者提供统一的产品视角和语境来讨论产品的规划和使用。
3.2、销售产品组件
图 7：销售产品组件结构
销售产品就是一套业务组件，上层是产品的是这套组件的产品信息和发布信息，它对应的是产品中心，下层的基础产品包含了 " 接口、业务产品、支付产品、默认账户 " 等构成一个支付产品的关键构件信息。
1）业务产品码：一个业务产品代表了一个可以独立使用的交易服务，他对应的是交易系统的服务。例如我们常见的即时到账、担保交易、合单支付、充值、提现等都是一个独立的业务产品。
2）清算产品码：对应的是支付核心的交易编码，是一个原子化的账务处理。例如入款、出款、退款、转账等原子记账服务。
3）支付产品：是支付方式对应的支付核心的账务处理参数，不同的支付产品账务处理流程和费率有所不同。
四、产品交互设计
4.1、生命周期管理
图 8：产品中心生命周期管理
4.2.1、产品设计
当接手一个新产品开发的需求后，我们首先就是分析和设计需要哪些新增的基础产品组件（后面简称为 " 基础组件 "），按照我们 "" 网关接口、业务产品、支付产品、终端类型、开通账户 "" 组件模版来分析我们需要开发哪些新增组件。
图 9：基础产品组件分析表
从上图可以看到，针对这类客户场景我们要新增付款类组件，并对部分组件限制其功能（图中红色部分）。然后我们就针对这些新增组件进行模型设计，分别定义他的交易接口、业务处理流程、支付产品和默认开通的账户。
设计完成后这些组件就能进行开发和测试了。
4.2.2、产品装配
当这些基础组件发布后，我们就会把这些基础组件通过产品模板装配起来形成一个销售产品，经过审核后，产品就发布上架提供给商户签约和使用了。
4.2.3、商户签约
新产品上架后，用户就可以签约和注册这个产品然后正式开始使用这个产品。商家使用过程中也能变更和添加产品。如果老产品需要退役可以隐藏基础产品，然后引导商户逐步关停，最终产品完成退役。
图 11：产品配置与商户签约交互流程图
4.2、产品配置
4.2.1、单一产品组装
图 13：单一产品组装
我们只是新增一个快捷收款或者付款到卡这样的单一产品，我们可以直接对 " 接口、业务、支付、账户、收银台 " 进行包装生成一个直接可以销售的产品。
图 14：产品的组件化配置
4.2.2、组合产品组装
图 15：组合产品装配
如果我们要装配一个消金支付、子商户分账的行业解决方案。
我们可以使用组合产品模板来引用基础产品组装出一个产品套件来进行对外销售。组合产品不能直接修改需要跳转到对应的 " 单一产品 " 中修改才能生效。
4.2.3、产品发布
产品经过审核后就是产品的最后发布上架，此时要对产品分发渠道、使用商户和发布资源进行配置，然后完成产品的最终上架。
图 16：产品发布
4.3、产品签约
4.3.1、添加销售产品
商户签约新的销售产品与商户的会员 id 进行关联，然后添加商户所需要的支付产品。
图 17：商户添加销售产品
4.3.2、商户费率设置
图 18：商户费率配置
商户费率的配置维度是按照产品组件的维度作为细分到 " 业务产品 + 支付产品 " 的维度来逐个配置的。如果需要更加细粒度的费率配置，可以在费率模板中增加产品组件来作为费率的配置维度（例如：接口 + 业务产品 + 支付产品 + 账户这样的更加细分的四级维度）。
图 19：费率配置详情
按照产品组件的维度来进行费率配置，费率配置也采用组合模板的方式可以任意添加多个计费项。每个计费项可以按角色来进行计费。费率一般按照 " 角色、目标机构、计费周期、费率类型、阶梯费率 " 等计费因子来进行配置。
五、总结
5.1、产品工厂是企业级架构
产品工厂是一种企业级的产品管理方法，它比较适合成熟的业务体系或者大型机构的产品体系建设。
对于中小机构模板化的产品配置更为经济实惠，因此我们不要盲目的抄产品工厂，而是要学习他组件化装配的设计思想。
5.2、分类因子 + 组合模板
我们遇到的产品配置需求、计费配置需求、规则配置需求都可以用分类因子 + 组合模板的方式来解决问题。就像我们例子中所介绍的产品配置和计费配置一样。
分类因子用来细化和路由产品，组合模板其实就是一棵目录树，他可以循环引用单一产品和计费项，从而生成各种维度的产品。只要你能想到，这套模式都能帮你实现各种维度的配置。（银行、保险几百个产品、阿里云几千个产品都是采用这样的方式来装配）
5.3、科学的目录化产品管理
如果你们公司没有足够的 IT 预算来做这样的产品工厂，那这篇文章给你带来最大收获就是 " 目录化的产品管理思想 "。
你完全可以通过一套 excel 模板来统一管理产品的规划、版本、设计规范和交付资料，这种管理方式小到一个客户解决方案，大到管理全公司、全集团的产品都游刃有余。
图 20：目录化的产品管理方式
- 打印本页 || 关闭窗口
