娃回来过暑假，我给他派了个活儿：做个暑假旅行攻略。
娃点头接了，然后几天没动静。家里人开始催，他嘴上说"在做在做"。
周五晚上，我还在外出车上收到方案，翻了前半页就感觉不行：方向有偏，行程太满，时间太紧，地点没覆盖，预算还超…
第一反应是"这方案质量不行啊"。但我随即意识到，我压根没告诉过他预算多少、哪几天走、往哪个方向、想玩什么类型的——我只说了三个字，“做攻略”。
他不是没努力，是在一道没有边界的题目里，硬憋出了一个答案。而我们在旁边催了四天。
工具不是问题，努不努力也不是问题。问题是有没有人，先把这件事该长什么样，说清楚。
这事放到公司里，一模一样。你天天做的业务，你能一口气说清楚吗？
说得清楚，是一道分水岭
我在之前那家制造业集团工作时，常跟同事讲一句话：业务解构，落到底就是一件事——你得说得清楚，你的业务长什么样子。
听起来简单，做起来，多数人做不到。
“会做"和"说得清楚”，是两件不同的事。会做，是知道下一步该点哪个按钮；说得清楚，是能讲明白这个流程为什么这样设计、断点在哪、边界在哪。
这也是我在《智链架构师模型》里，把"业务架构与系统解构力"放在第一个模块、给到35%权重的原因。四种能力里，它是地基。地基说不清楚，上面搭什么都是空中楼阁。
在这个模块下面挂了三样东西：业务本体翻译、TCO算法设计、供应链拓扑结构规划。为什么是这三样？因为解构一个业务，逃不过三个问题：它长什么样（形），它的代价是什么（价），它连着谁（网）。形、价、网，分别对应上面那三样能力。缺一个，解构就是半成品。
有人问过我为什么不是四样五样——这套模型标的是V1.0，我不认为它已经完备，但这三个问题谁都绕不开。
今天这篇，先说第一个：形，也就是业务本体翻译。
Agent日渐接管企业流程的今天，一个现实是：它几秒钟就能学会"怎么做"，但学不会"为什么这么做"——除非有人先把这件事翻译给它。
再往下想一层就会发现：给AI下指令的人，和给娃派活儿的人，犯的是同一个错——都把"定义任务"这一步，默认成了对方的活儿。
那位画不出业务全貌的老同事
《智链架构师模型》那篇里，我提过一位干了20多年的资深业务主管。今天想把这个故事讲完。
那天架构梳理会上，我请他把庞杂的采购类型梳理出底层运作逻辑、系统断点和线上线下边界。他无从下手。
等我把这套"业务本体"画成架构图，他看着图说了一句：“干了这么多年，我竟然画不出自己每天在跑的业务全貌。”
这不是能力问题，是太熟了。熟到所有判断都沉进肌肉记忆里，没有一个场合需要他把它取出来，摊在桌上看一眼。
我见过不少这样的人。他们是懂业务的，只是这份懂，一直没被翻译成能交出去的东西。
那篇写到这儿就停了。你读完大概以为这是个警示故事。其实后面还有半截。
他被拉进了架构梳理项目。那些"凭经验判断"的东西，被一条条画出来、写下来、被人反复追问"为什么这一步不能省"。
半年后，他不只能说清楚了，还成了团队里的"业务翻译官"——谁碰上流程说不清的地方，都爱找他聊两句。他也借着这次梳理，把自己的能力结构换了一轮。
后来他跟我说：“干这行20多年，这是我第一次看见自己的工作。”
20多年的经验没有白费，它只是一直没被翻译出来。
说清楚，从哪两块入手
业务本体翻译听起来抽象，落地却很具体，就是两件事：流程怎么走，数据怎么定。
这两件事是一体的。流程说不清，数据就没有归属；数据没定义，流程图只是一张挂在墙上的画。
之前的文章里我说过一句话，这里想再说一遍：数据是业务的责任区，不是IT团队的兜底项。很多人习惯把数据出错甩给"系统的问题"，却没想过，那套数据的定义、口径、边界，本该由业务方自己说清楚。
下面两份清单，是个引子。你不需要全答上来，能被某一条问住，这一条就值了。
流程，你说得清吗？（10条）
- 你正在操作的这个流程，在公司整张流程地图上，挂在哪根主干下面？上游是谁交给你的，你交出去的又是给谁？（说不出位置，你优化的就只是自己那一小块）
- 你能否用一张图，画出你负责业务核心的3-5个流程节点？
- 流程里哪些环节，是靠经验"跳过"、没被写成规则的？
- 如果你离职一周，谁能看懂你脑子里那套"隐性判断逻辑"？
- 你的流程图，上次是什么时候更新的？半年前，还是没更新过？
- 遇到异常时，你是"按规则处理"，还是"凭感觉兜底"？
- 流程里有没有一个环节，连你自己都说不清"为什么要这一步"？
- 换个新人接手，你的流程说明能让他一周上手，还是得靠你带三个月？
- 关键决策点，是写在纸面上的，还是只活在某几个"老人"的脑子里？
- 你能分清楚，哪些是"流程"，哪些只是"习惯"吗？
还有一条想单独放在这里：你的部门，有没有一张完整的、大家都认的流程全景图？没有这张图，前面十条都只能各答各的。
数据，你说得清吗？（10条）
- 你日常依赖的关键数据，说得清楚它从哪来、经过几手、谁在维护吗？
- 有没有一个"黑盒地带"，数据对不上时，你只能凭经验猜，而不是查？
- 数据出错时，责任是落在业务方，还是习惯性地甩给IT？
- 你能说清楚，哪些数据是"真实源头"，哪些是"层层转手后的二手加工"吗？
- 如果两个系统的数据对不上，你知道该信哪个、为什么信它吗？
- 你们部门常用的那几个指标，定义是唯一的吗？还是每个人算法略有不同？
- 同一个词（比如"交期"“在途"“齐套”），跨部门开会时，大家理解的是同一件事吗？
- 你的关键数据，有明确的责任人吗？还是"大家都在用，没人负责”？
- 你手里有没有那种"没人看、但一直在报"的数据？
- 做重要决策前，你是先查数据，还是先问人、再拿数据来印证自己已有的结论？
这10条越往后走，越会指向同一个坑：数据治理是怎么一步步失效的。那是另一个话题了。
另外两个问题
形说完了，还有价和网。
它的代价是什么——TCO算法设计（价）。这个概念被讲了太多年，模板满天飞。但难处不在会不会算，而在于：算是算了，拍板时看的还是报价单上那个数。算法设计的难点，不在算法。
它连着谁——供应链拓扑结构规划（网）。不少人以为就是画一张供应商层级图，差得远。在H公司ISC+变革的多级供应商协同（NTSC）项目里，我们做的是把数千个隐性的末端节点、产能分布从黑盒里强行解构出来，织成一张动态网络。平时把盲区变成数据，战时才能让AI跑出救命的对策。
这两块，今天都还没展开。
系统的主人，靠的不是工具，是说清楚
工具能支撑效率。但你在系统里是主人还是附庸，取决于你说不说得清楚。
Agent可以帮你画图、帮你跑流程，但它替代不了那个愿意坐下来，把自己脑子里的东西一条条理清楚的人。
这也是"智链"这两个字，我一直想说的意思：链条是原本就在的，智能是后来加的，而让它们真正连起来的，是那个能把业务说清楚的人。
那位老同事说，画清楚架构图那天，他第一次看见自己的工作。那一天，什么时候来，都不算晚。
我和娃也很快重做了一版攻略。我先把预算、日期、方向、想去的地方和游玩的类型提给他，不到两个小时他就拿出很好的可行方案。
不是他突然变聪明了。是题目定义清楚了。
工具不是我们的敌人，说不清业务的糊涂账才是。
别急着向系统要效率。先问问自己：如果今天拔掉网线、脱离了现在的 IT 界面，你还能徒手画出你的业务全貌吗？