驚くほど複雑なワークフローがあり、社内の Web アプリケーションを使用して、準技術系の従業員が監視する必要があります。約 30 のステップがあり、その一部は手動 (編集)、一部は半自動の停止ポイント (「ファイルが受信されました」または特定のテンプレートの顧客承認など)、一部は完全に自動化されています (ファイル変換、検索インデックス作成、等）。これらすべてのステップのフローチャートは大規模で複雑であり、3 人のユーザーが 3 つのまったく異なるステップに同時に取り組んでいる可能性があります。
この膨大な量の情報を、ユーザーにできるだけ役立つようにどのように提示しますか? ダイアグラム全体を表示するだけでは、力ずくの解決策のように思えます。しかし、それは大きく、より多くのことを行うにつれて大きくなる可能性があります. このダイアグラム全体を HTML でエンコードするために必要な複雑さは言うまでもありません。
娯楽や嘲笑のためだけにこれらを表示したくないと思いますが、途中でユーザーを支援し、可能な限り自動化し、プロセスを文書化します。アプリの目標または目的を明確に定義すると、おそらく役立つでしょう。 .
「ビジネス ルールのデバッグ」を除いて、ワークフロー全体を表示しても意味がありません。クライアントがそれを見たいと思っているかもしれません。
あなたの目標がユーザーの仕事を支援することである場合、「プロジェクト」(またはより適切な用語)の状態と、他の状態への可能な遷移を提示します。
状態は、ほとんど独立した複数の変数である場合があります。たとえば、コンテンツの進行状況を説明するものがあります。たとえば、「未完了」/「完了」/「2 番目のスタッフによるレビュー済み」/「2 番目のスタッフによる承認済み」などです。並行して、たとえば、「テスト印刷日 = スケジュールなし」、「印刷日 = スケジュールなし」、「最終配達 = 明日、できれば昨日」などです。
トランジションは、「レビューのために顧客に送る」、「コンテンツを完了としてマークする」、「コンテンツを変更する」などです。
これはあなたが念頭に置いていることですか？
ワークフローをモジュールに分割し、各モジュールのアクティブな状態を表すことを提案します。
モジュールは、メイン ワークフローのサブセットです。たとえば、タスク、人、役割、部門などで分割できます。これにより、ワークフローの表現が大幅に簡素化されます。誰かが多くの重要な瞬間にデータ入力を担当しているとしましょう。彼のすべてのタスクを、同じアクティビティ、入力、出力、および条件を含む 1 つのモジュール (またはサブワークフロー) にグループ化できます。モジュールは相互に依存し、関連している可能性があります。
状態は、モジュール内での位置です。単純なワークフローでは、アクティブなタスクは 1 つだけです。実際にはマルチスレッドです！したがって、1 つのモジュールで多くの状態が同時にアクティブになる可能性があります。状態には、アクティブな入力、出力、およびメモリ ビットも含まれます。
入力は、ブール条件を評価するためのアクティビティを実行するために必要なものです。ドキュメント、データ、信号などの可能性があります...
出力とは、タスクの結果として得られるものです: 情報、ドキュメント、シグナル...
十分な定義ですか？
次に、ワークフローをLADDER LOGICに変換するだけで、状態を取得できます。
ウィキペディアのラダー ロジックの定義を参照してください。
アクティブな状態のみを表示します。
抽象的に見える？
ここに小さな例があります...
ジャネットはシステムにデータを入力します。彼女はダイアグラムの緑色のタスクを管理しています。私たちは他の仕事ではなく、彼女の仕事だけに集中します。彼女は、ワークフローで 16 のタスクを実行する方法を知っています。私たちは、彼女からの次のアクションが継続されるのを待っています。彼女のイントラネット ダッシュボードには次のように表示されます。
優先度 1 : 販売レポートに基づいて翌月分の鉛筆を注文するには、PO を送信する必要があります。
優先度 2 : 生産によって拒否された消しゴムの数を財務システムに入力する必要があります
数十万のはしごステップがある自動化された生産システムで多くのトラブルシューティングを行います (ワークフローは複雑すぎて全体を表すことができません)。システムがブロックされると、各モジュールを調べて、アクティベーション タスクの完了に必要な入力が欠落しているものを特定します。
幸運を！
Preziを使用して、この情報をユーザーにわかりやすく提示できます。
これは、ユーザーが現在の状態に到達するためにこれまでに行ったアクションを確認するのにも役立ちます。しかし、彼が完了したステップの数が増えるにつれて、この提示方法はユーザーにとって厄介になる可能性があります。ユーザーがワークフローの終わりに近づいたとします。次のステップを確認するには、ユーザーを苛立たせる可能性のあるすべてのステップを実行する必要があります。
これを回避するために、ワークフロー全体を時系列で3〜5フェーズに分割できます。フェーズは論理的に分割する必要があります。最終的な目的は、完全なワークフローでユーザーを圧倒しないことです。個人的には、あなたが示した方法で提示された場合、このワークフローに関連するタスクを回避しようとします。不快感はありません。あなたも同じように感じるに違いない。
州名を数字に置き換えた後、画像を再投稿できれば、より良い画像が得られる可能性があります。
レイヤーでやってみてください。最も詳細なレイヤーが完成したら、詳細を非表示にして、より高いレベルのビジネス プロセスにグループ化されたドキュメントを追加します。ユーザーは、これらの詳細の一部を安全に無視できる必要がありますが、自分の部分が全体にどのように適合するかを可視化することはユーザーにとって良いことです。
複数の上位レベルのドキュメントが必要になる場合があります。
これは、BPELが適している種類のアプリケーションのように思えます。
もちろん、今すぐシステムを再構築する必要はありません。しかし、多くの BPEL 実装があり、その中にはグラフィカルな編集ツールが含まれているものもあります。これらのいずれかが、スコープの処理と詳細の非表示に優れているため、現在の状況で役立つ場合があります。したがって、言語で他に何もしなくても、ワークフローを BPEL ダイアグラムとして描画することでメリットが得られると思います。
ウィキペディアのページには、利用可能な実装がいくつかリストされています。さらに、Oracle の JDeveloper IDE には、SOA スイートの一部として BPEL Diagrammer が含まれています。残念ながら、標準インストールの一部ではなくなりましたが、引き続き利用できます。 詳細をご覧ください。
フロー全体をどこかに文書化することをお勧めしますが、ユーザーに配布されるものに関しては、タスク指向のフローに焦点を当てるのはどうですか? 私が想像するように、1 人のユーザーがプロセス全体を担当することはありません。
たとえば、A と B の 2 つの役割があり、1 から 6 までの 6 つのタスクが順番に実行されているとします。各タスクには複数のステップがありますが、自己完結型です (例: ファイルのダウンロード、レビュー、プロセスの実行、再レビュー、アップロード)。A は偶数のタスクを実行し、B は奇数のタスクを実行します。
A は、タスク 2、4、および 6 を構成する詳細な手順について知る必要がありますが、1、3、および 5 で何が行われるかについては知りません。各タスクをブラック ボックスとして扱う図。この方法でフローをモジュール化できない場合は、プロセス自体を見直して、なぜそれほど複雑なのかを確認することをお勧めします。
ワークフロー シナリオの例、つまり、ワークフローを通過する可能性のある 1 つの遷移を示してはどうでしょうか。これを特定のユーザー プロファイルに合わせて、関連する状態を強調表示し、他の状態を暗くすることができます。これにより、実際の例を見ることで、移行の明確なアイデアを得ることができます。