そのため、 最初の部分では、変化に対する耐性の程度、特定のタイプのBPを実装するための技術的概念、および適応BPモデルにタスクを追加/削除するロジックの例に関して、どのようなビジネスプロセスがあるかを調べました。
記事のこの部分では、アダプティブBPM（aBPM）が規範的BPM（nBPM）およびアダプティブケースマネジメント（ACM）とどのように異なるかを詳細に説明し、結果のaBPMシステムのアーキテクチャを紹介します。
図1は、明示的に構造化されたPSU（nBPM）から暗黙的に構造化されたPSU、つまりACMへの移行を明確に示しています。
これは、nBPMが前世紀であり、ACMの背後に管理プロセスの自動化の未来があるということではありません。
あるコンテキストの一部のPSUには、1つのアプローチがより適用可能であり、別のコンテキストの他のPSUには、異なるモデリングアプローチが適用できます。
例は、最も旅行されたBP「休暇申請」です。 ACMまたは通常のTreeSetを使用して、このプロセスを実装することができます。
これは、釘をボードに打ち込むことと比較できます。 ハンマーを使って釘を打つことは良いことです。建設杭を打ち込むための設備を取ってから、強度、振幅、衝撃角を計算し、この設備で釘を打つことができます。 結果は同じです-釘は打たれますが、簡単な問題を解決するための解決策（杭用のそのようなリグの設計と製造を含む）はどれほど困難でしたか？ そして、杭を打つためには、ハンマーはまったく適していません。
タスクに適用するツールとコンテキストを理解することが重要です。
nBPM-同じ企業内での明確に構造化された短期間のBP実行に適しています。たとえば、同じBP "vacation request"。
ACM-プロセスの各インスタンスを状況に応じて個別にモデル化できる場合、暗黙的に構造化されたBPの問題、たとえば医療や保険の問題を適切に解決します。 AFMアプリケーションのいくつかの例が maxstroyによって説明されています 。
私の意見では、aBPMは明確なnBPM構造と複雑なACMのクロスです。 プロセスインスタンスの長期実行のBPモデルに予期しない変更があった場合に、適切に適用されます。
金融業界の典型的な例は「ローンの返済」です（BPの実行期間は最大30年です）-起動時には、BPモデルは最新であり、実行中のすべてのプロセスインスタンスは同じです。 ただし、30年以上にわたって、プロセスモデルの新しい要件が発生し（たとえば、法律の変更）、必要な変更が既に実行中のプロセスのインスタンスに適用されています。つまり、このインスタンスの実行を中断することはありません。 すべての新しいプロセスインスタンスにはすでにこれらの変更が含まれており、いわゆるBPの進化が行われます。
偶然、私はほとんどの場合aBPMに対処しましたが、これについては後で説明します。
aBPMアーキテクチャは、従来のBPMエンジンに対する「アドオン」です。
アーキテクチャはメーカーに依存しないため、1つのBPMエンジンから別のBPMエンジンへのBP移行を管理する機会がもう1つあります（たとえば、Red HatがこのBPMエンジンのサポートと開発を拒否したJBoss BPMで発生したように）。
BPM-Adapter-各タイプのBPMエンジンとの通信機能をカプセル化します。 この例では、1つのタイプのBPMエンジンのみが使用されます。これはオープンソースのCamunda BPM （ Activiti BPMのフォーク）ですが、原則として、任意の組み合わせが可能です。
PCS-システムのコアであり、BPMエンジンのすべてのプロセスを制御します。 たとえば、プロセスインスタンスを開始する関数を呼び出すと、PCSはBPモデルのバージョンを制御し、どのバージョンをどのBPMエンジンで実行するかを決定します。
次のパートでは、aBPMプロセスのモデリングについて説明します。
今後、aBPMモデリングの主なアイデアに注目したいと思います。
aBPMモデルは、プロセスの2つのサブタイプで構成されています。
-対象のビジネスプロセス
-技術的なビジネスプロセス
対象のビジネスプロセスは技術的なBPから組み立てられ、 技術的なBPから、このBPのビジネスロジックモデルが構築されます。 サブジェクトBPでは、BPMN 2.0標準の要素の部分的な使用のみが許可されています。
技術的なビジネスプロセスには、BPMN 2.0標準のすべての機能が含まれています。
ご清聴ありがとうございました。記事の次の部分までブックマークに追加してください。