製造業の客先支給品管理システム導入｜所有・消費・精算の設計

製造業で客先支給品の管理システムを導入するとき、最初に決めるべきことはバーコードの種類ではありません。「誰の資産が、どのロットで、いまどこにあり、どの製造指図にいくつ使われ、残りをどう返すか」を、顧客と工場が同じ意味で確認できる取引にすることです。タイの受託製造工場で、顧客から部材を預かる担当者に向けて、入荷、検査、払出、実消費、スクラップ、返却、月次照合、請求境界、システム選定と受入試験までを整理します。

客先支給品管理で最初に固定する三つの境界

本稿の「客先支給品」は、顧客が材料を製造会社の工場へ送り、その工場が顧客の注文を加工・組立する場面を指します。材料の物理的な保管者は工場でも、所有者は契約で定めた顧客のままの場合があります。反対方向、つまり自社が外注先へ材料を支給する管理とは画面が似ていても、指図・資産・報告の主体が逆です。後者の設計は外注加工管理の記事で扱っています。ここでは、客先の材料が自社工場に入ってくる側に焦点を絞ります。

境界の第一は所有です。入荷した瞬間に買い取るのか、加工後も顧客所有なのか、損耗分はどちらが負担するのかを契約と品目マスタで一致させます。第二は数量の確定です。配送伝票の数量、受入実数、品質合格数、工程へ払った数、実際に消費した数は別々の値です。第三は金銭です。部材の価格を製造会社の売上・仕入に入れるのか、加工賃のみ請求するのか、欠損や超過使用をどう精算するのかを決めます。税務・会計処理は契約と現地専門家の判断に従う必要があり、画面の「支給品」チェック一つで確定できません。

Oracleの契約製造の説明では、OEMが提供した構成部品と契約製造拠点にある完成品を、OEM側の組織で追跡する例が示されています。一方、Microsoftの委託在庫の説明は、供給者所有の在庫を受け、製造前に所有権を移す別のモデルです。前者と後者を混ぜると、預かり在庫を自社の購入在庫として計上したり、実消費と所有権移転を同時だと決めつけたりします。自社の契約がどちらか、材料と完成品それぞれについて確認してください。Oracleの契約製造プロセスとMicrosoftの委託在庫説明は、この区別を議論する出発点になります。

「在庫数」ではなくイベント台帳で設計する

在庫残高だけを正とすると、なぜ差が生じたかを追えません。客先支給品は、受領予定、ゲート受領、数量検収、品質保留、合格、保管移動、製造指図への予約、払出、工程投入、実消費、戻し、スクラップ、顧客への返却、棚卸調整を別のイベントとして記録します。各イベントに元伝票、顧客、品目、顧客品番、自社品番、ロット、単位、数量、場所、時刻、担当者、承認者、理由、前後状態を残します。訂正は元イベントを書き換えず、取消と再計上で辿れる形が望ましいです。

GS1 EPCIS 2.0.1は、可視化イベントを対象・時刻・場所・業務文脈・状態の次元で扱います。すべての工場がEPCISを採用する必要はありませんが、イベントを「何を、いつ、どこで、なぜ、どんな状態で」と読む設計は、顧客への報告や後日の追跡に役立ちます。GS1 EPCIS標準に沿ってイベントの項目を見直し、顧客から来るASN、現品ラベル、受入結果、製造実績のキーを照合します。

例えば同じロットを二便で受けた場合、顧客ロットを一つの残高へ即時合算すると、どちらの便で過不足や破損が起きたか消えます。受領単位の容器IDと入荷IDを残し、必要な粒度でロット残高に集計します。箱を開けて小分けした場合は親容器と子容器の関係も記録します。製造指図を跨いで材料を共有する場合も、払出先と戻し元を失わないようにします。

製造業の客先支給品管理システム導入｜所有・消費・精算の設計 - figure 1

入荷・検収・品質保留で確定させる項目

顧客から出荷予定が届くなら、ASNまたは支給予定を入荷前に登録します。ただし予定は在庫ではありません。トラック到着時には、顧客、注文・支給指示、品目、改訂版、荷姿、容器数、封印、顧客ロット、製造日・有効期限が適用される品目ならその日付を照合します。数量単位も、個・箱・リール・重量の換算率と丸め規則を明示します。計数できない材料を伝票数量だけで受領済みにすると、後工程で差が見つかっても発生点が分かりません。

受入時には「到着」「数量検収済」「品質保留」「合格」「不合格」を別状態にします。数量検収済と生産投入可能は同じではありません。外観破損、顧客ラベル不一致、ロット不明、版違い、証明書不足、温湿度逸脱などは隔離場所へ動かし、品質部門または顧客の承認が出るまで引当・払出を禁止します。システム上のブロックと物理ラベルの色・置場が一致しているかをSATで確かめます。現品を止めてもERPの可用在庫に残れば、MRPが誤って使う計画を作ります。

バーコードは自社独自でも運用できますが、顧客ラベルにGS1識別子がある場合は意味を保って読み取ります。GS1のAI (10)はバッチ・ロット、(21)はシリアル、(241)は顧客品番を表します。ただしラベルにある情報が必ず十分とは限りません。顧客の品番と自社の品番を一対一に決めつけず、版・代替・有効期間を含む変換表で管理します。GS1 Application Identifiersにある識別子の意味を、実際の受領ラベルと突き合わせてください。

検収差異は「受領数量を帳尻で修正」ではなく、伝票数量、実数、受入保留数、顧客認定数を残し、差異通知、写真、承認、再送・不足補充、クローズまでを案件化します。配送中の損傷と工場での破損では責任が異なるため、検出時刻と引渡し時点の証拠が重要です。顧客が月末に送ってくる残高だけを正本にすると、現場の異常が次月まで隠れます。

製造指図への引当、払出、実消費を分ける

引当は「この製造指図で使う予定」、払出は「倉庫から工程へ移した」、実消費は「製品や廃棄へ実際に使った」です。多くの在庫差は三つを同じボタンで済ませるために生じます。指図が変更・取消されたとき、引当解除はできても工程に置いた材料は自動的には倉庫へ戻りません。現物を見て戻し入庫し、開封状態や再使用可否を記録します。品目・ロットの取り違えを防ぐため、払出スキャンでは容器と指図を同時に読み、版と受入状態を照合します。

BOMの標準所要量と実消費には、歩留まり、段取り、試作、再作業が挟まります。標準量だけでバックフラッシュすると、顧客が提供した高価な材料の余剰・損失が見えなくなる場合があります。Microsoftの原材料消費の説明も、製造開始時や工程開始時など計上タイミングの選択があることを示しています。原材料消費とフラッシング原則を参考に、対象材料ごとに自動計上かスキャン実績かを決め、差が出たときの承認を設けます。顧客所有品は契約上の報告粒度を優先してください。

一例として、顧客ロットAを100個受け、検収で2個を保留し、98個を合格とします。指図へ60個を払い、良品に56個、工程スクラップに2個、未使用戻しに2個を記録したなら、合格在庫は40個に戻り、保留2個は別残高として残ります。これは計算例であり、標準歩留まりや許容損耗率を示す数値ではありません。帳票が「払出60、良品56」だけなら、2個のスクラップと2個の戻しが行方不明です。顧客との残高照合に必要なのは、この内訳です。

製造業の客先支給品管理システム導入｜所有・消費・精算の設計 - figure 2

スクラップ、再作業、未使用戻し、顧客返却の例外

スクラップは単に在庫を減らす操作ではありません。発生工程、欠陥・破損原因、ロット、数量、写真または検査証拠、責任区分、顧客への通知、現物処置、費用処理を一つの案件にまとめます。品質不良の見本として保管するもの、顧客が引き取るもの、承認後に廃棄するものを区別し、システム上の残高と現物の所在を一致させます。顧客の承認前に廃棄すると、数量は合っても検証できません。

再作業では、良品製造に使った材料と追加投入分を分け、どの指図・版へ使ったかを記録します。BOMから自動的に引かれる通常分と、再作業時に現場が別箱から取った材料を混同しないためです。未使用戻しは、封が切られたか、保管条件が維持されたか、元のロットを維持できるかを見ます。工程から倉庫へ戻っただけで「新品」として再引当できるとは限りません。

顧客返却は出荷と対になるイベントです。返却依頼、選別、梱包、ロット明細、出庫、運送引渡し、顧客受領をつなぎます。顧客が実際に受け取るまでは、双方の残高にタイムラグが生じ得ます。照合表には「返送中」を独立した列として持ち、どちらがどの時点で残高から落とすかを取り決めます。期限切れや契約終了時の残材返却も、通常の出荷指図と混同せず、費用負担と廃棄権限を決めておきます。

月次照合と請求の境界を一枚の表にする

顧客との残高照合では、前月末の確定残高に当月受入を足し、承認済み消費・スクラップ・返却を引き、保留・工程内・輸送中を明示して当月末へつなぎます。数式だけでは足りません。どのイベントを顧客の「消費」に含めるか、締め時刻、タイムゾーン、月跨ぎの受領・返却、再計上の扱いを合意します。タイ工場と日本本社が別の日付で締めるなら、イベント時刻はタイムゾーン付きで保持し、レポートの集計基準日を明示します。

照合差は、顧客側未記帳、工場側未記帳、ロット違い、単位換算、保留処理、返品輸送中、締め日のずれに分類します。差異を翌月の「調整」一行で消さず、元イベント、発見者、原因、承認者、相手方の確認、修正伝票を紐づけます。定期棚卸では、顧客所有材料と自社所有材料を同じ棚で数える場合でも、棚札・システムで所有者を分けます。検品中や工程脇の箱も棚卸対象に含めます。材料管理の基本設計も参照すると、品目・場所・取引の正本を整理しやすくなります。

請求は契約によって異なります。加工賃のみなら、材料の受入・消費を売買として自動仕訳しない設計が必要です。超過消費、顧客指定の歩留まりを超えた損失、保管料、選別費用、廃棄費用を請求するなら、それぞれ承認された数量と金額の根拠を残します。委託在庫のように消費時に所有権が移り材料の購入が発生する契約なら、仕訳と請求の線が変わります。契約文言、インコタームズ、通関・税務の条件を会計担当と専門家が確認し、ERPの取引種別へ落としてください。一般的なソフトウェア仕様から税務結論を推定してはいけません。

ERP・MES・WMSに何を持たせるか

ERPは顧客、契約、受注、製造指図、財務・請求、確定残高の管理に向きます。WMSは入荷、ロケーション、容器、棚卸、現物移動を扱い、MESは指図に対する投入、工程実績、良否、スクラップを扱います。ただし名称だけで役割は決まりません。各イベントに「入力するシステム」「正本となるシステム」「参照するシステム」「訂正権限」「連携失敗時の再送」を決めます。ERPが在庫正本でも、ハンディの未同期イベントを現場が可用在庫として扱ってよいわけではありません。

必要なマスタは顧客、顧客品番、自社品番、版、単位、換算、BOM、製造指図、ロット、容器、保管条件、所有者、品質状態、場所、廃棄区分、請求区分です。同じ顧客品番が複数版で納入される場合、受入時に版を欠落させるとMESで誤投入を止められません。品番変換をExcelの個人表に残さず、変更承認と有効日を管理します。単位換算では「1箱=100個」が常に真か、重量から個数を推定するか、端数をどこで丸めるかまで明記します。

連携メッセージには一意のイベントIDと元伝票IDを持たせ、再送しても二重計上しないようにします。順序逆転、遅延、部分失敗を試験します。たとえば品質保留の通知より払出許可が先に届いた場合、可用化を拒否または保留する規則が必要です。オフラインハンディではローカル入力の時刻とサーバー受信時刻を分け、同期前の数量を「確定残高」と混ぜない設計にします。インターフェース成功と業務計上成功を区別する監視画面も必要です。

導入前の現状調査とスコープの切り方

最初に顧客二社、代表材料数品目、入荷から返却までの伝票を実物で辿ります。画面一覧を先に作るより、どの時点で数量と所有者が変わると認識されるかを聞きます。顧客が支給予定を送る形式、現品ラベル、品番の対応、品目別の保管条件、契約上の許容損耗、月次照合のExcel、請求明細、未解決差異を集めます。倉庫だけでなく、工程脇、品質保留棚、修理・再作業エリア、返品待ちも歩きます。

最初の導入範囲は、扱う顧客・品目・工場・イベントを三つの軸で限定します。たとえば「顧客Aの基板と樹脂部品、倉庫1と組立ライン2、入荷・保留・払出・実消費・戻し・月次照合」を第一波にします。例示であり、推奨数ではありません。選ぶ条件は差異の頻度、部材価値、トレーサビリティ要求、顧客協力、現場運用の安定性です。顧客と照合できないまま社内のスキャン率だけを上げても、最終目的を達成しません。

パイロットでは、過去一か月の実データから初期残高をつくり、同じ期間の取引を再現します。箱単位と個単位、ロット混在、緊急払出、保留解除、指図取消、再作業、スクラップ、返却中を含め、現行帳票との差を可視化します。初期残高に差があるまま稼働日を迎えると、新システムが正しい取引を記録しても顧客残高とは永遠に一致しません。差異の調査、承認、切替時点の共同サインオフを導入計画の工程に置きます。

RFPに入れるべき要求とベンダー比較

RFPには「客先支給品管理に対応」とだけ書かず、所有権のパターン、計上対象外の材料、顧客別在庫、ロット・容器追跡、品質保留、指図別消費、戻し、スクラップ、返却、月次照合、差異承認、請求連携の実例を載せます。業務イベントごとに入力者、確定時点、修正方法、監査証跡、ERP・MES・WMSへの連携先を示します。顧客ポータルが必要なら、閲覧できる残高と未確定取引、データ公開の遅延、権限範囲も明記します。

見積比較では、ライセンスや初期費だけではなく、マスタ整理、既存ラベルの読み取り、ハンディとプリンタ、インターフェース、初期残高移行、例外開発、FAT/SAT、教育、並行運用、保守、顧客帳票変更の費用を揃えます。ベンダーに代表シナリオを同じデータで実演させ、標準機能、設定、追加開発、手運用、対象外を列に分けて回答してもらいます。デモで「在庫が見える」だけなら、契約上重要な消費と精算の証拠は評価できません。

採点は、正常系の機能数よりも、差異処理と監査性を重くします。数量差が出た入荷を確定できるか、保留中のロットが誤って引き当たらないか、指図取消後の現物をどこへ戻すか、二重スキャンや通信再送で残高が増減しないか、締め済み月の訂正をどう扱うか。これらを質問ではなく、その場で操作してもらいます。ベンダーの責任境界と顧客側のマスタ・承認作業も見積に書き込んでください。

FAT・SATで確かめる受入条件

FATでは設定と連携を試験環境で検証します。受入予定100に対し実数98、うち2保留を記録でき、可用数が96となること。二回スキャンしても同じ容器IDを二重受入しないこと。顧客品番と版が不一致なら払出を止めること。払出後の指図取消で、倉庫残高だけが自動的に増えないこと。未使用戻し、工程スクラップ、返却中、締め後訂正が別イベントとして残ること。これらは試験データ例で、基準値や一般的な歩留まりを示しません。

SATでは現場で、実際のラベル、照明、箱サイズ、無線の弱い場所、手袋をした操作、プリンタ、隔離棚、棚卸手順を確認します。端末が圏外になってから復旧したときの重複送信、顧客ラベルの破損、異なる単位の混在、夜勤と日跨ぎを再現します。受入基準は「スキャンできた」ではなく、物理容器、システム状態、顧客報告残高、ERP仕訳または非仕訳が、各イベント後に合うことです。税務・会計上の期待結果は事前に承認された設計書で判断します。

移行判定では、対象ロットと容器の初期残高を顧客・倉庫・品質・経理で確認し、保留品と返却中を分離します。未解決差異を隠したまま「移行完了」にしません。稼働初週は毎日のイベント照合、翌月の締めでは顧客との月次照合を検収条件に入れます。教育は操作順だけでは足りません。「差が出たときに誰が止め、誰が顧客へ知らせ、誰が訂正を承認するか」を役割ごとに実演します。

製造業の客先支給品管理システム導入｜所有・消費・精算の設計 - figure 3

運用を止めない権限、監査、障害時の設計

客先支給品のシステムを稼働させると、在庫を合わせるための手作業訂正を誰でも実行できる状態が最大の運用リスクになります。受入担当は到着実数を記録し、品質担当は保留と解除を判断し、製造担当は払出と実消費を入力し、管理者は棚卸差異を承認するという権限分離を設けます。同じ人が実物を数え、差異を承認し、顧客へ残高を送る運用は、少人数工場では避けにくい場合もあります。その際も、承認の代行者、事後レビュー、理由コード、原始証憑の保存を決め、無条件の管理者権限で日常業務を回さないようにします。

顧客別の閲覧権限も重要です。顧客Aの支給品残高、顧客Bの品番と生産数量、工場の原価情報を同じポータル画面で見せないよう、データ行ごとに権限を試験します。帳票のダウンロードやAPIも同じ制限を適用します。監査ログには、誰が、いつ、どの端末で、どの元取引を、どの値からどの値へ訂正したかを残します。単に最終更新者だけを示すログでは、顧客から一か月前の残高差を問われたときに説明できません。

通信や電源が止まったときは、紙の仮伝票を使うか、オフライン端末へ入力するかを決めます。仮伝票には採番方法、二重入力の防止、復旧時の入力順、現物への識別表示、承認者を定めます。復旧後に仮伝票を一括登録するとき、すでに別端末から登録された同じ容器が二重受入されないよう、容器IDと元伝票IDで照合します。締め処理の途中で障害が起きた場合は、どの帳票が確定済みか、どの連携が未送信かを表示し、顧客へ送る残高を自動的に再計算しない条件も決めます。

KPIと投資効果は差異の収束まで測る

スキャン件数や端末利用率だけでは、顧客との照合が改善したか判断できません。月末の未解決差異件数、差異金額または数量、発見から原因特定までの時間、顧客承認までの日数、保留品の滞留日数、指図別に実消費が記録された比率、返品輸送中の件数を、対象顧客・品目別に追います。数値目標は現状を測ってから設定し、記事中の例示値を外部の業界標準として扱わないでください。

効果試算では、毎月の照合作業時間、棚卸差異調査、誤払出による停止、材料紛失の補填、顧客からの照会対応、請求の修正に費やした実績を基準にします。削減できる時間を全て現金削減として計上するのではなく、実際に残業や外注費が減る部分と、意思決定が早くなる部分を分けます。投資側には端末交換、ラベル消耗品、クラウド利用、インターフェース監視、顧客仕様変更、マスタ保守も含めます。導入後の最初の月次締めが終わるまで、投資効果を確定したと宣言しない方が現実的です。

顧客との共同改善会議では、差異が発生したイベントを順位づけし、一つずつ入力規則または現物動線を変えます。例えば入荷時の単位換算で差が多ければ換算表とラベルを直し、工程戻しの記帳漏れが多ければ戻し棚の位置とスキャン順を直します。システムのアラートを増やすだけで現場の物理動線を変えないと、例外承認が増えるだけです。改善後は同じ指標を翌月に測り、差異の原因が別の工程へ移っていないかを確認します。

導入後の変更管理：顧客仕様が変わった場合

運用開始後に顧客の品番、図面版、ラベル形式、許容損耗、請求条件が変わることは珍しくありません。変更依頼をメールだけで処理すると、倉庫は新ラベルを読めてもMESは旧版BOMで消費し、月次帳票だけが新しい区分になるといった不整合が起きます。変更ごとに適用開始日、対象ロット、未使用在庫の扱い、仕掛への適用、既存指図の再計算、顧客承認の証拠を一枚の変更記録にまとめます。現場が旧版と新版を同時に扱う期間には、ラベルと画面に両者を明示し、どのロットをどの指図へ投入できるかを試験します。

帳票やAPIの項目を追加するときも、顧客側の取り込み処理への影響を確認します。列の並びだけを変えてしまい、顧客側で消費数量が返却数量として読まれるような事故を防ぐためです。月次照合の確定後に過去イベントの訂正が必要になった場合は、元月を静かに書き換えず、訂正日と対象月の両方を残して顧客と合意した処理に従います。こうした変更管理までRFPと運用規程に入れておくと、システム導入後に顧客が増えても同じ台帳を使い続けられます。

よくある質問

客先支給品は通常の購入在庫と同じ品目マスタで管理できますか？

同じ品目コードを使える製品もありますが、所有者、評価、仕訳、引当可能状態、請求区分を分けられるかが条件です。コードを分けるだけで物理ロットを追えなければ不十分です。逆に同じコードでも所有者別の在庫と取引種別を確実に分離できるなら運用可能な場合があります。会計結論は契約と専門家確認に従います。

客先支給品のロット管理はどこまで必要ですか？

顧客要求、品質リスク、回収の粒度で決めます。最低でも受入ロットと顧客品番・版、使用した製造指図との関係は検討対象です。箱ごとの過不足や部分返却が多ければ容器単位のIDも必要です。GS1ラベルのロットを読み取る場合も、顧客ロットと自社の受入IDを同一視しません。

バックフラッシュだけで消費管理できますか？

標準量と実消費が安定し、顧客が許容する報告粒度と一致する場合は選択肢になります。ただし試作、再作業、スクラップ、手拾い、部分戻しが多い材料では差異の理由が消えます。材料ごとに自動計上と実績スキャンを選び、差異の承認方法を定めます。

客先支給品管理システムの導入費用はどう見積もりますか？

登録画面の数だけでは見積もれません。対象顧客・品目・拠点、現物ラベル、既存ERP・MES・WMS、初期残高、顧客帳票、例外処理、端末、試験、教育をRFPに揃えて比較します。特に所有と請求の境界を後から変更すると連携・会計・帳票に広く影響します。費用レンジを一律に示すより、代表シナリオで実演と見積内訳を取る方が確実です。

外注加工の支給品管理と何が違いますか？

外注加工は自社が材料を外注先へ送り、外注先にある自社材料を管理する視点です。本稿は顧客から自社工場へ材料が入り、自社が保管・加工する視点です。現物イベントは似ていますが、顧客報告、所有者、請求、責任の向きが逆です。両方を扱う企業は一つの在庫表に混ぜず、所有者と取引相手の役割を明示してください。

まとめ：顧客と同じ残高にたどり着ける設計から始める

客先支給品管理の成否は、倉庫在庫を表示できるかではなく、顧客が渡したロットと数量から、受入保留、可用、払出、実消費、スクラップ、戻し、返却、締め後訂正までを辿り、双方が同じ残高と精算根拠に到達できるかで決まります。所有と請求を先に定義し、イベントと状態を分け、ERP・MES・WMSの正本を決め、例外をFAT/SATで実演させてください。

TOMAS TECHでは、タイ工場の客先支給品について、現行の伝票と月次照合表を起点に、必要なイベント、現物スキャン、ERP・MES・WMS連携の範囲を整理する段階から相談できます。RFPを作る前でも、差異が生じる工程や顧客への報告条件をお問い合わせページからお知らせください。