知識資産の最大化を実現するKBマネジメント 本文へジャンプ

ビジネスアナリシス方法論 (その2)

2011年1月19



 

ビジネスアナリシス方法論GUTSY-4では、4つのモデルと4つのフェーズには密接な関係があります。

まずプロセスの階層レベルと4つのモデル(ビジネスモデル、ビジネスプロセスモデル、要求モデル、ソフトウェアモデル)との関係です。

 

プロセス階層レベル:                 

レベル0: 事業戦略(全社)             ビジネスモデル

レベル1: 戦略課題(営業本部、製造本部)   ビジネスモデル

レベル2: 業務課題(部)               ビジネス/ビジネスプロセスモデル
レベル3: 業務プロセス上位(営業課)      ビジネスプロセスモデル

レベル4: 業務プロセス中位(係)         ビジネスプロセス/要求モデル

レベル5: 業務プロセス下位(担当者)      ビジネスプロセス/要求モデル

      (トランザクション処理)

レベル6: トランザクション機能部品       ソフトウェアモデル

 

これらを図示すると次の図になります。




上図のように、4つのモデルは重なり合いながらブレークダウンして、「ビジネスモデル」から「ビジネスプロセスモデル」、「要求モデル」そして「ソフトウェアモデル」とカスケードしています。このように重なり合っているところが重要です。

さらに、この方法論では活動プロセスを図のように4つのフェーズに分けています。




各々のフェーズの内容の概要は以下のとおりです。

フェーズⅠは、戦略要素を構造化したもので、プロセス改革を構想するフェーズです。




緑色の部分がBABOKの知識エリア「エンタープライズアナリシス」に相当することが分かります。

タスクで言えば、「ビジネスニーズを定義」してから「ギャップを分析」し、フィージビリティ調査を行いますから、「ソリューションアプローチを決定する」タスクまでの活動となります。

オレンジ色の部分は課題の抽出ですから、知識エリア「引き出し」のタスクに相当します。

 

フェーズⅡはプロセス上位設計とプロセス改革企画フェーズです。




ピンクの部分は知識エリア「要求アナリシス」に相当します。上位プロセスですから、「要求を体系化する」タスクと言えます。

緑色の部分は企画の立案ですから、エンタープライズアナリシスの「ビジネスケースを定義する」タスクに相当します。

このフェーズはBABOK2つの知識エリア「エンタープライズアナリシス」と「要求アナリシス」にまたがった活動をしています。BABOKの知識エリア/タスクはプロセスではありませんから、このように方法論のアクティビティが知識エリアをまたがったプロセスであっても何ら差し支えありません。

 

フェーズⅢはプロセス中位設計とプロセス改革計画フェーズです。

 



ピンク色の(要求アナリシスのタスクに相当する)活動が多いのが分かります。オレンジ色は「引き出し」のタスクです。空色(RFP作成)は知識エリア「要求のマネジメントとコミュニケーション」の「要求パッケージを作成する」タスクです。黄色は知識エリア「ソリューションのアセスメントと妥当性確認」のなかの「提案ソリューションをアセスメントする」タスクそのものです。

 

フェーズⅣはプロセス下位設計とIT導入フェーズです。




空色の部分「ベースラインの要求定義」「ベースラインの要求仕様定義」はBABOKの知識エリア「要求のマネジメントとコミュニケーション」の「スリューションスコープと要求をマネジメントする」タスクです。

黄色の部分は知識エリア「ソリューションのアセスメントと妥当性確認」で、「業務運用設計」「マスターデータ移行」「新業務ユーザー教育」「業務移行計画」などは、「移行要求を定義する」タスクと言えます。「業務移行、各種テスト(共同)」は「ソリューションを妥当性確認する」タスクそのものです。ピンク色の活動(レベル5プロセス設計、ITRn要求定義、ITRn要求仕様定義)は

 

もう一度、4つのフェーズの全体図とBABOK知識エリアとの関係を見てください。




4つのフェーズの活動がBABOKの知識エリアにほぼ対応していることが分かります。

 

 

つづいて、BABOKの要求の分類との関係を見てみましょう。




図のように、各々のモデルが3つの要求の分類に対応することが分かります。

 ビジネスモデル         → ビジネス要求

 ビジネスプロセスモデル     → ステークホルダー要求

 要求モデル/ソフトウェアモデル → ソリューション要求

 

なおかつ、ビジネス要求、ステークホルダー要求、ソリューション要求が少しずつ重なり合っているのも重要なことです。これにより、容易に「要求のトレーサビリティを管理する」ことが可能になります。方法論のプロセスそのものにトレーサビリティの概念が内包していることになります。それだけではありません、「要求を妥当性確認する」タスクも必然的にプロセスがサポートしてくれています。