多工序的车间，货是一棒一棒往下传的：下料交给折弯，折弯交给焊接，焊接交给打磨。传的方式通常是——把料车推到下一道的地界上喊一声，或者在群里发张照片，再不然就是流转卡往筐里一插。
这套办法平时能转，出事的时候转不动。因为它只记录了「我交了」，没有记录「他收了」。上一道说昨天下班前就推过去了，下一道说今早才看见——两个人都没撒谎，中间那十几个小时没有主人。等到交期前一天开始查这批货在哪儿，得靠一个人拿着单子挨个工位问过去。
下面这套系统不解决排产，也不解决产能。它只把交接这一下拆成两下，让中间那段时间有名有姓。
下面这批 B-2317 现在停在「焊接 → 打磨」的交接上。焊接已经点了完工，但它并没有往前走。按一下按钮，替打磨的王建国点个接收，再往下推，注意每过一道工序你要按几次。
| 时间 | 工序 | 动作 | 操作人 | 这一段花了 |
|---|---|---|---|---|
| 03-11 08:12 | 下料 | 完工 | 李伟 | — |
| 03-11 08:40 | 折弯 | 接收 | 张强 | 等 28 分 |
| 03-11 11:05 | 折弯 | 完工 | 张强 | 做 2 小时 25 分 |
| 03-11 13:30 | 焊接 | 接收 | 陈明 | 等 2 小时 25 分 |
| 03-11 16:20 | 焊接 | 完工 | 陈明 | 做 2 小时 50 分 |
| — | 打磨 | 待接收 | 王建国 | 已等 2 小时 40 分 |
界面是示意，数据是编的。真实的工序路线、班组和节拍按你们自己的工艺走。
很多报工系统只有一个动作：完工。这看起来省事，代价是把整条链上最贵的一段时间变成黑的。
没有第二个时间戳，这件事无解——不是态度问题，是数据里根本没有那一刻。
上面那条链你自己推的时候，卡点是自己浮出来的——没有人去「汇报」它。
这一下要成立，前提是接收对接收的人有用：他点开就看到这批要做多少、上一道留没留不良说明、图纸是第几版，省了他一趟腿。如果接收纯粹是替管理层留个痕，工人一定会攒到下班一次性补点——那时候拿到的时间戳全是假的，整套数据两周内就废掉。这是这类系统唯一真正的失败模式，值得在动手之前先想清楚。
下面这张图就是你刚才推完的 B-2317：上面一条是它实际经历的顺序，下面一条把同样这些时间按性质归堆。
拿到这张图之后，会发现一件反直觉的事：最长的两段等待，是下班。20:10 完工的批次要等到第二天 08:15 才有人接，17:05 完工的那批等了 16 小时。这不是谁偷懒，是班次天然的边界。
知道这一点，能改的东西就变了：与其催工人手快一点，不如把焊接的完工时间往前挪半小时，让它赶上打磨当班的尾巴。这类调度上的判断，只有在等待时长被单独记下来之后才做得出来——这也是为什么值得多点那一下。
很多厂是先上报工、再上流转，结果工人一天要点两遍。其实反过来更省：把交接记清楚，报工要的数已经在里面了。
| 想要的数 | 它是怎么算出来的 | 还要工人多做什么 |
|---|---|---|
| 加工工时 | 本道接收到本道完工的时长 | 不用，两次点击已经有了 |
| 等待时长 | 上一道完工到本道接收的时长 | 不用 |
| 在制时长 | 首道完工到末道完工，也就是上面那条 49 小时 48 分 | 不用 |
| 瓶颈在哪道 | 各工序的等待时长排个序，堆得最久的那道就是 | 不用 |
| 合格数 / 不良数 | 点完工时顺手填，不良可以拍张照 | 填两个数，必要时拍照 |
| 计件工资 | 合格数 × 工序单价，按人按月汇总 | 不用，前提是单价维护好 |
需要说清楚的是：这样算出来的工时是「这批货在这道工序上占了多久」，不是「这个人干了多久」。一个人同时看三台机、或者中间去开了个会，这两个数就对不上。要拿它发计件工资，得先在厂里把口径谈定——这件事通常比开发本身更花时间，也更值得先谈。
「待接收」这个状态本身就是一个可以定时扫的队列——这是把它单独记下来之后，白捡的一个好处。
它们已经被上一道点了完工，但打磨班还没有人点接收。
平台的定时任务每小时扫一遍，把停留超过设定时长的批次挑出来，推给下一道的班组长本人——不是发到群里，群消息没人认领。
超过更长时间还没人接，往上抬一级，同时抄送生产调度。这条升级线要有人真的会被打扰，否则它只是一个没人看的红点。
阈值不该由我们定。热处理等两天是正常的，装配等两小时就要出事。所以它是每道工序各自的一个参数，由工艺自己填，填错了改一下就生效。
推送走的是平台的定向应用消息：推给本人，应用自己拿不到企微凭据，也发不了群。
上面那条链看起来简单，但它要成立，得先有人回答「点的这个人是谁」「他凭什么能点」「这条记录能不能改」。这几件是平台给的，不在应用代码里。
| 这一步 | 靠的平台能力 | 不然要自己建什么 |
|---|---|---|
| 点接收的是王建国本人 | 企微登录 | 一套车间账号体系，外加没人记得住的密码 |
| 下一道该找谁 | 成员目录与消息触达 | 手工维护的班组花名册，人员一动就过期 |
| 只有本道的人能点接收 | 功能权限 | 在每个接口里手写 if 判断，改一次授权就要改代码 |
| 班组只看自己的批次 | 可见范围 | 每张列表都要记得加过滤条件，漏一处就全厂可见 |
| 每小时扫一遍待接收 | 定时任务 | 一台常开的机器，外加没人管的 crontab |
| 流转记录改不了、查得到 | 独立数据库 | 和别家共用一个库，出事分不清是谁写的 |
| 不良拍的照片存哪儿 | 文件存储 | 对象存储的桶、密钥和会过期的链接 |
| 工艺路线改错了要退回 | 版本与回滚 | 没有，只能凭记忆改回去 |
还有两件不用点名、但一直在起作用的：这个应用跑在独立运行环境里，和别家互不影响；交付之前浏览器验证会替你把上面这条链真点一遍，确认接收之后状态确实变了、企微确实收到了。要接 ERP 取工单和工艺路线，走连接器。
这些名字和写法都照 平台能力 那一页的原话，没有另造。
装备与非标制造：工序更长、单件价值更高，一个延误会顺着链条一路滚下去。这类厂最想要的不是工时，是「这台设备的三十几道工序，此刻停在哪一道」。链更长，逻辑一样。
流程与批次行业（食品、日化、原料药）：交接的不是料车而是罐、批和中间体，而且往往有强制的等待——静置、发酵、质检放行。这时候「等」不再是浪费，反而要卡住不许提前接收：接收按钮得等质检放行之后才亮。同一套时间戳，判断条件换一个。
外协与委外加工：下一道不在厂里，在供应商那儿。这时候接收的人是外部的，用外部用户登录让他自己点——他只看得到自己那几批，看不到别人的。发出去和收回来两头各留一个时间戳，对账时不用再翻聊天记录。
维修与返工线：链不是直的，会往回跳。检验不合格要退回打磨，这一跳同样是一次交接，同样要下一道点接收——退回去而没人接的批次，恰恰是最容易在车间角落里放到过期的那些。
这是这套系统唯一真正的风险，所以要让接收那一下对接收的人有好处：他点开就知道这批该做什么、要做多少、上一道有没有留不良说明，不用再跑去问。反过来，如果接收只是替管理层留个痕，工人一定会补录、会代点，数据两周就废了。
常见做法是工位上放一台平板或一体机，扫批次二维码就是接收，不依赖个人手机。断网时本机先记，恢复后补传——但要接受一件事：补传的时间戳是补传的，不是真实的，所以流转记录上要区分标注，不能混在一起当作同一种数据。
不替代。工单、BOM、工艺路线仍然在原来的系统里，这套只负责「这一批现在在谁手上、等了多久」这一层，并把结果回写或导出。真正上了完整 MES 且工人在用的车间不需要它；卡在「MES 上了但车间还在用纸质流转卡」的，缺的就是这一层。
记得住，但要在建之前说清楚：拆批就是新开一个子批次、各自往下走，合批则要指定合到哪一批；一道工序多人同时干，是一次接收多个操作人，还是拆成多个批次分别接收——这两件事的口径不同，出来的工时也不同。这类问题谈清楚比开发本身更花时间。
观思动的入口就是一句话。把它复制走自己去建，或者带着它跟我们聊——两条路的起点是同一段文字。
做一个工序流转与报工应用：先维护产品的工序路线和每道工序的责任班组，然后按工单开批次，批次沿工序路线往下走；每道工序做完由本人点「完工」，下一道工序点「接收」才算交接完成，两次点击各自记下时间和操作人，中间的等待时长自动算出来；任何一批当前停在哪道工序、是在做还是在等接收、等了多久，都能查到；工序完工时可以填合格数和不良数，工时按接收到完工的时长自动累计，不用另外报工；待接收超过设定时长没人接的，自动推企业微信给下一道的班组长和生产调度；提供在制批次看板和单批次的完整流转记录。
