走出混沌，商业银行参与财资数字化的底层思考

2023年，因为持续的央企司库建设热潮，财资数字化市场热闹非凡，既有金蝶、用友这些头部ERP大厂俯身加入，更有前赴后继的银行、银行系金融科技公司跑步参与。但浮华背后，大厂的经营渡劫，坊间传闻“司库项目做一个亏一个”；银行系“雷声大、雨点小”，深度参与的司库项目了了，更多沦为司库建设的周边。本文尝试站在商业银行视角上，思考财资数字化“看上去很美，现实骨感”的症结所在，并就走出困境给出建议。

司库或财资数字化，Treasury，从字面意义看是企业财务和资金资源的管理，出发点企业管理，为经营服务，是企业关注的核心命题，但为何商业银行表现出如此大的热情？原因是恐惧，支付宝改变C端支付的经历还历然在目；和企业端支付紧密关联的司库和财资自然受到关注，且司库项下的账户和结算意味着低成本存款机会，而随着司库集中管控模式的落地这样的资源愈加稀缺；除此外结算本身还联接着金融，批发金融的入口不能失。

由此，从概念本身和银行参与的基本诉求，可以看到企业视角和银行视角，在产品定位上的底层差异。

聚焦需求本质，财资管理应当是企业针对自身拥有的金融资源的管理行为，定位是企业的管理平台，向交易和金融是一种兼带的场景延伸。而从银行诉求看，银行提供的财资服务，定位更倾斜于银行经营或展业平台。路径上大不同，也就意味着不同的终局。大企业预算充足，可以基于自身诉求，建构纯粹的司库平台，在这一场景下，不管是厂商还是银行，都是软件服务提供商，专业的科技服务才是比拼关键；而腰部客户，更看重综合性价比，让渡一部分客制化诉求和灵活性未尝不可，有性价比的使用银行输出的科技服务，交长期的朋友。存在即合理，但必须回到客户诉求，企业服务才是一切出发点。

关于产品的客群定位，设计者天然有一种惯性，即希望找到更大众的市场定位，客群覆盖足够宽，既支持头部KA类客户复杂需要，同时还能敏捷适配腰部客户轻量需求。但结果往往事与愿违，大众市场未能突破，反而让产品陷入大量不同维度的竞品的缠斗中。

回到财资数字化语境，遭遇是类似的。

司库和财资概念趋同，但中文语境里政策的官方背书，司库被定位为更高阶概念；随之概念被泛化，一时间市面上所有资金管理类产品都鸟枪换炮成了司库系统。司库漫天飞，但央企、头部客户的“司库”和腰部客户“财资”是同样意思吗？

差异巨大。

央企和头部客户的司库，被赋予了极高的管理内涵，目标上要“提高资金运作效率，有效防控风险”，范围上“横向到边，纵向到底”。如此定位，反映在产品功能建构上，要从账户支付结算走向金融资源管理，央企要满足政策确定的11+4标准，民企头部则更务实需要“贴身”定制服务。概括起来，专业纵深、定制化，是核心需要。

进而，为了实现这些需求，一方面需要功能颗粒的足够精细，满足垂直细分需要；另一方面需要底座的健壮且灵活，组件化、配置化，更快捷实现个性诉求。除此之外，还重要大项目的交付管控能力，能够专业疏导和平衡供需诉求，保障项目的有效交付。

就此而言，所有的大型集团客户，似乎只有重项目交付一条路。

其实不然。超级头部央企和全球龙头集团企业之下，大型集团企业仍有较大的产品机会。央企之于国企，民营集团头部之于行业周边，都有着较强标杆效应，做深做透一个客户，往往能够形成产品化复制的机会，交付成本在后续产品化复制里得以有效熨平。所以，司库能否产品化运作，关键在于前期项目客户的选择，是否足够标杆，是否代表未来。做好司库项目，才有司库产品的未来。

广大的腰部客户，是与大型集团客户不同的产品需求。具体而言，腰部客户规模相对有限，尚处于成长阶段，数字化预算有限，对于“司库”的要求，更多是支撑经营。功能层面，狭义的财资功能上关注高频、核心支付需求，但在“薄而全”的泛财资数字化覆盖上有较大期待，希望系统能够集成打通周边“财资税档”生态，一站式服务；交互体验上要去笨重，轻快灵活；实施交付方面，要轻、要敏捷，从而总体上降低财资数字化启动门槛。从这个意义上讲，复杂的司库功能对于腰部客户并不具真实的吸引力，“小脚穿大鞋，冷暖自知”，需要的是更务实具体的财资。

因此，要想赢得腰部客户市场，需要真正的客户视角，对齐腰部客户的商业成功，参与客户的真实场景，知分毫来之不易，“锱铢必较”，真正帮企业快捷高效结算、防控风险、预测资金流，创造价值；而不是不假思索兜售“司库”这顶大盖帽。

除了产品定位，更大的挑战在于底层商业模式。

涉及企业数字化，市面上相对成熟的商业模式，一种是传统软件，一种是SaaS。传统软件的商业模式，是商品买卖逻辑，一锤子买卖，通过大单、大项目实现经营自洽，难点在于交付，因为客户往往有着无穷无尽的定制诉求。而SaaS模式，相对于商品买卖，是一种服务经济，软件还是那个软件，但交易的载体是基于软件的价值服务，非单次合作，经营自洽的关键是持续的滚雪球式的合作展开。两种商业模式，在企业数字化领域占有率上半斤八两，传统软件模式对于交付能力高依赖，往往是人力密集型的，可以生存，但看不到想象力；而SaaS模式，模型很好看，但难在价值的传递和感知，尤其是TO B市场，很多SaaS厂商钱投出去了，却等不到持续合作的到来。

目前，SaaS模式受限于环境、受限于管理职业化，处在历史的冰点期；但站在产业终局的视角，厂商们已经用脚做出了选择，无论是金蝶、用友都纷纷进行了SaaS转型。

回到商业银行的视角，选择SaaS模式更是一种必然。

其一，银行的商业模式就是服务经济，无论是商行还是投行，都依赖于专业服务、价值服务来赢得长期合作。这一逻辑，和SaaS的商业模式有着天然的契合，商业银行愿意舍下血本，参与司库或者财资数字化，根本出发点就是借助财资数字化服务，交个朋友，长期合作，实现长期价值。

其二，不止于SaaS，商业银行还需要在SaaS商业模式基础上，厘清和明确“软件+交易+金融”服务经济新逻辑。即便和数字厂商一样提供软件服务，但因服务内容金融方向上的可拓展性，简单套用SaaS的软件服务LTV模型计算并不适当；金融、交易的介入，其赚钱效率要远高于单纯的软件服务，因此可见现象是银行愿意在财资产品上低价或免费。免费不是不可以，高频的软件服务，带动低频的交易和金融；软件服务免费，金融服务产生价值，也基本上契合了互联网经济“羊毛出在猪身上”模式特征；但随着科技创新的深化，企业服务的投入巨大，产出未必边际效益递减，没有清晰价值计量和内部转移计价，始终一笔糊涂账，最终可能毁掉财资业务和商业模式创新的机会。

站在客观角度上，纵使财资和司库对于商业银行有着极大吸引力，也应该在仓皇推出新产品前，思考清楚产品定位的元问题，否则战术的勤奋无法抵消战略思考不足的带来的深远影响。

首先，财资的产品定位是企业服务。

回归财资和司库本身，企业的结算和管理需求是根本，产品的定位毫无疑问是企业服务。在此前提下，无论掺杂多少商业诉求，都不能偏离根本，都应当从客户需求出发。这也意味着，基于开放银行理念的网银、直联产品，本质是银行经营展业平台；和基于企业服务理念的财资，功能虽相近，但实质不同，难以直接替代。甚至某种程度上，考虑两类产品的长期竞争力，在底层要形成清晰隔离。

其次，金融科技特性，将形成产品竞争力的有效加持。

财资产品定位是企业服务，但所涉及交易结算、金融管理资源，都与商业银行的服务密切相关。金融科技加持下的企业服务，将带来更大的想象空间，比如更安全、更稳定；但两者的开放融合，不能仅限于理念的想象，须借助不同视角的讨论落到实处，这需要在产品队伍结构涵盖企业资金管理、银行产品、技术不同背景。在此方面，蚂蚁集团在搭建企业司库时，对于银行日切和日结模式就是一个很好的范例。

“什么都想做，什么也做不好”，要想破局，需要回到客户本身、市场竞争本身，聚焦主流客群所需，绝不在非战略机会点上浪费战略性的竞争力量。

回到产品建构的视角，须找准生态位，聚焦商业银行本身的客群特性（头部客户、腰部客户，还是小客户）、资源禀赋（品牌优势、产品价格、渠道优势）、价值诉求（长期价值，还是短期变现）上，聚焦市场竞争。虽然商业银行规模巨大，但科技投入总是有限，如果目光不聚焦，只会形成无意义的浪费。

针对战略客户，或超级客户而言，司库建设势所必然。但顶层客户业务多元性、架构复杂性、地域分布的全球性，往往对产品功能要求精细、纵深，客制化属性极强；同时，叠加当前逆全球化趋势下数据和信息安全需要，对于部署方式和软硬件信创也提出了要求。复杂性决定了通用产品很难实现能力适配，需要围绕客户诉求的贴身定制。因此，围绕这类客户最好的方案就是定制化项目交付，大手笔投入，从咨询引导到项目落地，保证诉求的达成；具有一定产品基础当然好，但也要按照项目模式单独部署，避免过重的项目需求对于产品能力形成干扰。考虑这些因素，超级客户的司库项目对于资源投入有极高的要求，对于厂商的产品和专业基础、交付管理都是巨大挑战，客户和项目的选择要足够谨慎，唯有代表未来趋势的客户和项目才有参与价值。

一般的大型集团客户，基于司库产品模版基础上的适度定制。

企业的司库建设，与其说是系统建设诉求，不如说是管理理念升级诉求。并不是所有大型集团客户，都有资源和专业能力像超级客户一样进行司库管理体系周密规划、大手笔建设，更多期待在复制领先性基础上的企业语境适配。于此，产品和技术能力适配就成了最为关键的考量，前述超级项目选择的价值和意义也在此显现。产品上，功能是否具有足够领先性是重中之重，而这正是超级头部客户项目和产品的结合点。超级头部客户的领先管理体系是否得到有效萃取和产品化承载，以及超级头部客户的项目口碑、满意度和推荐度，决定了产品化方案多大程度上能得到客户接纳；反而来也提醒超级项目的选择标准，必须是未来客户和代表未来趋势的项目。技术上，产品化是基础，企业语境下的灵活适配需要技术支撑。技术架构是否稳定、健壮；底层平台是否精细、是否扎实；开发实现能否低代码、配置化；数据权限和体系是否清晰隔离；这些都决定了合作是否会从产品滑向项目的深渊。

腰部客户和更广泛SMB的客户，需要轻量产品+生态集成的一体化服务。

范围广大的腰部客户，追求的是性价比；功能覆盖不求精深，覆盖高频主流场景，支撑经营即可；实施应用门槛要低，最好开箱即用；系统间联接轻便、打通低成本，最好生态一体化。这意味着产品建构“薄而全”，不求纵深，但求宽广，和超级客户、头部集团客户产品建构不同；技术上，更关注门户和接口开放，便于生态集成。

站在开放融合视角上，腰部客户“All in One” 的性价比诉求，让基于银行展业需要和基于客户企业服务诉求的的2种财资平台建设模式一定程度上实现了平衡，都有市场空间和可能性。但未来随着开放银行模式的演进、标准的统一，或许有一天不再需要展业平台，银行站在银行视角下仅仅只需要建构服务和联接管道。

政策驱动，让财资市场颇具想象力，但参与者往往叫苦不迭，产品和项目的低定价，难以收回成本，往往让这门生意陷入无限内卷的死循环。但视野如果更宽广些，各行业的商业模式都在向性价比模式倾斜，汽车行里的比亚迪、特斯拉模式，饮品行业里的蜜雪冰城模式，无不如此。信息技术行业的发展也一样，云计算正在重构IT基础设施，应用构建组件化、服务化，基于需求敏捷编排，竖井式的应用逐渐消弥，因此客户也很难再接受为一套应用承担整个基础设施投入的商业合作。

回到财资，商业追求性价比的大背景下，客户对于司库项目、财资产品追求低定价；而银行作为厂商，面临基础设施成本投入持续攀升压力。是挑战，更是机遇，商业银行可以尝试参照互联网“羊毛出在猪身上”免费定价逻辑，建立起清晰的“软件+交易+金融”服务经济模式，持续量化的ROI监控，就能逐渐塑造出竞争中的领先优势，保障财资发展的健康可持续。

首先，面对超级客户，把项目作为一种投资。

无论是纯粹软件厂商，还是商业银行，在参与超级客户项目时，往往都心有忐忑，希望能够形成明确而具体的商业对价。但这是不可能的，超级客户往往有极高议价权，众心捧月，自然要杀到地板价。与其如此，既没赚到钱，又没换来认可；不如彻底换一种模式，在“软件+交易+金融”的框架下，以做投资的模式做项目。

其一，优选、慎选项目。资源有限，因此项目的选择要谨慎，一求产品价值，只做未来客户，项目必须要能够促进产品优势的塑造，要最终能够核算项目的可产品化率，从而在更长的时间尺度上熨平项目投入；二求交易结算或金融的价值的创造，确定长期的投资回报率目标。

其二，持续的项目投资复盘和运营分析。对于计划参与的财资项目，参照风投模式，建立严格的投决会机制；项目落地过程中通过咨询引导，项目落地后通过服务延展，创造交易、金融机会，创造出价值，在此基础上开展持续的项目投资运营分析。

其次，绝大多数客群，坚守产品化道路，综合定价，在“软件+交易+金融”框架下实现经营自洽。

除了超级客户，绝大多数客户服务应该坚守产品化。尤其是在当前产品基础设施研发成本向厂商的倾斜的情况下，财资产品创新门槛更高，产品化是必然，综合定价更能体现出竞争力所在。但过去综合定价，更多停留在口头，因为内部管理会计核算由于系统割裂、大数据模型和计算能力限制很难落地；但现在，系统对接融合门槛更低、数据埋点已成体系、基于流量的价值计算方式在直播电商领域早有先例可循，因此建立真正意义上“软件+交易+金融”综合计价模型具备现实可行性，通过综合定价的模式，让财资产品的性价比化成为现实，也能真正体现出财资作为公司业务流量入口的可量化的价值。

再次，注重客户成功。服务经济的相似性，让财资涉及的银行金融服务、软件服务都应当对齐客户的商业成功，通过服务经济商业模式的运作，实现持续的价值创造，客户成功带来财资服务繁荣，最终实现财资业务的飞轮持续运转。

声明：仅代表个人观点，与供职机构无关。

作者：杨梦Bruce，个人微信号：southmore