私の顧客は、ビジネス プロセス管理 (BPM) ソリューションを探しています。彼らが必要としているのは、単純なドキュメント ルーティングと承認システムです。BPM システムを実装する原動力は何ですか? 開発者が BPM ソリューションとワークフロー ツールまたはカスタム開発のどちらを実装することを提案すべきか?
jBPM はいつ適合しますか? アプリに組み込まれたステート マシンが適合するのはいつですか? jBPM と同様のソリューションを使用する必要があると判断するために、どのような問題が存在する必要がありますか?
「私たちは自分でソリューションを構築しようとしましたが、_のために AquaLogic/jBPM/Lombardi を使用することになりました」という実際の例を探しています。空欄を埋めてください。
BPM Acid Test (O'Reilly 発行、Michael Havey 著 Essential Business Process Modeling より)。
... BPM は、本質的な状態またはプロセスの感覚を持つアプリケーション、つまりプロセス指向のアプリケーションにのみ適しています。アプリケーションが正当にプロセス指向である場合、そのアプリケーションは BPM 酸テストに合格します。たとえば、旅行代理店のアプリケーションは、旅程の状態に関して最もよく理解され、旅程がどこまで進んだかによって常に定義されるため、テストに合格します。プロセス指向アプリケーションのその他の典型的な特徴は、次のとおりです。
- 長時間 -
開始から終了まで、このプロセスには数時間、数日、数週間、数か月、またはそれ以上の期間がかかります。
- 持続状態 -
プロセスは存続期間が長いため、その状態はデータベースに永続化され、それをホストしているサーバーよりも長持ちします。
- バースト、ほとんどの時間睡眠 -
このプロセスはほとんどの時間をスリープ状態で過ごし、次のトリガー イベントが発生するのを待ちます。その時点で起動し、さまざまなアクティビティを実行します。
- システムまたは人間のコミュニケーションのオーケストレーション -
このプロセスは、さまざまなシステムまたは人間のアクターの通信を管理および調整する役割を果たします。
... たとえば、ユーザーが口座残高を照会し、現金を引き出し、小切手と現金を預け入れ、請求書を支払うことができる現金自動預け払い機では、プロセスの感覚はつかの間であり、重要ではありません。ATM はオンライン トランザクション プロセッサであり、プロセス指向のアプリケーションではありません。
雇用主が jBPM をモデルにした IP を所有したかったので、ワークフロー エンジンを作成しました。独自の有限ステート マシンを作成する代わりに、このようなツールを使用する理由は、永続性を変更せずに変更に対応し、ワークフロー プロセスのエッジ ケースをサポートするためです。
典型的な、またはおそらく「ナイーブ」と呼ぶ方が適切な、有限状態マシンの実装は、管理されるデータとデータが流れるプロセスに密接に結合された一連のデータベース テーブルを備えています。過去のバージョンを保持し、プロセス中に誰がどのアクションを実行したかを追跡する方法もあるかもしれません。これが問題となる場所では、データとプロセス構造が変更されます。次に、これらの密結合テーブルは、新しい構造を反映するように変更する必要があり、古いものと下位互換性がない場合があります。
ワークフロー エンジンは、シリアライゼーションを使用してデータとプロセスを表現し、統合ポイント (特にセキュリティ) を抽象化するという 2 つの方法でこの課題を克服します。シリアル化の側面は、データとプロセスがシステム内を一緒に移動できることを意味します。これにより、同じタイプのデータ インスタンスが、たとえば新しい状態を追加することによって、実行時にプロセスを変更できるようになるまで、まったく異なるプロセスに従うことができます。また、基盤となるストレージを変更する必要はありません。
統合ポイントは、プロセスにアルゴリズムを注入する手段であり、認証ストア (つまり、アクションを実行する必要があるユーザー) に結び付けます。注入されたアルゴリズムには、状態が完了したかどうかの決定が含まれる場合がありますが、認証ストアの例は LDAP です。
ここでのトレードオフは検索が難しいことです。たとえば、データはシリアル化されているため、通常、履歴情報をクエリすることはできません。レコードを取得し、逆シリアル化し、コードを使用して分析する以外は不可能です。
ワークフロー ツールのもう 1 つの側面は、その設計と機能に組み込まれているエクスペリエンスです。これは、自分で作成することを考えず、必要になったときに後悔する可能性があります。私の頭に浮かぶ 2 つのケースは、時限タスクと並列実行パスです。
時限タスクは、特定の期間が経過した後、データに対するアクターの責任を割り当てます。たとえば、プレス リリースが作成され、承認のために提出され、その後、レビューなしで 1 週間放置されたとします。おそらくシステムに実行してもらいたいことは、残っているドキュメントを特定し、適切な関係者の注意を引くことです。
私の経験 (コンテンツ管理システム) では並列実行パスは一般的ではありませんが、それでも十分に頻繁に発生する状況です。これは、特定のデータがレビューまたは処理の 2 つの異なるパスに送られ、後で再結合されるという考え方です。このタイプの問題には、便利なマージ アルゴリズムと、データを同時に乗算する機能が必要です。事後にそれを手製のソリューションに織り込むことは、特に履歴データを追跡したい場合は、見た目よりもはるかにトリッキーです。
システムが変更される可能性が低い場合、特に変更によって古い情報が破損する可能性がある場合は、独自に展開する方が簡単な解決策になる可能性があります。ただし、そのような耐久性が必要であると思われる場合、またはこれらの珍しいが困難なシナリオが発生する可能性があると思われる場合は、ワークフロー ツールを使用すると、データやビジネス プロセスとして窮地に陥ることがないように、より多くの柔軟性と保証が提供されます。変化する。
たぶん、いくつかの質問をすることが助けになるかもしれません。
プロセスは変わりますか？新しいバージョンのプロセスが存在する間、プロセスの古いバージョンは存続しますか? プロセス (および各ステップ) の実行時間を測定する必要がありますか?
それはビジネス プロセス (複数のリソースの状態のオーケストレーション) またはリソースのライフサイクル (単一のドキュメント/リソースの状態のみ) に関するものですか? ...
たいした回答じゃなくてすみません。
あなたの取り組みを推進するビジネス ニーズ (つまり、「ビジネス ケース」) を詳しく見ていきます。私の理解では、BPM/ワークフローには次の目標が 1 つ以上ある可能性があります。
1. アクションを自動化する
これは通常、ドキュメントの作成、情報のアーカイブ、ユーザーへの通知などのタスクの自動化を通じて人間を機械に置き換えるために必要です。
2. 各工程の追跡
企業は、大量のプロセスが存在する場合に追跡を確立する必要があり、ビジネス ユーザーは通常、オフィスのドキュメントや電子メールでプロセスを実行しているため、それらを追跡できなくなります。ステータスに対するすべての外部要求 (クライアントなどから) は、調査に変わります。
3. コントロールを確立する
マネージャーにとって、プロセスの概要を把握し、統計的に調査することが通常重要です。KPI が維持されているかどうか、遅延、例外などを確認します。
4. 進行中のドキュメント交換とコラボレーションを管理する
BPM は、多くの場合、電子メールや口頭によるコミュニケーションから BPM での追跡可能な交換への切り替えを可能にするため、ドキュメント交換ツールとして機能します。
5. エンタープライズ システム間のデータ交換を自動化する
これは純粋な統合のケースであり、通常、さまざまなシステムを使用して (またはシステムによって) 多数のアクションが既に実行されており、それらの間の情報交換を自動化する必要がある場合に必要です。
現在、フル機能のすぐに使用できる BPM は 2、3、場合によっては 4 に適しています。jBPM およびその他のワークフロー エンジンは 1 および 3 に適していますが、重要な注意点があります。複雑な構成/開発が必要です。
SOA ベースのプロセス オーケストレーション エンジン (BPM と呼ばれることもあります!) は、(5) と (3) に適しています。
お気軽にリストに追加して議論してください！これをブログ投稿として投稿し、ここでもう少し詳しく説明しました: http://processmate.net/do-you-need-a-bpm-or-a-workflow/
最終的に、ビジネス関連情報の処理を扱うすべてのビジネス システムは、BPM またはワークフロー システムです。ビジネスの情報処理は、役割とアクティビティを含むワークフローまたは「ビジネス プロセス」の観点から説明できます。
これらのビジネス アクティビティが Java、C#、またはその他のプログラミング言語で記述されることが多いという事実は、基本的に、自動化されたエージェントを使用してビジネス プロセスを規定および記述できるほど十分に成熟した技術がない自動化の結果にすぎません。
成長や市場投入までの時間などに重点が置かれ、長期的な保守や柔軟性について適切に考えずにコンピュータ化が行われました。現在コードにあるものの 99% はそうであってはなりません。
対照的に、リアルタイム制御システム、ビデオ ゲーム、ハイ パフォーマンス コンピューティング、予測、ビジネス インテリジェンス、および数学的分析はすべて、グラフィカルなワークフロー記述に適していない問題の例です。これらは、コンピューターによって実行され、コンピューターの専門家によって維持されるべきものです。
ビジネス プロセスは、ビジネス オペレーションの専門家によって規定され、記述され、読み取られる必要があります。柔軟性の向上は、これを可能にするテクノロジー (ワークフロー システム) が向上するにつれてますます認識されるようになり、世界経済が「成長」を重視しなくなるにつれて、より広く受け入れられるようになるでしょう。