交接班记录电子化：三班之间的信息不漏

三班倒的车间，信息掉得厉害的地方不是生产，是交接。我在一家做精密冲压的厂里管信息化，二车间三条线，早班七点半、中班三点半、夜班十一点半，一天两次交接，每次十五分钟。原来交接靠一本硬壳本子挂在看板下面，谁交班谁写，写完签个名，看着挺规矩。

去年十一月我翻过半年的本子，一共四百一十二条记录，其中六十三条只写了"设备正常、生产正常"这一句，二十九条写了问题但后面没有下文。有一条印象很深：中班写了"三号冲床送料机构有异响，待查"，落款是一个已经离职的人，夜班没接，早班没提，那台机器又跑了九天。

结论先摆出来：交接记录难的不是"记下来"，是让未结事项跟着班次往下传。做法是把交接拆成两张表，一张记班次本身，一张记事项，每条未结事项带一个来源字段串成链，签收动作单独留时间戳。改完上线四个月，跨班丢失的事项从每月十来条降到零。

一、纸本交接漏在哪

1.1 交接本只记了"交"，没记"接"

纸本流程里，交班的人写完就算完成任务，接的人签个名也就算完成，两头都没有强制。签名只是一个字，看不出他到底看没看那三条未结事项。真出事回头查，本子上有字，责任却分不清。

更麻烦的是本子本身。三条线共用一本，写满了换新本，旧本子塞在柜子里，想查上个月某天的交接，得先找到本子再翻页。有一次客户投诉追溯批次，我们花了四十分钟才翻到对应那页。

1.2 漏的三种形态

半年记录梳理下来，漏的方式就三种。一种是没交：交班的人觉得事情不大，懒得写，比如模具上的一点毛刺。一种是交了没接：写了，接班的人扫一眼没往心里去，等到自己班上出事才想起本子上提过。一种是接了没跟进：两边都知道，但没有人负责到底，事项在三个班之间来回写三遍，还是没解决。

这三种形态对应三个技术点：写不漏、接得住、跟到底。任何一个环节只做到"有记录"，另外两个环节照样漏。

1.3 把纸本拍照上传不算电子化

中间试过一个省事的办法：让班组用手机拍交接本，传到群里。跑了两周就废了。照片里的字看不清，搜索不了，也没法统计哪类事项多。更要紧的是，拍照这个动作本身没有约束，忙起来就忘，忘了也没人知道。

电子化的判断标准很朴素：一条事项能不能被检索、能不能被指派到人、能不能看出它跨了几个班。三条都做不到，就只是把纸换了介质。

还有一点常被忽略：交接记录的价值在事后追溯。设备半夜停了，第二天要判断是交接没提，还是提了没修，得有连续的时间线。纸本只能提供一页字迹，电子记录能给出交接时间、签收时间、关闭时间三个点，责任落在哪一段一目了然。这也是后来车间愿意配合的原因------不是系统好用，是出了事大家能少扯皮。

二、表结构：一张班次头，一张事项行

2.1 为什么必须拆成两张表

一张表塞下所有信息，会出现大量重复：同一个班次写五条事项，班次时间、交接双方就要重复五遍，改一次错五处。拆开之后，班次头一条记录只写一次，事项行按需要多少写多少，关系和约束都能落到数据库层面。

拆表的另一个好处是签收动作有地方放。签收是针对整个班次的，不是针对某条事项，放在班次头表上更自然：接的人点一次，整批事项一起确认，有异议就在同一行写原因。

2.2 建表语句

sql 复制代码

CREATE TABLE shift_handover (
    handover_id    bigserial PRIMARY KEY,
    line_code      varchar(16)  NOT NULL,
    biz_date       date         NOT NULL,
    shift_code     char(1)      NOT NULL,
    from_emp       varchar(32)  NOT NULL,
    to_emp         varchar(32)  NOT NULL,
    handover_at    timestamptz  NOT NULL DEFAULT now(),
    accept_at      timestamptz,
    dispute_reason text,
    status         smallint     NOT NULL DEFAULT 0,
    CONSTRAINT ck_shift  CHECK (shift_code IN ('A','B','C')),
    CONSTRAINT ck_status CHECK (status IN (0,1,2)),
    CONSTRAINT ck_accept CHECK (status <> 1 OR accept_at IS NOT NULL)
);

CREATE UNIQUE INDEX ux_handover_slot
    ON shift_handover (line_code, biz_date, shift_code);

CREATE TABLE handover_item (
    item_id     bigserial PRIMARY KEY,
    handover_id bigint       NOT NULL REFERENCES shift_handover(handover_id),
    item_type   varchar(8)   NOT NULL,
    subject     varchar(120) NOT NULL,
    detail      text,
    owner_emp   varchar(32)  NOT NULL,
    due_at      timestamptz,
    closed_at   timestamptz,
    parent_item bigint REFERENCES handover_item(item_id),
    CONSTRAINT ck_item_type CHECK (item_type IN ('设备','质量','物料','安全'))
);

CREATE INDEX ix_item_open ON handover_item (owner_emp)
    WHERE closed_at IS NULL;

唯一索引那句话是有意加的。同一台设备同一天同一个班次，只允许存在一条交接头，重复提交直接报错，前端把报错翻译成"这个班次已经交过了"。没有这个约束，两个人同时点提交就会生成两条头记录，事项散在两边，又变成新的漏点。

2.3 链式传递怎么落

parent_item 这个字段是关键。夜班接班时，把中班没关掉的事项原样带过来，新行指向上一条的 id，subject 和 detail 继承，只更新 owner_emp 和 due_at。这样一条事项跨了三个班，在库里是一条链，查的时候顺着链往上走，谁在哪一班接手、在哪一班关掉，一目了然。

closed_at 为空就是未结。日常巡检页面只查未结的，ix_item_open 这个部分索引正好覆盖，几万条历史数据也不影响速度。前端不允许直接改 closed_at，关闭必须走一条带处理说明的更新语句，说明字段留在明细里，防的是"点一下当处理完"。

三、签收：交接不是写完就算

3.1 接的人不点，等于没交

交接头记录写进去，状态是零，表示待接。接班的人在平板上点"确认接班"，写 accept_at 并改状态为一；如果对某条事项有意见，点"有异议"，状态二，必须填原因，系统把这条推给班组长。

界面上的顺序也调过。原来交班的人一进页面就能提交，现在提交后跳出一句"请交给接班人确认"，平板留在交接台，接班的人当场点。十五分钟的交接会本来就要开，多这一个动作不增加负担。

3.2 超时提醒的阈值

待接状态超过四十分钟没有确认，往班组群推一条提醒；超过两小时，推给车间主任。四十分钟这个数字是按班次衔接算的：十五分钟交接会，加上吃饭、换衣服、走到工位，超过四十分钟基本就是漏了。

提醒只推一次，不反复轰炸。反复提醒的结果是大家把群消息设成免打扰，提醒等于没有。真要升级，就走主任那条线，让人去找人。

3.3 异议通道不能只留个按钮

异议填了原因，得有去处。我们的做法是异议自动生成一条事项行，类型按原因自动归类，负责人填班组长，due_at 给到当班结束。这样异议本身也进了事项链，不会点完就沉底。

上线初期异议比例大概百分之七，三个月后降到百分之二。降下来的原因不是大家懒得提，是很多争议点被写进了交接模板，交班时顺手就填了。

异议也要分类统计。我们按三类记：记录不准、责任不清、处理不及时。跑下来记录不准占了七成，说明多数争议不是人推责，是写得太粗。这一类靠模板细化就能解决，跟考核没关系。

四、跑起来之后

4.1 四个月的几个数字

上线四个月，交接头记录三千一百多条，事项行一万四千多条，其中跨班未结事项三百二十条，全部有明确的接手人和关闭时间。跨班丢失从每月十来条降到零。交接本还在，但只用来写临时通知。

有个意外收获：事项类型分布出来了。设备类占一半多，质量类两成，物料类一成半。设备类里又有四成集中在两台老冲床上，这个数字后来直接推动了那两台机器的大修排期。

4.2 交接会从念本子变成对清单

以前交接会是交班的人念，接班的人听，念完散会。现在平板上是一张未结清单，一条一条过，过完点确认。会还是十五分钟，但内容从"我这一班干了什么"变成"这几件事你接不接"。

车间主任的说法更直接：以前他每天要问三次"那台机器到底修没修"，现在打开清单就知道在谁手上。

夜间那班的变化比较细微。夜班人少，出了问题往往自己扛，能不写就不写。现在交接模板把设备、质量、物料、安全四类固定列出来，空着也要点一下"无"，反而让他们愿意填。有一个夜班班长跟我说，以前写本子怕写了没人管，现在写了第二天早上有人问，写着才有意义。

常见问题

问：三条线共用一个班次头表，会不会互相干扰？

答：不会，line_code 参与唯一索引，线体之间是天然隔离的。真要注意的是跨线事项，比如共用一台空压机，这种事项的 owner_emp 不要填到线体上，应该挂到公共设备组，否则三条线都以为对方在跟。

问：历史纸本要不要补录？

答：只补未结的。已经关掉的历史记录补进去价值不大，还要花大量人力录入，容易出错。把本子上还挂着的、没处理完的事项挑出来，按当前班次建一条新记录，detail 里写明原始日期，链就算接上了。

问：事项挂在个人名下，人调走了怎么办？

答：调岗或离职时做一次批量移交，把该员工名下所有 closed_at 为空的事项统一改到接替人，同时在明细里追加一条移交说明。千万别只改 owner_emp 不留痕迹，否则日后追责时说不清是原本就归他，还是半路转过来的。

问：交接记录要不要跟考勤或绩效挂钩？

答：可以挂钩，但只挂"未结事项是否按期关闭"，不要挂"提交条数"。挂条数会立刻出现大量凑数记录，写满一屏"设备正常"。指标一旦可以被凑，数据就废了。