アーキテクチャとデータモデルのシナリオの確認
学習の目的
この単元を完了すると、次のことができるようになります。
- 完全 PIM システムの 2 つの大きな懸念について説明する。
- 手動システムの考慮事項を 3 つ挙げる。
- Business Manager へのデータの入力方法を 3 つ挙げる。
- PIM 以外のデータの格納には別のシステムを使用する理由を説明する。
- ハイブリッドシステムの問題を 2 つ挙げる。
はじめに
商品データは、Salesforce B2C Commerce システムへの統合で特に厄介なコンポーネントになる可能性があるものの 1 つで、その内容もマーチャントごとに大きく異なります。マーチャントは通常、完全商品情報システム (PIM)、手動システム、または両者を組み合わせたハイブリッドシステムを使用します。
では、それぞれのシステムを詳しく見ていきましょう。
完全 PIM システム
時として、マーチャントが完全に機能する商品情報管理 (PIM) システムを所有し、そのシステムが元のサイトのアーキテクチャに基づいて計画されていることがあります。PIM システムは通常、一元化されたカタログ内で複数の地域と多言語データをサポートします。こうしたシステムは、メディアを問わない一元的なデータの維持を目的とし、データの収集、管理、調整、出力が重視されます。
B2C Commerce の実装では、商品情報が記録システムとなる PIM に入力されます。その後 B2C Commerce のサイトに送り込まれます。この種のシステムの最大の懸念は、データの一貫性と拡張性です。
データの一貫性
一貫したデータを作成することはこの上なく重要です。一貫性を確保できなければ、販売する特定の商品があるかどうかがマーチャントにわかりません。商品にどのような説明が付けられているのだろうかとマーチャントがあれこれ推測しなくても、商品を検索して見つけられるようにする必要があります。
B2C Commerce のサイトにデータが送られますが、このデータが一貫しているとは限りません。たとえば、「スモールサイズのすべての品目に「S」という属性が設定されているか?」「他の属性が使用されている場合、マーチャントはこのばらつきをどのように管理するのか?」「ソースシステムはクリーンアップされるのか、それともクライアントが B2C Commerce で手動で管理する必要があるのか?」「手動プロセスは拡張可能か?」などを検討します。
拡張性
最も望ましい形は、PIM システムを簡単に拡張できることです。マーチャントのシステムによっては、将来のデータを追加するためのシステムの変更を容易に実装できないことがあります。将来のビジネス要件に対応できるように、記録システムの柔軟性を理解しておく必要があります。ソースシステムが柔軟性に欠ける場合は、特定のデータをシステム外で管理するよう推奨することを検討します。たとえば、PIM システムは (e コマースだけでなく) エンタープライズ全体で使用される傾向にあります。そのため、e コマースのみに使用するフィールドを追加することが難しい場合があります。このような場合には、ベースデータは PIM から取得し、補足データは PIM の外部で管理するとよいでしょう。
PIM と手動のハイブリッドシステム
このシナリオでは、マーチャントが完全に機能する PIM システムを所有しています。この PIM システムはサイトのアーキテクチャで計画されましたが、一定のデータはこのシステム外に存在します。つまり、記録システムが複数存在します。商品データの保存と保守においてはこうしたことがよくあります。
この場合のあなたの最も重要な任務は、マーチャントに外部データを管理する実用的な方法があるかどうかを見極めることです。PIM システムで管理されていないデータは Business Manager に手動で入力する必要がありますが、この作業には大量のリソースを要します。
この処理は数通りの方法で行うことができます。
- Business Manager にデータを手動で入力する。
- PIM 以外のデータは別のシステムに格納する。
- スプレッドシートでデータを管理し、B2C Commerce XML を生成する。
データの手動入力
データを手動で管理する場合は、マーチャントに常に十分な人員がいるか、データが少量または単純であるため手動で管理可能である必要があります。
PIM 以外のデータを別のシステムに格納
レガシーシステムを更新することが難しい場合は、データを格納するスタンドアロンシステムを構築したほうが簡単かもしれません。この場合は、マーチャントが新しいデータをどのように取得し、どのような方法で新しいシステムに入力するかを判断します。マーチャントがデータを手動で入力するつもりの場合は、人員数を考慮する必要があります。何らかのシステムを所有することの利点は、ルールの適用、B2C Commerce XML の生成、ジョブや手動アップロードを使用したシステムへの読み込みなどを実行できることです。
スプレッドシートでデータを管理し、B2C Commerce XML を生成
この方法は、マーチャントがデータをスプレッドシートに入力し、XML を生成するマクロを実行して、その XML を Business Manager に手動でアップロードすることを前提としています。前述のデータソースの疑問はこの場合にも該当します。さらに複雑な点は、システム (この場合はスプレッドシート) でエラーの管理や、XML 形式が適切かどうかの検証が行われないことです。つまり、マーチャントにデータのトラブルシューティングや読み込みのスキルがあること、もしくはこうしたスキルを利用可能であることが求められます。
完全手動システム
このシナリオでは、B2C Commerce にデータをフィードできるシステムがマーチャントにありません。クライアントがすべてのデータを手動で管理する必要があります。データを手動で Business Manager に入力するか、スプレッドシートなどのツールを使用して XML を生成し、Business Manager に読み込む必要があります。この場合の記録システムは、オフラインのファイルか Business Manager です。
次の点を確認する必要があります。
- マーチャントがデータを管理可能である。
- マーチャントにデータを管理するスキルセットがある。
- スプレッドシートを使用して B2C Commerce XML を生成する場合は、「将来そのスプレッドシートのトラブルシューティングや変更を行うスキルセットを備えているのは誰か?」を確認します。この作業には、XML に関する知識 (または知識を習得する能力) と、適切な形式の XML を生成するためにスプレッドシートの式を変更する能力が求められます。
- 属性の選択によってデータの一貫性が確保される。たとえば、属性のデータ型を整数にすれば、使用可能な値にその型が適用されます。手動プロセスにはエラーチェック機能が備わっていないため、こうした制約が役に立ちます。