「シームレスなERP統合」というのは、実際には3か月のプロジェクトが待ち受けているという、お決まりの謳い文句です。契約締結前に、貴社のIT部門が実際にどのようなデータが照会されるかを確認できるよう、当社のAPIプレイブックを公開します。統合プロジェクトに着手する前に知っておくべきことを以下にご紹介します。
ERPが実際に提供すべきもの
DPPを構築するには、製品ごとに以下の情報が必要です：
-マスターデータ- 品番、名称、バリエーション、重量、寸法、画像 -部品表データ- 数量および再生材含有率を含む構成部品 -原産地データ- 生産地、ロット番号、生産日 -環境データ- 単位あたりのCO2eq、水使用量、エネルギー消費量 -サプライヤーデータ- どのサプライヤーがどのコンポーネントを供給しているか（デューデリジェンス用）
理論上、これらのデータはすべて貴社のERPに存在しています。 実際には、これらは4～7つのモジュールに分散しています：資材管理（MM）、生産（PP）、品質管理（QM）、サプライヤー管理（LFA1）、場合によっては環境データ用の独立したEHSモジュール、あるいは配合データ用のPLMシステムなどです。
統合に関する問題は、「御社のERPはDPPにデータを提供していますか？」というものではありません。問題は、「5つのサブシステムから得たデータを、どのようにして一貫性のあるデータセットにまとめるか？」ということです。
3つの実績ある統合パターン
パターン1：OData / REST-Pull
最新のERP（SAP S/4HANA Cloud、Dynamics 365、Odoo）で効果的に機能します。DPPプロバイダーがODataまたはRESTを介してデータを取得します。 増分型、スケジュール型、またはイベント駆動型。
メリット：貴社側での開発負担が少なく、読み取り用認証情報を提供すれば、プロバイダーがデータ変換を構築します。
デメリット：追加のAPIレイヤーがない旧式のSAP ECC環境では機能しません。データアクセスリクエストに対するガバナンスが必要です。
パターン2：イベントベースの統合
SAP Event Mesh、Apache Kafka、RabbitMQ。貴社のERPが変更イベントを発行し、DPPプロバイダーがそれを消費します。
メリット：ほぼリアルタイム、洗練されたスケーラビリティ、疎結合。
デメリット：設定が難しく、すべてのIT部門が備えているわけではないインフラストラクチャが必要です。小規模な企業にとっては、大抵の場合、過剰な仕様となります。
パターン3：ミドルウェア／ETL
ERPと外部システムの間に、統合レイヤー（Mulesoft、Boomi、Informatica、Azure Data Factory）を配置します。 このミドルウェアが「契約」の役割を果たします。DPPプロバイダーはERPと直接通信することはなく、常にミドルウェアを介して通信します。
メリット：既存の投資を活用できる、ガバナンスが安定している、第三者がERPに直接アクセスできない。
デメリット：ミドルウェアのコストもスケールします。
具体的なプロジェクトにおいて、当社が他社と異なるアプローチ
多くのベンダーは、お客様のERPに直接接続しようとします。当社は原則として 中間ステップを設けています。当社のAPIは中立的なJSONスキーマを受け入れ、お客様は任意のツールを使用してそのスキーマにデータを入力できます。つまり：
- 御社のチームが慣れ親しんだツールを使用して、データの前処理を自社で行うことができます
- 当社を他のベンダーに置き換えることも可能です。中立的なフォーマットは移植性があります
- データ全体をいつでもCSV、XLSX、JSON-LD、SQL形式、およびREST-API経由で取得できます
- アップロード前にデータを検証するインポートバリデータを提供します
完全なスキーマおよびすべてのエンドポイントは、/apidocsにてOpenAPI仕様として公開されています。 契約締結前に、貴社の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スキャンとして提出してくる。 これは構造化されたデータソースとは言えません。解決策：認証機関によるAPIクエリの提供が増えています（OEKO-TEXが先行し、GOTSは遅れをとっています）。あるいは、手動で登録する際、有効期限を明記することで、DPPに期限切れの認証書が表示されないようにします。
配合の機密性：特に化粧品、食品、医薬品分野において、完全な配合は企業秘密である。 DPPでこれを公開すべきか？解決策：ESPRの3段階モデル。製品カテゴリーは公開され、当局のみが完全な配合情報を閲覧できる。障害となることはほとんどないが、早期に明確化しておく必要がある。
サプライヤーベースのCO2データ：サプライヤーは、ロットごとではなく、ポートフォリオ全体の平均値を提示します。解決策：当面はこれを容認し、長期的にはサプライヤー契約を改定します。ESPRでは基準日以降の製品ごとの値を要求していますが、現在の実務では妥協案が採用されています。
現地語版：御社のERPには、製品名称がドイツ語と英語のみで登録されています。EU 27カ国に対応するには、それ以上の言語が必要です。解決策：用語データベースを活用した機械翻訳。これについては別途記事を掲載しています。
プロジェクト開始前に確認すべき質問
3社のベンダーにRFPを送る前に、社内で以下の質問に答えておいてください：
- DPPの対象となる製品／品目番号はいくつですか？（10、10,000、100万？）
- 現在、DPPに関連するデータを保持しているシステムはどれですか？
- 各システムはどの部門が管理していますか？
- 活用すべきミドルウェアへの投資はありますか？
- ERP上にすでに稼働しているAPIレイヤーはありますか？
これらの回答によって、3つのモデルのうちどれが貴社に適しているかが決まります。また、プロジェクトの期間が2週間になるか、6ヶ月になるかも、これらの回答によって決まります。