アンドンのエスカレーションルールの決め方:三段クロック設計
アンドンのエスカレーションルールとは、「誰が何分以内に到着しなければならないか」を計時と記録が可能な約束に変えたものです。呼び出しが発せられると通知先へ段階的に進み、各段には明確な待ち時間の上限と受信役割があり、上限を超えると現場で電話をかけ回すのではなく自動的に次の段へ引き継がれます。
なぜ呼び出しボタンよりエスカレーションルールが重要か
エスカレーションルールは異常がどれだけ早く受け止められるかを決めます。ボタンを押すことは問題を信号に変えるだけであり、ラインを実際に復旧させるのは、取り決めた時間内に誰かが到着することだからです。ルールを設計する際は、対応の連鎖を計時できる3つの役割に分解します。最初に気づいた工位、処理を担う一次サポート、そして資源を動かす権限を持つ管理層です。呼び出しが発せられると、システムは通知先へ段階的に進め、各段には明確な待ち時間の上限があります。上限内に誰も受付しなければ、信号は自動的に次の段へ移り、受付・到着・処理・終了の記録が完全に残ります。
アンドンがアラームダッシュボードと異なるのは、数値ではなく「対応」を測る点です。ダッシュボードは温度が高いと伝えますが、アンドンは決められた上限内に誰かがその高温に対応したかどうかを伝えます。したがってルールは同時に二つのことを定義する必要があります。異常の種類と深刻度、そして各段の責任者と対応期限です。この二つが定まって初めて、レポートは意味を持ち、「どの種類の異常が最も多く超過するか」に答えられるようになります。
表:三段エスカレーションの上限と役割(班の規模に応じて調整可能)
| 段階 | 発動条件 | 通知先 | 役割と待ち時間の上限 |
|---|---|---|---|
| 一段目の呼び出し | 工位で呼び出しボタンを押す、または故障コードをスキャン | ライン班長/チームリーダー | 待ち時間は通常分単位。担当者が現場で確認 |
| 二段目のエスカレーション | 一段目の上限内に受付または確認がない | シフト主任/当番エンジニア | 上限は一段目よりやや長め。暫定対応案の提示が必要 |
| 三段目のエスカレーション | 二段目も超過、またはライン全体のタクトに影響 | 生産マネージャー/当番工場長 | ライン停止・資源移動・緊急手順の起動を判断 |
最も見落とされやすい列は発動条件です。多くの現場では呼び出しボタンの意味が一つしかなく、材料切れ、詰まり、設備停止のいずれも同じ信号を送ります。その結果すべての異常が一つの経路に集中し、どれを先に処理すべきか誰にも判断できません。エスカレーションルールの起点は、まず呼び出しに種類を持たせることです。
ルールが現場で機能するかを決める4つの設定
ルールがどれほど整っていても、次の4つの設定が曖昧なままだと、稼働後は電話で人を探すやり方に戻ってしまいます。
- 待ち時間の上限は異常の種類ごとに設定する:タクトに影響するライン停止と通常の材料待ちが同じ上限を共有すると、緊急の呼び出しが通常の呼び出しに埋もれます。
- エスカレーションは自動で発生させ、手動クリックに頼らない:上限超過で引き継ぐことはルールそのものの一部であり、班長がクリックしないと昇格しない設計は、忙しいときに最初に省略されます。
- 受信役割は個人ではなく職位に紐づける:班長や当番エンジニアといった職位を通知先にすれば、交代や休暇があっても連鎖は途切れません。
- 受付・到着・終了のすべてを記録する:記録が残るルールだけが事後の振り返りに使え、班の対応評価の根拠にもなります。
この4つのうち、最も設計力を問われるのは二つ目です。呼び出し信号を孤立したボタンボックスではなく、通知を起動できるソフトウェアシステムに接続する必要があります。一般的な方法は、呼び出しボックスをPLCやフィールドバス経由で収集ゲートウェイに接続し、上位ソフトウェアがルールに従って班のメッセージ、看板、当番の携帯へ配信する構成です。これにより昇格はソフトウェアが実行し、現場は受付と処理に専念でき、「昇格を忘れないように」と意識する必要がなくなります。
呼び出し理由辞書:エスカレーションルールを分析可能なデータにする
連鎖を長期的に有効に保つには、統一された呼び出し理由辞書が必要です。辞書は現場で起こりうる異常をあらかじめ限られたカテゴリに分類します。たとえば材料切れ、設備故障、品質異常、治具の問題、技術支援の要請などで、各カテゴリには独自のエスカレーション連鎖と上限が紐づきます。運用上の経験として、カテゴリ数は班が記憶できる範囲に抑えること(通常十数種類で十分)、各カテゴリに明確な判断基準を設けて同じ事象が班ごとに別分類されないようにすること、そして新しいラインや工位を追加した際に対応項目を補える保守性を確保することが挙げられます。
辞書が統一されると、呼び出し記録を集計・分析できるようになります。カテゴリ別にどの異常が最も昇格を起こすか、シフト別にどの時間帯に昇格が集中するか、解決時間と組み合わせて繰り返し昇格しながら解決しない工位はどこか、といった見方が可能です。これらの統計はルール自体を変えるものではありませんが、調整すべき箇所を示してくれます。たとえばあるカテゴリの上限が厳しすぎて、現場で処理できる呼び出しが過度に昇格し、管理層が不要に巻き込まれる、といったケースです。
アンドンの記録は、シフトをまたいで連続するという利点もあります。夜勤の呼び出しと、日勤の受付・処理が同じ記録に残るため、引き継ぎ時に口頭での復唱に頼る必要がありません。多シフトで連続生産する工場では、この点が単一シフトの対応速度以上に、異常が本当に終結するかどうかを左右します。
稼働と受入確認:引き渡し前にルールを実測する
稼働前に、連鎖全体を実条件または模擬条件で一度通し、ルールが現場と一致しているか確認する価値があります。
- 呼び出しから通知まで:現場のボタンを押した後、設定した上限内に正しい職位へ通知されるか。
- 超過から昇格まで:一段目の上限を過ぎても受付しない場合、信号が自動で次段へ移り、一段目の超過記録が残るか。
- 受付と終了:受付・到着・処理・終了が、時刻と担当者を含めて完全に記録されるか。
- 履歴の追跡性:過去の呼び出しをカテゴリ・シフト・工位で照会でき、事後の振り返りに使えるか。
- 看板との同期:現場看板と班のメッセージが同じ呼び出し状態を示し、二つの表示が食い違わないか。
これらの確認項目を通過して初めて、ルールはボタンだけでなく本当に引き渡されたことになります。Orpaonのアンドン案件は通常この順序で進みます。まず呼び出しの種類とエスカレーション連鎖を確定し、次に各段の上限と受信職位を決め、その後に信号接続と通知経路の設定を完了し、最後に上記のチェックリストで一度完全に実測します。当社はこれまでに離散製造ラインでLEDアンドンと設備ネットワーク化を一体化した現場システムを納入しており(公開代称:某日系家電グループの上海工場)、工位の呼び出し・現場表示・ネットワーク通信を一つの経路に接続しています。こうした基盤の上で、ライン条件に応じたカスタマイズが可能です。
現場の設備ブランドが混在しプロトコルが統一されていない場合、エスカレーションルールの起点として、まず設備とプロトコルの一覧を作成し、呼び出し信号の収集方法と通知の配信方法を確認する必要があります。これらの前提が整理できれば、ルールの設計と検証ははるかに速く進みます。
まとめ
アンドンのエスカレーションルールは、壁に貼られた対応時間の一覧表ではなく、ソフトウェアが実行する三段クロックです。呼び出しは種類ごとに発せられ、各段には明確な上限と受信職位があり、超過時は自動で次の段へ引き継がれ、全過程が記録されます。ルールが機能するかは、上限を異常の種類ごとに設定しているか、昇格が自動で発生するか、通知が職位に紐づいているか、そして各処理が完全に記録されているかの四点にかかっています。この四点を定め、統一された呼び出し理由辞書で記録を分析可能なデータに変えれば、アンドンはボタン一つから継続的な対応の仕組みへと変わります。