第二章 为什么买系统和等 IT 排期解决不了

第二章 为什么买系统和等 IT 排期解决不了

核心结论：财务的需求有三个特征——碎片化、高频迭代、强上下文依赖。这三个特征天然适合「自己做」，天然不适合「等人做」。买 SaaS 解决不了定制性问题，等 IT 排期解决不了时效性问题。字节跳动已经用行动证明：连全中国技术实力最强的公司都认为流水线模式跑不动了。

---

买系统为什么解决不了

AP 自动化有专门的 SaaS，费用报销有费控平台，月结有对账工具，报表有 BI 系统。从几千块到几十万都有。

但大部分企业的实际情况是：系统买了，痛点还在。系统和你真实的业务之间，永远差那么一点——而那一点，恰恰是最痛的地方。

这一章我来说清楚，为什么「买系统」和「等 IT 排期」这两条你习惯的路径，在财务场景里会失灵。

---

SaaS 的三个致命局限

局限一：定制差——永远差那么一点

SaaS 产品的商业模式决定了它的能力边界：做标准化功能，卖给尽可能多的客户。这意味着产品功能是「所有人都能用」的最大公约数。

但你的财务不是最大公约数。

你的费用政策跟别人不一样——差旅标准按城市分三档，招待费用要匹配客户和项目，通讯补贴按职级差异化。你的合并规则跟别人不一样——内部交易抵销涉及多币种、多税率、跨法人的复杂场景。你的税务处理跟别人不一样——不同地区的税收优惠、不同行业的计税方法、不同时期政策变化。

SaaS 的「配置」功能能覆盖其中 70-80%。剩下 20-30% 怎么办？

标准答案是：提需求，排进产品路线图，等下一个版本。

现实是：你的需求排在第 37 位，产品经理评估后认为「只影响少数客户」，排期排到半年后。半年后上线了，发现做的跟你想的不完全一样——因为产品经理不理解你的业务上下文，他理解的是需求文档上写的那几行字。

于是系统做了 80%，剩下 20% 还是手工做。 你的团队变成了 ERP 系统和 Excel 之间的搬运工——把系统做不到的部分手工补上，日复一日。

局限二：数据外流——你敢把最敏感的商业数据放进别人的云里吗？

财务数据是企业最敏感的商业数据，没有之一。客户信息、供应商信息、成本结构、利润率、资金流水、税务数据——这些数据一旦泄露，竞争对手可以直接复制你的商业模式。

SaaS 产品意味着你的数据存储在别人的服务器上。你可以看服务条款里的「数据安全保障」，但事实是：

• 你的数据和其他客户的数据在同一套基础设施上，靠逻辑隔离而不是物理隔离
• SaaS 厂商的员工（或其云服务商的员工）理论上可以访问你的数据
• 如果厂商被收购、倒闭或被安全审查，你的数据怎么处理？
• 跨境场景更复杂——部分 SaaS 厂商的数据中心在境外，涉及《数据出境安全评估办法》

你会说：「大厂商有 ISO 27001、SOC 2 认证。」是的。但认证是合规底线，不是安全上限。你的财务数据越敏感，你对第三方信任的依赖就越不应该。

局限三：锁定——第三年开始，你就被绑死了

SaaS 的定价模式几乎都是订阅制：按用户数或按使用量收费。第一年的价格通常很友好——厂商要获客。第二年开始正常价格。第三年、第四年、第五年——你续约还是不续约？

你当然想续约。因为到第三年：

• 你的团队已经习惯了这个系统，工作流都建在上面了
• 你的历史数据全部在系统里，迁移成本极高
• 你为这个系统定制了报表模板、审批流程、集成接口，换一个系统等于重来

这就是经典的 SaaS 锁定效应。厂商知道你走不了，所以续约价格每年涨 10%-20%。你每年的费用从 10 万涨到 15 万、20 万、30 万——不是因为功能增加了，是因为你被锁定了。

你租的是工具，但积累的是对工具的依赖。 五年后你回过头看，你为这个工具付的钱已经足够自己建一套了——但你没有自己建的能力，所以继续付。

---

IT 排期的结构性问题

「既然 SaaS 不行，那就让 IT 部门自己做。」

这条路也有问题。问题出在模式本身，跟 IT 部门的能力没关系。

问题一：需求理解鸿沟

财务人员说的「对一下账」和 IT 人员理解的「对一下账」，通常不是一回事。

财务人员脑子里想的是：把 ERP 的应付模块数据和金税系统的进项税数据拉出来，按供应商分组匹配，差异自动标记，匹配不上的按金额排序，大于 5000 的优先处理。整个过程要在月结前完成，异常要通知到具体业务人员。

IT 人员听到的是：做一个数据匹配功能。

中间丢失的信息——匹配逻辑、排序规则、阈值标准、通知机制、时间约束——就是「需求理解鸿沟」。需求文档写得再详细，也无法替代坐在财务人员旁边看他实际操作一个下午。

这种鸿沟在传统软件项目中可以靠多轮评审弥补。但财务场景有一个特殊之处：规则本身就在不断变化。费用政策每季度调、税法每年变、合并范围因并购重组而改变——每次变化都意味着需求要重新沟通。IT 排期的响应速度跟不上业务变化的速度。

问题二：排期长——一个小改动要等三个月

IT 部门的排期通常是这样的：需求评审 → 方案设计 → 开发 → 测试 → 上线。一个报销审单规则的小改动——比如把差旅标准从按城市两档改成按城市三档——从提需求到上线，正常排期 6-12 周。

三个月。一个只需要改一个配置表的小功能，要等三个月。

原因不是 IT 不重视，是 IT 部门同时在服务全公司的需求——销售要 CRM、生产要 MES、HR 要 OA、供应链要 WMS。财务的需求在排队，和其他部门的需求竞争有限的开发资源。

财务的痛点不会等三个月。 月结每月份都要做，费用每天都在发生，报表每个月都要出。等到 IT 排期到了，业务可能已经变了。

问题三：迭代慢——做完发现不对，又要重新排期

IT 项目最大的风险是做完了发现不对。延期反而好处理——加人加钱能解决。做完了发现不对，要从头再来。

需求文档写了，方案评审通过了，开发做完了，测试通过了，上线了——然后财务人员用了一下说：「不对，我说的不是这个意思。」

这不是谁的问题。这是需求文档这种媒介的天然局限——它只能记录"想得到的需求"，无法捕捉"用了才知道的需求"。只有当工具真的跑起来、真的在日常工作中被使用，你才能发现它哪里不对。

发现不对之后怎么办？提新需求，重新排队，再等三个月。

财务的需求特征是：高度依赖使用反馈，需要快速试错和迭代。 传统 IT 流水线的节奏完全不匹配。

---

核心矛盾：财务需求的三特征

把上面的分析收拢到一点，财务需求有三个与其他业务需求不同的特征：

这三个特征加在一起，指向一个清晰的结论：

财务需求天然适合「自己做」，天然不适合「等人做」。

• 碎片化 → 大项目模式太重，小工具模式刚好
• 高频迭代 → 快速试错才能跟上变化，瀑布模式跟不上
• 强上下文依赖 → 最理解上下文的是财务人员自己，不是 IT

---

字节跳动已经用行动证明了一切

2026 年上半年，字节跳动把所有产品和技术团队全部砍掉，改成全员 FDE 化。

这不是一个创业公司在讲故事。这是全中国最懂技术和效率的公司做出的战略级决策。字节跳动有中国最好的工程师、最成熟的产品流程、最高效的迭代机制——即便如此，他们仍然认为「产品经理画原型、工程师写代码、运营跟进反馈」的流水线模式跑不动了。

如果字节跳动的流水线都跑不动，你的 IT 部门会比字节的更强吗？你的 SaaS 供应商会比字节的产品团队更懂你的业务吗？

字节跳动的回答是：把工程师推到业务前线。我的回答更进一步：你不需要等工程师来。你的财务人员，学会用 AI 编程工具，自己就是自己的工程师。

但怎么做？你的财务人员真的能学会吗？下一章给你完整的答案。

---

第二章小结：SaaS 定制差、数据外流、锁定效应——这三个致命局限让"买系统"只能解决 80% 的问题。IT 排期需求理解鸿沟、排期长、迭代慢——这三个结构性问题让"等人做"跟不上业务变化的速度。财务需求的碎片化、高频迭代、强上下文依赖特征，天然指向「自己做」。下一章：FDE 化——让你的财务团队成为自己的开发者。