JP2006048145A - ビジネスモデリング支援方法およびビジネスモデリング支援プログラム - Google Patents

Abstract

【課題】企業活動を最適化するビジネスモデリングを支援すること。
【解決手段】企業活動を構成する機能的構成要素（機能ユニット）を抽出し、抽出された機能ユニットの配置、組み合せまたは当該機能の実現手段を検討する機能モデル作成工程（Ｓ１０１）と、抽出・検討された各機能ユニットの内容を階層的に詳細化し、詳細化された実務レベルの機能ユニットを抽出する階層化／詳細化工程（Ｓ１０２）と、企業活動における種々な業務イベントを抽出する業務イベント抽出工程（Ｓ１０３）と、抽出された業務イベントごとの業務遂行プロセスをモデル化し、プロセスの所要コストおよび所要時間を算出するプロセスモデル作成工程（Ｓ１０４）と、ビジネスを遂行するための新しい組織体系をモデル化する組織モデル作成工程（Ｓ１０５）と、抽出された機能ユニット、または、モデル化された業務遂行プロセスをモニタリングするモニタリング工程（Ｓ１０６）と、を含む。
【選択図】 図１

Description

この発明は、企業活動のビジネスモデリングを支援するビジネスモデリング支援方法およびビジネスモデリング支援プログラムに関する。

近年、ビジネスモデルの浮沈スピードが加速し、これに伴って、いわゆるビジネスエンジニアリング（プロセスのコストおよび所要時間の実証的・継続的改善）の必要性が高まってきている。この際、企業の継続的な全体最適化のためには、ビジネスのモデル化（可視化）が不可欠であり、コンピュータ・システムとビジネスを統合的に表現するモデルが不可欠である。そして、ビジネスモデルの再構築やＢＰＲ（Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｒｅｅｎｇｉｎｅｅｒｉｎｇ）によって、自社の競争優位性を高めていくためには、企業の機能的構造と業務遂行プロセスを表現する企業の設計図が必要となる。

しかしながら、上記従来技術にあっては、その設計図を作成する方法論が存在しないなどの理由によって、企業には、その機能的構造や業務プロセスの形態を総合的に表現するための設計図に相当するものが事実上存在しない。このような状態では、最適なビジネスモデルやＢＰＲプランを、明確な見通しと確信をもって打ち出すことはきわめて困難であるという問題点があった。

この発明は、上述した従来技術による問題点を解消するため、企業活動を最適化するビジネスモデリングを支援することが可能なビジネスモデリング支援方法およびビジネスモデリング支援プログラムを提供することを目的とする。

上述した課題を解決し、目的を達成するため、請求項１に記載の発明にかかるビジネスモデリング支援方法は、前記企業活動を構成する機能的構成要素（以下、「機能ユニット」または単に「ユニット」という）を抽出し、抽出された機能ユニットの配置、組み合せまたは当該機能の実現手段の少なくとも一つを検討する機能モデル作成工程と、前記機能モデル作成工程によって抽出・定義された各機能ユニットについて、その内容を階層的に詳細化し、具体的な実務レベルの機能ユニットを抽出する階層化／詳細化工程と、前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスをモデル化し、プロセスの所要コストおよび所要時間の少なくともいずれかを算出するプロセスモデル作成工程と、ビジネスを遂行するための新しい組織体系をモデル化する組織モデル作成工程と、前記階層化／詳細化工程によって抽出された機能ユニット、または、前記プロセスモデル作成工程によってモデル化された業務遂行プロセスをモニタリングするモニタリング工程と、を含んだことを特徴とする。

また、請求項２に記載の発明にかかるビジネスモデリング支援方法は、企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、前記企業活動を構成する機能ユニットを抽出する機能モデル作成工程と、前記機能モデル作成工程によって抽出された各機能ユニットについて、当該機能の実現手段、当該機能ユニットの性質および当該機能ユニットの特徴の少なくとも一つを表現するアイコンを表示する表示工程と、を含んだことを特徴とする。

また、請求項３に記載の発明にかかるビジネスモデリング支援方法は、企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、前記企業活動を構成する機能ユニットを抽出する機能モデル作成工程と、前記機能モデル作成工程によって抽出された各機能ユニットの機能的内部構造を階層的に表示する表示工程と、を含んだことを特徴とする。

また、請求項４に記載の発明にかかるビジネスモデリング支援方法は、企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセス間を順次逐次的に強調するように表示する表示工程と、を含んだことを特徴とする。

また、請求項５に記載の発明にかかるビジネスモデリング支援方法は、企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスについて、当該機能の実現手段、当該機能ユニットの性質および当該機能ユニットの特徴の少なくとも一つを表現するアイコンを表示する表示工程と、を含んだことを特徴とする。

また、請求項６に記載の発明にかかるビジネスモデリング支援方法は、企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスについて、当該プロセスの詳細な関連情報の表示／非表示を制御する表示工程と、を含んだことを特徴とする。

また、請求項７に記載の発明にかかるビジネスモデリング支援方法は、企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスを部署別に層化して表示する表示工程と、を含んだことを特徴とする。

また、請求項８に記載の発明にかかるビジネスモデリング支援方法は、企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、前記業務イベント抽出工程によって抽出された業務イベントごとの実務レベルの詳細な業務遂行プロセスを表示する第１の表示工程と、前記第１の表示工程によって表示された詳細な業務遂行プロセスを俯瞰的なレベルで再展開し、再展開された業務遂行プロセスを表示する第２の表示工程と、を含んだことを特徴とする。

また、請求項９に記載の発明にかかるビジネスモデリング支援方法は、請求項４〜８のいずれか一つに記載の発明において、さらに、前記業務遂行プロセスの応答所要時間およびターンアラウンド時間の少なくともいずれかを算出する算出工程を備え、前記表示工程が、前記算出工程によって算出された結果に関する情報を表示することを特徴とする。

また、請求項１０に記載の発明にかかるビジネスモデリング支援プログラムは、前記請求項１〜９のいずれか一つのビジネスモデリング支援方法をコンピュータに実行させることを特徴とする。

本発明によれば、企業活動を最適化するビジネスモデリングを支援するビジネスモデリング支援方法およびビジネスモデリング支援プログラムが得られるという効果を奏する。

以下に添付図面を参照して、この発明にかかるビジネスモデリング支援方法およびビジネスモデリング支援プログラムの好適な実施の形態を詳細に説明する。

（ビジネスモデリングの概要）
まず、この発明の本実施の形態にかかるビジネスモデリング支援方法の概要について説明する。図１は、この発明の本実施の形態にかかるビジネスモデリング支援方法の概要を示す説明図である。

図１において、企業（すなわち、モデル化の対象領域）１００のビジネスモデリングをするに際し、まず、機能モデルの作成（すなわち、企業内の機能ユニットの抽出）をおこなう（ステップＳ１０１）。ここでは、企業活動を構成する「機能」を抽出し、これを「機能ユニット」というコンポーネントに整理する。さらに、これら機能ユニットの配置や組み合せ、あるいはその機能の実現手段を検討することによって、企業のコア・コンピタンスの検討・明確化、業務のアウトソーシング・インソーシングなどを含めたビジネスモデルの検討をおこなう。この作業は、マクロ的なビジネスモデルの分析と構築の段階に相当する。

つぎに、機能モデルの階層化（すなわち、機能ユニットの詳細化・具体化）をおこなう（ステップＳ１０２）。ここでは、それぞれの機能ユニットについて、そのユニットの内容を具体化するために、一つ一つの機能ユニットごとに、その内容を階層的に詳細化し、より細かい実務レベルの機能ユニットを抽出する。

つぎに、業務イベント一覧表の作成（すなわち、業務イベントの抽出）をおこなう（ステップＳ１０３）。ここでは、企業活動における様々な「ビジネス・イベント」をリストアップし、「業務イベント一覧表」として整理する。

つぎに、プロセスモデルの作成（すなわち業務遂行プロセスの可視化、ビジネスプロセスの最適化および時間とコストのシミュレーション）をおこなう（ステップＳ１０４）。ここでは、「業務イベント一覧表」に記載されたイベントごとの業務遂行プロセスをモデル化し、ＢＰＲを検討する。また、この過程でプロセスの所要コストや所要時間を算出する。プロセスモデルは「機能モデル」で抽出された「機能ユニット」を連鎖的につなげることによって表現される。

つぎに、組織モデルの作成（すなわち、現実の組織構造の決定）をおこなう（ステップＳ１０５）。ここでは、ビジネスを遂行するための新しい組織体系をモデル化し、そのビジネスを支える最適な組織のあり方を検討する。

最後に、モニタリング（すなわち、継続的なパフォーマンス測定と評価）をおこなう（ステップＳ１０６）。ここでは、現実のものとなった新しいビジネスモデルやプロセスをモニタリングし、モデルの妥当性を実務の中で検証する。このモニタリングの過程で課題を抽出し、つぎの新たな改善策を検討する。

ただし、上記の作業の流れは単純に一方向に流れるのではなく、作業の各ステップで様々な再検討がなされ、試行錯誤的な再構成とフィードバックがなされる。ダイアグラムを「作成してはやり直し」ということが繰り返され、この中でダイアグラムが完成度を増していくとよい。さらに、「機能ユニット」を軸に展開されており、それぞれの各作業ステップで、この「機能ユニット」が継承され再利用されていく。このような方式は、分析結果を相互に共有し継承していくという意味で、作業上の無駄や重複を防ぐことができる。

このような方法を支援するためには、ソフトウエア的な作業プラットフォームや作業支援ツールが必要になる。このようなツールがあれば、各ステップのモデルは常に整合性が保たれ、かつ、試行錯誤的なシミュレーションも手戻りを気にすることなく自由におこなうことができる。

（モデリングツールの内容）
上記ビジネスモデリングは、機能モデルで抽出される機能ユニットをベースに展開されるものであり、この機能ユニットに関する情報はプロセスモデルと組織モデルへ継承され共用される。一方で、機能モデルにおいて、最初から最適な機能ユニットを抽出できるということはほとんどなく、プロセスモデルの作成過程で、機能モデルや機能ユニットの見直しが間断なくおこなわれ、徐々に機能モデルと機能ユニットが洗練され「しっくりくる」ものになっていく。同様に、組織モデル作成の過程においても、機能モデルやプロセスモデルが影響を受け改変される場合がある。

このようにモデリングの過程で、機能モデル、プロセスモデル、組織モデルの３つのモデルは相互に密接にフィードバックし合う関係にあり、これを言い換えれば、３つのモデルは、絶えず相互に書き直さなければならないということを意味する。このような三位一体のモデル体系は、モデル全体を整合的に精緻化できるという特色を持つが、一方で、３つのモデルを齟齬なく書き直しておかなければならないという手間がかかる。

また、この発明の本実施の形態における機能ユニットモデルは、その階層構造に特色がある。機能モデルにおいては、全社俯瞰的なトップレベルのマクロモデルから、順次、具体的な詳細な段階へとブレイクダウンされていく。これは、あるダイアグラムシート上の特定の機能ユニットについて、その詳細を見たいとき、あるいはその全体の中での位置づけを見たいときは、別なシートを探し出して見る必要があるということである。このような垂直的な階層構造は、機能モデルに限らず、プロセスモデルや組織モデルにおいても同様である。

さらに、これらのダイアグラムは、視覚的なわかりやすさを追求しているために、ダイアグラムシート上に機能ユニットを配置しながら、モデルを「描く」という作業が多く発生する。この「描く」という作業はしばしば時間のかかる作業である。機能ユニットの配置場所の微妙な調整や、関係線の描画など試行錯誤的な作業を続ける必要がある。

このような作業を効率的におこない、かつ、その結果を統合的に保存し継承していくためには、専用のソフトウエア・ツールを作成し利用することが有効である。また、このようなソフトウエア・ツールは、モデリングの結果を統合的なデータベースに保存することができるため、このモデリング作業の成果をシステム開発用のデータベースと連携させることによって、コンピュータシステムの設計・開発にも役立てることができる。

（ソフトウエア・ツールの内容）
この発明の本実施の形態にかかるソフトウエア・ツールは、モデルコンポーネントをすべて統合的に格納するデータベース（リポジトリー）を作成する。このデータベースは、機能モデル、機能ユニット、プロセスモデル、業務イベント一覧表、組織モデル上のすべての情報を保有する。そして、以下の各機能を備える。

（１）ダイアグラミング支援機能
マウスを用いた画面上のポインティングやドラッグ・ドロップによる機能ユニットのプロット、および機能ユニット間の描線機能、機能ユニット配置場所の自動微調整機能などがあるとダイアグラミングの作業効率が大きく向上する。

（２）ビジュアライズ機能
プロセスモデルの処理シークエンスを順番に表示していく機能など、ディジタルな状態で設定された情報を、より見やすい形でプレゼンテーションする機能である。また、シンボル表示の要否、組織名表示の要否、プロセス・モデルの組織別層化表示など、ダイアグラム表示における様々なオプションのオフ・オンを制御する。このような機能は、「味気ない」ダイアグラムの表現力向上に、大きな役割を果たす。

（３）相互フィードバック機構
あるダイアグラムで他のダイアグラムへ影響をおよぼすような改訂を加えた場合は、自動的、あるいは半自動的に他のモデル（ダイアグラム）へ反映する機能である。たとえば、機能モデルで、ある機能ユニットの名称を変えた場合は、この機能ユニットを用いて作成されているプロセスモデル上の機能ユニット名を自動的に変更する。

（４）情報参照機能
機能ユニットモデルは、複数のモデルが一体となって作成されるものであり、それぞれの機能ユニットは複数のプロセスモデルで利用される。また、一つ一つの機能ユニットは、その名称、ＩＤ番号、処理に要する時間・コストなど豊富な属性情報を持っている。したがって、たとえばある特定のユニットの内容がどうなっているか、あるいは、その機能ユニットがどのように他のダイアグラムで使われているかなどを、ダイナミックに参照する機能である。おもな具体例としては、下記のようなものが挙げられる。

たとえば、機能モデルにおいて、特定の機能ユニットを画面上でポイントし、その属性情報を参照し更新する。また、機能モデルにおいて、その機能ユニットを使って作成されているプロセスモデルのダイアグラム一覧を表示する。さらに、そのプロセスモデルを呼び出して表示する。

また、業務イベント一覧表の該当行から、プロセスモデルのダイアグラムを呼び出す。また、プロセスモデルから業務イベント一覧表を呼び出す。また、プロセスモデルにおいて、特定の機能ユニットをポイントし、機能モデルで定義された機能ユニットの詳細な情報を参照する。また、組織モデルにおいて特定の部署をポイントし、その部署が担っている機能（機能ユニット）の一覧を表示する。また、ここから、機能ユニットの詳細を定義している機能モデルのシートを呼び出し表示する。さらに、機能モデル、プロセスモデル、組織モデルのそれぞれにおいて、上位のシート（全社的、あるいは広域的な組織体系を表現するシート）、下位のシート（具体的な部署を表現するシート）を相互に参照する。

（５）更新チェック機能
たとえば、機能モデルにおいて、特定の機能ユニットを削除しようとした場合、その機能ユニットがプロセスモデルですでに使われていたことを想定する。専用のソフトウエア・ツールがないと、このような不用意な削除を防ぐのは難しい。統合的なツールがあるとこのような違例なオペレーションに対して警告を発することができる。これ以外にも、同名ユニットに対する警告、ユニットの属性情報登録の際の必須項目チェック、他のダイアグラムで一切参照されていないユニットの存在に対する警告など、モデル全体に対する広域的なチェックなどをおこなうことができる。

（６）リポジトリーのエクスポート・インポート機能
このようにして作成されたモデル全体のリポジトリーは、システム開発用のリポジトリーとして継承したり、あるいは、ユニット一覧やダイアグラム一覧などの任意の情報再加工のために、ツールの外部に排出（エクスポート）できる。特に、近時、ソフトウエア開発用の統合リポジトリーの標準化が進められており、この標準リポジトリーの形式でデータを排出し、このデータファイルで設計情報の受け渡しをおこなう。さらに、一旦エクスポートしたファイルに対して、表計算ソフトウエアなどのＯＡソフトウエアを用いて各種の補足的情報を設定し、再度読み込み（インポート）をおこない、情報の更新をおこなえば作業効率が向上する。

このようなインポート機能は、モニタリングデータの読み込みにあたって、特に重要になる。モニタリングデータは時間やコストに関するデータであり、他システムやその他の方法で実測されたデータであり、処理時間やコスト（固定費用・変動費用）、組織情報（人員など）などが該当する。このようなデータを収集しモデルに反映させることは、ビジネスエンジニアリングを実現する上で不可欠であり、このような作業を継続的におこなう上で、システム的なプラットフォームを準備することは非常に重要なポイントになる。

（ソフトウエア・ツールの画面例）
図２〜図４は、機能ユニットモデルをベースとしたソフトウエア・ツールの具体的なイメージ、すなわちソフトウエア・ツールの画面例を示す説明図である。図２は機能モデル、図３はプロセスモデル、図４組織モデルの各モデリング・ツールの画面例である。

図２において、２０１は、表示画面２００の背景部でマウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。また、２０２は、表示画面２００上の説明ボックス２０３をポイントし、マウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。また、２０４は、画面上の機能ユニット２０５をポイントし、マウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。

図３において、３０１は、表示画面３００の背景部でマウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。また、３０２は、表示画面３００上の説明ボックス３０３をポイントし、マウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。また、３０４は、画面上の機能ユニット３０５をポイントし、マウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。

図４において、４０１は、表示画面４００の背景部でマウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。また、４０２は、表示画面４００上の組織名４０３をポイントし、マウス右ボタンをクリックした場合のプルダウン・メニューの例を示している。

このように、機能ユニットをベースにしたモデルは、機能モデル、プロセスモデル、組織モデルの３つのモデルから構成され、これらのモデルは相互に情報を共有して、フィードバックし合う関係にある。このような３つのモデルを齟齬なく維持するために、専用のソフトウエア・ツールを利用する。機能ユニットモデルの作成を支援するソフトウエア・ツールは、作成されたモデルの情報を統合的に管理するリポジトリーとともに、上記ダイアグラミング支援機能、ビジュアライズ機能、相互フィードバック機能、情報参照機能、更新チェック機能などを持つ。また、リポジトリーはエクスポート・インポートされることによって、システム開発作業への情報継承や、ビジネスエンジニアリングのための各種データの情報反映を容易にする。

（ハードウエア構成）
つぎに、上記ソフトウエアを実行するためのハードウエア構成について説明する。図５は、この発明の本実施の形態にかかるビジネスモデリング支援プログラムを実行するためのハードウエア構成を示すブロック図である。

このハードウエアは、ＣＰＵ５０１と、ＲＯＭ５０２と、ＲＡＭ５０３と、ＨＤＤ（ハードディスクドライブ）５０４と、ＨＤ（ハードディスク）５０５と、ＦＤＤ（フレキシブルディスクドライブ）５０６と、着脱可能な記録媒体の一例としてのＦＤ（フレキシブルディスク）５０７と、ディスプレイ５０８と、Ｉ／Ｆ（インタフェース）５０９と、キーボード５１０と、マウス５１１と、スキャナ５１２と、プリンタ５１３と、を備えている。そして、上記各構成部はバス５００によってそれぞれ接続されている。

ＣＰＵ５０１は、ハードウエア全体の制御を司る。ＲＯＭ５０２は、ブートプログラムなどのプログラムを記憶している。ＲＡＭ５０３は、ＣＰＵ５０１のワークエリアとして使用される。ＨＤＤ５０４は、ＣＰＵ５０１の制御にしたがってＨＤ５０５に対するデータのリード／ライトを制御する。ＨＤ５０５は、ＨＤＤ５０４の制御で書き込まれたデータを記憶する。

ＦＤＤ５０６は、ＣＰＵ５０１の制御にしたがってＦＤ５０７に対するデータのリード／ライトを制御する。ＦＤ５０７は、ＦＤＤ５０６の制御で書き込まれたデータを記憶したり、ＦＤ５０７に記録されたデータを情報処理装置へ読み取らせたりする。着脱可能な記録媒体として、ＦＤ５０７のほか、ＣＤ−ＲＯＭ（ＣＤ−Ｒ、ＣＤ−ＲＷ）、ＭＯ、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｋ）、メモリーカードなどであってもよい。ディスプレイ５０８は、カーソル、アイコンあるいはツールボックスをはじめ、文書、画像、機能情報などのデータを表示する。たとえば、ＣＲＴ、ＴＦＴ液晶ディスプレイ、プラズマディスプレイなどである。

Ｉ／Ｆ（インタフェース）５０９は、通信回線を通じてネットワーク５５０に接続され、ネットワーク５５０を介して、グループ企業内の各種データベース等に接続される。そして、Ｉ／Ｆ５０９は、ネットワーク５５０と装置内部とのインタフェースを司り、前記各種データベース等からのデータの入出力を制御する。Ｉ／Ｆ５０９は、たとえばモデムやＬＡＮアダプタなどである。

キーボード５１０は、文字、数字、各種指示などの入力のためのキーを備え、データの入力をおこなう。タッチパネル式の入力パッドやテンキーなどであってもよい。マウス５１１は、カーソルの移動や範囲選択、あるいはウインドウの移動やサイズの変更などをおこなう。ポインティングデバイスとして同様の機能を備えるものであれば、トラックボール、ジョイスティック、十字キー、ジョグダイヤルなどであってもよい。

スキャナ５１２は、画像を光学的に読み取り、情報処理装置内に画像データを取り込む。スキャナ５１２は、ＯＣＲやＯＭＲ機能を備えていてもよい。また、プリンタ５１３は、画像データや文書データを印刷する。たとえば、レーザプリンタ、インクジェットプリンタなどである。

（機能モデルの作成）
つぎに、機能モデルと機能ユニットの抽出について、その考え方と表記法について説明する。企業活動から「機能」を抽出する手順として、もっともわかりやすいのは、まずその会社の組織図を取り出して、その部課名や組織規程などをたよりに「機能」を抽出していくことである。この作業によってマクロ的な機能モデルの暫定版を作成する。大企業であれば、多くの部課が存在するが、一般に大企業は組織ごとに職掌が細分化されていて、それぞれの部課が固有の機能を発揮しており、それらがそれぞれに企業活動の中で無視できない影響力を行使している場合が多い。

一方で小企業の組織図というのは通常シンプルなものであり、各部署の機能も明確に分化されていない場合が多い。たとえば経営者自身が商品開発機能や営業機能を担っている場合などである。したがって、複雑な組織図を持つ大企業はマクロレベルの段階ですでに数多くの機能ユニットが登場するが、小企業では機能が明確に分化されていない以上、少なくとも最初の全社的なマクロ・ダイアグラムの段階では比較的少数の機能ユニットしか存在しないというのは、実態に即したモデル形態ということができる。

つぎに、企業の機能を考える場合、純粋に機能とはいえないが、機能を表現する場合に欠かすことのできない「機能の操作対象」ともいうべきものが存在する。これらの操作対象物は、機能を軸に企業活動を分解していく上で、副次的に定義されていくものであるが、一方で、企業の活動を表現していく上で欠かせない存在でもある。具体的な代表例は、商品、原材料、財務諸表、各種の帳簿・帳票類やデータなどである。これらは通常「目に見えるもの」である場合が多く、抽出は比較的容易である。

また、このような「機能の操作対象」が存在するということは、それを主体的に操作する「機能の主体」が存在するということでもあり、「機能の操作対象」から対比的に「機能」を抽出することもできる。これら機能の操作対象物は、それぞれの機能ユニットに内包されていると考えるべきものと、マクロ的なレベルの段階から独立して存在しているものと考えるべきものが存在する。

「商品」や「顧客」「原材料」はマクロ段階から独立して存在すると考えるべき重要な存在であるが、各種の「帳簿」「伝票類」や「データ（ファイル）」などは、下位の機能ユニットに内包されるものと考えた方が整理しやすい。

また、昨今は、企業活動における様々な分野に、コンピュータシステムやメカトロニクスが浸透して、人間の手作業が企業の現場から排除されつつある。しかしながら、機械やコンピュータシステムが担っている機能も、企業活動を支える「機能」であることに変わりはない。経理事務に関する作業がすべてシステム化されていても、あるいは生産ラインがすべてロボットによって自動化されていても、あるいは商品出荷時の仕分け作業が各種のセンサーとベルトコンベアによって自動化されていたとしても、それは「機能」であることは違いなく、これらも人間がおこなっている作業と同じように機能部品の一つとして抽出する。

また、企業の組織図は、企業内部の組織構造を表すものであり、企業の外部にある存在を表記するものではない。一方で、企業の活動を考える上で、企業の外に存在する機能を見逃すことはできない。企業は、本来、自己完結するものではなく、外部と何らかの関係を持ちながら活動している。このような意味からも、外部にある機能は無視することができない。外部に存在するものの代表例は、顧客（販売先）、仕入先、株主などである。また、本来企業内部で持つべき機能をアウトソーシングしている場合なども機能の抽出対象になる。経理業務や給与計算の委託先、生産委託先、法務機能（顧問弁護士）などがその例に該当する。

以上のような手がかりをもとに、暫定的な機能モデルの骨子を作成する。この最初の機能モデルは、もっともマクロ的であり、以後の機能モデルのベースとなる。最初の段階のユニットには、まだ位置づけがはっきりしないものも含まれている。そこで、つぎのステップは、これらの仮にプロットされた最上位のユニット群の妥当性を検証するために、もう一段細かいレベルで、それぞれのユニットの意味と位置づけを検証する。

（機能ユニットの階層的展開）
機能ユニットを抽出し機能モデルを作成していく上で、その重要なポイントの一つに階層化がある。企業には、大小様々な「機能」や「機能の操作対象物」が存在し、それぞれの重要性や概念的サイズは様々である。これら大小様々なユニットを、わかりやすく整理していくためには、マクロ的なレベルからミクロ的なレベルまで、それぞれのレベルで「大きさ」をそろえながら、階層的に整理していくことが有効である。

たとえば、「営業」というユニットは、「経営」や「人事」「経理」とならんで最上位のもっとも基本的なレベル（「第一レベル」）にあるとする。一方で、単に「営業」ユニットというだけでは、その定義が曖昧であり、そこに内包されている様々な機能・プロセスを表現しきっているとはいえない。そこで、図６に示すように、「営業」ユニットを分解し、その中にある「契約」機能をユニットとして切り出し（第二レベル）、さらにその内容を再分解（第三レベル）している。図６は、ユニットの階層的詳細化を示す説明図である。

このように、企業のビジネスモデルを表現するために、その企業の機能的構成要素たる機能ユニットをダイアグラム上で展開する際に、（画面上で特定の機能ユニットをクリックすることによって）「俯瞰的・マクロ的なレベル」から、「現場レベルの具体的なレベル」と自動的に遷移・展開することができる。また、逆に、「現場レベルの具体的なレベル」から、「俯瞰的・マクロ的なレベル」へと（下位レベルから上位レベルへと）動的に展開することができる。

これによって、従来、企業活動をダイアグラムで表記する際は、「俯瞰的・マクロ的なレベル」「現場レベルの具体的なレベル」など、そのレベルごとに個別に独立して作成され、それらが相互に構造的に関係付けられることはなかったものを、企業を構成する機能的構成要素（機能ユニット）を表記し検討する際、ダイアグラム上に列挙されたユニットを、画面からクリックすることによって、そのユニットの機能的内部構造を階層的に（フラクタルに）表示することができる。

また、特定階層（ｎ次階層）のダイアグラム上から（背景部におけるプルダウンメニュー等を用いて）、上位階層のダイアグラムへ遷移し、これを表示する。また、ダイアグラム上で、特定のユニットに関する部分のみを詳細に展開し、特定分野のみの機能構造を表示することを可能にする。これによって、同一平面上で一部のみズームアップされたダイアグラムが、他のマクロなユニット群と混在した形で表示される。

（「分類」と「固有名詞」の表現方法）
つぎに、機能モデルの中で、水平的な「分類」や「固有名詞」の表現の方法の一例について説明する。具体例として、損害保険の例を示して説明する。損害保険会社は自動車保険や傷害保険、火災保険など広い範囲の保険商品を扱っている。自家用車の任意保険と、空港の自動発行機などで販売される短期海外旅行保険ではその販売方法が大きく異なっている。

自動車保険は通常保険代理店を経由して販売されるが、自動発行型の短期海外旅行保険は、その名の通り自動販売機を用いて販売される。損害保険会社にとって同じ損害保険という商品を扱いながら、販売のプロセスが大きく異なるのである。また自動車用の任意保険も保険代理店以外に、インターネットやテレフォンセンターなどを通じて販売することも一般的になってきている。

このように、同じ損害保険商品でありながら、販売プロセスの違いを表現するために、販売チャネルのバリエーションをもとにした商品の「分類」が必要になる。一方で、その商品が傷害保険であるか自動車保険であるかによって、事故処理などの扱いが大きく異なってくる。事故処理という局面では、インターネットで販売されようが、自動車ディーラー経由で販売しようが基本的には対処手順は同一であり、むしろその保険の対象物（自動車事故、人身傷害、火災など）がもっとも重要な「分類」となる。

このように、損害保険にとっての商品の分類は、保険の種類、販売チャネル、その他販売可能な顧客の種別（法人のみ・個人のみ・法人個人共可能）など様々な商品サービスの分類が必要になる。

図７は、損害保険の分類例を示す説明図である。また図８は、損害保険商品の階層化を示す説明図である。また図９は、損害保険商品のダイアグラム化を示す説明図である。図７において、損害保険会社における商品が、４つであると考えた場合、商品は図８に示すように「商品」と「具体的商品」の２階層で表現できる。これを機能モデルの表記法で表現したのが図９である。

図８に示した図は、階層化の例で表現した階層的・垂直的な機能のブレイクダウンを表したものというよりは、そのカテゴリーに含まれる具体的な「もの」を水平的に列挙したものということができる。この場合、この「具体的な商品名」に相当するものを「具象名」と呼称し、各ユニットの右肩部に表示された具象名が記されたラベルを「具象名ラベル」、また、このような具象名ラベルが付されたユニットを「具象ユニット」と呼称する。

このような「具象名」は、個別の商品名や顧客名などを表記する際に利用されるが、個別の商品名・顧客名以外に「分類」や「カテゴリー」の表記の際にも利用される。保険商品の例でいえば、「一般任意自動車保険」、「インターネット専用自動車保険」、「自動機専用短期旅行傷害保険」、「一般傷害保険」などの具体的商品名（固有名詞）だけでなく、これらを分類するためのユニットである「自動車保険」、「傷害保険」などの分類・グループを表現する名称も「具象名」としてダイアグラム上に付記することができる。

以上説明したように、企業を表現するダイアグラムで、個別的な存在（固有名詞を持った存在、特定のグループ・カテゴリーに属する存在）を表現することができる。すなわち、企業のビジネスモデルを表すダイアグラム、あるいは業務処理フローチャートで、特定の顧客、特定の商品、特定の社員など「固有名詞」を持った存在を表現し、また、その特徴を表現するアイコンを付記し、表現力を高めることができる。

従来は、企業活動を表す上で、特定の顧客、特定の商品、特定の社員、ないしはそのカテゴリー・グループを表現する場合、たとえば、特定の顧客のための特殊な処理、特定の商品に関する特殊な販売手続き、特定の社員のみが許されている行為などを表現する場合、このような「固有名詞」を持った存在、あるいは特定のカテゴリー・グループを表現することができなかった。また、このような特殊な存在や特殊なカテゴリー・グループをダイアグラム上で表現する際は、その特殊性や性質をわかりやすく表示する（際立たせて表示する）ことが重要になるが、このための手法や技術も存在していない。

そこで、企業活動を表現する際、そこに登場する特定の顧客、特定の商品、特定の社員、ないしはそのカテゴリー・グループ（具象ユニット）を表示する。具象ユニットを定義する際に、以下の属性を別途あらかじめ定義して登録しておき、その具象ユニットが持つ「名称」（固有名詞、またはグループ名・カテゴリー名）や、その具象ユニットの性質をシンボリックに表現するためのシンボル（アイコン）を、ダイアグラム上で表示する際に、あらかじめ登録された上記属性をもとに、アイコンを付して表示する。

（機能モデルの表記法）
図１０は、機能モデルのシートの一例を示す説明図である。図１０において、それぞれのシート１０００は表題部１００１を持ち、同時に実際に機能ユニットを配置・描画する描画エリアを持つ。この描画エリアをダイアグラム・エリア１００２とする。機能モデルのシート１０００の表題部１００１には、（機能）ユニット番号１００３と（機能）ユニット名１００４とを記載する。

（機能）ユニット番号１００３は、それぞれの機能ユニットに与えられる固有の番号である。この番号を持って、一つの機能ユニットを特定できる。番号体系は、「（上位ユニットの番号．）ユニット番号（連番）」である。したがって、上位ユニットの番号が「１」であれば「１．ｎ」（ｎ：１，２，３，・・・）になる。具体的には「１．５」などになる。また、上位ユニットの番号が「１．５」であれば「１．５．３」などになる。このような番号体系により、そのユニットの番号を見れば、どの機能ユニットに属するユニットであるか（どのユニット・ファミリーに属するか）、あるいはその機能ユニットの階層の深さがわかることになる。

内部領域１００５は、上位の機能ユニットの内部構造を部品分解したユニットを配置する領域である。この場合、この領域は上位のユニットの「解剖図」のような位置づけになる。また、ユニット外領域１００６、企業外領域１００７は、内部領域１００５のユニットの位置づけを明確化する上で必要となる、その他のユニットを配置する領域である。一般に、機能モデルを階層的に展開する上で、上位ユニットに直接的に含まれるファミリー・ユニットのみを内部領域１００５内に記載すればよいようにも思えるが、各ユニットの意味や位置づけを明確化するためには、企業外領域１００７とユニット外領域１００６との関係も重要な意味を持つ。なぜならば、それぞれの機能ユニットは、他の機能ユニットとの関係の中でその意味や位置づけが明確化される場合が多く、それは同一カテゴリー内だけではなく、異なる領域の機能ユニットとの関係の中でより明確になる場合も少なからずあるためである。

（機能ユニットの種類）
機能ユニットには２種類のユニットが存在する。一つは「機能の主体」となるユニット（円で示す）であり、もう一つは「機能の操作対象」となるユニット（八角形で示す）である。そして、プロセスモデルや機能モデルをより直感的に理解しやすくするために、機能ユニットの表記にあたっては、その機能の「実現手段」をシンボルとして付記することとしている。実現手段に関するシンボルは、ユニットの下部に補足的に表記する。

図１１−１および図１１−２は、シンボルの種類を示す説明図である。これらはいずれも一例であって、各業種・業態によってまったく使用しないシンボルもあるだろうし、また逆に、より細分化されたシンボルを設定する必要がある場合も考えられる。そのような場合は、適宜必要なシンボルを追加的に作成してダイアグラムを作図すればよい。このような機能ユニットに付されるシンボルは、いずれもそれぞれのユニットの機能遂行手段を視覚的にわかりやすくするための「形容詞」であって、必ずしも必須のものではない。しかし、このようなシンボルを付すと、機能ユニットやダイアグラムが表現している業務の流れが一目瞭然となり、業務の実態を容易に連想することができるようになる。

また、このシンボルは、必ずしも「機能遂行手段」だけでなく、そのユニットの意味や内容を補足するための手段として活用することも可能である。たとえば、図１１−２における「３．１」、「３．２」に示す通りである。このようなシンボルは「機能主体のユニット」というよりは、一般に「操作対象のユニット」で活用されるが、これによって、ダイアグラムの表現力・説明力が大きく向上する。

これによって、従来、企業を構成する機能的構成要素群を表記する際、単にその「機能の名称」を表記するだけで、その機能の「実現手段」、あるいはその機能や存在の「性質」「特徴」等を表現するための付加的な配慮・工夫がなされることはなかった（そもそも、企業のビジネスモデルを、静的な側面から表現するための方法論が存在しなかった）ものを、ダイアグラム上で企業のビジネスモデルを表現する際に、その機能構成要素、または存在（すなわち機能ユニット）ごとにこれらの「実現手段」、「性質」、「特徴」などを表現するアイコンを付することによって、モデルの表意性、表現力を大幅に高めることができるようになる。

このアイコンは、ダイアグラムの作成者が、対象企業の業界・業種の特性、または分析の対象領域の特性などを勘案し、自由に準備することができる。また、このアイコンは、準備された「アイコン一覧」からもっとも適合するものを選択し、ユニットの一属性として定義づけるようにしてもよい。たとえば、物品を「搬送・配送する」際に自動車を用いる場合、「搬送・配送」ユニットには、図１１−１の「１．１０」の自動車のアイコンを属性として定義づけることができる。また、このアイコンをユニットの一属性として定義づける場合に、優先表示するか否かを設定することができる。たとえば、この配送手段の検討が、ビジネス表現の上で重要な意味を持つ場合は、「優先表示」を「ＯＮ」にし、あまり問題とされない場合は「ＯＦＦ」とする。

また、このアイコンを、ダイアグラム上で表示する際は、「アイコンをユニットごとに付記表示するか否か」を決定するオプションを設けておき、これを「ＯＮ」にすると、ダイアグラムでアイコンが表示される。また、「優先表示のみＯＮ」を設定すると、優先表示指定がなされたもののみを表示させる（強調したいアイコンのみを表示する）ことにより、ダイアグラムの見た目上の複雑化を回避することができる。

（機能ユニットの内部構造）
機能ユニットを定義していく上で、どのようなことを分析し、どのようなことを記録していけばよいのかについて説明する。図１２−１および図１２−２は、機能ユニットの内部構造を示す説明図である。

（１）ユニット番号には、機能ユニットに与えられる固有の番号を記載する。この番号を持って、一つの機能ユニットを特定できる。

（２）ユニット名には、文字通り機能ユニットに与えられる「名称」を記載する。

（３）ユニット種別には、「機能主体ユニット」であるか「操作対象ユニット」であるかの種別を登録（記載）する。「機能主体ユニット」であるか「操作対象ユニット」は直感的に自明であるかのように思われるが、中間的なユニットが多く存在する。したがって、このユニット種別の決定は、分析者が「わかりやすさ」という観点を軸に主観的に決定することになる。

（４）概要説明には、機能ユニットの内容についての述語的な説明を記載する。

（５）内外区分には、その機能ユニットが企業の「外部」に存在するものか、企業の「内部」に存在するかの区分を設定（記載）する。顧客や株主など本来的に外部に存在するもの、あるいはアウトソーシングしている機能、外部委託している機能は「外部」として登録する。

（６）シンボル種別には、その機能ユニットにおける機能の遂行手段・実現手段などを表現するためのシンボル（アイコン）の種類を設定（記載）する。所定の選択肢から設定される。通常「手作業」、「コンピュータシステム」、「トラック配送」などのシンボルが用意されるが、所定・既定のシンボル以外に、分析の対象範囲・対象領域、企業の業種・業態によって固有のシンボルを自由に追加すればよい。

（７）機能リストには、その機能ユニットが包含する詳細機能の一覧を記載する。この機能リストは所定の表形式のデータ（機能番号、機能名称、機能概要説明、メッセージコンテンツ、シンボル種別、処理時間、処理コスト）として定義される。

（８）データリストには、ユニットが保持するデータの一覧を記載する。機能ユニットは、固有のデータ群を保持する場合がある。「在庫管理台帳」というユニットがあった場合に、この「在庫管理台帳」は商品の在庫明細を管理する台帳であり、商品の在庫の明細を管理するためには、その商品の商品番号、個数（在庫量）、在庫場所、入庫日時などが必要であるとする。この場合、「在庫管理台帳」はその役割を全うするために、上記のようなデータを「自らのデータ」として、管理保持する必要がある。このようなデータは、特に「機能主体ユニット」よりも「操作対象ユニット」で重視され、かつ、このユニットがコンピュータシステムの構成要素として展開される場合に重要になる。

（９）対応組織リストには、ユニットの機能を担う組織のリストを記載する。機能ユニットにおける、この「対応組織リスト」は、抽象的なものとして切り出された「機能」が、現実の企業内のどの組織によって担われているかということを示すとともに、ＢＰＲやビジネスモデルの転換に際して、新たにどのような組織の改変をおこなうべきかということを検討する材料になる。

（１０）関係線リストには、機能モデル上の関係線情報を記載する。機能モデルでは、ユニット間の関係を方向つきの「関係線」で表現し、その関係の説明を「説明ボックス」で表現する。関係線リストは、この「関係線」と「説明ボックス」の情報を収納する場所であり、機能モデル上で視覚的に描画された情報が、ディジタルな情報として整理され収納される場所である。「関連先」（関係線の接続先）と「説明ボックス」の記載内容がリスト構造で表現される。

（１１）具象名には、具象ユニットの場合の具象名を記載する。本項に何らかの値をセットすると、自動的に本ユニットが具象ユニットと判断され、ダイアグラム上に「具象名」が表示されるとともに、この具象ユニットは複数のシートに属し得る性質を持つことになる。

（１２）従属ユニットリストは、具象ユニットの親ユニットのリストである。具象ユニットは、複数のシートに表記することができる。すなわち、複数の親ユニットを持つことができる。本項目は、具象ユニットの親ユニット群のリストを格納する項目である。

（１３）処理時間には、この機能を一回遂行するために要する処理時間を記載する。この情報はおもにプロセスモデルにおいて利用される。プロセスモデルは特定のビジネスイベントごとに、その業務の流れを「機能ユニットの連鎖」という形式で表現するが、この機能ユニット、または機能ユニット内部の詳細機能の一つ一つに与えられた「処理時間」を累積することで、このイベント全体に要する処理時間を算定することができる。

なお、この処理時間は、直接的に処理遂行に要する時間と、業務の現場における「滞留・遅延時間」の両者を登録する。後者の滞留・遅延時間は一連の処理が完了するまでのトータルな「ターンアラウンド時間」を計測する際に使用する。また、プロセスモデルでは、顧客などのイベントの起動元（リクエスター）に対する応答時間（レスポンス時間）なども測定が可能である。

（１４）処理コストには、機能を遂行するために要する「費用」を登録（記載）する。ここで設定するコストは、材料費、人件費、各種の機器類、およびコンピュータの経費などの物件費、その他の事務処理経費などである。また、このコストは「本社間接経費」などの「間接的固定費」と、上記以外の「変動費」や「直接コストとしての固定費」とに分けて登録する。このように分類して登録するのは、ビジネスイベントごとのコスト構造を分析する際に、見直しの余地が少ない（と一般的に考えられる）間接固定費と、直接的な見直しの対象となる直接的固定費と変動費用を分別して登録し、検討と分析の精緻化をはかるためである。

なお、この「処理コスト」と「処理時間」はいずれも、ある程度具体化された（機能モデル上の階層でいうと下位層の）機能ユニットでないと意味をなさない場合が多い。たとば、機能モデルで「経理」ユニットがあったとして、この「経理」ユニットに要する「処理時間」と「処理コスト」を設定しようとしても、「経理」ユニット自体が概念的に過ぎて意味をなさない。「経理」ユニットをブレイクダウンした「売上記帳」ユニットというものがあれば、これに要する「処理時間」と「処理コスト」は設定することができるようになる。

（業務イベントの抽出）
つぎに、業務イベントの抽出の手順について説明する。業務イベントの抽出をおこなう場合、二通りのアプローチが存在する。一つは、特定分野のワークフローの再構築や、特定分野におけるコンピュータシステムの構築など、ある明確な目的を持って、その目的に関係のある領域や業務フローを考える場合である。この場合は、抽出すべき業務イベントはある程度明確であり、所与のものである場合も多い。

たとえば、新しいコンピュータシステムを構築する場合は、その構築によって影響を受ける分野や部署は比較的明確であり、「どの業務フローを見直さなくてはならないか」は自明な場合が多い。特定業務のアウトソーシングなども、分析対象となる業務フローや業務分野はおおむね「当たりがついている」場合が一般的である。このような場合は、抽出するイベントは「目的にそった」イベントを抽出していけばよい。

もう一つの場合は、企業活動の全域にわたって業務イベントを抽出する場合である。この場合は、全社的にＢＰＭの体制を確立する場合が典型例であるが、「問題の所在」が不明確な場合なども該当する。後者のケースというのは「ライバル企業に較べて生産性が悪い」、「企業に活力がない」、「忙しい割りに成果が出ない」などの漠然とした問題を抱えている場合である。このような場合は、改善すべき「業務イベント」が特定されず、問題の所在がどこにあるのかがわからない場合である。このような全社的な業務イベントの抽出の手順は以下のようになる。

（１）分析対象とする「組織」を選び出す。
全社の各組織にわたって、一律に業務イベントを抽出するのが基本であるが、同様な性質を持っている支店や営業所が複数ある場合などは、ここから分析対象となる組織・部署をサンプリングして分析の対象を特定する。
（２）組織内の「業務イベント」を一覧表で整理する。
分析する対象組織を特定したら、その組織の中で「やっていること」を整理し表にまとめる。これが業務イベント一覧の作成である。表の形式は、たとえば図１３に示したようなものになる。図１３は、「業務イベント一覧表」のフォーマットの一例を示す説明図である。

業務イベントは、その組織、あるいは組織の従業員がおこなっている「作業」のすべてを網羅するように抽出していく。特に組織の効率化を考える場合、「無駄なことをしていないか」、「非生産的な活動を必要以上にやっていないか」という観点が重要になるため、「漏れなく抽出する」というのは重要である。組織の効率化や活性化を目的とする場合、この「業務イベント一覧」を作成するだけで、目的を達成する場合がある。業務イベント一覧表を作って、その組織が「どの業務についてどれだけの経営資源を投入しているか」のあらかたが掴めれば、それだけで改善すべき点が浮き彫りになることがあるためである。

（業務イベント一覧表）
図１３において、
（１）組織名には、この業務イベント一覧表の対象となる具体的な組織の名称を記載する。全社ベースのイベント一覧表を作成する場合は「全社」と記載する。

（２）イベント番号には、業務イベントを特定するための番号を記載する。

（３）イベント名には、この業務イベントの名称を記載する。このイベント名の記載は実質的な「イベントの抽出と分類」の作業を意味する。

（４）イベント説明には、この業務イベントに関する説明を記載する。このイベント説明は、特に第三者への説明をおこなうために記載されるものである。表面的な説明以外に、このイベントの特性や重要性、特異性など、時間やコストなどのディジタルな情報だけでは伝えきれない補足的説明をおこなう。

（５）起動元には、この業務イベント開始の「指示者」（リクエスター）や「契機」「きっかけ」を記載する。一般に業務イベントは、外部からの要請・指示等によって開始されるものと自発的に開始されるものがある。自発的に開始されるものは、時間・時限の到来によって開始されるものと純粋に自発的に開始する場合がある。

第三者からの指示によって開始されるイベントは、顧客、取引先、企業内の関連部署、上司などの指示・要請などによって開始されるものである。「顧客からの注文・クレーム・問合せ」「営業部門からの在庫問合せ」などが該当する。時間や時限の到来によって起動されるイベントは、定期的ルーチンワークに相当するものである。毎日定時におこなわれるもの、一週間の中で特定の曜日、時間に開始されるもの、月末作業、期末作業などがある。純粋に自発的判断によって開始される行為は不定期におこなわれ、通常、経営層・管理職など「指示を出す側」に多く見られる。

（６）起動タイミングは、前項の「起動元」に付随する項目である。起動元が第三者や自身にあるときは、通常「随時」となるが、時間起動型のイベントはその開始時間・時限を記載する。

（７）起動頻度には、この業務イベントが起動され実行される頻度を記載する。頻度の計測単位は、「一日当たり」でも「一週間」でも「一年」でも構わない。この頻度と計測単位を一緒に「３回／日」のように記載する。

（８）ターンアラウンド時間（モデル値、実測値）には、この業務イベントが開始され完了するまでの全体的な所要時間を記入する。このターンアラウンド時間は、この業務イベントの処理のために直接的に投入された時間ではなく、イベントが起動されてから結果を得るまでのトータルな所要時間である。

たとえば、顧客宛の提案書や見積書の作成に直接的に要した時間が実質「４時間」だったとしても、結果的にその提案書や見積書について内部的な承認を得るために「３日間」要した場合、この項目には「３日間」の方を記載する。「モデル値」には、プロセスモデル上のシミュレーションから導き出された時間を転記し、「実測値」には実務の中でモニタリングされた値を記載する。したがって、この「ターンアラウンド時間」における「モデル値」「実測値」は次項の「レスポンス時間」と「処理コスト」「処理時間」と同様に、通常、この業務イベント一覧表の作成の段階では空欄となっている。

（９）レスポンス時間（モデル値、実測値）には、顧客などのリクエスター（イベントの起動元）に対する、レスポンス時間を登録（記載）する。レスポンス時間は、リクエスターからの指示・要請を受けてから回答を返すまでの時間である。

（１０）処理時間および処理コスト（モデル値、実測値）には、この業務イベントを一回処理するために要する時間とコストを記載する。処理時間には、各業務イベントを処理するために「直接的に要した時間」を記載し、処理コストも同様に、本社経費などの間接的な固定費は通常対象外とする。

（１１）処理時間および処理コスト（比率）には、この業務イベントに要する「処理時間」と「処理コスト」のそれぞれについて、全体から見た「割合」を算出し、記載する。この項目は自動的に計算される項目である。この「比率」は、各セクションごとに合計は１００％となり、時間とコストの計算にあたっては、「一回当たりの時間・コスト」×「起動頻度（発生頻度）」で計算される。すなわち、この処理コストと処理時間に関する「比率」は、その部署で遂行されている様々な業務・作業に対する「経営資源の投入割合」を示す指標となる。

（プロセスモデルの作成）
つぎに、実際のプロセスモデルを作成する。具体例として、新たにコンピュータシステムを構築し、従来ＦＡＸで受け付けていた受注明細を、インターネットサイト上で受け付けるというＢＰＲプランを考えたとして、このダイアグラムを作成する。最適化された「あるべき姿」を模索していく際には、まず現状（「今はどうやっているか」）を分析するというアプローチをとる。

新しい商品や業務処理を一から考え出していく場合は、この現状分析は必ずしも必要とはされないが、通常は「現状の姿」があって、つぎなる「新しいあるべき姿」を対比的に描き出していくというステップが欠かせない。この新旧比較によって、現状との差分を明示的にあぶり出し、また、時間的・コスト的な改善の度合いを導き出すことができる。

図１４は、「受注」プロセスモデル（現状を表したもの）を示す説明図である。図１４に示すように、このプロセスモデルは、顧客からの商品発注を受けた営業部、および配送部、経理部の現状の一連の動きを描いたものである。このダイアグラムは、イベント一覧表における「受注」イベントの具体的な動きざまを表現したものであり、イベント一覧表からは得られなかった具体的な業務の手順やプロセスの様態が表現されている。

ここで、業務処理フローをダイアグラム上で表現するために、その「処理要素」ごとにアイコンを付記することによってダイアグラムの表現力・説明力を向上させることができる。

従来、業務処理フローを表現する際、フローチャート記号等、処理内容を表記するための「シンボルそのものが処理方法を表す」方法がとられており、表記ルールそのものに大きな制約を受ける場合が多かった。これにより、たとえば「大型トラックで搬送する場合、軽トラックで搬送する場合」の描き分け、「大型汎用コンピュータで処理する場合、ＰＣで処理する場合」、「専用線でデータを送信する場合、インターネットの公衆網で伝送する場合」などの描き分けがダイアグラム上でおこなず、業務処理フローの実質的・実務的な相違をダイアグラム上で「自由に」、「きめ細やかに」表現することができなかった。

そこで、ダイアグラム上で業務処理フローを表現する際に、その機能要素（処理ステップ、以下「ユニット」と称する）ごとに、その「実現手段」、「性質」、「特徴」等を表現するためのアイコンを付して要素・存在を表示する。このアイコンは、ダイアグラムの作成者が、対象企業の業界・業種の特性、または分析の対象領域の特性などを勘案し、自由に準備することができる。

また、このアイコンは、ユニットを定義する際に、準備された「アイコン一覧」からもっとも適合するものを選択し、ユニットの一属性として定義づける。たとえば、図１４に示すように、物品を搬送・配送する際に自動車を用いる場合、「搬送・配送」ユニットには、「自動車のアイコン」（あるいは大型トラックのアイコン、または軽トラックのアイコン）を属性として定義づけることができる。

また、このアイコンは、ユニット間の「メッセージング機能」（ユニットからユニットへの指示・情報連携・連鎖）を表す「メッセージボックス」にも一属性として定義づけることができる。この際の定義づけは、ユニットを定義する際に、その内部属性である「（メッセージング）機能」への属性定義としてなされる。これによって機能ユニットから機能ユニットへの連鎖の方法に関する実現手段（電話、ファクシミリ、手渡し、コンピュータシステムによる指示・情報連携など）が表現されることになる。

また、このアイコンをユニットの一属性、または機能の一属性として定義づける場合に、「優先表示するか否か」を設定することができる。この「配送手段の検討」が、ビジネス表現の上で重要な意味を持つ場合（ＢＰＲ検討の上で重要な意味を持つ場合等）は、「優先表示」を「ＯＮ」にし、あまり問題とされない場合は「ＯＦＦ」とすることができる。このような機能によって、たとえば「配車計画」の作業を手作業からコンピュータシステムへ移行する場合に、「配車計画」ユニットを「手作業」のアイコンから「コンピュータシステム」のアイコンへ設定し直してこの変更を強調しながら、配送作業自体はトラックでおこなうことが自明な場合は、このアイコンは敢えて表示しないといったメリハリの利いた表意力の高いダイアグラムを作成することが可能になる。

また、このアイコンを、ダイアグラム上で表示する際は、「アイコンを付記表示するか否か」を決定するオプションを設けておき、これを「ＯＮ」にすると、ダイアグラムでアイコンが表示される。また、「優先表示のみＯＮ」を設定すると、優先表示指定がなされたもののみを表示させることにより、ダイアグラムの見た目上の複雑化を回避する。

また、イベント一覧表でとりまとめた「起動頻度」などの情報は、このプロセスモデルにも継承され、ダイアグラムの表題部に記載されている（図１５を参照。）。図１５は、プロセスモデルからイベント一覧表へのフィードバックを示す説明図である。また、イベント一覧表では空欄となっていた「処理コスト」と「処理時間」「ターンアラウンド時間」「レスポンス時間」のぞれぞれのモデル値は、このプロセスモデルでシミュレーションされた結果がイベント一覧表の欄にセットされることになる。

プロセスモデルの中核部はいうまでもなく、ダイアグラム・エリアに描かれるダイアグラムそのものである。このダイアグラムは、機能モデルで抽出された機能ユニットと、これを連鎖的につなぎ合わせてプロセスの順序を表現するための矢印（これを「連鎖線」と呼ぶ）からなる。さらに、この連鎖の内容や意味を補足するための説明ボックスを付するとともに、このプロセスモデルの中の順序を表記するためのシークエンス番号を付記する。なお、説明ボックス内には、連鎖の方向を表す矢印も記載する。

このシークエンス番号は、説明ボックスごとに付記され、１，２，３，・・・と連番で採番していくが、既述のように同時に複数の連鎖が並行的に発生する枝分れ処理の場合は、通常、１，２，３などと連番で採番するところを、ｎ−１，ｎ−２，ｎ−３，・・・（”−”はハイフンである。「２−１」，「２−２」，「２−３」など）とする。この並行処理は、たとえば「３つの部署に同時にＦＡＸを送付する」というような場合に利用する。また、「ｎ−１」から、さらに続けてシークエンス番号を採番する場合は、ｎ−１→１，２，３，・・・と採番する。

処理のシークエンスを表すためのもう一つの表記法として「｜」を用意している。これは「順序性・同期性の切れ目」を表すものである。作業プロセスは、遅滞なく連続的に実行される場合以外に、その途中に休止が発生するケースや、処理の対象物が一定数に達するまで、あるいは一定時刻になるまで意図的に待つケースがある。「｜」はこのような「一旦休止」「連続性の停止」を表すシンボルである。このような一度休止や停止を経たプロセスは、他の一連の業務処理とは異なる時間軸で後続の処理がなされる。

たとえば、「営業部から配送部に対して配送の指示をおこなう」と同時に「営業部は経理部に対して売上明細の連絡をおこなう」とする。この場合、連絡を受けた配送部と経理部はそれぞれ「商品の配送」と「勘定の計上」処理をおこなうが、この場合「配送部内の手続き」と「経理部内の手続き」は独立して（相互の連絡を取り合うこともなく）おこなわれるものとする。このような作業の流れを表す場合は、「配送部」内および「経理部」内の固有の手続きに対して「｜」を用いてシークエンス番号を分割し、それが「非同期で独立性の高い処理」であることを表す。

また、このような処理シークエンスの表現は、「静止画」上のシークエンス番号のみを用いて表現するだけでなく、専用ツールを用いてアニメーションのように処理の順番を表現すると、処理全体の流れが非常にわかりやすくなる。

従来、業務の処理順序を表現する際は、フローチャート、またはこれに類する方式で表現されており、業務処理の流れが複雑な場合（複雑な分岐・収束、ループ処理など）において特に、「（手で）線をなぞりながら」その「流れを目や手でトレースする」などの必要があり、処理の流れを直感的に理解するのは困難であった。

そこで、ダイアグラム上で業務処理のフローを表示する際に、その順序を表すシークエンス番号や、「処理要素」間をつなぐ「線」をもとに、その処理の流れをアニメーション的に表現する。この際、アニメーション表示は、「処理要素」間をつなぐ線を順次逐次的に強調することなどによって実現する。また、この場合の強調は、描線の色を変える、太線にするなどの方法によって実現する。また、このアニメーション化において、処理の分岐がある場合は強調線も分岐させる。また、このアニメーション化において、処理の待ち合わせ（収束）がある場合は、分岐された複数の強調線が収束点に到達するまで待ち合わせをおこない、その処理が待ち合わせを要する処理であることを表現する。

また、このアニメーション化において、「処理要素」ごとの処理所要時間を「処理要素」にあらかじめ登録しておくことによって、強調（アニメーション）線の描画スピードを制御し、処理全体のボトルネックやクリティカルポイントを直感的に理解できるようにする。また、この強調（アニメーション）線の描画スピードの制御方法を、オプションによって指定することで、「処理要素ごとの処理所要時間」の割合を正確に表示する（強調線の描線スピードを処理所要時間に比例させる）場合、あるいは、待ち合わせの順序のみがわかればよい場合（時間の費消割合をデフォルメする場合）などを制御することを可能とする。

プロセスモデルにおける連鎖線というのは、発信元のユニットから受取り側のユニットに対する何らかの働きかけであり、これは発信元ユニットに設定されている「機能」の一つである。したがって、プロセスモデルにおける説明ボックスは、「発信元ユニットの機能群から、機能を一つ選択して当てはめる」ということになる。図１４に示した営業ユニット（受注ユニット）と配送ユニット（配送受付ユニット）との関係を例に挙げると、図１６に示すように、営業ユニットからの「配送指示」というのは、営業ユニットの機能として抽出されている機能の一つ（厳密にいうと、「営業ユニット」または「営業ユニット配下のユニット」が持つ機能の一つから選択するということになる。）であり、このダイアグラムを作成していく中で、恣意的に記載されたものではない。図１６は、プロセスモデルにおける説明ボックスの内容を示す説明図である。

さらに、メッセージの受け手から見ても、このメッセージが到来することは予期されているものと考えねばならない。これは、図１７に示すように、配送部門にとっては、営業部門から配送指示が来ることは、業務的な機能の一環として「おりこみ済み」のはずであり、配送指示を受け取った場合のアクションも既定の手順があるはずだからである。したがって「配送指示（受付）」という機能は、「営業」ユニットのみならず「配送」ユニットにとっても、これに対応する機能が機能リストに存在していることになる。図１７は、受信ユニットにとっての説明ボックスの内容を示す説明図である。

上述のように、「起動ユニット」から「被起動ユニット」への連鎖線が引かれているということは、そこに「メッセージが発信されている」ことを意味している。このようなメッセージには、通常、様々な付帯情報（メッセージ・コンテンツ）が含まれている。たとえば、顧客から営業部署へ商品を発注する場合は、単に「発注する」と連絡するだけではなく、これと同時に発注する「商品の明細」を連絡しなくてはならない。具体的には、商品名、数量、納入場所、納入期限などである。

したがって、プロセスモデルにおける説明ボックスには、「機能名」以外にこのような「メッセージ・コンテンツ」が含まれていることになる。さらに、「起動ユニット」から「被起動ユニット」へのメッセージングが、単なる指示・命令に相当するものではなく、照会・問合せに相当するものであった場合を想定する。照会・問合せは、何らかの答えを求めて発行されるメッセージであり、「在庫状況の照会」などが典型例として挙げられる。「在庫状況の照会」の例を考えると、メッセージの発信元からは、商品名（商品コード）などが発行され、照会先からは、商品名（商品コード）、在庫場所、在庫数量などが回答されることになる。

この場合は、メッセージ発行元からメッセージ受信先へのメッセージ・コンテンツだけでなく、メッセージ受信先からメッセージ発行元への返信に関する「返信メッセージ・コンテンツ」が存在することになる。図１８は、説明ボックスにおけるメッセージ・コンテンツを示す説明図である。

図１８において、業務処理フロー、すなわち業務遂行プロセスをダイアグラム上で表現する際、画面表示時のオプションによって、そのダイアグラムが持つ詳細な関連情報を表示するか否かを制御することができる。

従来、業務処理フローには、時間、場所、処理遂行者、処理方法、伝達されるメッセージの内容など様々な情報が内包されていた。これらの情報は、本来、すべてフローダイアグラム上に表示すべきものであるが、利用者によってはそれらの情報を必要としない場合もあるし、また、必要以上の情報が表示されたダイアグラムは複雑で見にくいものとなる。これらの付属情報は、その表記ルールによって、「すべて出す」か「すべて出さないか」のいずれかの方式に固定されており、状況に応じてその表示・非表示を自由に設定されることはなかった。

そこで、ダイアグラム上で業務処理フローを表現する際に、その機能要素（ユニット）ごとに、処理遂行者（担当部署等）、処理方法、伝達されるメッセージの内容詳細などをあらかじめ登録する。また、特定の「業務処理フロー全体の情報」として、「ユニットの処理順序番号」、「処理全体の所要時間」、「処理全体の所要コスト」などの情報が存在し得る。

上記のような、業務処理フローのダイアグラムが持つ情報を、画面等に表示する際、表示オプションによって、「すべて表示する」「主要な（標準の）情報のみ表示する」「付属的な情報は一切表示しない」などの表示モードを制御することができる。

また、プロセスモデルは、実務的な業務の流れを具体的に表す必要があり、そういう意味でも第三者にとってのわかり易さや具体性が重要なポイントになってくる。このような観点から、プロセスモデルでは表現力の強化のため、追加的にいくつかのオプションを設けている。これが、シンボルの表記と部署名の併記である。図１９は、プロセスモデルにおける「シンボル」と「部署名」の付記の例を示す説明図である。

（１）シンボルの併記
機能モデルの定義の過程において、各ユニットおよびユニット内の機能には、その機能遂行手段を表すための「シンボル」を定義づけることができる。プロセスモデルにおいて、このシンボルを表記することは、ダイアグラムの表現力を増す上で非常に有効な手段となる。このシンボルを付すことで、その行為が「どのような方法・手段で遂行されているか」を直感的に理解できるからである。

このシンボルは、ユニットに併記すると同時に、説明ボックス（すなわち各ユニットの機能）にも併記することができる。なお、この場合も、プロセスモデル作成時に恣意的に付記するのではなく、機能モデルでユニットごと、あるいは機能ごとに設定されたシンボルをプロセスモデル上に記載していくことになる。

（２）部署名の併記
シンボルを併記するのと同じような意味で、部署名を記載することもプロセスモデルの表現力を増す意味で有効な手段となる。特に、現状の業務プロセスを分析する場合、部署名を付さないダイアグラムは、抽象的な印象があり、あまり現実味を感じることができず「たしかにこうやっている」という確信を持ちにくい。一方で、ダイアグラム上に部署名を付すると、機能を遂行している部署を具体的に思い浮かべながら、ダイアグラムを検討し検証することができるようになる。

（３）組織別の層化表記
さらに、ダイアグラム上に部署名を併記した場合、ダイアグラム全体を部署ごとに層化することにより、一層ダイアグラムを見やすくすることができる。なお、この場合、部署ごとの層化だけではなく、機能モデルではコンピュータシステムなども一つの部署として認識されるので、人間が行っている部分とコンピュータシステムなどで機械化されている部分が分別して表記されることになる。この部署別の層化を施して、書き直した例を図２０に示す。

図２０に示すように、業務処理フローをダイアグラム上で表現する際に、その処理フローのダイアグラムを、担当部署ごとに層化して動的に再表示することができる。

業務処理フローを作成する場合、その作成目的や参照目的によって「誰が（あるいは「どの部署が」）」その処理（ステップ）を担っているかが重要な意味を持つ場合があり、ダイアグラムそのものも、部署別に階層化して作成する場合がある。この場合の「部署」は、会社内部のいわゆる「部署」以外に、外部の業務委託会社、コンピュータシステムなども、「部署」の一つとして認識され表記される場合が多い。

従来は、この部署情報が重要な意味を持たない場合、あるいは新規事業における業務処理フローの検討の場合など、部署がまだ決まっておらず部署別に分別して表記することができない場合などがあった。また、基本的な表記ルールの段階で、「部署別に層化・分別表記するか否か」が規定されている場合が多く、ダイアグラムの汎用性に欠ける場合が多かった。

そこで、ダイアグラム上で業務処理フローを表現する際に、「それぞれの処理ステップを担当する部署・組織情報」を登録する。これらの処理ステップをダイアグラム上に表示する際、「部署別に層化・分別するか否か」のオプションを決定することによって、画面などに表示するダイアグラムの表示形態を動的に変更することができる。

（プロセスモデルの粒度）
つぎに、プロセルモデルの粒度について説明する。プロセスモデルを作成する目的として、下記のような例が考えられる。
（１）ビジネスモデルの策定・検証（全社レベル。マクロレベル）
（２）ＢＰＲプランの検討（概要レベル。ミドルレベル）
（３）業務手順書・コンピュータシステムのレベル（具体的手順レベル。ミクロレベル）

したがって、「プロセスモデルの詳細度（粒度、粗さ・細かさ）はこのレベルで作成すべきである」ということを決め付けることはできないし、また、逆にいえばプロセスモデルの方法論は、上記のいずれのレベルにも適用できるものでなくてはならない。

上述したプロセスモデルのサンプル（図１４など）のレベルは、おおむね上記（２）の「ＢＰＲプランの検討」のレベル（ミドルレベル）ということができる。マクロレベルのプロセスモデルを作成する際は、ダイアグラム上にプロットされる機能ユニットも、マクロレベル（原則として最上位の第１レベル）の包括的なユニットになる。このようなマクロ的な機能ユニットをベースに作成されるプロセスモデルは、詳細を描き出すことはできないが新しいビジネスプロセスをスピーディーにスケッチしていく場合にはもっとも適している。

一方、詳細レベルのプロセスモデルを作成する際は、そこにプロットされるユニットも詳細なもの（したがって階層の深い第３、第４レベル以降のユニット）となる。このような詳細なプロセスモデルは、厳密で精緻なものとなる。

図１４に示したダイアグラムを、マクロ的な全社レベルのダイアグラムとして表記し直す場合、登場させる機能ユニットは、原則として最上位レベル（第１レベル）のユニットのみとなる（図２１を参照。）。図２１は、「受注」イベントのプロセスモデル（マクロレベル、ビジネスモデルのレベル）を示す説明図である。具体的には、「顧客」ユニット、「営業」ユニット、「経理」ユニット、「配送」ユニットなどであり、図１４に示したような「配送受付」ユニットや「売上記帳」ユニットなどの具体的なレベルのユニットを記載する必然性はない。ビジネスモデリングの段階においては、厳密性や網羅性よりも「概要を把握する」ことの方が重要になるからである。

図１４に示したダイアグラムをより詳細化して、ミクロなレベルのプロセスを表現する場合は、ダイアグラム上のユニット配置の基本形を崩すことなく、一つ一つのユニットの中の内部的なプロセスを階層的に表記すればよい。これを逆にいうと、ミドルレベルのダイアグラムを描く場合は、他のファミリーのユニットと対外的な連携（メッセージング）が発生する部分は、すべてミドルレベルのダイアグラムの段階で描ききっておく必要があるということになる。これを「部署」という観点から比喩的に言い換えると、他の部署との連携・連絡が発生する部分はミドルレベルで書き込みながら、特定の部署の中の詳細な手順はミクロレベルで記述すればよいということになる。

このような詳細レベルのプロセスモデルを作成する場合、まずラフスケッチとしてのマクロレベルのダイアグラムを作成し、後にミドルレベルのダイアグラムを作成し、最終的にミクロレベルのダイアグラムを作成するという方法がある。このような方法以外に、最初から、細かい手続きを含めた最詳細レベルのダイアグラムを作成するという方法もある。このような場合は、同一平面上に多くの詳細ユニットや機能を登場させダイアグラムを作成していくことになる。

トップダウンに逐次詳細化していくか、最初から詳細なレベルまで書き込むかは、ダイアグラム作成の目的や、作成者のスキルなどによって恣意的に決定されることが多い。いずれの場合であっても、詳細レベルのダイアグラム上にある同一ファミリーの連鎖ユニットを一つにまとめて、一段階上位のユニット群でプロセスを表現することも可能である。また、一旦まとめられたユニットを再度ブレイクして、一段下位のレベルでダイアグラムを再展開することも可能である。

また、特定のユニット内の詳細手続きだけを参照したり、同一平面上にすべての詳細ユニットを展開して最詳細レベルのダイアグラムを俯瞰することも可能である（図２２を参照。）。図２２は、プロセスモデルの階層性を示す説明図である。

このように、業務処理フローをダイアグラム上で表現する際に、その処理フローを「詳細な現場レベル」で作成しさえすれば、「俯瞰的・マクロ的なレベル」のダイアグラムをあらためて定義・作成することなく、自動的に構成し表示することができる。

業務処理フローを作成する場合、全社的なレベル（俯瞰的・マクロ的なレベル）で概略フローを参照・検討する場合と、詳細な現場レベルで業務の処理手順を参照・検討する場合とがある。全社のマクロ的なレベルは、企業活動の大規模なＢＰＲなどを検討する場合であり、後者は、現場の業務処理手順（業務処理マニュアル）などを検討・確認する場合である。従来は、マクロ的な処理フローと詳細な処理フローは独立して作成する以外に方策はなく、それぞれを個別に二重の手間をかけて作成していた。

そこで、ダイアグラム上で業務処理フローを表現する際に、これに先だって、図６にあるように、機能モデルにおいてそれぞれの機能的処理ステップ（機能ユニット）を階層的・構造的に定義しておく。これらのユニット群は樹上図的に関係が定義され、マクロなユニットから順次階層的に詳細化され、ミクロなユニットが定義される。これらのユニットのうち、最詳細レベルのミクロユニットを用いて、詳細な業務処理フローを作成する。

上記の詳細業務処理フローを作成した場合は、それぞれの処理フローの中で同一ファミリー（機能モデルにおける樹上図で同一の結節点下にあるユニット群）を一つのユニットとみなし、あらためて業務処理フローを再構成すると、マクロな階層にあるユニットのみが存在する業務処理フロー図を作図することができる。このミクロレベルからマクロレベルまでの業務処理フロー図は、ユニット階層図の結節点の数（階層の深さ）に応じて、複数レベルのフロー図が存在し得るが、このレベルはダイアグラム表示時のオプションによって設定する。

また、動的に再構成されたマクロダイアグラムは、順次下位レベル（詳細レベル）への処理フロー図へと順次参照することが可能であり、マクロダイアグラム、ミクロダイアグラムはそれぞれ循環的に参照することができる。マクロダイアグラムからミクロダイアグラムへと展開する際は、フロー図全体をミクロ化するのみならず、一部のユニットのみを指定して詳細化することも可能となる。

プロセスモデルを参照する場合、経営幹部であれば通常マクロレベルのモデルを参照することで用が足りる場合が多く、中堅幹部はミドルレベルのプロセスに責任がある場合が多い。プロセスモデルは、このようなモデル利用者の階層に合わせて、マクロレベルからミクロレベルへとプロセスモデルのレベルを自動的に再構成することができる。これは機能ユニット（機能モデル）が階層的に定義されているという特性を援用することによって実現できる機能である。このような展開レベルの自動遷移は、ソフトウエア的なダイアグラミング・ツールを用いて自動的に処理することができる。

プロセスモデルを作成する際、「新しい業務プロセスが支障なく円滑に遂行されるか」ということを検証すると同時に、そのプロセスの「所要時間と所要コストを検証する」ことも必要である。

企業活動におけるコストは固定費と変動費に分類される。固定費に該当するものは、（正社員の）基本給・固定給に相当する人件費、設備の導入・原価償却に要する費用や不動産関連費用などであり、一方の変動費には、材料費、消耗品費、時間外給与などがある。このような「固定費用・変動費用」と「機能モデル・プロセスモデル」の関係を考えた場合、固定費は機能モデルに、変動費はプロセスモデルにおおむね対応する。

プロセスモデルは、特定の業務イベントごとに、その業務遂行に必要となるコストを分析するが、固定費用の算定にはなじまない。なぜなら、固定費は通常特定のイベントごとに発生するものではなく、イベントが一度も遂行されなくても発生するコストであるためである。一方の機能モデルは固定費との関係が深い。機能モデルは特定のイベントに依存するダイアグラムではなく、企業の静的な構造をモデル化したものであり、「業務が一切遂行されなくても発生するコスト」である固定費の分析に適したモデルである。

通常、業務プロセスに関わるコストを算出する場合、そのプロセス遂行に要する人件費は大きな比重を占めるが、プロセスモデルで分析対象となるコストは変動費である時間外手当だけでよいというものではない。人件費は時間外手当（変動費）だけではなく基本給相当分（固定費）も対象としなければならない。

したがって、厳密にいうと、プロセスモデルは変動費にだけ着目していればよいというものではなく、固定費中の直接コストも対象とすることになり、間接的な固定費を除くコストのすべてを対象とすることになる。具体的には、本部管理経費等の間接的なコストを除く、人件費、設備投資（原価償却）費用、不動産関連費用、材料費、消耗品費、機器保守費用などはすべてプロセスモデルの分析対象となる。

また、業務プロセスにおける所要時間を考える場合、３つの視点が考えられる。第１は、そのプロセスのために費消された直接的な処理時間である。これは商品の生産・配送、各種伝票など書類の作成、連絡に要した時間などが該当する。第２は、一連のプロセスが開始されてから終了するまでのトータルの処理時間（ターンアラウンド時間）である。通常、企業の中では、一連の処理を遂行するにあたって陸上競技のバトンリレーのように遅滞なく連鎖的に業務が完遂されるケースばかりでなく、様々な部署で処理が滞留するケースが見られる。配送のための貨物の一時的集積や稟議書の回付における滞留などがこれである。

第３に、業務上しばしば重要視されるのが、レスポンス時間（応答時間）である。特に顧客からの様々な要請に対する応答のスピードや、取引先・株主・投資家からの質問などに対する応答の速度などは実務的にも重要視される。とりわけ顧客からの注文に対する配送、問合せに対する回答、クレームに対する対応の迅速さなどは企業のコンピタンスをはかるためのメルクマールとして重要視されることが多い。このレスポンス時間を計測する際は、リクエストの発生からリクエスターに対する応答までの時間を計測し、応答した後の事後処理のための時間は除外しなければならない。たとえば、顧客からの電話での問合せを受けた時点から、その応答を完了した時点までの時間がレスポンス時間であり、事後的な「顧客問合せ記録メモ」などの作成に要した時間などは除外されなければならない。

ターンアラウンド時間は、機能ユニットの属性に「所要時間」と共に平均的な「滞留遅延時間」を設定し、プロセスモデルを用いたシミュレーションにおける「所要時間計算」時のオプションとして「滞留遅延時間を含む」ものとして所要時間を計算すれば、ターンアラウンド時間を積算することができる。

また、レスポンス時間は、各業務イベント遂行の中で「計測すべきレスポンス時間」が何を意味するのかは本来難しい問題である。たとえば、顧客から電話やｅ−ｍａｉｌで苦情が入った場合、まずその苦情の内容を理解し受付の旨を回答し（あるいはお詫びの連絡）、しかる後に苦情に関する本格的な内容の調査・対処をおこない、この後に顧客に最終回答をするとした場合、最初の受付回答をレスポンス時間とすべきか、あるいは最終の回答をレスポンス時間とすべきかを考えねばならない。

言い換えれば、これはリクエスターである顧客が、どちらの回答スピードを重視するかという問題である。このような問題は、顧客からの発注連絡（企業にとっての受注連絡）や経営幹部などからの様々な指示についても同様である。とりあえずの「受付回答」までに要する時間がレスポンス時間なのか、あるいは「最終報告」までの時間かということである。

商品の注文にしてもクレーム対応にしても同様であるが、そもそも最初の注文連絡やクレーム連絡に対して、「在庫の確認」や「たらい回し」のために一次回答が遅れれば、これはこれで顧客満足度の低下に直結するし、商品の到着やクレームに対する最終調査結果の回答が遅れれば、こちらも顧客満足度の低下要因となる。そこで、最終回答の方を「レスポンス時間」とする。この場合、プロセスモデル上でこのレスポンス時間を計測する際は、リクエスターである起動元の機能ユニットに対して返される返信メッセージのうち、もっとも遅いタイミングの返信がリクエスターに戻るまでの時間をレスポンス時間として計測すればよい（図２３−１、図２３−２を参照。）。図２３−１、図２３−２は、プロセスモデルにおける「レスポンス時間」の計測範囲を示す説明図である。

図２３−１および図２３−２に示すように、業務処理フローをダイアグラム上で表現する際に、その処理ステップごとに処理所要時間、およびそれぞれの平均滞留時間を登録しておくことによって、その業務処理フローのレスポンス時間、ターンアラウンド時間（処理全体がすべて終了するまでの時間）を自動的に算出することができる。

業務処理フローを検討し、その処理全体の処理所要時間（（顧客等への）応答所要時間（レスポンス時間）、ターンアラウンド時間（処理全体がすべて終了するまでの時間）などを含む）を算定することは、企業活動における業務処理スピード、効率性の向上や、対顧客サービスレベルの向上などの観点から重要な意味を持つ。従来は、これらの「時間の測定」は、現場での実測や、手作業で（机上で）理論計算する以外に方法はなかった。

そこで、ダイアグラム上で業務処理フローを表現する際に、それぞれの機能的処理ステップ（ユニット）ごとに、処理所要時間、および平均滞留時間（ビジネスの現場においては「ベルトコンベア式」に遅滞なく連続的に処理がおこなわれる場合以外に、各種稟議書類の回付、各種伝票のコンピュータシステムへの入力など、処理完了・受け渡しの都度、滞留が発生する場合が多い。）を登録する。

業務処理フローをダイアグラム上で作成する際、処理フローは、ユニットとユニットを結び付ける線、および処理の順序定義で、処理フローが表現される。このダイアグラムから、ユニットが費消する処理所要時間を積算し、処理フロー図全体の処理所要時間を算定する。また、上記の処理所要時間に、平均滞留時間の合計を加えて、ターンアラウンド時間を計算する。さらに、ダイアグラムから「処理の起動者」への時間的な最短ルート、および最長のルートを割り出し、ここから最長と最短の応答所要時間（レスポンス時間）を算定する。

つぎに、図１４に示した現状のプロセスに対してＢＰＲを図り、コンピュータシステムをベースにビジネス・プロセス改変した例について説明する。新しい業務プロセスでは、インターネット上で受注用のサイトを構築し、これによって業務プロセスを大幅にスピードアップしコストを低減させる例を考える。この見直し後のプロセスを表現したダイアグラムを図２４に示す。図２４は、「受注」プロセスモデル（新しい業務プロセス）を示す説明図である。

図２４におけるダイアグラムにおいて、図１４における「現状」の受注ダイアグラムと、その概形は類似している。これは、本来、顧客からの商品発注を受け付けるという行為が、受注の記録を残し（受注簿の作成）、在庫商品を引当て、商品の発送を指示し、同時に財務会計としての売上記帳をおこなうという基本的な機能の連鎖は、これを電話とファックスをベースに手作業でおこなおうが、コンピュータシステムをベースにおこなおうが、本質的な差異はないことを意味している。このように、機能の流れ（機能ユニットの連鎖）に大きな変化はないものの、それぞれのシンボルは電話、ファックス、手作業から、コンピュータシステムに変更されており、処理の大半がコンピュータ化されたことが見て取れる。

このようなプロセスの質的変化は、この受注処理に要する「所要コスト」「所要時間」（および「ターンアラウンド時間」と「レスポンス時間」）を大きく変化させる。このＢＰＲによるコストと処理時間の改善は、プロセスモデルの作成によって自動的に算定され、プロセスモデルの脚注部とイベント一覧表に自動的に反映されることになる。このイベント一覧表への表示と、新旧比較の例を図２５に示す。図２５は、イベント一覧表における新・旧比較を示す説明図である。

このようにして策定されたＢＰＲプランをビジネス実務の現場へ適用した後は、継続的に実行状況をモニタリングし、そのパフォーマンスを評価しなければならない。これがつぎの新しいＢＰＲプランの策定へ繋げるためのＢＰＭ（Ｂｕｓｉｎｅｓｓ Ｐｒｏｃｅｓｓ Ｍａｎａｇｅｍｅｎｔ）の連環である。これを実現するためには、企業内のコンピュータシステムが保有する各種のデータ、実測値、その他の資料などから情報を抽出し、ここまで述べてきた機能モデル、プロセスモデル、および組織モデルにフィードバックする必要がある。

このように、実世界のデータをモデルへフィードバックし、モデル上の値（計画値）と比較することにより、実行に移されたビジネスモデルやＢＰＲプランの妥当性や実効性が評価され検証される。また、プロセス・モデルにおける時間やコストは、一つ一つの機能ユニット、あるいは機能ごとに設定された「処理時間」「滞留時間」や「処理コスト」（間接固定費、直接固定費、変動費）を元に積算される。したがって、これらの時間とコストの基礎データの正確性はきわめて重要である。これらの基礎データの正確性を確保し、モデルと現実との乖離を防ぐためにも、上記のようなデータの収集は必要となる。

（組織モデルの作成）
つぎに、組織モデルの作成について説明する。組織体系のあり方は、しばしば、それ自体がビジネスモデルであり、ＢＰＲの成果を直接的に映し出す。言い換えれば、ＢＰＲを実行した後は必ず大なり小なり組織の見直しを伴い、また、組織の改変を伴わないような本格的なＢＰＲは存在しない。

上述した機能ユニットにおける組織情報は、その機能を担っている（あるいは担うべき）組織を規定しているものであり、組織の体系そのものを定義しているものではない。組織体系を定義するためには、固有の「組織モデル」が必要になる。たとえば、機能モデルにおける、ある特定の機能ユニットを担う組織として、「本店営業管理部」と、「大阪支店営業管理課」が設定されていたとして、これらの部署がどのような位置づけにあるのか、どのような指揮命令系統下にあるのか、機能ユニットにおけるこのような断片的な組織名からだけでは計り知ることができない。

組織モデルにおいても、まず現状分析をおこなうのが基本である。「現状の組織モデル」は、基本的には現状の組織図を複写するだけで済む。しかしながら、ここで留意しなくてはならない点がある。それは、特定の機能を外部の会社に委託している場合や、コンピュータシステムなどが機能を担っている場合である。これらの外部の委託先やコンピュータシステムは「企業運営上必要な機能を担っている」という意味では、通常の人間系の内部組織と何ら変わるところがない。

ある程度以上の規模の会社であれば、たとえば経理機能の多くはすでにシステム化されている場合が多い。また、専門性の高い業務や、労働集約的な作業を外部に委託するということも日常的におこなわれている。これら外部の委託先や、コンピュータシステムなどの設備なども、現状の組織図に加えて書き込まないと、企業活動を支える「組織」の構造の全体を表現することにはならない。

プロセスモデル上でＢＰＲを考え、新たな担い手としての「部署名」をダイアグラム上に当てはめていく場合、何らかの仮定的な将来の新組織図が必要になる。しかしながら、この仮定的な新組織図は、ビジネスモデルやＢＰＲ検討の過程で随時見直しがなされていく場合が多い。この段階の新組織図は機能モデルやプロセスモデルの作成過程で改変されることを前提とした、あくまで仮の組織図である。

「組織モデル」の基本形は、通常よく見る一般的なピラミッド型の組織図に準じた形である。この組織モデルの構造と、組織モデルが保持する情報について、整理する。組織モデルを用いて、組織の体系を描く場合は、組織の最小単位（〜課、〜係など）まで記載するのが望ましい。しかし、企業がある一定以上の規模において、企業内のすべての部署を書き出すと相当大きな図になってしまう。

また、これに加えて外部の業務委託先の企業やコンピュータシステムをすべて書き出すとなおさら一枚の図にするのは困難になってくる。このような場合は、たとえば「部」の単位まで書いて、以下の細かい課・係などの部署についての体系図は各部内の詳細組織図ということで階層的にダイアグラムを描く必要が出てくる。この場合は、組織図間の階層関係を定義して、ダイアグラム全体を体系付けることになる。

また、組織モデルは、各シートごとに固有の属性情報を持つ。この属性情報は、図２６に示すように、各シートの表題部に記載される。図２６は、組織モデルの属性情報（ヘッダー部）を示す説明図である。

図２６において、
（１）組織ＩＤ番号には、このシートが表す組織に対する固有のＩＤ番号を記載する。最上位の「全社ベース」のシートには「１」を付与する。また、下位のシートで各部署の詳細をダイアグラミングする場合は、「１．２．３」のように「．（ピリオド）」を用いて番号帯を区切り、上位の組織（組織体系）と階層の深さを表現する。

（２）部署には、このシートが対象とする部署名を記載する。特定の部署に関するシートであれば、その部署名を記載し、全社レベルであれば「全社」と記載する。

（３）作成対象には、「現状」または「見直し後」の区分を記載する。

（４）収益には、その部署の収益額を記載する。なお、本部部門などのコストセンターについては記載対象外となる。

（５）要員数には、その部署・組織に所属する人員数を記載する。なお、この項目は人間の集団として成立している「企業内部の部署・組織」の場合に有効な項目であり、コンピュータシステムや自動化設備、外部委託先については記載対象外となる。

（６）直接コスト合計には、その組織を維持するために必要な、あるいは費消されている直接コストを記載する。なお、シートの対象が、コンピュータシステムや各種の機器類、自動化設備、あるいは外部委託先である場合は、購入費用・原価償却費、リース料、レンタル料、保守料、委託費なども算入される。

（７）間接コスト合計には、上記（６）の「直接コスト合計」と同様な方法で「間接コスト」について設定・展開する項目である。

（「部署」と「組織」の情報）
つぎに、このような組織モデルを作成した場合、部署単位の情報として得られる情報について説明する。

機能モデルにおける機能ユニットには、「機能」の情報以外に「部署名」が設定されている。したがって、組織モデル上で特定の部署を指定すると、その部署が担っている「機能の一覧」をリストアップすることができる。すなわち「その部署が何をやっているか」「何をやるべき部署なのか」がわかる。これにより、その「部署」の企業内での「役割」がより明確になり、指揮命令系統の整理や権限体系の見直しをはじめとする組織改革の基礎情報を提供する。

同様に、組織モデル上で特定の部署を指定すると、その部署の所属人員数、およびコスト（固定費・変動費）と収益額を見ることができる。コストを見るということは組織を考える上で重要なポイントとなる。なぜならば、この「組織に関わるコスト」というのは、その組織の「維持費」に相当するからである。上記「機能」とこの「コスト」「所属人員数」「収益額」を対比的に見ることによって、その組織が費消している経営資源が、遂行している機能やその組織が生み出す収益に見合うかどうかを検討することができる。

通常、「組織が生み出す収益」や「組織維持のためのコストや人員数の情報」は、組織図や組織が担っている「機能」の情報とともに統合的に視覚的な方法で還元されるということはない。言い換えれば「その組織維持のために投入されている経営資源が適切かどうか」ということを判断するための材料が提供されていない。このような状態では最適な組織設計は覚束ない。経営環境は不断に変化しており、企業経営の形を現す組織体系も、常に進化と適応が求められる。そのためには、組織がやっていること（組織の機能）と組織のコスト（人員数・固定費・変動費）も常に整理され情報として還元されていなければならない。

組織モデルは単に組織の形のみならず、それぞれの部署・組織、およびコンピュータシステムなどの設備、外部委託先などについて、「やっていること（機能）」「収益」「組織維持のためのコスト」「部署の人員数」などの「組織に関する情報」を統合的にかつ視覚的に提供する。

以上説明したように、組織のあり方の検討は、ビジネスを最適化するにあたって欠かせない重要なポイントである。ＢＰＲを実行する場合、そのほとんどが組織の改変を伴う。また、組織モデルは、一般的な組織図に、企業の外部にある存在や、コンピュータシステムを書き加えたものである。また、組織モデルは機能モデルやプロセスモデルと同様に階層性を持つ。さらに、組織モデルは、各組織ごとのコストや収益、人員数などの情報を持つ。これらの情報は、機能ユニットやイベント一覧表、プロセスモデル、およびその他の情報から設定される。

なお、本実施の形態で説明したビジネスモデリング支援方法は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーション等のコンピュータで実行することにより実現することができる。このプログラムは、ハードディスク、フレキシブルディスク、ＣＤ−ＲＯＭ、ＭＯ、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録され、コンピュータによって記録媒体から読み出されることによって実行される。またこのプログラムは、インターネット等のネットワークを介して配布することが可能な伝送媒体であってもよい。

以上のように、本発明にかかるビジネスモデリング支援方法およびビジネスモデリング支援プログラムは、企業活動に関するある目標（売上高、収益率など）を設定し、それを達成するために業務内容や業務の流れ、組織構造を分析、最適化するのに適している。

この発明の本実施の形態にかかるビジネスモデリング支援方法の概要を示す説明図である。 ソフトウエア・ツールの画面例（機能モデル）を示す説明図である。 ソフトウエア・ツールの画面例（プロセスモデル）を示す説明図である。 ソフトウエア・ツールの画面例（組織モデル）を示す説明図である。 この発明の本実施の形態にかかるビジネスモデリング支援プログラムを実行するためのハードウエア構成を示すブロック図である。 ユニットの階層的詳細化を示す説明図である。 損害保険の分類例を示す説明図である。 損害保険商品の階層化を示す説明図である。 損害保険商品のダイアグラム化を示す説明図である。 機能モデルのシートの一例を示す説明図である。 シンボルの種類を示す説明図（その１）である。 シンボルの種類を示す説明図（その２）である。 機能ユニットの内部構造を示す説明図（その１）である。 機能ユニットの内部構造を示す説明図（その２）である。 「業務イベント一覧表」のフォーマットの一例を示す説明図である。 「受注」プロセスモデル（現状を表したもの）を示す説明図である。 プロセスモデルからイベント一覧表へのフィードバックを示す説明図である。 プロセスモデルにおける説明ボックスの内容を示す説明図である。 受信ユニットにとっての説明ボックスの内容を示す説明図である。 説明ボックスにおけるメッセージ・コンテンツを示す説明図である。 プロセスモデルにおける「シンボル」と「部署名」の付記の例を示す説明図である。 「受注」イベントのプロセスモデル（部署別に層化した例）を示す説明図である。 「受注」イベントのプロセスモデル（マクロレベル、ビジネスモデルのレベル）を示す説明図である。 プロセスモデルの階層性を示す説明図である。 プロセスモデルにおける「レスポンス時間」の計測範囲を示す説明図である。 プロセスモデルにおける「レスポンス時間」の計測範囲を示す別の説明図である。 「受注」プロセスモデル（新しい業務プロセス）を示す説明図である。 イベント一覧表における新・旧比較を示す説明図である。 組織モデルの属性情報（ヘッダー部）を示す説明図である。

符号の説明

１００ 企業
２００，３００，４００ 表示画面
２０３，３０３ 説明ボックス
２０５，３０５ 機能ユニット
４０３ 組織名
１０００ シート
１００１ 表題部
１００２ ダイアグラム・エリア
１００３ 機能ユニット番号
１００４ 機能ユニット名
１００５ 内部領域
１００６ ユニット外領域
１００７ 企業外領域

Claims (10)

1. 企業活動のビジネスモデリングを支援するビジネスモデリング支援方法であって、
   前記企業活動を構成する機能的構成要素（以下、「機能ユニット」という）を抽出し、抽出された機能ユニットの配置、組み合せまたは当該機能の実現手段の少なくとも一つを検討する機能モデル作成工程と、
   前記機能モデル作成工程によって抽出・定義された各機能ユニットについて、その内容を階層的に詳細化し、具体的な実務レベルの機能ユニットを抽出する階層化／詳細化工程と、
   前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、
   前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスをモデル化し、プロセスの所要コストおよび所要時間の少なくともいずれかを算出するプロセスモデル作成工程と、
   ビジネスを遂行するための新しい組織体系をモデル化する組織モデル作成工程と、
   前記階層化／詳細化工程によって抽出された機能ユニット、または、前記プロセスモデル作成工程によってモデル化された業務遂行プロセスをモニタリングするモニタリング工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
2. 企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、
   前記企業活動を構成する機能ユニットを抽出する機能モデル作成工程と、
   前記機能モデル作成工程によって抽出された各機能ユニットについて、当該機能の実現手段、当該機能ユニットの性質および当該機能ユニットの特徴の少なくとも一つを表現するアイコンを表示する表示工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
3. 企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、
   前記企業活動を構成する機能ユニットを抽出する機能モデル作成工程と、
   前記機能モデル作成工程によって抽出された各機能ユニットの機能的内部構造を階層的に表示する表示工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
4. 企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、
   前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、
   前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスを順次逐次的に強調するように表示する表示工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
5. 企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、
   前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、
   前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスについて、当該機能の実現手段、当該機能ユニットの性質および当該機能ユニットの特徴の少なくとも一つを表現するアイコンを表示する表示工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
6. 企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、
   前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、
   前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスについて、当該プロセスの詳細な関連情報の表示／非表示を制御する表示工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
7. 企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、
   前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、
   前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスを部署別に層化して表示する表示工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
8. 企業活動のビジネスモデリングをコンピュータを用いて支援するビジネスモデリング支援方法であって、
   前記企業活動における種々な業務イベントを抽出する業務イベント抽出工程と、
   前記業務イベント抽出工程によって抽出された業務イベントごとの業務遂行プロセスを表示する第１の表示工程と、
   前記第１の表示工程によって表示された詳細な業務遂行プロセスを俯瞰的なレベルで再展開し、再展開された業務遂行プロセスを表示する第２の表示工程と、
   を含んだことを特徴とするビジネスモデリング支援方法。
9. さらに、前記業務遂行プロセスの応答所要時間およびターンアラウンド時間の少なくともいずれかを算出する算出工程を備え、
   前記表示工程は、前記算出工程によって算出された結果に関する情報を表示することを特徴とする請求項４〜８のいずれか一つに記載のビジネスモデリング支援方法。
10. 前記請求項１〜９のいずれか一つのビジネスモデリング支援方法をコンピュータに実行させることを特徴とするビジネスモデリング支援プログラム。
    
    
    

Images