データマネジメントの導入プロセス

記事データマネジメントのデータマネジメントの導入アプローチでは、企業にどのようにデータマネジメントを導入するのか、その流れについて説明しました。
データマネジメントは、次の図のように一つの戦略サイクルで導入されます。

ここでは、より具体的なデータマネジメントの導入プロセスについて次の観点で説明します。

• データマネジメントモデルの設計
• データマネジメント戦略の策定
• データマネジメントシステムの構築
• データマネジメントシステムの運用
• データマネジメント導入支援サービス

データマネジメント導入プロセス一覧（Excel）のダウンロード

データマネジメントモデルの設計

次の図は、データマネジメントモデル設計の流れを表したものです。

ここでは、データマネジメントの目的、体制、方法など本質となる型を設計します。

一つひとつ見ていきましょう。

• データマネジメントの目的の設定
• データアーキテクチャ（概念レベル）の設計
• データ管理基盤（方針レベル）の設計
• データマネジメント組織（ジョブ）の設計
• データマネジメントプロセスの設計

データマネジメントの目的の設定（ビジネス要件の定義）

ここでは、なぜデータマネジメントを行うのか、その目的を設定（データ戦略の設計）します。
ビジネス要件を満たすために、それに関連するデータの品質とセキュリティを確保するという観点でデータマネジメントの目的を設定します。
ビジネス要件は、戦略マップの設計を受けて、次の３つの観点で定義します。

• 各種戦略目標の実現（有効性）
• 各種報告の信頼性確保（信頼性：内部統制）
• 各種法規の遵守（安全性：コンプライアンス）

データアーキテクチャ（概念レベル）の設計

次の手順でデータアーキテクチャ（概念レベル）を設計します。

1. ビジネス上のデータ要件を定義する観点の整理
   ビジネス上の要件を満たすために必要なデータ要件はどういう観点で定義するか整理します。
2. データ品質評価項目のの定義
   データ品質の評価項目（データの一意性など）を定義します。
3. データセキュリティを測る基準の定義
   データセキュリティを測る基準（機密レベルと規制対象カテゴリ）を定義します。
4. ビジネスメタデータとして定義する内容の定義
   ビジネスメタデータとして定義する内容を定義します。
5. データドメインの定義
   データドメイン（データの定義域）を定義します。
6. マスターデータのデータアーキテクチャ（概念レベル）の設計
   1. マスターデータの全体概念マスターデータモデルを設計します。
   2. マスターデータの全体概念データフローを設計します。
   3. マスターデータのビジネスメタデータを定義します。
   4. マスターデータを主管システムに割り当てます。
7. トランザクションデータのデータアーキテクチャ（概念レベル）の設計
   1. トランザクションデータの業務概念データモデルを設計します。
   2. トランザクションデータの業務概念データフローを設計します。
   3. トランザクションデータのビジネスメタデータを定義します。
   4. トランザクションデータを主管システムに割り当てます。
   5. 現行システムのデータが重複しているかどうか確認します。
8. 分析データのデータアーキテクチャ（概念レベル）の設計
   1. 分析データの全体概念分析データモデルを設計します。
   2. 分析データの全体概念データフローを設計します。
   3. 分析データのビジネスメタデータを定義します。
   4. 分析データを主管システムに割り当てます。

データ管理基盤（方針レベル）の設計

データウェアハウスやデータレイクなどデータを管理するための物理的基盤を導入するための基準や方針を次の手順で定義します。
データ管理基盤の導入方針には、データアーキテクチャ（概念レベル）の結果も反映させます。

1. データウェアハウスの導入基準の定義
   データウェアハウス導入するかどうか判断する基準を定義します。
2. データ分析環境の導入基準の定義
   データ分析環境を導入するかどうか判断する基準を定義します。
3. データレイクの導入基準の定義
   データレイクを導入するかどうか判断する基準を定義します。
4. NoSQLの導入基準の定義
   NoSQLを導入するかどうか基準する基準を定義します。
5. マスターデータ管理の基準の定義
   マスターデータをどう管理するのか（トランザクションハブや統合アプローチなど）判断する基準を定義します。
6. データ統合の基準の定義
   データをどう統合するのか（リアルタイム統合やイベント駆動統合など）判断する基準を定義します。
7. データ連携の基準の定義
   データをどう連携するのか（ESBなどの連携基盤を使って統合するかなど）判断する基準を定義します。
8. データウェアハウスの導入方針の設定
   データウェアハウスの導入方針を設定します。
9. データ分析環境の導入方針の設定
   データ分析環境の導入方針を設定します。
10. データレイクの導入方針の設定
    データレイクの導入方針を設定します。
11. NoSQLの導入方針の設定
    NoSQLの導入方針を設定します。
12. マスターデータ管理の方針の設定
    マスターデータ管理の方針を設定します。
13. データ統合方針の設定
    データ統合方針を設定します。
14. データ連携方針の設定
    データ連携方針を設定します。

データマネジメント組織（ジョブ）の設計

データマネジメントに関わる役割を次の手順で定義します。

1. データマネジメントの対象者の定義
   データマネジメントの対象者を定義します。
2. データマネジメントジョブの設計
   データマネジメントジョブと、それらの関係を設計します。

データマネジメントプロセスの設計

データマネジメントをどう進めるのかデータマネジメントプロセスを次の手順で設計します。

1. データマネジメントプロセスの定義
   データマネジメントプロセスを定義します。
2. データマネジメントのアクティビティフローの設計
   データマネジメントのアクティビティフローを設計します。
   これは、データマネジメントのプロシージャになります。
3. データマネジメントのアクションフローの設計
   データマネジメントのアクションフローを設計しデータマネジメントジョブのタスクとして定義します。
   これは、データマネジメントのプロシージャになります。

データマネジメント戦略の策定

次の図は、データマネジメント戦略策定の流れを表したものです。

ここでは、データマネジメントモデルを具体的にどう実現するのか戦略を策定します。
その際、データマネジメントのビジョン、および、あるべき（To-Be)データアーキテクチャ、データ管理基盤、データマネジメント組織を論理レベルで設計します。
その上で、現行（As-Is)のデータアーキテクチャ、データ管理基盤、データマネジメント組織とのギャップを明確にします。
その結果を踏まえて、データマネジメントシステムの構築計画、および、データマネジメントシステム運用計画を策定します。
一つひとつ見ていきましょう。

• データマネジメントのビジョンの設定
• データ管理基盤（製品レベル）の設計
• データアーキテクチャ（論理レベル）の設計
• データマネジメント組織（部門）の設計
• データマネジメントシステム構築計画の策定
• データマネジメントシステム運用計画の策定

データマネジメントのビジョンの設定

いつどのデータマネジメント成熟度レベルになるか設定します。
次の図は、DMBOKのデータマネジメント成熟度モデルを、各分野別に詳細化したものです。

データマネジメント成熟度モデルに合わせて、次の図のように、データ利活用の成熟度も上がります。

データアーキテクチャ（論理レベル）の設計

次の手順で、企業全体のデータモデル（静的モデル）とデータフロー（動的モデル）を論理レベルで設計します。
論理データフローにはデータ管理基盤（製品レベル）の結果も反映させます。

1. テクニカルメタデータとして定義する内容の定義
   テクニカルメタデータとして定義する内容を定義します。
2. マスターデータのデータアーキテクチャ（論理レベル）の設計
   1. マスターデータの全体論理マスターデータモデルは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   2. マスターデータの全体論理データフローは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   3. マスターデータのテクニカルメタデータは、各アプリケーションを開発する際、システム開発者が定義します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
3. トランザクションデータのデータアーキテクチャ（論理レベル）の設計
   1. トランザクションデータの業務論理データモデルは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   2. トランザクションデータの業務論理データフローは、各アプリケーションを開発する際、システム開発者が設計します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
   3. トランザクションデータのテクニカルメタデータは、各アプリケーションを開発する際、システム開発者が定義します。
      データアーキテクトは、運用フェーズで、データアーキテクチャ（概念レベル）やビジネスメタデータのデータ要件が反映されているか検証します。
4. 分析データのデータアーキテクチャ（論理レベル）の設計
   1. 分析データの全体論理分析データモデルを設計します。
   2. 分析データの全体論理データフローを設計します。
   3. 分析データのテクニカルメタデータを定義します。

データ管理基盤（製品レベル）の設計

次の手順でデータ管理基盤（製品レベル）を設計します。

1. データウェアハウスの製品選択基準の定義
   データウェアハウスの製品選択基準及び評価指標を定義します。
2. データ分析環境の製品選択基準の定義
   データ分析環境の製品選択基準及び評価指標を定義します。
3. データレイクの製品選択基準の定義
   データレイクの製品選択基準及び評価指標を定義します。
4. NoSQLの製品選択基準の定義
   NoSQLの製品選択基準及び評価指標を定義します。
5. マスターデータ管理の製品選択基準の定義
   マスターデータ管理の製品選択基準及び評価指標を定義します。
6. データ統合の製品選択基準の定義
   データ統合の製品選択基準及び評価指標を定義します。
7. データ連携の製品選択基準の定義
   データ連携の製品選択基準及び評価指標を定義します。
8. オペレーショナルメタデータとして定義する内容の定義
   オペレーショナルメタデータとして定義する内容を定義します。
9. データウェアハウスの設計（製品レベル）
   データウェアハウスの製品を選定します。
10. データ分析環境の設計（製品レベル）
    データ分析環境の製品を選定します。
11. データレイクの設計（製品レベル）
    データレイクの製品を選定します。
12. NoSQLの設計（製品レベル）
    NoSQLの製品を選定します。
13. マスターデータ管理の設計（製品レベル）
    マスターデータ管理の製品を選定します。
14. データ統合の設計（製品レベル）
    マスターデータ管理の方針を設定します。
15. データ統合の設計（製品レベル）
    データ統合の製品を選定します。
16. データ連携の設計（製品レベル）
    データ連携の製品を選定します。
17. データウェアハウスのオペレーショナルメタデータの定義
    データウェアハウスのオペレーショナルメタデータを定義します。
18. データ分析環境のオペレーショナルメタデータの定義
    データ分析環境のオペレーショナルメタデータを定義します。
19. データレイクのオペレーショナルメタデータの定義
    データレイクのオペレーショナルメタデータを定義します。
20. NoSQLのオペレーショナルメタデータの定義
    NoSQLのオペレーショナルメタデータを定義します。
21. マスターデータ管理のオペレーショナルメタデータの定義
    マスターデータ管理のオペレーショナルメタデータを定義します。
22. データ統合のオペレーショナルメタデータの定義
    データ統合のオペレーショナルメタデータを定義します。
23. データ連携のオペレーショナルメタデータの定義
    データ連携のオペレーショナルメタデータを定義します。

データマネジメント組織（部門）の設計

データマネジメント組織（部門）を設計します。

データマネジメントシステム構築計画の策定

次の観点でデータマネジメントシステム構築計画を策定します。

• データ管理基盤構築計画の策定
  システム開発プロセスに従ってデータ管理基盤構築計画を策定します。
• データマネジメント組織構築計画の策定
  データマネジメント組織構築計画を策定します。

データマネジメントシステム運用計画の策定

次の観点でデータマネジメントシステム運用計画を策定します。

• 個別アプリケーション設計時の検証計画の策定
  データアーキテクトは、年間のアプリケーション開発計画に従って、個別アプリケーション設計時の検証計画を策定します。
• 個別アプリケーション受入テスト時の検証計画の策定
  データスチュワードは、年間のアプリケーション開発計画に従って、個別アプリケーション受入時の検証計画を策定します。
• 既存アプリケーションの検証計画の策定
  データスチュワードは、調査できていない既存アプリケーションシステムやデータ管理基盤の品質やセキュリティの検証計画を策定します。
• データ運用の検証計画の策定
  データスチュワードは、アプリケーションシステムやデータ管理基盤のオペレーショナルメタデータを確認し、データのバックアップと復旧の検証する計画を策定します。
• コードマスター（参照データ）のメンテナンス計画の策定
  データスチュワードは、コードマスター（参照データ）のメンテナンス計画を策定します。
• データオーナーの問い合わせ対応計画の策定
  データスチュワードは、データオーナーの問い合わせ対応計画を策定します。
• データドリブン経営の支援計画の策定
  データサイエンティストは、年間の経営計画に従って、データドリブン経営の支援計画を策定します。
• データの改善・強化計画の策定
  データスチュワードは、データの改善・強化計画を策定します。

データマネジメントシステムの構築

次の図は、データマネジメントシステム構築の流れを表したものです。

ここでは、戦略フェーズで策定したデータマネジメントシステムの構築計画に従ってデータマネジメントシステム（データ管理基盤およびデータマネジメント組織）を構築します。
一つひとつ見ていきましょう。

• データ管理基盤の構築
  データマネジメントシステム構築計画に従ってデータ管理基盤を構築します。構築されたデータ管理基盤は、ITサービスマネジメントの一環として運用されます。
  受入テストの段階でデータ管理基盤の実データのプロファイリングをします。
  受入テストの段階でデータ管理基盤のセキュリティ監査をします。
• データマネジメント組織の構築
  データマネジメント組織構築計画に従ってデータマネジメント組織を構築します。
• データマネジメントシステムの検証
  構築されたデータマネジメントシステム（データ管理基盤、データマネジメント組織）の上でデータマネジメントプロセスが運用できるか検証します。

データマネジメントシステムの運用

次の図は、データマネジメントシステム運用の流れを表したものです。

ここでは、戦略フェーズで策定したデータマネジメントシステム運用計画に基づいて、データマネジメントシステムを運用します。
なお、データマネジメントシステム運用の手順は、設計フェーズで設計したデータマネジメントプロセスで定義されてたものです。
一つひとつ見ていきましょう。

• データマネジメントシステム運用計画の実行
• データマネジメントシステム運用計画の検証
• データマネジメントシステム運用計画の改善

データマネジメントシステム運用計画の実行

• 個別アプリケーション設計時の検証
  • アプリケーションシステムのデータ要件の検証
    ビジネスメタデータのデータ要件とシステムのデータ要件を参照し、アプリケーションの要件定義の妥当性をを検証します。
  • アプリケーションシステムのデータモデルの検証
    ビジネスメタデータのデータ要件とデータアーキテクチャ（概念レベル）を参照し、アプリケーションの論理データモデルとテクニカルメタデータを検証します。
  • 業務パッケージのデータ要件の検証
    ビジネスメタデータのデータ要件と業務パッケージのデータ要件をギャップ分析し、業務パッケージの仕様の妥当性をを検証します。
• 個別アプリケーション受入テスト時の検証
  • アプリケーションシステムのデータプロファイリング
    受入テストの段階でアプリケーションシステムの実データをプロファイリングします。
  • 業務パッケージのデータプロファイリング
    受入テストの段階で業務パッケージの実データをプロファイリングします。
  • アプリケーションシステムのセキュリティ監査
    受入テストの段階でアプリケーションシステムのセキュリティ監査をします。
  • 業務パッケージのセキュリティ監査
    受入テストの段階で業務パッケージのセキュリティ監査をします。
• 既存アプリケーションの検証
  • 既存アプリケーションシステムのデータプロファイリング
    調査できていない既存アプリケーションシステムの実データをプロファイリングします。
  • 既存業務パッケージのデータプロファイリング
    調査できていない既存業務パッケージの実データをプロファイリングします。
  • 既存データ管理基盤のデータプロファイリング
    調査できていない既存データ管理基盤の実データをプロファイリングします。
  • 既存アプリケーションシステムのセキュリティ監査
    調査できていない既存アプリケーションシステムのセキュリティ監査をします。
  • 既存業務パッケージのセキュリティ監査
    調査できていない既存業務パッケージのセキュリティ監査をします。
  • 既存データ管理基盤のセキュリティ監査
    調査できていない既存データ管理基盤のセキュリティ監査をします。
• データ運用の検証
  • データ管理基盤のデータ運用検証
    データ管理基盤のオペレーショナルメタデータを確認し、データのバックアップと復旧の検証をします。
  • アプリケーションシステムのデータ運用検証
    アプリケーションシステムのオペレーショナルメタデータを確認し、データのバックアップと復旧の検証をします。
  • 業務パッケージのデータ運用検証
    業務パッケージのオペレーショナルメタデータを確認し、データのバックアップと復旧の検証をします。
• コードマスター（参照データ）のメンテナンス
  コードデータ（参照データ）は、データ分析するときの特徴量にもなり、これを会社全体で一元管理することはデータの一貫性を保つためにも重要です。
  コードデータをマスター化して会社全体で一元管理する支援をします。
• データオーナーの問い合わせ対応
  データオーナーからの問い合わせに対応します。
• データドリブン経営の支援
  KPIを検証するビジネスプロセスに従って問題の特定、原因の推定、解決策の策定、実験計画の策定、解決策の検証の支援をします。
• データの改善・強化
  • データ管理基盤のデータの改善・強化
    データプロファイリングやセキュリティ監査の結果を受けて、データ管理基盤のデータを改善、強化します。
  • アプリケーションシステムのデータの改善・強化
    データプロファイリングやセキュリティ監査の結果を受けて、アプリケーションシステムのデータを改善、強化します。
  • 業務パッケージのデータの改善・強化
    データプロファイリングやセキュリティ監査の結果を受けて、業務パッケージのデータを改善、強化します。

データマネジメントシステム運用計画の検証

データ管理者は、年間のデータマネジメント計画結果を検証します。

データマネジメントシステム運用計画の改善

データ管理者は、年間のデータマネジメント計画を改善します。その際、必要に応じて、データマネジメントモデルやデータマネジメント戦略も見直します。

データマネジメント支援サービス

弊社では、DXの一環としてデータマネジメントの導入を支援するサービスを実施しています。
本サービスの内容は次のようになります。

• データマネジメント体験ワークショップ
  データマネジメント体験ワークショップでは、ワークショップを通して、実際にデータマネジメントの成果物を作成することで、実践的に、貴社のデータ人材を育成します。
• データアーキテクチャ設計代行サービス
  弊社で貴社のデータアーキテクチャ設計を代行いたします。
• データカタログ作成代行サービス
  弊社で貴社のデータカタログ作成を代行いたします。
• データマネジメント代行サービス
  年間のデータマネジメントのデータマネジメントシステム運用計画に従って、次の運用タスクを代行いたします。

企業の担当者の方へ
一度、詳細をご説明いたします。
お問い合わせは以下のメールアドレスにお願いいたします。
culnou_dm@culnou.com