製品運用管理（製品管理システム設計（III）：製品管理）

製品管理システム設計（パート3）：製品管理

前回の 2 つの記事では、それぞれ製品管理システムにおけるカテゴリ設計と属性ライブラリの構築について紹介しました。彼らは製品管理において補助的な役割しか果たしておらず、製品管理の真の核心は製品にあります。製品がなければ電子商取引は存在しません。

商品管理システムは、電子商取引製品における最も基本的かつ中核的なシステムです。電子商取引製品全体を支えるコアです。基本的にすべてのシステムは製品データと切り離せないものであり、製品は電子商取引プラットフォーム全体を通じて実行されます。商品の仕入れから、入庫、商品の棚入れ、フロントでの陳列、発注、物流配送、受領、アフターサービスなど、すべてのプロセスは商品と切り離せません。バックエンドの商品システムは、一般的にカテゴリー管理、属性ライブラリ、ブランド管理、商品管理（商品の公開、商品の編集、商品の棚への出し入れ、レビュー、価格と在庫の設定、運賃テンプレートの設定など）に分かれています。この記事では主にバックエンドの製品管理について説明します。

電子商取引製品について知っておくべき用語が 2 つあります。SPU と SKU です。前回の2つの記事でも触れましたが、具体的な意味については詳しく説明されていなかったので、ここで詳しく説明する必要があります。

SPU（Standard Product Unit）：標準商品単位は、商品情報を集約する最小単位です。これは、「製品」の特性を説明する、再利用可能で簡単に検索できる標準化された情報のコレクションです。簡単に言えば、同じ属性値と特性を持つ製品を SPU と呼ぶことができます。前の記事で述べたように、カテゴリ システムの主要な属性によって SPU を決定できますが、SPU では特定の商品ではなく、特定の商品カテゴリを識別できます。たとえば、iPhone + iPhone X (ブランド + モデル) で SPU を判別できます。

SKU (Standard Keeping Unit): 在庫の入出庫を測定するための基本単位である在庫単位。 SKU は在庫の最小単位（個、箱、パレットなど）とも言えます。各 SKU には異なるコードがあります。前の記事で述べたように、カテゴリ システムの販売属性によって SKU を決定でき、これによって特定の製品を識別できます。たとえば、Apple の電話 + iPhone X + 12G + 黒で、SKU を決定できます。簡単に言えば、ユーザーが商品詳細ページで特定の商品仕様を選択すると、価格と在庫が表示されます。

SPU と SKU の関係は、通常、1 対多または 1 対 1 の関係です。 SPU には複数の SKU が含まれます。 SKU は SPU のサブセットであり、商品は SKU の具体的なオブジェクトです。たとえば、「Semir + 作業服の男性用シューズ」は SPU を表すことができます。色とサイズを追加すると、Semir + 作業服のメンズシューズ + 黄色 + サイズ 41 で SKU を表すことができます。

特殊なケースでは、1 つの SKU が複数の SPU に対応することもありますが、このような状況は比較的まれです。たとえば、店舗では同じ靴が 2 つの名前 (Semar ワークウェア メンズ シューズと Semir レトロ カジュアル メンズ シューズ) を持つ 2 つの製品としてリストされています。このとき、フロントには 2 つの商品が表示されますが、バックエンド システムでは対応する商品は 1 つの商品です (1 つの SKU コードは 2 つの SPU コードに対応します)。

理解を容易にするために、著者は SPU、SKU、および製品の関係を簡単に描いています。

上記の状況に加えて、販売者の実際のビジネス シナリオに応じて、製品システムには製品セットまたは組み合わせ製品と呼ばれる別の種類の製品が存在します。このビジネスシナリオは比較的複雑です。

例えば、スポーツウェアセット（2点セット、3点セット、4点セットなど）は、フロントエンドユーザーが注文した時点での商品であり、バックエンドの処理ロジックは、n個のSKUを仮想SKUに関連付け、倉庫に送られた後に仮想SKUを分解し、実際のSKUに応じて在庫を差し引き、出荷時にn個のSKUに該当する商品を1つのパッケージに梱包してユーザーに送ります。

これまでの一連の準備作業はすべて、カテゴリと属性ライブラリの設計、およびこの記事で説明した SPU と SKU を含む製品管理に関するものです。これらすべてを理解して初めて、製品管理システムがどのように機能するかを理解し、eコマース プラットフォームのコア システムである製品管理を真に理解できるようになります。

簡単に言えば、商品管理とは、商品の公開（追加）、棚への商品の追加と削除、商品の変更、商品の照会、配送テンプレートの設定など、商品の保守と管理を行うことです。次の図は、商品管理インターフェースです。

製品を作成または公開する前に、まず製品を添付するカテゴリを選択する必要があります。製品は、カテゴリに添付された属性を呼び出し、対応する属性テンプレートを生成し、キー属性と販売属性 (仕様属性) を通じて SPU と SKU を関連付けます。同じ SPU は、フロントエンドに表示されるときに同じ製品詳細を共有できますが、販売属性 (仕様属性) を通じて特定の SKU にマッピングする必要があります。

JD.com は SKU ディメンションに基づいて管理されますが、Taobao と Tmall は SPU ディメンションに基づいて管理されます。 （JD.comが商品仕様を変更すると、タイトルと商品詳細が変更されますが、TaobaoとTmallが商品仕様を変更すると、タイトルと商品詳細は変更されません）

新しくリリースされる製品情報の正確性を確保し、違法な製品がリリースされるリスクを軽減するために、プラットフォーム運営者は情報を審査し、プラットフォーム上でリリースされる製品の品質を確保する必要があります。商品は審査に合格した後にのみ、通常通り棚に並べたり、棚から取り除いたりすることができます。一般的な監査プロセスは次のとおりです（参考のみ）。

商品を公開（追加）する場合、商品情報には通常、商品の基本情報、商品属性、商品のグラフィック説明、支払い情報、物流情報、アフターサービスなどが含まれます。

• 製品の基本情報

製品の基本情報とは、製品の基本的な説明です。一般的には、ユーザーが商品を閲覧する際に最初に目にする情報を指します。この部分はプラットフォームの事業内容によって多少異なりますが、一般的には商品カテゴリー、商品タイトル（商品名）、ブランド情報、商品コード（69コードとも呼ばれます）、商品属性、広告スローガンなどの情報が主に含まれています。

• 製品属性

製品属性には通常、主要属性、販売属性、製品属性、共通属性が含まれます。会社の実際の業務に応じて、特殊属性、バインディング属性など、他の属性を分類することもできます。

属性ライブラリの構築に関する記事では、製品の属性、属性ライブラリをゼロから構築する方法、属性が製品カテゴリとどのように関連しているかについて詳しく説明しています。興味のある学生は、「製品管理システム設計（II）：属性ライブラリ構築」を読んでみてください。

• 製品説明

製品の写真と製品の説明が含まれます。製品画像には通常、メイン製品画像、製品カルーセル画像、製品アクティビティ画像が含まれます。商品説明は写真に添付されるテキストによる説明であり、記入してもしなくてもかまいません。

• 在庫設定

在庫設定は、商品の販売属性（仕様属性）、つまり商品のSKUに応じて、対応する価格と在庫を設定するものです。仕様が異なる製品は、価格と在庫も異なります。商品の在庫販売数が0になると、自動的に棚から削除されます。通常、SKU 在庫は WMS システム内の在庫、つまり実在庫、または手動で設定されたアクティブ在庫と同期されます。商品の在庫数量は在庫システムやWMSシステムとデータ交換し、フロントエンドに表示されます。インベントリシステムに関しては、後ほど更新された記事で具体的に共有します。

• お支払い情報

一般的には、ユーザーが商品に入札する際に使用する支払い方法と、商品に入札する際に使用する在庫数え方法を指します。

支払い方法には、固定価格（通常の取引モード）、事前販売モード、代金引換などがあります。固定価格とは、注文が提出されたときに一度に全額支払われることを意味します。先行販売モデルとは、最初に前金の一部を支払い、製品の販売が開始されたときに残額を支払うことを意味します。代金引換は、商品の受け取り確認後に利用者が代金を支払う仕組みで、比較的わかりやすいです。

在庫数えは、入札後の在庫減と支払い後の在庫減に分かれます。在庫を減らすために入札する場合、ユーザーが悪意を持って購入せずに注文してしまうリスクがあります。在庫を減らすために料金を支払う場合、プラットフォームまたは販売者が過剰販売するリスクがあります。どちらの方法にも長所と短所があります。

次の図は、Taobao の商品ページの支払い情報を示しています。

• 物流情報

主に商品の具体的な状況に基づいて、事前に設定された貨物テンプレートを選択します。要件を満たす貨物テンプレートがない場合は、物流システムにアクセスして設定してから使用することができます。

• アフターサービス

一般的には、商品の販売後にユーザーに対してなされる約束であり、例えば、返品交換の約束（7日間の無理由返品交換など）、偽造品に対する10倍の賠償などです。アフターサービスは商品によって異なります。以下の写真は、Taobaoの商品ページにあるアフターサービスを示しています。

商品管理における商品は、販売中の商品（棚にある商品）と販売予定の商品（棚から外れた商品）に分けられます。商品を公開する際に、自動出品削除ルールや時間指定出品ルールを設定することもできます。

商品は販売用商品と代理販売用商品の2つのモジュールに分かれており、プラットフォーム運営者や販売業者にとって商品の管理が容易になります。 Rishangの運営中、商品が削除される理由は多々あり、システムによる自動削除、販売者による自主削除など、対応する処理方法も異なります。

システムから削除されるシナリオには、一般的に違反、ブランドの有効期限切れ、店舗の移行などが含まれます。対応する一般的な理由には、リスク管理システムによる削除、店舗の移行または閉鎖、カテゴリの変更、プラットフォームの運用などがあります。製品を設計するときは、製品がシステムから削除されるシナリオと理由をできるだけ多くリストアップして、運用担当者が販売者に削除の理由を通知し、修正できるようにします。

商品編集は、商品の公開（新商品の追加）と同じ機能で、すでに公開されている商品の情報を修正するものです。変更後、システムはそれが新しい製品であるかどうかを判断します。新製品の場合は、店頭に並べられた時点で審査プロセスが行われます。

商品の削除とは、販売されなくなった商品を削除することを意味します。棚にある商品は削除できません。

商品管理モジュールに運賃を設定するための入り口があります。物流システムに直接アクセスして貨物テンプレートを設定できます。運賃テンプレートを設定後、商品を公開（追加）する際にそのままご利用いただけます。注文処理では、物流情報に基づいて運賃を計算します。価格設定方法は、一般的に個数計算、重量計算、容積計算に分けられます。図の運賃テンプレートは個数で計算されます。物流システムに関しては、後ほど更新記事で具体的にお伝えします。

商品のステータスは、新規、レビュー保留中、レビュー合格、レビュー不合格、販売中、販売終了、期限切れ、有効なレビュー保留中、の 8 つがあります。製品のプロセス全体のステータスフローチャートをまとめました（参考のみ）。

プラットフォーム運営者や加盟店が商品をリリース（新規追加）する際に、該当する商品がない場合には審査プロセスを経る必要があります。該当商品がある場合はレビューは不要です。 （新）製品が正常にリリースされた後にのみ、製品を棚に直接追加したり、棚から削除したりすることができます。

製品管理システムは、電子商取引プラットフォームの基盤であり、他のシステムが依存する基本的なデータ システムです。電子商取引プラットフォームを構築する初期段階では、システムの各モジュールを計画し、結合を減らすために各モジュールの拡張性を考慮する必要があります。後期段階での製品拡張中にボトルネックを回避します。後からシステム計画の調整を行うと、莫大なコストが発生します。したがって、強固な基盤を築くことは、電子商取引プラットフォームのその後のビジネス規模の発展において重要な役割を果たします。

製品管理システム設計（I）：カテゴリー設計はどのように行うのか？

製品管理システム設計（II）：属性ライブラリの構築

著者: ロッキー;公式アカウント: Chaoyue Products

この記事はもともと @Rocky によって Everyone is a Product Manager に掲載されました。著者の許可なく複製することは禁止します。

タイトル画像は、CC0 プロトコルに基づいて Unsplash から取得したものです。