グローバル社内ECの運用設計：在庫、権限、ローカライズ、海外フルフィルメント
グローバル社内ECや社員向けブランドストアは、ロゴ入り商品を並べるECサイトではありません。複数の国・部門・利用者を対象にするなら、誰が何を見られるのか、費用を誰が負担するのか、在庫をどこに置くのか、注文をいつ承認するのか、製造や配送が失敗したときに誰が復旧するのかを決める運用基盤です。
利用者が見るストア画面は最も目立つ層にすぎません。その裏側では、商品マスタ、ブランド審査、需要計画、在庫、地域調達、予算、ID・権限、受発注、海外配送、返品、問い合わせ、個人情報、請求・精算を一つの運用としてつなぐ必要があります。
サイト公開時の見栄えが良くても、数か月後に欠品、サイズ違い、古いロゴ、配送遅延、費用部門の不明、問い合わせのたらい回しが増えることがあります。多くの場合、問題はEC機能ではなく、公開前に運用責任を設計していないことです。
まず「社内EC」と福利厚生モールを区別する
日本では、社内EC、社員向けストア、社販EC、グループ内EC、クローズドEC、福利厚生サイトなど複数の呼び方があります。しかし、目的は同じではありません。
福利厚生モールは割引や外部サービスを集約することが中心です。一方、企業のブランドストアは、会社が承認したウェア、イベント用品、オンボーディングキット、表彰品、営業・パートナー向け資材などを管理します。利用者は社員だけでなく、管理職、営業担当者、販売パートナー、顧客、卒業生、会員、一般消費者の場合もあります。
費用負担も一つではありません。
- 会社が全額負担する入社用品や表彰品
- 役割やイベントに応じて付与するポイント・利用枠
- 会社補助と本人負担を組み合わせる購入
- 社員やコミュニティによる自己負担購入
- 部門・プロジェクト・原価部門に計上する管理職発注
- 期限、数量、対象者を限定したキャンペーン
そのため、検討の出発点は「ストアを作れるか」ではなく、「一件の注文が完了するまで、どの責任をどのシステムと組織が持つか」です。
プラットフォーム選定より先に運用憲章を作る
最初に一枚の運用憲章を作り、次の五点を明確にします。
1. 主目的
従業員エンゲージメント、ブランド統一、営業支援、イベント運営、チャネル施策、一般販売では、商品・予算・承認・サポートの設計が異なります。初期導入では主目的を一つ決めます。
2. 対象者
個人名簿ではなく、雇用形態、所属、役割、国、パートナーランク、キャンペーン資格、公開・非公開といったポリシーグループで定義します。
3. 費用負担
対象者と商品区分ごとに、予算元、原価部門、補助率、承認基準、有効期限、送料・税・関税の負担を決めます。
4. サービス約束
製造日数、配送目安、問い合わせ時間、欠品時の代替、返品・交換・再送を地域別に定義します。全世界に同じ納期を約束しないことが重要です。
5. 運用責任者
ブランド、人事、総務、調達、経理、IT、各地域が参加しても、エンドツーエンドの結果に責任を持つ一人または一部門を置きます。
ポリシーと収益構造に応じてストアを分ける
一社が複数のストア体験を持つことは珍しくありません。ただし、商品・ID・在庫・発注・フルフィルメント基盤は共通化できます。
| モデル | 主な用途 | アクセス | 主な運用リスク |
| 社員向け非公開ストア | カルチャー、表彰、日常グッズ | SSO、社用メール、招待 | 異動・退職後の権限と利用枠 |
| 管理職発注ポータル | 入社、イベント、営業活動 | 役割ベース | 大量発注と原価部門の統制 |
| 期間限定ストア | 周年、展示会、新製品 | 専用URL、コード、期限付き招待 | 需要急増と終了後の在庫 |
| パートナーストア | 販売支援、共同マーケティング | 企業、ランク、施策資格 | 利用資格と共同ブランド審査 |
| 一般公開ストア | ファン、卒業生、会員、寄付 | 公開 | 消費者対応、返品、税務 |
トップページの表現だけが違う場合は、ストアを複製するよりセグメント表示の方が管理しやすくなります。対象、価格、資金、商品可視性、フルフィルメント責任が実質的に異なる場合に分離します。
商品マスタをグローバル運用の中心に置く
各地域が自由に商品を追加すると、承認済みデザイン、原価、サプライヤー、在庫、代替品が分からなくなります。商品構成は四層に分けると管理しやすくなります。
- グローバルコア： ブランドを代表し、補充・生産条件が明確な少数商品
- 地域商品： 気候、サイズ、文化、法規、供給、配送に合わせた商品
- 用途モジュール： 入社、イベント、営業キット、制服、表彰、役員ギフト
- 期間限定商品： 公開日、上限、終了日が決まったキャンペーン商品
各SKUには、承認済みアートワーク、加工方法、サプライヤー、生産地、販売地域、サイズ・仕様、原価、価格、納期、最低数量、在庫方式、代替品、終了日を持たせます。
すべての国に同じ商品を出すことがグローバル統一ではありません。ブランド品質と体験を統一し、その地域で調達・配送・サポートできる商品を選ぶことが重要です。
在庫・受注生産・ハイブリッドをSKU別に選ぶ
在庫型
需要が安定し、短納期が必要で、セット組みや加工が少量では非効率な商品に向きます。速度と品質は安定しますが、資金、保管、陳腐化、アパレルのサイズ構成リスクがあります。
受注生産型
需要が不確実で、商品数が多く、個人名などのカスタマイズが必要な場合に向きます。先行在庫は減りますが、製造時間、単価、加工方法の制約を管理する必要があります。
ハイブリッド型
多くのグローバル施策では、定番・短納期商品だけを地域在庫にし、サイズ数が多い商品、地域版、試験商品を受注生産にする方法が現実的です。
Oracle NetSuiteの多拠点在庫ガイダンスが拠点別のリードタイムと安全在庫を扱うのは、需要と補充条件が場所ごとに違うためです。英国政府の多チャネル在庫ガイドも、需要、リードタイム、安全在庫から発注点を設計する考え方を示しています。
全拠点の合計在庫で地域欠品を隠してはいけません。他国に在庫があっても、移送費、納期、関税を含めると利用できない場合があります。
在庫アラートを担当者付きの業務に変える
在庫商品はSKU・バリエーション・拠点単位で、利用可能、引当済み、破損、隔離、需要、変動、調達・移送リードタイム、安全在庫、発注点、入荷予定、在庫年齢、サイズ別消化、キャンペーン予測を追跡します。
補充と拠点間移送は別の判断です。移送する場合も、移送コスト、納期、移送元の将来需要、通関を比較します。
「在庫不足」という通知だけでは解決になりません。補充、移送、代替、表示停止、販売制限、廃番のどれをいつまでに誰が決めるかをワークフロー化します。
ID、予算、承認を日常業務に合わせる
利用者は、自分のポリシーで許可されたストア、商品、支払方法、配送先だけを見られるようにします。入社、異動、海外赴任、雇用区分変更、退職に合わせて権限と残高を更新します。
予算は、全社、法人、地域、部門、原価部門、キャンペーン、管理職、個人利用枠などの階層で設計できます。期間、対象商品、超過時の扱い、未使用残高も定義します。
標準的な利用枠内の注文は自動化し、高額発注、未承認デザイン、特急製造、制限地域、上限超過などの例外だけを承認対象にします。
承認記録には、申請者、承認者、ポリシー版、金額、原価部門、判断、理由、時刻、取消しを残します。メール承認だけでは、月次請求と監査で同じ確認を繰り返すことになります。
ブランド審査を商品データに組み込む
ブランド管理を担当者の記憶に依存させてはいけません。商品ごとに色指定、余白、アートワーク版、加工方法、加工サイズ、本体色、梱包、対象市場を結び付けます。
新しい商品とデザインの組み合わせには校正・サンプル工程を設けます。実績のある組み合わせならデジタル校正、新素材、新加工、高価格商品、大規模発表なら現物サンプルが必要です。
デザイン変更時は旧ファイルを上書きせず、版管理を行います。未出荷注文と既存在庫への影響を確認し、旧版を使用できなくする日を決めます。
ローカライズは翻訳以上の運用である
日本向けでは、日本語、円表示、税込・税別の分かりやすさ、国内住所、姓名・郵便番号入力、センチ表記のサイズ表、配送時間帯、問い合わせ対応時間、請求補助、国内で期待される梱包品質などが体験を左右します。
表示できる商品と、約束どおり届けられる商品は同じではありません。生産・在庫拠点、国内外の配送経路、通常と例外の納期、交換・返品を確認した上で地域表示を決めます。
地域担当者には商品提案の正式な経路を与えます。在地需要、サプライヤー、サービス水準を記録し、ブランド・調達の承認後に導入し、利用実績と品質を見直します。
受発注とフルフィルメントを状態機械として設計する
注文状態は「注文済み」と「配送済み」だけでは足りません。少なくとも、決済・予算承認、承認待ち、在庫引当または生産指示、個別校正、梱包、出荷、通関・配送例外、配達、返品、交換、返金、完了を区別します。
各状態について、誰が見られるか、期限、次に進むイベント、例外担当者を決めます。
「ローカルフルフィルメント」は国数ではなく、SKUと配送先で検証します。どこで生産し、どこに保管し、どの配送網を使い、税・関税、配送失敗、返品を誰が負担するのかを確認します。
越境取引の税務・通関ルールは変わります。国別ルールに適用開始日と社内責任者を持たせ、個別案件については専門家の判断を得ます。
返品と例外を公開前に決める
名入れ・加工済み商品は一般消費財と同じ返品条件にできない場合があります。誤品・破損、サイズ選択、加工不良、住所誤り、受取拒否、保管期限切れ、関税未払い、配送紛失、イベント後到着、廃番、再販できない個人名商品を分けて扱います。
利用者には一つの問い合わせ窓口を示し、内部で原因と費用責任に応じて振り分けます。社員に人事、倉庫、印刷会社、配送会社を探させないことが重要です。
交換率だけでは改善できません。加工不良、サイズ情報、ピッキング、配送、住所のどこに原因があるかを理由コードで管理します。
日本の個人情報と海外委託をデータフローで確認する
社内ECは、氏名、社用メール、社員番号、住所、電話、衣類サイズ、所属、言語、注文履歴、原価部門を扱う可能性があります。各項目に利用目的を持たせ、資格確認と配送だけなら人事情報全体をコピーしない設計にします。
ID・資格の情報源、ストアへ渡す項目、サプライヤー・倉庫・配送会社が受け取る項目、処理国、保存期間、訂正・削除・利用停止・退職時の処理をデータマップにします。
日本の個人情報保護委員会は、外国にある第三者への提供に関するFAQで、海外事業者への委託、外国運営クラウド、海外サーバなどを個別に整理しています。海外にデータがあるという事実だけで結論を出すのではなく、提供先、委託関係、サーバ、相当措置、本人への情報提供など、実際の構成で判断する必要があります。
これは運用設計上の論点であり、法的助言ではありません。実際のデータフローと契約は、法務・個人情報保護責任者が確認してください。
週次・月次・四半期の運用カレンダーを持つ
週次
- 失敗注文、承認滞留、欠品、配送例外、未解決問い合わせを確認する
- キャンペーン需要を在庫・生産能力と比較する
- 繰り返す問題の原因と担当者を決める
月次
- 商品、ポイント、補助、返金、送料、税・関税、原価部門を照合する
- SKU需要、在庫年齢、代替、地域SLA、権限変更を確認する
- 経営・運用向けの簡潔なスコアカードを出す
四半期
- 低需要・旧仕様の商品を廃止する
- サプライヤー、加工品質、配送、地域カバレッジを評価する
- 季節商品、ブランド資産、承認ルール、プライバシー表示、問い合わせ手順を更新する
- 実運用コストと導入目的を比較する
売上だけでなく運用品質を測る
一般公開ストアでは売上が重要でも、社内ECの目的は、入手性、統制、従業員体験、ブランド品質、運用工数であることが多いはずです。
- 利用： 対象者の有効化率、利用率、再利用率、購入・交換率、地域・対象者別の差
- 商品・在庫： 市場別の販売可能率、欠品日数、回転、滞留、代替・キャンセル率
- 配送・品質： 製造・出荷時間、地域別納期遵守、初回配達成功、返品・再送・不良、100注文当たりの問い合わせ
- 財務： 商品、加工、梱包、保管、配送、税・関税、サポート、システム費用、成功注文単価、精算期間
- 施策成果： 従業員・パートナー満足、管理職の削減工数、参加率、ブランド遵守、入社準備やイベント成果
利用件数だけで離職率や売上への因果を主張しないようにします。重要な成果は、段階導入、導入前後、比較対象など意思決定に合う方法で検証します。
90日で設計・検証・安定化する
1～30日：定義
対象者と目的、注文・承認・在庫・配送・サポート・会計フロー、導入国、商品階層、予算、SLA、個人情報・税務・調達責任、基準値を決めます。
31～60日：設定とテスト
ID、権限、予算、原価部門、承認、商品、アートワーク、地域表示、在庫・フルフィルメント連携を設定します。住所、サイズ、通知、代替、失敗状態を含む注文を各導入国でテストします。
61～90日：パイロット
限定対象で開始し、週次で例外を確認します。約束と実際の製造・配送時間を比較し、在庫・受注生産ルール、FAQ、承認を調整します。SLAと統制の基準を満たしてから拡大します。
在庫不足、承認却下、住所変更、配送失敗、交換、越境配送など、難しいケースを必ず試します。
グローバル社内EC事業者を評価する質問
デモのデザインだけでなく、次の運用を実演してもらいます。
- 非公開、公開、期間限定、地域、パートナー向けをどう運用するか
- 商品、価格、ポイント、予算、表示を対象者ごとに変えられるか
- SSO、招待、異動、退職をどう処理するか
- 在庫、受注生産、ハイブリッドをどう組み合わせるか
- アートワーク、校正、加工仕様、サプライヤー版をどう管理するか
- SKU・仕様・状態・拠点別の在庫を取得できるか
- 注文失敗時の状態、証跡、復旧操作があるか
- 部門、原価部門、施策、法人別に費用を追えるか
- 供給会社・倉庫・配送会社へ渡すデータと保存期間は何か
- 移行時に在庫、デザイン、注文、残高、ドメインをどう返すか
Giftpackのグローバルスワッグ基盤は、ブランドストア、設計・調達、クラウド在庫、自動化、グローバルフルフィルメントを一つの運用層で扱います。単なるECテーマではなく、その裏側の業務を統合したい企業に適した比較対象です。
新入社員向けの用途はグローバルウェルカムキット運用、大学・会員組織はキャンパスストアと校友エンゲージメントも参考になります。
よくある質問
在庫とオンデマンド生産のどちらを選ぶべきですか？
通常は両方です。需要が安定し短納期が必要なコア商品は在庫し、長尾、個人名、サイズ数の多い商品、試験商品は受注生産にします。ストア全体ではなくSKUと拠点ごとに判断します。
最初に何商品を掲載すべきですか？
共通の正解はありません。主目的を満たし、運用チームが確実に管理できる最小構成から始めます。少数のグローバルコアと地域・用途モジュールの方が学習しやすくなります。
全世界で同じ商品を出すべきですか？
必須ではありません。ブランド、品質、体験、統制を共通化し、商品は気候、サイズ、文化、供給、配送、法規に応じて変えます。
誰が責任者になるべきですか？
一人または一部門が全体結果に責任を持ちます。ブランド、調達、人事、経理、IT、個人情報、運用が統制を分担しても、最終責任を曖昧にしません。
公開前に何をテストしますか？
資格、予算、承認、商品表示、サイズ・住所、在庫引当、受注生産、支払、通知、越境配送、失敗、返品、交換、精算、レポート、退職停止を対象国ごとに試します。
最後に守るべき運用原則
優れたグローバル社内ECは、商品数が最も多いストアではありません。承認済み商品を、各地域で利用でき、費用と状態を追跡できるブランド体験へ変え、裏側の手作業を隠さない仕組みです。
一つの対象者と目的から始め、グローバルコアを絞り、使いやすさと配送に影響する部分をローカライズします。速度や経済性が合う商品だけを在庫し、承認は例外リスクに集中させ、問い合わせ、個人情報、精算を製品要件として扱います。
構築、刷新、統合を検討しているなら、実際の一施策について対象者、商品、予算、フルフィルメント、問い合わせまでを描き、各事業者に失敗と復旧を含む同じ流れを実演してもらうことが、最も有効な比較方法です。