1.1 我先学会把公司看成一门生意
我第一次参加云枢科技的经营会时，几乎每个部门都带来了好消息。
案例说明：云枢科技、订单、经营会议和数字均为虚构教学设定，用于展示分析过程，不代表真实企业经营结果。
市场完成了线索目标，销售的新签合同额超过计划，项目团队启动的项目数量也没有落后。客户成功负责人说，大部分工单已经在规定时间内处理。轮到财务时，会议室却安静下来：公司比去年更忙，项目毛利正在下降，客户付款也越来越慢。
| 部门 | 当月汇报 | 单看这个数字会得到什么印象 |
|---|---|---|
| 市场 | 活动报名和线索数量超出计划 18% | 获客表现很好 |
| 销售 | 新签合同额完成计划 112% | 增长正在加速 |
| 项目 | 新启动项目数量达到计划 | 交接没有明显问题 |
| 客户成功 | 工单按时处理率 91% | 客户问题大多得到处理 |
| 财务 | 项目实际毛利下降，应收账款周转达到 76 天 | 增长质量在恶化 |
如果我只听前四个汇报，会觉得公司应该继续加速；如果只听财务，又可能得出“各部门花钱太多”的结论。两种判断都缺少一条完整的生意。
CEO 给我的第一个问题没有提 AI
CEO 没有问应该买哪个模型。他问：“为什么每个团队看起来都完成了工作，公司却没有得到更好的结果？”
销售负责人认为，项目团队接手后动作太慢；项目负责人认为，销售承诺了太多非标准内容；财务负责人说，很多尾款不是催不回来，而是客户没有完成验收。
三个人都给出了合理解释，但他们说的是一笔生意的不同阶段。我没有在会上决定谁对，而是请他们各自给我一笔能支持判断的订单。
项目负责人给出的就是后来贯穿全书的 YS-24-017：合同金额 70 万元，客户希望三个月上线，项目最后延期六周，验收后的 21 万元尾款也晚了 49 天。
我沿着订单离开了部门报表
我先从销售拿到客户会议纪要和方案，再到项目团队看交接记录，最后请财务打开合同与收款节点。
销售记录写着“客户旧系统可以提供接口”；售前个人文档写着“标准连接方式可能不适用”；对客方案却写成“完成会员数据接入”。合同签下后，项目经理才发现旧系统由第三方维护，客户没有取得接口授权。
这笔订单没有在某一个部门突然失败。它经历了几个看起来都能继续的局部决定：
- 销售把客户转述当成了可用条件；
- 售前发现风险，却没有进入共同决定；
- 方案把可能性写成了对客承诺；
- 合同没有列出客户需要准备的具体条件；
- 项目接手时，范围和价格已经很难重新谈；
- 验收推迟后，财务只能继续等待尾款。
我这才看见，公司的经营结果不是部门结果相加。客户的问题、公司的承诺、实际工作、成本和现金会穿过多个部门；其中一次信息丢失，可能到几个月后才以延期或坏账的样子出现。
我把最初的三个解释放在一起
| 初始解释 | 它能解释什么 | 它解释不了什么 | 下一步需要的证据 |
|---|---|---|---|
| 项目执行太慢 | 签约后确实等待和返工很多 | 风险在项目接手前已经出现 | 对照顺利订单和延期订单的签约前记录 |
| 销售记录不完整 | 客户条件没有稳定进入交接 | 记录完整也不代表公司已经批准承诺 | 查看谁在何时有权确认范围和成本 |
| 财务催款太晚 | 财务较晚介入客户风险 | 客户没有验收时，催款不能解决争议 | 还原验收条件与付款节点 |
现在我还不能选出根因。第一章的目的不是给出答案，而是把原来分散在部门里的解释放进同一个经营事件。
我开始同时追踪五条线
以后每看一笔生意，我都会追踪五件事：
| 我追踪什么 | 在 YS-24-017 中我先看到了什么 |
|---|---|
| 客户 | 客户以为云枢科技负责打通旧系统，却不知道自己要先取得第三方授权 |
| 工作 | 销售、售前、法务、项目和财务在不同时间补充同一件事 |
| 钱 | 额外适配没有进入报价，验收推迟又让尾款更晚回来 |
| 事实 | “可以接入”在会议、方案、合同和交接中含义不同 |
| 责任 | 风险被多人看见，却没有人在对客前必须作出完整决定 |
管理书里可能把这些叫客户流、价值流、资金流、信息流和责任流。第一次进入陌生公司时，我不会先背这些名词。我先问：客户听见了什么、公司做了什么、钱什么时候发生、大家依据什么、谁能决定。
我画出的0.1版商业系统图故意留下问号
白板上的第一版只有六行：
| 问题 | 我当时能写下的答案 | 状态 |
|---|---|---|
| 谁愿意付钱 | 拥有多家门店、希望统一运营的连锁企业 | 需要核对不同客户类型 |
| 为什么购买 | 希望更快上线系统并改善门店经营 | 仍然过于宽泛 |
| 公司怎样赚钱 | 软件订阅、实施项目和顾问服务 | 已由财务初步确认 |
| 承诺怎样完成 | 销售签约后交给项目实施 | 明显遗漏售前、客户条件与验收 |
| 最大损失在哪里 | 项目延期和回款慢 | 只看到了结果，原因待查 |
| 哪个 AI 项目最值得做 | 不知道 | 不能提前填写 |
最后一个“不知道”很重要。此时如果我写“建设销售 Agent”，后面的调查就会变成为预设方案找理由。
此时我只让 AI 帮助整理，不允许它形成结论
我可以让 AI 全栈工程师准备一个脱敏的订单时间轴，把会议、方案、合同、项目和收款记录按发生时间排列，并保留每条材料的来源。
它不能把不同说法合成一段顺畅总结，不能判断哪个部门负责，也不能修改原系统。存在冲突时，正确表现是把冲突并排留下。
这项小任务不是开始建设产品，而是降低我核对材料的成本。只有经营团队确认过的事实，才能进入后续商业系统图。
这一步改变了我看公司的方式
我离开第一次经营会时，没有带走 AI 项目清单，只带走一笔订单、三个竞争解释和一张满是问号的底图。
它已经足以建立一个原则：部门完成不等于客户完成，客户完成也不等于公司已经获得利润和现金。FDE 必须跟着同一件事走过部门边界，直到结果真的发生。
下一节，我会用五天把这张 0.1 版底图变成一份能够被经营团队逐项纠正的材料：我怎样用五天看懂一家陌生公司。