主要なBPMプラットフォームの比較：PegaとIBM BPM

BPM（ビジネスプロセス管理）の概念は、大企業および中小企業の生活の一部になりつつあります。 その本質は、会社のビジネスプロセスを資産と見なすことであり、これを使用してビジネスの収益性を高めることができます。 これに使用するツールは何でも構いません：紙、テキスト文書、Visio、またはその他のグラフ作成ツール...しかし、ビジネスを変革するためのツールとして機能するように特別に設計されたクラスのツールがあります-これらはBPMプラットフォームです。

このようなプラットフォームのタスクは、2つの方法で提示されます。一方では、ビジネスプロセスを視覚化する必要があり、他方では、完了する必要があります。







このようなプラットフォームの市場全体については説明しません。これは独立したGartnerエージェンシーの記事でよく説明されています。上記の図を使用しました（ ペガまたはIBMから全文をダウンロードできますが、登録が必要になります。 」）。

この記事の目的は、現在利用可能な（2014年秋）2つの主要なプラットフォームであるPegaとIBM BPMの技術的能力を、 ビジネスプロセス自動化プロジェクトでの使用経験の観点から比較することです。



ビジネスの変革を計画している場合、または上級管理職が設定したビジネス目標を達成するITソリューションが必要な場合、またはBPMソリューションに興味がある場合は、catへようこそ。

比較の原則

最初に、比較方法を正確に説明します。

第一に、BPMは、大部分はプロジェクト管理へのアプローチであり、特定の考え方であり、書面で合意された技術仕様を自動化するためのプラットフォームではありません。 PegaとIBMは、一般に同様のアプローチを推奨しています。目標設定、反復開発、変更の容易さ。 しかし、悪魔はいつものように詳細にあります。 したがって、私のレビューでは、プロジェクト管理、要件管理、期待値管理の側面にも注意を払っています。

第二に、ペガとIBMの類似点がすべてあるため、ベースプラットフォームのみを比較することはできません。 Pegaには、別途ライセンスされる多くの追加フレームワークがあります。 IBMにはさまざまなレベルのBPMライセンスがあり、BPMを補完する他のプラットフォームもいくつかあります。

したがって、このレビューでは、ペガとIBMは基本的なBPMプラットフォームよりも広い意味で理解されています。これらはソフトウェアと方法論ツールの完全な複合体です。

この記事は、次のセクションで構成されています。

1. PegaおよびIBM BPMの内部構造の簡単な概要、および実装方法の簡単な説明。 これらのレビューは完全な説明のふりをするものではありませんが、参照目的で提供されていますが、最初のダイビングに非常に役立つことを願っています。 詳細については、対応するプラットフォームのドキュメントを参照してください。
2. 主な比較ポイントは表にまとめられています。 表の各行は、比較されたアスペクトまたは機能の1つに対応し、列は、それぞれ異なるプラットフォーム（PegaおよびIBM）でのこれらのアスペクトの実装に対応します。
3. 両方のプラットフォームのユニークな利点。

Pegaアーキテクチャの概要

Pegaコアは、任意のアプリケーションサーバーで実行されるJavaエンタープライズアプリケーションです。 このカーネルに基づいて、ブラウザーを介してアクセス可能な開発者のポータル自体を含むPRPCの基本的なフレームワークを構成するクラスのスタックが構築されています（このポータルは内部開発チームでも使用されているため、 PegaはPegaで開発されていると言えます）。

Pegaの仕組みを理解するには、クラスとルールの2つの基本概念を定義する必要があります。

• クラスは、オブジェクト指向パラダイムの標準単位であり、関連するデータとその処理方法を含む構造です。
• ルールは、他のクラスに割り当てられた、または他のクラスに割り当てられた、特別な組み込み（フレームワークの1つで定義された）クラスの1つのインスタンスです。 ルールは、戦略パターンの実装と考えることができます（動作とも呼ばれます;パターンの完全な説明はwikiにあります ）：クラスに属するルールは、プロパティ、動作（フロー、フローアクション）、データの表示方法（セクション）などを定義します別の。

Pegaアプリケーションは、データ構造（Data-ブランチに格納される）、または作品またはケースの構造（Work-ブランチ）を定義する一連のクラスで構成されます。 これらの各クラスは、フレームワークで定義されたクラスまたは他のアプリケーションクラスからプロパティとメソッド（ルールで定義）を継承できます。 どのクラスでも、基本クラスで定義されたルールをオーバーライドできます。

Pegaには、継承を使用して最終的なアプリケーションを構築できる多くの異なるフレームワークがあります。たとえば、そのうちのいくつかを紹介します。

• PRPC自体はフレームワークです。
• DSM-意思決定システムの構築用。
• CPM-顧客との対話システムを構築するため。
• さまざまな産業パッケージ：金融、保険、エネルギーなど。

ペガ、アプローチ

このアプローチの基礎は、次の3つのことに基づいています。

• Situational Layer Cake （レイヤードアーキテクチャ）：ルール解決メカニズムの形式で実装された継承とポリモーフィズムにより、ペガでは、特定のクライアントのビジネスプロセスが、特定のクライアントの忠誠度のレベルなど、さまざまな条件に応じて変化することを保証できます。およびサービスオフィスの地域の法律から。
• 6Rは、受信およびルーティングタスク、レポート、応答、調査、意思決定、およびケースの解決を提供する統合ソリューションを構築する概念です。
• DCO （目的の直接キャプチャ）は、プロジェクトのフレームワーク内でビジネスに本当に必要なもののみを開発することを目的とした方法論とそれをサポートするツールのセットです。

Pegaは、要件の収集と管理、機能の開発とテスト、およびエンドユーザーがビジネスアプリケーションを操作するための単一のスペースを提供します。

最良のシナリオでは、アクションのシーケンスは次のとおりです。

1. コストの量と潜在的な効果の間の最適なバランスを示す最初のプロジェクトを選択します。 将来的には、他のプロジェクトに移行することが可能になるでしょう。
2. アプリケーションを作成します; DCOツールを使用して、さらに手順を実行します。 システムに直接。
3. ビジネスの目標と要件を修正します。
4. システムの動作方法を説明する仕様を導入し、それらを目標や要件に関連付けます。
5. 作業を別々のセクションに分割し、それぞれについて次の手順を実行します。
   1. 仕様の一般的な理解を検証するために、ユーザーとDCOセッションを実施します（DCOセッションは、要件を最初に収集するためではなく、開発を直接開始する前に仕様を検証することに注意してください）。
   2. これらの仕様に従って機能を実装します。
   3. ユーザーに結果を表示します。

Pegaのアプローチには軟膏があります。すべてのDCOツールを使用するには、ビジネス目標を定義し、要件を記録し、仕様を書き留められるようにアプリケーションを作成する必要があります。 ただし、AppExpressを使用してアプリケーションを作成する場合は、目標、ケースセット、ビジネスオブジェクトなどのデータを指定する必要があります。また、アプリケーションの基本的なフレームワークと必要なレイヤー構造を選択する必要があります。これは、要件の収集作業の一部が既に完了していることを意味します。



_{目標がそれほど怖くない場合-識別するためのツールは必要ありません。他の問題により、最初は要件を収集するためだけにアプリケーションが作成され、その後、自動化のためのアプリケーションが作成される場合があります。 ただし、要件と仕様をエクスポートおよびインポートすることにより、これを十分に調整できます。}

IBMアーキテクチャーの概要

IBMプラットフォームスタックは、websphereアプリケーションサーバーで実行されるJavaエンタープライズアプリケーションです。

IBM BPMには次の要素があります。

• ビジネスプロセス定義は、BPMN標準に準拠した実行可能なプロセス図です。 プロセスには、別のプロセスが含まれたり、特定のサービスが呼び出される場合があります。
• サービスは、アプリケーションのアトミックな実行可能ユニットです。 サービスは他のサービスに組み込むことができます。 概念的には、完全に自動化されたサービス（統合呼び出し、データ処理など）と自動化されていないサービス（ユーザーの操作が必要）の2種類のサービスがあります。
• データ型-アプリケーション内のデータ構造を定義します。別のデータ型で指定された単純型（文字列、数値など）または複合のプロパティを含めることができます。 特定の変数およびデータオブジェクトのインスタンスは、各プロセスまたはサービスで定義されます。

IBM BPMは、次の部分で構成されています。

• プロセスリポジトリ-プロセス、サービス、データ構造などに関するすべての情報を保存します。
• プロセスサーバー-ビジネスプロセスの作業を保証する実行コンポーネント。
• プロセスセンター-開発用のプロセスリポジトリへのアクセスを提供するコンポーネント。
• プロセスデザイナー-Eclipseベースの開発環境。
• ポータル-エンドユーザーの作業環境（使用しない場合があります）;
• プロセスデータウェアハウス-プロセスインスタンスの通過に関する統計情報のリポジトリ。
• Blueworks Liveは、ビジネスプロセスをモデリングおよび文書化するためのクラウドベースのサービスです。 構築されたモデルはプロセスデザイナにインポートできますが、実際にはこの機能はほとんど使用されません。

IBM BPMには次のライセンスレベルがあります。

• Express-上記のすべてのBPMコンポーネントが含まれていますが、1つのプロジェクトのみに制限されています。 クラスタリングの可能性なしに、単一のサーバーにのみインストールすることが可能です。
• 標準-上記のすべてのBPMコンポーネントが含まれます。 複数のプロジェクトを一度に実行したり、クラスター化されたサーバーに基本的な統合サポートをインストールしたりできます。
• 高度-追加の組み込みデータバスと高度な統合ツールが含まれています。 高負荷のプロジェクト向けに設計されています。

IBMにはさまざまな関連製品がありますが、例としてそれらのいくつかを引用します。

• ODM-ビジネスルールのプラットフォーム。
• ケースマネージャー-一連のケースを作成および整理するためのプラットフォーム。
• 統合バス-統合バス。

IBMのアプローチ

PegaとIBMの方法論的アプローチは非常に似ているという事実（プロジェクトの選択基準、ビジネス目標の重要性、要件と開発の反復的収集）にもかかわらず、IBMはこのアプローチをサポートするツールがはるかに少ない。

IBM BPMにソリューションを実装する場合、次のアプローチが想定されます。

1. コストと潜在的な効果との最適なバランスを示すプロジェクトを選択してください。
2. BlueworksLiveのビジネス目標を説明します。
3. BlueworksLiveでビジネスプロセスを説明します。
4. ユーザーとの一連の会議を実施して、BlueworksLiveで説明されているプロセス（いわゆるPlayback 0）を実行します。
5. BlueworksLiveからProcess Centerにプロセスを移動して、開発を開始します。
6. さらに繰り返し：
   
   
   1. ビジネスプロセスの一部を開発します。
   2. ユーザーに結果を表示します（再生1..N）。

比較論文

以下の表は、PegaプラットフォームとIBMプラットフォームのさまざまな機能を比較しています。

ペガ	Ibm
要件とプロジェクト管理
Pegaは、ビジネスの目標、要件（アプリケーションが行うべきこと）、および仕様（アプリケーションが機能する方法）を管理するためのDCOツールと、それらの間の関係を指定する機能を提供します。 開発結果を仕様にリンクして、プロジェクトの進捗を追跡することもできます。	IBMには、BlueworksLiveに目標を入力し、BlueworksLiveにビジネスプロセスのステップの説明（Pegaの仕様に類似）を入力する機能がありますが、一般的な要件を導入し、目標を仕様または実装に関連付ける方法はありません。
位置の違い
Pegaは、ケース、プロセス、および/またはビジネスルールを自動化するための単一のツールです。 統合を自動化するには、外部データバスを使用することをお勧めします。	IBM BPMは、プロセスの自動化と統合のための単一のツールです。 IBMスタックには、ケースとビジネスルール用の個別の製品があります。
Pegaには、プログラマが残りの作業を行っている間に、個々のルールをビジネスユーザーに委任する機能があります。	IBM BPMには、ユーザーが「戦闘」操作中にそれらを変更できるように、ルールやビジネスプロセスの一部を分離する機能はありませんが、そのようなツールはIBM ODMで使用可能です。個々のビジネスルールを異なるグループに変更するアクセスを提供する機能があります。
建築上の違い
ペガにはオブジェクト指向アーキテクチャがあります。 データオブジェクトを1つのクラス、このデータを処理するロジック、および入力と出力のインターフェイスにカプセル化することが可能であり、推奨されます。	IBMには、サービス指向アーキテクチャー（SOA）があります。 データオブジェクトを1つのユニット、このデータを処理するロジック、および入力と出力のインターフェイスにカプセル化することは不可能です。
ペガでは、ケースのインスタンスには次のような単一のデータ領域があります。 すべてのステップ、サブプロセス、および画面フォームのセクション。 サブケースには個別のデータ領域があります。それらの入力データマッピングはIBMの場合と同様であり、出力は個別の特別なメカニズムによって集約されます。	IBM BPMでは、プロセスまたはサービスの各インスタンスは、そのデータ領域によって制限されます。 あるプロセスから別のプロセスにデータを転送するには（たとえば、プロセスデータで画面を開くとき）、入力変数と出力変数を明示的に指定し、呼び出しごとにマッピングする必要があります。
Pegaは、ルールセットメカニズムのおかげで、作成したルールを別のアプリケーションで再利用する機能を提供します。 追加の意図しないコンポーネントの再利用の難しさ：低。	IBM BPMでは、別のアプリケーションでの個々のコンポーネントの再利用は、それらを特別なツールキットに割り当てることによってのみ可能です。これには、すでに作成され動作しているアプリケーションのリファクタリングが必要になる場合があります。 追加の意図しないコンポーネントの再利用の難しさ：高。
テクニックとメカニズムの使用
Pegaにはハードコードを使用してカスタマイズできる小さなセットがありますが、非常に幅広い標準コンポーネントがあります。	IBM BPMの標準コンポーネントのセットはかなり小さくなっていますが、JavaScriptやJavaで独自のコンポーネントを簡単に開発できます。
Pegaには、モバイルデバイス用のインターフェイスを適合させるためのメカニズムが組み込まれています。	IBM BPMには、すぐに使用できるモバイルインターフェース用の適応メカニズムがまだありませんが、これを実現できる追加のプラグインライブラリ（ツールキット）があります。
Pegaのコントロールとイベントを使用すると、デザイナーで適切なオプションを選択することにより、AJAXの送信とデータの自動更新を実装できます。	IBMでは、フォームをリロードせずにデータを更新することは個別に実装されます。AJAX呼び出しをサポートする特別なタイプのサービスがあり、コントロールにはJavascriptイベントを処理する機能があります。 ただし、イベントとサービスの接続、データマッピング、および結果の処理は、プログラマーによって手動で実行されます。
外部システムからのデータを処理するには、DataPageを使用して、データレイヤーとビジネスロジックレイヤーから統合レイヤーを分離します。 通常、画面上の外部システムからのデータを使用する場合、このデータがいつどのように受信されたかを心配する必要はありません。	外部システムからのデータを使用した操作では、特別なタイプのサービスが使用されます。 統合層とビジネスロジック層の分離は、プログラマーによって手動でサポートされます（たとえば、内部ルールや開発の推奨事項）。 これらの外部システムを使用するには、それらを入力変数として取得するか、統合サービスを直接呼び出す必要があります。
カスタム関数
標準ポータルには、メッセージング、プロセスの参加者に関する情報などのソーシャル機能があります。 任意のプロセス呼び出しオプションで使用できます。	標準ポータルには、メッセージング、プロセスの参加者に関する情報、専門家の支援などのソーシャル機能があります。 標準ポータルを使用する場合にのみ使用できます。
すべてのメール通知（新しいタスク、遅延など）は、タスクごとに個別に構成されます。	IBM BPMの標準アラートは、アプリケーション全体ですぐにオンになり、すべての新しいタスクをユーザーに自動的に通知します。 ただし、ユーザー自身が何らかの種類の追加サービスを開始した場合にもアラートが発生します。 この点で、複雑なプロジェクトではほとんど使用されません。
PegaにはIBM BPMよりも多くの標準レポートがあり、プロセスの全体像を示しています。 追加のレポートはすべて、標準のレポートと同じテクノロジーに実装され、単一のインターフェーススペースに配置されます。	追加のレポートはすべて、標準のレポートと同じテクノロジーで実装されます。 開発環境には、プロセスの有効性を分析し、変更の結果を予測するために使用される特別なレポートもいくつかあります。 このツールは非常に強力ですが、カスタマイズされた開発サーバーとインストールされた開発環境が必要です。 この点で、非常にまれにしか使用されません。
Pega開発者ポータルで作業を開始するためのエントリのしきい値： ビジネスの専門家にとっては簡単です 基本的なレベルでは、これはプログラミングのスキルを必要としません。 プログラマーにとってはより困難です アーキテクチャのより包括的な理解と、より多くの側面の保持が必要です。	IBM BPM Process Designerで作業を開始するためのエントリーしきい値： ビジネスの専門家にとってはより困難です この環境はプログラミングを目的としています。 プログラマーにとっては簡単です。なぜなら 基本的なレベルでは、少数の特定の要素の知識で十分です。

ユニークな利点

このセクションでは、他のプラットフォームにはないプラットフォームの特別な利点について説明します。

ペガのユニークな利点：

• 宣言ルールは、いつでも実行する必要があるアプリケーションの特定の特性（ビジネスデータの計算式など）を指定するルールです。 PRPCは、これらのルールの課題と実施を独自に提供します。
  
  _{たとえば、変数の値を計算するための式を指定する式ルールを宣言します。 この式の実行は、エンジンによって次の2つのオプションのいずれかで提供されます。}
  
  
  • 数式の変数を変更するたびに結果を再計算します。
  • 計算された変数の値を読み取るたびに結果を再計算します。
  
  
  
• Dcoツール：プロジェクトの複雑さの評価。 ドキュメントのさまざまなセクションの作成。 目標、要件、仕様間の関係。

IBM BPMのユニークな利点：

• BPMN 2.0の単一のエンドツーエンドプロセスの可視性（そのようなプロセスを構築できる場合）。
• プロセス変更の結果の分析と予測の可能性。
  
  _{たとえば、ビジネスプロセスインスタンスが特定のブランチに沿って移動する頻度を確認し、総運用コストを計算できます。 次に、ビジネスプロセスを変更し、運用コストやその他のKPIの予測変化を確認します。}

結論の代わりに

2つのプラットフォームの技術的な違いはすべてありますが、依然として同じ主な問題があります。これらのプラットフォームを誤って使用する人々です。 ほとんどのプロジェクトの成功の鍵は、選択したプラットフォームにほとんど依存しない、いくつかの簡単な点にあります。

• あなたのプラットフォームを知ってください：多くの場合、プラットフォーム上の実世界のプロジェクトで、すでに存在するものが実装されていますが、わずかに異なる方法（別のユーザーポータル、独自の通知システムなど）で。
• もう一度-あなたのプラットフォームを知るために：そのようなプラットフォーム上の実際のプロジェクトでは、彼らが意図しないものを実装しようとすることも少なくありません（一般的なオプションはあらゆる種類の会計システムです）。
• ビジネス目標を設定する：「予算を使う」ためにプロジェクトが構想されている場合、プラットフォームがどれほど優れていても、成功する可能性は低いです。 対照的に、プロジェクトがその実装により毎月N百万ルーブルを節約できると理解して開発された場合、適切な人は適切なタイミングで適切な決定を下すインセンティブを持ちます。
• 開発プロセスにビジネスユーザーを巻き込む：別の一般的な問題は、大規模プロジェクトでは、ビジネスカスタマーからプログラマーまでの距離が、数十人のマネージャー、2つか3つの側面のアナリスト、アーキテクト、他のシンパサイザー、メガバイトのドキュメントによって測定されることです。 その結果、単に必要なものが実現されるだけではありません。

コメントまたはPMでご質問にお答えいたします。 BPMプラットフォームの他の側面の比較や、より詳細な説明に興味がある場合は、次の記事のトピックになると思います。



_{小さな更新：すでに記事の出版準備の段階で、夏にIBM BPM 8.5.5の新しいバージョンがリリースされ、いくつかの改善が加えられたことを知りました。 私はそれらにコメントできません 実際には見られません。 しかし、私の知る限り、物理的にこのバージョンはまだどこにも実装されていないため、実際の経験はありません。}