2026-02-13

海外拠点の在庫と物流データを本社に集約しグローバル在庫の偏在と納期遅延を防ぐ方法

海外に複数の拠点を持つ製造業や卸売業では、各拠点が独自の在庫管理システムや現地のERPで在庫・発注・物流を管理しているケースが大半です。本社のサプライチェーン管理と現地データがつながっていないため、ある拠点では在庫が余り、別の拠点では欠品が起きるという非効率が日常的に発生します。この状態を放置すると、過剰在庫による資金の圧迫、拠点間の在庫偏在による販売機会の損失、そして納期遅延による顧客離れが同時に進行します。

この記事は、従業員300〜3,000名規模のグローバル展開企業で、本社側のSCM担当者や情報システム部門のマネージャーを想定しています。読み終えると、海外拠点のバラバラな在庫データを日次で本社に集約し、拠点横断で在庫状況を可視化して意思決定できるワークフローの全体像と、各ステップで使うツールの選び方が分かります。なお、この記事では大規模エンタープライズ向けのSAP S/4HANAやOracle SCM Cloudのようなフルスイート導入計画や、個別ツールの網羅的なレビューは扱いません。あくまで既存の現地システムを活かしながら、データ連携の仕組みを段階的に構築するアプローチに絞ります。

本記事で紹介するツールの組み合わせは代表的な一例です。同じ役割を果たす別の製品でも、同様のワークフローを構築できます。

読み終えた時点で、海外拠点の在庫データを本社に集約するETLパイプラインの設計方針、在庫の一元管理に必要なデータ項目の定義、そして拠点横断の在庫ダッシュボードの構成案を手にしている状態になります。

Workflow at a glance: 海外拠点の在庫と物流データを本社に集約しグローバル在庫の偏在と納期遅延を防ぐ方法

Step 1: 各拠点の在庫データを抽出・変換して統合する (Trocco) (BIツール)
Step 2: 統合データを在庫分析用に構造化して蓄積する (Google BigQuery) (BIツール)
Step 3: 拠点横断の在庫ダッシュボードで意思決定する (Looker Studio) (BIツール)

なぜ海外拠点の在庫情報は本社から見えなくなるのか

拠点ごとにシステムとデータ形式がバラバラ

海外拠点の在庫管理が本社と分断される最大の原因は、各拠点が独自のシステムを使っていることです。東南アジアの拠点ではExcelベースの管理、中国拠点では現地のERPパッケージ、欧米拠点ではNetSuiteやSAP Business Oneなど、拠点の設立時期や現地の商習慣に合わせてシステムが選ばれています。その結果、品目コードの体系、在庫数量の単位、日付フォーマット、通貨といった基本的なデータ項目すら統一されていません。

本社が各拠点にメールやチャットで在庫状況を問い合わせ、返ってきたExcelファイルを手作業で集計しているケースは珍しくありません。この方法では情報の鮮度が1〜2週間遅れになり、意思決定に使えるデータとは言えません。

在庫偏在が資金効率と顧客満足度を同時に悪化させる

本社がリアルタイムの在庫状況を把握できないと、拠点間の在庫移動の判断が遅れます。たとえば、北米拠点で特定製品の在庫が3か月分余っているのに、欧州拠点では同じ製品が欠品して納期遅延を起こしている、という状況が実際に起きます。過剰在庫は倉庫コストと資金の固定化を招き、欠品は売上機会の損失と顧客からの信頼低下に直結します。

物流ステータスの不透明さが二重発注を生む

海外からの輸送には船便で2〜6週間かかることが一般的です。輸送中の在庫がどこにあるのか、いつ届くのかが見えないと、現地拠点は安全のために多めに発注します。本社側も同様に、現地の発注状況が分からないまま追加発注をかけることがあります。この二重発注が過剰在庫の温床になります。

重要な考え方：現地システムは置き換えずデータだけを吸い上げる

海外拠点の在庫管理を改善しようとすると、全拠点のシステムを統一したくなります。しかし、これは現実的ではありません。現地の商習慣、言語、法規制に最適化された既存システムを一斉に入れ替えるには、数年単位の時間と億単位の投資が必要です。さらに、現地スタッフの抵抗も大きく、プロジェクトが頓挫するリスクが高いです。

FitGapが推奨するアプローチは、現地のシステムはそのまま使い続け、在庫・発注・物流のデータだけをETLツール（データの抽出・変換・格納を自動化するツール）で本社側に集約する方法です。各拠点のデータを共通のフォーマットに変換して一か所に集め、そこからBIツール（データを視覚的に分析するツール）で可視化します。

データ統合の3つの前提条件

この方法を成功させるには、3つの前提条件を先に整える必要があります。1つ目は品目マスタの統一です。各拠点で異なる品目コードを、本社の統一コードに紐づけるマッピングテーブルを作成します。2つ目は更新頻度の合意です。全拠点が日次でデータを出力するルールを決めます。週次では判断が遅れ、リアルタイムでは現地システムへの負荷が大きすぎるため、日次が現実的な落としどころです。3つ目は通貨と単位の変換ルールです。在庫金額は本社の基準通貨に、数量単位はSI単位系に統一します。

海外拠点の在庫データを日次で集約し拠点横断で可視化する

ステップ 1：各拠点の在庫データを抽出・変換して統合する（Trocco）

本社のデータ担当者が、ETLツールであるTroccoを使って各拠点のデータを自動収集します。Troccoは日本発のクラウド型ETLサービスで、100種類以上のデータソースに対応しており、海外拠点が使っているデータベースやクラウドサービスからデータを取り込めます。

具体的な作業は次の通りです。まず、各拠点のシステムからデータを取得するコネクタを設定します。拠点のシステムがデータベースであればDB接続、クラウドERPであればAPI接続、最悪の場合はCSVファイルをクラウドストレージ経由で取得する方法を使います。次に、Trocco上で変換処理を定義します。品目コードのマッピング、通貨換算、日付フォーマットの統一、数量単位の変換をここで行います。最後に、変換済みデータをGoogle BigQueryに格納するジョブを日次で自動実行するスケジュールを設定します。

このステップのポイントは、拠点ごとにデータの出し方が異なる現実を受け入れることです。API連携できる拠点もあれば、毎朝CSVをGoogle Driveに置いてもらうしかない拠点もあります。Troccoはこうした混在環境に対応できるため、全拠点を同じパイプラインで管理できます。日次バッチの実行時間は、日本時間の早朝（各拠点の業務終了後）に設定し、本社の業務開始時には最新データが揃っている状態を作ります。

ステップ 2：統合データを在庫分析用に構造化して蓄積する（Google BigQuery）

Troccoから送られてきたデータは、Google BigQueryに蓄積します。BigQueryはGoogleが提供するクラウド型のデータウェアハウス（大量データを高速に分析できる保管庫）で、数十億行のデータでも数秒で集計できます。

BigQuery上では、拠点別・品目別・日付別の在庫テーブル、発注テーブル、物流ステータステーブルの3つを基本構造として作成します。在庫テーブルには拠点コード、統一品目コード、在庫数量、在庫金額（本社基準通貨）、最終更新日時を持たせます。発注テーブルには発注先、発注数量、納入予定日、ステータスを記録します。物流ステータステーブルには出荷元拠点、到着先拠点、輸送手段、現在位置、到着予定日を格納します。

さらに、品目マスタのマッピングテーブルと為替レートテーブルをBigQuery上に持ち、Troccoの変換処理と二重にチェックできる構造にします。これにより、為替レートの更新漏れや品目コードの追加漏れを検知できます。データの保持期間は最低2年分を推奨します。季節変動の分析や前年同期比較に必要だからです。

ステップ 3：拠点横断の在庫ダッシュボードで意思決定する（Looker Studio）

SCM担当者と経営層が日常的に確認するダッシュボードを、Looker Studioで構築します。Looker StudioはGoogleが提供する無料のBIツールで、BigQueryとの接続が標準機能として組み込まれており、追加コストなしでダッシュボードを作成できます。

ダッシュボードには最低限、次の4つのビューを用意します。1つ目は全拠点在庫サマリーで、拠点別・品目カテゴリ別の在庫数量と金額を一覧表示します。2つ目は在庫偏在アラートで、特定品目の在庫が拠点間で大きく偏っている場合に色分けで警告します。たとえば、ある拠点で在庫回転日数が90日を超え、別の拠点で同じ品目が安全在庫を下回っている場合に赤く表示します。3つ目は輸送中在庫マップで、現在輸送中の在庫がどこにあり、いつ届くかを時系列で表示します。4つ目は発注計画の重複チェックで、同一品目に対して複数拠点から発注が出ている場合にフラグを立てます。

運用サイクルとしては、SCM担当者が毎朝このダッシュボードを確認し、在庫偏在アラートが出ている品目について拠点間移動の指示を出します。週次のSCM会議では、在庫回転率の推移と発注計画の妥当性をこのダッシュボードをもとに議論します。月次では経営層向けに、グローバル在庫総額の推移と資金効率の改善状況をレポートします。

この組み合わせが機能する理由

Trocco：異なるシステムからのデータ収集を1つの画面で管理できる

Troccoの最大の強みは、日本語のUIと豊富なコネクタです。海外拠点のシステムがMySQL、PostgreSQL、SQL Server、Amazon S3、Google Driveなど多様であっても、Troccoの画面上でコネクタを選んで設定するだけでデータ取得が始まります。プログラミングの知識がなくても、データの変換ルールをGUIで定義できるため、情シス担当者が1人で運用を回せます。

一方で、Troccoはリアルタイムのストリーミング処理には向いていません。日次バッチが基本の設計思想であるため、分単位でデータを更新したい場合は別の仕組みが必要です。ただし、海外拠点の在庫管理においては日次更新で十分なケースがほとんどです。また、Troccoは月額課金のサービスであり、データ転送量やジョブ数に応じてコストが変動します。拠点数が10を超える場合は、事前にコストシミュレーションを行うことを推奨します。

Google BigQuery：大量の在庫データを低コストで高速に分析できる

BigQueryの強みは、データ量が増えてもクエリ（データの検索・集計命令）の速度がほとんど落ちない点です。全拠点の在庫データを2年分蓄積しても、品目別・拠点別の集計が数秒で返ってきます。また、従量課金モデルのため、データを格納しているだけの状態ではコストが非常に低く抑えられます。

注意点としては、BigQueryのクエリ課金はスキャンしたデータ量に比例するため、非効率なクエリを大量に実行するとコストが膨らみます。テーブルのパーティション設定（日付ごとにデータを区切る設定）を適切に行い、必要な範囲だけをスキャンする設計が重要です。また、BigQueryはGoogleのクラウド基盤上にデータを保管するため、社内のデータガバナンスポリシーとの整合性を事前に確認してください。

Looker Studio：追加コストなしで全社共有のダッシュボードを作れる

Looker Studioは無料で利用でき、Googleアカウントがあれば誰でもダッシュボードを閲覧できます。BigQueryとの接続はワンクリックで完了し、ドラッグ＆ドロップでグラフや表を配置できるため、専門的なBIスキルがなくてもダッシュボードを構築できます。URLを共有するだけで、海外拠点のマネージャーにも同じダッシュボードを見せられる点も、グローバル運用では大きな利点です。

弱みとしては、高度な統計分析やアラートの自動通知機能が限定的である点が挙げられます。在庫偏在の検知を自動化してSlackやメールに通知したい場合は、BigQuery上でスケジュールクエリを設定し、閾値を超えたデータを別途通知する仕組みを追加する必要があります。また、同時接続ユーザーが多い場合にダッシュボードの表示速度が低下することがあるため、経営会議用と日常運用用でダッシュボードを分けることを推奨します。

Recommended tool list

Tool	Role	Pricing	Implementation time	Notes
Trocco	各拠点の異なるシステムから在庫・発注・物流データを抽出し、共通フォーマットに変換してデータウェアハウスに格納するETLパイプライン	月額課金	1〜2週間（1拠点あたりのコネクタ設定と変換ルール定義）	拠点ごとにデータソースの種類（DB接続、API、CSV）が異なるため、最初の1拠点で接続パターンを確立してから横展開する。品目マスタのマッピングテーブルは事前に本社側で作成しておく必要がある。
Google BigQuery	全拠点の在庫・発注・物流データを一元的に蓄積し、拠点横断の集計・分析クエリを高速に実行するデータウェアハウス	従量課金	3〜5日（テーブル設計とパーティション設定）	在庫テーブル、発注テーブル、物流ステータステーブルの3テーブル構成を基本とする。日付パーティションを設定し、クエリコストを抑制する。為替レートテーブルと品目マスタテーブルも同一プロジェクト内に配置する。
Looker Studio	BigQueryの統合データをもとに、全拠点の在庫状況・在庫偏在アラート・輸送中在庫を可視化するダッシュボード	無料枠あり	1〜2週間（4つの基本ビューの構築とテスト）	BigQueryとの接続は標準機能で完了する。在庫偏在アラートは条件付き書式で実装し、自動通知が必要な場合はBigQueryのスケジュールクエリと組み合わせる。経営会議用と日常運用用でダッシュボードを分離することを推奨。