建设全行级产品工厂：梦想能否照进现实？
文章来源：e路向上，文章仅供个人学习
商业银行在进行核心系统建设时，通常会提出一个目标：建设全行级产品工厂。期待建立全行级产品目录，通过可装配实现产品的快速上线，实现对市场和客户需求的“敏捷响应”。其后面的现实需要，至少有三点：
1）、从全行经营管理角度看，全行产品纷繁复杂，到底哪些产品赚钱了，哪些产品的回报率高，哪些产品具备可复制性、需要加大推广力度等等，需要有全行级的产品目录，及这些产品带来的客户数、低成本负债、利差收益、中收等数据作为量化决策的依据；
2）、于业务和技术而言，“需求、设计、开发、测试、投产”的产品实施周期太长了，能不能通过产品工厂来实现积木式的堆叠，实现对市场、客户需求的敏捷响应，一直是产品经理、架构师和程序员的梦想。
3）、从对中台产品部门的量化考核看，也需要根据产品带来的各种业务数据，对不同产品团队的KPI进行量化考核。
本文从以上三点的关切出发，简单介绍目前业界常见，已经实现的“产品工厂（中心）”都做了什么？探讨常见的产品工厂与银行管理层、业务期望还有什么哪些距离？要趋近那个理想中的“产品工厂”还需要做些什么。
一、“产品工厂（中心）”建设现状
产品工厂概念的提出，首先出现在核心系统，对基础存贷款业务而言，银行似乎总有一种将其复杂化的冲动，比如存款，活期存款可以通过计息方式封装出“靠档计息”、“分段计息”产品，根据结息周期不同封装出“按日结息”、“按月结息”、“按季结息”等不同的“产品”，定期则更加，根据存期可以封装出3个月、6个月、1年、3年、5年等不同的产品，根据存取方式可封装出一堆“整存整取”、“零存整取”、“整存零取”之类的不同产品。
然而拨开重重迷雾，回归实现的本质，最早的一批核心系统架构师，发现，这些产品其实大同小异：对活期存款而言，不同产品进行产品抽象后，真正影响其产品性质的要素无非如下几项：使用的利率种类–固定/浮动（哪一种）；利率浮动周期；结息周期（按天、月、季？）；计息方式–年化利率如何折算为日利率（ACT/ACT,30/360,30/365,ACT/360…）；对定期存款而言，则是存期、起存金额、逾期或提前支取时的设定等等；对贷款产品而言，抽象后的关键要素则包括：利率、利率浮动周期、还款方式、还款日、违约罚息利率、是否计收复利等。加上上一篇文章提及的会计核算科目，通过会计引擎配置化抽象后。架构师发现，只要将这些要素抽象后，即可以快速封装出各种业务需要的“产品”。毕竟，这些产品的底层功能实现大同小异，最差的程序员也知道存入、支取、计息、结息、冻结、解冻之类的实现类对应的方法，可以通过传参的方式实现差异化，对传参不能实现的，也可以通过方法的重载来解决。
于是，“产品工厂”应运而生。现行的产品工厂主要通过对基础产品的关键业务要素（属性）抽象，形成一些基础配件，然后通过配件的组装，来组装出各种不同的要素，再在建立服务合约的过程中，通过产品码，将已经绑定的若干要素带入账户层。其过程大致如下：
从上图容易发现，这里的“产品工厂”，其实更像是一堆抽象后的公共“要素”的集合，与在数据治理中经常提及的“数据字典”倒有几分相似。
而即便是这样的产品工厂，在实现路径上，也有不同的选择。有的银行选择将很多不同类型的产品要素抽象后，建立一个全行级的“配件仓库”，基于这个仓库，再去封装不同类型的产品。而有些银行则发现，存款、贷款的要素区别很大，将其弄到一起，还不如自扫门前雪，各自实现。其模式区别简要示意如下：
依笔者愚见，如果要建设“产品工厂”，2中的实现方式似乎较1要好，理由如下：
1）、存款和贷款实在是两个不太一样的事物，其业务要素除了在计息上有相似之处外，其他要素差别非常大；
2）、系统实现需要考虑人的因素，在2的模式中，可以有存、贷款开发团队各自闭环掉自己的实现–用一个简单的功能模块即可实现，有利于减少沟通成本；
3）、按照奥卡姆剃刀原则，若无必要，勿增实体。1的实现不可避免地需要找个团队专门去维护这个“产品工厂”，可以想见，这个活既增加成本，干这个活的人多半还吃力不讨好；
4）、不符合系统设计弱依赖、松耦合原则。1个全行级的“产品工厂”，如果在实际业务中，具体的业务系统没有建立自己的副本，则一定导致该系统成为依赖中心，一个既不直接对客服务，也不反应资金准确性的系统瞬间变成必须保证绝对高可用的A++类系统。
当然，1的实现也有好处，即有利于形成全行级的产品目录，可以生成统一的产品视图，另一个好处是，对外PR的时候，“企业级”的设计比较容易唬人…
但是，无论是1，还是2，做完了以后，似乎银行管理层还是经常面对一本糊涂账，业务期待中的“敏捷迭代、快速响应”似乎也未出现，要生命力的产品，仍然需要向开发部门提需求（*谢天谢地，还好没有这么牛的设计，不然作为程序猿的一员，可能饭碗不保….*）。要说清楚这个问题，我们需要暂时跳出核心系统，来看看产品到底是什么，银行除了面对核心系统的部门，都还有哪些岗位，他们在关切什么….
二、商业银行产品管理面临的困境
从第一章的描述中，不难看出所谓的“产品工厂”，始终都在围绕“核心系统”，“存贷”产品说事情。然而，显而易见地，银行可不止只有基础的存贷产品，比如，简单列举几类商业银行中的产品：
| 业务品类 | 常见产品示例 |
|---|---|
| 信用证 | 即期信用证、跟单信用证、光票信用证、背对背信用证、备用信用证、远期信用证… |
| 商业汇票 | 票据承兑、票据贴现、商业保贴、商票保证、票据池融资… |
| 企业贷款 | 流动资金贷款、项目贷款、固定资产贷款、设备改造贷款、银团贷款… |
| 个贷 | 房贷、车贷、金领贷、公积金贷、XX贷…. |
| 外汇 | 外汇即期、外汇远期、外汇掉期、外汇NFD、外汇期权… |
| 保理 | 明暗保理、有追索权保理、无追索权保理、正反保理… |
| 贸易融资 | 先票后货、担保提货、存货融资….. |
| 保函 | 投标保函、履约保函、工程承包保函、质量保函…. |
| 支付 | 快捷代扣、普通转账、智能汇路、智能收款… |
对这样一些产品，要将其抽象到第一章提到的“产品工厂”中，显然是不可实现的。稍微分析，很明显可以发现如下问题：
1、当前建设的“产品工厂”，只是部分业务的“产品要素工厂”。第一节“产品工厂”封装出来的“产品”，只是对产品属性的声明与定义，产品工厂本身不实现任何业务逻辑，不能提供任何有价值的服务。从技术角度看，更类似一个可被继承的POJO。也就是说，当前各家银行建设的所谓“产品工厂”，都有货不对版的嫌疑。
2、产品缺乏清晰的定义。《人人都是产品经理》一书中，将产品定义为“可以满足人们需求的载体，产品可以是有形的实物，也可以是无形的服务，还可以是两者相结合。”但在商业银行中，产品概念被极大地泛化了，“存款”、“贷款”是产品、“开放银行”、“银企直连”这一类服务渠道，也是产品。
3、产品建设随心所欲，维度多元。所谓“横看成岭侧成峰、远近高低各不同”，商业银行中，因为部门、团队不同，承担的责任和视觉也就不同，导致在产品定义时五花八门，有按期限来定义产品的，如3个月、6个月期定存，中长期贷款；有按资金用途来定义产品的，如流动资金贷款、项目贷款；有按业务模式来定义产品的，如担保提货、先票后货；有按业务流程来定义产品的，如正向保理、反向保理；有按法权关系来定义的，如应收账款转让融资与应收账款质押融资，有追索权XX，无追索权XX；有按目标客群来定义产品的，如金领贷、白领贷；还有按使用的模型数据来定义的，如税务数据贷、发票数据贷….
4、产品叠加计量，考核懵圈。以保理授信为例，在贸易融资的产品主管部门，设定的是“保理”类产品的某一种，但保理授信的基础出账品种，或是贷款，或是银行承兑汇票，一笔保理授信业务的出账，绩效将在两个产品团队双计。类似的，还有如票据池融资，票据池是出账的担保模式–票据质押，出账基础品种则是开立银承或者发放贷款，同样会造成一笔出账在不同产品团队的绩效双计，如果此时“银企直连”也是个产品的话，则采用银企直连开展业务的“票据池融资”，其产品绩效将被三计。
基于以上一些原因，在商业银行的管理中，多数银行在考核前线销售人员（理财经理、客户经理）时，可以做到数据准确、事实清楚。但对考核产品经理，则部分时候缺乏有效的数据支撑：全行既缺乏统一的产品视图，也缺乏不同产品带来的新增客户数、低成本负债贡献率、资本占用、利差及中收贡献的确切数据，事实上给量化决策带来诸多困扰。
三、几点思考与建议
面对以上困境，仅是在核心建设的时候抽象出一个“产品工厂”，显然无法满足商业银行产品治理的需要，要想把产品管理做的尽量好一些，需要从顶层设计开始，进行综合施策。
1、产品分层分类进行管理。商业银行一般采用条线式管理机制，产品在进行存、贷、汇、兑、金融同业等分类时，因为条线的存在，泾渭分明。但在某一业务领域内，对产品进行分层，首先有利于建立清晰的产品结构，其次有利于回归产品原理，厘清产品创新点，判断产品的实现复杂度，风险构成，合规责任。以负债类和融资类产品为例，以下是笔者梳理的一个简单分层的示意图。从图中可以看出，票据池融资本质是一种以银行承兑汇票（低风险现金等价押品）为质押物的质押类融资，基于这种特点，在产品实现中很容易就可以想到，票据可以质押，存单呢，保证金呢，3A级企业签发的商票及其应付款呢？其实本质上都可以用于质押，票据池可以很容易在产品形态上升级为“资产池”–保证池中的低风险质押物可以覆盖敞口即可。
2、不要试图建立全行级“产品工厂”，代之以建立全行级“产品目录”。考虑到商业银行产品形态的复杂性，跨条线后产品共性少而差异多，因此，建立全行级“产品工厂”事实上是办不到的，已经建立的所谓“产品工厂”，大多名不副实–覆盖产品少、抽象后的作用小。但这不意味着商业银行不需要建立清晰完整的产品目录。在全行级的产品目录中，每款产品都应该进行全生命周期管理，其应该管理的要素不应该试图去抽象业务属性–那是IT开发要做的事，反而应该将以下信息定义清楚：
| 定义内容 | 说明 |
|---|---|
| 产品定价 | 产品的价格：利率、收费 |
| 产品成本 | 产品的资本占用、付息率 |
| 目标客群 | 产品定位，目标客群特征、规模 |
| 竞品说明 | 市场竞品，产品的可替代性、差异化优势 |
| 服务渠道 | 手机银行、网银、直连、电话银行、柜面 |
| 产品文案 | 说明文案、营销文案、签约协议…. |
| 上架时间 | 产品推出时间 |
| 归属部门 | 产品归属哪个部门 |
通过自顶向下的要求，推动产品部门、产品团队在建设新产品时，提前对成本、收益、目标客群、竞品等做充分的分析–即完成5W1H分析，减少产品建设的盲目性、冲动性，减少无效投入。
3、做少而精，避免大而无当。类似的例子不胜枚举，不仅是商业银行，在其他行业也很常见，在iPhone出现前，同一手机厂商的型号动辄几十个，型号命名除了厂家自己，估计没人搞的清楚。在Tesla出现前，汽车品牌也是类似，ABCD先来一轮，再在ABCD中加上100/200/300等等，不一而足，大有不把消费者搞懵圈不罢休之势。而在金融行业，我们可以对借呗、花呗、网商贷、微粒贷、微业贷耳熟能详，但有哪个客户能将四大行的产品立时列举个子丑寅卯？要做精品，显然需要更多的资源投入，产品经理、开发、运营推广资源有限的情况下，选定好产品方向后，坚持持续迭代，持续运营，显然比浅尝辄止更有意义。要做的工作包括：产品建设前期的详细论证，谋定而后动；克制随意封装产品的冲动；谨慎向客户透出没有客户心智的名词–凡是客户听不明白，或是没有清晰定义的名词，都不应向客户透出。
4、有效的绩效牵引。要解决3中的问题，必须依靠有效的绩效引导，只有将产品团队的KPI引导向获客，引导向创造收益，才有可能将产品团队的精力导向产品的持续打磨和持续营运。部分银行产品团队在年终KPI报告时，列举的是一年上线了多少个产品，甚而更离谱的是，将一年上线了多少功能作为自己的KPI，这是典型的将压力转移给IT的做法，用“小步快跑、敏捷迭代”的网红词PUA开发：产品放弃思考，科技埋头苦干。没有ROI的产品，做的越多，越是对银行资源的浪费，在总资源量一定的情况下，无效的产品建设，其实是暴殄银行的资源。因此，建立**产品的后评估体系，持续跟踪产品的获客数、收益率、产品规模，对产品闭环运营，有效激励与考核意义重大。此外，对产品经理、产品团队的有效激励也非常重要，在互联网，打造出一款爆款产品，产品团队的升职加薪自不待言，还很有可能意味着整个建设团队的时来运转，从此走向人生巅峰。在这种强激励下，团队能爆发出的创意、责任感、战斗力自然可以想见。
5、“共享服务”而非“产品工厂”。中国人有大一统的执念，全行级的“产品工厂”，暗合了我们的这种哲学思维。但在系统开发实践来看，最好还是在统一的产品目录下按垂类定义自己的产品要素工厂。在此基础上，对产品的“共享服务”抽象，即“中台”服务的建设，才是关键。全行视角下，统一的核算引擎、统一的额度管控、统一的押品管理、统一的客户视图，这一类与具体业务板块关系不大的服务，可以抽象为全行级共享服务；而在领域内，依靠对Interface的实现，方法的重载，也可以将“余额更新”、“计息”、“还款计划重算”等抽象为公共组件。通过共享，减少重复建设，少造轮子，是实现规模敏捷的关键。
6、所有产品都应该考虑线上化。渠道本身不是产品，UI/UE只是产品设计的一部分，正如普通产品，有线下门店，也有线上商城销售一样，银行的电子渠道，也仅是销售渠道的一部分。随着互联网和移动互联网的发展，及信息化立法的不断推进，具备724小时服务能力，体验好、成本低的线上渠道，应该作为所有产品建设过程中的必选项*–在产品销售过程中，更加侧重线上体验。且最好避免一款产品因为线上和线下的区别，分散至不同部门（商业银行常见的一种分工：数字银行或网络银行负责线上化产品，原来的传统部门则负责线下产品）。这一分工，除了渠道不同，产品的内核：产品的功能、风险控制、定价、资本占用、对外报送，并没有区别。以商业银行一段时间内爆火的“秒贴”产品为例，其核心设计理念是将贴现业务线上化，减少审批环节，达到提交即放款的效果。但贴现利率、贴现功能、贴现的资本占用、贴现占用同业额度的实质其实没有任何改变。秒贴产品的客户体验极好，但秒贴产品上线后，普通线下贴现产品依然在各家银行的产品目录中顽强地存在着–凝重的传统是一种现实的力量。