作者做了多年的企业支付结算解决方案，一致专注于支付结算领域。继前面数字化和中台之后，这篇分享一下作者对该领域数字化建设的思考。希望本文对参与到企业数字化建设，特别是涉及交易、支付结算、财务的同学们有帮助。
这几年做了不少企业支付结算解决方案，作为产品专注于支付结算领域参与了从售前、业务方案、产品设计、开发交付到推广运营落地再迭代的完整生命周期，随着案例增加和自我认知更新，继之前2篇企业支付结算文章后有必要再做迭代更新。
支付：字面意思就是一方付钱一方收钱的过程。基于交易，由买方付钱，卖方收钱，买方消耗自己拥有的资产，权益或债务（理论上只要卖方认可，一切皆可支付，本质上是信任机制下的凭证转移），完成交易支付，包括付款和收款；
结算：交易维度有实际的资金（或资金等价物）转移，财务维度做相应的债权关系转移；
清结算：可以拆解为清分，清算和结算。
企业支付：企业作为买方或买方基于自有资金参与付款和收款，按卖方对象类型是否为企业可分为公对公和公对私支付；
企业结算：企业和服务方做资金结算，完成收入支出，必须满足企业的财务核算规则：交易信息流，资金流，销项进项发票必须做到可一一核算，相互匹配关联；
凭证：分为交易原始凭证和记账凭证，订单，小票，出库单，发货单，发票，高铁票等都是我们常见的交易原始凭证；记账凭证根据原始凭证填制，记载经济业务简要内容，确定会计分录，作为记账依据的会计凭证。
对账：账证实（交易账务，交易凭证，实物/资金）的核对，本质上是为了确保同一个事务的数据描述在不同业务或系统下记录一致而进行的相互之间的一致性比对（对比的对象可以是单据或账户，对比的维度可以是明细，总数或计算后的统计数据）；
账单：统计账证实流水，周期性的生成流水清单，便于买卖双方按需了解和确认交易，收付和履约等相关情况；
渠道和路由：支付结算需要有处理来源，谁提供处理服务谁就是渠道，有多条支付结算处理源时，就需要做路由，基于路由规则（静态或动态规则）明确走哪条渠道实现支付结算。
我们把企业经营按管理到执行从上到下，拆分为战略，经营模式，业务能力和流程，然后基于和支付结算业务的关联度，重点放在业务能力和流程上面。
战略：支付结算作为企业业务交易的一环，可弱化对企业战略的洞察要求，了解即可。
经营模式：
业务能力和流程：梳理出企业经营中和上下游及内部的核心业务能力，这里以制造类企业为例梳理了主业务能力，和业务对象，业务流程，企业组织架构的关系（这点对后续业务架构，数据架构设计，系统上下文串联非常重要）。
财务：财务这块，之所以单独拎出来，主要是考虑到：
作为企业支付结算产品经理，个人认为对财务的认知，思维上需要对企业的经济活动有财务角度监督和核算的思维；专业上对初级会计内容要有基本熟知，可以和财务人员做方案沟通，下面是个人梳理的支付结算产品要懂的财务知识。
基于企业经营业务能力，对象和流程梳理，可以梳理出完整的收付款业务能力，对象和流程，并结合企业实际业务场景和数字化程度，形成完整的企业支付结算业务架构。
下面按业务目标，业务场景，业务架构来具体说怎么形成业务方案。
支付结算产品定位上用来更好的支撑企业完成交易收钱和付钱的闭环（业务交易闭环，财务监督和核算闭环）；有效并灵活的支撑交易在线（满足企业服务可以灵活的触达B端和C端用户，特别是新业务的在线交易）；通过搭建标准的支付结算服务，可做快速技术对接，不再需要烟囱式的开发，降本增效；当企业经营业务不断通过标准的支付结算服务产生交易数据，可以不断的产生从交易，支付结算，发票到账务的完整数据，以实现数据赋能业务打好基础。
从业务模式的角度看，其实就是业务参与方的利益分配，我习惯用交易对象的角度来锁定业务，分为双方交易和多方交易（双方交易的多个组合），双方交易好理解：就是交易的生命周期中只有买方和卖方2方参与并完成（比如街道上摆菜摊的大妈，我付现金买菜）。
多方交易理解为：交易的生命周期中有多方参与，形成了多个“双方交易”才能完成交易闭环，最典型的就是电商业务。
以淘宝为例，涉及的参会方一般会有平台、商家、快递公司、用户、收单支付机构等。
明确完交易对象，可以更好的理解涉完成一个交易场景，涉及多少交易业务，理解基于交易怎么做支付、分账、结算、发票和税要怎么走。
下图是典型的BBC平台交易：
一般分为按单/合同结算和对账结算，按单结算主要是电商场景，交易订单完成履约闭环后，结算给商家对应的订单货款（可提现）；对账结算主要是企业之间的结算，需要周期性的生产账单进行账证实的核对，完成核对后确认账单并进行付款结算，比如我们常说的日结，月结，企业越大，溢价权越高一般结算周期更长。
企业间交易使用先货后款为多（有自己的授信体系，详细可见企业数字化系列——授信业务数字化设计），很品牌溢价权的则喜欢现款后货，收取预付款；另外除了支付现金外，在大宗交易场景，存在很多票据支付的情况。
业务架构的核心作用是在了解完企业所有的经营业务，对象和流程后，可以梳理清楚所需的完整业务能力，并未后面的产品设计打好业务框架。
下面支付结算业务架构覆盖了一般企业全渠道业务在线运作所需的支付结算业务：
基于业务架构，切入场景，搭建产品架构，并按领域驱动设计方法论对支付结算产品架构做领域划分和中心设计。需要对底层的数据和基础技术有系统性了解。
业务需要边界，产品和开发设计都需要边界，这是我理解的领域概念，作为支付结算产品，就应该做好支付结算领域内的事，什么都做就等于什么都没做，好的领域设计要确保独立性和可扩展。
我把领域设计分成2个维度，横向的业务领域，通过定义不同的业务对象做区分；纵向的架构领域，通过分层来解耦业务对象处理问题的复杂性（业务驱动领域设计，so不是业务领域，分层设计越多越好，比如只通过微信小程序试点自营商城业务，为了快速验证业务，只需要能做微信小程序支付足以）。
当了解了企业客户的整体业务和后面的战略规划后，就可以规划需要做哪些业务领域的设计来支撑当前业务，又满足后面的可扩展（需要平衡效率和成本，分的越细，技术上分布式事物的一致性设计越复杂，产品上看新业务的验证和打磨更关键）。
支付结算领域，正常都会分为支付，清结算，对账，账户，计费和财务集成，下面拿一笔企业交易的整体流程形成完整的业务上下游闭环。
其中：
商户就是参与到交易的交易对象，基本分为个人，企业和个体户，账户都需要关联到对应的商户下面（按账户权限做商户认知，比如收单特殊商户需要做实体认知）。
我理解的业务架构，通过层级来定义同1个业务的输入和输出边界，通过模块来定义同一层的不同能力或者服务，比如很多架构都会有应用层，逻辑层或物理层等。
对于支付结算领域来说，个人习惯应用层，逻辑层到核心层的3层或2层设计，应用层做服务的输出，逻辑层做业务解析和领域内的逻辑处理，核心层定义业务对象的核心能力和属性。
以聚合支付服务为例，应用层就是标准的聚合支付服务接口输出，外部应用通过调用接口获取聚合支付服务，获取到支付的业务订单数据后做业务解析，明确收付款方，支付方式等信息，通过支付路由规则明确支付方式对应的渠道。
有些场景（比如组合支付）还涉及逻辑的处理（组合支付需要基于主支付订单，拆分多条支付渠道流水，并要求所有的支付渠道流水成功才算组合支付成功），核心层就是拿着明确的支付方式，支付渠道，收付款方和金额等信息调用支付渠道做最终的支付处理。
业务驱动支付产品设计。
企业支付结算平台只是工具，要给企业带来价值，需要有业务主人（一般需要由专职财务，产品和市场业务人员组成专项组织）基于平台的功能和对外服务做运营推广，迭代优化和数据服务赋能企业管理层决策。
运营主要包含企业金融资源对接，支付结算渠道管理，异常数据监控。支付结算平台搭建后，只有不断的服务好新的业务场景，才能不断给企业产生价值。推广过程主要包含：
注意点：
1）基于自身定位，需要明确业务，财务，金融渠道和支付结算平台的边界，一旦涉及平台范围外的需求，产品层面需要和项目经理或相关领导确认，该走什么流程就走什么流程；
2）作为多方参与集成开发，接口说明和联调测试非常重要，尽量在前期就把问题暴露出来；
3）上线方案必须多方一起确认，可能涉及历史交易数据迁移；
4）早期支付结算平台搭建，可以弱化风险管控，主要针对异常交易数据做监控，主要是：
随着支付结算平台推广的交易场景增多，会源源不断的产生支付结算数据，可以通过几种形式输出数据服务：
1）周期性的输出各种类型的支付结算数据报表供企业财务和业务方查看；
2）提供数据给企业统一的数据平台（数据中台，数据湖，数据仓库等）；
3）监控异常数据，输出异常数据分析报表，来优化产品，对接更安全有效的支付结算渠道，优化业务交易和财务中可能存在的风险；
4）提供统一的上下游交易数据核对服务。
支付结算平台准守MVP产品的迭代思路，以满足切入的具体场景需求来定义搭建的服务能力。
迭代的整体思路按平台的纵向专业能力和横向推广能力推进，其中专业能力按各领域中心自身规划需要的完整服务能力迭代，横向主要结合业务场景推广会对接更多的金融资源，提供更多的支付结算服务选择。
这里还是以HE集团为例，作为国内最大的几家家电企业之一，企业战略上开始从传统分销到赋能分销商，直接触达终端客户提供零售服务的转型，通过企业数字化，实现库存在线，交易在线，资源在线，营销在线和组织在线，以更好的支撑服务多元的交易场景，尝试新的服务业务，通过标准化业务获取完整的有效数据，并驱动数据赋能业务。
支付结算以开发平台的产品形态，统一对接金融和企业授信，返利等资源，输出标准的支付结算和账户服务来满足2B,2C的不同交易场景。
业财一体的核心在于业务对企业经营要有财务思维，你可以理解为企业所有的经济活动，理论上都可以按财务规则翻译并做账务处理，因此不是说企业数字化后才开始有业财一体，而是之前企业业务和财务割裂，很多企业只有到算总账时候才发现不是业务没有账，就是记账业务说不清楚，分析起来也是因为统计口径不同，错误百出。
同时财务只注重管控，做的是核销的人力活，特别是月底结账，出季度年度报表的时候，苦不堪言，因此业财一体的另一个核心在于财务要对企业经营心里有底，从财务管控到财务经营，赋能业务。
支付结算平台一般切入企业全渠道销售场景，上下游分别有具体的业务交易履约和财务账务，资金结算场景，是业财一体非常好的切入点和基础服务，让各种交易凭证（订单、出入库单、发票、下票等），资金支付结算流水，记账凭证可以基于具体的交易场景和节点自动关联，完成核算。当然也可以从财务主数据管理，搭建统一的预算费用平台等切入点出发，逐步实现业财一下化。
企业支付结算产品从战略角度是企业数字化转型的一环，因此整个产品规划和设计的核心依赖于企业数字化战略和搭建方法论（比如企业架构框架TOGAF），同时从专业角度，企业结算，财务基础和中国支付清结算体系又是必须要账务的，最后才是基于企业的实际经营情况出解决方案，迭代落地。
本文由 @哈哈的鲸鱼 原创发布于人人都是产品经理。未经许可，禁止转载。
题图来自Unsplash，基于 CC0 协议
该文观点仅代表作者本人，人人都是产品经理平台仅提供信息存储空间服务。
此内容由惯性聚合(RSS阅读器)自动聚合整理，仅供阅读参考。 原文来自 — 版权归原作者所有。