资深产品经理，负责核心交易能力、招采与 SRM、银行融资对接、数据运营及行业 AI 方向的产品规划与落地协同。
产业互联网｜2023.10 至今
企业采购、商品交易与融资的一体化平台
围绕企业采购和大宗商品交易，把交易底座、招采协同、供应链金融和经营数据放进一套平台持续建设。
银行项目上线首月业务规模近 3 亿元；核心品类 GMV 阶段增长 150%+。
01
背景与难点
先说明为什么要做
业务背景
平台同时服务采购企业、供应商、运营人员和银行等外部机构，业务跨越商品、合同、资金、仓储物流和票据，既要满足线上交易，也要兼顾线下行业规则。
主要难点
业务链路长、参与角色多，不同品类的交易与履约方式并不一致；银行项目还涉及建档、授信、放款、还款和文件传输等跨系统状态同步。
核心使用者
- 采购企业：完成寻源、合同与采购执行
- 供应商：管理商品、报价、订单与履约
- 平台运营：处理商家、交易、异常与经营分析
- 银行及金融机构：接收业务数据并反馈融资状态
产品目标
- 01先建立可复用的商品、订单、合同与履约底座
- 02让招采、内采商城和融资共用同一套交易数据
- 03让银行融资状态在平台内可查询、可跟踪、可处理
- 04通过埋点和看板看清商家经营与交易转化
02
业务流程
业务怎么流转，产品负责到哪里
寻源与准入
供应商分级、询比价、招标
合同与订单
线上合约、商品批次、订单
支付与履约
支付结算、仓储、物流
开票与对账
发票、结算单、经营数据
融资与还款
银行申请、审批、用信、还款
流程图展示主链路；各节点涉及的状态、异常处理、接口和后台配置，在下方“产品判断”和“方案落地”中展开。
03
产品判断
我如何把问题转成产品方案
01
看到的问题
招采、商城和大宗交易各自提出需求，容易形成多套订单与商品逻辑。
我的判断
先统一交易对象，再保留不同业务的规则差异，比按项目分别建设更可持续。
落地方案
抽象 SPU / SKU / 批次、订单、合同、履约和结算对象，用配置与业务类型承载差异。
02
看到的问题
融资若只是跳转银行页面，平台无法掌握客户进度，也难以处理失败。
我的判断
融资应作为交易后的连续业务链路，关键状态必须回到平台。
落地方案
设计建档、申请、审批、用信、还款及文件传输状态，并补充失败原因与人工处理节点。
03
看到的问题
系统上线后只有交易结果，无法解释商家为什么转化或流失。
我的判断
数据设计要跟产品方案同时进行，不能等上线后再补。
落地方案
围绕商家入驻、发品、询价、下单和融资规划 95 个核心埋点及经营看板。
04
方案落地
我具体负责并交付了什么
- 01
梳理商品 SPU / SKU / 批次、订单、合同、支付结算、仓储物流、开票和客户关系，明确对象关系、状态流转及异常处理。
- 02
建设供应商分级、询比价与招标、线上合约、SRM 进销存和集团内采商城，打通采购协同与交易执行。
- 03
对接应收账款电子债权凭证与邮储银行信贷，覆盖企业建档、融资申请、审批结果、还款状态和文件传输。
- 04
规划 95 个核心埋点、商家经营看板和运营驾驶舱，用交易与行为数据支持运营判断。
- 05
参与行业 AI 产品规划，将合同、商品和经营数据等场景拆成可验证的产品能力。
主要交付物
业务流程与产品架构交易及履约规则银行接口与状态方案招采 / SRM 产品方案数据指标与埋点方案
05
结果与复盘
结果、能力证据与下一步思考
统一交易对象
将招采、商城和大宗交易共用的商品、合同、订单、履约与结算对象先统一，再处理品类差异。
补齐银行状态
把建档、申请、审批、用信、还款和文件传输做成平台内可跟踪状态，并为失败保留处理入口。
同步建设数据口径
在功能设计阶段规划 95 个埋点和经营看板，没有把数据工作留到上线之后。
项目结果银行项目上线首月业务规模近 3 亿元；核心品类 GMV 阶段增长 150%+。
项目复盘
这个项目最重要的不是功能数量，而是先建立统一交易底座，再让招采、融资和数据能力围绕同一套业务对象生长。后续若继续深化，我会进一步补齐不同品类的履约模板和跨系统异常监控。