製品の重量は資材管理システムに記載されています。再生材の割合は配合システムに記載されています。サプライヤーの証明書は、ネットワークドライブ上にPDFファイルとして保存されています。製品パスポートには、これら3つの情報を1つのデータセットにまとめる必要があります。まさにそこに統合プロジェクトの本質があり、2つのシステムを接続することそのものにあるわけではありません。
「シームレスなERP統合」というのは、実際には3か月のプロジェクトが待ち受けているという、ありふれた約束です。契約締結前に、貴社のIT部門が実際にどのようなデータが求められるかを確認できるよう、当ガイドを公開いたします。 本記事では、パスが貴社のシステムからどのようなデータを必要としているか、そのデータが3つの経路を通じて当社に届く仕組み、そしてなぜそれが2週間で完了するのかについて解説します。
ERPが実際に提供すべきもの
DPPを作成するためには、製品ごとに以下の情報が必要です：
-マスターデータ- 品目番号、名称、バリエーション、重量、寸法、画像 -部品表データ - 数量および再生材含有率を含む構成部品 -原産地データ - 生産地、ロット番号、生産日 -環境データ - 単位あたりのCO2eq、水使用量、エネルギー消費量 -サプライヤーデータ - どのサプライヤーがどの構成部品を供給しているか （デュー・ディリジェンスの義務のため）
御社のERPには、理論上はこれらのデータがすべて存在しています。実際には、これらは4～7つのモジュールに分散しています：資材管理、生産、品質管理、サプライヤーマスター、場合によっては環境データ用の独立したモジュール、あるいは配合データや部品表専用のシステムなどです。
統合に関する問いは、 「御社のERPはDPPにデータを提供していますか？」というものではありません。「5つのサブシステムから得たデータを、どのようにして一貫性のあるデータセットにまとめ上げるか？」というものです。
3つの実績ある方法
方法1：ERPからデータを取得する
最新のERP（SAP S/4HANA Cloud、Dynamics 365、Odoo）ではうまく機能します。DPPプロバイダーは、ERPのインターフェース（技術的にはODataまたはREST）を介してデータを取得します。取得されるのは変更されたデータのみであり、スケジュールに従って、あるいはイベントによってトリガーされます。
メリット：貴社側での開発負担が少なく、貴社は読み取りアクセス権限を提供するだけで、プロバイダー側が変換処理を構築します。
デメリット：追加のインターフェース層がない旧式のSAP ECC環境では機能しません。また、誰がどのデータを読み取れるかについて、明確なルールを設定する必要があります。
方法2：変更内容の転送
御社のERPが変更のたびにイベントとして通知し（SAP Event Mesh、Apache Kafka、またはRabbitMQを介して）、DPPプロバイダーがそれを受け取ります。
メリット：ほぼリアルタイムで処理でき、システムの規模拡大にも対応可能です。また、各システムが互いに依存しません。
デメリット：設定が複雑で、すべてのIT部門が備えているわけではないインフラストラクチャが必要です。小規模な企業にとっては、大抵の場合、過剰な仕様となります。
方法3：既存の統合レイヤーを活用する
ERPと外部システムの間に、すでに ### 統合レイヤー（Mulesoft、Boomi、Informatica、Azure Data Factory）が構築されています。このレイヤーが「契約」の役割を果たします。DPPプロバイダーはこのレイヤーと通信し、ERPとは直接通信することはありません。
メリット：既存の投資を活用でき、ルールは安定しており、第三者がERPに直接アクセスすることはありません。
デメリット：統合レイヤーにかかるコストも増加します。
具体的なプロジェクトにおいて、当社が他社と異なるアプローチ
多くのベンダーは、お客様のERPに直接接続しようとします。 弊社では原則として、 中間ステップを設けています。弊社のインターフェースは、お客様がご指定のツールでデータを格納できる中立的なデータ形式（JSONスキーマ）を受け入れます。つまり、
- お客様のチームが慣れ親しんだツールを使用して、ご自身でデータの前処理を行うことができます
- 弊社を他のベンダーに置き換えることも可能です。中立的なフォーマットは移植性があります
- お客様の全データは、CSV、XLSX、JSON-LD、SQL形式、およびREST-APIを通じて、いつでも取り出すことができます
- アップロード前にデータを検証するインポートバリデータを提供いたします
完全なフォーマットおよびすべてのクエリは、OpenAPIに準拠したインターフェース仕様として、/apidocsで公開されています。契約締結前に、貴社のIT部門がインターフェースを確認することができます。これには、サンプルリクエスト、エラー応答、認証の詳細も含まれています。
このアプローチによる実際のスケジュールは以下の通りです：
-1日目～2日目：マッピングワークショップ。ERPのどのフィールドがDPPのどのフィールドに対応するか決定します。 -3日目～5日目：ERPからの最初のJSONエクスポートを行い、当社のバリデータによる検証を行います。 -6日目～8日目：エラー修正（欠落しているフィールド、不整合なコードなど）。 -9日目～10日目：最初のDPPが稼働開始。
2週間で完了し、3ヶ月もかかりません。鍵となるのはマッピングワークショップです。そこでデータ品質が決定されます。
失敗の原因：最もよくある落とし穴
複数のシステムに分散した製品マスターデータ：SAPには品番、PIMには画像とマーケティングテキスト、PLMには部品表があります。 どのシステムも一貫した全体像を把握できていません。解決策：プロジェクト開始前に、どのシステムがどのフィールドについて主となるかを定義してください。
PDF形式の認証書：サプライヤーがGOTS、OEKO-TEX、またはREACHの認証書をPDFスキャンとして提供します。これは構造化されたデータソースではありません。 解決策：認証機関は、インターフェースを介した照会サービスをますます提供しています（OEKO-TEXが先行しており、GOTSは遅れをとっています）。あるいは、手動で登録する際、有効期限を明記することで、DPPに期限切れの認証書が表示されないようにします。
配合の機密性：特に化粧品、食品、医薬品において、完全な配合は営業秘密となります。 DPPでこれを公開すべきでしょうか？ 解決策：ESPRの3段階モデルです。製品カテゴリーは公開され、当局のみが完全な配合を見ることができます。障害となることはほとんどありませんが、早期に明確にする必要があります。
サプライヤーベースのCO2データ：サプライヤーは、ロットごとではなく、ポートフォリオ全体の平均値を提示しています。解決策：当面はこれを容認し、長期的にはサプライヤー契約を調整します。ESPRでは、基準日以降の製品ごとの値を要求していますが、現在の実務は妥協案となっています。
現地語版：御社のERPには、ドイツ語と英語の製品名称しか含まれていません。EU 27カ国に対応するには、それ以上の言語が必要です。解決策：用語データベースを活用した機械翻訳です。これについては別途記事をご用意しております。
プロジェクト開始前に確認すべき質問
3社のベンダーにRFPを送付する前に、社内で以下の質問に答えておいてください：
- DPPの対象となる製品／品目番号はいくつですか？（10、10,000、100万？）
- 現在、DPPに関連するデータはどのシステムに保存されていますか？
- 各システムはどの部門が管理していますか？
- 活用すべき統合レイヤーはありますか？
- ERPを介して、すでに稼働しているインターフェースはありますか？
これらの回答によって、3つのアプローチのうちどれが貴社に適しているかが決まります。また、プロジェクトの期間が2週間になるか、6ヶ月になるかも、これらによって決まります。
この記事に関するご質問
RESTインターフェースだけで十分でしょうか、それともミドルウェアが必要でしょうか？
インターフェースで十分です。3つのパターンは、変換が行われる場所が異なるだけで、受け取るデータの内容に違いはありません。当社のインターフェースは、どのようなツールで生成されたものであっても、中立的なJSONスキーマを受け入れます。 最新のERPからのプル、イベントストリーム、既存の統合レイヤーは、すべて同じエンドポイントに集約されます。ミドルウェアは、すでに運用している場合や、第三者との契約上それを維持する必要がある場合にのみ、導入する価値があります。現在ミドルウェアが存在しない場合は、プロダクトパス用に新たに購入する必要はありません。
マッピング・ワークショップではどのようなことが決定されるのでしょうか？
どのERPフィールドがどのパスフィールドになるか、また、複数のシステムが同じ値を保持している場合、どのシステムが主データソースとなるか。このワークショップは1日目と2日目に開催され、データ品質についてその場で決定し、後のコーディング段階で決定することにならないため、プロジェクト全体の成否を分ける重要なポイントとなります。 プロジェクトの責任者だけでなく、システムを維持管理する担当者もぜひご参加ください。マスターデータ、生産、品質管理、購買の各部門が、一つの部署に集まっていることはめったにありません。その後の作業、つまりデータのエクスポート、検証、エラー修正などは、すべて実務的な作業となります。
当社の証明書はPDFスキャン版しかありません。これについてはどうすればよいでしょうか？
スキャンデータは構造化されたデータソースではないため、パスには使用できません。有効な方法は2つあります。まず、認証事業者がAPIによる照会をますます提供しています。APIが利用できない場合は、手動で値を入力してください。ただし、有効期限を必ず記載し、公開されたパスに有効期限が切れた証明書が残らないようにしてください。 手動による作業は、単発のタスクではなく、定期的な業務として計画してください。
署名する前に、当社のIT部門がインターフェースを確認していただけますか？
はい。完全なスキーマとすべてのエンドポイントは、/apidocs に OpenAPI 仕様として公開されており、サンプルリクエスト、エラーレスポンス、認証の詳細も記載されています。 これらはすべて営業交渉の対象外ですので、契約が締結される前に、お客様の統合チームが作業量を把握することができます。この段階でプロバイダーがインターフェースを公開しない場合も、それは一つの判断材料となります。
プロバイダーを変更した場合、私たちのデータはどうなるのでしょうか？
これに対応しています。このインターフェースは、独自形式ではなく中立的なJSONスキーマを受け付け、お客様の全データはCSV、XLSX、JSON-LD、SQLの形式、あるいはREST APIを通じて出力されます。 これは意図的な仕様です。入力するフォーマットは移植性が高いため、変更の際はエクスポートするだけで済み、一から作り直す必要はありません。マッピングワークショップの前に、各プロバイダーに同じ質問を投げかけてください。そうすれば、ワークショップ終了後には、お客様のフィールド名がそのプロバイダーのモデルに反映されることになります。
接続には実際どれくらい時間がかかるのでしょうか？
当社が支援しているプロジェクトでは、2週間のうち、2日間をマッピングに、3日間を当社のバリデータによる最初のエクスポートまで、3日間をエラー修正に、そして2日間を最初のパス公開まで充てています。 手間がかかるのは決してコードそのものではなく、バリデータが検出する問題――欠落しているフィールド、不統一なコーディング、誰も責任を負おうとしない値など――です。これらの期間を短縮するのではなく、しっかりと計画に組み込んでください。この工程を省略したプロジェクトでは、その不備もそのまま公開されてしまいます。
すべての商品を一度に連携させる必要がありますか？
いいえ。まずはパスが必要な製品から始め、ソースシステムを用意してください。中立なスキーマは、部分的なカタログでも完全なカタログでも同様に処理でき、インポートは繰り返し実行可能です。したがって、その後の実行で在庫情報が更新されます。 これにより、マッピングワークショップの規模も2日間で完了できる程度に抑えられます。その後の拡張はマッピング作業であり、新たなプロジェクトではありません。
