生産管理システム停止時の手作業継続設計｜復旧後の照合まで決める

生産管理システムの導入を検討するとき、「止まったら誰が何を記録し、再開時にどう戻すか」は機能一覧から抜けやすい論点です。タイ工場ではERP、MES、倉庫管理、品質記録が別々の担当と回線に依存することもあります。停止中に製造を続けられても、復旧後に同じ実績を二度計上したり、検査未確認品を出荷したりすれば継続策は失敗です。本稿は生産管理システム停止時の手作業継続設計を、停止判断から復旧後の照合と承認まで一つの業務手順として組み立てます。製品比較や導入の一般論ではなく、調達時に提示できる受入条件と現場で使える記録様式に焦点を当てます。

「システムが復旧する」と「工場が正しく再開する」は違う

バックアップから画面が開くことと、停止中に作った製品・移した部材・判定した品質を正しい順序で台帳に戻すことは別の仕事です。NISTの情報システム継続計画は、代替設備での復旧だけでなく、短時間の代替手段として手作業で一部業務を処理する方法を挙げています。米国Ready.govの事業継続計画テンプレートも、手作業代替に必要な帳票と資源を文書化するよう求めています。これらはタイ工場にそのまま義務を課す規則ではありませんが、設計すべき項目を洗い出すための一次資料です。

例えばMESが止まってもプレス機は動くかもしれません。しかし、作業指図の最新版、金型と材料ロットの組み合わせ、初品検査結果、良品・不良品数、次工程への引渡しを記録できないなら、完成品として計上する根拠がありません。反対に、顧客の納期が迫っているからと紙の作業票だけで製造を進めても、再開後に二重登録を起こせば在庫が実物より多く見えます。継続設計の対象は「画面の代用品」ではなく、製品・数量・品質・責任者について後から説明できる証拠の流れです。

このため最初に三つの状態を分けます。通常運用、制限付き手作業運用、照合を終えた通常運用です。システムが復旧した瞬間を通常運用への復帰とみなさず、未入力記録がゼロか、重複候補と品質保留が処理済みかを確認して初めて切り替えます。復旧までの時間、データの古さ、手作業を続けられる時間には工場ごとの上限を設定します。クラウド製品の可用性表示だけで、現場の再開条件を代用しないことが重要です。

どの停止を想定するか：システム、回線、端末、連携を分ける

「システム停止」と一括りにすると、復旧責任者も手順も曖昧になります。少なくとも四つに分けてください。一つ目は生産管理アプリケーション自体の停止です。二つ目は工場内Wi-Fiや拠点間回線の停止で、サーバーは正常でも端末から使えない状態です。三つ目はハンディや共有タブレットだけの障害です。四つ目はERP・MES・WMSの連携停止で、各画面は動くのにデータが片側に届かない状態です。

それぞれの停止で、指図の閲覧可否、最新マスタの参照可否、実績の発生場所、再送機能の状態を確認します。ネットワークだけの障害なら、許可された端末のキャッシュや印刷済み作業票を使える可能性があります。一方、ランサムウェア等の疑いがある場合には、キャッシュ端末を再接続することが危険になるため、情報システム担当の隔離判断を優先します。現場が勝手にUSBメモリでデータを運ぶ手順は継続計画に入れません。NISTのOTセキュリティ指針が扱う安全性と可用性の制約を踏まえ、機械の安全制御はITシステム復旧の都合で迂回しないと明記します。

停止分類表には、検知方法、宣言者、停止対象、許される作業、禁止する作業、再評価時刻を書きます。例えば「ERP→MES指図連携停止、MES内の既承認指図のみ実行可、新規指図・設計変更品の着手禁止」といった粒度です。これなら現場監督者がラインごとに判断を変えてしまう危険が減ります。障害の原因が未確定でも、業務影響から暫定的に手作業モードを宣言できるようにしておきます。

停止前に決める境界：続ける工程と止める工程

継続の可否は品目や工程によって違います。評価軸は少なくとも、人的安全、法規・顧客要求、検査結果の取得、ロット追跡、誤投入防止、在庫差異、納期影響です。いずれかの必須条件を紙で確認できない工程は止めます。「紙に書ける」だけでは品質保証を代替できません。測定器から自動保存される数値が必須の工程なら、計測値をどのように記録・照合できるかを品質責任者が承認するまでは着手しない設計が妥当です。

停止中に継続する品目を、A「既承認指図と材料がそろい手作業記録で追跡できる」、B「条件付きで継続できるが完成品は品質保留」、C「作業を止める」に分ける方法が実務的です。この分類は製品の永続的な格付けではなく、障害時点のマスタ、注文、検査、在庫の状態で毎回判定します。Aでも後工程への引渡しに電子承認が必須なら、その境界で止めます。Bは現物に隔離札を付け、通常在庫と混ぜません。Cは設備を安全に停止する手順と仕掛品の状態保存を別紙に持ちます。

ここで「何時間なら紙で回せるか」を決めます。二交代工場なら一交代だけの暫定運用と、翌日までの延長では必要な人員・保管場所・照合件数が違います。上限は製造能力ではなく、記録と照合を正しく処理できる能力から決めます。例えば停止中に手作業記録が毎時100件発生し、その間は照合できないなら、5時間の停止終了時には500件が未処理です。復旧後に新たな手作業記録が発生せず、照合担当が毎時40件処理する場合、全件の照合に12.5時間かかります。復旧後も新規の手作業記録が流入する場合は、その件数を処理能力から差し引いて所要時間を見積もり、流入が毎時40件以上なら未処理は減りません。これらの数値は説明用の仮定であり、自社の実測値で置き換えてください。未処理量の上限を超えたときは、製造を続けても復旧できない状態になるため、停止または品目を絞る判断を行います。

RTO・RPOと現場の「紙運用可能時間」を別々に測る

RTOは許容できる復旧までの時間、RPOは許容できるデータ損失時点の目標として使われます。ただしクラウド事業者のRTO/RPOと、工場全体が完全な取引整合を取り戻すまでの時間は一致しません。Microsoftの事業継続・災害復旧の資料も、組織自身の継続計画には関係者、プロセス、具体的な手順を記載すべきだとしています。パッケージのSLAだけを見て判断するのではなく、工場側の連携、回線、端末、手作業記録、照合を含む「業務再開時間」を別に見積もります。

例として、アプリは2時間以内に復旧しても、停止中の200件の作業票を6時間かけて登録し、さらに品質部門が保留品を確認するなら、出荷可能な状態までの時間は8時間以上です。RTOの目標を2時間と書くだけでは、この遅れは表現されません。そこで、業務影響分析表に「画面復旧目標」「手作業開始までの時間」「手作業可能時間」「未処理記録をゼロにする時間」「品質保留解除までの時間」を別列にします。時間はあくまで自社で決める目標であり、本稿は特定の達成値を保証しません。

RPOがゼロでない場合には、障害直前の何件がシステムに保存済みか不明になる「境界取引」があります。最終バックアップ時刻だけで判断せず、取引ID、設備ログ、端末の送信履歴、印刷伝票の連番を突き合わせます。境界取引を通常の再入力に混ぜると二重計上の原因になるため、専用の保留リストに分けます。見つけた時点で「登録済み」と決めず、システム側の確定状態と現物を二重確認してください。

手作業票は「後で入力できる最小データ」にする

紙の様式を普段の画面のコピーにすると、項目が多すぎて現場が書けません。逆に「品名と数量」だけなら復旧後の照合に耐えません。最低限、手作業票固有の一意な番号、発生日時とタイムゾーン、工場・工程・設備、作業指図番号と版、品目・ロット、材料ロット、作業者・確認者、実績数量と不良数量、単位、品質状態、理由・備考欄を用意します。個人情報をむやみに書かず、社員IDで識別する方式も検討します。

番号は「工場コード−日付−帳票種別−連番」のように、発行拠点が重ならない構造にします。複数ラインが同じ連番台帳を共有しないと衝突するなら、ラインコードも入れます。番号の欠番は消さず、未使用・破棄・紛失を区別して記録します。訂正は元の記載が読める形で訂正日時と承認者を残し、修正液で消さない運用が望まれます。電子化時には紙票番号をシステムの外部参照キーとして保持し、紙票から取引、取引から紙票を検索できるようにします。

材料移動、製造実績、品質判定、出荷指示を一枚に押し込まないことも大切です。各業務は承認者と確定時点が違うため、帳票種別を分けます。例えば材料払い出し票には出庫元・出庫先・材料ロット・数量、実績票には指図・工程・良品/不良・開始終了時刻、品質票には検査項目・測定値・判定者・保留理由を記録します。紙票の写しをどこに置くか、現物の札とどうひも付けるか、停電時に印刷機が使えない場合の事前配布枚数も決めます。Ready.govのテンプレートが帳票と資源の両方を求める理由は、様式だけあっても運用できないからです。

品質保留を「未検査」と「不合格」に分ける

停止時に最も避けたいのは、検査データがまだ確定していない物を合格品として動かすことです。手作業継続の対象には、合格、不合格、判定待ち、記録欠落の四状態を定義します。判定待ちと記録欠落は同じではありません。前者は検査を実施して承認待ち、後者は検査を実施したかどうかも確認が必要です。両者を「後で入力」とまとめると、復旧後に出荷許可を誤ります。

物理的な隔離場所が確保できない場合も、少なくともパレット・容器単位の保留札と移動禁止を設定します。品質責任者が明示的に承認するまでWMSで引当・出荷しないよう、復旧時の登録フローを設計します。MESの画面だけに品質保留を載せて、WMSへ連携されない構成なら、システムが正常に戻っても出荷事故を防げません。停止中は出荷可否の判断を誰が紙で承認するか、復旧後にその承認がどのシステムへ反映されるかを契約と手順で確かめます。

例外を作る場合には「急ぎなので出す」と口頭で許可しません。顧客特採や再検査など、品質マネジメント上認められた正式な手続きを別に起動し、番号と承認を残します。業界・顧客ごとに適用要件が違うため、本稿は一律の出荷可否を示しません。現場の製造継続と出荷可否を別のゲートにすることで、納期の圧力が品質判断を飛び越すのを防ぎます。

復旧後の照合：二重計上・抜け・数量差を三方向から確認

再開手順の中心は、紙票、システム取引、現物の三方向照合です。紙票だけを一括入力し、エラーが出なければ完了とする方法では、停止直前に端末から送った取引が遅延して確定した場合の重複を見逃します。まずシステムの最終確定時刻と同期キューの状態を確認し、停止開始前後の境界取引を保留します。次に紙票を帳票番号順に登録し、システム内に同じ外部参照番号がある場合は再登録を禁止します。最後に対象ロットの現物数量と記録数量を照合します。

照合表の行単位は「一枚の紙票」だけでは不十分です。一枚の作業票で複数ロットや良品・不良品を扱う場合は、帳票番号＋明細番号＋取引種類を一意キーにします。システムが冪等な外部参照キーを受け付けない場合は、入力前照会と入力後レポートで二重チェックし、並列入力を避けます。再送機能がある連携では、メッセージIDと処理結果を一緒に残します。Microsoftの外部ERPとWMSを組み合わせる資料も、在庫更新ログと照合を独立した論点として扱っています。製品固有の機能を一般化せず、自社が使う製品で実際にどのログが取得できるか確認してください。

差異は「重複」「未登録」「数量違い」「品目・ロット違い」「品質状態違い」「時刻・順序違い」に分類します。担当者は差異の原因と処理を記録し、差異のある明細は勝手に上書きしません。特に手作業中に材料を別ロットへ代替した場合、合計数量が合っていてもトレーサビリティが壊れています。生産実績と材料消費の両方でロットを確認します。品質状態に差異がある場合は、品物の移動を止めたまま品質部門の判断を待ちます。

再入力の順序も決めておきます。最初に自動再送を一時停止してキューと最終確定取引のスナップショットを取り、指図と品目マスタの版を確認します。次に紙票と現物の件数を確定し、材料の払い出し・戻し、工程実績、品質判定、倉庫移動の依存関係に沿って入力します。ただしシステム構成で正しい順序は変わるため、現行ERP・MES・WMSの業務ルールを受入試験で実測し、固定した手順書にします。材料払い出しの前に製造完了だけを入れると、システムが自動引落しを行う設定では在庫を二度減らす可能性があります。品質保留中の完成品を先に通常在庫として登録すると、WMSが出荷に引き当てる可能性があります。各段階で件数・数量・ロット・品質状態を照合し、差異があれば次段階へ進まず保留します。再送を再開するのは、紙票からの入力と既存キューの重複関係を確認した後です。取り消しが必要な場合も原取引を消さず、修正履歴が残る方法を製品ごとに確認します。

照合完了の判定も数値だけにしません。すべての帳票番号が回収されたか、破棄・欠番は説明されたか、対象指図の良品数＋不良数＋仕掛残が整合するか、ERP・MES・WMS間の未処理メッセージがゼロか、品質保留品に責任者が付いているかを確認します。差異をゼロにできない場合は、例外一覧に残し、対象ロットだけを保留したまま他の品目を通常運用へ戻す条件を決めます。「差異があるから全工場停止」も「差異があるが全件解除」も避け、影響範囲で切り分けます。

ERP・MES・WMSの境界は単一の責任者を置く

生産管理システムの周辺にERP、MES、WMSがあると、同じ「在庫」でも責任の所在が違います。受注・購買・会計に関係する基準値をERPが持ち、工程実績をMESが持ち、ロケーションと入出庫の実行値をWMSが持つ構成では、停止中にどれを正本として扱うかを取引種類ごとに決めます。単に「ERPが正」と書いても、倉庫内の現物移動の瞬間をERPが直接観測していなければ正しく復元できません。

責任マトリクスには、指図発行、材料払い出し、工程完了、品質判定、倉庫移動、出荷確定について「通常の正本」「停止中の記録元」「復旧時の入力先」「承認者」「下流への再送元」を一行ずつ書きます。二つのシステムから同じ取引を再送しないようにすることが重要です。例えば紙票からWMSに移動を入れ、その結果がERPへ連携される構成なら、ERPへも手入力してはいけません。もし会計締めの都合でERP側に暫定取引が必要なら、後の連携取引と相殺・識別する手順を事前に設計します。

前段のシステムが復旧しても、下流へのメッセージ処理が滞れば整合は戻りません。キューの送信済み、受信済み、業務反映済みは別の状態です。「送信成功」のログだけで在庫の確定を宣言しないでください。システム横断の照合レポートを作れるか、作れない場合にどのCSVや画面を突き合わせるか、サポート契約に誰が責任を持つかまで確認します。一般的な生産管理システム導入失敗の整理では組織・マスタ面も扱っていますが、ここでは停止境界と復旧取引に論点を絞ります。

手作業継続の受入テストを見積もりに含める

発注時の要件に「バックアップあり」「障害対応あり」と書くだけでは十分ではありません。RFPには、実際に停止を模擬し、手作業票を発行・回収・再入力・照合する受入テストを入れます。テストの対象は本番の全件でなくても、工程、ロット、返品、不良、分納、設計変更など停止時に差異を生みやすい代表シナリオを含めます。障害注入の範囲や停止方法は安全と運転を管理する担当の承認を得て、検証環境から始めます。

シナリオAは、作業者が実績送信ボタンを押した直後に回線が切れ、画面には完了が返らない状態です。復旧後に「サーバーには登録済み」か「未登録」かを判断できる証拠を示してもらいます。シナリオBは、停止中に材料ロットを変更し、紙票には旧ロットの取り消しと新ロットの払い出しを記録する状態です。シナリオCは、検査結果が紙で判定待ちのままMESだけ先に復旧する状態です。WMSの引当・出荷がブロックされることを確認します。シナリオDは、ERPとMESの連携が片側だけ再送される状態です。メッセージIDで重複を排除できるか、少なくとも差異を検出して保留できるかを確認します。

FAT（工場出荷前の受入試験）では、制御された環境でソフトウェアと連携の重複防止を確認します。SAT（現地受入試験）では、タイ工場の回線、実物の保留場所、交代勤務の役割、紙票の配布・回収を含めて確認します。両者は本稿が提案する契約上の判定点であり、全業界に共通する固定時間の基準ではありません。

合否基準は「テスト担当が使えた」ではなく、証拠として残る成果物で定義します。停止宣言時刻、手作業開始時刻、紙票の発行・回収一覧、未処理件数推移、重複検出ログ、現物照合表、品質保留と解除承認、通常運用復帰の署名を要求します。ベンダーが提供するのはソフトウェア機能だけか、帳票設計・訓練・試験支援まで含むかを価格表で分けます。Microsoftの実装ガイドも稼働前に統合試験、受入試験、性能試験、移行と切替計画、教育、権限付与の完了を挙げています。ここでのテストは、その一般的な稼働判定を工場停止時の業務へ落とし込む提案です。

調達時に確認する契約・運用の8項目

手作業継続はソフトウェアライセンスの付属機能とは限りません。見積比較では次の八項目を同じ表に並べると、安く見える提案の未計上部分が分かります。

「対応可」とだけ書かれた見積には、どの工程の帳票を誰が作り、誰がテストするかを追記してもらいます。クラウド事業者のBCDRと工場の手作業運用の責任は通常分かれます。ベンダー、現地SI、IT、製造、品質、倉庫の境界を決めなければ、障害当日に互いに相手の作業だと思い込む危険があります。費用は停止対策の初期設計、訓練、年次改訂、バックアップ試験、帳票保管、端末・プリンタ予備、稼働支援を分けて見積もります。架空の定額相場を示すより、自社の停止影響額と対象工程数を出して同条件で比べる方が有用です。

既存の生産管理システムのメリットとデメリットは導入判断の全体像に役立ちます。本稿で追加すべき調達質問は「止まった間の物とデータを、誰がどの証拠で一致させるか」です。この問いへの具体的な回答が無い提案は、平常時のデモが優れていても停止時の責任範囲が未確定です。

タイ工場で運用を定着させる実務上の工夫

日本本社が決めた日本語手順をそのまま現地に渡すと、停止宣言や品質保留の言葉が交代勤務のチームまで届かないことがあります。現場向けにはタイ語の短い判断表を作り、必要に応じて英語・日本語を併記します。翻訳すべきなのは画面ラベルだけでなく、停止理由、使用可否、品質保留、解除承認、差異理由です。用語集には「システム障害」「設備故障」「検査不合格」を別語として定義します。障害時にこの三つが混同されると、IT復旧を待つべきか、保全を呼ぶべきか、品物を隔離すべきかが変わります。

交代時には、未使用の紙票、発行済み番号、未回収票、品質保留ロット、連携保留件数を引き継ぎます。朝礼で「紙運用中」とだけ伝えても、前直の境界取引は伝わりません。引継ぎ簿に最新のシステム状態と障害連絡先を書き、タイ語で復唱確認します。紙票は水や油、粉じんで読めなくなる可能性もあるため、保管場所と筆記具を工程に合わせて選びます。写真で代用する場合は改ざん防止・アクセス権・保存期間を別途設計します。

演習は昼勤のIT担当だけで完結させず、夜勤、休日、品質部門、倉庫、出荷まで含めます。実障害時に「誰がやるか分からない」を防ぐには、代理者を記載し、訓練で一度実際に帳票を回すことが必要です。NISTの2026年OTバックアップガイドは、バックアップを変更管理に組み込み、定期的に取得・テストし、復旧演習で見直すことを勧めています。バックアップ復旧テストと業務照合テストを同日に行うと、技術復旧と現場復帰の時間差も測れます。

90日で設計・演習する場合の進め方

最初の30日は業務影響と停止境界を決めます。過去の停止・回線不調・端末故障の記録を集め、どの指図・品質判定・在庫取引が止まるかを工程図に置きます。各工程の継続条件、停止条件、手作業可能時間、権限者を決めます。次に紙票の最小項目を定義し、現行データの主キーと対応させます。実績の入力画面だけでなく、ERP・MES・WMSを通る同一取引の状態を追います。

次の30日は帳票、連番、差異表、品質保留札を試作します。現場の作業者が手袋を着けた状態で書けるか、夜勤でも指図の最新版を確認できるか、紙票一枚あたりの記入時間を測ります。代表品目で停止後の流れを机上でたどり、同じ紙票から二人が入力した場合、端末に遅延送信が残った場合、途中でロットを替えた場合を試します。机上で説明できない分岐は、本番の障害でも判断できません。

最後の30日は安全に許された範囲で演習し、未処理票ゼロまでの実時間を測ります。ログ、現物、紙票の差異を分類し、品質保留解除に必要な署名をそろえます。合否判定後に手順と帳票を改訂し、版番号を付けます。90日は計画例であり、工場規模や規制に応じて変わります。重要なのは「導入完了」より前に一度、停止から照合までを通すことです。単にバックアップ取得を確認しただけでは、紙運用からの再入力品質は検証できません。

具体例：夜勤中にMESとの連携が途切れた場合

ここまでの項目を一つの架空例に当てはめます。午後10時、ERPからMESへの新規指図連携が止まり、既にMESへ配信された指図は見える状態です。設備は動き、WMSも通常どおりですが、翌朝の出荷に使う材料ロットを夜勤中に切り替える予定があります。この例で最初に確認するのは「MESが動くから製造可能」ではなく、指図の版が確定している品目の範囲です。計画変更の可能性がある品目は着手しません。現場リーダーは障害番号を発行し、対象ライン・指図・時刻を掲示します。IT担当は連携キューを隔離し、原因を調べる間に同じメッセージが自動再送されないか確認します。

既承認指図の製造を続ける場合、材料払い出し票には在庫の実際のロットを記録します。計画上のロットではありません。材料ロットを変更した時点で、品質部門が承認を要する製品ならB分類に移し、製造を続けても完成品を品質保留にします。夜勤リーダーは交代時に発行した紙票の枚数、未回収票、途中で取り消した票の番号、保留ロットを翌直へ渡します。朝に連携が復旧した後は、まずERPからの指図がどの版でMESへ届いたかを比較し、停止中に紙へ記録した実績をその版へ結び付けられるか確認します。版が異なる場合、実績を都合のよい指図へ付け替えず、設計変更の影響判定に回します。

この例で連携停止を30分で直せたとしても、紙票の回収とロットの照合に90分かかったなら、業務の正常化は2時間後です。この時間はあくまで仮例です。演習では実際の時刻を測り、どこで待ちが発生したか記録してください。障害の長さだけを報告するより、出荷可否までの経過を示す方が経営判断に使えます。品質保留ロットを解除できない場合は、他のロットだけを通常処理へ戻せるか、在庫の引当順まで検証します。

照合に使う一覧表を先に設計する

復旧後に「差異を見つける」と言っても、比較する一覧が無ければ担当者の目視作業になります。最低限、紙票番号、明細番号、停止中の発生時刻、取引種類、指図番号、品目、ロット、数量、単位、品質状態、システム取引ID、入力者、照合者、差異分類、是正日を一行に載せます。これを停止時の紙票設計と同時に作ってください。紙票に無い項目を照合表で必須にすると、復旧後に現場へ聞き直す作業が発生します。逆にシステムから出せない取引IDを必須にしても一覧は埋まりません。導入候補の画面やAPI・CSVで取得可能な項目を実機で確認します。

一覧表の集計には、帳票総数と未回収数、入力済み数、差異件数、品質保留件数を置きます。ゼロになった数字だけを緑色にするような単純な表示で構いません。ただし「入力済み」は「照合済み」と違います。登録されたデータが現物と一致しない、またはERPに届いていない場合、入力済みであっても完了ではありません。特に数量が同じでロットが異なる差異は、集計値だけを見ると隠れます。合計数と明細の両方を確認する承認欄を用意します。

システムの再送キューを扱う場合は、障害中に自動再試行した回数と、手動で再送した人・時刻を記録します。再送のたびに新しい取引IDを作る仕様なら、同じ業務取引に複数IDが付く可能性があります。業務の元番号とメッセージIDを別列に置き、業務上の二重計上か単なる通信再試行かを分けます。システムの内部実装が分からない段階では、ベンダーに「同じ紙票番号を二回登録したら何が起こるか」「応答前に回線が切れたら登録結果をどう照会するか」をデモで示してもらうのが早道です。

責任分担は代理者と意思決定の順番まで決める

停止時の役割表に部署名だけを書くと、夜勤や休日に誰も承認できません。障害を宣言する現場責任者、機器と回線を診断するIT担当、継続可能な品目を判断する製造・品質担当、紙票を発行・回収する担当、再入力する担当、照合結果を承認する担当を指名し、代理者と連絡方法を併記します。同じ人が入力と最終承認を兼ねると誤登録を見逃しやすいため、少なくとも高リスク取引は役割を分けます。小規模工場で分離できない場合は、翌直または管理者が事後照合する手順を決めます。

重要なのは、判断の順番です。ITが「復旧」と連絡しても、品質が保留を解除する前に出荷を再開しません。製造が紙票を回収しても、倉庫の現物数量が違えば在庫移動を確定しません。ERPとMESが同期しても、工程内の仕掛品がどこにあるか不明なら指図を閉じません。通常運用復帰の署名者を一人に集約する必要はありませんが、製造、品質、倉庫、ITがそれぞれ自分の確認項目を承認したことを一枚で追えるようにします。

この責任表は契約先にも渡します。製品ベンダーが担当するのはアプリとデータベースの復旧までか、連携メッセージの再送と照合レポートまでか、現地SIが紙票からの登録を支援するか、境界を明記します。停止時に新しい作業を委託しようとしても、権限やデータ持ち出し条件の協議で時間を失います。平時の見積段階で停止演習への参加範囲、連絡先更新、休日対応を確認しておく方が確実です。

よくある質問

生産管理システムが止まったら、すべての製造を止めるべきですか？

一律には決められません。安全、品質、ロット追跡、顧客要求を手作業で満たせる工程だけを、承認された時間と品目の範囲で継続します。確認できない工程は止め、仕掛品を識別して保管します。継続と出荷は別判断にします。

生産管理システム停止時の手作業票に必要な項目は何ですか？

一意な帳票番号、発生日時、工場・工程、指図と版、品目・ロット、材料ロット、数量と単位、品質状態、作業者、確認者が核です。工程固有の測定値や保留理由は追加します。復旧後にシステム取引と一対一で照合できることが項目選定の基準です。

バックアップがあれば手作業継続設計は不要ですか？

不要にはなりません。バックアップはシステムの過去状態を戻す手段です。停止中に製造・移動・検査した実物の状態を自動で作成するわけではありません。障害直前に送信した取引の確定可否も、ログと現物で確認する必要があります。

復旧後の二重計上をどう防ぎますか？

紙票番号と明細番号を外部参照キーにし、再入力前に同番号の確定取引を照会します。境界取引と再送キューを別に保留し、入力後に紙票・システム・現物を照合します。製品に冪等登録機能がない場合は並列入力を避け、二人で入力前後を確認する運用を設計します。

手作業継続の費用は見積もりのどこに入りますか？

ライセンス費とは別に、停止境界の設計、帳票、品質保留、連携ログ、復旧照合、演習、教育、年次改訂、時間外支援を分けて提示してもらいます。導入先ごとに工程・取引量・規制が違うため、単一の相場を当てはめません。同じ受入シナリオで各提案を比較してください。

まとめ

生産管理システム停止時の手作業継続設計は、バックアップの有無だけでは完成しません。止める工程と続ける工程を事前に分け、停止中の証拠を一意な番号で残し、復旧後に紙票・システム・現物を照合します。二重計上、未登録、ロット相違、品質保留を分類し、未解決事項に責任者を付けてから通常運用へ戻す。これを受入テストに含めれば、導入時点で実際の継続力を確認できます。

タイ工場の生産管理システムを選定中で、停止時の紙運用や復旧照合をRFPにどう書くか迷っている段階でも、TOMAS TECHへご相談ください。対象工程と既存のERP・MES・WMSの役割を伺い、最初に確認すべき停止シナリオから整理できます。

参考資料

• NIST: Contingency Planning — 代替手段に手作業処理を含める考え方。
• Ready.gov: Business Continuity Plan Template — 手作業代替の帳票・資源・訓練の記載例。
• NIST: OT Backup Quick Start Guide (2026) — OTバックアップの取得・試験・復旧演習。
• Microsoft Learn: Business Continuity and Disaster Recovery — SaaS側の復旧と利用組織の継続計画。
• Microsoft Learn: WMS-only mode with external ERP — システム間の在庫照合と更新ログの実装例。
• Microsoft Learn: Prepare to go live — 統合・受入・性能テストと切替計画。
• NIST: Guide to Operational Technology Security, SP 800-82 Rev. 3 — OTシステムにおける安全と可用性の考慮。