INTERCOMPANY DATA CONTRACT
物流情報標準・EPCIS・SSCC設計：企業間トレーサビリティを実装する
項目マッピングを越えて、Shipment、Consignment、荷姿、場所、イベント、時刻、責任、変更管理を企業間で共有する実装方法を整理します。
EXECUTIVE ANSWER
最初に押さえる結論
標準を採用することと、相手企業と同じ意味で運用できることは別です。標準語彙を自社の正本、業務イベント、品質SLA、適合性試験へ落とす必要があります。
実装では、適用条件、設計判断、成果物、KPI、ガードレールをセットで扱います。個別製品やアルゴリズムの導入は、その判断を実現する選択肢として評価します。
DECISION SCOPE
一つの論点を四つの対象へ分解する
IMPLEMENTATION DETAIL
設計判断を実務へ落とす
制度・標準・製品名称を並べるだけでなく、現場で何を観測し、誰が何を決め、どの証跡で受け入れるかまで具体化します。
取引と運送契約を分ける
Shipmentは荷送人から荷受人へ送る物品集合、Consignmentは運送契約の対象となる物品集合として扱います。一つのShipmentが複数Consignmentに分かれ、複数Shipmentが混載される場合を表現できなければ、積替、共同輸配送、運賃、PODを正しく追跡できません。現行システムの一項目へ無理に統合しないことが重要です。
荷姿の集約関係をイベントで持つ
Item、Case、Pallet、Containerは固定的な階層ではなく、梱包、積替、再梱包、分割で関係が変わります。SSCC等の識別子とAggregation/Disaggregationイベントを用いて、その時点で何がどの物流単位に含まれていたかを再現します。ラベル再発行やIDの再利用は禁止条件と例外手順を明確にします。
標準をData contractへ落とす
標準の要素名だけ合わせても、必須性、コード、時刻、粒度、順序、欠損、再送、変更通知が違えば連携は壊れます。各企業の正本と標準語彙を対応させ、適用しない項目と拡張理由をADRへ残します。正常系に加え、欠損、重複、逆順、取消、再送、相手停止を適合性試験へ含めます。
DESIGN DECISIONS
実装前に合意する判断
各判断には選択肢、評価軸、決定者、根拠、残余リスク、見直し条件を付けます。
対象モデル
取引、運送契約、物品、荷姿、輸送機器、場所、区間を分離
識別
Item、Case、Pallet、Container、Vehicleの一意IDと再梱包を定義
イベント
Shipping、Receiving、Aggregation、Sensor等を業務責任と対応
契約
必須、品質、SLA、権限、再利用、変更、障害、終了を合意
適合性
正常・欠損・重複・逆順・取消・再送を企業間で試験
IMPLEMENTATION SEQUENCE
導入を六つの品質ゲートで進める
前段の仮説が崩れた場合は、後続の要求・テスト・移行・KPIを影響分析して更新します。
- 一つの企業間ユースケースを選択
- 現行文書・項目・イベントを棚卸し
- Canonical modelと識別規則を定義
- 標準への対応と差分ADRを記録
- Data contract/API・EDI仕様を作成
- 適合性試験と変更運営を開始
ENTERPRISE ARCHITECTURE
業務・データ・アプリ・技術の対応
一対一の製品対応表ではなく、同じ経営判断が各層で何を意味し、誰が何を受け入れるかを示します。
Business
責任、例外、判断、SLAをBPMNへ落とし、ShipmentとConsignmentの分離を運用する
- OWNER
- 業務責任者
- ACCEPTANCE
- 顧客影響と現場受入を確認
Data
識別子、時刻、状態、品質、証跡を定義し、SSCC・GLNと荷姿集約を追跡する
- OWNER
- 物流データオーナー
- ACCEPTANCE
- 意味・正本・品質SLOを確認
Application
OMS/WMS/TMS/YMS/分析・連携の機能配置を決め、EPCISのWhat/Where/When/Whyを実装する
- OWNER
- アプリ責任者
- ACCEPTANCE
- 重複・例外・共存を試験
Technology
端末、IoT、Network、Cloud、IAM、監視、DRでData contractと適合性試験を支える
- OWNER
- 技術責任者
- ACCEPTANCE
- ピーク・圏外・障害復旧を試験
DOMAIN VOCABULARY
用語を自社の設計契約へ変換する
Shipment
売買・納品の観点で、ある荷送人から荷受人へ送る物品集合。複数Consignmentへ分割される場合があります。
Consignment
一つの運送契約の対象となる物品集合。複数モード・区間でも契約単位として識別します。
SSCC
Serial Shipping Container Code。Pallet等のLogistic unitを一意に識別し、内容物との集約関係をイベントで管理します。
GLN
法人・機能・物理/デジタル場所のGS1識別子。荷主、倉庫、バース、納品先等の責任境界を表せます。
ASN / Despatch advice
出荷前に品目・数量・荷姿・予定等を通知するメッセージ。実際のShippingイベントとは区別します。
EPCIS / CBV
What/Where/When/Whyの可視化イベントと共通語彙。Shipping、Receiving、Aggregation、Sensor等を共有します。
REQUIRED EVIDENCE
判断と受入に残す証跡
Canonical物流概念モデル
証跡 01：所有者、版、承認、関連する要求・テスト・KPIを識別子で追跡します。
識別子・荷姿階層ポリシー
証跡 02：所有者、版、承認、関連する要求・テスト・KPIを識別子で追跡します。
EPCISイベント対応
証跡 03：所有者、版、承認、関連する要求・テスト・KPIを識別子で追跡します。
Business Glossary
証跡 04：所有者、版、承認、関連する要求・テスト・KPIを識別子で追跡します。
企業間Data contract
証跡 05：所有者、版、承認、関連する要求・テスト・KPIを識別子で追跡します。
適合性・変更管理記録
証跡 06：所有者、版、承認、関連する要求・テスト・KPIを識別子で追跡します。
MEASUREMENT
成果を判断する測定システム
各KPIに式、粒度、時間窓、データ源、基準値、責任者、対立指標を置きます。
- 識別子完全性
- イベント順序適合率
- 意味変換例外率
- 再入力率
- 変更通知遵守率
FAILURE PATTERNS
実装時に避けるべき失敗
標準項目名だけをコピー
製品コードを企業間IDとして流用
再梱包・分割・混載を表現できない
標準改訂・相手変更の運営がない
PRIMARY SOURCES
参照する一次資料
制度・標準は更新されるため、適用時に最新版と個別条件を再確認します。
株式会社DXwheelの代表取締役。コンサルティング会社勤務時代、総合商社において中東地域の貿易交渉や、大手エンターテインメント企業のビジネスモデル変革に携わる。その後、株式会社DXwheel設立。マーケティングの戦略立案とシステム開発の両方面で、主に大企業を対象にしたコンサルティング業務を行い、デジタルトランスフォーメーションの分野に貢献。