视觉项目里各部门谁干什么
一个视觉项目从立项到稳定运行，会经过工艺、质量、设备、生产、IT、采购这几个部门，外加外部供应商。技术上的困难通常有明确的解法，真正拖住项目的是职责上的空白——某件事大家都以为别人在做，直到某个节点上需要有人签字或下结论时才发现没人能做主。这三件事里最典型的是判据的定义权、参数的控制权、验收的签字权。
核心要点
- 判据的定义权必须落在工艺或质量，不能让供应商代替定义。
- 参数一旦受控就不能由个人随意修改，需要变更流程。
- 验收标准和验收人要在项目开始前就定下来，不能等做完再谈。
- 三件最容易掉在地上的事：判据归属、参数控制、异常处置。
视觉项目里，各部门的参与方式差别很大：工艺关心判据对不对，质量关心能不能追溯和审得过去，设备关心机械电气接得上、维护得了，生产关心节拍和会不会误停，IT 关心网络和系统接入，采购关心合同和付款。这些关注点没有冲突，但如果没人把它们串起来，就会出现典型的拖延模式：方案反复修改、验收标准迟迟定不下来、系统装好了却没人敢签字放行。
常见的角色与职责
| 角色 | 主要职责 | 在哪个节点必须参与 |
|---|---|---|
| 工艺 | 定义什么算合格、什么算不合格；提供缺陷类型与严重程度分级 | 立项与判据冻结前；判据每次修订 |
| 质量 | 确定验收判据与样本要求；负责记录与追溯体系；对接客户审核 | 验收标准制定；验收签字；稽核准备 |
| 设备 | 提供机械与电气条件；负责安装、夹具、线缆与防护；承担日常维护 | 方案评审；安装调试；移交后的保养 |
| 生产 | 提供节拍与工况信息；反馈误报与操作问题；承担日常操作 | 节拍确认；试运行；移交后的日常使用 |
| IT | 网络、系统账号、数据存储与安全策略；与 MES 等系统的接口 | 接口方案评审；上线联调 |
| 采购 | 合同、付款、供应商管理；变更与索赔的商务处理 | 合同签订；变更发生时 |
| 供应商 | 算法与系统实现、现场调试、培训与售后支持 | 全周期，但边界须在合同中写清 |
三件最容易掉在地上的事
逐条确认归属
- 判据的定义权
「这个划痕算不算不合格」这个问题，只能由工艺或质量来回答，因为他们对产品的功能和客户要求负责。实践中最常见的偏差是让供应商来定——供应商为了尽快出效果，会按自己看到的现象划一条线，那条线看起来很合理，但可能与客户的实际要求无关。判据的定义权一旦让出去，后面所有的验收争议都会失去基准。
- 参数的控制权
系统上线后，曝光、增益、阈值、光照这些参数归谁管？如果答案含糊，实际就是「谁在现场谁管」。随之而来的问题是：有人为了消掉一个误报顺手调了阈值，结果漏放率上升，而没人知道发生过这次调整。正确的做法是把参数当作受控对象，改动走流程、留记录，这一点在系统上线前就要定下来。
- 异常处置的责任
系统报警了、判错了、停机了，第一反应找谁？如果没定，每次都要现场临时商量，处置时间拉长，而且处置方式每次都不一样。合理的做法是定一个明确的层级：操作员能做什么、班长能做什么、什么时候必须叫工程师、什么时候必须停线。这份层级要写下来并培训到位，否则出事时不会有人按它执行。
怎么让它运转起来
把上面这些职责写下来并不难，难的是让它们在实际项目中被执行。有效的做法通常包含三点：一是有一个明确的项目负责人，职责是推进而不是执行，专门负责把跨部门的事情推着走；二是有固定的例会节奏，关键节点前必须开，会上确认的是决策而不是进度汇报；三是有书面的决策记录，每次会上定了什么、谁定的、什么时候生效，写下来发出去。第三点看起来最形式主义，但它在项目后期最有价值——争议发生时，翻出当初的记录比重新讨论一遍快得多。
关于项目分工的常见问题
项目负责人该由哪个部门出？
通常由最关心结果的那个部门出，多数情况下是工艺或质量，也有由设备出的。关键不在于来自哪个部门，而在于这个人是否有足够的授权去推动其他部门，以及是否有时间投入。让一个本来就很忙的工程师兼任，是常见但效果最差的做法。
供应商的责任边界怎么划？
按「谁有能力控制」来划。算法效果、系统稳定性、调试质量属于供应商；工件本身的波动、环境条件、夹具精度属于使用方。模糊的地方最容易扯皮，比如「检不出是因为算法不行还是因为光照环境太差」——这类问题要在合同里约定好判定方法，常见做法是约定由双方共同确认的样本集来判定。
生产部门不配合怎么办？
生产不配合通常有两个原因：一是试运行影响了产量，二是他们觉得系统会给他们添麻烦。第一个问题靠排期解决——把调试安排在换型或停线窗口；第二个问题靠让他们参与早期设计解决。让操作员在方案阶段就提出意见，比上线后说服他们接受容易得多，这也是 操作员抵触 那一篇要处理的事。
把职责写成一句话
职责表常见的毛病是写成部门名称加一堆职能，谁看都觉得跟自己有关，又都觉得自己不是主责。更管用的写法是给每件事配一句「谁负责、谁配合、卡住找谁」。比如判据这件事可以写成「工艺负责定义，质量负责确认可追溯，卡住找工艺负责人」，一句话就把主责、配合和升级路径都写清楚了。项目启动时把这十几句话抄在一页纸上贴出来，比一份二十页的职责文件有用得多——后者通常只在评审会上被翻一次，之后就没人记得里面写了什么。
您的项目卡在谁那里？
把项目当前的状态和卡住的环节告诉我们，我们帮您判断该补哪一项职责、该在哪一步做决策。
相关文章
-
SOP 执行不到位的原因与对策
SOP 落不了地，多数时候不是员工态度问题，而是五个结构性原因：标准不可执行、执行过程不可见、反馈延迟太长、监督成本过高、异常没有闭环。理解这五点，才能判断该用…
了解详情 → -
防跳步方案：从流程约束到视觉校验
跳步和漏工序是两类问题。跳步的产品每道工序都做过，但顺序与标准不符，往往在功能测试或售后阶段才暴露。它的隐蔽性更强，也因此更难靠抽检发现。
了解详情 → -
报警疲劳：为什么现场会关掉系统
很多视觉 SOP 系统不是被技术问题打败的，而是被现场「静音」的。报警疲劳一旦形成，再准的算法也产生不了价值。它本质上是一个组织与设计问题。
了解详情 → -
视觉SOP相机选型与安装位置
视觉 SOP 的相机选型与产品检测不同，关注点是「动作与状态」而不是「外观缺陷」。因此三个决定的顺序应该是：先定安装位置与视野，再定快门类型，最后定分辨率与光源…
了解详情 →