左手ERP,右手监管平台:软件厂商如何与自己竞争?

《穿透式监管的另一面》· 第三篇｜厂商内部的经营协同

一家公司，既卖ERP，也卖穿透式监管平台。客户提出新需求，两支团队却可能给出两套方案。

ERP团队说，业务和数据都在原系统里，升级更直接。监管团队说，客户还需要跨企业、跨系统分析，应该引入专门平台。

两边都有理由，也都承担经营指标。问题随之出现：客户到底需要什么，谁来作出取舍？少卖产品的团队，又怎么算贡献？

以下用重构情境讨论产品协同，不对应任何具体企业。

对同时拥有这两类产品的厂商，难点可能不在于方案做不出来，而在于最合适的方案，需要有人少卖一些、有人多配合一些。

一、技术分歧背后，还有一笔经营账

ERP团队服务客户多年，熟悉业务，也承担原系统的交付和运维。监管团队需要新场景验证产品，形成项目收入。

客户只升级ERP，监管团队可能失去一个机会；客户买独立平台，ERP团队可能需要开放接口、解释数据，却得不到相应的业绩认可。

这时，“产品怎么组合”很容易变成“项目归谁”。

当考核只承认本产品线的签单额，推荐更适合客户的方案，可能反而损害团队的短期利益。

所以，一张分层架构图能解释产品怎么配合，却不会替任何团队承担销售指标，也不会自动解决配合工作的预算。

二、先分清能力，再决定放进哪个产品

先把客户需要的工作分开。例如，业务发生时的付款控制、跨企业的异常交易分析，以及风险核查后的整改复核，未必需要由同一个产品承担。

已有系统能做的就验证复用，不足的再改造或补充。ERP可能提供跨源分析，独立平台也需要证明增量价值，不能按产品名称预分高低。

内部应先形成一份共同认可的能力边界，再报价。但边界清楚以后，还有一个更难的问题：按这个方案做，各团队的投入和贡献怎么算？

三、协同要同时改动方案、项目账和责任

第一，对客户只有一份统一方案。

明确客户责任人和总体方案责任人，由其统筹范围、报价、接口前提和验收结果。专业团队分别负责业务控制、数据接入、模型分析等工作。

“一份方案”不是禁止比较备选路径，而是由一个责任人组织比较、明确取舍，不让两支团队各拿一份未经协调的建议对客承诺。

否则，甲方既要评价产品，还要替供应商协调内部意见。

第二，把共同投入和协同贡献一起算清。

接口开发、字段解释、数据映射和公共组件维护，都需要预算。某支团队承担工作，就要有相应的成本安排和贡献确认。

例如，ERP团队发现了超出自身产品范围的需求，主动引入监管团队，又承担接口配合。如果最后只按各自软件签单额算业绩，这种主动协同就可能成为一笔“不划算”的生意。反过来，监管团队参与场景分析，最后证明只需升级ERP，它的专业投入也不应因为没卖平台就被抹掉。

可以根据公司实际采用贡献确认、内部结算或联合考核，但至少应在报价前说清：谁牵头，谁投入，哪些工作进入项目预算，协同贡献如何认可。不是平均分账，也不是把同一笔合同收入重复计算。

项目经济账还要看定制开发量、后续维护和公司整体收益。能满足同一目标的方案，应同时比较客户长期成本和厂商实际投入，不能只把两条产品线的报价相加，也不能用未经验证的未来收入填平当前成本。

第三，把跨团队故障责任写清楚。

模型报出重复付款，原因可能是业务状态、同步延迟或规则未更新。客户需要有人负责组织定位和恢复，而不是听三支团队分别证明自己的模块正常。

业务系统升级、字段改变或监管口径调整时，也要有人通知、修改并完成回归验证。公共能力必须有长期维护人。

项目中的定制功能，后续是否沉淀为共享组件、进入哪个产品版本，也要有明确的决策责任，避免相似需求在不同团队反复开发。

四、最能检验协同的，是允许谁少卖一些

设想一家集团已有财务和司库系统，贸易、采购分布在不同系统，希望先做付款控制、异常交易识别和整改跟踪。

联合团队先用经授权脱敏的样本验证能力，再确定产品组合。假如付款控制可以复用，异常交易识别需要新增分析组件，整改流程仍由现有系统承接，就按这个范围组织交付。

这时，ERP团队承担数据接口和业务解释，监管团队承担新增分析及模型说明，项目负责人统筹整体结果。接口开发与后续维护纳入预算，各方按约定确认贡献，而不是把配合任务无偿压给另一条产品线。

如果验证后发现，只增加少量规则就能满足需求，项目就应当允许简单交付。

如果客户确实需要新的跨源分析能力，原产品团队也应有动力配合，而不是把所有业务迁回自己的系统作为前提。

这里最值得检验的，是公司能否作出一种取舍：某条产品线少卖一些，公司仍认可它为客户和整体交付创造的价值。

五、管理者可以检查四个结果

• 面向客户的方案，是否只有一个有效版本？
• 公共接口和数据工作，是否有明确预算？
• 跨团队问题，是否有人负责到底？
• 共享组件和模型，是否有后续维护人？

这四项结果，比开了多少次联合售前会议更能说明问题。

客户的问题可能跨越产品边界。拥有多条产品线的价值，就在于能够作出合适的组合，也能够主动删去不需要的部分。

产品协同最后要回答的是：当最适合客户的方案，不符合任何一条产品线的单独利益时，公司能不能作出决定，并把它交付出来？