製造業の工程別不良理由コード管理システム導入｜RFPと受入基準

製造業で工程別不良理由コード管理システムの導入を検討するとき、最初に決めるべきものは入力画面ではありません。同じ「傷」が、どの工程で発見され、どの工程で発生し、どの製品仕様に照らして不良と判断されたかを、現場・品質保証・生産管理が同じ意味で読めるようにすることです。本記事は、タイの製造拠点を含む多言語工場を想定し、不良コードマスタの設計、MESの実績入力、ERPとの連携、RFPとFAT/SATの受入試験までを一続きで整理します。数値例は説明用の仮定であり、特定工場の実績や市場平均ではありません。

なぜ工程別不良理由コードが必要なのか

「不良数」は集計できても「なぜ、どこで、何が起きたか」を比較できない工場があります。成形工程の「外観NG」、組立工程の「傷」、最終検査の「外観不良」が同じ欠点を指す場合も、別の欠点を指す場合もあります。逆に、同じ「寸法不良」という語が金型の摩耗、工具の誤設定、測定条件の違いを混ぜている場合もあります。この状態で拠点横断のパレート図を作ると、数値は正確でも分類の意味がそろいません。

工程別不良理由コードは、検査で観察した現象と、後から調査して承認する原因を区別し、どの工程・品目・仕様版で選択できるかを管理するための共通語彙です。単なるドロップダウンの選択肢ではありません。現場が確実に記録できる粒度で事実を取り、品質部門が原因を確定する前に推測を強制しない仕組みです。たとえば外観検査員は「表面に線状傷」を記録できても、それが搬送治具、金型、後工程の取り扱いのどれに由来するか、その時点では分からないことがあります。原因が未確定なら未確定として保持し、判明後に権限を持つ人が別の欄へ登録します。

この区別は既存の品質データ管理システムの3層設計で扱う「記録・紐付け・分析」のうち、とくに記録の意味と分析の比較可能性を支えます。本記事の焦点は、品質データ全般ではなく、人が確認して選ぶ工程別の不良理由分類と、そのマスタ変更の統制です。設備の故障コードをAIで自動正規化する話とも別です。コードを選ぶ作業の責任者と、後から原因を確定する承認者を明示することから始めます。

最初に分離する四つの概念

RFPを書く前に、少なくとも「発見工程」「推定発生工程」「不良現象」「原因」の四つを別の項目にします。発見工程は不良を見つけた作業場所、発生工程は不良を生んだと考えられる工程です。後者は初期値を「未確定」にできる必要があります。不良現象は観察した状態であり、原因は調査による判断です。さらに処置（手直し、選別、廃棄、特採など）を独立させます。「傷」という現象コードを「金型交換」という処置コードと同じ欄で扱うと、分析も監査も壊れます。

入力例を考えます。製造指図WO-1042、品目A、ロットL-21の組立後検査で5個の表面傷を発見したとします。入力時点では発見工程=組立後検査、不良現象=線状傷、発生工程=未確定、原因=調査中、処置=隔離です。調査により前工程の搬送トレイと接触した証拠が確認された場合、品質担当者が発生工程=搬送、原因=トレイ接触へ変更し、変更前後と根拠を履歴に残します。この「発見」と「発生」を一欄に混ぜると、最終検査で見つけた不良をすべて最終検査の責任と誤読します。

ISO 9001は品質マネジメントの枠組みを示しますが、特定の不良コード表の列構成を規定するわけではありません。引用したISO/IAFの監査実務資料はサービス組織の監査を対象に、不適合の記録と適切な管理レベルへのフィードバックを確認点として挙げています。製造工場固有の義務を示す資料としては扱いません。以下の項目設計は規格の条文をそのまま転記したものではなく、監査可能な記録にするための実装提案です。数値や期限を規格要求と誤認しないよう、工場の品質手順と顧客要求で確定してください。

製造業の工程別不良理由コード管理システム導入｜RFPと受入基準 - figure 1

製造不良コードマスタをどう設計するか

最小単位は「コードID・表示名・定義・適用範囲・有効期間・版・状態」です。コードIDは画面表示語を変更しても変えない識別子とし、表示名は日本語・タイ語・英語・必要に応じベトナム語を別欄に持ちます。定義には、選ぶ条件、選ばない条件、類似コードとの境界、代表写真や測定基準への参照を記します。画面の短いラベルだけでは、新任者や夜勤者に同じ判断を期待できません。コードの粒度が粗すぎれば改善対象が見えず、細かすぎれば入力者が迷い「その他」に集中します。

コード体系は全社共通の大分類と、工程・製品群で限定する小分類の二層から始めると管理しやすくなります。例として大分類「外観」の下に「線状傷」「打痕」「異物付着」を置きます。ただし工程が違っても同じ現象なら共通コードにできる一方、判定基準が違う品目では適用条件を分けます。「工程ごとに別IDを振る」ことだけが工程別管理ではありません。共通語彙を再利用し、どの工程で選べるかを関連表で制御する設計もあります。重要なのは集計時に共通概念へ戻せることです。

マスタには「誰が申請し、誰が承認し、いつから使うか」を持たせます。過去のコードを削除せず、廃止または後継コードへ紐付けて履歴を残します。昨日の実績を今日の名称で上書き表示すると、過去に現場が何を選んだのか分からなくなります。実績には選択時のコードIDと版、必要なら表示名のスナップショットを保持します。版の切替時刻は時刻帯と対象拠点を明確にし、オフライン端末が旧版を送ったときの扱いも定義します。

「その他」は完全にはなくせません。しかし自由入力だけで終わらせず、理由の暫定説明、写真・測定値、申請者、レビュー期限、正式コードへの再分類の要否を記録します。その他の比率を下げること自体を目的にすると、作業員が近いが誤ったコードを選びます。見たいのは、未分類が何件あり、いつ、誰が妥当性を確認したかです。新コードの追加には例示データを付け、既存コードで表現できないことを品質・製造の双方が確認します。

MESの不良実績入力を現場で成立させる

入力画面の最小操作は、対象の製造指図・品目・ロットまたは個体・工程を読み込み、良品数・不良数・保留数を照合し、不良現象を選ぶことです。工程と品目に適用されないコードを一覧に出さない一方、現場で選べる候補が消えたときには「未分類」を登録して品質担当へ回す逃げ道が必要です。選択に迷った作業員へ原因の推測を求めず、観察できる現象を優先します。端末で撮影した写真、測定器の値、検査仕様の版を任意または条件付きの証拠として関連付けます。

入力時点で数値の整合を確認します。たとえば投入100個、良品94個、不良5個、保留1個なら合計100個です。ただし再検査、手直し、分割ロット、工程内スクラップ、前工程からの持越しでは単純な合計式が成り立たないため、計算ルールを工程ごとに決めます。同じ個体が複数の現象を持つ場合、現象件数と不良個数を別の指標にします。1個に傷と寸法外れがあれば現象は2件でも不良個数は1個です。これを混同すると歩留まりが実態より悪く見えます。

作業中のネットワーク断は現場では例外ではありません。入力端末が一時保存するなら、送信時の重複防止キー、端末時刻とサーバー受信時刻、旧版マスタの扱いを定めます。端末が同じ5個の不良を二度送っても集計を10個にしないため、実績イベントIDを再送時に維持します。修正は元行を消す方式ではなく、訂正理由・訂正者・承認者と差分を残す方式を検討します。承認待ちの実績をERPへ渡すかどうかも先に決めます。

現場の操作時間は「何秒ならよい」と一般化できません。手袋、画面サイズ、バーコードの位置、工程のタクト、検査密度で変わります。導入候補の評価では、実作業者が通常・例外・手直しの三つのシナリオを実機で操作し、誤選択や中断の場面を観察します。日本語で作った分類をタイ語へ機械的に置き換えただけでは、用語が現地の製品・工具に合わない場合があります。現場のタイ語と本社の日本語が同じIDを指すことをサンプルで確認します。

製造業の工程別不良理由コード管理システム導入｜RFPと受入基準 - figure 2

ERPと品質データをどう連携するか

ISA-95は製造オペレーションと企業業務の情報交換を整理する参照モデルです。ISAはMESを主にレベル3、ERPを主にレベル4として説明しています。この境界をそのまま製品機能の固定ルールにする必要はありませんが、「どのシステムがどの事実の正本か」を決める出発点になります。例として、品目・製造指図・BOM・標準工程はERPまたは生産管理システムからMESへ、工程ごとの実績・現象コード・数量はMESからERPまたは品質システムへ、処置承認は品質システムから両者へ返す構成を考えます。

連携仕様ではコードの文字列だけでなく、イベントID、製造指図、品目と版、ロット・個体、発見工程、推定発生工程、不良現象コードと版、数量と単位、検出時刻、入力時刻、承認状態、処置状態を候補にします。全項目をすべてのシステムへ複製する必要はありません。受信側がどの判断をするかに必要な項目だけを選び、元データへの参照を残します。たとえばERPの原価計算には不良数量・スクラップ額が重要でも、写真の原本は品質システムに置けます。

APIまたはメッセージ連携は、再送・順序逆転・部分失敗を前提に設計します。品質側でコードの原因が後から確定した場合、最初の「現象」イベントを消して新しいレコードに置き換えると、受信側が差分を追えません。訂正イベントで元イベントIDと版を参照し、受信側が重複適用しない契約にします。ERP側で指図が取消済み、ロットが未登録、品目版が違う場合には、エラーキューと担当者を設定します。「連携成功」はHTTP応答だけでなく、受信側の業務レコードへ反映されたことまで確認します。

OPC FoundationのISA-95情報モデルは、MOMとERP間の情報表現を共有する取り組みを示します。ただし自社の不良分類を標準が自動で決めてくれるわけではありません。共通コードの意味、版、責任部門は工場が定義します。NISTの製造データの追跡可能性と信頼性に関する資料も、データ交換の記録とメタデータを重視しています。設計では「いつ、どの指図の、どの検査記録が、どのシステムへ渡ったか」を追えるようにします。

コード管理と不適合処置を混同しない

不良現象のコードは、品質の処置判断そのものではありません。表面傷を見つけた段階で、手直し可否、廃棄、特別採用、顧客承認が自動的に決まるとは限りません。Siemensは欠陥管理を逸脱と是正措置の追跡に関わる機能として説明し、不適合が必ずしも欠陥になるわけではないと区別しています。したがってRFPでは、検出記録、物理隔離、評価、処置承認、再検査、出荷可否を独立した状態として定義します。

たとえば「傷」のコードが入力された直後は対象ロットを保留し、品質担当の評価で「磨き作業後に再検査」を承認するかもしれません。このとき現象コードは変わらず、処置状態だけが変わります。再検査で合格した数量を元の不良数から黙って引くと、発生した欠点の改善指標が消えます。生産良品数、初回合格数、最終合格数、スクラップ数を区別してください。物理隔離ラベルとシステム上の保留状態が一致するかはSATで必ず試します。

不良品の誤出荷防止をさらに設計する場合は、出荷判定・物理隔離・ロット逆引きの実務を参照してください。コード管理の導入範囲を、出荷ゲートやMRB全体の置き換えと混同すると、予定費用も責任者も曖昧になります。まず欠点の記録と分類を安定させ、処置プロセスのシステム化をどこまで同時に行うか、RFPで分けて見積もります。

多拠点・多言語で分類を維持する運用

本社とタイ工場で日本語の「打痕」が別の現象として解釈される場合、翻訳表を作るだけでは解決しません。現物写真、合格・不合格の境界サンプル、測定方法を用意し、タイ語の作業用語と日本語の品質用語を同じコードIDへ結びます。英語版の名称は拠点間の照合に使えますが、現場教育の言語を英語だけにする必要はありません。承認した訳語がどの版から有効かを管理し、スマートフォンや端末の画面で長い語が切れないことも確かめます。

中央マスタとローカル拡張の境界を設けます。製品の共通現象は全拠点で共有し、特定ラインだけの現象は適用範囲を限定します。拠点独自コードを無制限に許すと全社集計で比較できず、中央承認を重くしすぎると現場が自由記述へ逃げます。追加申請の一次判断は拠点品質担当、共通化の判断は全社品質担当といった役割が実務的です。月次で新規・廃止・その他・再分類をレビューし、統合したコードの対応表を保存します。

マスタ変更には、適用製品、旧コードとの関係、過去データの再分類方針、教育対象、ERP・BIレポートへの影響を添えます。旧コード「外観NG」を新しい三分類へ分割した場合、過去の実績を証拠なしに各分類へ按分してはいけません。過去分は旧コードのまま残し、比較図では「旧分類」と明示するか、確認できた個票だけを再分類します。管理会議へ出す不良率の折れ線に分類変更日を注記しないと、工程改善による変化とコード変更による変化を取り違えます。

RFPに転記する要件の書き方

導入範囲を決める会議では、対象工程を一枚の工程図に並べ、「どこで不良を見つけるか」「どこで数量を確定するか」「誰が保留を解除するか」を別の記号で書き込みます。同じ外観傷でも、工程内の自主検査で発見した場合と出荷前検査で発見した場合では、必要な通知、遡及範囲、現物の移動が違います。コード表だけ先に完成させると、この処理の違いを後から画面改修で吸収することになります。まず業務の分岐を図にし、各分岐で必須のデータと責任者を記します。

現場への説明では、コードの目的を「人のミスを探すため」と受け取られないようにします。工程名は発見した場所を示す事実であり、責任の所在を即断する項目ではありません。原因調査と改善措置には別の手続きが必要です。入力者を責める運用になると、選択可能な最も無難なコードや自由記述が増え、データの正確さが下がります。現場レビューでは迷った事例を収集し、用語の説明や適用表を改善します。判断の難しいケースほど、入力画面の責任ではなく分類設計の課題として扱います。

データ移行では旧コードと新コードの対応を「一対一」「一対多」「対応なし」に分けます。一対一であっても旧定義と新定義が同じか確認します。一対多の旧コードは、個票の写真や測定値が残っていなければ新しい小分類へ機械的に振り分けられません。対応なしの履歴を消すと、移行前後の総不良数が一致しなくなります。旧コードを履歴専用として残し、新コードの開始日以降だけを新定義で集計する案を用意します。経営向けの時系列レポートは、集計の切替点を明示します。

権限表には、作業者、班長、品質担当、マスタ管理者、監査閲覧者を列として置き、登録・訂正・原因確定・処置承認・マスタ発行・履歴閲覧の操作を行にします。一人が兼務する小規模工場でも、システム上の権限と承認責任は記録できます。緊急時の代理承認は誰がいつ使えるかを決め、共有アカウントで済ませない設計にします。退職や配置転換時の権限停止、夜勤の承認待ち、品質責任者が不在の場合の保留ルールも運用要件に入れます。

機能一覧に「不良コード入力可能」とだけ書くと、ベンダーごとに別の意味で見積もられます。RFPには対象工程、品目群、ロットか個体か、現象と原因の分離、コードの多言語表示、適用範囲、有効期間、承認ワークフロー、オフライン再送、修正履歴、レポート粒度、ERPとの項目対応を明記します。検査の写真や測定結果を既存システムへリンクするのか、MES内に保管するのかも決めます。データ移行では過去の自由記述を一括自動変換するか、未分類として保留するかを分けて見積もります。

次のように書くと受入判定までつながります。「作業者は製造指図と工程を指定した後、その工程・品目・有効日時に許された現象コードだけを選択できる。原因欄は未確定を許容し、品質承認者だけが確定できる。訂正時には旧値、新値、理由、操作者、承認者、時刻を保存する。承認済みの不良実績はイベントIDを付けてERPへ送信し、同一イベントの再送で数量を二重計上しない」。これは例文です。実際の権限と送信タイミングは工場の手順に合わせます。

見積依頼では標準機能、設定、追加開発、外部連携、教育、データ移行、保守を別々の金額と工期で回答してもらいます。コードマスタの初期作成を誰が行うかも重要です。ベンダーが画面を用意しても、過去の不良票から用語を整理し、工程責任者が判断基準を承認する作業は工場側に残ります。現場検証の回数、タイ語の用語確認、旧実績の取込範囲を見積条件に含めると、後の追加費用を説明しやすくなります。

製造業の工程別不良理由コード管理システム導入｜RFPと受入基準 - figure 3

FATとSATで何を確認するか

FATは工場に搬入する前の環境で、設定されたマスタと処理が設計どおり動くかを確認する試験です。SATは実際のライン、端末、ネットワーク、実作業者、連携先で成立するかを確認します。両者の名称を契約で使わない場合でも、試験環境と現場環境を分ける意義は変わりません。単に画面にコードが表示されたことではなく、間違った選択を防ぎ、例外時に正しい責任者へ渡せることを確認します。

FATの最低シナリオは、①適用工程外のコードが選べない、②有効開始前・廃止後のコードが選べない、③翻訳名が同一IDへ対応する、④原因未確定で現象を登録できる、⑤承認権限のない人は原因を確定できない、⑥訂正履歴が残る、⑦二重送信で数量が増えない、⑧旧版端末からの送信を規定どおり扱う、です。各項目に入力データ、期待結果、証跡の取得方法を付けます。可否を「目視で問題なし」にせず、検索画面とAPI応答、受信側レコードまで照合します。

SATでは、実物のラベル読取、手袋をした操作、複数言語表示、ネットワーク遮断と復旧、端末交換、作業中断、夜勤の引継ぎを試します。隔離棚の現物と保留数量、MES画面、ERPの在庫状態が一致するかを追います。サンプルは通常生産だけでは足りません。1個に複数現象、ロット分割後の不良、手直し後の再検査、入力間違いの訂正、未分類から正式コードへの再分類を含めます。計画された試験件数と許容差は対象工程のリスクと現場条件に基づいて契約で決め、一般値として外から持ち込みません。

受入の判定者も明記します。IT部門がAPIの成功を確認し、製造部門が操作を確認し、品質部門が分類の意味と証跡を確認し、生産管理が数量と指図の整合を確認します。ひとつの部署だけで「合格」を出すと、後で別部署が使えない問題が残ります。指摘は重大度、再現手順、暫定回避、修正期限、再試験結果で管理し、未解決の項目がある場合は稼働可否の承認者を事前に定めます。

導入の順番と評価指標

試行ラインを選ぶ際、最も簡単な工程だけを選ぶと本番で必要な例外が見えません。かといって最初から複数工場の全製品を対象にすると、仕様が決まる前にマスタが膨張します。一定の生産量があり、現象の種類が複数あり、製造と品質の担当者が試験へ参加できる一つのラインを選びます。対象品目の工程を始点から出荷前までたどり、どの時点で個体・ロットが分かれ、再びまとまるかを確認します。この線が不明なままでは、不良を正しい対象へ紐付けられません。

最初のワークショップでは、過去の不良票を十数件持ち寄り、各人が独立にコードを選んでみます。選択が割れた事例は、多数決で片付けず「定義が曖昧」「写真が足りない」「検査仕様が異なる」「現象と原因を混同した」のどれかに分けます。これは特定件数が必要という基準ではなく、境界事例を発見するための実務的な方法です。判定が割れる頻度を導入前に把握し、定義と例示を改訂した後に再度同じ事例を判定すれば、分類表が使えるものになったかを評価できます。

マスタの初版を出したら、現場で一週間または工程に必要な稼働周期だけ並行記録を行います。旧帳票と新システムの両方で記録し、数量、ロット、工程、現象、訂正の差を毎日確認します。ただし二重入力の負担が大きい場合は、サンプル期間と対象指図を絞ります。並行運用の目的は新旧の総数が偶然一致することではなく、差が生まれる理由を把握することです。旧帳票にはなかった保留や複数現象が新システムへ現れるなら、集計定義の違いとして記録します。

本稼働判定には、未解決の重大な欠陥、運用手順、教育記録、バックアップ、障害時の紙帳票、復旧後の二重登録防止を含めます。通信が戻るまで生産を止めるのか、紙で継続するのかは品質と生産の責任者が決めます。障害中に紙へ記録した不良を後入力するときは、発見時刻と入力時刻を区別し、原票を参照できるようにします。復旧後に自動送信と手入力の両方が発生しても、同じ実績を二重に数えない識別方法を決めます。平常時だけでなく、この戻し方までSATで確かめます。

運用後の月次レビューでは、上位不良コードの順位だけを見ると判断を誤ることがあります。あるコードの件数が減った理由は、工程改善、検査基準の変更、生産量の減少、別コードへの付け替えのいずれかです。分母となる投入数や検査数と、品目構成の変化を併記します。重大な不良が少数である場合、件数上位でなくても優先して調べます。現場へ返すレポートは、作業者個人のランキングよりも、工程・設備・品目・時間帯と現象の関係を示し、具体的な改善へつながる形にします。

報告書を多言語で共有する場合は、画面表示名ではなくコードIDを集計キーにします。翻訳が修正されても過去と現在の数値をつなげられます。図表の見出しには表示言語とコード版の基準日を記し、他拠点の担当者が同じ分類を参照しているか確認できるようにします。新しい拠点を追加するときは、コードの説明だけでなく、典型例、境界例、登録してはいけない例を研修に入れます。研修を受けた人が実物の事例で同じ判断を下せるかを確認することが、資料配布の完了よりも大切です。

導入を一度に全工場へ広げる前に、代表的な1ラインでコードと数量の意味を固定します。最初の段階で現状の不良票、Excel、MES画面、ERPの指図・在庫、品質会議資料を集め、同じ不良がどう記録されているかを追います。次に不良現象を重複・曖昧・使われていない分類へ分け、工程・品目への適用表と日本語・タイ語の用語表を作ります。品質・製造・生産管理の責任者がサンプルを使って境界を承認してから画面設定へ進みます。

試行中に見る指標は、不良率だけではありません。未分類件数、訂正件数、原因未確定の滞留、コード選択の迷い、マスタ申請から承認までの時間、ERPとの未連携件数を見ます。これらは新システムが立ち上がった直後に一時的に増えることもあります。見えるようになったこと自体を悪化と断定しないため、旧方式で見えていなかった件数を区別します。改善効果は、分類変更や製品構成の変化を注記したうえで、同じ工程・品目条件の前後を比較します。

展開時には、試行ラインのコードをそのまま全拠点へコピーしません。各拠点の設備、検査仕様、作業言語、ERPの項目、顧客要求との違いを洗い出し、共通部分とローカル部分を決めます。運用開始後のコード追加を誰が受け、何営業日以内に暫定判断するかを決めておくと、現場の自由記述が再び増えることを防げます。この日数は会社の体制に合わせた内部目標であり、外部規格の要求値ではありません。

よくある質問

導入候補を比較する際、画面の美しさや設定項目の数だけで優劣を決めないでください。実務上の差は、分類を変更したときに過去の実績がどう見えるか、複数言語の同義語をどう保つか、現場の訂正がERPとレポートへどう伝わるかに表れます。デモではベンダーが準備した正常事例に加えて、自社で実際に起きた曖昧な事例を持ち込みます。たとえば同じ品目を二つのラインで作り、片方だけ新しい検査基準へ移行した状況を再現します。このとき旧版・新版のコード候補が正しく出し分けられ、双方のデータを無理に同じ意味として合算しないかを確認します。

見積書の「カスタマイズ不要」という表現も、現場運用まで含むとは限りません。設定で多言語ラベルを持てても、承認ワークフローや版の有効日時、端末のオフライン処理は別モジュールという場合があります。RFPでは必須、望ましい、将来検討を分け、必須項目には実演方法を付けます。導入後に追加できる機能であっても、初期のデータ構造を変える必要があるなら将来の拡張性を先に確かめます。たとえば後から個体単位の記録へ移る可能性がある場合、現在のロット単位データと個体IDをどのように結ぶかを確認しておきます。

記録を使う側の品質会議にも設計が必要です。上位コードだけを見て対策を決めるのではなく、そのコードを構成する品目、工程、設備、ロット、時期を掘り下げます。発生工程が未確定のまま多く残っているなら、現場入力の問題と決めつけず、追跡に必要な工程間の紐付けが欠けていないかを調べます。コードが細かすぎて同じ対策へたどり着くものばかりなら統合を検討し、粗すぎて複数の対策が混ざるなら分割を検討します。分類表は一度作って終わる静的な一覧ではなく、実績と改善活動から検証する業務資産です。

投資判断では「入力時間を何秒短縮したか」だけでなく、調査に必要な記録を探す時間、原因未確定の滞留、手戻り、誤った集計を直す負担も見ます。ただし導入前後で製品構成、検査量、顧客要求が変われば単純比較はできません。比較対象と計測方法を導入前に決め、実測できない効果を金額へ無理に換算しない方が、経営判断の信頼性は高まります。正しく分類できるようになった結果、従来見落としていた不良が初期に増えて見える可能性もあります。その変化を失敗と判断せず、記録品質の向上と実際の工程状態を分けて評価します。

工程別不良理由コードは、すべて工程ごとに別IDが必要ですか？

必要とは限りません。同じ現象と判定基準を共有できるなら共通コードを使い、工程・品目との適用関係で選択範囲を絞れます。一方、同じ名前でも判定条件が違うなら、定義または別IDで区別してください。集計の共通化と現場の選択しやすさを両立することが目的です。

MESの不良実績入力で原因まで必須にすべきですか？

入力者が観察できない原因を必須にすると推測値が増えます。まず現象、数量、対象、発見工程を確実に記録し、原因は未確定を許可して品質担当者の調査と承認へつなぎます。安全上・顧客上の重大な事象は別の通知と保留フローを設計します。

製造不良コードマスタの「その他」は禁止すべきですか？

禁止より統制が有効です。想定外の現象を近いコードへ誤登録するより、暫定の説明と証拠を残して期限付きでレビューします。「その他」の傾向を見て、必要なら正式コードを追加します。正式化後の過去実績を自動で書き換えるかどうかは、証拠と承認の有無で判断します。

ERP品質データ連携では、何を正本にしますか？

製造指図・品目、現場の不良イベント、品質処置、在庫・原価のそれぞれについて正本を決めます。製品名だけで役割を決めず、各レコードの作成者、承認者、更新権限、配信先を表にします。イベントIDと版を共有し、再送しても二重計上しないことを受入試験で確認します。

工程別不良理由のRFPとFAT/SATで最も見落とす点は？

正常入力だけを試し、原因未確定、複数現象、訂正、旧版、通信断、再送、廃止コードを試さないことです。RFPの各要件に期待結果を一対一で付け、FATでは機能、SATでは現場と連携先まで確認します。試験の成否を判定する部門を事前に決めます。

まとめ

工程別不良理由コード管理システムの導入では、観察した現象、発見工程、推定発生工程、原因、処置を分け、各データの責任者と変更履歴を決めることが要点です。MESで現場が入力できる分類を整え、ERPとの境界と再送時の扱いを定義し、FAT/SATで例外まで試せば、集計値の意味をそろえられます。製品選定より前に、現物サンプルを使ったコード定義と受入基準を用意してください。

工程別の不良コード表、MESの入力画面、ERPへの連携範囲がまだ整理できていない段階でも、TOMAS TECHへのご相談を受け付けています。現場の記録例から、どこまでを共通マスタにし、何をRFPと受入試験へ書くかを一緒に整理できます。