最开始，我真没觉得这会变成一件大事。
那时候摆在面前的东西很普通：一堆 Excel。
应收合同、应付费用、基础配置、追踪信息，各种表分散在不同地方。有人维护，有人下载，有人拿去算费用，有人拿去做报表。
我一开始看到的，也是最表面的那些问题：
表太多，格式太乱，公式太散。
那就先整理一下。
先把 Excel 规范起来，把 Power Query 跑通。后来不够用了，再写 Python 脚本；脚本再往后，又慢慢变成 SQL 存储过程、调度、对账和 Power BI。
如果只看工具变化，这一年好像就是从 Excel 一路换到数据库和报表。
但真正麻烦的东西，不在工具上。
Excel 只是表面。
更麻烦的是：很多业务规则根本没有被系统接住。
它们散落在表格里、旧系统里、人工经验里、临时口径里。平时靠人处理，好像也能转起来；真要让系统稳定重复地算，就会发现很多地方其实说不清。
什么时候适用这条规则？
字段为空到底是没填，还是代表全部适用？
特价和普价重叠时怎么切？
一个结果算出来以后，怎么证明它是对的？
我原来以为自己是在整理 Excel。
后来才发现，我是在一点点补系统原本应该承接的那部分业务。
最早看这些 Excel，我很容易把它们当成“数据源”。
但实际做进去以后会发现，有些 Excel 不是单纯记录数据，而是在替系统表达规则、保存口径、承担判断。
比如应付费用表。
同样是一条费用规则，它可能跟承运商有关，跟启运站有关，跟卸运站有关，跟邮件种类有关，跟业务类型有关，跟运输方式有关，还跟生效日期和截止日期有关。
有些字段为空，不一定是没填。
它可能表示“全部适用”。
有些价格看起来是一条记录，实际上只在某个时间段有效。
有些特价规则不是简单覆盖普通规则，而是要在时间轴上和普通规则切开。
有些线路也不是一段运输，而是头程、EXP、操作费、续程拼出来的路径。
所以，问题从来不是“Excel 不专业”这么简单。
Excel 只是这些规则暂时住的地方。
麻烦的是，这些规则没有变成系统能理解、能执行、能解释的结构。
一开始用 Power Query，确实很顺手。
它离 Excel 近，调整方便，结果也能快速看到。
早期做验证时，它确实帮了很多忙。
但规则一多，Power Query 开始变得吃力。
一个查询接一个查询，一个步骤套一个步骤。头程先处理，EXP 再合并，操作费再接上，后面还要补续程。
每一步都可能涉及日期交叉、空值含义、特价区间、重复记录。
结果一旦不对，很难判断到底是哪一步错了。
是 EXP 没匹配上？
是卸运站空值被当成缺失，而不是通用规则？
是日期区间没切开？
还是特价覆盖错了？
后来我把一部分逻辑搬到 Python、Pandas、DuckDB 里。
不是因为它们听起来更高级。
主要是因为我需要把过程拆开看。
头程处理完是什么样，EXP 合并后是什么样，操作费特殊判断后是什么样，续程加进去以后又是什么样。
这些中间结果看起来很笨，但关键时候能救命。
复杂业务规则最怕的不是写得慢。
最怕的是错了以后，你不知道它从哪一步开始错。
整理 Excel 时，很容易把目标理解成“把数据跑出来”。
但做费用、利润、对账这些东西时，光跑出来不够。
还要能解释。
为什么这票费用是这个金额？
它命中了哪条规则？
为什么没有命中特价？
为什么新逻辑和旧系统不一样？
如果只看最终结果，这些问题很难回答。
所以后面越来越多工作，都围绕一个问题展开：
怎么算出来，只是第一步。
怎么证明它算对了，才是分水岭。
这也是后来会走向 SQL Server、存储过程、中间表、批次日志和对账的原因。
不是为了显得正规一点。
一套规则只要开始长期运行，就必须留下过程。
哪一批数据进来了？
哪一步处理过？
哪条规则命中了？
哪些记录失败了？
失败以后能不能重跑？
这些问题，如果只靠一个脚本或一张报表，很快就会撑不住。
以前我会觉得，对账是最后一步。
新逻辑写完了，拿旧系统结果比一下，看看差多少。
后来发现不是这样。
对账不是收尾。
对账会把系统还没理解的业务暴露出来。
很多差异，并不是代码写错这么简单。
有的是旧系统用了某个隐藏口径。
有的是 Excel 里有例外规则。
有的是业务上临时调整过，但没有被结构化记录下来。
有的是同一件事在不同表里表达得不一致。
这些差异一开始很烦。
但后面看，它们很有价值。
因为每一条差异都在提醒我：这里还有一块业务事实没有被说清楚。
所以后来我对“算对了”的理解变了。
不是某个公式跑出来等于旧系统，就叫算对。
而是规则、过程、结果、差异，都能被追溯和解释。
这件事想明白以后，数据仓库就不只是放数据的地方了。
它开始变成承接业务事实的地方。
Power BI 很容易给人一种错觉：
报表做清楚了，问题好像就解决了。
但做到后面会发现，如果底层事实不可信，报表做得越复杂，越容易把问题包装得更像“已经解决了”。
应收价格、应付成本、利润模拟，这些不应该在每张报表里各算一遍。
报表应该消费已经处理好的事实。
复杂规则应该尽量下沉到可以调度、可以对账、可以追溯的数据层。
后来 DZA 决策分析层的思路，也是这样一点点变的。
它不应该自己承担太多原始规则。
更合理的方式是：应收引擎产出收入事实，应付引擎产出成本事实，DZA 连接这些可信事实，再做模拟和分析。
很多时候，我们以为自己在做报表。
其实是在补底层数据事实的债。
如果底层没有稳定事实，报表只是把混乱换了一种更好看的形式展示出来。
当数据、费用、调度、对账逐渐清楚以后，下一个问题就冒出来了。
光有数据仓库和报表还不够。
因为报表只能回答“现在是什么样”。
但业务每天还要处理：
• 作业如何产生。
• 人工如何确认。
• 应收和应付如何维护。
• 追踪信息如何补齐。
• 状态如何流转。
• 哪些结果要回传旧系统。
这些不是报表能解决的。
所以后来开始想业务系统蓝图，包括作业初始化、应收工作台、应付工作台、运输追踪工作台、接口兼容等。
这一步不是突然想做一个新系统。
而是前面的事情做到一定程度后，我才发现：
如果业务规则只在 Excel 里，系统就只能事后补算。
如果业务事实只在报表里，流程就还是散的。
数据仓库解决的是算清楚、看清楚、对得上。
业务系统要解决的是：这些业务事实从哪里产生，谁来确认，怎么流转，最后怎么留下记录。
这是我回头看这一年时，最大的变化。
我不是从一开始就想做系统。
我先是被 Excel 里的混乱推着走，后来被费用规则推着走，再被对账推着走。走到最后才意识到，自己一直在补系统应该承接、但当时没有承接起来的那部分业务。
所以这篇文章如果只总结成“我从 Excel 做到了数据仓库”，其实是不准确的。
更准确地说，是我慢慢摸出了一条处理业务数据的顺序：
先看见规则，再拆开过程，再验证中间结果。等这些都能说清楚了，再固化成结构，建立对账，接入调度。最后才谈报表和系统。
这个顺序不高级，但它很有用。
很多业务数据工作里的问题，刚开始看都像工具问题：
Excel 太多。
脚本太散。
报表太慢。
系统不好用。
但往下追，常常会发现问题换了一个样子：
规则没有被稳定表达。
过程没有被拆开观察。
结果没有办法被证明。
业务事实没有地方沉淀。
如果从这一年里提炼一句话，我现在会这么说：
不要急着替换 Excel。
先问清楚，Excel 里到底替系统扛了哪些东西。
后面这个系列，我想继续从这些具体问题写起。
不是写一个技术教程，也不是把项目包装成什么宏大的东西。
就讲一件事：
一个业务数据系统，是怎么从一堆 Excel、规则、脚本、对账和报表里，一点点被逼出来的。
