製造業で製造日報の承認ワークフローシステムを導入するとき、入力画面を紙からタブレットへ移すだけでは、ERPへ渡す生産実績の信頼性は決まりません。現場の記録を誰が確認し、いつ確定し、確定後の誤りをどう訂正して各システムへ反映するかが核心です。この記事では、タイ工場の班長・生産管理・品質管理・IT担当が同じ仕様を決められるよう、承認フロー、版管理、締め時刻、例外処理、ERP/MES連携、RFPとFAT/SATの受入条件を具体化します。数量や期間の例は設計例であり、業界平均や法的要求を示すものではありません。
製造日報の電子化と「承認して実績を確定する」ことは別の仕事
製造日報を電子化すると、紙の回収、Excelへの転記、文字の読み取りといった負荷を減らせます。しかし、未確認の数値を入力直後に在庫へ反映すると、誤入力も同じ速度で広がります。完成数、手直し待ち、不良数、停止時間、材料使用量は、それぞれ入力担当者と確認担当者が異なる場合があります。たとえば班員が完成数を入力し、班長がロットと設備の記録を照合し、生産管理が製造指図との整合を確認してからERPへ渡す運用なら、入力完了と業務上の確定を同一のボタンにしてはいけません。
既存の記事「製造日報の電子化」は入力と利用の全体像を扱います。本記事は、その後に起こる承認、差戻し、締め、訂正の契約を扱います。また「現場の生産実績収集」は実績をどこから集めるかの議論に役立ちます。収集元の確かさと、確定権限の設計は一続きですが、検討項目は分けて記述するとRFPで比較しやすくなります。
Microsoft Dynamics 365の製造実行に関する文書は、作業者の登録が承認を経て関連モジュールへ転送される流れを説明しています。これは特定製品の実装例であり、すべてのERPに同じ標準機能があるという意味ではありません。自社の購買候補には「承認前はどのデータが見え、何が転記されないか」を実機で示してもらう必要があります。出典：Microsoft Learn, Registration for manufacturing execution
まず「日報」を一枚ではなく、確定対象の明細に分解する
紙の帳票は一枚でも、システムが確定すべき単位は多くの場合もっと細かいものです。推奨する識別キーは「工場・ラインまたは設備・製造指図・工程・シフト・生産日・品目またはロット・報告種別」です。このキーを候補として、自社の製品特性に合わせて重複しない粒度を定義します。工場全体の日報一枚に承認印を付ける設計では、特定工程の不良数だけを訂正した際に、他の確定済み明細まで無効化するかが曖昧になります。
各明細に「入力中」「提出済み」「確認中」「差戻し」「承認済み」「連携待ち」「連携済み」「訂正申請中」「訂正確定」「取消済み」などの状態を用意する案があります。状態名より大切なのは、各遷移を誰が実行でき、どの証拠が必要かを明文化することです。承認済みと連携済みを一つにまとめると、ERPが停止して転送できない場合の状態を表現できません。入力画面に見える「緑のチェック」が何を保証するかも分からなくなります。
生産日と入力日時も分けます。タイ工場で夜勤が日付をまたぐとき、午前零時より前後の記録をどちらの生産日に帰属させるかは会計、在庫、日報集計に影響します。日付の決め方を端末ごとに任せず、工場のシフトカレンダーに基づく判定規則を一つ置きます。過去日の入力は必要ですが、「いつ製造したか」と「いつシステムへ記録したか」を同じ列にしてはいけません。
製造日報の承認フロー：班長が何を見るかを先に決める
承認者の仕事を「画面に表示された数値を全部眺めること」にすると、件数が増えるほど形骸化します。班長が確認する項目を、指図の有効性、工程の順序、良品・不良・手直しの数量関係、シフトの稼働時間、停止理由、ロットの紐付け、前工程からの受入、設備カウンターとの差分に分けます。全項目を毎回手動で照合する必要があるとは限りません。機械的に判定できる整合条件はシステムが先に示し、人が理由を判断すべき例外へ注意を向けます。
承認待ち一覧には、単なる未処理件数のほか、提出からの経過、締め時刻までの残り、差分の種類、代行可否を表示します。担当班長の不在時には代理承認者を指定できますが、代理期間、対象ライン、代理理由を残します。同じ人が入力と最終承認を兼ねる必要がある小規模拠点なら、その例外を規則として明示し、特定条件だけ二人目の確認を要求する方法があります。承認人数の多さを目的にせず、誤りが在庫や出荷へ波及する経路に応じて権限を置きます。
差戻しはコメントだけでは足りません。「対象の明細」「修正してほしい項目」「差戻し理由」「期限」を記録し、再提出時に何が変わったかを差分表示します。班長が気づいた異常を電話で伝え、作業者が元の値を静かに上書きすると、初回入力がなぜ不正確だったかを検証できません。差戻しと再提出をイベントとして残すことで、現場教育やマスタ改善の材料にもなります。
自動承認は例外を減らすために使う
すべてを手動承認すると、締め時刻の直前に一括クリックが発生しがちです。自動承認の候補は、指図と工程が一致し、必要なロットと検査結果が揃い、数量関係と時間の範囲が妥当で、設備カウンターとの差が許容規則内である明細に限定します。ただし許容規則は品目や設備で変わり得るため、条件と版を記録します。自動承認の実行主体、適用ルール、判定時刻も履歴に残し、人の承認と区別します。
Microsoft Learnは、時間登録のワークフローにおいて、規則に合う登録を自動承認し、受け入れられない逸脱を手動処理へ回す例を示します。自社で同じ考え方を数量や品質へ広げる場合も、対象範囲と停止条件を個別に設計してください。出典：Microsoft Learn, Calculate, approve, and transfer registrations
生産日報の訂正履歴：承認前と承認後を別の操作にする
承認前なら作業者が訂正し再提出できます。ただし初回値、変更後の値、変更時刻、変更者、理由を保存します。承認後は、原則として元の確定レコードを直接書き換えず、訂正依頼と差分を作ります。権限者が理由を確認して承認し、新しい有効版を作るか、取消イベントと再計上イベントを発行します。どちらを選ぶかはERP側が受け付ける訂正手順に合わせる必要があります。
たとえば良品120個を確定しERPへ送った後、実際は118個だったと判明した場合、画面の最新値だけを118に変えてもERPには120が残る可能性があります。訂正履歴には元の120、訂正後118、差分マイナス2、判明した理由、承認者、ERPへの補正送信の結果を結びます。この数量は説明用の仮定です。返品、再作業、保留品の判定が絡む場合は、単純な差分ではなく元取引の取消と新取引が必要なこともあります。
SAP Digital Manufacturingの公式文書は、すでにERPへ投稿された数量確認を取り消し、その取消を連携先ERPへ伝える手順を説明します。ただし、適用条件や自動入庫・バックフラッシュの有無による制約も書かれています。したがって「取消APIがあるからすべての訂正を自動化できる」と推論してはいけません。候補システムの版と構成で可能な訂正パターンを照合します。出典：SAP Help, Cancelling Quantity Confirmations
履歴を監査のためだけの長いログにすると、現場の調査で使われません。明細画面から、初回入力、差戻し、再提出、承認、連携、訂正の時系列を一画面で追えるようにします。各イベントに発生日時と記録日時を持たせ、端末がオフラインなら送信遅延を区別します。タイ語・日本語・英語が混在する拠点では、理由コードを共通化し、自由記述は原文を保持したうえで翻訳表示の扱いを決めます。翻訳文だけを正本にしないことが重要です。
NIST SP 800-53は、監査記録の内容と保持期間について管理策を示しています。ただし製造日報にそのまま適用される法令ではありません。イベント種別、時刻、結果、実行主体などを検討する参照枠として用い、保持期間は自社の顧客契約、業界規則、個人情報方針に合わせて定めます。出典：NIST SP 800-53 Rev.5.1
締め時刻からERP・MESへ渡す「確定実績」を作る
締め時刻は画面のロック時刻だけではありません。どの生産日の、どの工程・指図・シフトの明細を、どの承認状態で、どのERP取引に変換するかという境界です。締め前に承認された明細を集計し、未承認と差戻しを別に出す設計が基本になります。未承認を黙ってゼロとして集計すれば、生産量が少ないのか入力が遅れているのか分からなくなります。ダッシュボードには「確定実績」「暫定実績」「未報告」「連携失敗」を分離して示します。
ISA-95は製造オペレーションと企業側システムの間の情報交換を整理する枠組みです。MESとERPの境界、システムごとの責任、データの送り手と受け手を決める際に有用ですが、個々の工場の締め時刻や承認者を規定するものではありません。自社のインターフェース仕様では、製造指図の発行元、作業実績の正本、在庫計上の正本を表にして合意します。出典：ISA, ISA-95 Standard
Microsoftの生産指図完了報告では、良品数、不良数、不良理由を入力し、完了報告ジャーナルを確認する手順が示されています。別の公式文書では、完了報告が在庫を更新する仕組みを説明しています。このように「日報に載せた数量」と「ERPで在庫へ計上した数量」を同じ用語で呼んでも、状態と影響は異なります。設計会議では、日報の数量、承認済数量、ERP受入数量を別列で扱ってください。出典：Microsoft Learn, Report a production order as finished／Production order posting
連携レコードに最低限持たせたい識別情報
連携の主キーには、明細ID、版、取引種別、送信イベントIDを組み合わせます。事業上の参照には工場、指図、工程、品目、ロット、生産日、シフト、単位、数量を含め、技術上の追跡には作成時刻、承認時刻、送信時刻、受信応答、ERP取引IDを含めます。どの値を必須にするかは製品・工程と既存ERPの仕様次第です。品目単位が「個」で、設備カウンターが「ショット」、箱詰め実績が「箱」なら換算係数とその適用版を送信の前に確定しなければなりません。
同じイベントをネットワーク障害で再送しても二重計上しない仕組みが必要です。受信側がイベントIDを重複排除できるか、できないなら送信側が照会してから再送するかを明記します。ERPが受信しただけで計上に失敗する場合もあるため、HTTP成功を業務成功と同一視しません。ERP取引IDと最終状態を返すか、結果を照会できるようにします。障害復旧のための再送と、承認後訂正による新しいイベントは、同じ「再実行」ボタンで混同させない方が安全です。
GS1のEPCISは製品や資産の出来事を「何が、いつ、どこで、なぜ、どのような状態で」といった観点から表現する標準です。日報の承認ワークフローにEPCIS採用が必須という意味ではありませんが、ロットの移動・変換イベントと承認済実績をつなぐデータ設計を考える参考になります。出典：GS1, EPCIS Standard
例外を先に書く：遅延、欠測、数量差、設備停止、シフトまたぎ
順調な日の画面だけで見積もると、運用開始後の差戻しと手作業が膨らみます。夜勤担当が端末の通信不良でオフライン入力した場合、端末時刻とサーバ受信時刻が違います。どの時刻を生産実績に使うか、締め済日の遅延入力を誰が承認するかを決めます。端末内に残った記録が重複送信される場合にも、同一IDのイベントを一つとして扱います。通信断の間は「未送信」と明示し、班長の承認一覧にまだ届いていない記録を承認済みと見せない設計にします。
設備カウンターと作業者申告が一致しない場合は、設備値を無条件に優先しません。空打ち、段取り、複数個取り、検査落ち、再作業を分け、差分理由を選べるようにします。手直し品を当日良品に加えるか、翌日の良品にするかも二重計上を防ぐ重要な規則です。ロット検査が終わっていないものを完成数に含める運用なら、在庫の利用可否と分けて管理します。差分の閾値は工程ごとに設定し、承認時に適用した閾値の版を保存します。
作業指図が変更・分割・取消されたとき、古い指図に紐づく未承認日報をどう扱うかも必要です。変更前の指図番号を上書きせず、元指図と新指図の関係を持たせます。月末の会計締めが終わった実績の訂正は、日報側の見かけ上の訂正だけで完了にせず、ERP側の補正可否と会計期間の扱いを確認します。製造現場で「数字が直った」と言っても、在庫・原価・受注引当が古いままでは、工程全体として直っていません。
例外キューと責任者の対応表
| 事象 | 最初に見る担当 | 確認する証拠 | 完了条件 |
|---|---|---|---|
| 未提出・締め遅れ | 班長 | シフト、端末送信状態、指図 | 提出または未報告理由を記録 |
| 数量の整合不良 | 班長・品質 | 設備カウンター、検査、手直し | 差分理由を確定し再提出 |
| ロット不明 | 品質・倉庫 | 受入、払出、現品票 | ロットを特定または保留を明示 |
| ERP連携失敗 | 生産管理・IT | 送信ID、応答、ERP取引 | 二重計上なく受入を確認 |
| 確定後訂正 | 生産管理・権限者 | 元値、変更理由、下流影響 | 取消・補正の受入まで照合 |
この表の担当は例です。小規模工場では兼務しても構いませんが、承認と下流反映の確認を同じ一つの緑表示に潰さないことが肝心です。例外キューは件数だけでなく、発生からの時間と次の担当を示すと、放置の発見に役立ちます。
RFPには画面一覧より「状態遷移と証拠」を書く
製造日報システムの提案依頼書を作るとき、「タブレット入力」「管理者承認」「ERP連携」だけでは見積もりの前提が揃いません。候補ベンダーごとに承認の段数、代理権限、差戻し後の再提出、締めの時間帯、オフライン可否、訂正の方式を異なる前提で見積もってしまいます。RFPの付録に、対象工程の実帳票、指図・品目・ロットのマスタ例、夜勤カレンダー、正常と異常のデータ例、現行ERPの取込仕様を添えます。個人情報と顧客情報は必要に応じて匿名化します。
要求項目は「必要」「望ましい」に分け、実演で判定できる文にします。たとえば「承認済みの良品数を権限のない作業者が編集しようとすると拒否され、元値と試行者を監査画面で確認できる」「承認後の訂正は元ERP取引に結び、重複送信でも在庫が二重に増えない」「締め後の遅延入力は例外キューへ入り、承認前には確定実績へ入らない」と書きます。条件を明文化すると、選定時の比較だけでなく、FAT/SATの合否判定にも使えます。
RFPで依頼する回答表には、機能の有無に加えて、標準設定・追加開発・外部連携のどれで実現するか、制約、必要な運用手順、証拠となる画面やAPI仕様を記載してもらいます。デモでは事前に用意された綺麗な日報だけでなく、誤入力、再提出、夜勤の日付変更、ERPタイムアウトを自分たちのデータで試します。単価だけを比べず、稼働後に誰が例外を処理し、マスタや承認規則を保守するかまで費用範囲に含めて比較します。
FATとSATで確認するシナリオ
FATは供給者側の環境で仕様を検証し、SATは実際の拠点・設備・ネットワーク・運用者で受入を確かめる場として計画します。名称や契約上の位置づけは案件によって異なるため、RFPと契約書で試験責任者、証跡、是正期限を決めます。画面が開いたことだけで合格にせず、入力からERPの取引までを追跡できるシナリオを用意します。
- 正常系：作業者が良品・不良・停止を登録し、班長が承認。締め時刻後にERPが一回だけ受け入れ、日報IDとERP取引IDが照合できる。
- 差戻し：数量不整合で班長が差戻し、作業者が理由を付けて再提出。旧値と新値が見え、承認前にはERPへ送られない。
- 訂正：ERP受入後に良品数を訂正。権限者の承認を経て、採用方式に応じた取消または補正が行われ、在庫と日報の双方が整合する。
- 通信障害：送信応答が失われた後に再送しても、ERP取引が二重にならず、失敗キューと復旧結果が残る。
- 夜勤：日付境界をまたぐ記録と遅延入力について、定義済みの生産日が端末、日報、ERPで一致する。
- 権限：代理承認の期限、兼務の例外、権限外の訂正要求が指定どおりに動作し、履歴に残る。
- 再作業・保留：品質未判定品と再作業完了品を、良品や不良品へ二重計上せずに移せる。
各シナリオの期待値を、画面、API送受信、ERP明細、監査履歴の四つで確認します。SATでは現場の作業員に操作を実施してもらい、手袋、騒音、端末の共有、通信の弱い場所、タイ語表記を確認します。多言語画面なら、状態名と差戻し理由の翻訳が業務上同じ意味かを現場責任者に確認してもらいます。ここで必要なのは翻訳の美しさだけでなく、誤操作を避けられることです。
導入順序：一工程で規則を固めてから広げる
最初から全ラインを同じ承認フローへ載せると、例外がどの工程に起因するか分からなくなります。パイロット工程は、指図と実績の対応が追いやすく、班長が日々確認でき、ERP受入結果を検証できる場所を選びます。最初の段階で現行帳票と承認印の意味を確認し、数量の定義、締め、訂正、連携の一枚の業務ルール表を作ります。次に画面と権限を設定し、実データに近い例外でFATを行います。拠点でSATを終えたら、紙との並行運用期間と切替条件を決めます。
導入後の評価は「入力時間が短くなったか」だけでは不十分です。締めまでに承認された明細の割合、承認待ちの滞留、差戻し理由の内訳、承認後訂正の発生、ERP連携失敗の復旧時間、日報とERPの数量差を観察します。これらは自社の工程と運用を改善する指標であり、この記事では標準的な改善率を提示しません。数値目標は現状測定から決め、現場が入力を避けるインセンティブにならないよう注意します。
将来の設備データ自動取得やAIによる日報下書きを検討する場合も、先に確定データの責任を決めます。センサーは観測値を示し、AIは文章を生成できますが、不良の処置や在庫計上の責任は業務規則と権限者に残ります。入力自動化を進めるほど、観測値、作業者申告、承認済実績の差を明示する設計が重要になります。
導入前の業務観察で集めるべき原本
提案依頼の前に、通常日だけでなく、休日明け、夜勤、月末、品目切替、再作業があった日の原本を集めます。現場の日報、設備のカウンター値、検査記録、班長の承認印、ERPの生産実績、在庫受入、手書き訂正を同じ製造指図で追います。原本間の数量が一致していない場合は、どちらが正しいかをすぐ決めるのではなく、それぞれが何を数えているかを確認します。設備が数えるショット、検査が数える合格品、ERPが受け入れる完成品は、同じ「生産数」という日本語でも異なる対象です。
業務観察では、数字だけでなく判断が止まる瞬間を記録します。班長が欠測を見つけたとき誰に電話するのか、品質判定待ちをどの帳票へ書くのか、承認印を押した後に誤りが判明すると誰がERPへ連絡するのか、といった実際の経路です。公式手順と現場の迂回策が違う場合、その差を責めるためではなく、必要な例外処理がシステムの設計から抜けている可能性として捉えます。短時間の画面説明だけで業務を理解したと判断しないことが、導入後の手戻りを減らします。
データの責任者を工程ごとに定める
指図番号と計画数量はERP、生産時刻と工程イベントはMES、品質判定は品質システム、在庫残高はERPまたはWMSが正本という構成は一例です。実際には製品や既存システムによって異なります。正本の表を作り、同じ値が複数のシステムに表示される場合は、どちらからどちらへ同期するかを決めます。複数画面で値を直接編集できると、承認済みのはずの数字がいつの間にか食い違います。
連携項目ごとに「所有者」「更新契機」「許容される遅延」「訂正を開始できる人」「失敗を監視する人」「照合する相手」を記します。たとえばERP側で製造指図が取消されたとき、MESがその情報を受け取るまでの間に作業者が日報を提出したらどうするか。逆にMES側で訂正が承認された後、ERPが会計期間の締めで受け付けなかったら、誰が代替の調整を決めるか。このような境界の質問に回答できると、画面の便利さだけでシステムを選ぶ危険が減ります。
運用を開始した後も承認規則を版管理する
承認規則は一度設定したら終わりではありません。新製品の追加、設備の更新、夜勤編成の変更、品質判定方法の見直しで閾値や権限が変わります。規則を変えたら、適用開始日、変更理由、承認者、影響する工程、旧規則で処理された明細の扱いを保存します。過去の明細を再表示するときには、現在の規則で再判定した結果を過去の承認結果として見せず、その時点で適用された規則を示します。
特に自動承認は静かに誤った確定を増やす可能性があります。開始直後は自動判定の候補を人が確認し、誤判定と例外の発生を観察してから対象を広げます。条件の変更を現場の単独操作だけで反映させず、業務責任者とシステム管理者が変更内容を確認できる流れにします。反対に、誤った条件が見つかった際には対象工程の自動承認を止められる操作も必要です。変更前後のデータを識別できれば、問題の範囲を迅速に調査できます。
本番切替前に旧帳票との照合期間を設ける
紙やExcelから新システムへ移る際は、一定期間、同じ製造指図について旧帳票と新システムの値を突き合わせます。単に日合計が一致したかだけでは足りません。工程、シフト、ロット、良品・不良・保留の区分、訂正の回数まで比較すると、集計時に相殺される誤りを見つけられます。差が出た場合は、旧帳票が正しいとも新システムが正しいとも決めつけず、現物と検査・在庫の証拠に戻って原因を記録します。照合の担当者、差の許容条件、未解決項目の責任者を決めてから切替日を設定します。
切替後も、承認待ちと連携失敗の一覧を毎日見る担当を明確にします。日報システムの画面が正常に開いても、ERPへの転送が止まっていれば業務は完了していません。監視対象は送信数だけでなく、受入数、失敗数、再送数、訂正数、未報告の指図を含めます。障害が発生した日に手作業で在庫を調整したなら、その調整と後日の自動再送が二重計上にならないよう、手作業の取引IDも関連付けます。稼働開始後にこの運用を持つことで、承認フローが形式だけになるのを防げます。
よくある質問：製造日報承認フローの導入前に確認すること
承認者が休みの日は製造日報を確定できないのですか？
代理承認を認めるかを決め、対象期間、対象工程、代理者の権限、代理理由を記録すれば運用できます。自動承認の条件が適切な明細だけを先に確定し、例外を翌営業日まで保留する設計もあります。ただしERPの締め時刻と衝突しないかを確認してください。期限切れの代理権限が残る状態はSATで必ず試すべきです。
承認後の生産日報訂正履歴はどこまで残しますか？
元値と新値だけでなく、対象明細・版・変更理由・変更者・承認者・各時刻・ERP側の取消または補正結果を結びます。保存期間は顧客契約や業種の規則、社内の記録方針で決めてください。NISTの監査管理策は設計の参考ですが、保存年数を一律に指定する根拠にはなりません。
MESがあれば製造日報の承認ワークフローは不要ですか？
MESの実績収集機能と、承認・締め・訂正・ERP受入の責任分界は別に確認が必要です。MESがすべて標準搭載するとも、必ず別製品が必要とも言えません。RFPで実際の状態遷移と例外シナリオを示し、候補製品の標準機能、設定、追加開発の内訳を比較してください。
製造日報をERPへ即時連携する方がよいですか？
進捗の可視化は即時でも、在庫や原価へ効く確定取引は承認後にする設計が考えられます。一方、工程や製品によっては即時計上が必要です。重要なのはリアルタイムか一括かの二択ではなく、暫定値と確定値、ERP受入済みの値を明確に区別し、訂正できる契約を作ることです。
製造日報システムのRFPとFAT/SATには何を最低限入れますか？
実帳票、状態遷移、権限、締め、生産日、数量の定義、訂正方式、ERP側の重複排除、監査履歴、夜勤と通信障害の例を入れます。FAT/SATでは正常系だけでなく、差戻し、承認後訂正、再送、代理承認期限切れを試し、日報とERPの両側で一致を確かめます。
まとめ
製造日報の承認ワークフローシステム導入で決めるべき中心は、入力欄ではなく「どの明細を、誰が、どの証拠で確定し、間違いをどう訂正してERP/MESへ伝えるか」です。承認状態と連携状態を分け、初回値と訂正履歴を保ち、締め後の例外を扱えるようにします。RFPでは状態遷移と入出力を具体化し、FAT/SATでは異常系まで検証すると、導入後の運用責任を明確にできます。
タイ工場の既存帳票とERP/MESの境界を整理する段階でも、TOMAS TECHへご相談ください。対象工程の実績確定、訂正、連携の論点を一緒に洗い出せます。
参考情報
- ISA, ISA-95 Standard: Enterprise-Control System Integration
- Microsoft Learn, Registration for manufacturing execution
- Microsoft Learn, Calculate, approve, and transfer registrations
- Microsoft Learn, Report a production order as finished
- Microsoft Learn, Production order posting
- SAP Help, Cancelling Quantity Confirmations
- NIST, SP 800-53 Rev.5.1
- GS1, EPCIS 2.0 Standard
