00 · 方法论与思维框架¶

这是整套指南最重要的一篇。如果只读一篇，读这篇。如果时间紧，至少把"心法"四节看完。

一、先搞清楚：你这次是什么角色¶

业财一体化项目里有三种"调研顾问"，做法天差地别：

类型	任务	价值产出
A 类·访谈员	收集需求，整理成文档	一份需求清单
B 类·业务顾问	梳理流程、给优化建议	流程图 + 优化方案
C 类·数据架构师 ⭐	重构数据模型与钩稽规则	数据血缘图 + 钩稽规则 + 数据字典

这次项目是 C 类。从文档原文的措辞就能看出来：

"完全重构数据源、数据关系及业财联动规则" "数据建模思维、逻辑重构能力" "目标数据钩稽关系图"

C 类的特征是： - 不只问"业务怎么做"，更问"这个数从哪来、怎么算、被谁用" - 不只画流程图，更画数据流图 + ER 图 + 血缘图 - 输出物的核心不是 Word，是 结构化的表/图/规则

⚠️ 典型错误：拿 B 类的方法做 C 类的项目，最后输出一堆流程图，开发拿到说"这没法落地，我不知道每个字段从哪个表来"。

二、心法（最重要的四条）¶

心法 1：永远跟着"数据"走，不只跟着"流程"走¶

业务顾问的思路：

"营收是怎么填报的？由谁填？什么时候填？要审批吗？"

数据架构师的思路（叠加在上面）：

"营收这个数，字段名是什么？数据类型是什么？
输入时和哪些字段做了关联校验？合同号、项目号、客户号怎么对上？
一旦填错，下游哪些报表/计算会受影响？
这个数被改了，有没有版本记录、谁改的、为什么改？"

记住一句话：每一个业务动作，背后都是一次数据的写入或变更。你的工作是把动作翻译成数据事件。

心法 2：警惕"假数据源"¶

一期项目最常见的坑：报表上有个数，但这个数其实是人工拍上去的。

举例：营收汇总表里有"已确认营收"列，看起来很正经，但追溯下去发现： - 财务每月在 Excel 里手工算出来，导入系统 - 系统里那个"营收确认单"模块从来没人用过 - 报表上的数和单据完全脱节

你的第一周最重要的工作：把所有关键报表的每一列，追溯到最原始的业务单据字段。追不到的，就是"假数据源"，是二期最该重构的地方。

心法 3：人机结合点 = 不可自动化的判断点¶

文档反复强调"人机结合点"。这个词的本质是：

哪些步骤需要人类的判断/经验/责任，哪些步骤只是机械的传递/计算？

判断三问： 1. 这一步如果错了，谁负责？ → 有责任的环节，人工保留 2. 这一步需要看系统外的信息吗？（市场、关系、政策） → 需要外部信息，人工保留 3. 这一步的规则能写成 if-then 吗？ → 能写出来的，系统自动

人机结合点不是"用户体验问题"，是"权责设计问题"。

心法 4："业财一体化"的本质是双口径¶

很多人以为业财一体化 = "业务系统和财务系统打通"。错。

真正的业财一体化是：同一笔业务，同时按管理口径和财务口径自动生成两套数据。

业务事件	管理口径	财务口径
客户签合同	项目立项、产值任务下达	合同登记，暂不入账
完成里程碑	产值确认（按完工进度）	收入确认（按权责发生制）
客户付款	项目回款率更新	银行存款增加，应收减少
内部转产	部门产值结算	不影响公司损益

二期要重构的，就是这套"一动作两口径"的自动转换规则。这是项目的灵魂。

三、思维模型：四象限法分析每个业务点¶

每遇到一个业务环节，套这个矩阵：

                ┌──────────────────────────────┐
                │       数据来源是否清晰         │
                │                              │
                │  清晰              不清晰     │
       ┌────────┼──────────────────────────────┤
   清晰│        │                              │
       │  象限① │  象限②                       │
   规则│  保留  │  补充数据采集                │
       │        │                              │
       ├────────┼──────────────────────────────┤
       │        │                              │
   不清│  象限③ │  象限④                       │
       │  补充  │  重新设计                    │
   晰  │  规则  │  （整个流程要推倒）           │
       │  定义  │                              │
       └────────┴──────────────────────────────┘

象限①：现状 OK，保留。少
象限②：规则清晰但缺数据 → 在前端加字段、加单据
象限③：数据有但规则模糊 → 工作坊上要逼出明确规则
象限④：双失 → 这里是整个项目的"重灾区"，重点投入

每访谈完一个业务点，给它标个象限。访谈本上画一栏"象限"。

四、从访谈描述到数据模型：五步抽象法¶

这是最关键的硬技能。访谈对象不会主动告诉你"实体、属性、关系"——你得听出来。

示例：访谈营收会计，对方说：

"我们这边营收要按项目记，一个项目下可能有好几个合同，合同里又分阶段付款。每次客户验收一个阶段，运营那边给我一张验收单，我根据验收金额做收入确认。但有时候验收完客户不一定按时付钱，我得跟应收账款挂上。"

五步抽象：

找名词 → 项目、合同、阶段、验收单、收入确认、应收账款、客户
找动词 → 验收、确认、挂账
画关系 →
项目 1:N 合同
合同 1:N 阶段
阶段 1:1 验收单（实际上）
验收单 1:1 收入确认
收入确认 1:1 应收账款
找属性 →
验收单：阶段号、验收金额、验收日期、客户签字人、验收附件
收入确认：确认金额、确认期间、对应合同/阶段、是否含税
找规则 →
"客户验收 → 系统自动生成收入确认" 是自动联动？还是要财务人工触发？
"应收账款的账期" 从哪天算起？验收日 or 收入确认日 or 合同约定日？

这五步必须当场和访谈对象确认完。不能"回去再整理"。

五、行业特殊性（中核设计单位）¶

不是设计院出身可以快速补的几个点：

1. 收入确认方式：完工百分比法¶

设计院的项目周期长（1-5 年），不能等项目完成才确认收入。 - 按里程碑：每个阶段验收按比例确认 - 按工时投入：累计投入工时 / 预计总工时 × 合同金额 - 按完工进度：第三方造价师评估

二期数据模型里必须有"完工百分比"这个核心字段，并定义它的算法和刷新频率。

2. 项目分级管理¶

中核体系一般有 A 级（重大）、B 级、C 级项目，审批权限、审计要求、报表频率都不同。数据模型里必须有"项目级别"维度。

3. 集团报表合并要求¶

设计院作为子单位，要按月/季度向中核集团报表。集团口径 ≠ 单位内部管理口径。这是数据模型里要预留的转换规则。

4. 产值 vs 收入¶

设计院特有的概念： - 产值：内部考核口径，反映工作量，按完成进度自己算 - 收入：财务口径，按权责发生制和合同约定确认

二者经常不一致，要在数据模型里独立维护，但有联动规则。

5. 委托单文化¶

设计任务在内部部门间流转通过"委托单"。委托单是产值结算依据。委托单的状态机（下达→执行→交付→确认）是项目数据模型的核心之一。

⚠️ 这五点如果你不熟，第一周一定要找个院里的老业务（不是 IT、不是新人）当面问清楚。问错对象会被带歪四周。

六、判断自己有没有"上道"的三个信号¶

第一周结束时，你应该能做到：

✅ 能画出现有系统的核心数据 ER 图（哪怕粗糙）
✅ 能说出至少 3 个"假数据源"（报表有但源头是手工）
✅ 能识别出至少 5 个"象限④"业务点（数据+规则双失）

如果第一周结束这三条都做不到，赶紧停下来反思——大概率是你还在用"访谈员"的方式做事，赶快切换到"数据架构师"模式。

七、最后：你要不停问自己的三个元问题¶

整个 4 周，每个访谈、每张表、每条规则都用这三问检验：

这个数据，未来从哪里产生？（数据源问题）
它流转到哪里，被谁用？（数据消费问题）
谁有权改它，改的时候留什么痕迹？（数据治理问题）

回答不出来的，就是没调研完。

下一步 → 01 · 四周工作节奏