本文内容
操作员发出了异常信号。灯变了，大家也看到了，生产任务却仍在等待。维修人员以为主管正在处理，主管则以为已经有人联系了维修。与此同时，下一个部门还在为这台无法运行的设备准备生产任务。
真正有用的安灯系统（Andon）必须补上这个缺口。在制造现场，Andon让异常显现出来，提醒大家哪里需要支援。它的价值在于信号发出之后的行动：有人接手负责，协调合适的支援，并确认生产过程何时已具备恢复条件。
生产经理还需要处理另一层影响。已确认的生产中断不仅影响停下来的工序，还可能改变多个客户订单的生产顺序。SkyPlanner APS可帮助您根据产能变化，对相关生产任务重新排程，让工厂按一份统一计划执行，而不是各自拿着临时拼凑的加急清单忙碌。
制造业中的安灯系统（Andon）是什么？
Andon是一种目视化管理方法，用于显示生产状态，并在出现异常或需要支援时发出信号。拉绳、按钮或设备信号可以触发指示灯、显示板或其他通知，指出哪里需要关注。Andon一词源于日语中的“行灯”，与丰田生产方式密切相关。
关键信息很简单：问题在哪里、需要什么支援、谁在响应？根据具体生产过程，信号可能涉及设备故障、质量疑虑、零部件短缺，或操作员未能跟上约定的作业顺序。
安灯显示板也可以展示计划产量和实际产量。但显示结果并不等于建立了完整的响应机制。如果操作员发出信号后，仍要离开工作中心去找主管，那么最关键的沟通问题依然没有解决。
与两个相近概念作比较，有助于厘清Andon的用途：
- Andon与生产看板：生产看板展示选定的生产信息，Andon则引导人员立即响应某个具体状况。同一块屏幕可以兼顾这两种用途，但显示警示并不等于明确了由谁负责响应。
- Andon与看板拉动机制（kanban）：在拉动式系统中，kanban用于授权生产或补料，或发出相应信号。Andon则用于传递状态，或提示需要关注的问题。缺料可以触发Andon呼叫，但这并不意味着两种方法可以相互替代。
Andon也支持自働化（jidoka）：识别并处理异常，而不是任由不合格品继续流入后续工序。实际落地的起点不是一块更炫目的屏幕，而是事先约定好：有人求助时，接下来该怎么做。
为信号建立配套的响应流程
有效的Andon流程应将最初发现的异常与最终经过验证的结果衔接起来。各环节的交接要足够明确，确保忙碌的班次也能顺利执行，而不是只有平时负责的主管站在旁边时才管用。
| 阶段 | 团队需要做什么 | 如何确认交接到位 |
|---|---|---|
| 发出信号 | 通过约定渠道，说明受影响的工位及观察到的状况。 | 对应的响应人员能够识别哪里需要支援。 |
| 接手负责 | 指定的响应人员接手负责，并告知操作员已收到呼叫。 | 有明确的责任人；确认收到呼叫不会被误认为问题已经解决。 |
| 响应与升级处理 | 评估状况，协调相应专业人员，并按约定的生产处置流程执行。 | 下一步行动、负责人及下一次进展通报安排均已明确。 |
| 恢复与验证 | 恢复正常运行前，确认已完成必要的设备、工艺和质量检查。 | 由相关责任人确认已具备恢复条件，而不只是指示灯已经复位。 |
| 反馈与改进 | 向团队说明发生了哪些变化，并为尚未完成的调查或纠正工作指定负责人。 | 操作员了解处理结果，反复出现的问题有后续跟进。 |
应将首次响应交给真正能采取行动的岗位。“当班所有人”只是知情者，不是责任人。可以由班组长接下首次呼叫，再协调维修、质量或物料供应人员；也有工厂按问题类别直接指定对应人员。无论采用哪种安排，都需要明确常规响应人员缺席或忙于其他事务时，由谁替补。
转交过程中也要始终保留明确的责任人。如果主管请维修人员介入，就要约定由谁继续向生产方通报进展。消息转出去了，不应让操作员夹在部门之间无人回应。
收到呼叫后应迅速确认，但不要为了考核分数而匆忙结案。“我看到了”和“生产过程已恢复”是两件不同的事。将两者分开，才能避免绿色显示掩盖尚未完成的工作。
拉动Andon拉绳会让生产线停下来吗？
这取决于系统和生产过程的设计。Andon呼叫可能是在获准条件下继续作业的同时请求支援，也可能与停机相关联。以丰田的定位置停止方式为例，发出呼叫后会有人员前来支援；如果问题仍未解决，生产线会在规定位置停止。并不存在“每拉一次绳，所有设备都立即停机”这样的通用规则。
对于您自己的生产过程，应区分三项决定：请求支援、判断是否允许继续生产，以及批准恢复正常运行。引入信号之前，先约定各项决定的负责岗位和适用条件。
Andon通知本身并不具备急停或设备隔离功能。实际处置必须遵循相应设备的停机、隔离和重启规定。不要照搬其他工厂的拉绳触发方式或响应时限，将其当作通用安全规程。
对管理者而言，道理很直接：员工需要确信，报告合理的疑虑会得到支援。如果每次呼叫都会因为产量损失而受到责备，那么恰恰在最需要及早获知情况的时候，这套系统反而会让员工选择沉默。
从一个区域做起，明确约定响应方式
选择一个经常出现支援延误的生产单元或生产线，与操作员、当班负责人及需要参与响应的职能人员一起，回顾最近发生的一次事件。找出延误究竟发生在哪里：发现异常、找到响应人员、接下呼叫、协调专业人员，还是决定如何处理受影响的生产任务。
然后约定一套简明的操作流程：
1. 明确哪些情况需要发起呼叫。依据应是操作员能够观察和识别的现象，而不是他们尚无法作出的诊断。与其要求先确认某个部件已经失效，不如将“设备反复异常停机”作为呼叫条件，这样更实用。
2. 首次报送的信息要简短。说明工位、问题类别和当前生产状况即可。详细原因可以后续记录，不要让正在等待支援的操作员先填完一份长报告。
3. 明确每个班次的首位响应人员和替补人员。安排时应考虑休息、缺勤及多个呼叫同时出现的情况。还要确认人员在实际工作位置能够接收到信号，并识别其含义。
4. 明确响应和升级处理的界限。事先决定无人接单、问题迟迟未解决，或后果变得更严重时该如何处理。应依据生产过程的需要和可用支援来制定规则，而不是随意套用一个通用时限。
5. 明确结案条件及与计划环节的交接。确定由谁确认恢复、谁通知操作员，以及生产计划受到影响时，由谁更新产能或剩余生产任务。
与实际使用这套流程的人员一起测试。测试应涵盖呼叫无人接单、响应人员正忙以及换班等情况。如果流程能否顺利执行还取决于某个人是否记得一个私人电话号码，那么这套响应机制还不够可靠。
让信号易于理解
只设置少量状态，并确保人员在实际工作距离上能够分辨。例如，现场可以约定区分正常运行、已请求支援和生产已停止这几种状态。统一各状态的含义，在作业现场附近展示说明，并对所有班次开展培训；对于还需要用文字或符号表达的信息，不应只靠颜色传递。
不要以为红灯或黄灯在每家工厂都代表同一含义。真正有用的标准，是参与您这套生产过程的人员对信号有一致的理解。只有当增加颜色或声音能帮助响应人员选择不同的处置行动时，这样做才有价值。
实体还是数字化Andon：围绕响应需求来选择
如果响应人员就在附近，且信号能清楚指出具体工位，拉绳、按钮和可见的指示灯就可以很好地发挥作用。如果响应人员需要在不同区域间走动、涉及多个支援职能，或团队需要可靠的事件记录，数字化通知则能提供帮助。
无论采用哪种方式，都应从同样的实际问题出发来评估：操作员能否方便地发出求助信号？信号能否传达给合适的人？是否能看出已有人接手？团队能否区分尚未解决的求助与已经确认恢复的生产过程？通信渠道不可用时，又该如何处理？
评估数字化系统时，要查看任务指派、升级处理、事件时间戳以及后续跟进所需的信息。通知并非越多越好：把每个事件都发给所有人，反而会让人更难识别哪些求助需要立即处理。
先明确响应约定，再选择技术方案。交接职责尚不清晰就实现自动化，只会让这种不确定性传播得更快。
示例：一台设备停机，多个订单受影响
设想一个机加工车间：操作员发现某台加工中心反复出现故障，于是按约定发出安灯（Andon）求助信号。信号明确标示了故障工位。当班班组长接手求助，核查现场状况，并通知维修人员参与处理。设备处置遵循该设备经批准的操作规程。
维修人员确认，设备在维修期间将无法使用。此时，计划员要考虑的问题与维修技术人员不同：这部分产能不可用时，其余生产任务该如何安排？
其中一个受影响的订单还需要完成机加工、检验和包装。另一个部门即将开工的任务，之后也要在这台停机设备前排队等待。只有当另一台设备已获准执行该工序且有可用产能时，才可以考虑将前一个订单转过去；这样做还会挤占其他已排定任务的生产时间。
计划员需要掌握已确认的设备不可用时段、受影响工序的实际状态，以及根据当前信息作出的最可靠的恢复时间估计。如果估计发生变化，计划就需要再次更新。历史平均修复时间并不代表本次维修也一定能在相同时间内完成。
如果维修人员到场后就直接清除报警，上述对生产的影响仍然没有得到处理。
使用 SkyPlanner 重新计算关联任务的排程
在 SkyPlanner 中，可以通过工作中心异常记录资源不可用的时段，将这段时间从可用产能中扣除。随后，SkyPlanner 的人工智能排程引擎 Arcturus 就能根据此次中断重新安排受影响的生产任务，无需计划员逐台设备手动调整任务队列。
计算依据包括已配置的工作中心、班次、工序依赖关系和优先级。甘特图会显示计算后的任务顺序，让计划员能够结合后续任务一起审视机加工工序，并看清哪些完工日期需要关注。
由您确定优先级以及需要锁定的排程安排，Arcturus 则在这些设定范围内计算。紧急订单可以优先安排，但提高优先级并不能补回故障造成的机时损失。其价值在于：在再次承诺交期之前，先看清整个共享生产计划中需要作出的取舍。
负责团队确认设备恢复可用后，应更新系统中记录的可用时间，并按需重新计算排程。将当前任务顺序传达给执行人员。设备恢复与可执行的生产计划相互关联，但不能仅凭指示灯复位就认定其中任何一项已经落实。
SkyPlanner 可通过其开放的 REST API 与任何 ERP 或 MES 集成，将现有订单和生产信息与排程衔接起来。在这一流程中，关键是将已确认的产能变化交接给计划环节，让生产计划有明确依据作出调整。
衡量支援是否到位，问题解决后是否复发
要审视整个响应过程，而不只是统计信号数量。应分别记录从发出求助到有人接手、到有效支援开始，以及到生产过程经验证确认恢复所经历的时间。这些时段反映的是不同问题，不应合并成一个看似令人放心的平均值。
简要记录发生位置、观察到的状况、相关时间戳、响应措施和后续跟进情况。如发生停机，应按统一口径记录持续时间。对同一工位或相同运行条件下反复出现的求助进行复盘；反复复位可能掩盖持续存在的原因。
与操作员和响应人员进行简短复盘，应得出明确结论：哪次求助等待过久、后备响应安排为何未能奏效、哪些问题需要技术调查，以及上次纠正措施是否持续有效。将设备问题反复造成的生产损失纳入更全面的维护改进计划，而不是指望指示灯本身能防止故障再次发生。
设定指标时要谨慎。求助次数减少，可能意味着问题减少，也可能意味着员工不再上报。更快确认接手，只有在后续确有支援时才有价值。关闭事件也一样：必须真正检查并确认已具备恢复生产的条件，且所有剩余纠正工作都有明确负责人，关闭才有意义。
下一次中断确认后，用一份共享计划统筹应对
先让下一次安灯（Andon）求助真正可靠：信号易于理解、响应人员责任明确、升级路径清晰，并向发出求助的人反馈进展。然后补上生产计划环节的缺口。维修团队不应还要负责安排全厂的生产任务顺序，计划员也不应再从各自独立的紧急任务清单中拼凑出整体排程。
如果确认生产中断后，您仍需手动调整关联订单的排程，可以选择 SkyPlanner。记录产能变化并重新计算共享排程，能让交付影响更清晰，也能减少制定并下达下一版可执行任务顺序所需的协调工作。
预约 SkyPlanner 产品演示，带上近期一次设备中断的情况、受影响的订单及其后续工序。了解设备不可用时段会如何改变计划，以及哪些交付决策需要您关注。如果想先了解排程方式，也可以使用演示数据试用 SkyPlanner。
Jussi Mäntylä
生产计划专家，SkyPlanner
