基幹システムを一つにしても、「在庫」の意味が事業・国・拠点ごとに違えば、経営数字は一つにならない。画面や製品の統一より先に、何を数え、いつ計上し、誰の在庫とするかを統一する必要がある。
Quollio Technologiesは2026年7月24日、ヤンマーホールディングスがデータカタログ「Quollio Data Intelligence Cloud」を採用し、グローバルSCMとAI活用に向けたデータ基盤整備を進めていると発表した。
発表によると、ヤンマーは事業会社ごとにビジネスモデルが異なるため、グループ全体で基幹システムを単一製品へ統一するのではなく、各事業に適したシステムを許容している。その結果、データ形式や定義が異なり、複数システムから抽出したデータをExcelで突合する運用もあったという。現在は、実績計上のタイミングや洋上在庫などの在庫区分をメタデータとして明文化・公開し、PSI（生産・販売・在庫）分析へ使う環境を整えている。
重要なのは製品名ではない。「基幹を統一しない」という判断と、「数字の意味は統一する」という判断を分けた点だ。本記事では、複数事業・拠点を持つ中堅企業の経営者、CFO、DX責任者向けに、システム統一・データ定義統一・両方の3択、在庫定義シート、進め方を示す。
この記事の要点
- ヤンマーの事例では、各事業に適した基幹システムを許容しつつ、在庫区分や実績計上タイミングをメタデータとして明文化する取り組みが示された。
- 発表元は導入製品の提供会社であり、効果数値を独立検証した事例ではない。「運転資本が改善した」と断定せず、分析環境を整備・展開中の事例として読む。
- 基幹統一とデータ定義統一は別の意思決定である。事業共通性、規制、業務差、移行リスクに応じて3択する。
- データカタログを入れても、定義責任者、承認、変更履歴、品質ルールがなければ「検索できるテーブル一覧」で終わる。
- 最初は全社用語集ではなく、「在庫」「売上」「粗利」など経営判断を止めている一つの数字から始める。
公式発表から確認できること
Quollioの発表は、ヤンマー側の担当者コメントを含むベンダー発表である。確認できる事実と、今後の目標を分けて読む。
横にスクロールして確認できます
| 区分 | 公表内容 | 読み方 |
|---|---|---|
| 背景 | 複数事業・国にまたがるSCMと在庫把握、運転資金の最適化が課題 | 経営課題は「システム数」ではなく、資産効率と意思決定 |
| システム方針 | 各事業に適した基幹システムを許容 | 一律統一を選ばない経営判断 |
| 現場課題 | 複数システムのデータをExcelで手作業突合する運用も存在 | 定義・形式差が人手と判断リスクを生む |
| 導入 | 複数製品比較後、QDICを採用 | 製品選定理由は当事者発表であり他社へ自動適用しない |
| 現在の活用 | 実績計上タイミング、洋上在庫などをメタデータとして明文化・公開 | 「意味」を分析者へ共有する仕組み |
| 適用範囲 | 1事業部のPSI分析から全事業へ展開する方針 | 全社展開・成果は進行中 |
| 今後 | 製品別連結損益、人材管理、自動ダッシュボード、AIエージェントへ拡張を目指す | 実績ではなく展望として扱う |
公表文は「求める情報へはるかに短い時間でたどり着けるようになった」とするが、短縮時間、運転資本、在庫回転などの定量効果は示していない。したがって、記事や稟議でROIの実績値としては使えない。自社導入では、探索時間、手作業突合、定義不一致件数、意思決定時間、在庫関連KPIを導入前から測る必要がある。
MANUFACTURING DX
Excel限界から受発注システムへ、同規模の概算は？
中小製造業の概算費用・導入期間・役割分担マトリクスをその場で確認。要件整理テンプレも無料提供します。
基幹システムを統一すれば、数字も統一されるという誤解
基幹統一プロジェクトで起きやすい判断ミスは、「同じ製品・同じ画面を使えば、同じ意味になる」と考えることだ。
例えば、同じ「在庫数量」という項目でも、次が違えば数字は一致しない。
- 工場を出た時点か、販売会社へ到着した時点か
- 洋上・輸送中を含むか
- 他社預け・委託倉庫を含むか
- 予約・引当済みを利用可能在庫から除くか
- 検査中、不良、返品、仕掛品を含むか
- 日次締めか、現地時間の月末締めか
- 所有権移転と物理的な所在のどちらで計上するか
- 数量と会計評価額の対象範囲が一致するか
製品を統一しても、各事業が異なる計上ルールを設定すれば、同じ項目名に違う数字が入る。逆にシステムが複数でも、定義、コード、変換、責任者が明確なら、経営会議用の数字を比較できる。
これは「基幹統一は不要」という主張ではない。二重入力、保守費、セキュリティ、法改正、連携複雑性を減らすため、統一が合理的な場合もある。問題は、製品統一と意味統一を一つの判断として扱うことだ。
経営者が選ぶ3つの方針
横にスクロールして確認できます
| 方針 | 適する状況 | 主な利点 | 主なリスク | 最初の確認 |
|---|---|---|---|---|
| A. システムを統一 | 業務・商流・規制・会計がほぼ共通 | 運用、保守、教育、統制を共通化しやすい | 事業固有要件の過剰カスタマイズ、長期移行 | 共通化できる業務比率 |
| B. データ定義を統一 | 事業差が大きく、基幹を残す合理性がある | 現行業務を維持しつつ横断分析できる | 変換・品質・定義運用が恒久的に必要 | 経営KPIの定義差 |
| C. 両方を段階実施 | 共通領域と固有領域が混在 | 共通は統一、差異はメタデータで吸収 | 境界設計と移行管理が難しい | ドメイン別の統一可否 |
Aを選びやすい条件
複数拠点で商品、価格、受注、会計、在庫移動がほぼ同じで、ローカル差が慣習にすぎない場合。システム統一と業務標準化を同時に進める価値が高い。
Bを選びやすい条件
受注生産と見込生産、製造と保守、国内販売と海外販売など、ビジネスモデルが根本的に違う場合。現場の機動力を残しつつ、経営で比較する数字の意味と変換を統一する。
Cを選びやすい条件
会計・ID・マスタ・セキュリティは共通化し、製造・販売・サービス業務は事業別に残す場合。多くの中堅グループでは現実的だが、「何を共通にしないか」まで経営合意が必要になる。
グループITガバナンスと標準化の考え方や基幹刷新前のシステム資産棚卸しも、3択の前提整理に使える。
FREE DOWNLOAD
AI導入チェックリスト（PoC 失敗要因 10項目）
情シス部門が PoC 前に押さえるべき失敗要因を10項目に整理した無料チェックリスト。
最初に作る「在庫定義12項目」
データカタログ製品を選ぶ前に、経営会議で使う在庫指標を一枚にする。最低限、次の12項目を埋める。
横にスクロールして確認できます
| # | 項目 | 記入例ではなく確認する問い |
|---|---|---|
| 1 | 指標名 | 「在庫」「利用可能在庫」「会計在庫」を区別しているか |
| 2 | 経営目的 | 欠品、運転資本、生産計画、評価損のどれを判断するか |
| 3 | 対象品目 | 製品、部品、仕掛品、保守部品を含むか |
| 4 | 所有主体 | 自社、販売会社、委託先の誰の資産か |
| 5 | 物理的所在 | 工場、倉庫、店舗、洋上、他社預けをどう扱うか |
| 6 | 状態 | 良品、検査中、不良、返品、予約済みをどう分けるか |
| 7 | 計上時点 | 出荷、検収、所有権移転、月末のどこか |
| 8 | 利用可能量 | 引当、予約、安全在庫をどう控除するか |
| 9 | 単位・通貨 | 個、箱、重量、換算、為替レートは何か |
| 10 | 更新時刻 | リアルタイム、日次、月次、現地時間のどれか |
| 11 | 原本システム | どのシステム・テーブル・項目が正本か |
| 12 | 責任者・版 | 定義の承認者、変更日、適用開始日、旧版は何か |
これに「品質ルール」を足す。欠損、重複、負数、遅延、コード不一致、前月比異常をどの基準で検知し、誰が直すかを決める。メタデータは説明文だけではなく、判断・変換・品質・責任を結び付ける。
データカタログが失敗する4つのパターン
1. テーブル一覧を自動収集して終わる
技術メタデータは増えても、業務用語、計算式、利用目的、責任者がない。利用者は項目を見つけても、それが経営会議で使える数字か判断できない。
2. 全社用語集を一度に作る
数千語を登録しようとして、現場レビューが追いつかず、公開前に陳腐化する。最初は在庫、売上、粗利、顧客など、重要な意思決定を止めている一領域へ絞る。
3. 定義の対立をIT部門へ押し付ける
「売上は受注時か検収時か」「洋上在庫を誰の責任にするか」は、データ項目の問題に見えて、経営・会計・業務責任の問題だ。IT部門が勝手に決めると、後で事業側に覆される。
4. 一度決めた定義を変更できない
M&A、新事業、会計方針、物流網の変更で定義は変わる。版、適用日、旧新変換、影響レポートがなければ、過去比較が壊れる。データカタログは「辞書」ではなく変更管理の仕組みとして扱う。
データガバナンスの一般設計はデータカタログ・ガバナンス基盤の費用と進め方やデータプラットフォームのガバナンス設計で整理している。
「在庫の意味」を90日で統一する
0〜30日：同じ会議に出る違う数字を集める
- 経営会議、SCM会議、財務会議で使う在庫表を集める
- 同じ月・品目なのに数字が違う箇所を特定する
- 各数字の作成者、原本、Excel加工、締め時刻を記録する
- 差異が意思決定へ与えた影響を「会議延期・追加確認・欠品・過剰在庫」で残す
31〜60日：12項目と変換を合意する
- 在庫指標を目的別に分ける
- 事業・国ごとの現行定義を並べる
- 全社共通にする部分と、差異として残す部分を決める
- CFO、SCM責任者、事業責任者、IT責任者が承認する
- 原本から経営指標への変換式と品質ルールを決める
61〜90日：一つの会議で運用し、変更を試す
- 一事業・一会議へ限定して新定義を使う
- 元データから指標まで追跡できるか確認する
- 欠損・遅延・例外を誰が直すか実地で回す
- 定義を一つ変更し、旧版・新版・影響通知が残るか試す
- 探索時間、Excel突合時間、差し戻し、会議時間を導入前と比較する
ここまでできてから、データカタログ、MDM、DWH、BI、基幹刷新のどれへ投資するかを決める。製品が先ではなく、運用できる最小単位が先だ。
基幹刷新を始める前に、経営数字の「意味の差」を診断しませんか
GXOでは、複数事業・拠点の基幹刷新やデータ基盤を検討する企業向けに、システム統一・データ定義統一・段階併用の3択を整理します。在庫、売上、粗利など一つの経営指標から、定義、原本、責任、品質、移行範囲を可視化します。
データ定義と基幹刷新の優先順位を相談する → GXO お問い合わせ
投資判断で見るKPI
データカタログの登録件数やログイン人数だけでは、経営価値を測れない。次を導入前から計測する。
横にスクロールして確認できます
| KPI | 目的 |
|---|---|
| 同じ指標の定義数 | 意味の重複・対立を減らせたか |
| 原本不明の指標数 | 数字の出所を説明できるか |
| Excel手作業突合時間 | 人手加工を減らせたか |
| 指標確定までの時間 | 会議前の確認を短縮できたか |
| 定義不一致による差し戻し | 判断のやり直しを減らせたか |
| 品質ルール違反の解決時間 | 欠損・遅延から回復できるか |
| 定義変更の通知漏れ | 版管理が機能しているか |
| 対象KPIを使った意思決定時間 | 経営判断が速くなったか |
運転資本や在庫回転への効果を語る場合は、データ定義以外の施策を分ける。需要予測、生産計画、発注条件、物流、販売施策も数字を変えるため、データカタログだけの効果と断定しない。
ベンダーへ確認する13項目
- 技術メタデータと業務メタデータをどう結び付けますか
- 原本システムから経営KPIまでのリネージを追えますか
- 定義の責任者、承認、版、適用日を管理できますか
- 複数事業で違う定義を、無理に一つへ潰さず表現できますか
- 欠損、重複、遅延、異常値の品質ルールを実行できますか
- 権限・機密区分・個人情報をメタデータと連動できますか
- API、エクスポート、他製品への移行方法はありますか
- 登録件数、利用者、接続先、APIで5年費用はどう変わりますか
- 初期登録後の更新を誰が何時間で行いますか
- 定義の対立を解くワークショップは契約範囲ですか
- AIが参照できる定義・データの範囲を制御できますか
- 契約終了時に定義、リネージ、履歴、品質ルールを返却できますか
- 成功を登録件数以外の業務KPIで合意できますか
データ基盤・データプラットフォーム構築では、DWHやBIの導入だけでなく、データ定義、品質、権限、運用責任を含む上流設計から支援している。
よくある質問（FAQ）
ヤンマーは基幹システムを統一しないと決めたのですか
Quollioの発表では、事業会社ごとにビジネスモデルが異なるため、グループ全体を単一の基幹システムへ統一せず、各事業に最適なシステムを許容する方針と説明されています。個別領域の統合有無までは公表文から断定できません。
データ定義を統一すれば、基幹刷新は不要ですか
不要とは限りません。老朽化、保守終了、セキュリティ、二重入力、高額運用などは刷新理由になります。データ定義統一は、刷新範囲と移行順を誤らないための前工程にもなります。
データカタログとマスターデータ管理は同じですか
同じではありません。データカタログはデータの所在、意味、責任、関係、品質を見つけ理解する仕組み、マスターデータ管理は顧客・商品・組織等の基準データを統制する仕組みです。併用する場合があります。
最初に全社用語集を作るべきですか
最初から全社全用語を対象にすると止まりやすいため、経営判断を止めている一つの指標から始めます。在庫、売上、粗利など、原本と責任者を90日で確認できる範囲が適切です。
AIフレンドリーなデータ基盤とは何ですか
AIがデータ項目の意味、関係、権限、品質を理解・参照しやすい状態を指します。ただし、メタデータがあるだけでAIの回答が正確になる保証はありません。対象データ、権限、評価、監視が別途必要です。
GXOには製品選定前でも相談できますか
相談できます。製品比較の前に、3択、対象KPI、12項目、責任分担、90日検証を整理します。すでにDWH・BI・ERPの提案を受けている場合は、提案範囲と不足工程を第三者確認できます。
出典・確認日
- Quollio公式「ヤンマーホールディングスがQuollioを導入」
- Quollio Technologies公式発表（PR TIMES）
- デジタル庁「データガバナンス・ガイドライン」
- IPA「データ利活用の入門知識」
- IPA「DX実践手引書 ITシステム構築編」
最終確認日：2026年7月27日。導入内容と効果はQuollio側の発表を中心とし、独立した効果測定ではない。全社展開、運転資本改善、製品別損益、人材管理、自動ダッシュボード等は、公表上の現状と将来目標を区別した。価格・機能・導入範囲は案件ごとに再確認する。
まとめ
基幹システムの統一は、経営数字の統一を自動的には生まない。ヤンマーの事例が示す判断価値は、事業ごとのシステム選択を残しながら、実績計上タイミングや洋上在庫などの「意味」を明文化し、横断分析へ使おうとしている点にある。
経営者が最初に決めるべきは、ERP製品ではなく、システム統一・データ定義統一・両方のどれを、どの領域に適用するかだ。在庫定義12項目を一枚にできない状態で大規模刷新へ進めば、部門ごとの違う意味を新システムへ移すだけになる。まず一つの経営数字をそろえ、運用できることを確認してから、基盤と刷新へ広げたい。
