タイの工場で「顧客から届く注文書を毎日ERPへ打ち直す」「納入先ごとに異なる出荷通知を作る」「請求書と検収結果が一致せず月末に調査する」という状態が続くと、現場の負担は書類の枚数以上に大きくなります。担当者が転記を終えても、相手先の品番、納入先、単位、納期の意味が一致していなければ、誤出荷や請求差異は残るからです。製造業のEDI導入で決めるべきことは、通信方法だけではありません。誰との、どの商取引を、どの識別子と例外処理でつなぎ、受注から検収・請求まで追跡できるようにするかが中心です。
この記事は、タイで工場を運営する日系企業と現地サプライヤー・顧客の担当者向けに、導入判断から見積依頼、90日PoC、FAT/SATまでの実務を整理します。購買・販売・物流・経理・ITが同じ判断表を使えるよう、発注、回答、出荷通知、受領通知、請求の五つのメッセージを一つの取引として扱います。数値例はすべて計算方法を見せるための仮定に基づく例示です。実績や市場相場ではありません。
最初に決める「EDIでつなぐ取引」の範囲
EDIは、企業間の標準化された業務文書をコンピューター間で交換する仕組みです。GS1は発注、出荷通知、受領通知、請求などを対象として説明しています。ただし「EDI導入」という一語で、発注書のPDF送信、顧客ポータルへの手入力、ファイル転送、標準メッセージによる双方向連携まで一緒に語ると、見積もりも成果指標も曖昧になります。まず取引先、拠点、品目群、対象工程、例外を一枚のスコープ表にしてください。
| 確認軸 | PoCで決めること | 先送りした場合の問題 |
|---|---|---|
| 取引先 | 顧客または仕入先を1〜2社選び、担当者と承認者を指名 | 相手のテスト環境がなく接続試験できない |
| 工場・納入先 | 発注元、請求先、納入先、受領拠点を分ける | 同じ会社でも別拠点への誤配送が起きる |
| 品目 | 対象の社内品番、相手品番、包装単位を固定 | 1箱と1個の換算が曖昧になる |
| 文書 | 発注→回答→出荷通知→受領通知→請求の採否を決める | 片方向の転送だけで効果を過大評価する |
| 例外 | 数量変更、分納、拒否、返品、取消、再送を定義 | 正常系だけ通って本番で止まる |
既存の受発注・購買システムの機能比較が必要なら受発注・購買管理システムの選び方を参照してください。本稿はその上にある取引先間のメッセージ契約と接続運用を扱います。ERP側のAPI設計全般は製造業のAPI連携開発で詳しく整理しています。EDIはAPIを使う場合もありますが、APIという転送手段だけでは取引の意味と相手先合意は決まりません。
五つのメッセージを「一つの注文」で結ぶ
典型的な流れは、買い手がPurchase Order（PO、発注）を送信し、売り手がOrder ResponseまたはAcknowledgment（回答）で受諾・変更・拒否を伝え、出荷前にDespatch Advice（出荷通知）を送り、買い手がReceipt Advice（受領通知）で実績を返し、最後にInvoice（請求）を照合する形です。業界や顧客仕様により採用するメッセージと名称は変わるため、この順序を「全企業に必須の標準セット」とは扱いません。PoCでは取引のどこに不一致が多いかを見て優先順位を付けます。
| メッセージ | 最低限の参照関係 | よくある例外 | 確認する業務責任 |
|---|---|---|---|
| PO | 発注番号・行番号、買い手/売り手、品目、数量、希望日 | 発注変更、取消、重複送信 | 購買が正式発注を承認 |
| 回答 | 元POと行番号、受諾数量・確定日 | 一部受諾、納期変更、拒否理由 | 営業/生産計画が回答を承認 |
| 出荷通知 | 元PO、出荷番号、梱包単位、出荷数量 | 分納、混載、運送中の変更 | 物流が現物と通知を照合 |
| 受領通知 | 出荷番号またはPO、受入数量、差異理由 | 破損、欠品、検査保留 | 倉庫/品質が受入実績を承認 |
| 請求 | PO・出荷/受領参照、価格、税区分、請求番号 | 単価差、数量差、締め跨ぎ | 経理が税務要件も確認 |
回答を「通信サーバーがファイルを受け取った」という技術ACKと混同しないことが重要です。技術ACKは到達の手掛かりであり、納期と数量を売り手が受諾した証拠とは限りません。また、出荷通知は現物の出荷予定または実績を表し、受領通知は買い手が実際に受けた数量を表します。この差を保持して初めて、分納や破損を含む照合ができます。PoCでは各文書に同じPO行番号を通し、送信・受信・業務承認の三段階を別の時刻として記録しましょう。
品番と拠点番号の「意味」を合わせる
EDIの失敗は、ファイル形式が読めないことより、同じ項目名の意味が違うことから起きます。例えば買い手の「納入先コード」が工場全体を指し、売り手の「納入先コード」が倉庫ゲートを指す場合、文字列のマッピングだけでは足りません。GS1の標準では、GLNが取引当事者や場所、GTINが商品・サービス、SSCCが物流単位の識別に使われます。ただし、すべての取引先が同じ識別子を使用するわけではありません。採用する識別子は相手先の実装ガイドと合意書に合わせ、社内品番や顧客品番との対応表を管理します。
マッピング台帳は、単なる「送信項目→受信項目」ではなく、①業務上の定義、②データ型と桁数、③必須/任意、④コード体系、⑤変換規則、⑥原本システム、⑦例外時の所有者を持たせます。特に数量と価格には単位、通貨、税の扱いを併記してください。1,000個を100箱と表す換算では、箱入数がロットや品目で変わる可能性があります。変換時点の包装マスタと有効日を残さないと、後から差異の理由を追えません。小数点や日付のタイムゾーンも試験値に含めます。
例示として、顧客POの品番「A-17」、単位「BOX」、数量12に対し、自社ERPの品番「P042」、単位「EA」、換算1 BOX=24 EAと合意した場合、内部所要は288 EAです。ただし受注画面には原文の12 BOXも残し、返品・請求・監査時に元の意味へ戻せるようにします。この換算率は実在企業のデータではありません。もし同一品番でも製品改訂によって箱入数が変わるなら、「品番だけ」のキーでは足りず、改訂と適用開始日をマッピング条件に追加します。
GS1 XMLとEANCOMでは、同じ識別子でも表現上の規則が異なる場合があります。GS1が示すGTINの例では、XMLは14桁へゼロ埋めし、EANCOMでは可変長の表現を使います。したがって「先頭ゼロを数値変換で消しても同じ」と決めつけず、規格・版・相手先実装ガイドを確認してください。メッセージの構文、業務項目の意味、相手先固有のルールという三層を分けた台帳が必要です。
形式と通信方法は相手先契約から選ぶ
候補にはGS1 XML、GS1 EANCOM、UN/EDIFACTのほか、取引先が指定するCSV、XML、JSON、ポータル連携などがあります。GS1は新規利用者にGS1 XMLを勧める一方、既存取引先がEANCOMを使う場合はその仕様に従う可能性を示しています。独自形式の方が短期の一社接続では早くても、複数社に展開するとマッピングの分岐が増えます。RFPでは特定方式を最初から固定する前に、取引先が受け入れる版、実装ガイド、通信プロトコル、テスト窓口を確認します。
通信層にはAS2、SFTP、API、事業者ネットワークなどを使うことがありますが、転送成功と業務成立は別の状態です。ファイル名やHTTP応答だけで受注完了にせず、送信ID、相関ID、PO番号、行番号、バージョン、処理状態、エラー理由を管理します。再送時は同一取引を二重登録しない冪等キーを設計し、修正発注では元番号と改訂番号の扱いを決めます。接続方式が何であれ、通信暗号化、認証、証明書更新、相手先停止時の保留キュー、再送権限と監査ログを運用項目に入れます。
Peppolは電子調達・電子請求などで使われる仕様とネットワークの体系です。OpenPeppolのPost Award文書には注文や請求等の仕様が公開されています。ただし、タイ国内のすべての商取引EDIでPeppolが法的に必須という意味ではありません。顧客がPeppolを求めるか、他のネットワークや個別EDIを求めるかを確認し、要件に入れるべきです。タイのe-Tax Invoiceについても別途税務要件として判断します。
タイのe-Tax Invoiceと商取引EDIを混同しない
商取引EDIのInvoiceメッセージは、取引先が請求情報を照合するための業務文書です。一方、タイのe-Tax Invoice & e-Receiptは税務上の電子文書・送信等に関する制度です。EDIでInvoiceを送っただけで、その文書がタイの税務要件を満たすとは限りません。逆に税務対応を終えても、発注・出荷・受領の差異解消まで自動化されるわけではありません。両者は同じ請求データを参照しても、目的、承認者、保存、送信先、検証項目が違います。
具体的には、EDI側では「取引先がPOと請求行を突合できたか」を確認し、税務側では現行のタイ歳入局およびETDAの要件、文書形式、署名や送信方法、保存を担当者が確認します。規則や採用可能な方式は変更され得るため、実装直前に公式情報を再確認してください。税務連携の設計はタイのe-Tax InvoiceとERP連携を参照できます。EDIの見積書には、税務連携を含むか除くかを明記し、含む場合は税務適合の検証責任を別項目にします。
導入前の現状測定：効果を誇張しない基準線
「EDIなら転記がゼロになる」と見積もる前に、取引先別に現状を数えます。対象期間を4〜8週間などと決め、PO件数と行数、転記分数、変更件数、出荷・受領差異、請求差異、再送・問い合わせ件数を採取してください。現状が紙、メール、ポータル、既存EDIの混在ならチャネル別に記録します。入力に要する時間だけでなく、差異調査と相手先への確認に費やす時間を含めます。一方、EDI後も例外承認やマスタ保守は残るため、削減率を100%としません。
評価指標の例は「PO受信からERP受注確定までの中央値/90パーセンタイル」「手入力を要した行の割合」「メッセージ初回受理率」「PO行と出荷・受領・請求行の照合率」「処理不能の例外が担当者に届くまでの時間」です。どの数値を成功基準にするかは、現状を測った後に経営・現場・取引先で合意します。注文件数だけを数えると、一件の注文に数百行ある工場では負荷を見誤ります。行数と変更回数を同時に見てください。
90日PoCの進め方と各段階の成果物
90日は普遍的な導入期間ではなく、一社・限定品目・限定文書で検証するための計画例です。取引先の準備やマスタ品質によって延長・縮小します。全取引先を同時に接続すると、相手先固有の例外が重なり原因切り分けが難しくなります。初回は変更頻度が適度で、担当者が協力できる一社を選び、正常系に加えて実際に起きる変更・分納を対象にします。
| 期間例 | 作業 | 判定可能な成果物 |
|---|---|---|
| 1〜15日 | 現状測定、取引先同意、対象POと品番・拠点の棚卸し | スコープ、現状KPI、責任分担、サンプル文書 |
| 16〜30日 | メッセージ契約、識別子・単位・例外・セキュリティ設計 | 実装ガイド、マッピング台帳、試験ケース |
| 31〜55日 | 変換・ERP接続・監視画面の構築、単体試験 | サンプル通過記録、エラー/再送ログ |
| 56〜70日 | 相手先との結合試験、変更・分納・取消・障害試験 | FAT証跡、未解決課題と対応計画 |
| 71〜90日 | 実環境で限定運用、現場教育、測定 | SAT証跡、KPI比較、展開判断 |
FATは、提供側または試験環境で仕様どおりに変換・連携できるかを確認する場と定義します。SATは、実際の工場・取引先接続・担当者・業務手順で使えるかを確認する場と定義します。契約によって名称や場所は異なるため、RFPに受入条件を文章で記すことが大切です。FATで通ったサンプルだけをSATで再実行しても十分ではありません。SATでは実際の通信停止、マスタ未登録、長期連休、担当者不在、発注改訂の運用まで確認します。
FAT/SATの試験ケースは「失敗の扱い」まで書く
正常系の受注成功だけでなく、重複メッセージ、順序逆転、桁数超過、品番不明、拠点不明、単位不一致、価格差、部分出荷、数量超過、請求取消を試験します。それぞれに入力サンプル、期待するERP状態、相手先へ返す応答、担当者通知、再処理の権限、監査ログを定義します。失敗を単に「エラー表示」と書くと、夜間の不着を誰も発見できない可能性があります。
たとえば同じPO番号・行番号・改訂番号のメッセージを二度送る試験では、二回目に重複受注が作られず、受信履歴には二件の通信が残り、業務上の一件に結び付くことを確認します。変更発注が元発注より先に届いた場合は、保留にするのか、元を待つのか、取引先に再送を依頼するのかを仕様に決めます。自動再送は便利ですが、相手先が既に処理した可能性を考慮しなければ、重複請求を生みます。エラー画面と監視通知は購買・営業・物流・経理の担当者が理解できる言葉にします。
取引先オンボーディングの実務
最初の一社で作った変換プログラムを、次の取引先へそのまま適用できるとは限りません。共通のメッセージ形式でも、必須項目、商品コード、納期の扱い、添付資料、出荷単位が違います。取引先ごとに実装ガイドの版と例外表を保存し、共通変換ルールと取引先別差分を分けて管理します。仕様変更の通知先、テスト環境、証明書期限、障害窓口、稼働時間、切替日、並行運用期間も接続台帳に記録してください。
オンボーディングの入口には、標準の確認票を用意します。商流責任者、技術担当、経理担当、採用メッセージ、サンプル、識別子、通信方式、変更頻度、SLA、サポート言語を一度に確認します。相手先がEDI対応できない場合は、手動入力のWebフォームや管理されたCSV取込を移行措置として認めてもかまいません。ただし「EDI接続済み」と呼ばず、手入力がどこに残るかをKPIへ記録します。小規模サプライヤーに高額な専用接続を強制するより、取引量と必要な統制を見て段階的に参加してもらう方が現実的です。
本番切替では、旧メール発注と新EDI発注を無期限に二重運用しないことも重要です。同じPOを両方で受け付けると重複登録の危険があります。並行期間、正本チャネル、緊急時の代替手段、旧方式停止条件を文書化し、双方の担当者が承認します。取引先追加のたびにテストデータと結果証跡を残せば、三社目以降の見積もり精度も上がります。
RFPで見積条件をそろえる
「EDIを導入したい。費用を見積もってください」だけでは、初期費用と月額費用の比較ができません。RFPには対象取引先数、文書数、月間メッセージ数、ピーク、ERP環境、データ品質、要求する可用性、ログ保存、言語、税務連携の範囲を記載します。サンプル文書は機密情報を匿名化して添付し、実データの品番や取引条件を外部へ出す前に社内の共有権限を確認してください。
| RFP項目 | ベンダーに回答を求める内容 |
|---|---|
| 接続方式と標準 | 対応形式・版、通信方式、相手先固有実装の扱い |
| ERP連携 | 受注/購買/出荷/入荷/請求の入出力、変更と取消の処理 |
| マスタ | 品番・拠点・単位・税区分の原本、同期と承認フロー |
| 例外運用 | 監視、通知、再送、手動復旧、重複防止、監査ログ |
| セキュリティ | 認証、暗号化、鍵/証明書の更新、権限、保管先 |
| 受入試験 | FAT/SATの試験ケース、証跡、合否、瑕疵対応 |
| 費用 | 初期、取引先追加、メッセージ従量、月額、保守、改修 |
| 契約と出口 | データとマッピングの所有、移行、解約時の取り出し |
比較では、単価だけでなく「取引先一社を追加する時に誰が何日かかるか」「障害発生後にどのログで原因を特定できるか」をデモで確認します。標準対応と書かれていても、相手先ガイドへの適合が別料金なら総費用が変わります。相手先テストの調整、現場教育、ERP側改修、法務・税務確認、将来の版更新の負担も含めた見積もりにしてください。
費用モデル：仮定を置いて計算する
ここからの金額は市場価格でもTOMAS TECHの見積額でもなく、判断方法を示す架空の試算です。実案件では取引先仕様、ERP改修、契約、通信量で大きく変わります。例として、初期費用をTHB 1,200,000、月額をTHB 45,000、取引先追加を一社THB 120,000、初期対象を2社、初年度にさらに2社追加すると仮定します。この場合、初年度現金支出は1,200,000 + 45,000×12 + 120,000×2 = THB 1,980,000です。税・社内人件費・回線等を含まない仮定と明記します。
便益も分解します。月間PO 2,000件、1件あたり転記・照合8分、EDI後にその70%を削減し、作業時間の内部評価をTHB 300/時と仮定すると、月間の作業時間便益は2,000×8÷60×0.70×300 = THB 56,000です。加えて差異調査の回避が月THB 35,000、急ぎの再送・配送調整の回避が月THB 20,000と仮定すると、月便益はTHB 111,000です。月額費用THB 45,000を差し引いた月次純便益はTHB 66,000。初期費用だけを66,000で割る単純回収期間は約18.2か月ですが、取引先追加費用や立上げ期間、税、運転資金、時間価値を含まないため投資判断には不十分です。
作業時間が減っても給与支出が直ちに同額減るとは限りません。残業削減、採用回避、受注処理能力の増加など、実際に価値として回収できる条件を確認します。差異や遅延の削減を金額換算する時は、過去の実測件数と平均対応費用を掛け、販売機会損失を安易に上乗せしません。保守的・標準・高負荷の三つのシナリオを作り、取引先追加費用と月額の従量条件を含めて3年間の総費用を比較してください。
発注すべき条件、まだ発注しない条件
導入を進めやすいのは、同一取引先との文書件数が多い、改訂や分納が頻繁、手入力の遅れが生産計画や出荷に影響する、相手先がテストに協力できる、社内マスタの所有者が決まっている場合です。まず小さく試すべきなのは、取引先ごとの品番対応が未整備、発注の承認フローが定まらない、請求差異の原因が税区分なのか受領実績なのか不明、ERPへの入力仕様が頻繁に変わる場合です。こうした前提はEDI製品の購入だけでは解消しません。
「一社だけ、月数件の注文」であれば、最初から全面連携するより管理されたCSVやポータルで十分なことがあります。反対に、顧客が出荷通知と受領差異の電子連携を調達条件にしているなら、費用対効果だけでなく取引継続リスクも判断材料です。判断を急ぐ前に、失敗した時に手動へ戻す手順と、システム間のどこに正本データを置くかを確認しましょう。
調達と導入契約で見落としやすい境界
EDI基盤の提供者に、すべての業務判断を委ねることはできません。発注の承認規則は購買部門、出荷実績の確定は物流部門、受領差異は倉庫と品質部門、請求と税区分は経理・税務部門が責任を持つ必要があります。IT部門は接続、変換、監視、権限の仕組みを提供し、業務部門の判断を記録できるようにします。RFPの回答者に「標準搭載」と書かせるだけでなく、誰がマスタを更新し、誰が例外を承認し、どの費用に含むかを一覧にしてください。
契約には、初期の導入範囲、取引先追加時の単価、メッセージの版更新、障害対応時間、データの所有権、ログの取り出し方法を入れます。通信事業者、変換事業者、ERPベンダーが別々なら、障害の切り分け窓口を一本化するか、連絡順序と回答期限を決めます。相手先のシステム停止による遅延を自社ベンダーの可用性違反とみなすかどうかも、測定地点が違えば答えが変わります。契約上のサービス水準は、送信完了、到達、業務取込のどの状態を測るかまで書いてください。
導入プロジェクトでは、現場が発注書の画面を使い慣れていることと、相手先から届いたEDIを信頼して運用できることを同一視しない方がよいでしょう。自動作成した受注をどの権限で確定するか、変更の承認を誰が行うか、例外が残ったまま出荷できるかを、担当者と実データに近い試験で確認します。画面教育は操作手順だけでなく、数字が食い違ったときの連絡先と判断順序を含めてください。業務部門がこの手順を自分の言葉で説明できることがSAT合格の一つの証拠になります。
多拠点・多言語のタイ工場で追加確認すること
タイの工場と日本の本社、海外顧客、現地仕入先が同じ取引に関わると、注文時刻、出荷時刻、請求日付が異なる時間帯で記録されます。システム内部では時刻とタイムゾーンを保持し、画面表示は担当拠点の現地時刻に変換します。「当日中」の意味は契約上の締め時刻で定義してください。休日も国や工場によって違うため、納期回答の営業日計算を一つのカレンダーで済ませない方が安全です。輸出入を伴う場合は、商取引EDIの文書と通関書類の責任範囲を分けて確認します。
現地の担当者がタイ語で運用し、本社が日本語で承認し、海外顧客が英語のメッセージ仕様を送る場合、エラー通知の翻訳も運用要件です。ただし、取引先コードや品番、状態コードは言語ごとに別の意味になってはいけません。コードと元の値を保存したうえで、人が読む説明を各言語へ対応付けます。研修資料に画面のスクリーンショットだけを貼ると、改修後に古くなります。操作の目的と判断基準を併記し、言語版を更新する責任者を定めます。
タイ国内のe-Tax関連文書、海外顧客のEDI、社内ERPの三つが交わる場合は、同じ請求番号でも各システムの状態が違うことがあります。送信済み、受信済み、税務処理済み、支払照合済みという状態を一つの「完了」へ丸めないでください。取消や訂正時にどの状態を戻し、相手先へ何を通知するかを、経理と営業の両方で確認します。この区別は数字を合わせるためだけでなく、問い合わせを受けた際に現在地を迅速に説明するためにも必要です。
マッピング台帳のサンプル：発注一行を追跡する
実際の設計では、POヘッダーだけを先に作っても業務価値を測れません。一行の発注が回答、出荷、受領、請求にどのように引き継がれるかを追えることが重要です。仮の例として、買い手の注文番号を「PO-EXAMPLE-01」、行番号を「10」、買い手品番を「A-17」、売り手品番を「P042」、発注数量を「12 BOX」とします。売り手が「10 BOXは指定日に、残り2 BOXは翌週」と回答した場合、注文行を単一の日付で上書きしてはいけません。元の依頼、確定した二つの納期、変更理由を関連付けて残します。ここで示す番号と数量は説明用の架空値です。
出荷通知が最初の10 BOX分だけ届いたら、同じPO行に対して出荷通知番号と出荷明細番号を保存します。倉庫で9 BOXしか受領できなければ、受領通知は9 BOXと差異理由を返し、ERPの受入実績を自動で10 BOXにしないでください。破損や数量差は品質判定にも影響し、買掛または売掛の照合にもつながります。請求が10 BOXで来た場合、契約条件に応じて保留、差額照会、請求訂正などを担当者が判断します。「受信できた」ことと「支払ってよい」ことは異なる状態です。この状態遷移を表にして両社で承認するだけでも、PoC中の議論が具体的になります。
台帳の列には、相手先メッセージ項目、社内ERP項目、表示名、説明、必須条件、許容値、変換、原本、照合相手、エラー時の処理を設けます。たとえば「RequestedDeliveryDate」は単なる日付の文字列ではなく、顧客が希望する工場への到着日なのか、サプライヤーの出荷日なのかで計画への入力先が変わります。「Quantity」は発注単位と在庫単位が違うなら二つの値を保持します。「BuyerParty」と「ShipTo」は同じ法人であっても、請求・納品の責任主体が違うことがあります。項目の型変換だけを終えても、こうした意味が未合意なら試験を通過させない方が安全です。
データの正本も決めます。品番変換は誰が申請し、誰が承認し、いつから適用するか。取引先の住所変更が届いた時、ERPの取引先マスタをEDIから自動更新するのか、承認待ちにするのか。単価は購買契約から参照するのか、POを優先するのか。判断をシステムの隠れた設定にすると、担当者交代時に説明できなくなります。マスタ改訂履歴とメッセージ版を紐づけ、後日同じ取引を再現できる設計にしてください。
運用設計：夜間の不着に誰が気づくか
EDIは人の転記を減らせても、無人で全例外を解決する仕組みではありません。PoCの最初から運用責任を決める必要があります。送信元の取引先、通信基盤、変換処理、ERP取込、業務承認のどこで止まったかを区別し、警告を受ける担当者を分けます。技術担当へ「ファイル受信失敗」を通知するだけでは、翌朝の生産計画に影響するPOが未確定のままになるかもしれません。購買と生産計画には業務への影響を示し、復旧の優先順位を判断してもらいます。
運用手順書には、定時の未受信検知、再送の起点、相手先への連絡、手動代替の条件、復旧後の二重登録防止を含めます。ある取引先が毎日決まった時刻までに発注する場合は、その時刻を過ぎても届かないこと自体を監視できます。一方、不定期発注なら「未受信」を障害と断定できず、相手先の送信確認との突合が必要です。監視の閾値は契約と業務実態に沿って決め、全社共通の固定値を押し付けないでください。
ログには個人情報や価格条件が含まれる場合があります。本文の全量を誰でも見られるダッシュボードに載せるのではなく、役割に応じた権限とマスキングを設けます。調査に必要な相関ID、時刻、状態、エラー分類、担当者の対応履歴は残し、保持期間と削除方法を契約・社内規程に合わせます。証明書の期限切れや相手先の仕様変更は運用で起こるため、期限前のアラートと再試験の時間を確保します。週次会議では受信件数だけでなく、未解決例外の件数と滞留日数を確認します。
展開判断を数値で行うためのゲート
90日PoCの出口では「つながったから全社展開」と決めず、予定した業務価値と運用負担を比較します。例えば、初回受理率、受注確定までの時間、手入力の減少、例外解決までの時間、請求差異の件数をPoC開始前の基準線と比較します。ただしPoC期間に取引量や製品構成が変わった場合は、その影響を分けて説明してください。繁忙期だけの一時的な効果を年間便益に単純換算しないことも大切です。
展開ゲートの例として、①優先したメッセージが正常系と主要例外系で合格、②担当者が自分で再処理・連絡できる、③POから請求まで参照番号が切れない、④責任分担と保守契約が承認済み、⑤追加取引先一社あたりの見積もりが成立、という五項目を設定できます。これは推奨する検討項目であり、全工場共通の合格基準ではありません。現場の影響が大きい項目は数値の達成率だけで免除せず、失敗時の代替手段を確認してから進めます。
本番後も四半期ごとに、取引先別の例外件数、品番マッピングの修正件数、実際の運用費、追加接続に要した日数を見直します。最初の一社で作った標準が二社目でどれだけ再利用できたかが、将来の費用を左右します。再利用できなかった理由が取引先固有要件なら差分として管理し、社内の品番・拠点マスタの揺れなら共通側を改善します。PoCの成功を「動いた」という一回の事実で終わらせず、接続先を増やしても管理できる仕組みに育ててください。
よくある質問
EDIとAPI連携は同じですか？
同じではありません。EDIは企業間で合意した商取引文書とその意味を扱い、APIはシステム間でデータや機能を呼び出す方法の一つです。EDIメッセージをAPIで運ぶ設計もあります。選定ではメッセージ契約と転送方式を別々に評価してください。
タイでPeppolの採用は必須ですか？
全商取引EDIに一律の必須条件として扱わないでください。採用すべきかは取引先の要求と対象文書、現行制度の確認によります。Peppolの仕様とタイのe-Tax要件は別々に照合します。
電子請求書を送れば税務対応は完了ですか？
いいえ。商取引のInvoice交換と、タイのe-Tax Invoiceの要件充足は別の確認です。税務担当者が歳入局・ETDAの現行資料を確認し、必要な形式、送信、保存、証跡を判断します。
まず何から見積もればよいですか？
対象取引先、五つの文書の採否、月間件数・行数、既存ERPとマスタ状態、例外件数を整理してください。RFPには実データを匿名化したサンプルと受入試験条件を付けます。価格だけでなく、取引先を追加する際の費用と運用責任も比較します。
結論：最初の一社で再現可能な接続を作る
製造業EDIの導入価値は、発注書を電子的に送ることだけでは測れません。POの改訂、回答、分納、受領差異、請求まで同じ取引として追え、担当者が例外を解決できる状態が目標です。最初の一社では、品番と拠点の対応表、メッセージ契約、監視・再送手順、FAT/SATの証跡を残してください。それが次の取引先へ広げるための土台になります。
TOMAS TECHでは、タイ工場のERP、購買・販売、物流、取引先接続を含む要件整理をお手伝いしています。まだ製品や通信方式が決まっていない段階でも、現状の文書、相手先要件、PoCの対象を一緒に整理できます。お問い合わせはこちら。
参考情報・一次資料
- GS1 Ireland: Electronic Data Interchange — EDIの定義、発注・回答・出荷・受領・請求の業務メッセージ。
- GS1: EDI Implementation — 識別子、EANCOMとGS1 XMLの選択。
- GS1: EDI Standards — EDI標準の構成。
- GS1: GTIN format in EDI — XMLとEANCOMのGTIN表現の違い。
- GS1 EDI Business Terms — 業務項目の意味の標準化。
- OpenPeppol: Post Award Documentation — 注文・請求等の仕様参照。
- ETDA: e-Tax Invoice standard — タイの電子税務文書の規格情報。
- Thai Revenue Department: e-Tax Invoice & e-Receipt — 制度運用の公式入口。
