适用场景：城商行理财子公司（含筹建期）在核心系统（TA/估值/投研/风控/监管报送等）选型中的POC方法论第一章：POC的本质认知——不是"看演示"，而是"真枪实弹"1.1 什么是POC？POC（Proof of Concept，概念验证）是在正式采购/立项前，用真实业务场景、真实数据、真实环境，对候选系统/方案进行的小范围、可量化、可复现的验证测试。它与常见概念的本质区别：维度Demo演示POC验证UAT验收目的展示功能亮点验证可行性确认交付质量数据厂商预制数据企业真实数据（脱敏）生产环境数据场景理想化流程核心业务痛点场景全功能覆盖周期1-2小时1-4周2-8周参与方厂商+IT业务+IT+厂商+合规业务+IT+厂商决策价值低（主观感受）高（客观数据）中（交付确认）解释：Demo是"厂商出题、厂商答题"，POC是"企业出题、厂商答题"。在理财子公司场景下，一道"题"可能包含：一只嵌套三层SPV的净值型产品，从募集成立到日终估值、TA清算、监管报送的全链路处理。只有POC能验证这道"题"是否真的能解。1.2 POC要回答的三个核心问题POC核心三问能否解决核心业务痛点？能否与现有系统/数据/流程兼容？实际效果是否达到预期阈值？理财子公司场景:产品募集期资金清算时效净值披露准确性大额赎回流动性管理理财子公司场景:与母行核心系统对接理财登记中心直联报送TA与估值系统对账理财子公司场景:并发认购性能日终批量处理时长异常交易容错率第二章：为什么理财子公司必须做POC？五大核心价值2.1 降本止损：避免"百万级选型失误"行业痛点：理财子公司系统选型失误代价极高——TA系统选错可能导致全量产品迁移（涉及数十万客户、数百亿资产），估值系统偏差可能引发监管处罚和投资者诉讼。POC价值：用"数人·周"的小投入，提前暴露以下风险：功能偏差：如"支持净值型产品"实际仅支持摊余成本法，无法满足市值法估值需求（2024年底监管已明确要求不得违规使用自建估值模型平滑净值，必须采用中债/中证/外汇交易中心第三方估值）性能不达标：日终批量处理超过监管要求的T+1时限集成失败：与母行核心系统接口协议不匹配，导致资金清算延迟案例：某城商行理财子公司在TA系统POC中发现，厂商承诺的"高并发申赎"在真实并发下响应时间超过30秒（行业合理预期应3秒），及时终止合作，避免上线后客户投诉和监管问责。2.2 去伪存真：用"实战数据"替代"PPT承诺"厂商演示的"三大幻象"：最优场景：用简单产品结构演示，回避复杂嵌套产品干净数据：预制完美数据，回避脏数据清洗问题专人操作：厂商专家操作，回避业务人员真实使用体验POC要求：真实验证真实业务数据脱敏后的历史交易流水核心业务流程产品成立-认购-估值-赎回-清盘极限性能测试募集期峰值并发