几年前，我们做过一次MES相关的追溯项目。

当时，管理层很关注品质追溯，希望把员工在各个工作环节的操作、检测和判定记录得更细。这个方向没有问题。对一些质量要求高、追溯要求明确的产品来说，完整记录确实有必要。

IT接到任务后，开始和业务沟通、设计方案，并根据意见改了很多版。后来项目最终上线，但实际覆盖范围比最初设想明显收窄，只优先保留在部分高要求场景中。

系统是做出来了，难点出在运行上：更细的追溯意味着更多现场动作。当时缺少能显著替代人工操作的自动化方案，员工要承担额外的记录和确认工作。后来业务量和产能目标提高、人员没有同步增加时，业务部门反馈现有实现方式增加了现场操作负担，影响作业效率，也认为系统设计仍需要继续优化。

现在回看，我当时有一个没有想清楚的地方。我把主要精力放在了“怎样把追溯做得更完整”上，却没有在项目开始前把几个更根本的问题锁定：哪些产品和风险场景值得承担这套追溯成本？现场需要投入多少人和多少时间？业务部门准备怎样安排执行？最终的改善结果由谁负责？

于是，追溯完整性在实际运行中，慢慢被默认期待由IT来兜底。IT可以把规则做进系统，但不能单独承担业务目标、现场资源和执行结果。这件事让我重新理解了“懂业务”。

懂业务，不是替业务把决定做完

早期做信息化时，我很容易把“懂业务”理解成：业务说不清，我来梳理；规则不完整，我来设计；现场卡住，我来推动；项目推进不下去，我来协调。这样做短期看起来很有效，IT既能帮助业务把问题讲清楚，也能把一件模糊的事推到上线。但边界一旦越过去，IT就会从“帮助业务解决问题”，变成“替业务承担管理责任”。

业务目标、适用范围、现场资源和管理取舍，本质上都属于业务经营的一部分。例如，追溯做到什么颗粒度、哪些产品必须执行、为了满足追溯要求是否增加人员或调整节拍，这些不是单纯的系统配置问题。

IT可以分析每一种选择的系统影响、数据要求和实现成本，却不能替业务决定哪一种取舍值得承担。

懂业务的目的，是把业务问题、规则、数据和技术之间的关系说清楚。业务目标和管理责任，仍然要由业务承担。

两种责任，要分在同一张图里

划清边界，并不意味着IT要退回到“业务提什么，我就做什么”的施工队位置。IT越深入业务，越应该把责任分得清楚，否则技术团队会在项目中不断补位，业务部门也很难真正形成自己的规则、资源安排和执行机制。我现在把一项业务改善项目分成两个层次来看。

业务部门对业务结果负责

业务部门需要决定：

• 为什么要做这项改善，真正要解决什么问题；

• 哪些产品、客户或场景需要优先覆盖；

• 现场规则如何执行，谁负责推进；

• 为了实现目标，是否投入必要的人力、时间和管理资源；

• 项目上线后，业务结果是否真的改善。

这些决定没有明确之前，IT可以协助分析，但不能把它们默认为自己的交付目标。

IT对技术交付负责

IT需要负责：

• 判断方案是否可行，哪些数据、接口和流程条件必须具备；

• 把已经确认的业务规则转化为系统设计和技术方案；

• 说明不同方案的成本、风险、数据要求和技术边界；

• 保证约定范围内的系统实现、稳定性和技术交付质量；

• 在运行中发现技术问题，持续改进自身应承担的部分。

IT不能用“这是业务决定”回避技术问题；业务也不能因为“系统是IT做的”，就把业务结果全部变成IT的责任。

业务结果责任与IT技术交付责任需要协同，但不能混成同一个指标。

后来，我换了一种介入方式

2025年下半年，我们讨论过一个计划排程相关的系统方向。生产模式调整以后，计划端的复杂度上升，业务希望通过系统改善排程效率，并尽量控制人员继续增加。

如果按过去的习惯，IT可以很快进入产品调研、选型和立项。但那次沟通中，我没有急着讨论“系统能做什么”，而是先把问题摊开：设备和报工数据是否足够及时？订单冲突时，排产优先级到底按什么规则判断？现场异常是否已经在线呈现？工艺变化带来的新规则是否稳定？

我想做的，是把系统上线前需要共同面对的管理前提讲清楚。

业务后来开始改善技术资料、校准标准工时、重新梳理排产优先级；设备数据机联等工作也同步启动。相关系统没有被否定，仍在继续调研，只是暂时不急于上线。

这一次，我没有替业务拍板“必须上什么系统”，也没有用一句“条件不成熟”结束讨论。我做的是把可行路径、前置条件和技术风险讲清楚，让业务决定是否投入资源、先补哪些基础，以及怎样对最终的业务目标负责。

好的边界，要让真正该作决定的人带着完整信息作决定。

老板交办的任务，IT应该怎样接

说到这里，一个很现实的问题是：任务是老板交办的，IT负责人怎么可能简单地对业务说“这是你们的责任”？如果处理不好，所谓边界确实很容易被理解成推工作、躲责任。老板交办的任务当然要接，但首先要接住管理目标，具体的系统范围和实现方式还需要继续分析。现在再遇到类似任务，我会按四个动作推进。

1. 先接住目标，再确认系统要解决哪部分

老板关注的通常是质量、交付、成本或风险，不一定是某个具体功能。IT要先把目标翻译清楚：究竟要降低什么风险、改善什么结果，哪些是必须满足的底线。

这样做，是为了避免团队把“实现所有功能”误当成“完成管理目标”。

2. 带着方案和代价找业务，不把空题丢给业务

只把一句“你们到底想怎么做”丢给业务，同样是一种失职。技术团队应该先进入现场，把可选路径整理出来。

例如，同一项追溯要求，可以比较全范围覆盖、优先覆盖高风险场景，或者先选择一条产线试点。每种方案分别需要多少现场动作、数据条件和技术投入，可能影响什么效率，又能控制什么风险，都应该摆在同一张桌面上。

业务作决定以前，IT有责任把选择题和每个选项的代价讲清楚。

3. 立项时同时锁定业务责任和技术责任

方案确定后，不能只有一个IT项目负责人。还需要明确业务负责人：谁确定适用范围，谁安排现场资源，谁推动执行，谁确认业务结果。

与此同时，IT要写清自己的技术交付：系统实现哪些能力，需要哪些数据和接口，怎样处理异常，什么状态才算达到技术标准。

项目进度可以由IT协助组织，但组织推进不等于替业务承担最终结果。

4. 目标与资源冲突时，把取舍带回决策层

最难处理的情况，是老板要求目标必须实现，业务又没有足够资源承担新增动作。这时，IT不能靠强推系统解决，也不能用一句“业务不配合”结束项目。

更合适的方式，是把事实和选项带回决策层：如果坚持完整范围，需要哪些资源、会带来什么现场影响；如果优先关键场景，可以先控制哪些风险；如果继续等待自动化条件成熟，又要接受什么阶段性结果。

需要领导决定的是企业愿意为这个目标投入多少资源、接受怎样的取舍，而不是评判IT和业务谁对谁错。

不推诿的边界，不是IT把所有事情接过来，而是把任务推进到应该作决定的人能够作出决定。

责任分清，不会削弱IT的价值

有时我们会担心：如果不替业务承担更多，IT会不会又被认为只是支持部门？我的理解恰好相反。只接需求会沦为施工队，替业务把所有决定都做完，也只是把管理缺口暂时转移给IT。

真正有价值的IT，既能进入现场理解业务，也能在关键时刻指出：哪些问题要先由业务决定，哪些资源要先被投入，哪些规则需要统一，哪些技术条件还没有准备好。这需要的不只是技术能力，还包括判断、沟通和守住边界的能力。

数字化管理者既不能离业务太远，也不能把业务变成自己的责任。业务目标与技术交付需要处在同一条路径上，并且各自有人负责。

对于我来说，这仍然是一条正在学习的边界。过去，我会因为想把事情推进下去，习惯性多接一点、多扛一点。现在我更希望先把目标、范围、资源和责任说清楚，再让技术真正帮助业务把结果做出来。

​

阅读原文：https://mp.weixin.qq.com/s/cgbs2q4rMfWjkRZqhLQIcQ