ワークフロー システムを、一部の作業を自動化する通常のアプリケーションと区別するにはどうすればよいですか? システムがワークフロー システムとして分類されなければならない特定の機能はありますか?
5 に答える
Workflow systems manage objects (often logically or actual electronic replacements for documents) that have an associated state. The state of an object in the system is node in a state machine (or a Petri net).
State transitions move an object from one state to another. The transitions can be triggered by people, automated events, timers, calendars, etc. Usually the transitions represent steps in a process in the real world.
That's pretty abstract, so consider an example: bug tracking software. A bug report probably starts out unvalidated, and as such is in a QA tester's queue. The QA tester will validate the report and make sure the steps are clear, grade the report for severity etc., and assign it to a developer or developer group. It is then in the developer's queue, who will ultimately fix or decide not to fix the bug, which will send it back to QA for validation. If there's a dispute over the bug, it might go into a state in which it bubbles up the management stack.
A trivial implementation of the above is to use an enumeration for the state associated with every object, and make everybody's inbox be a query for objects with a state of a particular enumeration value.
That's the gist of it, but things can get more complex, such as splitting off new objects, reacting to non-human events such as timing, internal or external (i.e. third-party) services, etc.
ワークフロー管理システムは、システム内の複数の機能と、場合によってはワークフローの複数の参加者をホップするプロセスを通じてユーザーをプッシュします。ワークフロー エンジンはプロセスの状態を把握しており、これを独自のストレージに格納します。このストレージは、メイン アプリケーション データベースの一部である場合とそうでない場合があります。
ワークフローは、ステート マシン、ペトリ ネット、またはプレーンな古いスクリプト言語を含むその他のさまざまな構成要素を使用してモデル化できます。独立したオーケストレーション システムを使用して、複数のアプリケーションにわたるワークフローを管理できます。多くの (すべてではない)ワークフローの標準記述言語としてBPEL (Business Process Execution Language)をサポートしています。アプリケーションがサービス指向アーキテクチャとして設定されている場合、ワークフロー システムはアプリケーションの機能を制御してこれを行うことができます。ワークフロー エンジンのもう 1 つの機能は、ワークフローを中止し、データベースの一貫性を維持しながら状態の変更を元に戻すことができることです。
www.workflowpatterns.comには、ワークフロー システムに関するドキュメントのコレクションと、パターンのライブラリがあります。
ワークフロー システムのアプリケーションの例:
保険金請求管理。本質的にそれらすべての祖父です。通常、このプロセスには、誰がどのくらいの金額を承認できるか、誰がさまざまな種類のビジネスの請求を処理できるか、監査証跡を提供するためにどの文書を提示してリンクする必要があるか、支払いの問題を発行および追跡し、損失調整作業を承認できるかを規定するルールがあります。 . 典型的な請求ワークフローは、通知から準備金と支払いの承認、支払いの発行まで請求を追跡し、損失調整作業を手配するためのサイドプロセス (おそらく第三者を通じて)、これが完了するまで支払い権限を保持し、支払いを発行し、支払いを発行します。損害調査費の支払い。実際には、これらのプロセスは非常に複雑になる可能性があります。
コンピュータシステムなどの複雑な製品の発注、見積もり、構成管理。
珍しい例の 1 つは、医薬品メーカーが開発した新医薬品の承認プロセスを追跡するシステムでした。これには、規制フレームワークがコード化されたエキスパート システムも組み込まれており、規制のフープを通る最短経路を選択できます。これにより、市場投入までの平均 R&D ライフサイクル時間が 9 年から 5.5 年に短縮されました。
ビジネス プロセスの外部ドキュメントを参照する必要なく、ユーザーがビジネス プロセスをガイドされる場合、アプリケーションをワークフロー システムと見なします。
Barry のバグ追跡の例を拡張すると、たとえば、「閉じる」というボタンが押されたときにバグがクローズ状態に移行し、ユーザーがクローズ コメントを入力できるようになる場合、バグ追跡アプリケーションはワークフロー アプリケーションであると言えます。タイムスタンプとユーザー名を入力し、通知電子メールを送信します。
ユーザーがドロップダウンから新しい状態を選択し、通知電子メールを自分で送信する必要がある場合、それはワークフロー システムではありません。
ビジネス プロセスの全体または一部を自動化することで、一連の手続き規則に従って、ドキュメント、情報、またはタスクが 1 つの参加者から別の参加者*に渡されます。
*participant = resource (human or machine)
私の意見では、ソフトウェアに関して 2 種類のワークフローがあります。静的 (または組み込み) ワークフローと動的 (プログラム可能な) ワークフロー。多くのドキュメント管理、バグ追跡、またはブログ ソフトウェアでさえ、単純な状態遷移を使用する組み込みのワークフローを備えています。
人々が「ワークフロー」と言うとき、それは一般的に、既存のソフトウェアにビジネス ロジックをプログラムできるものを意味していると思います。たとえば、在庫にニンジンが不足している場合、自動的に sysco を呼び出します。
ワークフロー機能の実際の例については、Microsoft Dynamics CRMを参照してください。
正確な定義があるとは思いません。ここにいくつかの緩い基準があります:
- 複数の人の作業を調整する (ただし、グループウェアは除く)。
- 複雑な組織環境の中で
- 通常、管理されたビジネス プロセスの一部として (BPM のように)。