销售大表 v1.0→v1.1 复盘：瓶颈会转移
销售大表自动化 v1.0 把拼表 4 小时压到 10 分钟，但总耗时只省 30 分钟——瓶颈转移到开票数据。复盘与教训。
本节要点：v1.0 把拼表 4h 压到 10min，但总耗时只省 30min；瓶颈转移到开票数据源；半自动化 + 痛点转移也是胜利，别等全自动化。
v1.0：方向对，效果小
销售大表 v1.0 做了 3 件事：
- 金蝶导出 1565 行自动解析
- 内销/外销分类 100% 验证通过（338/1226）
- 按固定 schema 生成大表
拼表环节从 4 小时压到 10 分钟。信心满满交付。
结果销售会计反馈："只省了 30 分钟。"
为什么只省 30 分钟
拆解 6 小时分布发现：
| 环节 | 改造前 | v1.0 后 |
|---|---|---|
| 金蝶导出整理 | 1h | 10min |
| 产品归类 | 1.5h | 1min（v1.1 关键词） |
| 销售模式标注 | 0.5h | 1min（v1.1 自动） |
| 客户结算方式 | 1h | 1min（v1.1 对照表） |
| 开票信息补全 | 2h | 2h（没动） |
| 核对 | 微 | 微 |
瓶颈在开票信息——金蝶里没有，要去国税系统/中天易税云查，手工抄。v1.0 只能消化金蝶数据，消化不了开票系统。
瓶颈没消除，只是转移了。
v1.1：把能做的做到极致
v1.1 在 v1.0 基础上做了 4 件增量：
1. 产品类别关键词匹配
产品名出现"口红/眼影"→ 彩妆；"面霜/精华"→ 护肤；"沐浴露"→ 个人护理。
1565 行中 7 行未匹配 = 99.5% 自动识别。未匹配标"待确认"，人工 5 分钟。
2. 销售模式自动填
按客户档案标 OEM / 自有品牌。
3. 43 客户结算方式对照表
43 个老客户的结算方式建对照表自动带入。踩过格式坑：全角/半角括号兼容（客户名里"（北京）"vs"(北京)"）。
4. 收入科目编码参考
7 个收入科目（主营业务收入-内销/外销/视同/其他业务收入…）做成参考表。
v1.1 把金蝶能做的全部做掉。剩下的开票，是第 2 个工具的事。
最大的教训：瓶颈会转移
这次最大的认知：自动化不是"省总时间"，是"把瓶颈挪到下一站"。
改造前：拼表 4h（瓶颈）→ 开票 2h
v1.0 后：拼表 10min → 开票 2h（新瓶颈）
总时间从 6h 降到 2.5h，但瓶颈还在，只是位置变了。
如果只盯着"拼表"做优化，永远省不到 2h 以下。要再省，必须攻坚开票系统（RPA 或 API）。
半自动化也是胜利
很多人卡在"要做就做全自动化"，结果啥都不做。
v1.1 的诚实定位：半自动化 + 痛点转移。
- 拼表全自动 ✅
- 开票半自动（工具铺好框架，人工补开票）
- 总耗时从 6h → 2.5h，省 58%
不是 100% 自动，但已经够省。先把能做的做掉，再慢慢攻坚剩下的。
工具形态判断
收入成本大表 = 典型的外部数据 EXE 化：
- 数据源：金蝶（固定 Excel 导出）✅ 单系统
- 规则：产品关键词 + 客户对照 + 科目映射 ✅ 可成文
- 输出：大表 Excel ✅ 结构化
三项全中，Python EXE 单机最合适。已交付 v1.1。
实测数据
| 指标 | 改造前 | v1.1 |
|---|---|---|
| 拼表耗时 | 4h | 10min |
| 产品归类准确率 | 人工，月错 5-8 行 | 99.5%，7 行待确认 |
| 总耗时（含开票） | 6h | 2.5h |
| 销售会计反馈 | — | 方向全确认，瓶颈在开票 |
下一步
v1.2 计划：攻坚开票数据源。
- 选项 A：国税系统 RPA（技术难，合规风险）
- 选项 B：中天易税云 API（如果有）
- 选项 C：开票数据前置录入（业务流程改造）
等销售会计提供国税/中天易税样本，再定方案。
给同行的建议
- 自动化前先拆时间分布——知道瓶颈在哪
- 别等全自动化——半自动化 + 痛点转移也是胜利
- 瓶颈会转移——第一站做掉，盯下一站
- 格式兼容坑（全角/半角括号）写进对照表
本节要点
- v1.0 拼表 4h→10min，但总耗时只省 30min（瓶颈转移到开票）
- v1.1 把金蝶能做的做到极致：99.5% 产品归类 + 43 客户对照
- 自动化 = 瓶颈挪站，不是省总时间
- 半自动化 + 痛点转移也是胜利，别等 100%