プロセスモデル

出典: フリー百科事典『ウィキペディア(Wikipedia)』
移動: 案内, 検索

プロセスモデル(Process Model)とは、何らかのプロセス(過程、工程)のモデルである。例えば、ビジネスプロセスモデルとは、企業のプロセスモデルである。また、プロセスモデルは化学工学の重要な概念でもある。以下では主にビジネスプロセスモデルに関して解説している。

Colette Rolland はプロセスモデルを次のように定義している[1]:

同じ性質を持つプロセスは1つのプロセスモデルに分類される。つまり、プロセスモデルはプロセスの型レベルの記述である。プロセスモデルが型レベルであるとすれば、個々のプロセスはそのインスタンス化したものである。プロセスモデルは様々な開発に繰り返し利用されるため、そのインスタンスは多数存在する。[…] プロセスモデルは「物事がどのようになされるか(なされるべきか/なされなければならないか)」を記述したものであり、一方個々のプロセスは実際に起きる出来事である。プロセスモデルは多かれ少なかれプロセスがどのようになるかを予測するものである。プロセスがこうあるべきだという方針は実際のシステム開発時に決定されるだろう。

目次

[編集] ビジネスプロセスモデリング

ビジネスプロセスモデリング: Business process modelingBPM)は、企業のプロセスの現状と将来を表現する活動であり、それにより現状のプロセスへの理解が深まり改善が生み出される。BPM はアナリストやマネージャがプロセスの効率化や高品質化を目指して行う。BPM によるプロセスの効率化にはITが関わる場合が多い。

改善されたビジネスプロセスを実施に移行させる際には変革管理が必要となる。技術革新とともに、BPMによるモデルを完全に実行可能にできる可能性が高まってきている。

ビジネスプロセスモデリングはビジネスプロセス管理 (BPM) において、重要な役割を担う。どちらも同じ頭字語(BPM)となるため、両者を混同することがある。

BPM で使われる標準モデリング言語には以下のものがある[2]

他にも、モデル駆動型アーキテクチャサービス指向アーキテクチャといった技術がビジネスプロセスモデリングと関連している。

BPM はエンタープライズアーキテクチャのプロセス的側面を扱う。企業全体のシステム(データアーキテクチャ、組織構造、戦略など)におけるビジネスプロセスは企業改革に大きな意味を持つ。例えば、企業の合併において、両企業のビジネスプロセスを詳細に分析することで業務上冗長な部分を効果的に特定できる。ビジネスプロセスモデリングはビジネスプロセス・リエンジニアリング (BPR) にとっても、シックス・シグマのような継続的改善手法にとっても重要である。

[編集] 主な目的

  • 記述的な目的
    • プロセス内で実際に何が起きるかを順次記述する。
    • プロセスを外部の視点から見て、そのプロセスをより効率的にする改善点を見出す。
  • 規範的な目的
    • ある目標を達成するためのプロセスを定義し、どのようにすべきかを示す。
    • 規則、ガイドライン、行動パターンなどに帰着してプロセスの改善を促す。厳密な規則から柔軟なガイダンスまで様々である。
  • 説明的な目的
    • プロセスの原理を説明する。
    • 原理に基づいてとりうるコースを探索/評価する。
    • プロセス間および満たすべき要求との明確なリンクを確立する。

[編集] 用途

「理論的観点では、プロセスメタモデルでは開発プロセスで何がどういう理由で発生するかといったことを記述するための鍵となる概念を説明する。実施側の観点では、プロセスメタモデルは技術者や開発者に一種の手引きを提供する。」[Rolland1993][3]

ビジネスプロセスのモデリングでは、プロセス改善の必要性を予測したり、改善すべき問題点を指摘したりする。これは必ずしも情報技術の導入を意味しないが、情報技術の導入がビジネスプロセスのモデル化のきっかけとなることが多い。変革管理プログラムによってプロセスが実行に移される。技術革新とともに、ビジネスプロセスモデル(BPM)の重要性が増してきている。サポート技術として、統一モデリング言語(UML)、モデル駆動型アーキテクチャサービス指向アーキテクチャなどがある。

プロセスモデリングは企業ビジネスアーキテクチャのプロセス的側面を明らかにし、最終的にエンタープライズアーキテクチャの構築につながる。ビジネスプロセスと企業のその他の側面(システム、データ、構造、戦略など)の関係を明らかにすることで変革の分析と計画に寄与する。例えば、企業の合併においては、両社のプロセスを詳細に把握することで冗長となる部分が明らかとなり、合併がスムーズに進むことになる。

プロセスモデルはビジネスプロセス・リエンジニアリングの鍵であり、シックスシグマにおける継続的改善の鍵でもある。

[編集] プロセスモデルの分類

[編集] 適用分野による分類

[Dowson1988][4] は、以下の4つの異なる意味でプロセスモデルという用語が使われているとした:

  • 活動指向: ある製品を定義する目的の下で関連する活動群。目標達成までの半順序的ステップ群。[Feiler1993][5]
  • 製品指向: 製品を目標のレベルにするための一連の活動。
  • デシジョン指向: 特定の製品定義のために必要な決定の集合。
  • コンテキスト指向: 製品の改良をもたらす一連のコンテキストの集合。

[編集] レベルによる分類

Rollandによれば[1]、プロセスは以下のように分類され、それぞれモデル化手法が異なる。

  • 戦略的プロセス
    • 代替案を検討し、それを実行する計画を立案することもある。
    • 高度な活動であり、代替案の選択も重要な選択となる。
  • 戦術的プロセス
    • 計画の実行を支援する。
    • 実際の計画実行により近く、計画の詳細化を行う。
  • 実装プロセス
    • 最も下位のプロセス。
    • 計画を実施するための詳細を扱う。

[編集] 粒度による分類

粒度(Granularity)とは、プロセスモデルの詳細さのレベルを意味する。

「粒度は提供すべき手引き、説明、手順の種類に影響を与える。粒度が粗い場合、あまり具体化しない。粒度が細かい場合、より詳細なものを提供する。必要とされる粒度は状況に依存する」[Rolland1998][1]

顧客や経営者は粗い粒度のプロセス記述を要求する傾向があり、意思決定のための概略的情報を必要とする。一方、ソフトウェア技術者やユーザーは細かい粒度のプロセスモデルを必要とし、それによって具体的手順を知ったり、個々の人々の依存関係が明らかになる。

細かい粒度のモデル記述法もあるが、粗い粒度のモデル記述法の方が古くから存在する。プロセスモデルは理想的にはあらゆる粒度に対応できるのが望ましい(例えば、Process Weaver [Fernström1991][6])[Rolland1998][1]

[編集] 柔軟性による分類

プロセスモデルは何らかの予測を行うが、実際に起きることは予測通りではない[Rolland1999][7]。従って、フレームワークを実際の状況に合わせて修正することでモデルの価値が向上する。このようなフレームワークの研究を Situational Method Engineering と呼ぶ。

方式を構築する手法は柔軟性の低いものから高いものまである[Harmsen1994][8]

[編集] 技法

Rolland はプロセス表現技法として、「文書」、「プログラム」、「ハイパーテキスト」の3つのスタイルを挙げた[Rolland1998][1]。これをまとめたのが以下の表である:

プロセス表現スタイル
Perspective 文書 プログラム ハイパーテキスト
利用法 人間同士の間で対話的に用いる マシンが実行する プロセスの異なる観点(製品の部品、決定、論点、課題)を結びつけたネットワーク
特徴 非決定性がある 事前に決めた範囲でのプロセスの可変性をサポート
応用範囲 規範的目的で使用(柔軟な手引き) 規範的目的で使用(厳密な規則) 記述的および説明的目的で使用

Rolland によれば、自然言語や非定型的な図が情報システムのプロセスモデルを表現するために使われてきた。また、ソフトウェア工学においては、より形式的なプロセスモデルが使われてきた。これについては、[Armenise1993][9]、[Curtis1992][10]、[Finkelstein1994][11]でも解説されている。そのような形式的プロセスモデルはプログラミング言語と関連しており、次のような対応がある:

[編集] 関連項目

[編集] 外部リンク

[編集] 脚注

  1. ^ a b c d e C. Rolland. A Comprehensive View of Process Engineering. Proceedings of the 10th International Conference CAiSE'98, B. Lecture Notes in Computer Science 1413, Pernici, C. Thanos (Eds), Springer. Pisa, Italy, June 1998
  2. ^ Business Modeling FAQ”. 2007年2月6日閲覧。
  3. ^ C. Rolland. Modeling the Requirements Engineering Process, 3rd European-Japanese Seminar on Information Modelling and Knowledge Bases, Budapest, Hungary, June 1993.
  4. ^ M. Dowson. Iteration in the Software Process, Proc 9th Int. Conf. on Software Engineering, 1988.
  5. ^ P. H. Feiler, W. S. Humphrey. Software Process Development and Enactment: Concepts and Definitions, Proc. 2nd Int. Conf. on "Software Process", 1993.
  6. ^ C. Fernström, L. Ohlsson, Integration Needs in Process Enacted Environments, Proc. 1st Int. Conf. on the Software Process, IEEE computer Society Press, October 1991.
  7. ^ C. Rolland, N. Prakash, A. Benjamen. A Multi-Model View of Process Modelling. Requirements Engineering. Volume 4, Number 4. Springer-Verlag London Ltd , 1999
  8. ^ A. F. Harmsen, J. N. Brinkkemper, J. L. H. Oei; Situational Method Engineering for information Systems Project Approaches, Int. IFIP WG8. 1 Conf. in CRIS series: Methods and associated Tools for the Information Systems Life Cycle (A-55), North Holland (Pub. ), 1994.
  9. ^ P. Armenise, S. Bandinelli, C. Ghezzi, A. Morzenti, A survey and assessment of software process representation formalisms Int. Journal of Software Engineering and Knowledge Engineering, Vol. 3, No. 3, 1993.
  10. ^ B. Curtis, M. Kellner, J. Over, Process Modeling, Communications of ACM, vol 35 n°9, september 1992, pp 75-90.
  11. ^ a b c d A. Finkelstein, J. Kramer, B. Nuseibeh (eds). Software process modelling and technology. Wiley, New York, 1994
  12. ^ L. Jacherri, J. O. Larseon, R. Conradi, Software Process Modelling and Evolution in EPOS, in Proc. of the 4th Int. Conf. on Software Engineering and Knowledge Engineering (SEKE'92), Capri, Italy, 1992, pp574-589.
  13. ^ V; Ambriola, M. L. Jaccheri, Definition and Enactment of Oikos software entities, Proc. of the First European Workshop on Software Process Modeling, Milan, Italy, 1991
個人用ツール
名前空間
変種
操作
案内
ヘルプ
ツールボックス
他の言語