Supply Chain & Procurementシリーズの一部
完全ガイドを読むPower BI を使用した在庫分析: 在庫、売上高、需要
過剰在庫には、毎年その価値の 25 ~ 30% の維持費がかかります。在庫切れにより、小売業者は推定で毎年 1 兆ドルの売上損失を被ります。これら 2 つの極端の間には、最適なインベントリの狭い帯域が存在します。Power BI は、運用チームがそのラインを正確に維持できるツールです。
Power BI の在庫分析の課題は、在庫がフロー測定 (今月の販売量) ではなく、スナップショット測定 (現在いくらあるのか) であることです。この区別により、データ モデルおよびすべての DAX 計算パターンにおけるあらゆる設計上の決定が推進されます。このガイドでは、データ モデル、ABC 分類、売上高分析、再注文ポイントの計算、需要予測の視覚化など、完全な在庫分析プラットフォームについて説明します。
重要なポイント
- 在庫は、販売指標とは異なる DAX パターンを必要とするポイントインタイム (スナップショット) 測定です。
- ABC 分析では、収益貢献度に応じて項目を分類します: A (上位 80%)、B (次の 15%)、C (下位 5%)
- 在庫回転率 = COGS / 平均在庫 - 業界によって大きく異なります
- 再注文ポイント = (1 日の平均使用量 × リードタイム) + 安全在庫
- DAX RANKX 関数により、データの変化に応じて ABC 分類が自動的に強化されます
- Power BI の需要予測では、DAX または Azure ML 統合による線形回帰を使用します。
- 低速移動および陳腐化 (SLOB) 在庫の識別により、維持コストを大幅に節約
- Power BI は、データを移動せずに ERP インベントリ テーブル (Odoo、SAP、NetSuite) に接続します
在庫分析のデータ モデル
コア在庫テーブル
Inventory_Snapshot (日/週あたりアイテムごとに 1 行 — 時点の在庫レベル):
| コラム | 説明 |
|---|---|
| コード0 | 在庫数の日付 |
| コード0 | アイテム/製品のディメンションへの FK |
| コード0 | 倉庫/場所へのFK |
| コード0 | 物理的な在庫数量 |
| コード0 | オープン注文書の数量 |
| コード0 | オープン注文にコミットされた数量 |
| コード0 | QoH - 予約済み |
| コード0 | 平均または標準コスト |
| コード0 | 手持ち数量 × 単価 |
Inventory_Movements (株式取引ごとに 1 行):
| コラム | 説明 |
|---|---|
| コード0 | トランザクションID |
| コード0 | アイテムへのFK |
| コード0 | FKから場所へ |
| コード0 | 移動日 |
| コード0 | 受取・売却・譲渡・精算・返品 |
| コード0 | 移動量 (正 = 入力、負 = 出力) |
| コード0 | 移動時のユニットあたりのコスト |
Sales_Lines (需要分析用に販売注文明細ごとに 1 行):
OrderID、ItemID、OrderDate、ShipDate、Quantity、UnitPrice、Revenue、CustomerID
Purchase_Orders (リードタイムと調達分析用):
POID、ItemID、OrderDate、ExpectedDate、ReceiptDate、Quantity、UnitCost
Dim_Item (製品の寸法):
ItemID、SKU、Name、Category、SubCategory、Supplier、LeadTimeDays、ReorderPoint、SafetyStock、UnitCost、ListPrice、IsActive
DAX を使用したコア在庫 KPI
在庫レベルの測定
// Current Stock on Hand (point-in-time)
Stock on Hand =
CALCULATE(
SUM(Inventory_Snapshot[QuantityOnHand]),
Inventory_Snapshot[SnapshotDate] = MAX(Inventory_Snapshot[SnapshotDate])
)
// Stock Value (current)
Stock Value =
CALCULATE(
SUM(Inventory_Snapshot[StockValue]),
Inventory_Snapshot[SnapshotDate] = MAX(Inventory_Snapshot[SnapshotDate])
)
// Available to Promise (ATP)
Available to Promise =
CALCULATE(
SUM(Inventory_Snapshot[QuantityAvailable]),
Inventory_Snapshot[SnapshotDate] = MAX(Inventory_Snapshot[SnapshotDate])
)
// Stock on Order (incoming POs)
Stock on Order =
CALCULATE(
SUM(Inventory_Snapshot[QuantityOnOrder]),
Inventory_Snapshot[SnapshotDate] = MAX(Inventory_Snapshot[SnapshotDate])
)
// Projected Stock (current + on order - reserved)
Projected Stock = [Stock on Hand] + [Stock on Order] - [Stock Reserved]
在庫回転率
// COGS in Period (for turnover denominator)
Total COGS =
SUMX(
FILTER(Inventory_Movements, Inventory_Movements[MovementType] = "Sale"),
Inventory_Movements[Quantity] * Inventory_Movements[UnitCost]
)
// Average Inventory Value (beginning + ending / 2)
Avg Inventory Value =
AVERAGEX(
VALUES(Date[Month]),
CALCULATE(
SUM(Inventory_Snapshot[StockValue]),
Inventory_Snapshot[SnapshotDate] = MAX(Inventory_Snapshot[SnapshotDate])
)
)
// Inventory Turnover Ratio
Inventory Turnover =
DIVIDE([Total COGS], [Avg Inventory Value], 0)
// Days Inventory Outstanding (DIO)
Days Inventory Outstanding =
DIVIDE(365, [Inventory Turnover], 0)
// Benchmark comparison (industry varies widely)
// Manufacturing: 6-12x | Retail: 4-6x | Electronics: 8-15x
Turnover vs Benchmark =
[Inventory Turnover] -
LOOKUPVALUE(
Industry_Benchmark[InventoryTurnover],
Industry_Benchmark[Category],
SELECTEDVALUE(Dim_Item[Category])
)
ABC分析
ABC 分析では、在庫項目を収益またはコストの寄与度に基づいて分類します。
- A 項目: 収益/COGS の上位 80% — 優先度が高く、厳格に管理されている
- B アイテム: 次の 15% — 中程度のコントロール
- C 項目: 下位 5% — 最小限の見落とし
// Revenue contribution per item (last 12 months)
Item Revenue 12M =
CALCULATE(
SUM(Sales_Lines[Revenue]),
DATESINPERIOD(Date[Date], TODAY(), -12, MONTH)
)
// Cumulative revenue % (for ABC cutoff)
Cumulative Revenue % =
DIVIDE(
SUMX(
FILTER(
ALL(Dim_Item),
RANKX(ALL(Dim_Item), [Item Revenue 12M], , DESC) <=
RANKX(ALL(Dim_Item), [Item Revenue 12M], , DESC)
),
[Item Revenue 12M]
),
CALCULATE([Item Revenue 12M], ALL(Dim_Item)),
0
)
// ABC Classification (calculated column in Dim_Item, refreshed periodically)
ABC Class =
VAR CumPct = [Cumulative Revenue %]
RETURN
SWITCH(TRUE(),
CumPct <= 0.80, "A",
CumPct <= 0.95, "B",
"C"
)
// ABC Summary measure
A Items Count = CALCULATE(COUNTROWS(Dim_Item), Dim_Item[ABC Class] = "A")
A Items Revenue % = DIVIDE(
CALCULATE([Item Revenue 12M], Dim_Item[ABC Class] = "A"),
CALCULATE([Item Revenue 12M], ALL(Dim_Item)),
0
)
ABC-XYZ マトリックス
需要の変動性を考慮して ABC を XYZ 分類で拡張します。
- X: 需要の変動が少ない (CV < 0.5) — 予測可能、効率性を考慮した計画
- Y: 中程度の変動性 (CV 0.5-1.0) — ある程度の不確実性
- Z: 高い変動性 (CV > 1.0) — 予測不可能、サービス レベルの計画
// Coefficient of Variation for demand variability
Demand CV =
DIVIDE(
STDEV.P(Sales_Lines[Quantity]),
AVERAGE(Sales_Lines[Quantity]),
0
)
// XYZ Classification
XYZ Class =
SWITCH(TRUE(),
[Demand CV] < 0.5, "X",
[Demand CV] < 1.0, "Y",
"Z"
)
AX セグメント (高収益、予測可能な需要) は、最も厳しい再注文管理を受けています。 CZ セグメント (低収益、予測不可能) は、削除または受注生産の候補です。
再注文ポイントと安全在庫の計算
再注文ポイントの計算式
再注文ポイント = (1 日の平均使用量 × リードタイム) + 安全在庫
// Average Daily Usage (last 90 days)
Avg Daily Usage =
DIVIDE(
CALCULATE(
SUM(Sales_Lines[Quantity]),
DATESINPERIOD(Date[Date], TODAY(), -90, DAY)
),
90,
0
)
// Reorder Point calculation
Calculated Reorder Point =
ROUND(
[Avg Daily Usage] * AVERAGE(Dim_Item[LeadTimeDays]) +
Dim_Item[SafetyStock],
0
)
// Below Reorder Point flag
Below Reorder Point =
IF([Stock on Hand] < [Calculated Reorder Point], "Reorder Required", "OK")
// Days of Supply remaining
Days of Supply =
DIVIDE([Stock on Hand], [Avg Daily Usage], 0)
// Stockout Risk Score (0-100)
Stockout Risk =
SWITCH(TRUE(),
[Days of Supply] < 7, 100, -- Critical
[Days of Supply] < 14, 75, -- High risk
[Days of Supply] < 30, 50, -- Medium risk
[Days of Supply] < 60, 25, -- Low risk
0 -- OK
)
安全在庫の計算
// Safety Stock using statistical method
// SS = Z-score × σ(demand) × √Lead Time
Safety Stock Calculated =
VAR ZScore = 1.645 -- 95% service level
VAR DemandStdDev = STDEV.P(Sales_Lines[Quantity]) -- per day
VAR LeadTime = AVERAGE(Dim_Item[LeadTimeDays])
RETURN ROUND(ZScore * DemandStdDev * SQRT(LeadTime), 0)
動きが遅い、陳腐化した (SLOB) 在庫
SLOB 在庫を特定することは、運転資本の最適化にとって重要です。
// Days Since Last Sale
Days Since Last Sale =
DATEDIFF(
CALCULATE(
MAX(Sales_Lines[OrderDate]),
ALL(Date)
),
TODAY(),
DAY
)
// SLOB Classification
SLOB Class =
SWITCH(TRUE(),
[Days Since Last Sale] > 365, "Obsolete",
[Days Since Last Sale] > 180, "Slow Moving",
[Days Since Last Sale] > 90, "At Risk",
"Active"
)
// SLOB Inventory Value
SLOB Value =
CALCULATE(
[Stock Value],
Dim_Item[SLOB Class] IN {"Slow Moving", "Obsolete"}
)
// SLOB as % of total inventory
SLOB % =
DIVIDE([SLOB Value], [Stock Value], 0)
需要予測の視覚化
Power BI では、以下を使用して需要予測を視覚化できます。
組み込みの予測 (分析ペイン)
折れ線グラフを右クリック → [分析] ペイン → [予測]:
- 予測期間: 12 か月
- 信頼区間: 95%
- 季節性: 自動検出
これには、単純で定常的な需要パターンに適した指数平滑法 (ETS) アルゴリズムが使用されます。
カスタム DAX 線形予測
// Simple Linear Regression Forecast
Demand Forecast =
VAR LastPeriod = MAX(Date[MonthNum])
VAR ForecastPeriod = LastPeriod + 1 -- Next month
VAR N = COUNTROWS(VALUES(Date[Month]))
VAR SumX = SUMX(VALUES(Date[MonthNum]), Date[MonthNum])
VAR SumY = SUMX(VALUES(Date[Month]), [Monthly Sales Qty])
VAR SumXY = SUMX(VALUES(Date[Month]), Date[MonthNum] * [Monthly Sales Qty])
VAR SumX2 = SUMX(VALUES(Date[MonthNum]), Date[MonthNum]^2)
VAR Slope = DIVIDE(N*SumXY - SumX*SumY, N*SumX2 - SumX^2, 0)
VAR Intercept = DIVIDE(SumY - Slope*SumX, N, 0)
RETURN Intercept + Slope * ForecastPeriod
Azure ML の需要予測
高度な需要予測を行うには、Azure Machine Learning を統合します。
- Azure ML の需要履歴データに基づいて Prophet モデルまたは ARIMA モデルをトレーニングする
- Azure ML Web サービスとしてデプロイする
- AI Insights 統合を使用した Power BI データフローからの呼び出し
- 予測値を項目ディメンションの列として表示する
インベントリ ダッシュボードのアーキテクチャ
ページ 1: 役員名簿の概要
- 総株式価値 (前月比変化を含む KPI カード)
- 在庫回転率 (ゲージと業界ベンチマーク)
- 在庫残高日数 (傾向を含む KPI)
- 在庫切れアイテム数 (アラート カード、>0 の場合は赤色)
- SLOB 値 (合計に対する割合を示す KPI)
- カテゴリ別株価(ツリーマップ)
- 再注文アラート (表: 品目、QoH、再注文ポイント、供給日数)
ページ 2: ABC 分析
- パレート図 (収益、累積 % でランク付けされたアイテム)
- ABC 分布 (ドーナツ チャート: クラス別の数と値)
- ABC-XYZ マトリックス (散布図: X に収益、Y に CV、バブル サイズ = 株価)
- 上位 A 品目の表 (品目、収益、売上高、株価、利益率)
ページ 3: 在庫モニタリング
- 在庫レベルヒートマップ(場所×カテゴリ)
- 再注文ポイント項目の下 (在庫切れリスクの色の表)
- 受信POタイムライン(ガントチャートまたは棒グラフ)
- 在庫期間分析 (棒グラフ: 0 ~ 30、30 ~ 60、60 ~ 90、90 日以上)
ページ 4: 需要と予測
- 実際の需要と予測 (予測に陰影を付けた折れ線グラフ)
- カテゴリ別の需要変動 (箱ひげ図または誤差範囲付き棒グラフ)
- 季節的な需要パターン(ヒートマップ:月×曜日)
- 上位 20 社の急成長企業 (週間販売個数別の棒グラフ)
よくある質問
インベントリ データを取得するために Power BI を ERP に接続する最良の方法は何ですか?
接続方法はERPによって異なります。 Odoo の場合は、リードレプリカ上の PostgreSQL に直接接続します。 SAP の場合は、インベントリ CDS ビューで SAP HANA コネクタを使用します。 NetSuite の場合は、SuiteAnalytics Connect ODBC を使用します。 Dynamics 365 Business Central の場合は、Business Central コネクタを使用します。すべての ERP 接続では、在庫テーブルへの読み取り専用アクセスを持つ専用の分析ユーザー アカウントを使用し、オフピーク時間に更新をスケジュールして ERP の負荷を最小限に抑えます。
Power BI で複数のウェアハウス インベントリを処理するにはどうすればよいですか?
倉庫名、都市、国、タイプ (配送センター、小売店など) などの属性を使用して、場所ディメンションをデータ モデルに追加します。すべてのインベントリ スナップショット行には LocationID が含まれます。すべての場所を集計するか、スライサーを使用して選択した場所でフィルターするメジャーを作成します。倉庫間移動分析の場合、MovementType = "Transfer" の Inventory_Movements テーブルは、場所間の在庫の移動を追跡します。
良好な在庫回転率とは何ですか?
それは業界に大きく依存します。エレクトロニクス: 8 ~ 15 倍 (高速、低マージン)。食料品/日用消費財: 15 ~ 30 倍。自動車部品: 3 ~ 6x。ファッション小売: 4 ~ 8 倍 (季節的)。工業製造: 3 ~ 8 倍。一般的な目標ではなく、業界のベンチマークと離職率を比較してください。 「理想的な」比率は、サービス レベル (在庫切れの回避) と維持コスト (超過の回避) のバランスをとります。
Power BI は在庫がなくなる時期を予測できますか?
はい — 「供給日数」メジャーは、現在の在庫が 1 日の平均販売率で何日カバーされるかを計算します。これがリード タイム + 安全在庫バッファーを下回ると、Power BI はアイテムにリスクがあるとしてフラグを立て、再注文アラート テーブルに表示できます。予測在庫の場合、Azure ML の需要予測を統合して将来の売上を予測し、過去の需要ではなく予測された需要に基づいて在庫切れのリスクが重大になる時期を計算します。
Power BI で在庫の老化を視覚化するにはどうすればよいですか?
各期間(0 ~ 30 日、31 ~ 60 日、61 ~ 90 日、91 ~ 180 日、180 日以上)の在庫価値の割合を示す積み上げ棒グラフを使用します。経過期間は、最も古いバッチの受領日から計算されます。この傾向を長期にわたって追跡して、経年変化のプロファイルが改善しているか(より新しい在庫に向かって進んでいる)、それとも悪化しているか(古い在庫が蓄積している)を確認します。 90 日以上の在庫を SLOB リスク指標として赤で強調表示します。
次のステップ
Power BI の効果的な在庫分析により、輸送コストが削減され、在庫切れが防止され、キャッシュ フローが改善されます。この 3 つの指標は、サプライ チェーンと運用のリーダーシップにとって最も重要です。データ モデルを正しく取得すること (スナップショット ベースの在庫レベル、動きベースのフロー分析) は、他のすべての構築の基礎となります。
ECOSIRE の Power BI チームは、Odoo、SAP、NetSuite、Dynamics 365 などの ERP システムに接続されたサプライ チェーンと在庫のダッシュボードを構築します。当社は、ABC 分析、再注文アラート システム、需要予測の視覚化を実稼働対応のダッシュボードとして実装します。
サプライ チェーン分析の実装については、Power BI ダッシュボード開発サービス をご覧ください。在庫データ ソースと分析要件については、チームにお問い合わせください してください。
執筆者
ECOSIRE Research and Development Team
ECOSIREでエンタープライズグレードのデジタル製品を開発。Odoo統合、eコマース自動化、AI搭載ビジネスソリューションに関するインサイトを共有しています。
関連記事
Building Financial Dashboards with Power BI
Step-by-step guide to building financial dashboards in Power BI covering data connections to accounting systems, DAX measures for KPIs, P&L visualisations, and best practices.
Blockchain for Supply Chain Transparency: Beyond the Hype
A grounded analysis of blockchain in supply chains—what actually works, real-world deployments, traceability use cases, and how to evaluate blockchain for your business.
Case Study: Power BI Analytics for Multi-Location Retail
How a 14-location retail chain unified their reporting in Power BI connected to Odoo, replacing 40 spreadsheets with one dashboard and cutting reporting time by 78%.
Supply Chain & Procurementのその他の記事
Blockchain for Supply Chain Transparency: Beyond the Hype
A grounded analysis of blockchain in supply chains—what actually works, real-world deployments, traceability use cases, and how to evaluate blockchain for your business.
ERP for Agriculture: Farm Management and Supply Chain
Complete guide to ERP for agriculture — farm management, crop tracking, supply chain integration, compliance reporting, and precision agriculture for 2026.
ERP for Government: Procurement, Finance, and Citizen Services
How ERP systems modernize government operations by automating procurement, fund accounting, grants management, and citizen service delivery with full auditability.
ERP for Logistics: 3PL and 4PL Operations Management
Complete guide to ERP for logistics providers — 3PL and 4PL operations management, WMS integration, customer billing, and supply chain visibility for 2026.
Warehouse Automation with ERP: Efficiency and ROI Analysis
Quantify warehouse automation ROI with ERP integration — labor savings, throughput improvement, inventory accuracy, and technology investment frameworks for 2026.
Odoo Inventory and Warehouse Management Deep Dive
Complete guide to Odoo 19 Inventory: multi-warehouse setup, lot tracking, reordering rules, putaway strategies, and warehouse operations.