 |
||||||||||||||
|
||||||||||||||
| 前のページ 1 2 3 次のページ | ||||||||||||||
|
||||||||||||||
| 開発方法論としてのBPMS | ||||||||||||||
|
それではシステム構築を行うBPMSの本論に移ります。 BPMSはMDA（注1）でシステム構築を行うのが常識ですので、それを包含した開発方法論の観点で説明します。
※注1：
MDA（Model Driven Architecture：モデル駆動型アーキテクチャ）
モデリングの標準技術体系。「モデルを一度作ればそこから次のステップが駆動できること」と「分析モデルをプラットフォームに依存せずに設計モデルと独立して定義できること」という2つの利点がある。 |
||||||||||||||
| ウォータフォール開発 | ||||||||||||||
|
ウォータフォール開発は各フェーズにきっちりしたドキュメント（モデル）を作り、そのドキュメントを基に次の工程の作業を行います。逆流が起こるとその影響範囲は大きくなるので、後戻りは許されません。従って、後戻りしないように終了時点のドキュメントの完成度を上げることが必須なのです。 ウォータフォール形の開発工程は次の通りです。  図1：ウォータフォール形の開発工程 （画像をクリックすると別ウィンドウに拡大図を表示します） BPMSの適用はウォータフォール型の開発に直接影響を与えるのは基本設計までであり、業務に設計仕様を固める部分がBPMの活躍する場です。しかし、間接的な再利用性の促進や開発機能の削減などでは全体におよびます。そこで、BPMSをこのウォータフォールに適用したときの影響（効果）を追って解説していきます。 |
||||||||||||||
| システム化の仕様と基本設計の業務要件 | ||||||||||||||
|
BPMSを開発手法に適用した場合の導入の利点は以下の通りであり、その特長から1種のプロトタイピング技法ともいえます。
表1：BPMSを開発手法に適用した場合の導入の利点
BPMSの適用はすべての内容を網羅しているのではありません。その適用はEA（エンタープライズアーキテクチャ）の中のBA（ビジネスアーキテクチャ）に関する部分なのです。 BPMSの適用によりビジネスプロセスのフロー部分／組織（担当）／業務ルールが業務要件として切り出され、その内容を情報システムで行う業務処理に持ち込まない整理がされていることになります。その結果、フローの変更／組織の変更／業務ルールの変更への対応が迅速の行えます。 情報システム技術からするとこの部分がBPMS導入の成功の鍵を握っており、情報システムの技術的なコンセプトを決めます。そして、BPMSに関係するところに絞ると大きなフレームとしてのBA（ビジネスアーキテクチャ＝BPM適用箇所）とSA（システムアーキテクチャ）のインターフェースを決めます。 もしBPMで定義したタスクごとに情報処理のアプリケーションを作ってしまうと、アプリケーションは非常に複雑になってしまいます。 |
||||||||||||||
| 全体設計の視点で見るBPMS | ||||||||||||||
|
BPMSで記述するビジネスフロー（ワークフロー）は現実の世界ですので、場合によっては様々なところで同じ機能が使われる可能性があります。ワークフローは概念的な整理より実践的な記述になので、その実践的な記述のルール（制約）を補完する整理が必要です。  図2：BPMの概念的な整理 実際の開発では「企業全体の業務フォーメーション概念的な設定」「業務機能の概念的な設定」「情報の概念的な設定（データモデル）」「業務機能をさらに詳細化したサービスの概念的な設定を並行（スパイラル）」「先行して実行されること」が求められます。 安定した情報システムの処理基盤とその上に搭載されるBPM機能の構造は、こういった要件を踏んだ上で構築されます。BPMの適用領域の解説を今回の前半で触れましたが、ワークフローとしての決済や稟議で扱うBPMSと基幹業務で扱うBPMSの構築上の違いはまさにこの部分なのです。 |
||||||||||||||
|
前のページ 1 2 3 次のページ |
||||||||||||||
|
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
|
|
||||||||||||||
|
||||||||||||||
-
-
連載
